寻求 SRE

第 3 章 所以，你想建立一支 SRE 团队？

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

卢克-斯通，谷歌

本章是为那些没有实施站点可靠性工程（SRE）的企业领导者准备的。这是为那些面临云带来的干扰的 IT 经理准备的。本章面向每天都要应对越来越多复杂问题的运营总监。这是为正在构建新技术能力的首席技术官准备的。您可能正在考虑建立 SRE 团队。它适合您的组织吗？我想帮助您做出决定。

自 2014 年以来，我一直在 Google Cloud Platform 工作，遇到过至少上百位处于这种情况的领导者。我在谷歌的第一份工作是在 SRE 出现之前，而今天，我与在组织中应用 SRE 的云客户一起工作。我看到 SRE 团队在许多环境中从种子成长起来。我也见过那些努力寻找能量和营养的团队。

那么，让我们假设你想建立一个 SRE 团队。为什么？我听到过一些反复出现的主题。这些杜撰的引语说明了这些主题：

• "我的朋友们认为 SRE 很酷，在我的简历上会显得很别致"。

• "上次发生故障时，我被骂得狗血淋头"。

• "我的组织希望获得更多可预测的可靠性，并愿意为此付出代价"。

它们是对更多细微情况的巧妙提炼，但可能会引起你的共鸣。每一句话都指出了几个机会和陷阱。了解它们将有助于你弄清 SRE 将如何融入你的组织。让我们来看看每一句话的真正含义。

选择 SRE 的正确理由

"我的朋友们认为 SRE很酷，在我的简历上会显得很别致"。

第一点是要避免误解：贵组织必须从更深层次理解 SRE。

如果 SRE 在你看来很酷，那么恭喜你品位极高！将错误预算这样的理论性东西应用到实际问题中......并看到结果，是一件很酷的事情。这是科学！这是工程

然而，从长远来看，单纯依靠 SRE 目前的受欢迎程度，它是无法在您的组织中茁壮成长的。每次故障都是对团队提供真正价值能力的考验。坏消息是，当事情出现灾难性错误时，围绕着一个高度可见的团队建立信任需要大量的工作。好消息是，SRE 经过了精心设计、详细说明并在现实世界中进行了测试。它可以成为实现所需可靠性计划的支柱。

所以，你不能指望 "酷 "能带你走多远。一个运作良好的 SRE 团队拥有一种随着时间推移而发展起来的文化，而在你的组织中组建一个团队将是一个长期、高强度的项目。我们说的是几个月到几年的时间。如果这不是你的乐趣所在，你仍然可以通过采用一些 SRE 实践快速取得一些成果。例如，您可以坚持撰写后记并与团队一起回顾。这可能很有用，但不要指望它能产生与采用全套 SRE 原则相同的影响。

同样，如果你的 SRE 团队没有每天都在生产工程中实践 SRE 方法，也不要指望它能产生影响。给现有团队贴上 SRE 的标签，换几个职位名称，然后声称自己已经迈出了第一步，这样做很有诱惑力。你也许能猜到，这样做是不可能成功的，因为它实际上并没有改变系统本身的任何东西。SRE 团队从根本上说是一个由软件工程师组成的团队，他们的矛头直指可靠性问题，因此，如果你的组织不能维持软件工程师，那就不适合 SRE。如果你有软件工程师，但不能把他们的精力集中在 SRE 方法上，那么你就会有另一种 "名存实亡的 SRE"。

一个有效的 SRE 团队需要一定的环境。必须有来自基层的支持，也要有来自侧面和上面的支持。你需要得到 SRE 团队成员本身、他们的同行（开发团队和其他 SRE 团队）以及管理层的支持。团队不会孤立地茁壮成长。它需要融入公司的技术核心。沟通的便利性很重要，因此应考虑与开发团队同地办公，或投资于高质量的视频会议。SRE ...