一人维护一万台服务器的奥秘 --- 梁定安

北哥

梁定安(大梁)

• 硕士
• 10余年互联网运维经验
• 腾讯织云负责人(前腾讯社交类业务运维负责人)
• 腾讯课堂专家讲师
• GOPS金牌讲师
• 复旦大学客座讲师
• 腾讯云布道师

分享的主题是一人运维一万台服务器的奥秘。主要分成三个部分：

1. "令人向往"的运维工作
2. 精挑细选的DevOps运维方法论
3. 自动化运维平台“织云”的实践

首先跟大家捋一下，就是从运维的角度我是怎样看待DevOps的，运维这个岗位为什么如今会面临这么多有可能阻碍IT最大化，阻碍发布效率，让我们每天都疲惫于救火的问题以及是怎么产生的。下面将结合腾讯运维流水线实践来讲解思考这些内容。

一. “令人向往”的运维工作

1.1 运维主要做些什么？

运维主要是做什么呢？别人眼中的运维，运维眼中的运维，老板眼中的运维和现实中的运维。

这是谁眼中的运维？救火，这是我们合作团队的运维，因为每天找不到你，每天不是在开会就是救火，没时间给你说需求。

这是谁眼中的运维？一般是自己觉得自己牛。然后我们在一些场合经常开玩笑说运维有三板斧，什么不行重启，再不行就回滚，要不多喝水试试。

这是谁眼中的运维？老板眼中的，一个老板跟他的运维说，当一切正常的话，老板就会问运维，我要你何用？当故障发生时又会问我要你何用？经常看不到运维的存在，但是一旦出现又是解决不了的问题，向你诉苦就是背锅的时候。

这是真实的运维？网络上有为服务器开光贴符的图片，我觉得很能代表，就经常可能需要去求神保佑，去让我们的一些服务能够健康稳定的运行。这纯粹是娱乐，大家想想，腾讯今年年初到现在股价一直是创新高，基本上每个月都是创新高，如果我们是这样的运维状态是不可能的，企业是没办法放下很多的包袱让业务去狂奔的。

我们的工作是频繁被打断的，人是一个单进程动物，我们同时没办法处理多个事情。如果正在做的事情被打断了，切换回来，就要消耗很多的时间，我们的思考没办法马上回到上一件事情的状态。

1.2 运维的精益思想

老外做了一个分析，当一个人只做一件事情时，效率是100%，火力是全开的。如果同时做两三件的话，时间浪费越来越多，红色矩阵所示。如果同时在超过5件事情，效率是极低的。

无论是精益开发还是日常运维我们都提到一个观点，运维每次做变更操作或者发布操作也好，建议大家一件一件做，如果两个同时操作的话，那带来的后果就如同今年春节的时候Gitlib发生的状况。就是运维人员在测试环境和生产环境多终端切换的时候迷失了自己，不知道终端到底是测试环境还是生产环境，结果敲了一个Delete，把他们的生产环境删除了，虽然公关做得很好，但是还是存在700多家客户的数据丢失。

我们怎样让我们的工作单件流，如果靠人是否能够保证呢？

1.3 对运维工作的反思

日常运维工作为什么会有计划外的任务呢？我们以脉络思考的方法去思考一下，这里我举了四个例子：

• 开发写死IP
• 无变更规范
• 无日志规范
• 无预警手段

开发写死了IP，会把IP地址编译到二进制文件里，原来本来是单机不可用的问题，导致我处理这个故障需要重新做一次编译和完整的事件流。 这本来是一个很简单的事情，如果接入F5或者高可用架构，往往因为这种问题导致我们没办法实现自动化。

如果没有日志规范，出现问题我们又得应对这个问题，去响应去手动查询日志来排除故障。

我们的时间会因为上面所举的案例被切成碎片化，严重导致我们没办法去专注做运维想做的事情。

1.4 产品生命周期与IT价值链

如果把一个产品或者是一个应用的生命周期看作是一个IT的价值链的话，那么这条IT价值链的源头就是我们的产品人员。这跟DevOps2.0的价值流图是很像的，每一个圆圈代表企业当中的角色，产品人员希望有很好的Idea，需要交付到手中，那首先经历规划与设计，然后开发，开发编码实现到测试、再到运维，然后发布到用户手中。

大家可以认为，如果IT的价值链流转速度越快，企业的IT能力是越强的，这也是DevOps经常所强调的一个能力，最直接的度量就是每天发布多少次。

这条链如果在用户使用的过程中发生一些Bug，反馈到我们的客服和运维，如果是新需求或者Bug修复返回到开发，如果是度量验收或者故障处理会到运维。会有很多的子链。

对于运维来说，我们是处于整个IT价值链的最下游。如果IT价值链交付的对象是应用程序，还有我们的一些制品，如果在设计时架构有缺陷，软件有缺陷，是很难要求运维拿到一个有缺陷的很烂的程序，他能够很高效地帮你保障起来，最直接后果就是运维背黑锅。

1.5 传统交付的困局

前面的价值链不断地埋下炸弹，到运维手中就爆炸了，这对运维是伤害，对用户是伤害，对产品也是伤害。那怎样解决这个问题呢？

怎样算传统交付呢？这个产品是部门流的开发，每个阶段就是产品在做规划，测试的时候不为后面的人考虑，在做开发的时候只考虑自己的，这就导致了大家认为中间的红线就是部门墙，企业IT的价值流，价值流转不顺畅，最终带来了运维团队拿到一堆无法维护的对象，有菱形、三角形、正方形，这些都是不一样的，又需要分配给不同的运维角色，彼此之间又是没办法整合成一体的，全局地去规划，就带来了很多的问题，那就是背黑锅。

1.6 Dev与Ops的冲突之源

我们最终的目标不是去相互互撕，而是给公司带来最终的价值，其实就是要让我们的IT价值链流转更快。基于传统的交付模式，开发和运维就有了冲突的来源了，因为往往由于项目的压力，开发可以延期，测试时期可以再压缩一点，运维交付测试上线的时间又可以压缩一点。

在2015年上半年DevOps报告当中，访谈了1000多家硅谷的公司，他们发现所有的公司的运维团队都面临同样的一个问题，那就是他们百分之六十多、七十的故障都源自于运维变更。换句话可以这样理解，如果我的生产环境不变，发生故障的机率是很低的，所以屁股决定脑袋，对于运维团队而言，如果对它的考核是不发生故障，这是很悲伤的。我曾经听过金融行业一个很有意思的分享，就是他们运维团队的考核，起分是0分，然后就是负分，但是满分就是0分。
在腾讯不是这样的，运维可以做很多的事情帮自己加分。首先这是文化的差异，我们的企业是不是有拥抱变化，让我们的IT能力不断提高，是否有这样的沃土，帮助我们提高。但是我相信DevOps在国内的影响越来越大，很多传统的企业他们的老板、CIO、CTO都意识到了这一点，关键是靠大家把落地的方法带回去。

那对于开发人员而言，他要实现他自己的角色，对企业的一个价值，其实就是要把功能实现了。那功能实现就是代码写完了，最终还是要发布的，所以开发人员先天对我们实现它个人的岗位价值，它就是需要不断地发布和变化，那对于运维呢？它就是不断地不给变，如果我们的IT能力不够，我们要保证好生产质量，这就形成了一个对抗，就是我们经常而言的Dev和OPS的冲突。

冲突最直接带来的后果是什么呢？就是我们上了一套Itool流程。为什么要上这套流程呢？因为Itool强调一点，我不关心你的企业这么做是不是最好的，是不是最快的，要不要这些都不重要，重要的是我Itool给你的是，你做同样的，如Requst Change，你按照我给你的这十步做完是最稳定和安全的。因此当Dev和Ops没有找到好的方案时，就倾向于选择Itool。因为Itool在彼此都能接受的情况下，能够保证IT的活动。这直接带来的一个后果就是一刀切，什么事情都走流程，离线的流程跟在线的操作流程衔接不起来，最直接的结果就是IT的效率很低，什么东西都提一个流程。

在2008年的时候，有大半年是引入了Itool，我们当时定了很好的流程，一个需求多久给我做完。在牧场最火的时候，当一个用户凌晨3：00起来偷菜偷不到，他的内心很沮丧的，一沮丧就会投诉。我们内部定义的影响范围就是影响用户的数量。我记得有200个用户投诉就是很高事件了，就是二级的重大事件，马化腾先生都会收到告警。2008年玩农牧场的时候是接近上亿的用户状态，200个用户分分钟都会产生。这直接导致的后果对开发来说，当发生这样的问题，你不要跟我说什么流程不流程，全是紧急需求。

你就会发现漫谈流程的全部设置都不攻而破了，后来这个流程就被下掉了。 换成了运维开发工具形式，自己使用和变更。当时是基于这样合作和业务的大背景走到了那样的状态。

二. 精挑细选的DevOps运维方法论

2.1 为什么是DevOps？

为什么运维处于这样艰苦的大背景，DevOps有哪些方法论可以为我们所用，让我们参考地做这样一个运维的规划。

在当下整个商业市场都充满着不确定的情况下，让越来越多传统行业去意识到很现实的一个问题，其实不是说我们的IT能力以前被很多企业定性成一个成本中心，我只要养着它，它保证我的质量不出问题就可以了，但是现在不是的。

以金融行业来说，现在越来越多的互联网金融企业的诞生，传统的金融就像四大行，股份制银行，这样的传统企业要跟新型的互联网公司竞争，互联网金融的产品很活，每天都在变化，你看他们的理财产品，每天都有不同。那传统的呢，它不是不想变，它的业务已经意识到这一点，要推出业务和另外一家抗衡，但是不好意思，因为IT能力太弱了，没办法把我预想的很好的点子发布出去。按照以前的发布周期要一个月发布出去，这时候黄花菜都凉了，很多用户就不断地流失了。所以IT慢慢地从一种支撑的团队变成一种企业和企业之间竞争的优势，这也是为什么很多的行业要跟互联网企业学习。互联网企业先天就把IT当成它的一个竞争优势。腾讯内部70%的都是IT，都是技术人员。

2.2 DevOps的CALMS文化精髓

• Culture(文化) - 是指拥抱变革，促进协作和沟通
• Automation(自动化) - 是指将人为干预的环节从价值链中消除
• Lean(精益) - 是指通过使用精益原则促使高频率循环周期
• Metrics(指标) - 是指衡量每一个环节，并通过数据来改进循环周期
• Sharing(分享) - 是指与他人开放分享成功与失败的经验，并在错误中不 断学习改进

DevOps提倡了几点，就是包括它的文化，指导团队协作的一些精益理论，怎样度量，持续改善的一些指标，还有强调团队与团队之间要分享知识、职责等。

2.3 DevOps持续交付原则

• 为软件的发布创建一个可重复且可靠的过程
• 将几乎所有事情自动化
• 把所有的东西都纳入版本控制
• 提前并频繁地做让你感到痛苦的事情
• 内建质量
• "DONE"意味着"已发布"
• 交付过程是每个成员的责任
• 持续改进

DevOps给我们最重要的一个触发就是在自动化这块给了我们一个很好的实践，就是持续交付，让我们怎样加速IT的价值链。

在持续交付中，有八大原则。《持续交付》这本书我读完触发很大的，因为以前我们在构建企业运维整个体系时，并没有高大上的理论指导，我们更多地是从原生的方法论，或者是原生的需求痛点提出的方法论，然后将它变成我们的工具化，但是当我读到这一本书，读到这八大原则时，我发现它就是把过去的事情总结出来了。

我们一起来看一下，为软件的发布创建一个可靠可重复的过程，大家细细品味一下，要能实现可重复，你必须要有一个体系和标准，你要有一个标准才能可靠的重复去做的。

在持续集成的阶段，我们很多测试的动作能否自动化，在做运维发布部署的时候，能不能把很多的事情都朝自动化做，所有的东西都纳入版本控制，你要度量必须描述它，要描述它必须把对象产品化。大家细细品味一下，我们每发布一个对象，一个软件或者一个制品，开发是怎样提供给我们的，他是丢了一个压缩包过来，有没有版本，有版本，但是没有日期。这个日期编号是代表一个全量的产品库，还是增量的，有时候给全量，有时候增量，有时候是压缩包的文件等这一系列的方法，都决定了你后面能否用可靠可重复的方法解决它。让你频繁看到痛苦的事情，首先你得量化频繁痛苦的事情是什么，然后才可以标准化、自动化。

内建质量四个字包括的事情非常多，包括八个“率”，成功率、复制率等。运维的阶段代表着你的进程挂了能不能发现，硬盘空间满了能不能发现。还有后三点，指我们团队协作时有可能遇到的文化问题。

我把刚才提到的一些点，用我个人的理解做了阐述，这些阐述里面包含了开发和测试的决策，应该怎样理解这八个环节。我们是做运维的，更多的是从运维的角度。我们的工作都可以按照8个原则来指导，来自动地实现运维计划外的业务变成计划内，然后把它自动化。

三. 自动化运维平台“织云”的实践

3.1 腾讯织云简介

我们都是把业务对象精捡出来，每个业务做运维操作和活动时，它有可能涉及的对象就是我们的包、配置文件、脚本、或者是我们的镜像和容器。

抽象出来怎样管理呢？抽象出来标准化以后，通过我们的自动化。细细的想一想，我们的日常运维工作就是对不同运维对象的变化，如果要修改一个配置，我可能就是操作我的配置文件，如果我要做一个发布，可能这里面涉及的运维对象，既有二进制文件又有配置文件，或者就是一个镜像。这取决于我们企业所要从事业务活动时，需要通过哪些原子的去组成，这时候自动化你可以认为是一堆工具的编排，解决这一点以后，我们就可以尝试着去让工具帮助我们做更多的事情。

然后就是智能化，怎样尽量地让运维人员更少地去干预、决策，就像我们的设备通电能否自动地给我们的CMDB注册一下，当我们的服务容量很高的时候，怎样利用虚拟化的能力去动态伸缩，当我们的进程不存在了，怎样自动地帮我们去修复，这就是我们做腾讯织云平台的一个初衷。

3.2 如果定义标准化

在一个产品、软件的生命周期中我们怎样定义它的标准化呢？这是腾讯的一个经验，我们把产品的技术生命周期分成四个不同的阶段，这四个阶段分别是开发前、上线前、上线中、运营中。

大家回想一下第一个部分的企业IT价值链图，企业IT价值链经历了从产品设计到编码，在这个阶段运维其实还没有参与整个的事情，但是在这个阶段不同的角色做出的任何一个决策都有可能给运维埋下一个定时炸弹，那为什么我们不能把运维的一些规则去前置呢？这时候在开发前我们强调了非功能的规划和技术架构的选型，同样是一个Web的服务，可能不同的开发团队他的选择不一样，有的用Apache，有的用其它的。再一个技术很强的团队，他们都认为自己写的是最好的，都要自己实现。自己实现带来的是什么呢？就是很多的对象，本来大家是一个nginx，就是一套。比如说监控是埋点实现还是日志实现，上线前需要度量它，就是一些准则和标准化是否落地，这里就概括成运维标准化的规范，对应开来就是很细的检查点。跟很多同事交流过，每家企业都有自己的运维标准化，但是很遗憾大多数是停留于纸面，而没有办法去承载它。

腾讯是怎样的呢？我们是用一些工具去承载。我们不仅仅是解决了要求还提供了解决方案，人的思考和前瞻性是有局限的，没办法一步到位地设计好全部的东西，在未来十几、二十年和几百年都不用改变，因此我们要有持续改进的过程。

在腾讯我们通过质量体系，通过每次故障去做故障复盘的时候，会把我们的理念不断地提升为前置规范，不断地落地从而形成这样一个闭环，来保证所有的业务的架构不断地迭代，还有运维能力，能够不断地得到提高。

3.3 运维对象标准化

我们再来看一下，理清楚了标准化怎么做，有哪些环节可以做标准化。在腾讯我们是按事业群的机制，有专门负责机房规划的，有专门负责系统的，有专门负责DBA的，有专门负责应用运维的，组件运维。每一个角色或者是每一个软件的层级，我们要考虑的运维对象都是不一样的。对于运维来说，其实有一个方法论是通用的，是要尽量减少有可能涉及到的运维对象，每一个层级。举个例子，在系统资源层，能否针对所有的机器，都用统一的一个内核。如果要打补丁，负责内容管理的同学，就可以基于它的需求去做一个很好分案工具也好系统也罢去修复它，一旦实现了他的效率，他就可以去想的更多。比如如何应对内核多样化的发展，他可以设计成配置化，一点点地把能力加强，直到后面我任何应用上线都不需要考虑这一点。

理清我们要纳管的运维对象，减少这个运维对象后，我们要有很直接的问题就是怎样描述它。大家听了很多运维自动化的分享，都提到一个核心的功能模块，就是配置管理。在腾讯我们把配置管理分两层，一个是基础资源层，一个是应用资源层。这两层都有数据发现的，有一些是靠人工维护的。为什么呢？以基础资源层举例，新服务器上架，通电后自动找到它的Master，会把它的IP注册进来。然后我们都是有一个默认的密码，这时一个新IP进来就会下发命令进去，把它的状态全部改成我们所要的状态。但是有一部分的信息是没办法获取的。比如说这个机器的负责人是谁，上面要跑哪些应用程序，运营状态是运行中还是隔离中，是属于生产环境还是测试环境，这些是需要人去规划落实的。

3.4 自动化之始CMDB

这是我们的CMDB系统。

3.5 统一应用管理节点

我们提出了一个标准的硬件节点的管理方法，就是我们提出了一个模块它作为管理节点。在腾讯模块代表的是同一种功能服务的集群，就是它背后是一堆IP，这堆IP会记录什么信息呢？包括它资产配置，硬件配置，运营配置和分配配置，淡黄色这部分信息。这有什么用处呢？进入了分配信息，有一个关联机故障了，我马上反馈出它上下链假设有一千个IP，那我可以做告警的收敛。一个核心交换机故障了，就会有一些Agent超时报警甚至是更严重的报警。基于这样的配置，可以在我告警的模块里多加一层二层收敛，查它们有没有共同的事情。其实很多自动化的逻辑和工作都是基于我们一定的配置去实现的。还有下面一些应用的信息，就是资源的信息。资源的信息代表什么呢？就是我部署的模块，它的镜像是什么，包是什么，配置文件是什么，先把它规划好，再会有我们的部署。

大家可以想像一下，其实模块提供单一功能的集群和服务。如果我有一个服务，为了就近接入我要部署在10个地方，为我的用户提供服务。站在运维的角度，要部署在10个地方，按照这套管理理念来说是相当于10个模块，为什么呢？因为10个地方的用户量不一样，10个地方硬件的基础设施的环境不一样，直接导致的后果是容量不一样，产生故障的机率不一样，运维必须基于此去规划我们的一些工作。

这里以运维的视角去管理生产环境我觉得没关系，但是开发人员是怎样看待我们的生产环境呢？对他来说，10个地方的分布应用程序都是同一套代码和制品。在这个基础上我们提出包的管理节点，就是经过持续集成产生的库，就是二进制文件，我们认为是一个包。

在腾讯，在运维系统会把制品全量地存一份，存一份是为了让我们更好地做发布和回滚。在生产环境跑的每一个版本我们运维都有。持续集成打成了一个Docker镜像，在运维有一个全量的仓库存起来。我们一直用这种方法管理起来了。在制品库上针对不同的技术栈，是Java是其它的，它的管理是什么样的，框架是什么样的，配置文件在哪里，日志文件写在哪里，针对这些做了标准化规范。以此来实现一键的发布、安装、启动、停止。然后以此来做我们的一些自监控、自清理、防篡改等能力。

3.6 可重复的运维操作

我们的运维思想就是把一些可以重复的操作，都把它标准化、自动化。

哪些操作是重复的呢？每家公司运维面临的重复都不一样，但是有一点是重点，运维的操作都会把某些对象、资源，无论是包还是镜像是要传输到目标机器，然后执行。无论是还原目录结构，还是安装和卸载它。这一点就是Docker给我们抽象出来的。对于腾讯也是这样的，这是我们的资源，就是一个容器。但是我们会把资源里面的每一个细节都给列出来，然后将它传输，无论是用SSH还是用SC架构传输的方案都可以，原理就是将它传输到我们的分布式设备上，然后执行它，无论做自动化的部署、测试、灰度还是上线的动作，它都是执行。无非就是你本地的执行还是远程调用接口的执行。

3.7 抽象运维操作并自动化

理清楚了可重复的运维操作后，我们再来看日常的运维工作中有哪些操作是可以被抽象出来朝自动化去做的。我这里没有完全地拿腾讯的技术来讲，因为都是自研的，没有开源的方案所以意义不大。

假设我们做设备上架的操作，首先机器通电了检查连通性，然后将密码入库随机化，入库以后做什么就自己定义，本来是固定的密码。然后权限回收，参数初始化，然后应该改什么Agent这都自动化去做。这些操作被不同的流程所覆用，被不同的工作所重复，然后改运营状态最后划入Buff池。放Buff池有一个好处，要去用Buff池的时候，你就可以调它去得到所要操作的对象。这样就可以根据Buff池的频次去执行你的资产，应该囤多少冗余的量，帮助你做好运营环境的管理。

这个过程就是一个圆圈，圆圈表达的是完全自动化的工具，黄色的矩形是人决定怎样走的过程，这样就会让我们的运营工作逐步逐步地朝着一件化或者是效率很高地去做。

3.8 传承经验的变更管理

我是站在运维的角度，没有太多讲持续集成的阶段，对于持续集成来说，只要制品库是按照运维的要求提交，这一串的能力都可以获取。这套能力不仅仅解决的是持续交付的问题，还解决了你日常维护的问题。这样我们就可以将我们的运维经验传承下来。

大家可以看到，CMDB记录了很多我们要去发布管理的无论是镜像也好，配置也好、包也好，都是按照事物的角度去定义的，然后按照标准的操作，将它可靠和可重复地推到我们的环境，都是基于我们的标准化，传输的时候可以做用户权限的管理，你操作这10台的机器，我是QQ业务的负责人我可以操作它，把这个权限同样给到开发和测试人员。然后生产环境得到的运维对象，它的表现、版本是什么，可不可以描述它，它的版本型号是否跟我们CMDB一致，就是在线和离线的对比，通过一次性对比的方案，一次性对比是另外一套CS的架构。根据不同活动的体检、审计、统计、监控报警，让我们做很多自动化的事情，并且这些自动化的事情所依赖的人的经验都被我们的系统所承载。

3.9 智能给自动化加点料

这里是一个自动扩容的案例。基于我们的容量系统，容量决策树并没有多高大上，就是经验的沉淀。

3.10 自动触发部署流程

容量扩容，需要经过上面决策树。通过容量管理的接口，这部分的数据我们可以获取，能获取得到就可以获取自动化的流程，就可以自动化了。如果需要自动地触发一个流程，是做了这样的6步，申请设备、获取资源、发布部署、发布自检、业务测试和灰度上线。

如果将每一个操作原子化，腾讯是对应了23个不同的操作，为什么对应不同的操作呢？每一个原子的运维工具，执行的接口的调用都可以被不同的业务活动所复用，根据后台各种适合我们开展活动流程引擎的编排能力，把我们计划外的东西朝这方面去靠，慢慢地把人解放出来，更多地是去做工具的建设。

3.11 进程自愈

怎么怎样做进程的自愈管理呢？这里是有一个流程，当我们做自动化安装，部署一个软件包，部署完后的一个流程安排，要上报这个包的状态，会注册到我们CMDB里面，让这个模块和软件包与进程名有一个映射关系，这个映射关系会生成基础监控的监控文件，下发到一个主机。每个机器上运行的进程是什么，每分钟PS我们的进程，假如它不存在了，如果进程上面勾了要恢复的，就会自动地找到我们的启动脚本和程序将它拉起来。如果异常就发给告警平台，还是基于一条自动化操作的日志去通知一下就可以了。每一个流程都要把运维体系所主张的东西串联起来，让我们的状态信息在CMDB里面是最精准地被记录和承载。

3.12 硬盘自动清理

再智能一点就是自动清理。《网络安全法》规定不能随意清日志，不能违反。在腾讯，日志是符合规范的话会自动清理。日志清理的规则又可以和业务关联，如果我一个程序部署了10个模块，每个模块10台机器，那就100台机器，只要1台机器产生硬盘告警，然后它会生成一条清理策略，这个清理策略被部署下去，那就是10个模块100个机器都会接受到这个策略。100台机器只要一台产生了告警，后面的99台得到了这条清理策略就都不会出现这样的告警。这样做就是希望将我们非计划内的工作变成计划内的工作。

3.13 自动化调度实战案例

最后以一个真实的案例来结束。我在社区发的8亿次军装照背后的运维技术的故事文章，就是用了这样的技术。我们的流量，因为我们是来自于腾讯的社交业务，社交业务UGC内容比较多，你时不时的就不知道为什么流量上来了，可能就是一个热点事件。如5201314大家就开始发红包，发微黄金。我们要有这样的能力来做自动化的决策。这个是用了流量指标，军装照也是用了流量，我们会收到短信，微信的提醒，其实就是7×24小时的自动化的一些案例。它无非就是对应了我这个决策以什么指标去调度哪个流程去自动化完成，最终走上人生的巅峰。以此去把我们所主张的运维的规范给落地实现它。