在Google有十几年的历史了。这个模型是如何成功的？我总结如下几点：
职业化
运维行业从来都说不清楚自己是干嘛的，这是不对的。很多人认为会操作Linux，或者是DBA、会配网络，就算运维了。实际上运维的范围要比这个大得多。运维应该是负责公司业务正常运转的角色，这才是真正的运维。在出问题的时候能解决问题，保障业务连续性，甚至避免问题发生，这才是运维职业的定义。
具体如何做呢？推演和演习。
推演是给你一套系统，你要分析出来它会有什么样的失败模式。我们当时经常在黑板上画系统图，大家一起讨论如果这个组件出问题了会发生什么情况，用户到底还能不能看视频了，用户购买流程还能不能走通。实际上这些过程很多时候软件开发是不考虑的，但是如何拆分、如何去保证每个环节的可靠，这才反是运维这个行业最关键的一点，所以一定要做这种推演。只有这种推演才能输出改变，让系统更可靠。
第二点是演习。我们当时每周都会进行一次小型灾难演习，例如把以前出现的问题拿出来一个，让新加入团队的人去演习，所有其他的人也都要去参加。这里主要是观察新人到底是怎么思考这个系统的，新人做出的决定到底是不是正确的。因为一个人做出的决定是不是正确的实际上取决于系统给的反馈到底是不是对的。Google认为运维复杂系统不是一个靠智商和记忆力就能解决的问题，不能依赖人一定要知道这段话或这个知识点，而是要知道一种方法，知道如何去排除问题或排查问题。运维系统应该提供足够的信息，让轮值的人能够用正确的方法去处理问题。这很像是背英语辞典和会用英语聊天的区别，你再怎么背辞典关键时刻也是要查辞典的，但是真正能运用这些信息解决问题，是比较难的。
此外，要区分责任和指责。责任和指责是两个事情，但是很多公司的运维经常分不清楚。什么叫责任，就是这个事到底谁负责。指责是另外一回事，例如一个员工敲错了一个命令，大家说 “都是因为他的错，给他扣工资、扣奖金，让他三天不吃饭”，但这其实并不真正解决问题。再比如，一个系统设计电源插座，没有仔细考虑，很容易被人踢到，结果有人真踢到了，整个机房断电了出了很大的事故。那么从Google的理念来说这里不是人的问题，而是系统设计的问题。这里是不是应该有两套电源，是不是应该有保护？只有从系统设计问题的角度出发才能真正解决问题，而指责这个踢到插座的人，让他一个月不上班，甚至当时开除也并不能解决系统的设计问题，下回总会还有人踢到。
说一个故事，故事的内容是一个事故。某个数据中心有一排机器要断电，数据中心的人发了一个工单告诉操作员要把这个开关给关了。然后这个操作员去关，他关掉了开关，但是发现这一排机器的灯没灭，另外一排的灯却灭了——按错开关了。他检查一下发现按错了，“啪”把另外一个开关也关了，然后再把这一排机器给启动，结果由于启动时候过载导致整个数据中心都断电了，扩大了问题。如果单纯只是指责，这个人肯定完了，起码奖金没有了，能不能保证工作都不知道。但是Google 更关注的是这个东西为什么会容易出错，要么是开关颜色不对，要么是相同机器的操作方式靠得太近了，会让人产生这种错误的判断。所以你看Google的机房里都是五颜六色的，因为这样确实有用，比如热水管是红色的，制冷管是蓝色的，所以查起来很容易，区分起来很容易，尽量减少了这个问题。这个设计的思想在SRE日常工作里贯彻得非常深，每人在流程或工作的时候都要考虑到有没有被误用的可能，然后如何避免误用。
专业化
专业化体现在什么程度呢？要真正的去写代码，要能给业务系统或者给研发写的东西挑出问题，提高可靠性。
第一，减少琐事。运维中有很多虚假的工作。每天很忙，然而又不解决问题，做了很多假的工作。大家看起来好像很忙，一个屏幕上十几个窗口，各种刷屏，但完全不解决问题。更好的方式是用自动化、系统化、工具化的方式去消除这种琐事的存在。如果永远靠人工，那永远都闲不下来。
第二，回到SRE，SRE制度里有一条红线，运维的人只能把一半的时间花在运维上，另外一半的时间必须搞工程上、研发上的东西。研发可以是写工具，可以是参与系统设计，参与可靠性的提高，但是要保证运维不能只干运维。
第三，我认为也是比较缺少的，运维部门光有责任没有决策权，所以大家都说一出事故，运维就背黑锅。怎么不背黑锅呢？说改这儿、改那儿，然后发现没有人批准改动，这是最大的问题。SRE做的最好的一点是管理层对SRE的工作方式非常认可、非常支持，他们认为服务质量是服务的一个重要指标。一旦上升到这个高度，SRE部门提出一些要求就比较容易理解，得到支持，因为他们是有事实根据的。当GoogleSRE发现生产出现问题的时候，标准的解决办法就是暂停所有更新，确保业务稳定。举个比较极端的例子，像刚才说的如果发现线上系统有问题的情况下，SRE是有权利拒绝接受业务更新的，只允许研发部门修bug，不允许加新功能。这个争议我在过去八年见过为数不多的几次，开发可以一直闹到 VP，SVP 这个级别。每一次都是听SRE的。
打通与产品团队的反馈回路
所有东西不都是百分之百稳定的，稳定性的提高要消耗成本，要增加更多的冗余，更多的容量，甚至只能花钱解决。运维部门的任务就是提供这些数据和方案。比如搞三个9、四个9，要如何达到，这在投入和系统设计上有很大区别。这个部分公司里没有其他人可以提出，必须要由运维部门提出。如果没有这个反馈回路的话，你会发现大家都很痛苦，很多时候做出的决定都是违背自然规律的。我看过很多这样的案例，上面拍脑门决定某个业务要100%稳定，完全不管下面怎么搞，由于反馈回路不存在或者这个反馈回路的信息流动不够顺畅，导致了这个东西最终实际做不好，这是SRE模型相当关键的一个地方。
