导语：2019年9月6日，GNSEC 全球新一代软件工程高峰论坛，腾讯技术专家、《技术运营标准》核心编写专家 梁定安（大梁）全面、系统地分享了技术运营标准的七大模块及案例。 新版技术运营标准分别以七大技术运营的维度，提供可量化和可评测的运维能力成熟度检查项，供广大企业的运维同仁参考与自评，找准技术运营能力提升的路径。以下是演讲全文。
梁定安
腾讯技术专家
《技术运营标准》核心编写专家
大家下午好，很荣幸能给大家介绍 DevOps 标准的技术运营模块，技术运营总共有七个模块，核心的起草专家有三名，我今天作为代表给大家全面的介绍下，还会有结合案例把标准的内容串起来和大家分享交流。
先简单的自我介绍，我叫大梁，是高效运维社区的老朋友，现在在腾讯云负责售后技术支持工作，大家如果遇到腾讯云的使用或技术问题都可以找我，或者有意愿加入腾讯云的也可以联系我。
今天主要是分四个部分聊一下技术运营模块：
1. 技术运营标准简介
为什么要做这个标准？源自于几个核心起草的专家，都是来自于互联网行业。互联行业没有太多传统的软件工程时代的包袱，从一开始业务架构就朝着分布式来设计，应对着大规模、高并发的服务场景。因此，支撑业务应用的运维平台、技术运营能力也是按这样的思路来设计的。
李克强总理曾经说要以”用电量”衡量中国 GDP 的发展，马化腾先生也提出“用云量”将成未来经济发展重要指标，弦外之音是企业的 IT 规模将越来越大，那么做 IT 支持和运营的同学就会面临着解决大规模的运维技术难题。
在云计算盛行的当下，在开源技术和云能力的加持下，怎么样通过系统平台开源的方案，构建成企业应用的技术运营的方案？将是广大运维人员，也是技术运营标准所关注和希望找到答案的。
介绍下照片中几位参与标准编写的专家们的初心，早在2015年这张照片上的专家们就在起草写互联网应用运维框架，这就是技术运营标准的前身。
随后我们在原框架内容的基础上做了多次的修改，整个 DevOps 标准经历三年三稿，不断有各行业的专家提出建议，标准内容也得到迭代和完善。使它能够被各个企业所应用，并最后有幸在2019年7月份的 DOIS 大会上正式对外发布。
技术运营标准可以分成两大块能力组成，它是企业的软能力和硬技术，今天我会将七大模块按照这两个能力抽象介绍一下。
在编写标准时，参考很多框架和方法论，我们希望技术运营标准的内容能够更接地气，能够给予企业直接的指导和运用场景对标。因此，本标准的内容覆盖很多技术细节点，企业可以对照着完成自评估与制定规划。
同时，也希望中国企业在云计算这波浪潮中，能够将互联网的技术优势发挥好，看能否在技术运营的垂直领域创造一个新高度。这一切都是依赖于我们国内的统一，这也是本标准的价值，借助信通院、行业协会和社区的力量，将中国运维行业的精华融合，形成行业标准规范。
2. 标准的框架与设计思路
下图是 DevOps 标准全局的框架，持续交付已经发布一年多的时间，备受金融科技的企业的拥戴。随着技术运营标准的推广和评审，希望它的影响力能让更多企业受惠。
在设计技术运营的七个模块，我们更看重标准应该从务虚到务实，此前社区对外发布的技术运营简化版，里面写的内容都是可以被实施落地的。
技术运营框架主体的设计思路，因为有腾讯系的作者的缘故，标准的设计参考了很多腾讯内部对技术运营的理解。腾讯对于技术运营岗位的定义，是希望技术运营团队能够给线上的业务做到几个角度的保障。
一是质量，二是效率，三是成本。你会发现在技术运营的框架是围绕这三个角度写的，我们需要质量做的好监控能力要做到什么样；需要什么样的技术实现能够兼顾质量和效率；对于运行态的生产环境的怎样保证高可用等等，都是技术运营核心关心的主题。
监控管理、事件与变更管理、配置管理、容量与成本管理、高可用管理、业务连续性管理，这6大能力项的最终目的是要服务于企业的价值，但企业的用户价值实现与否并未体现，所以有了用户体验管理的第7个能力项。
企业的初心是要为客户提供价值。该标准有1—5级，前期信通院主导的行业问卷调查，国内的技术运营能力现状是1.5级，大家能来参会都是大于1.5级的，可以想像一下低于1.5级的企业有很多。用一句话来概括二级是中等规模的企业，已经有二级的能力帮助它完成很多技术运营的目标和效果。
之前在各大技术峰会上，听到 BAT 的运维实践分享，动不动就是几十万台的服务器的规模，监控流的数据量动辄几P。然而很多企业不需要这么海量的技术能力，马化腾先生天天说要做产业的助推器，做技术运营的标准也是同理。
我们应该换一种姿态，从维护几十万台规模的运维能力中总结经验，再从这些经验中，找到适用于不同规模企业的能力项。
例如，服务器的规模在5000台左右，细看技术运营标准的二级已经可以实现很多高效的运维能力。或者通过技术运营标准的运营，让企业从上到下的达成共同的认知，有个统一的运维能力规划，朝着三级的能力来建设技术运营平台和自动化能力，从被动运维转变成主动运维，将是很大的进步。
在规划技术运营标准时，我们有考虑到技术运营的七个模块不应是相互割裂的。有研发背景的小伙伴，都应该能够很好的理解在 DevOps 标准当中持续交付相对是比较好写的。因为过去已经有很多成型的方法论支持着研发过程管理，有很多理论被总结和整理出来，DevOps 的持续交付可以说是集百家所长的产物。但是在行业里面就技术运营的话题是没有公认的定义。而这次技术运营标准中的七大模块，也是经过专家们反复斟酌讨论出来的。
我用一个例子来介绍下模块与模块之间的关系，大家看配置管理，垂直的纵深是层层递进，从人肉支持到平台化自动化的递进，纵向的能力描述更多的是站在维护对象的全生命周期来叙述的。七大模块间的横向能力，则是在同一生命周期阶段中，相关联的能力描述，如监控二级是对常见的场景进行管理，对该阶段的流程、场景、高可用、容量和成本、用户体验的管理方案。在技术运营标准中，七大模块关联互补，能力层级的递进也是相对平滑的。
技术运营和持续交付中存在着重叠的能力项，为什么？当时考虑到持续交互配置管理能不能包含技术运营的话题，结论肯定是不行的。因为在做软件构建研发的过程，考虑的是软件质量的版本控制，但是在技术运营中，考虑更多的是生产环境维护的质量或变更管理等。同是配置管理，但管理的对象不一样。
3. 标准的“硬”技术与案例解读
介绍完背景的知识，进入到标准中硬的技术部分，包括四个模块，就是监控管理、配置管理、高可用管理、容量与成本管理，里面所描述的所有内容都是具体技术实践。
我给大家举一个例子，在持续交付流程后，技术运营会收到流程传递的配置对象和配置数据，监控可以基于配置数据执行数据采集、处理、应用，看看的数据又可以用作变更管理或容量成本管理的用途。容量的数据将是预算与核算管理的重要数据支撑，同时运营成本的理清，也能更好的支撑我们规划数据高可用的架构能力。
举个实际运用的例子，应用程序发布后，1 有标准运维流程支持完成配置录入。2 监控系统可以根据配置数据库的配置记录，按要求采集对应的应用程序的运用信息到监控系统中。3 监控数据可以组装成基础设施容量和业务容量。同时，4 容量数据可以服务于变更能力，如弹性能力、柔性能力、运行与维护。结合实际运用的容量数据，5 可以确保应用程序的成本合理性，并基于此做预算与核算。
同理，如果要实现进程自愈的自动化运维的能力，只需要在应用程序部署到生产环境后，在配置数据库中，注册上对应的运行IP、进程名称、启动命令等配置信息。监控系统具备在对应的IP上监控对应的进程名称的功能，当进程不存在时，自动化调用该进程的启动命令，既可以实现一连串的自动化运维操作。
通过这个案例，希望大家能够更好的理解四个模块四个模块之间的关联关系，在企业的实际运维工作中，如果能很好的通过流程或平台能力，将四大模块的能力组合使用，将会使企业运维能力上升一个台阶。
为什么如此简单的进程自愈仍要把它能力分级？试想下，如果不走配置对象管理这一步骤，当一个告警说某某IP上的进程不存在时，我们无从求证该IP上是否需要部署该进程，这也是先规划再运营的一个典范。运维的规划不是凭空而来的，而是通过每一次持续交付过程的软件构建发布而来，从软件的发布源头就确保配置的准确性。
监控管理的分级主要是由监控数据流处理的三部分组成：监控采集、数据管理、数据应用。
配置管理能力更多的是考虑到能力阶梯式提升，大部分企业如果没有独立的配置管理系统，最大的配置管理系统就是Excel表格，好一点的可能是在线的表格。其实，当企业IT的规模很小时，未必就需要一个功能很强大的配置管理系统来支持运维工作。
本标准也是朝着这个思路去设计的，一级没有过多的去谈论配置管理平台的规划，更多的是从实现的效果入手，将基础设施对象纳入管理。二级则需要纳管应用软件的生命周期，如软件名称、发布环境、运行状态、进程信息等等。配置管理的能力提升，是取决于我们要解决运维场景的复杂度，是个循序渐进的过程。
在介绍高可用管理时，我想先以招行手机银行的案例介绍产品与技术协同的最佳状态。招行转帐功能操作后，会有6秒钟倒计时，其实在技术上转账并不需要耗费6秒的时间，但是从产品设计上预留的6秒，给予了业务调用的事务流程足够的失败重试时间。确保在用户界面见到的转账功能的成功率是极高的，这个产品功能的设计是很符合 DevOps精神。
在金融强事物型的交易调用链路中，有任何一环出错转帐就会失败，但是产品设计用6秒钟来完成事实上只需要1秒钟的业务流，在最坏的情况下最少可以重试6次，才给用户反馈结果，以此最大化的保障了服务请求的成功率。
这个是特别成功的案例，是产品、开发、测试、运维相亲相爱很好的结果，有一些场景光靠技术的办法解决，往往会需要投入昂贵的成本。因此，企业在构建高可用能力的同时，建议更多考虑 ROI，让成本花在刀刃上。
容量和成本管理也是这样的，一级客观的量化，大家能够通过一些技术的监控，能看到单台机器的容量，若按照硬件的维度聚集的方法聚集，或按照业务维度聚集，看看基础设施CPU是不是平均分布均匀的，能够看到这样的容量数据就 OK 了。
第二级要求能实现关联的计算和场景化的使用。举个场景化容量实用的例子，假设电商平台双十一要做运营活动，这个时候计算业务的容量，它就得关联分析，找到端到端的容量瓶颈点。而到三级的能力，则更多强调主动的管理，应该有更多优化思路被提出和执行。例如，为了一个运用活动是需要提前购买充足的设备容量，还是在技术上实现一个柔性策略扛过峰值即可，都可以根据我们对容量合理性的分析和成本的把控来决策。
4. 标准的“软”能力与案例解读
分享的第四部分是介绍标准中的软能力，这个其实很重要的，因为组织是要靠流程、组织、数据驱动等管理手段将技术能力串起来服务于业务目标的。
举个案例，业务如果要做一个重大活动的保障，首先我们需要定义业务的价值是什么？在元旦零点的微信发朋友圈功能，用户价值是要保障朋友圈消息的发送成功，但在元旦零点的高并发场景，为了扛住上亿用户同时在0:00的流量可能需要扩容10倍的服务器，那在成本合理的方案下，我们会选择适当的扩容，再配合用户排队或者延迟发送的方案。并以此建立完整个机制，确保标准的执行操作和应对异常场景的容灾和应急管控的方案，最终把技术服务的用户体验做到位。
技术运营的第一个介绍模块是用户体验管理，区别于传统行业运维的”封闭”，在互联网行业对用户重视程度特别高，运维也同样，这也是 DevOps 提倡的技术价值。为此，根据互联网企业的实践经验，把用户体验管理这部分的内容独立成一个模块，希望技术运营的能力提升一定是服务于用户价值的。
事件与变更管理核心逻辑是事前、事中、事后应该怎么做，需要有怎样的机制，需要有怎样的流程和仪式感，才能保证每次变更的质量和效率，同时有必要的流程支撑好运维阶段的事件管理。不同的能力分级，分别覆盖平台化、可视化、系统间的信息联动等。
最后就是连续性管理，这里参考了ITIL中对故障测量的 RTO 方法，对业务的影响评估和对风险的分析。运维组织对危机管理和应急管理的必要准备。
为什么有很多企业明明有业务容灾方案，但是偏偏在紧急关头不敢切换？因为，大家对业务容灾切过去是否正常心里没底，不知道切过去等待着大家的是恶魔还是天使。但如果这个容灾切换每天都在做，当真正故障来临需要调度切换时，它就是稀疏平常的事情，自然会执行的干脆迅速。
今天简单的给大家介绍了技术运营的七大模块，引用的一些案例希望能让大家更容易理解标准背后的目的，和更全面的了解 DevOps 技术运营的内容，谢谢大家。
