SRE系列教程 | 孙宇聪：来自Google的DevOps理念及实践（下）(2)

其实说到Google在这一点上,也有所谓的运动式演练.每年1、2月份都会组织一次运动式演练,整个公司所有部门都要参与.在这一个星期的时间里实际上公司是不干什么正经事的,所有人都想出各种各样的方法去测试或者去提高系统的可靠性.

ONCALL的正确姿势

刚才说的这种比较大的所谓实战演习,具体到工作的时候也有几个,就是我们的轮值制度值班.国内小公司都是没有轮值制度的,所有人手机24小时开机,随时打电话,随时得解决问题,一个箭步从被窝里爬出来,赶紧上去解决问题.实际上这跟Google不一样.Google的值班方式更多的是八个人每人值一个星期,值一个星期,剩下的时间你就自己去写程序、做工程研发.但是在这一个星期里,你必须能处理生产上发生的一切问题,这才是真正值班.只有你值班,别人休假了,这才是值班,否则就不叫休假,也不叫值班.所以Google有一个非常明确的规定,Google认为一个事故的正确处理或从发生到解决到事后解决需要六个小时,它认为需要六个小时.运维人员每次值班一般都是值十二个小时的班,大概从早上五点到晚上五点或者是从早上十点到晚上十点.因为它所有的值班都是由两地互相倒的,在美国有一部分,在欧洲有一部分,我们上班的时候我们值班,他们上班的时候他们值班.Google认为其实一天最多只能发生两次事件.不管什么样的系统问题,首先要保证一定要有足够的时间去处理问题.因为如果问题发生太频繁了,就像有些互联网公司,每天一上班这手机就开始“嗡嗡”在桌子上不停的响.一旦有一会儿不响了,就开始担心说这个监控系统到底是是不是坏了.

如果处理太多了,实际上就变成什么呢?两个比较重要的因素,第一个因素是你没有办法好好处理,你处理相当于就是上去敲一个命令,没有时间去想到底这个东西为什么会出现这个问题,以后怎么避免这个问题.所以这个叫(狼来了)效应,你on call的时候已经没有时间去思考了.第二个会发生“狼来了”事件.本来可能是两次完全不一样的事故,但是你上一次处理的时候,你发现重启就行了,下一次你就条件反射,出现这个问题的之后你又去重启了,但它实际上可能是另外一个问题,可能是完全不相关的问题,你重启可能导致这问题更糟糕.所以如果你总是用这种模式处理问题的话必然会出问题,早晚这个灾难会升级.本来是一个很小的问题,结果可能变成一个很大的问题.

运维重要一点是解决线上问题.很多软件工程师做运维会钻牛角尖,这个线上系统出问题了,比如商城里不能购买了,这时候如果钻到这个程序里考虑要这么写还是那么写,实际上是不解决线上的问题.作为运维这个职业或者作为运营这个职业来说,它唯一的目标就是要保证系统的正常.有的时候需要用一些比较low的手段或者是方式.比如在项目初期机器有问题,我们就把它们都停了,然后使用一些新的服务器重新搭起来.事实上也不知道这个东西为什么坏了,就把它放在这儿,先去解决生产上的实际问题.实际上我认为这是运维最大的价值.运维部门目标就是保证业务的持续性.

事后总结

接着是做总结,写一些事后总结.Google的事后总结都是非常专业的,是非常对事不对人的,它会非常详细地列出来在什么时间出现了什么问题,谁去操作的,他执行了什么操作,这个操作到底是解决问题还是没有解决问题,如果没有解决问题的话该怎么去确保不会去执行这个操作.这是一个循环往复的过程,是一个不停锤炼的过程.把解决问题当成一个职业来对待的话,所有事情都很好办了.这回出现这个问题,解决了一遍,然后发现执行了某些地方可能是系统给出错误的信号,可能是文档有问题,把它都一一解决了.下回再执行的时候,可能换了一拨人来执行这个,也能保证不会出现问题.这就是事后总结带来的最大利益.

SLO预估

最后说说SLO.SLO是运维部门的一个关键工具.服务质量实际上是运维部门唯一负责的事情.公司要求员工达到某某指标,那员工怎么去达到这一点?第一,要先帮助制定SLO,要用事实、数据去说明白达到这个服务质量到底需要多少投入、需要多少流程改进、需要多少系统改进.第二,要确保达到这个服务质量不会影响创新速度.这要有一个平衡的取舍,要用数据去说话,一个每天只能down一分钟的系统和一个每天可以down四个小时的系统,它所能承受的更新频率是不一样的,部署的要求和方式肯定都是不一样的,所以要围绕着这个去做,要把这些理念推行到研发部门和产品部门.最后就是把可靠性当成产品的一个重要组成部分,研发也得关心可靠性,他在写代码的时候得知道这个东西一定是要可靠的.把可靠性一直推到产品设计或者是业务层次去,它才能贯彻到底层的研发、运维,才能把它做好.

SRE模型成功的标志

最后就是说到底SRE成功还是不成功,实际上就是看这两条曲线.上面这条线是部署规模,大家都知道互联网的业务都是爆发式增长,它是指数型的.如果说按照常规的那种招聘曲线,直线性的,那么永远赶不上这个规模,所以运维事务必须要把它压下来.Google经常做这种统计,到底我们业务规模扩大之后,扩大了多少工单数量,然后出现了多少事故,造成了多大问题.实际上只有统计这个事情,才能知道你到底做得好不好.当这个系统成熟到一定程度之后,SRE的运维速度是固定的,甚至是越来越少的.只有做到这一点,才相当于把运维这个事情做好,剩下的时间或者剩下的精力才能去接手更多的业务、做更多的技术研发.

我分享的东西也到此结束了,谢谢大家!

（编辑：ASP站长网）