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

回到最开始,Google SRE的VP叫Ben Treynor,他是一个资深的软件开发经理.2003年他加入公司第一个任务,是组建一个7人的“生产运维小组”.很快他发现如果想把这件事情做好,也就是把搜索服务运维好的话,按照Google机器增加的速度,传统的模式绝对是不可能的.机器增加的速度,系统复杂度增加的速度远比人增加的速度要多得多.所以他组建的团队有以下三个特点,注意,这里我认为其实更多的是事后的总结.首先,他的执行方式是像组建一个研发团队一样来组建这个运维团队.他招了很多他熟悉的研发工程师,这些研发工程师从开发能力上没有任何问题,用现在流行的话就是全栈工程师,什么都会做.第二点,这些人对系统管理比较有热情,懂一些Linux内核知识、网络层的知识.第三点,最关键的是这些人鄙视重复性劳动,码农最痛恨的是什么事,就是反复做同一件事.他把这些人聚到一块,然后让他们执行以前传统公司运维人员来做的事情,很自然这些人不愿意手动干,于是就写程序干.多快好省,同时写程序还有一个好处,就是可以把一些最佳实践、方式、流程、方法都固化成代码,用这种方式去应对规模性的扩张,去应对复杂度的上升.

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

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

SRE的工作职责

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

应急响应

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

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

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

（编辑：网站开发网_盐城站长网 ）

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