Google储存SRE团队负责人第一手经验大公开_云技术实践-爱微帮
&& &&& Google储存SRE团队负责人第一手经…
在Google负责服务维运工作的工程师称为SRE（Site Reliability Engineer，网站可靠性工程师），而其中的储存SRE团队，负责维运的是Google云端平台中与储存相关的服务&突然发现Gmail用户能看到他人信件内容，若你是Gmail维运人员，会怎么做？通知团队负责人？立刻打电话询问公司副总裁？订披萨准备找问题？还是立刻关掉这个全球10亿人使用的邮件服务？Google储存服务SRE部门总监Melissa Binde说：「正确答案是立刻关掉Gmail。」&在Google负责服务维运工作的这类工程师通通称为SRE（Site Reliability Engineer，网站可靠性工程师），MelissaBinde表示，不论担任SRE这类职务的人是实习生，或是刚拿到第一份薪水的新进，只要为了保护Google，SRE维运人员「可以做任何决定的权力，甚至必须关闭整个</网站，公司高层都会支持。」她说，这句话反映出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）。她认为，解决意外最好的方式，就是了解事情始末，如果随便找人背黑锅，只会让情况越来越恶化。
点击展开全文
悄悄告诉你
更多同类文章
还可知道有多少人阅读过此篇文章哦
阅读原文和更多同类文章
可微信扫描右侧二维码关注后
还可知道有多少人阅读过此篇文章哦
云计算，云技术，云运维，虚拟化，运维，分享在云计算/虚拟化/运维项目实施中的资讯、经验、技术，坚持干货。
您的【关注和订阅】是作者不断前行的动力
本站文章来自网友的提交收录，如需删除可进入
删除，或发送邮件到 bang＠ 联系我们，
(C)2014&&版权所有&&&|&&&
京ICP备号-2&&&&京公网安备34Google储存SRE团队负责人第一手经验大公开 - 吐槽 - 爱瞎玩网
Google储存SRE团队负责人第一手经验大公开
12:40:05 　评论()
原标题：Google储存SRE团队负责人第一手经验大公开
Google网页可靠性团队储存部门总监现身说法 图片来源: iThome 突然发现Gmail用户能看到他人信件内容，若你是Gmail维运人员，会怎幺做？通知团队负责人？立刻打电话询问公司副总裁？订披萨时刚椅侍猓炕故橇⒖坦氐...Google网页可靠性团队储存部门总监现身说法
图片来源: iThome 突然发现Gmail用户能看到他人信件内容，若你是Gmail维运人员，会怎幺做？通知团队负责人？立刻打电话询问公司副总裁？订披萨时刚椅侍猓炕故橇⒖坦氐粽飧鋈10亿人使用的邮件服务？Google储存服务SRE部门总监Melissa Binde说：「正确答案是立刻关掉Gmail。」在Google负责服务维运工作的这类工程师通通称为SRE（Site Reliability Engineer，网站可靠性工程师），Melissa Binde表示，不论担任SRE这类职务的人是实习生，或是刚拿到第一份薪水的新进，只要为了保护Google，SRE维运人员「可以做任何决定的权力，甚至必须关闭整个网站，公司高层都会支持。」她说，这句话反映出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就是由软体工程师来负责维运工作的设计和执行。」由熟悉软体的软体工程师来负责系统维运，更能掌握软体、系统间的交互运作关S，更重要的是，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更快完成部署、建置程序，「我对这本厚到不行的书，感到相当兴奋。」?
热点 / Hot
最新 / Latest中国领先的IT技术网站
51CTO旗下网站
Google SRE：运维还能如此高逼格？
SRE是Site Reliability Engineer的简称，从名字可以看出Google的SRE不只是做Operation方面的工作，更多是保障整个Google服务的稳定性。SWE是SoftWare Egineer的简称，即软件工程师（负责软件服务的开发、测试、发布）。SWE更新的程序代码（下文称为server），只有在SRE同意后才能上线发布。因此，SRE在Google工程师团队中地位非常高！
作者：王璞来源：| 17:21
王璞，数人科技创始人。2002年获得北京航空航天大学力学学士学位，2007年获得北京大学计算机硕士学位，2011年获得美国George Mason University计算机博士学位，研究方向机器学习，发表十余篇机器学习以及数据挖掘相关论文。毕业后在硅谷先后供职StumbleUpon、Groupon和Google三家公司，负责海量数据处理、分布式计算以及大规模机器学习相关工作。2014年回国创办数人科技，基于Mesos和Docker构建分布式计算平台，为企业客户提供高性能分布式PaaS解决方案。
SRE是Site Reliability Engineer的简称，从名字可以看出Google的SRE不只是做Operation方面的工作，更多是保障整个Google服务的稳定性。SRE不接触底层硬件如服务器，这也是高逼格的由来：
Google 数据中心的硬件层面的维护工作是交给technician来做的，technician一般不需要有大学学历。
SWE是SoftWare Egineer的简称，即软件工程师（负责软件服务的开发、测试、发布）。
SWE更新的程序代码（下文称为server），只有在SRE同意后才能上线发布。因此，SRE在Google工程师团队中地位非常高！我们下面将分别介绍。
备注：我本人是SWE，本文是从SWE的角度看SRE，我的老朋友@孙宇聪同学是原Google SRE，他会从另一个角度来阐述此主题，敬请期待哦！
1. SRE 职责
SRE在Google不负责某个服务的上线、部署，SRE主要是保障服务的可靠性和性能，同时负责数据中心资源分配，为重要服务预留资源。
如上文所受，和SRE想对应的是SWE（软件开发工程师），负责具体的开发工作。
举个例子，我之前在Google的互联网广告部门，我们team负责的server是收集用户数据用于广告精准投放，这个server的开发、测试、上线部署等工作，都是由SWE来完成。
SRE不负责server的具体实现，SRE主要负责在server出现宕机等紧急事故时，做出快速响应，尽快恢复server，减少服务掉线带来的损失。
备注：这里的server是指服务器端程序，而不是物理服务器。在Google，SWE和SRE都无权接触物理服务器。
2. SRE 要求
因为SRE的职责是保障服务的稳定和性能，所以在SRE接手某个server之前，对server的性能和稳定性都有一定的要求，比如server出现报警的次数不能超过一定的频率，server对CPU、内存的消耗不能超过预设的指标。
只有server完全满足SRE的要求以后，SRE才会接手这个server：
当server出现问题时，SRE会先紧急修复，恢复服务，然后SRE会和SWE沟通，最终SWE来彻底修复server的bug。
同时，对server的重大更新，SWE都要提前通知SRE，做好各种准备工作，才能发布新版server：
为了能让SRE能接手server，SWE要根据SRE的要求，对server做大量的调优。首先SRE会给出各种性能指标，比如，服务响应延迟、资源使用量等等，再者SRE会要求SWE给出一些server评测结果，诸如压力测试结果、端到端测试结果等等，同时，SRE也会帮助SWE做一些性能问题排查。
所以SRE在Google地位很高，SWE为了让server成功上线，都想法跟SRE保持好关系。
我举个具体的例子来说明，在Google，SWE是如何跟SRE配合工作来上线server的。
我们team对所负责的server进行了代码重构，重构之后，要经过SRE同意，才能够上线重构后的server。
为此，我们team的SWE要向SRE证明，重构后的server对资源的开销没有增加，即CPU、内存、硬盘、带宽消耗没有增加，重构后的server性能没有降低，即端到端服务响应延迟、QPS、对压力测试的响应等这些性能指标没有降低：
当时对server代码重构之后，server有个性能指标一直达不到SRE的要求。这个指标是contention，也就是多线程情况下，对竞争资源的等待延迟。重构server之后，contention这项指标变得很高，说明多线程情况下，对竞争资源的等待变长。
我们排查很久找不到具体原因，因为SWE没有在代码中显式使用很多mutex，然后请SRE出面帮忙。
SRE使用Google内部的图形化profiling工具，cpprof，帮我们查找原因。
找到两个方面的原因：
tc_malloc在多线程情况下频繁请求内存，造成contention变高；
大量使用hash_map，hash_map没有预先分配足够内存空间，造成对底层tc_malloc调用过多。
3. SRE 工作内容
简而言之，Google的SRE不是做底层硬件维护，而是负责Google各种服务的性能和稳定性。换句话说，Google的SRE保证软件层面的性能和稳定性，包括软件基础构架和应用服务。
SRE需要对Google内部各种软件基础构架(Infrastructure)非常了解，而且SRE一般具有很强的排查问题、debug、快速恢复server的能力。
我列举一些常见的Google软件基础构架的例子：
Borg：分布式任务管理系统；
Borgmon：强大的监控报警系统；
BigTable：分布式Key/Value存储系统；
Google File System：分布式文件系统；
PubSub：分布式消息队列系统；
MapReduce：分布式大数据批处理系统；
F1：分布式数据库；
ECatcher：日志收集检索系统；
Stubby：Google的RPC实现；
Proto Buffer：数据序列化存储协议以及RPC协议；
Chubby：提供类似Zookeeper的服务。
Google还有更多的软件基础构架系统：Megastore、Spanner、Mustang等等，我没有用过，所以不熟悉。
4. 运维未来发展方向
我个人觉得，在云计算时代，运维工程师会慢慢向Google的SRE这种角色发展，远离底层硬件，更多靠近软件基础架构层面，帮助企业客户打造强大的软件基础构架。
企业客户有了强大的软件基础构架以后，能够更好应对业务的复杂多变的需求，帮助企业客户快速发展业务。
另外我个人观点，为什么Google的产品给人感觉技术含量高？
并不见得是Google的SWE比其他Microsoft、LinkedIn、Facebook的工程师能力强多少，主要是因为Google的软件基础构架(详见上文）非常强大，有了很强大的基础构架，再做出强大的产品就很方便了。
Google内部各种软件基础构架，基本上满足了各种常见分布式功能需求，极大地方便了SWE做业务开发。
换句话说，在Google做开发，SWE基本上是专注业务逻辑，应用服务系统(server)的性能主要由底层软件基础构架来保证。
&&&&我是分割线&&&&
下面就是本次分享的互动环节整理（真的非常精彩哦：）。
问题1：SRE参与软件基础项目的开发吗？
SRE一般不做开发。比如Google的BigTable有专门的开发团队，也有专门的SRE团队保障BigTable server的性能和稳定性。
问题2：一般运维工具，或者监控，告警工具，哪个团队开发？
SRE用的大型管理工具应该是专门的团队开发，比如Borgmon是Google的监控报警工具，很复杂，应该是专门的团队开发，SRE会大量使用Borgmon。
问题3：基础软件架构有可以参考的开源产品吗？
Google内部常见的软件基础构架都有开源对应的版本，比如Zookeeper对应Chubby，HDFS对应Google File System，HBase对应BigTable，Hadoop对应MapReduce，等等。
问题4：还有SRE会约束一些项目的性能指标，比如CPU和内存的使用阈值，这些值是从哪里得来的？或者说根据哪些规则来定制的？
SRE负责Google的数据中心资源分配，所以一些重要server的资源是SRE预留分配好的。对CPU、内存等资源的分配，SRE按照历史经验以及server的业务增长预期来制定。
此外Google数据中心里运行的任务有优先级，高优先级的任务会抢占低优先级任务的资源，重要的server一般优先级很高，离线任务优先级比较低，个人开发测试任务优先级最低。
如何一起愉快地发展
高效运维系列微信群是国内高端运维圈子、运维行业垂直社交的典范。现有会员800余名，其中运维总监及以上级别会员300多名。
&高效运维&公众号值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛线上/线下活动精彩分享及部分群友原创。&高效运维&也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。
提示：目前高效运维两个微信主群仅有少量珍贵席位，如您愿意，可添加萧田国个人微信号 xiaotianguo 为好友，进行申请；或申请加入我们技术交流群（技术讨论为主，没有主群那么多规矩，更热闹）。
重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及如下二维码。
【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条外电头条头条
24H热文一周话题本月最赞
讲师：5人学习过
讲师：29人学习过
讲师：5人学习过
精选博文论坛热帖下载排行
Java的出现，实现了跨操作系统平台的程序开发，以Java为基础的J2EE技术已经成为因特网服务技术的主流。然而，以J2EE为基础的SOA架构技术必...
订阅51CTO邮刊为什么谷歌的服务从来不会崩溃？
谷歌的全套应用似乎总是坚如磐石，稳固可靠。
钛媒体注：本文由钛媒体编译自《连线》文章，Joyce/编译。
对于身处墙外以及自备科学上网技能的你，还记得上一次是什么时候，你想上谷歌搜索点什么结果网页崩溃了吗？
真相是，这个答案本身就不成立，因为谷歌似乎一直都在那里，从来没有宕机过，除非你连不上网。而除了搜索引擎，谷歌提供的各种线上服务，无论是Gmail、Google Docs还是其他，都似乎是同样地稳定可靠。根据谷歌提供的统计数字，在2015全年99.97%的时间里，你都能畅通无阻地使用包括Gmail和Docs在内的全套谷歌应用。
似乎全世界的用户都对此习以为常，但这完全称得上是非常了不起的成绩，只是使用谷歌的我们很少会去思考，这家公司是怎样把&奇迹&变成日常的。
谷歌只用了短短三个词来解释：网站可靠性管理（Site Reliability Engineering，简称SRE）。
听起来没什么厉害的，但谷歌在十几年前就提出了这一影响深远的设想。这种管理哲学其实意蕴深厚且适用范围广泛，简而言之，可以归结为这么一个中心思想：
不要让擅长管理网络服务的IT人员来管理你司的网络服务。让编写软件的程序员自己来管理。
这么做的话，程序员就会自己开发有助于程序运作的工具，而不需要其他人另外花力气找bug。
&我们期待着有朝一日，不需要人进行任何管理。&
&&TODD UNDERWOOD，谷歌网站可靠性主管
谷歌工程副总裁Ben Treynor Sloss在新近的一篇文章里写到：&我们的方法呈现出来的效果是，整个团队的成员都会对手动执行任务很快地产生厌倦，也因此都掌握了编写程序的能力来代替之前的手动操作。&
对许多硅谷中的人来说，这并不算什么新鲜的观点。或者这么说，从亚马逊到，整个科技界基本上都是这么干的。人们称之为DevOps，即开发（development）和运维（operation）的合并，整合编程人员的技术与系统管理员的目标。不过，这场DevOps运动的发展虽然源自谷歌内部的SRE管理体系和亚马逊内部类似的管理原则，但也大有不同并自成一体。只是谷歌一直都秘而不宣，就像人们好奇谷歌高效的线上运维是怎么实现的时候，他们还是保持低调行事。
但谷歌已经进入了新时期，现在的它比以前更愿意对这类话题开门见山展开讨论，很大一部分原因在于谷歌想借此推广自家的云服务，以引进更多外部的公司，在谷歌的数据和机器网络之上运行他们的软件，甚至还出了一本专门论述SRE内功心法的书，就叫《网站可靠性管理》（Site Reliability Engineering）。
无论是科技业的从业人士还是圈子外的每一个小白，系统管理或曰运维都是计算机技术领域最无趣的一个方面，往往出了问题才会事后诸葛亮。然而，负责谷歌日常运作的副总裁Sloss可不这么认为。恰恰相反，他认为网站可靠性是&任何一款产品最基础的特性&，毕竟&如果没人能用得上，这个系统就毫无用处。&
从无到有的SRE
Sloss算是这场SRE运动的&发起人&。一开始，谷歌把他招进来负责运维，正是他后来提出了SRE这个词。&SRE就是你让一个软件工程师去设计一个运维团队，&他说，&我假设自己就是一个SRE系统，并按着那样的方式来设计并管理我的团队。&
而对Todd Underwood来说，公司聘请Sloss这样的程序员是再自然不过的事。他向《连线》杂志表示，&当谷歌还处于创业阶段的时候，其实还有很多其他的优秀软件工程师，他们更清楚问题可能以怎样的形式出现，也更明白整个工程该怎么做好。但没有人真的想去亲手落实。&
这是非常&谷歌&的一种现象。配置管理工具Chef的首席技术官Adam Jacob非常同意Underwood的看法并解释道，当线上的运营成长到足够大的体量时，这是一种意料之中的转型。&把软件开发和实际运营结合起来，乃至让二者密不可分，这是很自然要讨论的问题。全面地看问题才能有更好的产出。&
若联想到开发和运维原本是两个&死对头&，这种转型就显得格外有趣了。开发团队希望开发新软件，并尽可能快地让公众得到不同的体验，但运维人员更希望确保万事俱备、毫无差错，最好的办法就是尽可能减少变化。
&这是不相称的两个目标。&Underwood说。
窍门就在于，把开发和运维结合起来，消除这种对立。
Underwood把这称为&黑格尔式的正题-反题综合体&。他也承认，这种说法没人会真正买单，因为&没人还会读黑格尔了&，他打趣道。但这种说法恰恰正中命门，谷歌正是在这样的哲学思想指导下，把其他的业务都结合起来，加速了整个SRE的转型进程。
把犯错概率编入预算
其中一个重要的观点是，为了减少开发和运维之间的冲突，公司不会苛求正常运作时间达到100%。Sloss在文章中写到，真实情况是用户并不需要网络服务达到百分百可用。退一步说，用户也分不清正常运作时间达到100%和99.999%的区别（手提电脑、WiFi、电力和ISP宕机的概率可远远大于0.001%）。如果设定好一个合理的、低于100%的正常运作时间目标，也就是&错误预算&，你就有了更大的空间来调整变化，进行试验。
&引入&错误预算&解决了开发和SRE目标之间的结构性冲突问题，&Sloss写道，
&&停电&再也不是坏事，而是创新过程可预见的一部分，也是开发团队和SRE团队可以管理并且无需畏惧的正常现象。&
与此同时，谷歌也制定了配套的制度，为的是确保新的SRE成员不会沦落成以前的系统管理员角色。大体上，谷歌规定了SRE组的成员不能把超过一半的时间用在开发之外的传统运营上。如果运营的部分开始大于开发，谷歌就会把一些运营工作交给一般只负责开发软件的团队，也就是软件工程师。&有意识地保持运营和开发工作的平衡，让我们得以确保SRE团队的工作带宽，能够投入开发创造性的自动化工程，同时保留在运维工作中手机得来的经验智慧。&Sloss写到。
Chef公司的Jacob则认为，50%的比例并不是那么重要，但他喜欢这种态度。他说：&这就是经济学。我们总需要一些人来做运营的破事儿，人们总有无限的破事儿希望运营人员能够解决。所以，给这些破事儿设个限额是完全合理的。&
在招聘SRE人员方面，谷歌甚至出台了严格的指导方针。约有五成到六成SRE人员是通过工程师的招聘流程进来的，其他人则有&85%到99%&的同等技术能力，再加上&大部分软件工程师缺乏、但对SRE工作非常有用的技术技能&，比如深入了解UNIX操作系统的内部原理或硬件联网协议。这也是为了确保开发和运营保持适当的平衡。
登月计划的启示
从许多方面来看，这是一种新的管理原则。但在进一步的阐述中，谷歌团队用了一个很老的案例。
谷歌SRE原则的精神祖先其实是&代码女神&Margaret Hamilton，她是MIT的程序员，也是数学和电脑科学的先锋，在上世纪六十年代为阿波罗登月计划开发程序。Hamilton描述到，阿波罗项目的文化之一就是&从每个人、每件事上学习，包括你最不抱希望的人和事。&
Hamilton虽身为技术人员，却在运维方面起到了重要作用。当年，她经常把自己的小女儿Lauren带到实验室去。有一天Lauren不小心按下一个按钮，结果把一个用于阿波罗发射前的程序输入到正在运行发射后方案的电脑。这立马使得电脑崩溃，此后Hamilton便尝试给系统加入一个新的错误校验代码，让其能够在真正的飞行中预防这类突发情况的发生。上司对她的想法表示反对，认为宇航员永远不会犯这样的错误。然而，在阿波罗八号的飞行中，宇航员真的发生了这样的状况，所幸Hamilton早在系统文档中加入了一个变通方案。在此后的发射中，她给系统加入了错误校验代码。
&光是指出&那样做会崩溃的&真的没啥作用。但如果你说，&那样做会崩溃的，我来告诉你怎么做&，这就非常了不起了。&Underwood是这样解读的，&她看到了程序将会崩溃，并看清了会怎么崩溃，然后设计出了预防方案。&
这就是DevOps，用谷歌的说法就是SRE。听起来没什么大不了，却是非常强大的理念。它已经成就了谷歌。不过，像Underwood这样的哲学家型SRE人士还有更大的雄心。他们设想，在未来的世界里，运维能够更进一步变成代码的一部分。Underwood说：&我们期待着有朝一日，不需要人进行任何管理。&
文章来自钛媒体，作者JoyceChan
看过本文的人还看过
最新图文推荐
钛媒体TMTpost—把脉科技资本论，从资本市场看科技价值与趋势，中国最好的TMT行业观点平台。
大家感兴趣的内容
&&<a rel="nofollow" class="red" href="" target="_blank" color="red新版网站排行榜
===全新上线===
网友热评的文章