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

美团点评做的不止是一个慢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研究更深等等,到底应该如何走?这是我们尚在思考的话题.谢谢大家.

（编辑：ASP站长网）