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

这些是SRE跟传统的运维模式最不同的一点,就是招的人研发为主,做的事也是以研发为主.这是当时SRE成立背后的故事,这些年来我认为他们做得最好的一点是一直在维持了一种平衡.将运维部门从传统执行部门往上提升,打破了传统的界限.就像刚才说的DevOps,很多人理解为就是让研发部门做运维的事,或者运维部门做研发的事情,但实际上DevOps在国外的定义更宽泛一点.DevOps的思想更多的是说把整个开发流程的界限打通,产品有的时候也要干一些研发的事,研发有时候把这个信息要很快的反馈给这个产品,开发和运维或者QA和运维之间的界限也打通.所以现在去搜DevOps的图片,会发现IBM这些人都在讲圈圈,说以前是产品研发都是一条线直着来,而现在都是转圈的,这就是DevOps理论.

按照这个理论来说,SRE就是DevOps的思想在开发和运维之间的一个平衡.

SRE的工作职责

这个图是我发明的,书中没有提到.书里大概有二十多章的内容是在讲SRE的各种日常工作,简单提了一下它的金字塔模型,于是我归纳总结了一下.这里是由下至上,下面的事份额比较大一点,上面的事份额比较小一点,分了三类.第一类,运维部门最重要的是应急响应这个问题,因为业务越来越大,与运营的结合越来越紧密,很多时候要处理的事情更多的是商业和运营上的事,也包括软件上的问题,这个部门最特殊或者最唯一的职责就是应急响应.之上是日常运维,保证机器能够正常更新、快速迭代.再往上是输出一些工程研发,无论是做工具,还是做高可用架构、提高可靠性,这些都是最上层的东西,只有把底下全部做好了才能说到上面.

应急响应

应急响应是运维部门在公司最独特的一点,表现为当公司出现问题时,应该找谁或者流程应该是怎样的.我回国之后见了不少初创企业,他们网站出问题了,往往是CEO先发现,CEO打电话“哎,这个到底是怎么回事啊”,然后每一个人都说“不知道啊,不是我负责呀,我得找谁谁”.不管多大一件事都得传遍整个公司,整个效率非常混乱.

我在Google待了八年时间,这样的流程也经历过,但是最近这几年Google非常重视这一点,建立了一整套应急事件处理方式.首先要有全面监控,监控这件事情是持久不断的,重中之重.SRE所有人都要非常了解整个监控系统在所有业务中的部署实施,其实这是我们平时花精力最多的地方.监控系统里面对整个系统所有方面都有监控,不光包括业务指标,也包括性能指标、效率指标.监控应该平台化、系统化,不停的往上积累,多做一些模板,同质化的系统就可以用同样的方法去做监控.

第二点是应急事务处理,应急事务处理分两部分,第一部分是演习,另外一部分是真正的处理流程.如何把它做好?实际上就是要不停的去演习、去做这个事情.像刚才举的例子,网站挂了,首先不应该CEO先发现,而应该是监控系统或者报警系统先告警,在发现之前就很应该明确这个东西应该谁排查,谁处理,这个信息应该早就发给合适的人去处理,甚至他应该早就在做了.如果发生特别大的,需要跨部门之间协作的问题,那不应该只是领导现场调配,而是整个组织每个人都明白这个流程应该是怎么样的,直接就做.Google甚至可以做到在一次事故中间两地交班,某个团队处理一半,然后我交接给另外一边团队,就下班回家了,持续不停的有人继续跟踪处理这件事情,而不会出现问题.这样一个模式是我觉得非常值得我们思考的.

处理完问题之后,要总结.之前听过的一个故事是,某公司业务出现了一个事故,大家加班加点,十几个小时没睡觉把这事搞定,然后领导过来就说了一句“大家辛苦了,回家睡觉吧”.但是,其实在这个时候我要说,领导光说这个其实恰恰是不够的.领导在这里应该问：为什么加班啊?这个事情为什么会发生啊,下次能不能不发生,大家能不能不加班,能不能不熬夜?这样才对,能做到事后总结这个事情很难,但只有把这个做好了,才能降低以后问题发生的几率.

日常运维

日常运维做得最多的可能是变更管理.业务现在发展非常快,迭代速度、迭代周期非常快.其实这件事情能做好,能够做到无缝、安全、不停的变更管理,是运维部门能给公司做的最大贡献.

第二个,容量规划,当规模大到一定程度的时候,就需要有人来回答这个问题——到底要买多少新机器,能否保证明年的性能、效率,那谁来负责这件事呢?SRE部门提出这些方案,然后要确保这些指标、这些东西是有数据支撑的,确实能解决问题的.

工程研发

工程研发虽然做得少,但是工作很关键.SRE在工程研发上主要的工作,首先是帮产品部门确定一个SLO.SLO是一个服务指标,每一个产品都有一个服务指标.任何系统都不可能是百分之百可靠的,也没有必要做到百分之百可靠.这里得有一个目标,比如说可以每个月中断几分钟.这件事情是要产品部门考虑清楚的.比如我之前在YouTube做视频存储、视频点播的时候,要考虑每个视频到底是存一份还是存两份的问题,将这种问题放到一个非常大的部署规模里面的时候,只有产品部门能够拍板.说到底是要不要花这个预算,要不要花这么多钱去提高0.1%的可靠性或者0.01%的可靠性.

（编辑：应用网_丽江站长网）

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