背景几年前，运维迎来了一场业务整合，倒逼了后端IT能力的整合。由于系统之间的依赖关系和运行环境的差异，导致系统迁移后无法使用。因此，在不改变当前发布模式的情况下，需要对依赖的运维平台系统进行重构和修改。需求由此产生，并会随着业务的发展向外扩展。本文将带你了解平台从过去到现在，新的设计方案如何融入现有系统？重新设计的平台带来了哪些变化？团队在建设过程中收获了什么？经验和经历？目前整合期间，发布部署系统、业务调度、DB需求和执行平台、配置中心都保留，带来两个问题：1、运行环境不同，所有系统都需要修改和重新编程，以确保新平台的稳定运行2.发布部署系统和其他强烈依赖CMDB控制发布过程的设备。因此，为了保证业务的正常迭代，需要对关键路径进行重构。经过两年的努力，目前的系统构成大致如下，有的是和之前的电商系统集成，有的是新建平台：1、CMDB和其他互联网公司类似。通过底层CMDB建立设备与业务、设备与人的关系，记录设备生命周期和生命状态。然后向资源管理系统角色中的所有其他系统调用提供信息。对于CMDB数据的维护，我们通过与各个系统的联动来反向保证数据的准确性，比如与RPM包发布的联动：因为集成前系统依赖的CMDB是业务型的CMDB，我们也重建时针对业务CMDB。2.配置中心配置中心是一个重要的生存系统，管理访问路由和DB路由信息，负责负载均衡、业务容灾以及所有业务包的基础配置、业务间调用、DB路由接入和自动切换设备的版本管理和分发，以及设备角色的管理，都是通过配置agent完成配置中心到目标机内存的分发。总体架构图如下图所示：Configprocessor采用多线程模型并行处理configagent和jsf事务。用户通过portal进入配置中心，提交给DB供服务器读取。将内存的时间戳发送给服务器，服务器判断时间戳是否过时。如果它已过时，它会将新配置文件的内容发送给代理。代理将配置信息更新到共享内存并刷新时间戳。另外，服务端也会主动将配置信息发送给代理，在共享内存中维护一个互斥量以确保更新不冲突。此外，配置中心还支持白名单功能，对配置进行灰度化。3.调度系统负责执行命令和向设备下发文件。其他系统中的任何文件或命令下发动作都通过调度系统集中处理。这样做的好处是可追溯，权限可控，返回日志统一。比如DB需要自动执行平台。需求方提出需求后，平台会通过初审，交给DBA审批。审核通过后，需求平台将SQL打包成脚本，通过调度平台传递给目标端执行，并返回结果。4.应用持续部署我们采用RPM方案进行应用部署，是目前业界少见的开源包管理方案。主要的考虑是：1.RPM作为开源世界的通用解决方案已经非常成熟，可以自由开发，在spec文件中定义安装前、安装后、卸载后各个阶段的动作。2、通过在spec文件中标注包所属组的概念，可以很好的控制包的发布权限。3.通过在spec中定义Requires，可以方便的管理依赖，平台不再维护复杂的包依赖。目前R&D通过JATS编译C++包，然后通过RPM将编译好的二进制文件打包到RPM包中，通过发布设备角色（dev、伽马、idc）和人员（开发、测试、运维）角色打包发布。相应地定义和发布，并控制发布过程。EOS是运营商对页面切片和CDN的发布和回滚。通过配置中心区分设备角色，然后下发相应的页面切片文件。安全扫描包括CGI和域名扫描，定期启动在线漏洞扫描，保障业务安全。5、质量监控平台GMS基础监控平台基于openfalcon开源修改，对物理机、docker进行基础项、组件、自定义监控告警。目前自研的日志监控平台通过日志采集、过滤、统计等方式接入GMS。基础监控平台监控nginx日志，红绿灯系统监控是业务维度的监控。通过集团的可用率报告细化到业务的健康状态管理。调模系统通过配置中心业务间的调用关系完成调用链的梳理。以及调用链路的可用率统计。容量管理利用GMS基础监控数据，计算设备和业务维度的负载率，管理高低负载。6、DB管理平台深圳侧的DB层主要是mysql和redis，所以DB需求的自动执行，备份中心以及自研redis集群的实例管理都是围绕着这两个做的。以下是这些平台的建设和转型过程的大致描述：融合方案业务整合后，业务需要快速迭代，效率是第一要务。通过梳理系统上的依赖关系，我们确定了自下而上先填充再扩展的方案。也就是从顶层的CMDB开始，填补现有系统强依赖的关键路径，然后构建缺失的部分。第一阶段，我们决定重建一个小型的CMDB，解决大部分剩余系统的关键依赖；第二阶段，我们保证了剩余系统的正常运行，保证了业务的快速迭代上线；第三阶段，我们专注于质量提升，下面简单介绍一下这三个阶段：第一阶段：重建小型CMDB关于CMDB系统，通常从使用上分为两层，面向基础设施的资源管理系统和面向业务的资源管理系统。对于京东深圳事业部来说，主要偏向于业务层，所以系统建设主要是面向业务的，基础层由集团管理。为了快速匹配现有系统实现核心需求，CMDB的业务标注沿用了之前的方法，使用模块树进行管理，按照深圳业务的三层模块进行标注。如图：作为面向业务的资源管理，数据变化频繁，可维护性非常重要。当业务部门没有自动发现机房和访问拓扑时，主要采用资源共享来保证数据的准确性。提供资源共享和维护的API，如维护设备状态，设备负责人的数据用于监控系统的判断和推送；维护模块的环境属性用于RPM包系统和IDC环境的包发布判断测试，便于发布管控，从而反向保证CMDB数据的准确性。目前CMDB管理23个属性，包括设备属性（IP、配置信息、机房）、设备-业务关系（业务模块、集群）、设备-人关系（运维人、研发）、设备寿命状态（Maintenance、operation）、生命周期（transferrecords）等，基本上标记了当前设备的画像。当然还需要结合RPM包发布和配置中心来管理服务包和基础包的信息。第二阶段：保证留存系统的正常运行留存系统主要是配置中心和发布部署系统。限于篇幅，这里只介绍RPM系统。目前系统完成打包、包信息注册、版本管理、发布回滚、权限控制等动作，目前管理包1200多个，两年支持发布7万个。顺利完成了日常的包发布和紧急扩容需求。简单结构如下：dashboard如下：目前也在考虑对现有的RPM系统进行改造。现在docker已经大规模应用，如何将包发布与docker充分结合，发挥docker快速交付的优势，是需要优化的地方。第三阶段：质量优化提升业务系统上线后开始扩容，首先考虑提升质量，主要是建立一套自下而上的立体监控，运维主要负责建设前两层及以上提供API。对于任何监控来说，数据都是第一位的，所以它侧重于对各种数据源的采集和整合，主要针对CMDB、采集代理、配置中心调用关系、集团UMP数据上报点的关联。经过对基础设施层和基础组件监控系统的多方考察，采用并修改了小米的开源openfalcon。改造要点如下：1、agent同时适配物理机和docker。2、打通CMDB并创建API，方便未来容量系统数据共享，打通自研告警网关（邮件、短信、微信）3、改造系统以应用为主/模块监控4、扩展服务组件的监控功能，对nginx、mysql、redis等自研组件做专项采集docker的使用不再适用于传统的采集代理。为避免出现不同类型的设备拆分到不同系统的情况，对代理端进行了改造，采用了相同的报表格式和不同的采集方式。鉴于母机没有权限，与南京云不同。平台合作，物理机采用传统的collection，docker采用api数据并整合，将两者的监控项统一，实现表现形式的统一。目前监控上报设备基础监控项，如CPU、内存、丢包率、重传率、文件节点、coredump等，另外还有针对服务组件的特殊上报内容，如nginx.conn.active和nginxnginx的.conn。reading等。为了保证告警的有效性，我们通过针对不同应用的个性化监控策略，将每天的基础告警数量维持在20-50个之间，以保证运维对告警的敏感性。下图是dashboard：根据模块的综合视图，在大规模的横向比较中，用户对数字的敏感度高于图形线条，所以我们设置数字作为第一屏，图形线条作为第二入口来提供趋势查看下图组件监控的部署流程，以nginx为例：日志分析目前正在完善中。由于架构的特殊性，nginx的日志需要进行二次处理，所以在采集端做了开发。当错误日志过多时，进程处理方便消息队列拥堵。目前的架构图如下：日志分析中域名错误数的监控：通过红绿灯系统进行应用层监控，根据集团UMP业务监控系统的数据进行整合。界面层监控采用红、黄、绿三色标识。接口层监控系统根据上面的配置中心梳理调用关系，然后根据ump报告计算当前可用率。进入京东体系后，我们重新审视如何做。我们会继续用大电商平台的思维来优化我们的平台，比如细粒度的管理和监控，Docker的持续交付。众所周知，京东是目前国内使用Docker最为凶猛的公司。Docker作为一个新的IT对象，对原有的持续部署、CMDB、监控、数据分析等平台提出了新的体系和要求。其实，世界上最痛苦的事情就是遗留系统的集成。我们花了一年多的时间才完成这次整合、迁移和新业务的启动。涉及数千台底层服务器，300多个业务模块，100多个应用的??能力迁移。有挑战，也有慢慢收获和经验。运维体系的建设过程是从运维到运营理念的转变过程。当通过标准化把具体的设备和抽象的服务标准化，搭建起基础的持续交付系统，收集各种数据进行监控，如何利用现有系统进一步提升效率，利用数据为业务提供更多的服务？参考支持是一种进一步思考的能力；比如如何利用RPM进一步快速交付和扩容以满足开发，如何更精细地收集日志分析数据，让研发更了解自己的CGI使用情况。这些都是运维需要考虑的。CMDB的分层解耦非常重要。需要将CMDB区分为基础资源管理型CMDB和业务型CMDB。用于改进CMDB数据的维度更改系统。强依赖是上层运维管理平台迁移的最大障碍。自上而下的业务驱动需求生成和自下而上的系统构建分而治之，在业务整合中表现得非常明显。当有比较成熟的中间系统时，如何保证系统的稳定性，并以此作为核心扩展？需求自上而下发生，要求构建者自下而上构建。每个系统都是一个资源池。只有通过系统关联共享资源池，才能盘活系统，保证系统高效准确运行，而不是沦为工具平台。系统建立后的维护非常重要。加强系统间依赖是为了减少系统维护。盘活平台的一个重要途径也是一个关键路径，比如RPM系统如何与CMDB挂钩。提供数据采集端数据后，结合监控、容量管理、CMDB，轻松支撑IT运维分析。运维系统的设计大多咨询研发和业务产品经理。这里的咨询不仅包括技术，还包括使用。维护要专业，更何况运维平台的用户也来自于研发。方便用户的系统更容易推广和使用，也容易得到反馈。当然，切记任何系统都要把反馈入口放在显眼的位置：）运维平台的建设也是一个迭代演进的过程。没有业务的变化，就没有平台的迭代；如果没有Docker的快速引入，就没有必要演进RPM平台。所以运维平台本身和业务技术架构是一样的。随着业务和技术的变化，它也强调适应性。
