经过数年蛰伏，DevOps成为了业界焦点，不过如何实现DevOps，依然路漫漫，本期文章转载自数人云组织的DevOps系列分享实录，了解并学习Google的DevOps实践
SRE（Site Reliability Engineering）是最早由Google提出，又经由Google发展完善的一个崭新运维理念。如今SRE已成为一个涵盖运维理念、思路、组织架构和具体实践的完整体系。数人云推出SRE系列教程，由SRE经验丰富的技术大牛们为大家分享运维一线的独家干货，揭示SRE背后的秘密。
数人云邀请了前Google SRE、《SRE：Google运维解密》的译者孙宇聪与大家进行了线上分享。本文讲述了SRE的基本概念和核心原理。与孙老师本人一样风趣幽默的文章，小数希望大家阅读愉快：）
PS:文末线下活动有孙老师翻译著作书籍赠送
今天与大家分享的内容是关于最近我翻译的这本书，据说反响还不错，今天借这个机会聊一聊书中的内容，并与大家分享一下我回国两年多以来，Google经验在国内的一些思考和落地实践。
很多时候国内把DevOps的范围定得有点狭窄， DevOps这件事情在国外更多是整个行业内的一个趋势。DevOps是一种模式，主要是让IT相关的东西与商业结合得更紧密一些，迭代速度变得更快一些，所以它适用于各个行业。今天说的SRE，我认为也是在运维行业上的一部分。
概括来说，我认为《SRE：Google运维解密》这本书是一个文集。GoogleSRE全球一千多人，这个组织在公司里相对比较小众，但又是一个比较重要的部门，整个Google所有业务线的运维环境都由SRE来负责。SRE是一个非常分散的组织，每个业务线、每个部门其实都有自己的SRE小团队。这本书里共有一百多个作者联合写成，其中也包括我以前所在的团队，我们做过的一些Project也在书中也有提到，所以它是一本文集。我与原著的三个编辑聊天时，他们说成书最大的难处就是删减内容，当时征集来的内容大概有一千多页，最后删到了五百多页。这也是这本书比较有意思的一个花絮。
回到这本书的宗旨， SRE到底是什么？SRE是Google发明的一个词语或者新定义的一个职业。以前这个运维角色，大家叫运维，美国叫Operation。现在Google把这个职位扩展为SRE，就是用软件工程师的方法和手段，招了一些软件工程师来解决运维的难题，这是SRE的官方定义。
传统运维模式的弱点
现在传统的计算机行业的运维方式，大部分都是采用系统管理员的模式。大家最熟悉的运维方式是这样：招聘一些系统管理员，他们有负责采购机器的，有负责维护数据中心的，也有专门维护数据库的等等。系统管理员模式有几个特点，他们只是把一些现成的组件组装起来，并不会自己开发和创造新的系统，比如拿了MySQL把它跑起来，或是研发部门开发出来的新代码组装成之后提供这样一个服务。这是运维部门的一个特色，负责把这个东西运行好。
举一个例子，在美国的时候我们经常自嘲，说自己是流水线上的工人。因为这个流水线实际上是别人设计出来的，总得有人去操作这个机器，而我们就是一线的操作流水线的工人。又比如，我们好像是发电站里的工作人员，又或者是飞机驾驶员。飞机驾驶员就是开别人造出来的飞机，这和运维部门的职责很像。
那么这样一个运维部门的职责包括哪些呢？首先最重要的是应急事件的处理，这是重中之重，也是最唯一的职责。其次是常规更新，现在的业务发展越来越快，每周都有新的东西上线，比如说今天要买新机器，明天要改IP地址，大家可能80%的投入都是在这些事上，这就是系统管理员或者是现在运维行业的工作模式。
但是系统管理员模式有一个最大的弊端，按照传统的组织架构模式或者是这种运维模式运行会导致这个团队持续扩张，业务越来越多，需要不停的招人去应付各种各样的事。刚开始接手生产的时候，也许一周就出一次事或者是需要更新一次。因为人的沟通能力总是有限的，招了五个人之后，这五个人之间的传达问题就形成了一个困难。当你把一个精神传达给这五个人，他们事后执行出来的结果都不一样，这就是传统模型一直想要解决的问题。但是这种模型也有好处，就是市场招聘比较容易。
Google有几个比较重要的特点，首先它的部署规模非常大。Google到今天已经十八年了，刚开始前几年公司所有的人平时写代码，周末去机房接机器。因为它扩展速度特别快，部署规模非常大。如果按照传统的系统管理员的那种模式操作，这个机柜归你，这个机柜归他，再下一个归另外一个人，那么Google招人的速度一定赶不上机器增加的速度，所以Google是被逼迫创造了这样的职位，因为没有办法安排团队做如此大规模的运维。
传统的运维模式还有一个更大的问题，它过于强调专业化。比如一个人是做网络的，他只做网络其他都不管，全公司可能只有他懂网络，因为他不停的在网络上投入时间，集中力气把这个事情做好。这样一个结果就是会发现运维部门没人能休假，一出事只有一个人能解决问题。不仅仅是网络，特殊硬件、一些第三方服务都存在这个问题。这就导致了知识没法共享，人灵活性受到限制，整个组织的灵活性也受限制。这个问题，我认为它最终形成了一个负反馈的循环，每个人之间越是互相隔离，越是没有办法提高，导致服务质量上不去。最大的问题是，招来更多的人其实也不解决问题，因为这个部署规模不断扩大，人之间的知识不能共享，所以招来的人只能运维新的设备，旧的设备还是这些人在做。
这是一个怪圈。回国之后我与很多公司的朋友都聊过这个问题。以前大家讲Oracle这样的公司存在老DBA，说老DBA都是难得一见的，深居简出，但是你有什么问题，只有他能解决，其实这在Google这个语境里这是一个比较不健康的状态。SRE的一大特点就是想请假的时候随时请假，每一个人都可以请假；当出现紧急情况的时候，当天值班的人真的可以处理他负责的这个服务所有的问题。
Google SRE的起源与特点
回到最开始，Google SRE的VP叫Ben Treynor，他是一个资深的软件开发经理。2003年他加入公司第一个任务，是组建一个7人的“生产运维小组”。很快他发现如果想把这件事情做好，也就是把搜索服务运维好的话，按照Google机器增加的速度，传统的模式绝对是不可能的。机器增加的速度，系统复杂度增加的速度远比人增加的速度要多得多。所以他组建的团队有以下三个特点，注意，这里我认为其实更多的是事后的总结。首先，他的执行方式是像组建一个研发团队一样来组建这个运维团队。他招了很多他熟悉的研发工程师，这些研发工程师从开发能力上没有任何问题，用现在流行的话就是全栈工程师，什么都会做。第二点，这些人对系统管理比较有热情，懂一些Linux内核知识、网络层的知识。第三点，最关键的是这些人鄙视重复性劳动，码农最痛恨的是什么事，就是反复做同一件事。他把这些人聚到一块，然后让他们执行以前传统公司运维人员来做的事情，很自然这些人不愿意手动干，于是就写程序干。多快好省，同时写程序还有一个好处，就是可以把一些最佳实践、方式、流程、方法都固化成代码，用这种方式去应对规模性的扩张，去应对复杂度的上升。
这些是SRE跟传统的运维模式最不同的一点，就是招的人研发为主，做的事也是以研发为主。这是当时SRE成立背后的故事，这些年来我认为他们做得最好的一点是一直在维持了一种平衡。将运维部门从传统执行部门往上提升，打破了传统的界限。就像刚才说的DevOps，很多人理解为就是让研发部门做运维的事，或者运维部门做研发的事情，但实际上DevOps在国外的定义更宽泛一点。DevOps的思想更多的是说把整个开发流程的界限打通，产品有的时候也要干一些研发的事，研发有时候把这个信息要很快的反馈给这个产品，开发和运维或者QA和运维之间的界限也打通。所以现在去搜DevOps的图片，会发现IBM这些人都在讲圈圈，说以前是产品研发都是一条线直着来，而现在都是转圈的，这就是DevOps理论。
按照这个理论来说，SRE就是DevOps的思想在开发和运维之间的一个平衡。
这个图是我发明的，书中没有提到。书里大概有二十多章的内容是在讲SRE的各种日常工作，简单提了一下它的金字塔模型，于是我归纳总结了一下。这里是由下至上，下面的事份额比较大一点，上面的事份额比较小一点，分了三类。第一类，运维部门最重要的是应急响应这个问题，因为业务越来越大，与运营的结合越来越紧密，很多时候要处理的事情更多的是商业和运营上的事，也包括软件上的问题，这个部门最特殊或者最唯一的职责就是应急响应。之上是日常运维，保证机器能够正常更新、快速迭代。再往上是输出一些工程研发，无论是做工具，还是做高可用架构、提高可靠性，这些都是最上层的东西，只有把底下全部做好了才能说到上面。
应急响应
应急响应是运维部门在公司最独特的一点，表现为当公司出现问题时，应该找谁或者流程应该是怎样的。我回国之后见了不少初创企业，他们网站出问题了，往往是CEO先发现，CEO打电话“哎，这个到底是怎么回事啊”，然后每一个人都说“不知道啊，不是我负责呀，我得找谁谁”。不管多大一件事都得传遍整个公司，整个效率非常混乱。
我在Google待了八年时间，这样的流程也经历过，但是最近这几年Google非常重视这一点，建立了一整套应急事件处理方式。首先要有全面监控，监控这件事情是持久不断的，重中之重。SRE所有人都要非常了解整个监控系统在所有业务中的部署实施，其实这是我们平时花精力最多的地方。监控系统里面对整个系统所有方面都有监控，不光包括业务指标，也包括性能指标、效率指标。监控应该平台化、系统化，不停的往上积累，多做一些模板，同质化的系统就可以用同样的方法去做监控。
第二点是应急事务处理，应急事务处理分两部分，第一部分是演习，另外一部分是真正的处理流程。如何把它做好？实际上就是要不停的去演习、去做这个事情。像刚才举的例子，网站挂了，首先不应该CEO先发现，而应该是监控系统或者报警系统先告警，在发现之前就很应该明确这个东西应该谁排查，谁处理，这个信息应该早就发给合适的人去处理，甚至他应该早就在做了。如果发生特别大的，需要跨部门之间协作的问题，那不应该只是领导现场调配，而是整个组织每个人都明白这个流程应该是怎么样的，直接就做。Google甚至可以做到在一次事故中间两地交班，某个团队处理一半，然后我交接给另外一边团队，就下班回家了，持续不停的有人继续跟踪处理这件事情，而不会出现问题。这样一个模式是我觉得非常值得我们思考的。
处理完问题之后，要总结。之前听过的一个故事是，某公司业务出现了一个事故，大家加班加点，十几个小时没睡觉把这事搞定，然后领导过来就说了一句“大家辛苦了，回家睡觉吧”。但是，其实在这个时候我要说，领导光说这个其实恰恰是不够的。领导在这里应该问：为什么加班啊？这个事情为什么会发生啊，下次能不能不发生，大家能不能不加班，能不能不熬夜？这样才对, 能做到事后总结这个事情很难，但只有把这个做好了，才能降低以后问题发生的几率。
日常运维
日常运维做得最多的可能是变更管理。业务现在发展非常快，迭代速度、迭代周期非常快。其实这件事情能做好，能够做到无缝、安全、不停的变更管理，是运维部门能给公司做的最大贡献。
第二个，容量规划，当规模大到一定程度的时候，就需要有人来回答这个问题——到底要买多少新机器，能否保证明年的性能、效率，那谁来负责这件事呢？SRE部门提出这些方案，然后要确保这些指标、这些东西是有数据支撑的，确实能解决问题的。
工程研发
工程研发虽然做得少，但是工作很关键。SRE在工程研发上主要的工作，首先是帮产品部门确定一个SLO。SLO是一个服务指标，每一个产品都有一个服务指标。任何系统都不可能是百分之百可靠的，也没有必要做到百分之百可靠。这里得有一个目标，比如说可以每个月中断几分钟。这件事情是要产品部门考虑清楚的。比如我之前在YouTube做视频存储、视频点播的时候，要考虑每个视频到底是存一份还是存两份的问题，将这种问题放到一个非常大的部署规模里面的时候，只有产品部门能够拍板。说到底是要不要花这个预算，要不要花这么多钱去提高0.1%的可靠性或者0.01%的可靠性。
另外一点是无人化运维。大家都看过《黑客帝国》吧？一醒来发现大家都是电池，都是为机器服务的。其实把这个比喻放在运维部门非常合适。因为如果不停的开发出需要人来操作运维的系统，结果大家最后都是电池，明显是不可持续的。如果不停的产生这种需要人来操作的东西，不停的招人，最后就变成不停的运维这个东西。把整个流程自动化，建立一个能够应对复杂业务的平台，这就是工程研发上最需要的东西。
SRE在Google有十几年的历史了。这个模型是如何成功的？我总结如下几点：
职业化
运维行业从来都说不清楚自己是干嘛的，这是不对的。很多人认为会操作Linux，或者是DBA、会配网络，就算运维了。实际上运维的范围要比这个大得多。运维应该是负责公司业务正常运转的角色，这才是真正的运维。在出问题的时候能解决问题，保障业务连续性，甚至避免问题发生，这才是运维职业的定义。
具体如何做呢？推演和演习。
推演是给你一套系统，你要分析出来它会有什么样的失败模式。我们当时经常在黑板上画系统图，大家一起讨论如果这个组件出问题了会发生什么情况，用户到底还能不能看视频了，用户购买流程还能不能走通。实际上这些过程很多时候软件开发是不考虑的，但是如何拆分、如何去保证每个环节的可靠，这才反是运维这个行业最关键的一点，所以一定要做这种推演。只有这种推演才能输出改变，让系统更可靠。
第二点是演习。我们当时每周都会进行一次小型灾难演习，例如把以前出现的问题拿出来一个，让新加入团队的人去演习，所有其他的人也都要去参加。这里主要是观察新人到底是怎么思考这个系统的，新人做出的决定到底是不是正确的。因为一个人做出的决定是不是正确的实际上取决于系统给的反馈到底是不是对的。Google认为运维复杂系统不是一个靠智商和记忆力就能解决的问题，不能依赖人一定要知道这段话或这个知识点，而是要知道一种方法，知道如何去排除问题或排查问题。运维系统应该提供足够的信息，让轮值的人能够用正确的方法去处理问题。这很像是背英语辞典和会用英语聊天的区别，你再怎么背辞典关键时刻也是要查辞典的，但是真正能运用这些信息解决问题，是比较难的。
此外，要区分责任和指责。责任和指责是两个事情，但是很多公司的运维经常分不清楚。什么叫责任，就是这个事到底谁负责。指责是另外一回事，例如一个员工敲错了一个命令，大家说 “都是因为他的错，给他扣工资、扣奖金，让他三天不吃饭”，但这其实并不真正解决问题。再比如，一个系统设计电源插座，没有仔细考虑，很容易被人踢到，结果有人真踢到了，整个机房断电了出了很大的事故。那么从Google的理念来说这里不是人的问题，而是系统设计的问题。这里是不是应该有两套电源，是不是应该有保护？只有从系统设计问题的角度出发才能真正解决问题，而指责这个踢到插座的人，让他一个月不上班，甚至当时开除也并不能解决系统的设计问题，下回总会还有人踢到。
说一个故事，故事的内容是一个事故。某个数据中心有一排机器要断电，数据中心的人发了一个工单告诉操作员要把这个开关给关了。然后这个操作员去关，他关掉了开关，但是发现这一排机器的灯没灭，另外一排的灯却灭了——按错开关了。他检查一下发现按错了，“啪”把另外一个开关也关了，然后再把这一排机器给启动，结果由于启动时候过载导致整个数据中心都断电了，扩大了问题。如果单纯只是指责，这个人肯定完了，起码奖金没有了，能不能保证工作都不知道。但是Google 更关注的是这个东西为什么会容易出错，要么是开关颜色不对，要么是相同机器的操作方式靠得太近了，会让人产生这种错误的判断。所以你看Google的机房里都是五颜六色的，因为这样确实有用，比如热水管是红色的，制冷管是蓝色的，所以查起来很容易，区分起来很容易，尽量减少了这个问题。这个设计的思想在SRE日常工作里贯彻得非常深，每人在流程或工作的时候都要考虑到有没有被误用的可能，然后如何避免误用。
专业化
专业化体现在什么程度呢？要真正的去写代码，要能给业务系统或者给研发写的东西挑出问题，提高可靠性。
第一，减少琐事。运维中有很多虚假的工作。每天很忙，然而又不解决问题，做了很多假的工作。大家看起来好像很忙，一个屏幕上十几个窗口，各种刷屏，但完全不解决问题。更好的方式是用自动化、系统化、工具化的方式去消除这种琐事的存在。如果永远靠人工，那永远都闲不下来。
第二，回到SRE，SRE制度里有一条红线，运维的人只能把一半的时间花在运维上，另外一半的时间必须搞工程上、研发上的东西。研发可以是写工具，可以是参与系统设计，参与可靠性的提高，但是要保证运维不能只干运维。
第三，我认为也是比较缺少的，运维部门光有责任没有决策权，所以大家都说一出事故，运维就背黑锅。怎么不背黑锅呢？说改这儿、改那儿，然后发现没有人批准改动，这是最大的问题。SRE做的最好的一点是管理层对SRE的工作方式非常认可、非常支持，他们认为服务质量是服务的一个重要指标。一旦上升到这个高度，SRE部门提出一些要求就比较容易理解，得到支持，因为他们是有事实根据的。当GoogleSRE发现生产出现问题的时候，标准的解决办法就是暂停所有更新，确保业务稳定。举个比较极端的例子，像刚才说的如果发现线上系统有问题的情况下，SRE是有权利拒绝接受业务更新的，只允许研发部门修bug，不允许加新功能。这个争议我在过去八年见过为数不多的几次，开发可以一直闹到 VP，SVP 这个级别。每一次都是听SRE的。
打通与产品团队的反馈回路
所有东西不都是百分之百稳定的，稳定性的提高要消耗成本，要增加更多的冗余，更多的容量，甚至只能花钱解决。运维部门的任务就是提供这些数据和方案。比如搞三个9、四个9，要如何达到，这在投入和系统设计上有很大区别。这个部分公司里没有其他人可以提出，必须要由运维部门提出。如果没有这个反馈回路的话，你会发现大家都很痛苦，很多时候做出的决定都是违背自然规律的。我看过很多这样的案例，上面拍脑门决定某个业务要100%稳定，完全不管下面怎么搞，由于反馈回路不存在或者这个反馈回路的信息流动不够顺畅，导致了这个东西最终实际做不好，这是SRE模型相当关键的一个地方。
接下来聊一聊SRE的一些最佳实践，我认为Google做得比较好的几点。
建设平台化服务体系
首先， 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成功还是不成功，实际上就是看这两条曲线。上面这条线是部署规模，大家都知道互联网的业务都是爆发式增长，它是指数型的。如果说按照常规的那种招聘曲线，直线性的，那么永远赶不上这个规模，所以运维事务必须要把它压下来。Google经常做这种统计，到底我们业务规模扩大之后，扩大了多少工单数量，然后出现了多少事故，造成了多大问题。实际上只有统计这个事情，才能知道你到底做得好不好。当这个系统成熟到一定程度之后，SRE的运维速度是固定的，甚至是越来越少的。只有做到这一点，才相当于把运维这个事情做好，剩下的时间或者剩下的精力才能去接手更多的业务、做更多的技术研发。
我分享的东西也到此结束了，谢谢大家！（全文完）
来源：中生代技术
