微信号:infoqchina

介绍:有内容的技术社区媒体

云时代运维如何转型?大众点评有话说……

2016-03-25 08:01 钟红军

作为一家超过十年的互联网公司,大众点评的运维实践和运维理念,经历了很多变化和挑战。从2013年开始,点评运维从以前的传统运维方式中,逐步开始探索自己的道路。总结而言,就是从工具化,发展到产品化,再到现在的运营化。在这个过程中有些什么思考?为什么要这么做?结果如何?


本文由大众点评网运维和数据库总监钟红军在去年的QCon上海2015大会上的分享内容整理而成。


问题导入

先从解决问题开始。什么样的问题呢?做过运维的应该都能理解。

  • 手工操作:繁琐、不统一

  • 容易出错,无成就感

  • 无法快速交付

具体来看看。

  1. 第一个问题是,大量手工操作,这些操作很烦琐,不统一,可能A做的是这样,B做的就不一样。

  2. 第二个很容易出错,没有成就感。当时运维跟“苦逼”这个词联系在一块。

  3. 第三个问题是没有办法做到快速交付,这个快速交付有两层含义。一个是资源的快速交付,比如说突然有个大促,要扩容,但是做不到一个小时或半天把它扩完,而可能要几天。另一个是支持的快速交付,比如说周末运维不在岗,出问题了,很多时候就一群研发等着运维出现。

解决方案之工具化

解决方案一开始很简单,就是工具化。思路有三点:

  • 用户应包括整个公司研发队伍

  • 形成层次化的开发(普通运维参与开发)

  • 自动化比例要达到80%以上

首先,当时做工具化希望这个工具不止做给运维,而是做给整个研发团队,我们希望做了这个工具之后很多操作由研发去发起。其次,希望形成一种层次化的开发。除了要有一个核心的运维开发团队,可能几个人去开发一些相对比较难的地方,希望所有运维都能做开发,开发自己要用的工具。这个是有一些挑战的,因为不是每个运维都会做开发。再就是要把自动化比例做到80%以上,80%是最低要求,低于这个值失败。

我们做了两年,从1个运维开发人员开始,到现在有4个开发人员,当然其他运维都在开发,核心开发就是这4个开发人员,总共做了26个东西。

这26个有一定规律的,总结下来它核心如下图所示。

中间是Cmdb,它是一个资料库,所有自动化就基于这个东西。上面有一个Workflow,研发说业务需要扩容,或者要上一个新的东西,就去流程系统里面提一个流程,这个流程系统里面80%就可以完成,一分钟之后机器就扩好容了。右侧是一个Go的操作平台,简单来说就是脚本库,这个Go的设计落地希望除了80%可以自动化流程的东西之外,希望把剩下20%的运维操作通过一个网页去完成。左侧是CAT,这是一套监控系统,这套监控系统是点评架构去做的。这4个以外的东西就是普通运维开发的。这就是工具化。

在这个过程中,我们一边做一边思考,工具化到底解决什么问题?我们做了26个工具,其实就解决一个问题,就是提高效率,运维的操作效率,少出错,交付的效率。

悲剧的是,解决一个问题的同时带来了另一个问题:失控!

  • 工具开发管理的失控

  • 工具使用本身的失控

  • 工具所产生的信息的失控

工具化做了一年之后,发现开始要失控了。一个是工具太多了,越做越多,一大堆。另一个是开发管理失控了,版本都开始失控。还有一个是使用量也失控了,一个新进来的员工,也可以点一下鼠标完成一个扩容。可能今天往资源库上了1000台虚机,下午只剩下200台了,因为太快了,一点就申请完了。

还有工具产生的信息的失控,这些工具产生很多信息,有各种各样的监控信息,这些信息都形成一个孤岛,这里也有,那里也有。2015年业界也有出过因为工具失控而产生的悲剧例子,我们就不说了。

那怎么解决这个问题呢?当时的一个思考,就是产品化。

解决方案之产品化

公司除了运维之外,有很大的业务开发团队,他们是开发公司产品,他们面临的问题肯定比我们更严重,因为开发的东西更多,用户更多,数据更重要,他们怎么去控制呢?产品化,而不是工具化。所以我们就借鉴这个想法,提出了产品化的思路。从此就有产品经理了。

介绍产品化之前,再总结一下运维工具一些常见不足。

  • 工具主要是重视功能实现,不太重视使用体验

  • 工具不太注重多个工具之间的关联

  • 工具通常不注重使用统计和报表

  • 工具往往在开发管理方面不太严谨

比如做工具不太注重多个工具之间的关系,就像我们做了26个工具,各做各的,大家忽略各个工具之间的关系,没有形成一个整体,很零散。工具通常不注重使用统计和报表,比如说做一个扩容的工具,但是不会自己去统计每天执行了多少次,扩了多少次容,其中平均一次执行了多长时间,还有成功多少,失败多少,做工具很少自己带统计的。工具开发管理方面,一般不太严谨,因为大家就写一个工具,写完脚本就好了,可能不太做版本管理,不太做测试。这是一些常见的不足。

产品化就反过来了。

  • Service + 接口 + UI 三者分离

  • 多个工具之间的数据和功能打通

  • 注重用户的操作体验

  • 自带报表

  • 用类似“业务研发”的方式来管理

  1. 第一,工具全部都Service化,每个工具都把Service、接口和UI三者分离,Workflow可以在上面新建流程,查看流程,我们叫UI,有一个流程引擎执行这些流程,下面Service化了,对外提供一个接口。

  2. 第二,把工具之间数据和功能都打通。比如说监控数据,监控数据在CAT里面,所有其他工具都应该调CAT监控数据。功能打通,比如说Go有一个脚本是重启机器,如果Workflow发起一个流程,应该是调Go那里面的功能去完成。

  3. 第三,看中用户的操作体验。简单来说好用,好看。不但要才华横溢,也要颜值爆表。这样对工具推广有很大帮助。工具是给所有研发用的,不是单给运维用,而研发人员要远远多于运维人员。所以要让他们喜欢用。

  4. 第四,全部自带报表,要看各种运行统计数据,这个工具执行多少次,成功率、失败率,平均时长,这些指标一定要看。

  5. 第五,用业务研发方式来管理,认认真真把它当做一个代码,一个产品,而不是随随便便写的两段脚本。

又做了一段时间之后,慢慢发现这里出现一个新的事情,就是运营化。

解决方案之运营化

大家都知道产品这个词后面老跟着运营这个词,我经常也这样听,但是没有当回事。但是产品化之后我发现就要运营了。

这里运营分两块,工具产品本身的运营化和运维本身的运营化。开始把运维变成运营。我们分开来讲。

工具产品本身的运营化

产品运营比较好理解了,大概有这么几个点。

  • 运营指标 VS 技术难度

  • 功能 VS 内容

  • 宣传推广(考核 PV )

第一,开始这个思路之后,我们看待工具的方式变了,以前都是看技术难度,但现在就不看这个了,而是看运营指标。我们做了26个工具,做一个工具跑过来给我看,我一般都问运营指标,这个工具带来什么样的指标变化,这个工具有多少人用,使用量有多少,成功率、失败率,我们以运营指标考核工具,不再看技术难度。这是我们对工具管理的变化。

第二,功能和内容的对比。原来这个工具大家看中的是功能,每次运维开发团队开周会的时候都会说,我这周又开发一个什么功能,可以怎么样怎么样。我们现在思路会有所转变,我们会看中以工具提供的内容,比方讲事件管理系统是一个工具,它管理全公司的故障事件,我更看中它的内容,比如事件管理系统录入的内容准确不准确,事件发生时间准不准确。如果内容不对,系统工具就没有什么意义了。

第三,我们看中宣传和推广。

这里列一些工具的常见指标。

像Workflow,我们看中覆盖率。所谓覆盖率,比如说一天有1 000次运维的操作需求,有多少是用Workflow完成的。剩下完成不了,就看是研发没有用,还是说这个Workflow功能没有用。因为我们希望它提高效率,虽然自动化了,但如果自动化比人工还慢,那也受不了。然后自动化的比例,再就是成功率。自动化有9次都失败了,那也不行。

Cmdb看的是数据准确率。还有发布系统,发布效率和发布成功率。我们把点评系统的发布成功率提到了99%。

下面重点说一下运营推广。我们想了很多办法在公司推广我们的工具,在这个过程中也学到很多做运营的思路。

事件运营 

  • 发生热点事件时趁机推广

老板运营 

  • 总监在各种场合不忘推广自己产品

推广策略 

  • 比如,新功能何时推出才能获得最大反响?

  • 能否同时推出两个新的运维工具?

我们想了很多办法在公司推广我们的工具,在这个过程中也学到很多做运营的思路。比如说抓公司的热点,有人发了抄给很多人的邮件骂什么事情,我们赶紧跳出来,我们就有这个东西,很好用,人家说这个不太符合我们要求,我们可以改,马上把开发人员带到你身边去,你看你要怎么样,马上可以改。

还有就是老板运营,作为总监,我的一个重大职责就是在各种场合推产品。

然后我们还有很多的推广策略,比如说我们工具做了新功能,以前我们测试完就上线了。现在我们不会这样,我们会想什么时间点推更好一点。比如说早晨9点推和下午3点推哪个时间点最好。大家做过运营就会发现,其实很不一样。

还有一个办法半夜推,因为半夜推能确保你这封邮件是它的新邮件里面的第一封。我们会想很多办法去推,比如说我们要不要同时推两个工具,我们一般不会这样做,怕冲淡了用户的关注度,哪怕我们同时做完了,也会拉开推,一切为了PV、UV、DVU。

运维本身的运营化

先说一下我对运营的理解:精心打造数据和内容,以一定的策略(类似营销)去影响目标人群,促成目标人群采取我们期望的行动,并达成期望的成果。

具体到运维本身的运营化,有几个要点:

  • 数据一直都在,如何理解和运用

  • 结果靠“目标人群”去达成

  • 目标人群就是业务研发团队

把运维的结果表现为一系列数字,不断去推动整个技术团队去改进这个数字。我们把这个叫做线上环境的“质量运营”。

为了做这个事情我们自己开发了一套平台——DOM,提供这些数据。

这里有一个截图,有很多服务运营的数据,有端到端的成功率,有数据库的很多指标,资源指标,上线发布的指标。也可以定制报表,因为不同的团队关心的数据不一样。比如说服务运行数据,我们关心两个数据,我们要求所有Service平均响应时间不能超过50毫秒,可用性必须是4个9。

还有App端到端成功率。所谓端到端成功率,在App上点一个功能,一定会发起一个请求到后方服务器Service接口,这个来回叫端到端,这个成功率很重要,如果这个成功率低,意味着用户点这个经常没有反应。为了把这个成功率提高,我们按部门,按团队分了两个团队的成功率,然后把它的责任写在这,一些数据,执行次数,成功率、失败率等,然后不停地做各种各样的红榜、黑榜,发给各种老大,各种会上去说,甚至跑到别人会议室去贴。

终于有一个团队受不了了,要把这个值做高,然后就做N多事情,具体做什么事情是技术的事情。不管怎么样有一个团队把这个事情做上去了,接下来大家就不停地做,于是我们从一开始90%出头做到了2个9。

这个是红黑榜,我们会出这样的榜,到处发给各种老大,CEO。

“监控”和“质量运营”到底有何区别呢?主要是思维方式不一样。具体而言:

目的不同 

  • 监控关注具体问题的解决,运营关注能力的持续提高

关注对象不同 

  • 普通技术人员更关注监控,技术leader更关注运营指标

数据不同 

  • 监控是实时详细数据,运营是提炼的有针对性指标

效果不同 

  • 再好的监控,不会导致问题的减少

我们来看一下真实效果。

回顾与总结

做了这么久之后我们发现有一些职责的改变,运维团队构成发生一些变化:

  • 线上环境质量运营

  • 工具产品的开发运营

  • DO分离的O(逐步减少、云化)

工作变成这三部分,第一部分是运营,第二部分工具产品的开发和运营,第三是传统的DO分离的O。

跟研发团队的关系也从被动变成主动。以前都是他们出故障找我们,现在我们在出故障之前告诉他们,看看你的数据很惨。

近两年来我们发生哪些转变呢?第一个我们做了这件事情,从工具化走到产品化,最后走到运营化。然后团队的过程有一个变化,以前就是运维,现在开始有开发,这个开发指的是运维的开发。

做事方式的变化,以前都是面向功能,现在我们注重两件事情,推广和运营。推广除了总监在做之外,开发人员也要自己做,自己开发的工具要自己找到人用。然后持续运营它。

跟其他团队关系的变化,以前靠流程驱动和事故驱动,我觉得研发老是乱搞出问题,我设置一些流程,你的上限要经过我允许,这个流程做了之后都是费力不讨好,他们也不喜欢,我们也做得很累,现在变成数据驱动了。

讲到转型,为什么提到转型这个词?在所谓的“云”时代,给运维带来一些挑战。我的思考是这样,第一,这个所谓转型是一直在的,不是因为云时代或者怎么样就开始转型,它天天在转,它是一个动态过程。大的“转折点”很难预见到,但是大的方向可以预见到,就是运维这个行当要向哪里去。我们的方向就是“面向运营”:

  • 更直接的为公司业务发展提供价值

  • 核心使命是持续提高各运营指标

  • “去边缘化”和所谓“运维特殊性”

比如说持续提高各运营指标,我相信任何一家互联网公司的网页打开速度,会直接关系到公司收入,转化率等等,如果运维把打开速度提高了10个百分点,就是很大的成绩,不需要跟公司说今年办了多少机器,其实领导可能也不关心。

很多人跟我说运维是边缘的,我们要想办法去边缘化,拼命跑到中间一点去,我们面向运营就会中心一点。另外一个消除运维的特殊性,大家都说有问题找运维,这个特殊性为什么存在?首先自己不要特殊,我们按业务研发的要求来要求自己。比如我们也做产品,也做运营,也招妹子,也做推广,没事打打横幅,也出数据打打屁股,数据有的时候碰到CEO也可以讲。

总结一下,运维领导者,应意识到转型无时不在,要不断抛弃和转变。我们转型的目标就是要不断逼近业务核心价值,并持续运营。

老司机介绍

钟红军,大众点评网运维和数据库总监。有多家互联网公司(如:pptv, 腾讯,百度等)的运维工作经验。于2013年加入大众点评网,目前致力于带领大众点评的运维、数据库、IT、安全等团队进行云时代的转型。

扩展阅读:

彩蛋一:

后台回复关键词「运维」,即可获取完整PPT。注:是在InfoQ公众号上回复,不是在本文评论区!


号外:

QCon北京2016即将于4月21日~23日在北京国际会议中心举行,本次大会也设置了运维相关话题,蚂蚁金服支付事业群首席架构师于新林(青轩)、腾讯蓝鲸负责人党受辉、滴滴出行第一位运维专家陆沛、豆瓣高级系统工程师朱兆龙、百度资深研发工程师王剑英以及阿里巴巴技术专家张智宇等将带来精彩分享。


本文系InfoQ原创首发,未经授权谢绝转载。

 
InfoQ 更多文章 年前挖的坑都填了吗?技术债务偿还计划 程序员VS武林高手:技术为外功,思维乃内力 腾讯游戏大数据服务场景与应用(附PPT) 偷师饿了么:怎样用HTTP/2优化iOS APP网络层次架构? 作为高颜值的女程序员是一种怎样的体验?
猜您喜欢 高效的秘密——快速成为技术领导者 为什么Android手机系统升级慢? 初识 iOS 9 中新的联系人框架 直播课程【2013-07-19】Mysql数据库-优化-事务-关联 这些小工具让你的Android 开发更高效