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

《SRE系列教程 | 孙宇聪：来自Google的DevOps理念及实践（下）》要点：
本文介绍了SRE系列教程 | 孙宇聪：来自Google的DevOps理念及实践（下），希望对您有用。如果有疑问，可以联系我们。

接下来聊一聊SRE的一些最佳实践,我认为Google做得比较好的几点.

SRE的最佳实践

建设平台化服务体系

首先, Google现在是一个六万人的公司,涉及到的产品线可能一百多个,各个部门之间差距很大,而且Google全球几百个数据中心,有很多机器,它如何管理?如果按照国内公司的方式去管理早就累死了.因为国内很多运维部门从上到下什么都管,从买机器开始,一直到最上面安装服务器、调试,配网络,所以业务线、运维部门经常好几千人.Google做得比较好的一点就是它把一个东西横向切分,因为它很早之前就意识到很多部门或者很多人之间有共性?像现在国内有的公司也开始讲的,运维部门要输出能力,公司内部也要服务化,因为只有服务化才能让每个团队更加专业化.

所以回到Google这个平台上,我认为它实际上是不停的在切分,就是横向切分.首先最底下是所谓的资源供给层,就是相当于把数据中心这件事情真的当成了一个资源,可以服于用户.就是用户需要什么样的机器,配置架构怎么样,怎么设计数据中心,这些东西它都帮用户做好.有一个专门的团队去做这件事情,这个团队也有自己的研发,也有自己的运维,也有自己的operation、PM,什么都有.

往上是技术架构,技术架构是大家经常听说的Borg系统等,让一些比较通用的技术或者通用的架构都能形成平台式的东西.

再往上才是产品线,每一层实际上都有自己的SRE部门、运维部门,都是一个项目.所以把这个平台搭起来之后,上层的人可以越来越少关心底下的细节问题,一定程度的减少了他很多精力、减少了很多官僚主义上的问题.需要计算资源的时候就给资源,不是还要先去审批又买机器,什么样的机器,什么样的配置都不一样,所以整个公司是一个非常同质化的公司,很多业务底下共享的东西很多.工作在越底层的人如果能服务的人越多,就会产生一个所谓的放大效应.可能大公司都是这样的,它有平台化效应,底下的人可以搞出一个世界最好的数据中心,可以同时服务几十个产品线的业务；搞出一个更好的数据库,所有人都可以用,这是Google做得比较好的一点.

容量规划和容量管理

然后大家会发现在做一个业务层运维的时候,可以关注更高级的东西,不是关心买什么样机器,而是更多关心到底需要多少容量,这些容量应该在什么地方.在YouTube我们经常在办公室摆一个世界地图,大家经常会讨论这里有一个数据中心,那里有一个数据中心,然后讨论在这边放多少容量,在那边放多少容量,它们之间如何灾备,我们可以考虑这些更高级的、更抽象的东西.这样的好处是可以真正的做到容灾,就是所谓的N+M.就是如果平时需要的峰值流量是N,M是作为灾备流量或者是这个冗余流量.N和M到底是什么?很多公司连自己的N都不知道,从来没有说过我们到底要处理多少流量,有些领导说我们“双11”想来多大量的就来多大量,这怎么能搞好?

这个问题是运维部门独特的功能或者独特的角色,要负责将把这个东西确定下来,我们到底要承担多大的流量,要有多少冗余.接下来就是验证这件事情,到底有没有这样的能力,能不能处理这么大的流量或者这么大的需求? Google有一个内部指标就是130%,比如可以处理1秒交易量是一百万,实际上集群的峰都是按照一百万的130%来处理.130%是负载均衡或者是一些外界波动导致的,它实际上是不平均的.我们可以说它是一百万条交易的负荷,但实际上不可能说一百万零一条这个系统就崩溃了.可以留一下窗口,留一些冗余量来处理一些操作中的未知性,还有一些特殊意外情况,所以130%是一个我们常用的指标.

在Google里面已经很少提灾备这件事情,就是对我们来说我们没有灾备容量,都是平均负载均衡的.可能有一些冗余,比如一个系统只能一千台机器,这一千台机器并不是说我有十台是不接受业务处理的,而是我们所有机器都是接受业务处理,只不过他们处理能力可能没有把所有的资源都用完.这也是Google有很多经验教训,如果一个东西老是不用的话,它就是坏的,你平时再怎么演习、怎么用,一到关键时刻它就过不去、它就是有问题,所以更多的时候压根不讨论灾备的问题,所有东西永远都是在线的,这也是为什么说想把Google.com给弄坏是一件非常困难的事情,得全球几百个数据中心同时出问题,才可能会出现不可用的情况.所以Google全球业务是不可能中断的,不管出现多大的自然灾害,它这个业务都是不可能中断的.可能只有局部地区受损,只有基础设施受损的地方,它才会有一些问题,所以这就是灾备.

实战演习

另外一个更关键的一点是做实战演习.刚才也提到了,SRE以业务小组为单位,每周都会做实战演习,整个公司实际上每年也会做一次非常大的实战演习.我可以举几个例子,Google很多地方都有办公室,有一年某个办公室食堂的菜有问题,导致所有人都拉肚子进了医院.这是Google总部啊,一万人、两万人这样.于是我们就提出这样一个问题,说如果这个地方没有人来上班了,网站到底还能不能正常运行啊?我也曾经问过百度、腾讯,他们所有人都在一个大楼里,如果大楼突然断网了,公司还运转不运转?这是一个很大的问题,不管是地质灾害问题、自然灾害、人文灾害,这些虽然听起来好像比较极端,但确实能考验出一个组织的业务持续能力.实际上这是Google做得比较好的一点.刚才说的都是比较夸张的例子,是比较大范围的.一些比较小的例子,比如这个系统就是你这个小组负责,你们这个小组到底有没有单点故障,这个人是不是能休假,如果一旦出现问题是不是所有人都能去解决这个问题.我们经常互相出题去做这种测试,然后去分享一些知识.我想这更多是一种风气吧.首先你认同这个目标,目标当然就是把这个系统建设得更可靠.认同了这个目标,接下来就是不停地去考验还有哪些漏洞,并确保整个团队其他人也有同样的知识,同样的技能去解决这个问题.

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

ONCALL的正确姿势

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

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

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

事后总结

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

SLO预估

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

SRE模型成功的标志

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

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

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4316.html