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

数人云“当西方的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，要按照必定的规则打散它，确保挂了以后会止损，好比四分之1、三分之1、二分之一，就全靠资料库的完备，只要差一点点就都有问题。

第二，标准操做。刚才说到流程不会超过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毫秒，这个要求一旦定出来，就出质量报表，看公司全部的应用，如今的平均值是多少、高了是多少、低了是多少，分红团队、部门，立刻出TOP十、TOP20的列表，推进作得比较差的同窗改进。还好比APP的响应时间，也是相似的。慢SQL见得比较多，咱们的打压仍是比较有用的，这样作下来，慢SQL引发的故障就少了不少。

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

总结与思考

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

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