解密腾讯SNG云运维平台“织云”

InfoQ：织云定位为内部的自动化运维平台，那么它具备那些特征呢?

梁定安：织云平台定义了SNG业务的标准化运营规范，在平台中运维人员抽象出上层的管理节点，减少与统一运维对象，降低海量运维的复杂度，得益于运营环境的标准化建设，有更多通用的自动化工具被设计开发，配合流程引擎的驱动，使我们逐步迈入自动化的运维阶段。平台最大的特色是“一键上云”帮助SNG自研业务快速实现织云最初的上云目标；而“自动调度”则实现标准化服务的容量自动维护；还有我们基于内核inotify的一致性监控，保证了配置资源与现网资源的一致性。此外，织云的核心模块还有：资源管理，包管理，配置管理，自动流程，中心文件源，权限中心，都是自动化运维必不可缺的重要功能模块之一。

InfoQ：“一键上云”实现没有那么容易吧？非标准化业务应该是很难接入，在实现这一目标时，你们又遇到那些难题？

梁定安：困难是必然存在的，我们第一个遇到的难题是虚拟化选型和适配改造，在XEN和LXC之间，我们选择更轻量成本更低的LXC作为织云平台的虚拟机，在运营过程中，由于虚拟机与实体机管理模式的差异，我们没少踩坑。如同母机下子机对CPU、网卡流量抢占造成相互影响，子机多crontab集中调度，常用系统命令只显示母机状态，LXC内网NAT管理改变原运维习惯等等问题，都被一一啃下，LXC顺利本土化成功。

第二个难题是运维标准化的普及，像QQ秀、会员这类腾讯比较早期的业务，在当时没有标准化规范的背景下，现网的运维管理有诸多阻碍顺利上云的问题点，如程序混布、hardcode IP地址、依赖非标准库等等，在接入织云前都要经过运维和开发的适配改造。为了顺利推动让业务开发配合运维做上云的改造，我们设计了织云的“自动调度”、“一致性监控”、“权限中心”等核心功能，让开发改造的工作量有了充足的利好回报，让旧业务标准化的改造如期完成。我们乐观的看到织云平台使SNG运维从D/O分离转型为DevOps模式。在织云平台中，没有运维和开发的严格区分，平台的用户会在既定的标准管理框架中，对统一管理对象——模块，进行录入或变更资源配置（包、配置文件、权限、目录、脚本），流程引擎则会按照既定的次序和调用不同的自动工具，完成用户的一键上云或其他变更需求，而这一切都会在织云的标准化体系保障中自动化的实现。

一键上云的成功，得益于SNG自研业务的标准化运维管理的良好基础，我们所有程序的包管理（pkg包系统）、配置文件svn管理（CC系统）、目录管理（中心文件源）、权限管理（标准api）、名字服务（L5）的高覆盖率，都可以经过轻量的改造即可成为织云平台的功能之一。再辅以流程引擎，将上云的步骤串成自动化的流程。用户只需在织云平台上管理好模块与依赖资源的关系，织云便可以一键式的完成整个迁云的过程。

InfoQ：织云的自动调度是实现业务动态扩缩容？你们又是如何控制“雪崩”的？面对业务的大量突发，是全自动，还是人工干预？

梁定安：是的，我们认为当一个模块可以灵活的实现扩容自动化时，它便具备了跨IDC/城市迁移的调度能力。同理，我们对运维的业务按核心功能的不同分别抽象成不同类型的SET/服务视图（包含多个模块），当整个SET的标准化程度且SET内的模块都具备自动调度的基础能力时，我们便可以对整个SET进行调度操，目前Qzone、说说、广点通等重点业务的SET已经具备快速调度能力。

雪崩的预防是负载均衡管理中必须解决的一个问题，在SNG我们拥有一款十分出色的负载均衡+容错组件L5，L5利用名字服务将一个集群标识成一个L5ID，主调方可以通过嵌入L5api并调用get_route来获取被调L5ID中的每个IP：port，然后当请求结束后update_route来更新该L5ID的每个IP:port的成功与延时信息，L5组件便可以通过全局数据的整合，在下个调用时间片动态的为L5ID下的每个IP分配合适的请求量，利用这个原理，L5根据实际每个被调IP:port的请求量、成功率和延时的波动数据，可以计算出每个IP：port最大可支持的请求量，当遇到业务请求量陡增的场景，L5会启动过载保护，在保证被调方饱和的请求量前提下，对新到的请求全部拒绝服务，以防止雪崩的发生。这些都是由L5组件全自动实现的。

织云的自动调度原理是对服务/模块的容量指标（CPU/流量）进行监控，当触发扩容阀值时，织云后台便自动触发部署、测试、灰度、上线这一系列的全自动流程，保证线上服务容量的可用，除非耗尽可用设备buff，否则织云的自动调度功能辅以L5的优秀容错能力，可保持业务容量处于高可用的水平。

InfoQ：一致性应该是多个方面的，包括上面有提到一致性监控，还有织云的另一大特色服务一致性管理，这里的关系与具体包含的内容都有那些？

梁定安：先介绍下一致性本身，这是一套C/S的监控程序，C利用内核inotify订阅监控的对象，并通过动态上报的架构，在一个集群内选取一个leader汇总数据后，传输到S进行数据落地，实测性能可达监控1000个文件秒级感知，是我们实现织云前台实时监控现网环境的核心手段。

回到一致性管理，视乎场景的不同，具体可以分为两大类：资源的一致性和服务的一致性。资源的一致性，比较容易理解，织云自动调度中依赖的资源，包括：包（进程、版本、运行状态）、配置文件（md5）、目录（md5）、权限、后置脚本（md5）。通过一致性的管理，使织云能够在无人职守的前提下，自动的变更运营环境。 服务的一致性则与SNG业务的形态耦合比较重，如Qzone的多地容灾分布，每地的服务彼此一致，主要也是利用一致性的监控管理，服务一致性管理的会比资源一致性管理纬度要粗，往往只包含多个模块的包、通用目录、权限这3类。

InfoQ：织云的核心模块有：资源管理，包管理，配置管理，自动流程，一致性监控，中心文件源。对于开发团队而言，在织云做这些操作，和不使用织云有什么区别？ 大体的操作流程是什么样子的？

梁定安：织云提供给开发和运维团队的是工作效率的提升，让我逐一为大家介绍这些核心模块的功能。

资源管理，我们对现网操作的最小管理对象——模块，部署上线所依赖的所有资源，和操作这些资源的先后次序，都将录入到织云的资源配置，并存入模块的CMDB配置管理数据库，成为该模块必不可少的属性之一，结合自动流程可实现多种自动化的操作。原则上模块的资源配置只能由少数模块负责人修改，并且当资源发生变更时，织云提供锁表的能力，防止交叉篡改。没有织云的资源管理，运维/开发只能依赖wiki、文档等古老的方式记录，并且无法自动化。 包管理，是SNG一个最基础的系统，运维要求每个上线运营的程序，都必须按照SNG包管理规范打包，包管理本身提供了一套完整的框架，包括：进程名字与端口管理，启停方式统一管理，标准化的目录结构，完善的进程监控体系，灵活升级回滚的svn管理等等。包管理是一切标准化的基础，离开它，运营环境将一片狼藉。

配置管理，指的是配置文件管理，包括线上编辑、版本迭代、diff、前后置脚本、批量下发/回滚等等功能，是单文件管理的利器。没有它的话，就只能回到脚本发布时代了。

自动流程，指的是织云的流程引擎，主要功能是将不同的标准化工具串联起来，前者的输出可作为后续工具输入用途，支持流程分支汇总的能力，可通过串联不同的工具，拼装出不同的自动化流程，实现无人职守的各种操作。这就是人肉和自动化的差别。

一致性监控，主要就是秒级感知现网变化的能力。有了它，开发再也不会提让运维批量查一批IP的配置是否一致的需求了。

中心文件源，主要是为目录管理诞生的一套svn管理的系统，可根据策略不同，自动与现网同步或被同步，且支持大批量的分发能力。没有它，大伙还是只能靠脚本来进行目录类的发布管理，效率低下。

InfoQ：在织云上的业务部署监控、日志收集是如何实现的？而运维“织云”这个平台运维工程师又是如何保证平台的稳定性？

梁定安：托管于织云上的业务使用的是SNG内部统一的上报通道，将监控数据和日志上报到监控平台的storm集群中，监控数据处理集群利用mongoDB、rabbitMQ和Infobright对大量的流数据进行处理，最终产生监控告警或报表。织云负责提升运维效率，统一监控平台则负责提供监控告警管理。

织云平台本身的可用性，也是严格按照SNG可运营规范要求设计的。值得一提的是，织云为了保证具备自动调度能力的模块在关键时刻的可用性，我们特别设计了演习功能，每天都随机抽取演习，随时检验平台核心能力的可靠。