针对高速团队的事件管理
喜欢 DevOps？等您遇见 SRE 再说
您可能听说过一家名为 Google 的小公司。他们发明了很酷的东西，比如无人驾驶汽车和太空电梯。对了，他们还开发了非常成功的应用，如 Gmail、Google 文档和 Google 地图。可以肯定地说，他们对成功开发应用略知一二，对吧？
他们还作为先驱者在幕后大力支持着一项不断发展的运动，称为“现场可靠性工程”（SRE）。SRE 有效结束了开发和运营之间由来已久的斗争。它鼓励产品可靠性、问责制和创新，减去了您可能会遭遇的那种让您感觉像在上软件开发中学的走廊戏剧。
怎么做到的？让我们来看看基本信息。
SRE 也会写代码
在旧模式中，您会让人们陷入可靠性问题中，然后继续施加压力（有时持续一年或更长时间），直到问题消失或把事情搞砸。
SRE 不是这样。开发和 SRE 团队共享一个人员库，因此，每雇用一名 SRE，开发人员人数就会减一（反之亦然）。这结束了开发和运营之间无休止的人头争夺战，并创建了一种自我监管系统，开发人员可以因编写性能更好的代码（即，需要更少 SRE 提供更少支持的代码）而获得增加队友人数的奖励。
实际上，SRE 团队完全由明星开发人员/系统管理员混合编组，不仅知道如何发现问题，也清楚如何解决它们。他们可以轻松地与开发团队交互，并且往往随着代码质量提升、项目需要的 SRE 变少，而转入开发团队。
事实上，其中一条核心原则规定，SRE 只能将 50% 的时间花在运营事务上。他们应尽可能多地花时间编写代码和构建系统，以提高性能和运营效率。
开发人员也会亲力亲为
在 Google，Ben Treynor 不得不为这一事业拼搏，并且庆幸这么做了。事实上，他在 SREcon14 上关于 SRE 的精彩主题演讲中强调，启动 SRE 之前必须先获得高管的承诺。
基本上，开发团队处理所有运营工作的 5％（处理请求单、提供待命支持，等等）。这样，他们能够与自己的产品保持紧密联系，了解其运行情况，并做出更好的编程和发布决策。
此外，每当运营负载超出 SRE 团队能力时，溢出部分一定会分配给开发人员。当系统运行良好时，开发人员也开始自我调节，编写强大的代码并谨慎地发布，以防将来出现问题。
SRE 是自由人（可在需要时撤退）
为确保团队保持健康和愉悦的心态，Treynor 建议允许 SRE 根据自己的意愿转移到其他项目，甚至转移到其他组织。SRE 倡导积极、敬业和高效的团队合作，因此不应阻碍任何团队成员追求自己的个人目标。
如果整个 SRE 和开发人员团队无法和平相处，制造的麻烦多于可靠的代码，那么您可以采取最后一个严厉措施：将整个 SRE 团队从项目撤出，并将所有运营工作直接分配给开发团队。Treynor 在整个职业生涯中只这样做过几次，其威胁通常足以使两个团队建立更加积极的工作关系。
SRE 的内容远不止我在一篇文章中能介绍的，比如 SRE 如何防止生产事故、如何为待命支持团队配备人员，以及他们在每次轮班时应遵循什么规则，等等。
我们怎么看
当然，IT 世界充满了流行语和新潮流。前一分钟还是云，下一分钟就是 DevOps、客户体验或游戏化了。SRE 的能力不止于此，特别是因为它更多地关注人员和流程，而不是为它们奠定基础的技术。尽管随着概念变得成熟并被越多的团队采用，技术当然可以（而且很可能会）适应这一概念，但是您不需要新的工具来使开发和运营组织围绕现场可靠性工程原则进行调整。
在后续文章中，我们会探讨这一点：朝着 SRE 前行的实际步骤，以及技术能够发挥的作用。
关于作者
