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

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

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

事后总结

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

SLO预估

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

SRE模型成功的标志

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

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

（编辑：核心网）

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