如烹小虾： 运维自动化闭环，腾讯是这样作的

本文是数人云深圳技术分享课上优维科技联合创始人彭鲤航的演讲实录，演讲主题是《运维自动化实践》。

精彩观点抢鲜看

实现运维自动化闭环，最主要就是配置管理、状态管理和变动管理能力。

治大国如烹小虾，咱们来类比餐厅老板，看如何实现炒菜的自动化：

• 首先，我要知道个人厨房里到底有些什么东西是可用的，好比备了哪些菜，有那些工具，这些就是配置管理。

• 此外，我要让系统帮我去作菜，是炒、是炖仍是煮？是加水、加油仍是加火，这些都是变动管理的能力。

• 最后，系统还须要可以知道我炒的菜目前是一个什么样的状况，有几分熟，温度有没有过高，油是否是太少什么的。这些就是状态管理的能力。

无论是什么样的自动化系统，实现本质就是这三个能力的闭环。

正文

我结合本身在运维方面的一些工做经验，介绍一下怎么样去设计和建设一套完整的运维系统以便支持分布式架构的系统。

首先简单自我介绍下，本人从事运维相关的工做有很长一段时间了，应该有十几年了吧。

个人第一份工做是作系统集成，期间建过网络、建过机房、爬过天花、搬过服务器，感受全是各类体育锻炼，锻炼出来的身体正好就是干运维的料子。由于运维首先得有体力搬得起服务器。

印象中我搬过最重的服务器是 IBM的RS6000，应该有个几百斤吧，一我的根本扛不动，四我的搬都很是吃力。我原来身体好的时候能作一百多个俯卧撑，自从不搬服务器了，如今估计30个都作不动了。

2006我加入了腾讯，腾讯企业文化很好，常常会有不少小组活动、部门活动什么的，可是作运维很苦。常常在外面玩得时候，人刚到电话就过来了。

有一段时间我专门负责值班优化，承包了全部的告警处理，那时候天天晚上要起来四五次处理故障，一个故障最少也要搞个半个多小时到一个小时，当时一直以为这事只熬过来别的事情就应该都是小菜一碟了。

虽然当我有小孩以后，才发现原来还有比干运维更辛苦的事情的。

都说运维苦，但其实只要干好了，也能够是很是快乐和有成就感的。为了让运维都干得比较快乐。

因此，2015年的时候咱们几个腾讯的同事一同创业，但愿把咱们的想法和经验可以传递出来。经过推进和帮助各个企业进行运维平台的建设，来解放运维的压力，帮助运维进行转型，并造成运维技术的企业竞争力。

一、运维的趋势与挑战

先说说目前的运维的一些变化。

首先，从运维的职能来看。只要干好一件事就能够，那就是让咱们管的机器，或者业务可以一直正常运行，只要它不故障，基本就没有运维的事了。

但若是出了异常，无论什么事都会有咱们的责任，这就是运维。

为了作好运维，须要关注的事情不少很广。从能力维度来看，咱们须要关注运营产品的质量，效率成本。从产品的生命周期过程来看，咱们须要关注发布前、发布中和发布后的整个过程。

其次，从运维服务的发展趋势来看。不少年前咱们常常很是会YY一下，咱们在腾讯所作的运维优化和支持是否是能够打包成服务或解决方案去支持商业用户，当年以为是异想天开。

但随着云计算的出现，你们能够看到，如今上面已经有不少的服务，其实就运维所作的优化和提供的服务。运维的价值不断地从内部向外去传递。运维能力的建设也愈来愈受到企业的重视。

最后，来看看运维能力的发展趋势。这里我列出了腾讯互联网运维团队所经历的三个阶段。

最先的时候运维只要关注各类底层的东西，如服务器、网络、交换机等，把安排的事情干完就能够。

但随着你业务规模作大，须要作的事情就没那么简单，不但要把事情作了，还得作得快，作得好，这就须要有能力平台的积累。

经过运维平台，一方面是把咱们好的、正确的经验积累下来，二是可以经过平台把咱们的工做变得更可靠、更高效。

当平台建设达到必定的水平以后，就进入到了第三个阶段，即数据分析和云计算的阶段，在目前大数据分析能力快速发展的状况下，数据的价值不断地被你们发现和有效利用。

运维做为数据的直接管理人，咱们能够在数据的层面上去挖掘不少的价值，尤为是在服务优化和成本优化等方面，运维能够经过把有价值的数据实时采集和分析出来，并反馈给研发、产品团队，来推进产品的不断优化。

从这个角度来看，这里有不少的挑战，好比说云计算带来的一些新技术，对人能力的要求。这些不一样的新开源组件，新的技术，新的方法，都会对传统的运维工做带来变革的要求。

甚至今天主题提的分布式存储，分布式架构，各类新的架构方案和技术的流程也对运维工做带来不少冲击，这些都是须要咱们去面对，去变革的。

举个例子，我刚到腾讯的时候，腾讯有一个很奇怪的面试官，叫通道委员会。他反复问我什么是ITIL，那个时候彻底不懂，你们作运维的应该没有人不熟悉这个东西了。之前流行经过ITIL，经过流程的理念来管理IT系统。

这东西虽然有用，但运维来讲很是的烦人，它会设定没多的门槛和流程，其实这里面不少是不科学的。

好比，咱们之前要求作故障单管理，故障修复完必定要关闭故障单，我故障早都已经恢复完了，但系统老是记录我忘记结单，处理超时。为了关闭事件单，我就须要浪费额外 的时间去登录系统，去手工关闭流程。

这种时间上的浪费，当你维护的系统变大的时候，效率的损失就边得很可怕了。因此ITIL的管理理念如今已经不流行了。

如今你们都讲DEVOPS，提研发、测试和运维的协同。之前ITIL讲分工，发布就是运维的责任，如今DEVOPS强调协同，发布就都让研发去作了。

这样很合理，由于程序发布这事你让运维去负责，其实大部分状况下出了问题运维根本识别不出来，你说别人写的代码到底有没有问题我怎么知道，真出了问题，耽误了时间，最后事情仍是得交由开发来定位和处理。

而DEVOPS重视的就是高效，整个团队协同去处理这个事情，什么样的模式或什么样的人去作这个事情会变得更高效，谁就是第一责任人，咱们就让他去负责，这样团队的流转就更高效和科学了。这是理念上的一些变革。

对应这些变革，运维人员的能力要求也有所变化。之前咱们搬搬服务器，写个脚本什么的就能够了。可是随着技术和管理理念的变化，如今不同了，运维也要开始写代码了，JAVA、PYTHON、C++什么的。

运维在公司的角色定位也不太同样了，之前就只是任务实施，如今慢慢朝平台建设，甚至朝运营分析方向转变。咱们不但要有能力写代码还得有能力和研发一块儿讨论架构，和产品进行运营沟通。

真要想把运维作好，你要学的东西太多了。对于各类新技术的学习、应用和融合，若是说每一个公司或每一个运维都要去重头开始琢磨，那成本会很是大，对人的要求也会很是高。

二、平台建设理念

刚才提了不少挑战和趋势，总的来讲，若是咱们要去作一个运维平台，去解决运维遇到的这些问题和挑战，咱们要怎么作，怎么样才可以把运维的能力经过平台去不断地提高？

我这里给了一些本身的想法，这些也是咱们在腾讯这么些年积累下来的经验。

首先想讲的是平台建设的理念。不少时候作事情时，事情背后的理念每每会比作事情的方法会更重要，不知道你们认不认同这一点。

技术人员特别容易陷进一个误区，我要作一个事情，只要关注最新潮的方法和手段，背后的一些背景和因果所有都无论。

就比方说有些技术人员，他们喜欢用Markdown来写文档，但他们就历来不考虑写出来的东西商务人员该怎么使用，结果咱们公司的全部商务也得学用Markdown。在公司内部也许这种妥协是容易的，但放到市场环境下这种妥协就不现实了。

因此我以为在建设运维平台以前，有必要先沟通一些成功的经验和方法轮。

任何公司想要建设它本身的运维平台都会是一个庞大并复杂的系统工程。这里面牵涉到方方面面。不少人每每在设计的时候会但愿一步到位。

好比，但愿要一步到位，但愿直接就设计一个能力很是全面的平台，这个平台要包含全部须要的功能，要把权限管理好，要把安全控制住，要把稳定性作高、要把用户体验作精。

这种状况下，平台的建设就会很难，建设的周期也会很是的长，不少状况下项目可能尚未建设完成，需求就已经变了，项目也就烂尾了。

其实，咱们应该考虑先从0到1，而后再从1作到N。先考虑把核心最迫切的功能功能先快速实现，只有用起来才是好平台。简单的功能能够先实现，再不断地慢慢再完善，不断地丰富它的功能，这样过程当中的平台收益才会最大化。

第二，标准先行。作过运维的人都知道，我要管理的事情很是多，环境会很是复杂。当咱们推行标准化的时候，它带来的最大好处是下降平台设计和实现的难度。

标准化能力和系统建设能力是一个翘翘板。咱们在业务架构标准化方面作得好一点，那么系统建设的复杂度就低一点。

好比说，若是咱们的运维标准化作得较差，咱们有10种不一样的硬件，每种配置都不同，上面操做系统也不同，这种状况下咱们的平台就须要作不一样系统和环境作兼容性，系统实施成本就很是的高了。

标准化先行，这样系统的建设复杂度和难度都会相应下降。

第三，快速尝试。复杂系统的设计和建设都是很是难的，并且对于没作过的东西，其实不少方面在一开始的时候跟本想不清楚，也想不明白，这种状况下，应该先简单一点快速实现DEMO原型，而不是停留在反复的讨论和设计。

只要系统在应用环境中跑一阵子，很快你就会发现问题和找到相应对策的。

第四，接受不完美。腾讯如今自动化运维平台对外有两个品牌，织云和蓝鲸，而我恰好在两个团队都待过，也都经历了两个平台的建设和成长。

好比织云平台的建设，最先是从打包规范的推广开始。早期的平台只是一个简单的脚本工具平台，以后才逐渐补充了一此管理功能，如Web管理，组件管理，包发布、配置发布等，最后才逐渐建成面向全业务管理和调度的织云平台。

这里必定是个逐步完善、逐步演进的过程。腾讯也有不少一开始就规划得很大的项目，如今看起来，基本上这些大项目都死光了。因此，这里在设计和建设中，你们都要可以接受或是忍受不完美。

对技术人员来讲，这点也许会有点困难吧。记得上次参加GOPS全球运维大会的时候大众点评的一个讲师提到一点颇有道理：

咱们在面对不完美的平台时，要知道没有任何一个平台是完美的，也没有任何一个技术是完美的。但咱们决策用不用它的时候，能够评估，若是我用它，它带来的好处、优势比缺点更多，那这个平台和技术就是有价值的。

第五，业务导向。建成的平台可否发挥做重就看咱们的推广能力，这里实际也是有一些技巧的。任何一个新的东西，任何一个新的技术、在推广的时间其实都会遇到阻力。

就腾讯内部的平台推广经验来看，最有效的手段就是先找一些比较配合的团队、或是重点的业务，这些团队和业务相对的资源也比较丰富。当咱们快速完成了这些试点业务的推广，就可以在公司内部创建业务标杆，并造成影响力和口碑。

当创建了业务标杆以后，后面的业务再去推进就会容易不少了。因此，过程当中平台快速的上线，尽快输出成效，是很是重要的。

三、平台建设实践

讲完方法论，如今回到具体的系统设计和实现。咱们应该如何来设计这个运维平吧呢？做为一个完整的运维平台，必定要考虑造成运维管理能力的闭环，并逐步实现自动化。

如何才能实现运维的自动化闭环呢？最主要就是掌握配置管理、状态管理和变动管理能力。

运维的自动化你们可能不太好理解，我举个简单的例子。好比我是餐厅老板，我但愿实现炒菜的自动化。那要怎么实现呢？其实很是简单：

首先，我要知道个人厨房里到底有些什么东西是可用的，好比备了哪些菜，有那些工具，这些就是配置管理。
此外，我要让系统帮我去作菜，是炒、是炖仍是煮？是加水、加油仍是加火，这些都是变动管理的能力。
最后，系统还须要可以知道我炒的菜目前是一个什么样的状况，有几分熟，温度有没有过高，油是否是太少什么的。这些就是状态管理的能力。

无论是什么样的自动化系统，实现本质就是这三个能力的闭环。

对于运维平台来讲，咱们经过配置管理能务来收采和管理全部的系统资源，经过状态管理能力实时的监控资源的运行状况，最后再根据监控的结果来对现多的资源进行变动和调度。

能力闭环实现了，自动化能力也就实现了。

在运维平台的设计实现上。我里有一张PPT，你们应该常常可以在老王的演讲中看获得。

为了实现一个完整的平台能力，咱们须要对整个平台进行分层设计，最底层是各类硬件和资源的管理平台，它可以抽象地去管理各类物理资源和逻辑资源，和这些资源自身有关的管理能力也都会放在这一层。

再往上是通用能力层，这一层其实是把运维所负责的常规服务都实现成为系统能力。 好比运维平常的配置管理、域名管理、文件管理等。

经过第二层的平台把运维的工做所有服务化，而这里服务化的核心就是把平常手工工做都进行系统封装，变成服务接口。这种服务接口能够供外部的服务或更上层的系统进行调用和扩展。

当运维系统的服务能力构建成熟，咱们就能够上更上层构建基础能力平台，好比说用于管理交付的持续交付平台，用于管理服务状态的智能监控平台等。

当这些基础能力平台完成后，最后咱们能够开始建设各类向向业务场景的精细化管理平台。好比：

咱们但愿可以提高产品服务质量，咱们能够建设相应的业务可用性分析平台；
咱们但愿下降产品成本，咱们能够建设相应的容量优化平台；
咱们但愿提高变动效率，咱们能够建设相应的设备扩容调度平台等等。

从这里能够看到平台的分层设计，必定是从去场景化的基础能力开始向场景化的服务能力延伸，因此咱们的系统建设步骤也应该遵循这个规律。

进一步展开运维平台的实现，如今让咱们来看一下每个模块的重要功能和设计挑战。

四、配置管理平台介绍

首先说说CMDB配置管理。其实配置管理这个东西很是简单，无论什么样规模的公司，确定都会有本身的配置管理的系统或是办法。最简单的配置管理，它其实就是一个excel文档。

若是复杂一点，咱们能够搭建一个数据库，它同样也能够实现CMDB的功能。可是若是真正要把这个东西作好，要考虑的问题就比较多了。

好比说，传统的ITIL理念是很是重视CMDB的，但它把全部精力都集中在硬件资源的管理，如机房、机柜、交换机、网络，这些层面的东西。ITIL下的CMDB会把这些东西管理得很好。

但就运维所维护的业务来讲，这些信息只有其中的一个很小的一部分，并且它们对业务自动化运维所可以提供的价值实际上是很是低的。由于这些硬件信息无论管理得再怎么精细，在具体操做的层面仍是须要依赖人来进行操做。

相反，在应用程序的层面，咱们能够作的事情就不少。若是能力到位了，咱们甚至能够实现故障自愈、自动调度、弹性计算等高级的自动化能力。而这些能力，须要咱们的CMDB可以关注和管理面向业务的配置信息。

好比说我业务资源是什么样的，个人程序是什么样的，个人应用是什么样的，个人权限是什么样的，个人流程，个人策略是什么，这些东西是很是有价值的。

只有把这些东西全面管理起来，才可以真正去驱动整个业务的自动化流程。举个例子，好比说常规的一些磁盘空间告警，我要想实现故障治愈，首先我得有明确的处理策略。

好比每一台机器对应的磁盘空间清理策略是什么，而这些是须要在CMDB中管理起来的。当出现任何异常的时候，咱们的自动化系统直接到CMDB里查询相应的策略，就能够实时针对不一样的业务去实现自动恢复。

除了业务信息的管理，CMDB设计还须要考虑到数据模型的管理能力，即怎么样去支持和实现灵活的数据存储结构。

咱们要管理的数据不会都象EXCEL同样简单，相反在真正的业务环境中，必定会是多层的关联数据结构。并且这个数据结果也不可能就是一成不变的，它必定会在业务运营的过程当中须要进行动态的调整和修正。

这种状况下，咱们的CMDB就须要考虑到存储可灵活性和可扩展性。咱们须要实现可配置、可定义，并支持分级数据模型的配置，这些都是建设CMDB时候考虑的事情。

CMDB这里最后要讲讲配置信息的维护，作过运维的人应该都会有同感，配置信息的维护是很是讨厌这的事情。

腾讯在早期的时候，配置信息也都是手工维护的，若是咱们进行了服务器的上、下线，过后必定要记得登录系统去手工更新信息，否则其余人再进行操做就会出错。时间久了信息的失去价值了。

因此咱们之前的作法公司会考虑配置准确性，也即一段时间运动一次，人工的去修正信息。

更好的方法，应该是要去作信息的自动发现和自动更新。怎么实现呢？

一方面这里咱们能够作CMDB的探针，它直接去采集设备上的状态和信息，实时的上报回CMDB并更新。
另外一方面能够提供接口和外围的管理系统对接，当每一次变动结束了之后，都经过接口把变动的信息实时回写和更新CMDB，以止实现信息的自动维护。

五、变动管理平台介绍

关于变动管理平台的实现。这里能够考虑分阶段的实现方案。对于一些基础比较差的团队来讲，要想一步到位是很是困难的，并且若是能力没有达到必定的水平，有一些自动化能力也不必定能够用得起来。

这里须要建设根据团队的技术实力，选择合适的节奏分阶段进行建设。

建议先从脚本平台开始，先实现最基础的做业管理能力，以后再实现业务管理和流程管理能力。

做业管理也能够理解为脚本管理。实现自动化最简单的办法，其实就是编写脚本。每一个公司的运维团队都必定会有些积累的脚本。这些都是运维人员最宝贵的资产。

因此在变动管理平台建设的过程当中，咱们应该首先考虑把这些资产的价值发挥出来。

经过实现做业管理平台，来提供统一的可视化脚本管理能力，它一方面可以经过分享和复用来下降脚本开发的成本，另外一方面也能够实现集中控制，并保证操做的可靠性。腾讯目前的蓝鲸平台，其实本质上就是一个做业管理平台。

若是团队能力更强一点，就能够开始考虑实现业务管理能力。经过脚原本实现自动化虽然比较简单，但面对业务管理的场景时，咱们就会发现即便是一个简单的业务，都会须要大量的脚本才有可可以把业务的关联环境维护好。

这种状况下，咱们须要考虑集成的业务管理能力，须要把业务通用的维护手段和管理方法封装成通用的平台功能：

好比业务发布后的进程守护、日志清理、启动初始化；
再好比业务自己的版本管理、集群管理、实例管理、回滚管理等等。

这样作最大的好处是把业务维护的复杂度封装在平台内部，对外只须要关注到一些通和的服务接口便可。

变动管理的第三个阶段是流程和调度管理。

当咱们把所须要的各类原子操做和业务管理能力都实现以后，那么咱们就能够考虑实现最终的自动化流程和调度管理能力。

好比咱们但愿实现放牛式的服务器管理，服务器挂了能够直接把服务器杀掉而不影响业务。这时须要流程化的自动管理能力，它不但须要和资源池交互调动新设备，并且还要和业务管理平台交互，把业务实例发布上去。

随即还要调动自动化测试能力，检测一下新上的服务器是否是好的，并加载灰度上线的逻辑，把服务器慢慢上线到运营环境中去。

整个复杂的过程不但须要把各类基础工具和平台组织起来，还须要根据接口和各个不一样的系统进行交互，并根据交互的结果进行工具和后续流程的决策。

分阶段的变动管理平台建设，能够有效的下降平台建设的启动成本，而且不一样的平台能力也能够较好的适配企业不一样团队在IT能力发展过程当中所处于的不一样阶段的需求。

六、状态管理平台介绍

对于状态管理平台。说得简单一点就是监控平台。对运维自动化来讲，监控平台是一个最主要的活动触发源。若是我不知道业务运行的状态，不知道业务有没有异常，那么自动化也就没法发挥它应有的价值。

一个好的监控系统须要可以实现端到端的监控。

目前市面上有不少开源的监控组件，但基本都是单一纬度的监控，好比主机监控或是日志监控的产品。

但真正作过运维的人都应该清楚，现网中出现的不少故障都并无那么简单，大部分状况下，这种单一惟独的监控都没有办法很好的覆盖业务的监控需求。

好比：咱们但愿关注业务的运行状况，而采用了CPU的监控，它虽然能够发现到CPU的异常。但对于程序有否有BUG就无能为力了。因此一个全面的监控体系必定是须要考虑端到端的监控能力。

每个系统的最终用户都必定是人，因此咱们能够从用户的角度，模拟用户的访问路径，从而实现一个全面的端到端监控能力。

咱们能够把用户请求过程当中所通过的节点和链路所有监控起来。再经过综合的分析和汇聚，从而有效果的掌握业务的运行状态，并及时发现异常。

具体实现时，咱们能够从最底层的基础网络和链路逐步往上是应用服务器、应用组件、组件请求、服务质量、到最上层的业务状态实现所有的监控覆盖。

在监控的通道上，目前有两种主流的方式。一种是外部的探测，别一种是内部的主要采集和上报。

内部采集方式，咱们须要在服务器上部署监控的的探针，它会根据须要定时的去检查业务的运行状态，并收集有价值的日志信息。

因为不一样业务所须要的采集逻辑和收集的信息都不同，因此监控的探针须要设计成一种插件化的模式，以便支持不一样业务的灵活扩展。

对于外部探测的监控模式，通常的实现是在业务生产系统的外部寻找合适的探测节点，如公网上的服务器或外网CDN上的缓存节点。经过这些节点的访问，咱们能够模拟用户的访问路径，并还原用户的链路质量对业务的影响。

对于比较强的团队来讲，咱们在建设监控系统时，能够同时考虑集成两种不一样的监控通道能力，并实现监控能力的互补。

监控能力对于自动平台来讲，最大的价值是可以完成事件的触发。也即实现从数据发现、分析、定位、到问题解决的闭环。

经过这个闭环咱们能够构建各类故障的自愈能力。经过及时的发现异常，快速的恢复，可以有效的提高业务的可用性和质量。

举个实例的例子：当系统发现机器的CPU有异常的时候，须要对 CPU高负载进行故障干预和恢复，这种状况下我怎么作？

咱们能够取到告警的信息，告警里会告诉我这台机器的IP地址和告警的值；
经过IP，能够从CMDB中查一下这个机器属于哪一个业务，再根据业务信息能够查询到同业务下还有那些机器；
而后咱们经过同业务的IP地址把其它机器的当前CPU值都查询出来，得出的平均值再去和告警的CPU值来对比；
最后判断出是否须要系统干预。若是须要修复，系统会根据告警的IP地址到CMDB中去查询相应的恢复策略，再进行处理。

经过这种灵活和完整的验证处理闭环，咱们就能够构建出各类可靠的自动故障恢复策略。

最后，让咱们再来总结一下以前提到一些方法论。

先是标准先行、小步快跑、容忍缺陷、业务导向。

对于复杂的运维系统，不要贪大求全，关键是先构建出配置管理、状态管理和变动管理的能力闭环。

咱们能够先从标准化开始，经过推进标准化来下降运维系统的设计和实施复杂度，而后才是具体的系统实现。

第一步是配置管理，最简单的配置管理能够先从搭建一个MySQL开始。
以后的变动管理，能够先梳理运维经常使用的脚本，造成团队的脚本库或的操做标准。
监控能力的建设能够依赖外部的开源组件，也能够经过运维脚本加CRONTAB来实现。

从最简单的平台，逐步积累标准化和服务化能力，等你们造成标准化和服务化的意识和习惯了，以后再逐步完善和丰富运维系统的能力。

对于运维自动化管理平台来讲，无论具体的实现手段是什么，只要咱们可以覆盖以前所介绍的领域，可以知足业务的需求，那么这个平台就必定会很是的有生命力，很是的有价值。

以上这些就是我对运维自动化平台建设和经验和理解，谢谢你们。