喜欢 DevOps？等您遇见 SRE 再说

SRE 究竟是什么？

Google 的 SRE 幕后策划者 Ben Treynor 依然没有公布一句话定义，但他将网站可靠性描述为“当软件工程师承担过去所谓的运营任务时会发生什么”。

隐藏的问题是：开发团队希望向大众发布令人称绝的新功能，并见证它们成为广受欢迎的热门应用。运营团队则希望确保这些功能不会造成任何破坏。从历史上看，这引起了一场激烈的权力斗争，运营团队试图尽力延缓更多版本的发布，而开发团队则在寻找巧妙新招来绕开阻碍他们前进的流程。（我敢打赌，这是耳熟能详的事。）

SRE 消除了关于发布内容和发布时间的猜测和争论。它引入了红绿灯发布的数学公式，并派遣一支由掌握运营技能的人组成的专职团队（恰当地称为“服务可靠性工程师”或 SRE）来持续监督产品可靠性。正如 Google 自己的 SRE Andrew Widdowson 所描述的那样，“我们的工作就像是担任世界上最紧张的车队维修工一样。我们要为时速 100 英里的赛车更换轮胎。”

听起来还不够革命性？神奇之处在于其运作方式。下面总结了一些核心原则，它们恰好也是与传统 IT 运营区别最大的地方。

首先，根据当前产品性能为新产品发布会开绿灯。

大多数应用无法实现 100% 正常运行时间。因此对于每项服务，SRE 团队都会制定服务级别协议（SLA），来规定系统对于最终用户需要达到的可靠程度。如果团队同意 99.9% 的 SLA，那么错误预算就是 0.1%。顾名思义，错误预算就是错误和中断被允许的最大阈值。

专业提示：通过这份很酷的正常运行时间备忘单，您可以轻松地将 SLA 转换为“停机分钟数”。

关键论据：开发团队可以用自己喜欢的任何方式来“支出”这种错误预算。如果产品当前运行良好，几乎没有错误，他们就能随时随地发布想要推出的内容。相反，如果达到或超过了错误预算，并且其运行触及或低于定义的 SLA，则所有发布将被冻结，直到他们将错误数量减少到允许继续发布的水平。

天才？SRE 和开发人员都有强烈的动机，一起奋力将错误数量减少到最低水平。

SRE 也会写代码

在旧模式中，您会让人们陷入可靠性问题中，然后继续施加压力（有时持续一年或更长时间），直到问题消失或把事情搞砸。

SRE 不是这样。开发和 SRE 团队共享一个人员库，因此，每雇用一名 SRE，开发人员人数就会减一（反之亦然）。这结束了开发和运营之间无休止的人头争夺战，并创建了一种自我监管系统，开发人员可以因编写性能更好的代码（即，需要更少 SRE 提供更少支持的代码）而获得增加队友人数的奖励。

开发人员也会亲力亲为

在 Google，Ben Treynor 不得不为这一事业拼搏，并且庆幸这么做了。事实上，他在 SREcon14 上关于 SRE 的精彩主题演讲中强调，启动 SRE 之前必须先获得高管的承诺。

基本上，开发团队处理所有运营工作的 5％（处理请求单、提供待命支持，等等）。这样，他们能够与自己的产品保持紧密联系，了解其运行情况，并做出更好的编程和发布决策。

此外，每当运营负载超出 SRE 团队能力时，溢出部分一定会分配给开发人员。当系统运行良好时，开发人员也开始自我调节，编写强大的代码并谨慎地发布，以防将来出现问题。

SRE 是自由人（可在需要时撤退）

为确保团队保持健康和愉悦的心态，Treynor 建议允许 SRE 根据自己的意愿转移到其他项目，甚至转移到其他组织。SRE 倡导积极、敬业和高效的团队合作，因此不应阻碍任何团队成员追求自己的个人目标。

如果整个 SRE 和开发人员团队无法和平相处，制造的麻烦多于可靠的代码，那么您可以采取最后一个严厉措施：将整个 SRE 团队从项目撤出，并将所有运营工作直接分配给开发团队。Treynor 在整个职业生涯中只这样做过几次，其威胁通常足以使两个团队建立更加积极的工作关系。

SRE 的内容远不止我在一篇文章中能介绍的，比如 SRE 如何防止生产事故、如何为待命支持团队配备人员，以及他们在每次轮班时应遵循什么规则，等等。

我们怎么看

当然，IT 世界充满了流行语和新潮流。前一分钟还是云，下一分钟就是 DevOps、客户体验或游戏化了。SRE 的能力不止于此，特别是因为它更多地关注人员和流程，而不是为它们奠定基础的技术。尽管随着概念变得成熟并被越多的团队采用，技术当然可以（而且很可能会）适应这一概念，但是您不需要新的工具来使开发和运营组织围绕现场可靠性工程原则进行调整。

在后续文章中，我们会探讨这一点：朝着 SRE 前行的实际步骤，以及技术能够发挥的作用。