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

上一期孙宇聪老师关于SRE基本概念和核心原理的线上分享一经推出就引发了小伙伴们的热烈关注，看来你们对SRE的相关内容很感兴趣呀。

今天小数继续为你们带来孙老师的第二次线上分享内容，探讨SRE的一些最佳实践和成功标准，但愿你们阅读愉快并持续关注咱们后续的SRE内容：）

接下来聊一聊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在这一点上，也有所谓的运动式演练。每一年一、2月份都会组织一次运动式演练，整个公司全部部门都要参与。在这一个星期的时间里实际上公司是不干什么正经事的，全部人都想出各类各样的方法去测试或者去提升系统的可靠性。

ONCALL的正确姿式

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

若是处理太多了，实际上就变成什么呢？两个比较重要的因素，第一个因素是你没有办法好好处理，你处理至关于就是上去敲一个命令，没有时间去想到底这个东西为何会出现这个问题，之后怎么避免这个问题。因此这个叫（狼来了）效应，你on call的时候已经没有时间去思考了。第二个会发生“狼来了”事件。原本多是两次彻底不同的事故，可是你上一次处理的时候，你发现重启就好了，下一次你就条件反射，出现这个问题的以后你又去重启了，但它实际上多是另一个问题，多是彻底不相关的问题，你重启可能致使这问题更糟糕。因此若是你老是用这种模式处理问题的话必然会出问题，迟早这个灾难会升级。原本是一个很小的问题，结果可能变成一个很大的问题。

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

过后总结

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

SLO预估

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

SRE模型成功的标志

最后就是说到底SRE成功仍是不成功，实际上就是看这两条曲线。上面这条线是部署规模，你们都知道互联网的业务都是爆发式增加，它是指数型的。若是说按照常规的那种招聘曲线，直线性的，那么永远赶不上这个规模，因此运维事务必需要把它压下来。Google常常作这种统计，到底咱们业务规模扩大以后，扩大了多少工单数量，而后出现了多少事故，形成了多大问题。实际上只有统计这个事情，才能知道你到底作得好很差。当这个系统成熟到必定程度以后，SRE的运维速度是固定的，甚至是愈来愈少的。只有作到这一点，才至关于把运维这个事情作好，剩下的时间或者剩下的精力才能去接手更多的业务、作更多的技术研发。

我分享的东西也到此结束了，谢谢你们！

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