背景
几年前运维迎来业务上的一次融合，从而倒逼后端的IT能力进行整合。因为系统间的依赖关系，另外运行环境也有差别，导致系统迁移后无法使用，因此在不改变当前发布模式的情况下，需要重建依赖的运维平台体系并进行改造，需求由此而生并随着业务发展向外扩展。本文将带大家去了解平台从过去到现在，新的设计方案如何融合到现有体系中?重新设计后的平台又带来了什么样的变化?在建设的过程中，团队又获得了什么样的心得和体验?
当前现状
融合时期保留了发布部署系统，业务调度，DB需求与执行平台和配置中心，这就带来两个问题：
1. 运行环境不同，所有系统需要修改重编保证在新平台的稳定运行
2. 发布部署系统等强依赖CMDB的设备与业务的关系，从而管控发布流程
因此为了保证业务能够正常迭代，需要重建关键路径，经过两年的努力，目前体系组成大致框架如下所示，部分是融合之前电商的系统，部分是新搭建的平台：
1. CMDB
与其他互联网公司类似，通过底层CMDB构建设备与业务、设备与人的关系，设备生命周期、生命状态的记录，进而以资源管理系统的角色提供信息给其他所有系统调用。对于CMDB数据的维护，我们通过多种系统与其联动反向保证数据准确性，比如与RPM包发布的联动：
因为融合前系统依赖的CMDB为业务型CMDB，因此我们重建时也以业务CMDB为目标。
2. 配置中心
配置中心为留存下来的重要系统，管理访问路由和DB路由信息，负责负载均衡、业务容灾、以及所有业务包的基础配置、业务间调用、DB路由访问与自动切换等配置信息的版本管理和下发、以及设备角色的管理，通过配置agent完成配置中心到目标机器内存的下发。大致架构图如下图所示：
Configprocessor采用多线程模型，并行处理configagent和jsf的事务，用户通过门户输入配置中心并提交至DB交由server读取，agent与serer保持长连接，会定期发送本地共享内存的时间戳到server，server判断时间戳是否过时，过时则发送新的配置文件内容到agent，agent将配置信息更新至共享内存并刷新时间戳，另外server也会主动将配置信息下发至agent，共享内存中维护互斥锁，保证更新不冲突。此外配置中心还支持白名单功能，对配置进行灰度。
3. 调度系统
负责对设备的命令执行和文件下发，其他系统任何的文件或者命令下发动作，都集中通过调度系统去处理，这样做的好处就是可追踪，权限可控且返回日志统一。比如DB需求自动执行平台，需求者提出需求后，平台初审完毕交由DBA审批，审批完毕后需求平台将SQL打包为脚本，通过调度平台传递到目的端执行，并返回结果。
4. 应用持续部署
应用部署我们采用的是RPM的方案，目前也是业界少有的采用开源包管理方案，主要的考虑点是：
1. RPM作为开源界通用的方案已经非常成熟，开发可以自由在spec文件中安装前，安装后，卸载后等各阶段的动作进行定义
2. 通过在spec文件中标注包所属组的概念，可以很好地管控包发布权限
3. 通过在spec中定义Requires，可以方便的管理依赖关系，平台不再维护复杂的包依赖。
目前研发通过JATS对C++包进行编译，然后通过RPM将编译成功的二进制文件进行RPM包的打包，通过包发布对设备角色(dev，gamma，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，配置信息，机房)，设备与业务关系(业务模块，所属集群)，设备与人的关系(运维负责人，所属研发)，设备生命状态(维护，运营)，生命周期(流转记录)等，基本标示了当前设备的画像。当然这里还需要与RPM包发布，配置中心结合起来，管理服务包与基础包的信息等。
第二阶段：确保留存系统正常运转
留存系统主要为配置中心和发布部署系统，篇幅所限这里只介绍RPM系统，目前系统完成打包，包信息登记，版本管理，发布与回滚，权限控制等动作，目前管理包1200余个，两年时间中支持发布7w次， 很好地完成了日常包发布和紧急扩容等需求，简单架构如下：
dashboard如下：
目前我们也在考虑对现存RPM系统的改造，如今已经大规模应用docker，如何将包发布与docker充分结合，发挥docker快速交付的优势是需要优化的地方。
第三阶段：质量优化与提升
业务系统可用后，我们开始进行扩充，首先考虑提升质量，主要是建立一套自下而上的立体化监控，运维主要负责***两层的搭建并向上提供API。
任何监控，数据为先，因此着重汇聚各种数据来源，并进行整合，主要为CMDB、采集agent、配置中心调用关系、集团UMP数据上报点等四者进行关联。
基础设施层和基础组件监控系统
各种考察之后采用了小米开源的openfalcon并进行了改造。改造点如下：
1. agent同时适配实体机与docker
2. 打通CMDB并新建API方便未来容量系统进行数据共享，打通自研的告警网关(邮件、短信、微信)
3. 将系统改造成主要面向应用/模块的监控
4. 扩展服务组件监控的功能，对nginx，mysql，redis和其他自研组件做特别收集
5. 方便插件开发和使用
系统建设期间面临的***个问题就是京东当时正在大规模采用docker，这对于传统的采集agent不再适用，为了避免不同类型设备割裂为不同系统的情况，对agent端进行了改造，采取相同汇报格式不同采集方式，鉴于对母机没有权限下放，与南京云平台合作，实体机采取传统采集，docker采用api数据并整合，对二者监控项进行了统一，从而表现形式上实现了统一。
目前监控上报设备基础监控项，比如CPU，内存，丢包率，重传率，文件节点，coredump等，另外对服务组件有特殊的上报内容，比如nginx的nginx.conn.active， nginx.conn.reading等。
为了保证告警有效性，我们通过不同应用的个性化监控策略，维持每日基础告警数在20-50之间，从而保证运维对告警的敏感度。下图为dashboard：
如下图按照模块的综合视图，用户在大批量的横向对比中对数字的敏感度要高于图线敏感度，因此我们将数字设为首屏，图线作为第二入口提供趋势的查看
下图组件监控的部署流程，以nginx为例：
日志分析目前正在完善，由于架构特殊性，需要对nginx日志做二次处理，因此在收集端做了开发，消费者log-viewer采用多进程处理，便于错误日志过多时消息队列拥塞，目前架构图如下：
日志分析中的域名错误数监控：
应用层监控
通过红绿灯系统来承担，根据集团的UMP业务监控系统数据做了整合，直观的按照红黄绿三色做标示
接口层监控
接口层监控系统根据上文的配置中心，梳理出调用关系，再根据ump上报，计算出当前可用率
心得
随着进入京东的体系之后，我们重新审视，如何用大电商平台化的思维来持续优化我们的平台，比如说精细化的管理和监控，持续交付Docker化。我们都知道目前京东是国内Docker使用最凶猛的公司，Docker作为一种新的IT对象，对原有的持续部署、CMDB、监控、数据分析等平台都提出了新的体系和要求。
其实世界上最痛苦的事情就是莫过于做遗留系统整合的事情了，我们用一年多时间来完成了这次的整合、迁移和新业务上线。其中涉及到底层服务器数千台，业务模块300多个，应用100多个的能力迁移，有挑战，更是慢慢的收获与心得。
运维系统的搭建过程是一个从运维到运营观念转变过程。
当通过标准化对具体的设备和抽象的业务进行规范，搭建起来基本的持续交付系统，采集到各项数据做监控之后，如何利用现有系统更进一步的提升效率，利用数据为业务提供更多的参考支持是更进一步需要思考的能力;比如如何利用RPM更进一步快速交付扩容让开发满意，如何更精细的收集日志分析数据使研发对自己的CGI使用有更多的了解，这些都是运维需要考虑的问题。
CMDB的分层解耦很重要
一定要把CMDB区分出基础资源管理型CMDB和业务型CMDB，面向上层应用的CMDB可以脱离底层基础资源层的CMDB而存在，通过自己的一套数据自动化发现和运维变更体系来完善CMDB数据。强依赖是上层运维管理平台迁移的***障碍。
自上而下的业务驱动产生需求和自下而上的系统建设分而治之
这一点在业务融合中非常明显，当有一个相对成熟的中间系统时，如何才能保证系统稳定并以此为核心扩展，这一需求从上而下发生，并且需要建设者自下而上的建设。
每个系统都是一个资源池，通过系统关联进行资源池共享才能盘活系统，保证系统高效准确的运转，而不是沦落为一个工具平台
系统建立起来后维护非常重要，加强系统间依赖是减轻系统维护的一个重要方式，也是盘活平台的关键路径，比如RPM系统如何与CMDB联动，数据采集端的数据提供上来后，监控、容量管理、CMDB三者结合很容易为IT运营分析做支撑。
运维系统的设计多咨询研发和业务产品经理
这里的咨询不只包括技术上的，也是使用上的，业务研发和产品经理作为最靠近用户的一端，对原型设计，系统使用上如何影响用户比运维要专业，何况运维平台的用户也来自研发，一个对用户方便的系统比较容易推广使用，也容易受到反馈，当然，记得任何系统都要把反馈入口放在显眼位置：)
运维平台建设也是一个迭代和演进的过程
如果没有业务变更，就没有此次平台的迭代;如果没有Docker快速的引入，就无需对RPM平台进行演进。因此运维平台本身也和业务技术架构一样，随着业务和技术的变化，本身也在强调适应性。
