Table of Contents

Legendary

传奇

为什么有些故障一经缓解就会被遗忘，而另一些则会成为团队的传奇？

我相信这是因为传奇故事遵循英雄的旅程，这是文学作品中用来理解从摩西到哈利波特的各种故事的模式。服务中断，就像英雄的旅程一样，有三个关键部分：行动的召唤，考验的道路，以及回归。我想象on-call[1]的工程师们踏上了史诗般的征程，按照这些步骤，我们可以看到是什么让一个事件的故事变得激动人心——而且，希望能给我们带来所需的洞察力，我们需要防止它再次发生。

我传说中的行动召唤以 “那是圣诞节前的两个晚上”开始。时间很重要，因为坦率地说，这个问题在一年中的任何其他日子都不会那么有趣，但我是团队中的新人，必须鼓起勇气，在公司的假期里，给我的老板打电话寻求帮助。

考验的道路往往是最重要的部分——这是你诊断和缓解情况的时候。这个阶段是 “WTF” 时刻的金矿。如果你大声讲述你的故事，这是你的听众应该集体抱怨的地方。也许日志信息中缺少一个你需要的细节来揭开谜底。或者，像我一样，一个简单的配置变化，由于缺少工具，花了六个小时和四个开发人员来部署。

我们发现这个问题是由一个姐妹团队在做一些 “无害的”年终清理工作时造成的。幸运的是，从那时起，我们这个团队已经成熟了，但每当有人向我抱怨假期封锁或生产访问安全时，我就会拿出这个故事。从考验的道路上得到的教训是您应该投入开发时间以防止未来的痛苦。

回归(return)很重要，因为它几乎与我们的技术系统毫无关系，而与我们的团队文化息息相关。在进行事后分析或根本原因分析时，我们经常用TTx（到X的时间）来思考事件，如检测时间或缓解时间，但这些指标让我们对什么是事件的有趣之处了解甚少。如果这是你的故事中最有趣的部分，那么它的原因是否正确？还是你的团队需要努力培养一种无责的文化，在这种文化中，这些故事可以不加评判地被分享？

这些传奇故事，无论我们是否有意为之，通常都超越了我们的团队。他们的故事在聚会和喝啤酒的时候被分享，或者经常在其他故障中被分享。我是在大学的一次招聘会上了解到2012年Azure Leap Day的中断事件的。一位初级工程师分享了他的故事，他在同一个会议室里与技术研究员和副总裁一起写了一个代码修复。他的故事表明，你可以在职业生涯的早期就参与到重要事件中。最终，这影响了我加入微软的决定。

许多年后，在on-call的轮班中，我现在明白，如果一个工程师是英雄，那么在流程、基础设施或工具方面就存在着差距。我还了解到，英雄从来不是一个人。在我鼓起勇气给我的老板打电话后，我们一起解决了这个问题。那四位帮助推动配置改变的工程师是很有价值的朋友和同事。是的，我们在工作时分享了我们最喜欢的事件。

所以，大家围在一起，讲述你的故事，但请记住，这并不全是关于英雄的故事。它是关于逆境将团队聚集在一起的方式以及我们如何防止今后的故障。

我们如何构建本书的结构

SRE虽然涉及复杂的技术系统，但归根结底是一种文化实践。文化是人的产物，这启发我们根据你在组织中的SRE数量来组织本书的各个部分–你具体处理什么，你的一天是怎样的，取决于有多少个SRE工程师。我们将本书的文章分为 “SRE新手” 、0-1个SRE、1-10个SRE、10-100个SRE和 “SRE的未来 ”。

读者如果想找寻先从哪里开始的指导，可以直接跳到最适用于自己的部分；但是，你仍然会发现阅读那些目前并不适用于你日常的部分的文章的价值。

在0到1个SRE时，还没有人被指定为SRE，或者你已经找到了你的第一个SRE，这个角色看起来几乎是孤独的。

在1到10名SRE时，你正在组建一个团队，有知识共享和分工的能力。

在10到100个SRE时，你已经成为一个组织，你需要思考的不仅仅是你所从事的系统，还需要思考如何组织这么多SRE。

“SRE新手” 涵盖了基础性的话题（尽管并不详尽！），对于那些刚刚开始SRE之旅的人来说是很有帮助的，即使是最有经验的SRE，也是一种复习。 “SRE的未来” 包含了一些文章，这些文章探讨了SRE潜在的发展方向，或者是（目前）坐拥时代潮流。

没有必要按照任何特定的顺序阅读本书。你可以从头到尾读一遍。或者，如果你对某个特定的主题感到好奇，可以翻到索引，在那里你可以找到关于该主题的所有文章。把它作为参考指南，或者是灵感的来源–可以在需要的时候提供一个震撼。或者，也许可以建立一个阅读俱乐部，每周一次挑选一篇文章与同事讨论。这就是散文集的魅力所在。我们希望你和我们一样喜欢阅读它们。

结语

SRE系列的文章，有时间我就会翻译一些，希望大家能学到对自己有用的东西。谢谢

翻译不易，转载时请注明原文链接，谢谢

延伸阅读

1.on-call