美团点评运维总监钟红军：美团运维的工具化、产品化、运营化

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

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

美团点评的自动化工具

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

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

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

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

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

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

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

阶段2：产品化

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

阶段3：运营化

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

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!