梁定安

腾讯技术专家

《技术运营标准》核心编写专家

大家下午好，很荣幸能给大家介绍 DevOps 标准的技术运营模块，技术运营总共有七个模块，核心的起草专家有三名，我今天作为代表给大家全面的介绍下，还会有结合案例把标准的内容串起来和大家分享交流。

先简单的自我介绍，我叫大梁，是高效运维社区的老朋友，现在在腾讯云负责售后技术支持工作，大家如果遇到腾讯云的使用或技术问题都可以找我，或者有意愿加入腾讯云的也可以联系我。

为什么要做这个标准？源自于几个核心起草的专家，都是来自于互联网行业。互联行业没有太多传统的软件工程时代的包袱，从一开始业务架构就朝着分布式来设计，应对着大规模、高并发的服务场景。因此，支撑业务应用的运维平台、技术运营能力也是按这样的思路来设计的。

李克强总理曾经说要以”用电量”衡量中国 GDP 的发展，马化腾先生也提出“用云量”将成未来经济发展重要指标，弦外之音是企业的 IT 规模将越来越大，那么做 IT 支持和运营的同学就会面临着解决大规模的运维技术难题。

技术运营框架主体的设计思路，因为有腾讯系的作者的缘故，标准的设计参考了很多腾讯内部对技术运营的理解。腾讯对于技术运营岗位的定义，是希望技术运营团队能够给线上的业务做到几个角度的保障。

监控管理、事件与变更管理、配置管理、容量与成本管理、高可用管理、业务连续性管理，这6大能力项的最终目的是要服务于企业的价值，但企业的用户价值实现与否并未体现，所以有了用户体验管理的第7个能力项。

企业的初心是要为客户提供价值。该标准有1—5级，前期信通院主导的行业问卷调查，国内的技术运营能力现状是1.5级，大家能来参会都是大于1.5级的，可以想像一下低于1.5级的企业有很多。用一句话来概括二级是中等规模的企业，已经有二级的能力帮助它完成很多技术运营的目标和效果。

之前在各大技术峰会上，听到 BAT 的运维实践分享，动不动就是几十万台的服务器的规模，监控流的数据量动辄几P。然而很多企业不需要这么海量的技术能力，马化腾先生天天说要做产业的助推器，做技术运营的标准也是同理。

我们应该换一种姿态，从维护几十万台规模的运维能力中总结经验，再从这些经验中，找到适用于不同规模企业的能力项。

在规划技术运营标准时，我们有考虑到技术运营的七个模块不应是相互割裂的。有研发背景的小伙伴，都应该能够很好的理解在 DevOps 标准当中持续交付相对是比较好写的。因为过去已经有很多成型的方法论支持着研发过程管理，有很多理论被总结和整理出来，DevOps 的持续交付可以说是集百家所长的产物。但是在行业里面就技术运营的话题是没有公认的定义。而这次技术运营标准中的七大模块，也是经过专家们反复斟酌讨论出来的。

我用一个例子来介绍下模块与模块之间的关系，大家看配置管理，垂直的纵深是层层递进，从人肉支持到平台化自动化的递进，纵向的能力描述更多的是站在维护对象的全生命周期来叙述的。七大模块间的横向能力，则是在同一生命周期阶段中，相关联的能力描述，如监控二级是对常见的场景进行管理，对该阶段的流程、场景、高可用、容量和成本、用户体验的管理方案。在技术运营标准中，七大模块关联互补，能力层级的递进也是相对平滑的。

技术运营和持续交付中存在着重叠的能力项，为什么？当时考虑到持续交互配置管理能不能包含技术运营的话题，结论肯定是不行的。因为在做软件构建研发的过程，考虑的是软件质量的版本控制，但是在技术运营中，考虑更多的是生产环境维护的质量或变更管理等。同是配置管理，但管理的对象不一样。

我给大家举一个例子，在持续交付流程后，技术运营会收到流程传递的配置对象和配置数据，监控可以基于配置数据执行数据采集、处理、应用，看看的数据又可以用作变更管理或容量成本管理的用途。容量的数据将是预算与核算管理的重要数据支撑，同时运营成本的理清，也能更好的支撑我们规划数据高可用的架构能力。

举个实际运用的例子，应用程序发布后，1 有标准运维流程支持完成配置录入。2 监控系统可以根据配置数据库的配置记录，按要求采集对应的应用程序的运用信息到监控系统中。3 监控数据可以组装成基础设施容量和业务容量。同时，4 容量数据可以服务于变更能力，如弹性能力、柔性能力、运行与维护。结合实际运用的容量数据，5 可以确保应用程序的成本合理性，并基于此做预算与核算。

同理，如果要实现进程自愈的自动化运维的能力，只需要在应用程序部署到生产环境后，在配置数据库中，注册上对应的运行IP、进程名称、启动命令等配置信息。监控系统具备在对应的IP上监控对应的进程名称的功能，当进程不存在时，自动化调用该进程的启动命令，既可以实现一连串的自动化运维操作。

配置管理能力更多的是考虑到能力阶梯式提升，大部分企业如果没有独立的配置管理系统，最大的配置管理系统就是Excel表格，好一点的可能是在线的表格。其实，当企业IT的规模很小时，未必就需要一个功能很强大的配置管理系统来支持运维工作。

在介绍高可用管理时，我想先以招行手机银行的案例介绍产品与技术协同的最佳状态。招行转帐功能操作后，会有6秒钟倒计时，其实在技术上转账并不需要耗费6秒的时间，但是从产品设计上预留的6秒，给予了业务调用的事务流程足够的失败重试时间。确保在用户界面见到的转账功能的成功率是极高的，这个产品功能的设计是很符合 DevOps精神。

在金融强事物型的交易调用链路中，有任何一环出错转帐就会失败，但是产品设计用6秒钟来完成事实上只需要1秒钟的业务流，在最坏的情况下最少可以重试6次，才给用户反馈结果，以此最大化的保障了服务请求的成功率。

容量和成本管理也是这样的，一级客观的量化，大家能够通过一些技术的监控，能看到单台机器的容量，若按照硬件的维度聚集的方法聚集，或按照业务维度聚集，看看基础设施CPU是不是平均分布均匀的，能够看到这样的容量数据就 OK 了。

最后就是连续性管理，这里参考了ITIL中对故障测量的 RTO 方法，对业务的影响评估和对风险的分析。运维组织对危机管理和应急管理的必要准备。

今天简单的给大家介绍了技术运营的七大模块，引用的一些案例希望能让大家更容易理解标准背后的目的，和更全面的了解 DevOps 技术运营的内容，谢谢大家。