Google储存SRE团队负责人第一手经验大公开

突然发现Gmail用户能看到他人信件内容，若你是Gmail维运人员，会怎么做？通知团队负责人？立刻打电话询问公司副总裁？订披萨准备找问题？还是立刻关掉这个全球10亿人使用的邮件服务？Google储存服务SRE部门总监Melissa Binde说：“正确答案是立刻关掉Gmail。”

在Google负责服务维运工作的这类工程师通通称为SRE（Site Reliability Engineer，网站可靠性工程师），Melissa Binde表示，不论担任SRE这类职务的人是实习生，或是刚拿到第一份薪水的新进，只要为了保护Google，SRE维运人员“可以做任何决定的权力，甚至必须关闭整个Google.com网站，公司高层都会支持。”她说，这句话反映出Google对SRE一职的重视和倚赖。

Melissa Binde率领的储存SRE团队，负责维运Google云端平台中与储存相关的服务，例如GCS、Bigtable服务、SQL服务等，也包括了Google内部使用的Bigtable、分散式高扩充档案系统Colossus等多项Google全球性分散式储存系统。换句话说，SRE团队正是维持Google每天正常提供各项服务的幕后功臣。

SRE团队需支援Google全球的云端业务

但究竟Google所创立的SRE是个什么样的职务？Melissa Binde解释，其实SRE就像是近来火热的DevOps，但两者仍然略有不同。

DevOps工程师是为了解决开发团队和维运团队的矛盾而出现的新角色，不过，目前各界对DevOps内涵仍众说纷纭，出现了各式各样的诠释或定义，而Melissa Binde表示：“对Google来说，SRE就是由软件工程师来负责维运工作的设计和执行。”

由熟悉软件的软件工程师来负责系统维运，更能掌握软件、系统间的交互运作关系，更重要的是，Google的SRE团队，不是照本宣科地执行维运，更要同时负责“设计和优化维运工作。”

Google赋予SRE团队三大工作目标，包括了确保正式环境的可靠性、水平扩展性及效能表现。为了实现这些目标，SRE得想办法让负责系统的运作更自动化与视觉化，也得打造仪表板以时时监控这些系统的效能表现。例如SRE可以更换Google服务底层的数据库，来改善服务的延迟，或开发许多自动化程式加速系统部署，或是设计软件机器人（Software robot），来进行跨系统资料传递、自动关闭特定机器，甚至是关闭整座资料中心。Google的SRE团队不会集中在一处，Google全球各地据点都有分配SRE团队，来支援云端业务。

找出合适人才，是Google建立SRE团队的第一步

如何打造出这样的SRE团队？Melissa Binde透露，有4件事很重要。

第一是人员组成。她说，所有SRE成员，人人都得通过软件面试才能加入，尤其必须通过非抽象大型系统（Non-abstract large system）设计的测验，甚至“SRE要比开发人员还更了解开发。”

擅长开发的SRE参与维运机制的设计后，更能改善维运工作，举例来说，许多软件在开发阶段常有些过于理想的假设，像是系统呼叫必定不会失败，但是一旦在正式环境中大规模部署时则几乎是一定会发生系统呼叫失败的情况，后者就是SRE要负责解决的问题。

分配固定开发团队配额给SRE团队

第二是组织层级。为了让开发团队也能对SRE有贡献，当开发团队打造出来的服务大受欢迎，导致维运工作超量时， Google的开发团队可以将自己的人力配额（Headcount）贡献给SRE团队，让SRE团队可以招募更多人力，来确保服务维运的品质，才能让开发团队继续推出更多新功能。不过，SRE也有权拒绝这样的配额转移。

不过，SRE团队的直属主管必须和开发团队分开，SRE团队的直属副总和开发团队直属副总是两个人，如此一来，“当线上环境还未备妥前，SRE团队也能有权拒绝开发团队的要求。”Melissa Binde表示，因为“SRE不是群随传随到的猴子。”

减少维运人员杂事干扰，专注于手上专案任务

第三是好的工作环境。为了避免SRE受到杂事干扰，Melissa Binde表示，必须让SRE过半数时间能专注于负责的专案工作，减少SRE受到会议、工单、待命任务等工作的干扰。如果SRE团队手中有太多的专案要处理，除了可以请求开发团队提供更多配额外，也可以将手上专案转给开发团队接手。

另外，Google也采取12小时的待命（On-Call）轮班制度，而非更长的18小时或24小时待命制度。

另一方面，尽管SRE团队成员的加入颇有难度，也需经过主管同意，但所有SRE成员都是自愿加入而非受指派而成为SRE，SRE团队成员如果厌倦了从事维运工作，也可随时转入开发团队。正因此，“SRE团队也一直处在人来人往的状态，随时会有新成员加入，旧成员离开。”Melissa Binde表示，这些新血也能带给SRE团队新的思维。

守住系统高可靠性，开发团队也能尽情推新功能

Dev和Ops常见的冲突是，开发团队想尽可能尝试新功能，但Ops担心新功能影响既有服务的稳定性而力阻，双方经常各执一词而争执不下。Melissa Binde表示：“我们用数学来解决这个问题。”Google明确地建立了一个可以兼顾推新功能和服务稳定性的规则，称为“犯错预算”（error budget）的概念。

Melissa Binde举例，若某项服务承诺的SLA可用性是99.9%，那么开发团队就等于拥有0.1％的尝试错误空间，“这个0.1％就是开发团队在这项服务上可用的犯错预算。”只要整体影响服务中断的时间没有超过0.1％，开发团队可以尽情尝试新功能。当然，“若开发团队在开发过程常常失败，得不断重启服务，也会更快地用光这个预算。”Melissa Binde说。

不过，犯错预算用完了，Google仍提供开发团队一个缓冲机制，称为银色子弹（Silver Bullet）。如果开发团队耗尽了错误预算，但非常希望推出某项新功能，则可以使用银色子弹来说服VP，放手让开发团队进行。Melissa Binde笑说，虽然这样的仪式看起来很笨，“但其实威力强大。”

出错后撰写事后报告，避免错误一再重复

明确界定出开发团队可犯错的空间，让开发与维运的争执点有法可循之外，Google也非常重视出错后的事后检讨，但不是为了究责，而是为了避免错误再度发生。例如若有新人上传的程式码导致一项服务中断时，Melissa Binde认为，更应该检讨的是开发流程的程式码审核（code review）、测试及快速回复（rollback）工具的问题。她解释，这些程序应该要有能力阻止开发者上传错误的程式码，不该让人为疏失蔓延到正式环境中。

而Google也会要求开发者在事后检讨报告中，除了详细交待事故原因，更必须提出预防方法，以及发生类似事件时该如何缓和来降低受影响人数的对策。

Melissa Binde表示，这样的思维正是Google企业文化中的不究责事后检讨（blameless post mortems）。她认为，解决意外最好的方式，就是了解事情始末，如果随便找人背黑锅，只会让情况越来越恶化。

 

Google SRE团队维运心法大全  Google网页可靠性团队储存部门总监Melissa Binde同时也大力推荐这本由Google SRE团队撰写的SRE心法大全，里面汇聚70名SRE团队成员，总共累积500工作年的一手维运经验，分享他们如何帮助Google更快完成部署、建置程序，“我对这本厚到不行的书，感到相当兴奋。”