档案库 · 工作与做事的点子 · 运营决策 · 2003–2016
谷歌SRE将运维变成软件工程——可靠性成为一项预算
2003年，谷歌让软件工程师设计运维；SLO设定了一个错误预算，团队可以将其用于发布新功能，而不是追求100%的可用性。
谷歌
当时的题目
By 2003 Google's growth made the traditional operations model unworkable — hiring enough operators was cost-prohibitive and near-impossible — so VP Ben Treynor Sloss had to invent a different way to run production.
它是怎么成立的
站点可靠性工程（SRE）始于2003年的谷歌，出于必要。谷歌的服务增长如此之快，以至于传统的运维模式——雇佣更多运维人员来管理机器——成本过高且几乎无法配备人员。副总裁本·特雷纳·斯洛斯决定用工程方法解决这个问题，他后来有一个著名的表述：“SRE是当你让软件工程师设计运维功能时得到的结果。”
机械上讲，SRE团队是由软件工程师组成的，他们运行生产环境，编写代码来完成以前由系统管理员手动完成的工作。谷歌将SRE的繁琐运维工作限制在时间的50%之内，其余时间用于自动化。谷歌将可靠性定义为预算：团队商定一个服务级别目标（SLO），而与100%的差距就成为一个错误预算，团队可以将其用于发布新功能。当预算耗尽时，发布冻结，直到稳定性恢复。
这一理念也改变了处理失败的方式：事后分析是无指责的，因为人为错误被视为系统问题。正如谷歌SRE教育总监珍妮弗·佩托夫所说，你不能修复人，但你可以修复系统和流程，使人们做出更好的选择——如果指责受到惩罚，事故就会被隐藏而不是被修复。
谷歌在2016年将其实践出版为免费书籍《站点可靠性工程：谷歌如何运行生产系统》，将内部纪律变成了一种可移植的纪律。SLO、错误预算和减少琐事成为全行业的标配，到2021年，谷歌自身在Alphabet中发布了超过600个SRE职位。
妙在哪
- 它将招聘问题重新定义为工程问题：SRE编写软件来完成工作，而不是用人力维持机器运行。
- 错误预算使可靠性成为双方可以交易的货币：开发者用它来发布功能，运维通过稳定性工作来收回它。
- 50%的琐事上限将自动化制度化——一个完全忙于应对的运维团队永远无法让系统变得更易运维。
- 无指责的事后分析消除了掩盖失败的动机，因此事故成为修复系统（而非修复职业）的数据。
- 出版这本书使实践变得可移植：任何公司都可以采用这一纪律，而无需雇佣谷歌的工程师。
做出来什么
Error budgets aligned development, operations and business: when the budget is spent, launches stop until stability returns. Google published the free SRE book in 2016, and SRE became a standard industry discipline — Google itself advertised 600+ SRE jobs by 2021.
可以借走的
当一个问题无法通过增加人手来解决时，重新设计工作本身：为团队设定一个可衡量的不完美预算，限制琐事，并修复系统而不是指责人。
后来
2016年免费发布的SRE书将谷歌的内部实践转变为行业标准。SRE职位头衔在科技界广泛传播；云提供商和初创公司采用SLO和错误预算作为服务运行的常规方式。在谷歌内部，SRE继续运行其最大的产品，到2021年，该公司发布了超过600个SRE职位。该学科还促进了DevOps运动，后者吸收了许多实践。由于最初的创意是公开而不是保密的，其影响力体现在职位头衔和工具上——而不是收入上。
资料来源
- The Origins of SRE from the Director of SRE Education at Google
- What is Site Reliability Engineering?
发现哪里写错了？告诉我们。
轮到你了
你刚读完一个点子。把你手上的题目说出来，看看谁接过同样的题。
免费账号 · 3 次免费提问 · 不用绑卡