10万台服务器怎么实现自动化运维？腾讯梁定安解密织云系统！
文章来自 壹佰案例
导读
腾讯社交业务产品种类繁多，拥几亿用户群体，在移动互联网时代，用户可能因各种难以预料的问题或异常，导致无法正常使用腾讯的社交服务，如何监控用户侧对我们产品的实际使用体验或感受，成为运维团队建设监控能力的一个新挑战。
该实践案例源于运维团队，是对传统质量监控技术的一个更新，结合爬虫、大数据、波测等技术手段，对不同纬度的数据进行关联，得出能用以度量用户体验的指标，指导业务不断优化，是运维技术转化为产品价值的实践案例。
（全文共4471字 预计阅读时长：5分钟）
一、 “织云”轻松应对海量运维需求
面对腾讯社交网络海量运维（大于10w台服务器）的业务要求，运维如何武装自己，利用自动化技术和devops理论提升工作效率，以保证运维团队在业务快速发展和海量运维繁杂的需求中，从容不迫，轻松应对，其中的秘诀就是腾讯DevOps自动化运维平台“织云”。
本章将从0开始带领读者深入理解“织云”的工作原理和技术架构，希望给读者以启发，在各自的运维岗位上，设计出最适用的自动化运维管理系统。
二、为什么要做“织云”
腾讯社交网络运营部负责腾讯旗下所有社交类业务的运维支持工作，如QQ、Qzone、QQ音乐、QQ相册等服务的技术运营工作。做织云的原因，我们总结为下述4点，如图1所示。
图1 “织云”产生的背景
规模
腾讯SNG的设备数量5年间从几千台增长到10万台，要更高效地管理这么多的设备，提升效率是运维团队发展的必然结果。
成本
腾讯公司的快速增长，设备、带宽运营成本高居不下，老旧机房裁撤，新旧机型、虚拟化技术替换等等因素，都对运维效率提出了很高的要求。
趋势
云计算、devops的兴起，整个行业都在创新，运维也在自己负责的领域中寻求新的技术突破口。
使命
技术人的情节、业务寄予的期望、职责成熟度的标志，各种原因都会趋使我们运维人的进步和进化。
三、 “织云”的工作原理
“织云”的工作原理主要是将devops的合作文化贯彻在日常开发、测试、运维三个角色的协同工作中，建设成由三个不同角色共同操作的自动化运维平台，具体原理如下所述：
合作理念
要实现运维自动化目标，与开发、测试、运维高效的协作，我们首先从团队文化上求变，devops正好是高效运维需要的最佳合作实践方案。开发、测试、运维三者都是以用户价值、业务价值为最终的目标和共同责任，彼此之间良好的合作，少了推脱少了扯皮，打通了阻碍工作效率的瓶颈，从而为实现自动化打好地基。
工作原理
织云的工作原理归纳为4步，如图2所示。
图2 “织云”的工作原理
将运维规范转换成可落地（看得见摸得着）的资源配置，这样运维系统便可以基于这些自动化操作中依赖的资源配置，发起相应的操作流程，通过技术的手段将资源配置push到生产环境中。
简而言之就是将标准化的运维管理对象，统一在cmdb中记录，结合自动化流程，实现对生产环境的自动化操作。
设计织云平台的主要出发点是因为在腾讯运维的不同发展阶段中，我们都有对应的阶段性运维工具/系统产物。这些运维工具/系统会覆盖固定的运维操作场景，提供高效和高质量的操作支持。
基于这些技术的储备，织云继承了所有运维工具/系统的优点，并提出更高的标准化要求。同时提供了一种创新的协作模式，让开发、测试、运维3个角色在织云平台中各司其职，共同承担运维的服务。织云平台还具备智能的决策分析能力，能够无需人工介入，全自动化的发起操作决策，将人介入的这个环节释放掉。
四、 “织云”的技术架构
● 4.1织云的核心模块
织云的技术架构，如图3所示。
图3 “织云”的技术架构
织云门户提供用户（开发、测试、运维）协作的管理操作页面，也是作为后续功能的入参来源，这部分配置信息无法自动获取，需要人工进行一次性的初始化环境配置。
决策系统，流程系统，是相互配合的两个功能模块，主要是根据一定的信息分析、判断，识别出异常，触发不同流程，全自动化地完成特定场景的运维操作功能。
工具库，继承织云平台之前运维工具/系统建设的成果，为流程引擎输出不同工具能力的支持，流程引擎则负责在不同的工具间传递参数，使工具间能够有效的配合，有顺序、有逻辑的进行拼接，从而自动化地完成运维预先定义好的操作流。
工具库调用的具体子系统有很多，图中只是列举了部分常用的系统。以权限中心为例，它是一个业务权限管理系统，负责按IP集群管理其对一些敏感业务权限的增、删、改、查功能。业务权限在腾讯服务中是个很普遍的需求，因为腾讯很多业务都是基于QQ平台而延伸出来的社交社区，这些社区/服务依赖于QQ关系链、QQ昵称、好友生日等等重要数据信息，腾讯内部对于不同的敏感数据都有权限管理，权限中心则负责实现权限管理的自动化。
命令通道，这是运维通用的一个管理服务器的传输和执行命令的关系，支持大批量文件传输、命令的远程解析和执行。
CMDB将运维预先定义的标准化管理对象作为标准配置项记录下来，为流程、工具、一致性监控提供配置接口，是所有自动化运维操作的数据源，底层支撑数据。
CMDB的数据来源分为基础配置和业务配置。基础配置相对是固定的，与运维操作关系不大的，如CPU、内存、硬盘等硬件信息，又如IP归属的机房、分布等地域分布信息，还如设备运营状态、响应级别等运营配置信息。业务配置包含了运维对生产环境操作时，相关的一些业务属性配置信息，可以理解为，包信息（进程端口）、业务、路由、域名等，又如相关的流程、相关的测试用例、相关的决策配置信息等。
一致性监控，负责对生产环境与CMDB中的配置记录进行对比，保障数据库中的配置和生产环境中的现场的一致性，从而确保每次变更都是准确无误的。
● 4.2 织云的工作原理
织云的工作原理由标准化-CMDB-流程系统-生产环境四部分构成。
标准化
腾讯SNG运维对上线服务的程序提出有可运维规范的要求，并以此作为衡量业务标准化程度。首先，我们要理清标准化涉及的对象有哪些。
图4 标准化涉及对象
图4列举有很多不同的对象（未枚举完），以机型举例说明标准化的重要性。我们将不同的设备使用场景划分成为不同机型的使用需求，如CPU计算型，一般用于web、逻辑层，我们就统一用C1支持（配置：CPU8核内存16G硬盘200G），其他的还有内存型设备，存储型设备（ssd、普通硬盘）等。统一设备可减少运维在生产环境的管理对象，降低设备在不同业务之间的复用难度，提高复用率，对企业的运营成本管理，资源的高效利用，都有很重要的意义。
其他不同的标准化对象也是一样的道理。设置标准化的出发点就是为了减少运维对象，降低运维管理生产环境的复杂度，更有利于运维抽象出共性的系统工具来管理这些标准的运维对象。
有了运维管理对象的范围后，便可以设置可运维规范了，如图5所示。
图5 可运维规范
这里规范很多，有流程性的要求，有操作配置的要求，但是所有的规范都要求在生产环境的运维活动中被严格执行（图6），以保证生产环境的标准化。
图6 生产环境的运维活动
运维对象遵循可运维规范，落地到对应的运维工具系统中管理起来，最终被作为CMDB的配置项记录下来，为后续的自动化提供配置信息的支持，如图7所示。
图7 运维对象
CMDB
“模块”是CMDB众多配置项中很重要的一个管理节点。众所周知，不同的角色（开发、测试、运维）对程序的称呼和管理方法都是不一样的。
举个例子。一个程序tnginx部署了100个IP。在开发人员的视角中，这100个IP是一个整体，但是运维对这100个IP还会跟进设备的分布或者支撑不同地域的用户，划分为25个IP支持华北，35个IP支持华东，40个IP支持华南。于是，这100个IP被划分成3个不同的整体，它们的业务量、容量、变更频繁度、机房内网带宽等均有差异。在生产环境管理中，这些都是很重要的考虑要素。我们就以“模块”这个管理节点提升为所有角色都要统一的管理节点，开发、运维、测试、工具系统，都是以节点为操作单位的。
这么做既减少了运维对象（100个IP->3个模块），也能满足对生产环境的运维要求。并且所有的运维标准化都会被收拢到这个管理节点，如图8所示。
图8 模块管理
以模块为统一的管理节点，开发、运维、测试共同维护模块对应的业务资源配置，开发和运维在织云中管理模块依赖的包、配置文件、权限等资源配置，开发和测试可维护模块对应的测试用例、测试工具等。这样的分工都是为了更好的把三种角色间关注的不同维度通过织云平台承载起来，并记录、落地到cmdb中，为后续的流程和工具提供数据支持，为自动化铺垫。
有了CMDB的配置管理数据库，同时还有一份生产环境的真实存在，如何保证配置管理数据库记录的内容能够准确无误的push到生产环境，如何管控生产环境的真实存在与数据库中的记录完全一致，这就是织云平台通过技术化的手段达到的管理目标，如图9所示。
图9 CMDB配置管理数据库
流程系统
流程系统（流程引擎）是所有自动化的驱动器，负责传递自动化操作中依赖的相关参数，负责关联调用自动化操作中相关的工具系统。流程系统的工作原理将工具通过一定的逻辑组装成一个标准化的流程，同样标准化的操作，只需要通过输入不同的执行参数，流程即可交付相同的操作结果，如图10所示。
图10 流程系统
流程配置的步骤：
定义数据类型，用于数据在整个流程中的传递。如IP是一种数据类型、返回码、二维表等又都属于不同的数据类型，具体按流程的场景和工具系统的要求而定。
定义工具配置，通俗讲就是配置工具的内容和用途。如重启进程的工具，工具作者就会开发相应的工具逻辑，如进程名、目录、IP、端口号等参数，工具执行完成，输出结果的执行状态码等其他信息。
流程定义，配置一个流程的开始、过程、结束，依赖的初始化参数、过程中调用工具等信息。
流程系统的架构通过消息队列+worker的模型提升吞吐并发能力，每个worker都会去消息队列中取到单个流程执行，利用monitor对全局的任务进行监控，对每个工具的状态码进行识别，写日志到mysql来将串行的流程变成并行，这样就可以更高效，并发量更大。
图11为一键扩容的实例。用户只需要在织云前台对标准化的模块点击扩容，标准化的扩容流程就会一步步的执行、传递参数，直到流程完成。
图11 自动一键扩容
生产环境
实现流程系统后，就离自动化不远了，整个自动化运维平台只差几个功能模块，便可以实现无人值守智能化，如图12所示。
图12 实现无人值守智能化
决策系统便是这样关键的一个环节，它的作用是识别出标准化的模块需要上线或下线设备，及如何设置最优的判断策略。
我们采用了白名单的形式管理着无人值守的标准化模块，如图13所示，打开织云中的开关控制，容量系统会对白名单的设备进行监控，当识别到一些指标异常时（如CPU、流程等），容量系统就会调用决策系统的接口，触发决策分析。
图13 决策系统
决策分析其实就是一个决策树（checklist）。为了防止一些错误决策，或者一些波动、锯齿影响决策的准确性，我们事先定义好了一棵决策树，检查完对应场景决策树上的检查点，我们便可以相信这个容量异常点是需要触发自动流程来解决的。继而决策系统便会调用对应的流程来完成一系列自动化的运维操作。
有了无人守值的决策系统和自动流程系统后，我们距离设备的自动上线只差一个灰度测试的环节，如图14所示，这个环节我们提供了ATT和QIA两种方式。这两种方法都是腾讯质量部（测试团队）维护的测试系统。
图14 灰度测试
五、 运维自动化经验总结
运维自动化平台的建设可以简单总结为：运维根据运营要求提出标准化的规划，指导业务开发在编码和发布时，按照标准化的模式交付，使生产环境由复杂变得简单，从而让运维能够更好的制定对应的管理系统，最终实现运维操作的全自动化。
我们把实现自动化归结为3大因素，人>流程>工具如图15所示，因为我们坚信只有当devops的思想完全成为开发、测试、运维三者合作的基础，彼此都以最终的用户价值为目标（图16），而摒弃ITIL时代的所谓D/O分离的流程和负担时，我们才有可能进入更优的分工协助时代，也才有可能进入自动化运维的时代。
图15 人>流程>工具
图16 devops
★★ 征稿 ★★
寻找100个年度最具价值的实践案例
我们只要案例干货，拒绝广告
成为特约作者，你将：
◆ 连接100名年度经验与增长值TOP100的研发精英
◆ 提前入围「壹佰案例」年度最优案例榜单
◆ 案例整理成册，出版发行图书
◆ 成为msup客座教练
◆ 以观察员身份受邀出席壹佰案例
◆ 所在公司享有msup活动优惠
有意者联系壹佰案例主编Cynthia