活动实录|工具化、产品化、运营化——「美团点评」运维团队背后的故事

数人云“当西方的 SRE 遇上东方的互联网” Meetup 第一弹实录来啦！

本次分享嘉宾是美团点评运维中心高级总监钟红军，他向我们详细介绍了美团点评近 3 年来在大规模运维的理念和实践方面的探索，尤其是在运维自动化和数据运营方面的工作和效果——

钟红军 / 美团点评运维中心高级总监

美团点评集团运维中心高级总监，此前曾工作于百度，腾讯， PPTV 等互联网公司，熟悉系统、网络、运维、安全、数据、开发等多个领域。

今天我将美团点评这几年在运维方面做的一些工作，以及自己的思考与大家分享一下。美团点评整个运维团队 100 多人， base 在北京和上海，美团和点评两家公司在 2015 年合并，所以团队也是两地都有。运维中心有 SRE 团队有数据库的团队，有自动化开发等。

阶段 1 ：工具化

我是 2013 年从百度加入点评的，之前在腾讯，当时想法很明确，因为腾讯、百度的运维体系相对比较成熟，包括运维工具、自动化的工具都是一整套，比较好用，对我来说最遗憾的是这些工具都不是自己做的，在腾讯我只是一个用户，每天用那些运维工具却不知道这些工具如何做出来的。所以在美团点评给自己的使命，就是要把美团点评的运维做到腾讯、百度的水平，把缺失的过程、成长的过程由自己做出来。美团点评运维团队在 2014 年－ 2015 年业务发展非常快，公司有几万人，研发团队很大，那时候的运维做得还是处于相对基础的阶段，遇到了问题，不分白天黑夜操作压力很大，尤其是出了事故要应急，过节需要各种的准备，值班也很混乱。

最初想法很简单，希望把这事情做到极简、规范和一致，保证操作能做到几十年不变，不管谁来做都是同样的操作。比如装一台机器或者是部署一个应用，希望它做一百次、一千次也是这样。第二，把程序代替繁琐的工具，第三，所有的操作都可记录，以免出了事故找不到是谁操作的。第四，把运维操作往前推，希望运维操作不要由运维来做了，由研发来做，因为需求本身来自于研发，不是来自于运维，所以需求来了也应该由研发去做。

以上是我去年总结的四句话，看似很普通的四句话，是美团点评做自动化过程中的一个线条。第一句话，凡是不能变成工具的规范我们都不看。做运维大家会想到出一点规范，比如发布规范、部署规范、命名规范，机器取名得有一个规范，不规范操作容易出错。在我看来，任何一个规范如果不能变成一个工具去约束的话，这规范没有意义。写一篇文档或者一个要求，发给研发去看，只要它不能变成一个工具就没有意义，因为这个规范出来，如果布置工具的话，实现 100 次可能有一次有人不遵守。但其实他一次都不遵守，好过做 100 次只有一次不遵守，因为每次都不遵守，问题很好查，而做了 100 次有一次不遵守，就很难查。比如晚上服务挂了，一千台的服务器，是其中一台的问题其实挺难查的，如果这一千台有共同的问题，就很好查。

规范本身没有任何的意义，只有它变成一个工具才有意义，因为强调的是一致性，希望它犯错也是每次犯同样的错，不要每次犯不一样的错。所以，我们的点评团队没有 howto ，没有文档，整个运维很少做文档。当然现在也做了， 100 多人还是要做一些不能形成工具的规范，不过还是坚持这一点，规范应该想办法做一个工具。比如我们有一个静默期的要求，春节长假前三天不允许发版本。那么从 2013 年开始点评就执行这个规则的，因为它有工具支持，发布系统要有开关，一到时间就能关掉，必须走运维的审批流通，这个流程是自动化的。但在 2015 年，新发布系统不支持这个开关，因此把这个规范停下来了，不执行这个规范，因为没有工具支持，执行这个规范没有意义，发个通知告诉大家要静默期，首先要挨骂，其次大家该怎么样怎么样，骂完之后扔不执行这个规范，后来我们就停下来，直到今年春节的时候，终于支持这个功能了再执行这个规范。

第二，不是增加 power ，而是减少 power 。解释一下，在 2014 年－ 2016 年做运维自动化相关工具的时候，团队的内部也是有很多的争议的，其中一个很重要的争议就是，有相当多的同学认为做自动化工具是给运维的人更大的 power ，能做更多的事，大家无限畅想这个工具可以怎么样，一按键所有的机器都重启起来，其实很悲剧。我的理念是工具是为了减少 power ，不是为了增加 power ，为什么这么说呢？如果是使之为了更强大的话，其实手工操作是最强大的，给一个 ssh 命令的窗口，一个 root ，就是最强大的，什么都可以做。工具本质是为了限制，不是为了增强，是干不了什么而不是能干什么。比如做自动化流程系统，在考核自动化流程系统的时候，看它的流程多不多，流程越多说明做得越烂。作为一个运维来说，我认为不应该有超过 10 个流程。常见的运维操作不会超过 10 个，加机器、减机器、重启机器，其他的配一个域名等。如果管理到位一点，比如配一个 web 的 IP ，这些应该都不需要运维来做，所以超过 10 件事是有问题的。

第三，解决一个复杂的问题，不可以引入另一个复杂问题作为代价。很多做运维的同学，尤其是做了一段时间后，学过很多各种各样的概念，从最早的 ITIL ，到现在的 SRE 等等，容易犯一个错误，就是喜欢用复杂的方法解决复杂的问题，运维的体系也好、运维自动化也好，其实是一个简单的问题。回到最初来讲，运维解决的问题是保障线上的稳定，只有这一件事情。运维自动化解决什么问题？就是让所有第三方因素或者是人为的因素对线上稳定性造成的伤害越少越好，这个越少越好来自于第一变更越少越好，我们在腾讯后期提出这种理念，没有变更才是最好。以前大家说管理变更，变更要管理起来，这个变更完了是永远管理不好的，最好不要有变更。比如扩容，很多同学提出节假日了容量不够，要实现一键扩容，在我的理解里面，我希望实现不需要扩容。

解决一个复杂问题，如果是用一个复杂的方法去解决，或者是引入另外一个复杂问题的话，把这东西搞得更复杂了，这是不对的。比如做监控的时候，是做减法而不是做加法，因为搞太复杂了没有意义，假定监控报警一天超过一千个了，是没有区别的，因为这时候运维做的事情肯定就是关手机，所以要做减法，不能引入复杂的问题，一定要找一个简单的方法。

第三句话和第四句话是类似的，就是工具“极简”是一种使命。我看过很多运维自动化的工具，包括腾讯、百度，还有国内很多互联网公司，因为我当时在招人，面试过互联网公司做工具的同学，很不幸最后一个人没有招，我发现他们做工具的思路和我的不太一样，很多做自动化工具的同学，往往以为让工具有价值，就把它做得复杂，看起来很华丽。总之，这不是我的思路，我的思路是极简。

比如这个运维自动化的工具假设只有一个按钮，那当然是最好的，但是做不到，我们不是乔布斯。再如做一个扩容，有很多选项可以选的，什么机房、哪个机房，尤其是规模比较大的话什么类型的机器、多少内存、多少 CPU 等等，很多同学认为选项越多，这个工具越好，越强大，在我看来选项越少越好，多了以后，第一容易出错，万一选错了，接下来就涉及到研发和运维的 PK 了。还有一个是浪费了时间，扩容一台机器应该是一件不花时间的事情，选项那么多就要看半天的时间。从工具表现来说，也是工具越简单越好。但造成一个没有想到的后果，工具做得很难看，后来我们也招前端的同学来把它做好看一点，而不是做复杂。这几年做运维自动化总结下来就这四句话。

美团点评的自动化工具

讲一下美团点评的自动化工具。最早做的是这样一个系统，抽离一下主要是四个东西：中间是一个 CMDB ，一套流程系统，一套操控平台和一套监控系统。自动化主要是四件事——

第一，资料。所有的自动化基于非常准确、详尽的资料，尤其是虚拟化、云计算比较流行的时代，一台机器在哪个交换机上是很重要的信息。比如自动扩容的时候，一定不希望同一个应用的两台机器扩到同一个交换机上，所以必须要知道这个信息。资料当时做得很详细，比如它有几段网卡，是双向还是单向连接等。资料是非常重要的，因为美团点评的规模很大，大量的机器部署在不同的城市，不可能每次真正操作的时候临时再看。再如部署的打散问题是非常关键的，部署一个应用 100 个虚拟机或者 200 个虚拟机，要确保这 200 个虚拟机是打散的，不能在同一个交换机或者是同一个物理机，或者是同一个机柜或者是同一个 IDC ，要按照一定的规则打散它，确保挂了之后会止损，比如四分之一、三分之一、二分之一，就全靠资料库的完备，只要差一点点就都有问题。

第二，标准操作。刚才说到流程不会超过 10 个，这种运维的标准操作也不会超过十几个，把这些操作提炼为标准的操作，叫做原子化的操作。想象一下，自己做一个扩容、做一个上线为例，申请一个机器，初始化它的环境，把它加入监控，做一个配置，基本上这些操作是相对固定的，原子操作是可以落地下来的，它是一个标准化的动作。这个标准化的动作把它形成一个操作库，会有人确保这个标准化动作本身的健壮性，比如重启一台机器这样的操作，肯定要把操作本身做得特别健壮，确保所有的运维，无论任何时间，做重启动作的时候一定用的同一个标准的操作。

第三，场景是一个复杂的动作，我们叫做流程。比如今天要给业务部署 300 台机器，或是今天上线一个新业务等等这是一个场景，一定能分解很多标准化的操作去完成的，场景就是流程，所以在开发的时候我们是流程系统。

独立于这三个之外就是监控。这个监控是多层面的，操作系统、监控应用，也要监控发布变更，我要知道有多少变更，多少发布。总的来说，美团点评自动化的体系就是基于这么一个大框架，当然框架有 4 个，里面的产品有很多。只要框架框好了，产品多是没有关系的，比如流程系统做两套没有关系，只要在同一个框架就好。

自动化工具讲完了，讲一下当时的过程。当我们按刚才说的思路做了很多自动化工具之后，很快陷入了一个迷茫，觉得运维不过如此，人生好像很灰暗的感觉，而且这种工具很会带来一种副作用，刚开始的时候大家还是挺开心的，有了工具之后迅速的工作效率提高了，需要半夜应急的事情就少了，有些事情真的可以研发去处理了。有一次运维团队年会，大家出发了以后突然接到电话，有一个事情研发那边需要线上做一个操作，我就跟他说有流程，在流程上申请一下就好了，而且是自动的，果然他一申请把它的操作做好了。

换做以前，那一年在腾讯的时候，我们的大部门去越南团建，万一出故障了谁处理？于是大家都去了，我一个人没有去，在家里守着电脑，等着处理故障。后来在美团点评，研发自己的流程就可以把这件事搞定，说明自动化工具确实是有效的， 2014 年底，这套东西还获得了公司季度大奖。今年我们运维团队获得了美团点评的年度大奖，还是非常不容易的。当时我们做自动化做完后，觉得很开心，然而开心没有几天大家陷入迷茫了。工具做太多之后，很快陷入了一种失控，解决问题开始带来问题了，带来问题非常多，开发也很多，很乱，信息开始不一致，工具越来越危险，于是我们开始思考——

阶段 2 ：产品化

思考的结果，我们把它叫做产品化。一开始做工具，认为它是一个工具，实现自动化的工具，没有把它理解为产品，后来思路转变了一下，把这工具转变成产品，就跟开发一个美团这样的 APP 一样的，它是一个产品，比如把这个 CMDB 或者流程定位成一个产品而不是一个工具，当想到这一点之后就豁然开朗了，产品就不一样了，做产品首先有产品经理，也可以招女同学来做 PM ，诸如此类运营都做起来了。

阶段 3 ：运营化

做了产品之后，工具确实解决了刚刚说的失控问题，但又陷入一个迷茫，简单来说就是运维和业务的关系。运维可以说在整个技术链条的最后端，食物链的最低端，如何才能体现运维价值？这时我们又整理出一套新的思路出来，叫做质量运营，这里面的想法与 SRE 有一些类似。质量运营的想法很简单，从监控系统里面不断的提炼数据，把监控的数据变成一个质量指标，以这个指标去驱动整个研发体系。因为很多的问题都是开发相关的，比如这个研发 SQL 语句写得比较差，慢 SQL 比较多，就比较容易出故障，线上压力一旦大一点，数据库都抗不住了。对这个问题以前的做法，现在线上挂了，查出来是一条慢 SQL 引起的，大家开始互相 PK ，研发说我没有改过，这条 SQL 一直都是这样的，运维说就是你这条 SQL 引起的，这是常见的套路。但是，现在反过来，运维平时就监控每个应用的慢 SQL 的个数，如果比较多，我们认为它是一个亚健康的状态，即使没有出问题，也应该降下来。

美团点评做的不止是一个慢 SQL 这么简单，我们把运营上很多的质量数据，根据这个质量数据去推动研发把质量数据改善，运维不断的检测这个数据，直到这个数据确实降下去了。 DOM 是美团点评的质量平台，类似于报表的平台，在上面不断放入很多的质量数据，拿这个数据去推动研发，基本上能想到的都有，跳板机、质量运营、消息队列， CAT 、云平台、 Nginx 等，计划中的每一件事情都被定义了出来，有一套质量指标，质量指标完全可以追溯和详细化的，所谓的追溯就是可以看到过去以来所有的，详细就是可以一直往下点，比如这个部门这台 DB 得分是 75 分，点进去看到为什么得 75 分？可能有慢 SQL5000 个，再点进去可以看到慢 SQL5000 个到底是哪 5000 个，这 5000 个到底是谁的？因为 CMDB 里面记录了所有的应用信息，研发人员对应的信息，所以效率非常高。

还有一个 DB 的健康表，其中有慢查询得分多少，磁盘使用率、锁情况得分多少，延迟一致性、绿帽子库，大表，容量系数等等，数据会不断的迭代。因为公司人比较多，美团点评的做法一般是横向对比。任何一件事情总有团队做得比较好，有团队做得比较差，让大家做横向对比，可以看到哪个团队做得比较好，哪个团队做得比较差。通过这样的方式刺激大家做改进，因为谁也不愿意自己团队做得比别的团队差，这是作为技术团队的修养。

质量运营，一句话就是提炼指标出来，不是等到它出事了，也不是响应研发需求，而是运维主动提炼这种指标出来，并推动研发把可能造成影响的指标降下去。去年 2016 年做的比较多的，一个是应用的平均响应时间，比如一个 java 应用， call 一下的平均响应时间，时间很长肯定容易出故障，负载一高就有超时等等各种故障，平时响应的时间 100 毫秒看起来还好，但是负载一旦提高就会有问题了，所以要求不能超过 50 毫秒，这个要求一旦定出来，就出质量报表，看公司所有的应用，现在的平均值是多少、高了是多少、低了是多少，分成团队、部门，马上出 TOP10 、 TOP20 的列表，推动做得比较差的同学改进。还比如 APP 的响应时间，也是类似的。慢 SQL 见得比较多，我们的打压还是比较有用的，这样做下来，慢 SQL 引起的故障就少了很多。

自此之后，运维团队和之前有了很大的变化，从完全辅助被动的状态，开始进入所谓的主导的状态。过去都是研发需要运维做什么，然后运维做什么。现在都是运维需要研发做什么，大家来做什么。团队的职责比以前有很大的变化，现在大概有三部分：第一是质量运营，第二是自动化的开发，第三是 DO 分离的 O 。三年前美团点评基本上就在做这三部分， D 是开发 O 是运维，我们是将 DO 分离的 O 逐渐减少。

总结与思考

简单总结一下，美团运维的探索之路，从一开始做工具、到做产品，到做运营， 2016 年主要的精力是做运营，团队也变成了四大部分。以前自动化工具注重的是一些功能，团队绩效就是看今年做什么功能，但是这两年不看功能了，看的是工具推广得如何，运营得怎么样。现在已经是数据驱动了，早期是事故驱动比较多，出问题了由大家来驱动，做各种改进、各种辅助、各种 case study 。流程驱动，运维设计各种各样的规则，其实都没有用，没有哪一次规则起过作用。现在是数据驱动，看数据报表，而且不断的迭代。

最后留给大家两句话：云时代以后，大家离基础设施越来越远之后，运维怎么体现价值？第二，到底是往上走还是往下走？所谓的往上走就是往业务的角度走，往下走就是相对比较传统的，比如说我对 OS 研究更深等等，到底应该如何走？这是我们尚在思考的话题。谢谢大家。