Table of Contents

It’s About the Individuals and Interactions

这是关于个人和互动的问题

个人和交互高于过程和工具。 ——敏捷宣言

这并不是说工具或流程不重要，因为它们确实重要，但创建DevOps文化的最大障碍往往是我们自己以及我们如何与团队合作。

作为我们2017年数据中心迁移工作的一部分，我们的领导层决定，团队现在将负责他们自己的基础设施。当时，我们的集中式基础架构团队在很大程度上被视为团队的阻碍。我们的一些大型应用团队缺乏技能和资源，无法在云中迁移和建立他们的应用程序，所以我们开始帮助他们。在某些情况下，这就是我们在做工作，实际上是和他们的团队坐在一起。就这样开始了我们的参与模式。

在早期，我们意识到，为了使团队长期成功，我们不能只是做工作。特别是，如果SRE【1】不断与其他团队接触，那么SRE的积压工作怎么办？因此，我们采用了一个共享目标的模式。这帮助我们在减少自动化积压和与其他团队接触之间实现了平衡。

一个共同的目标是，我们将与一个团队合作，为他们的用例建立功能，或找出一个他们将成为早期采用者的问题。这种参与更多的是给予专门的指导或嵌入一个团队，帮助它完成一个项目，如测试自动化。

经过几次合作，我们建立了一个流程，使我们能够建立这些合作伙伴关系以取得成功。在合作开始时，我们定义了成功是什么样子的，以及我们将如何衡量它。这个目标将出现在两个团队的路线图上。

然后，我们对联合执行的工作方式设定了预期。例如，我们想确保我们的工作将是指导和建立团队可以使用的工具的组合。我们还明确了谁将在诸如ticket writing【2】之类的事情上扮演角色和承担责任，以及我们将如何保持进展的更新。关于这个模式如何运作的更详细的解释，我强烈建议阅读我的同事Prashanth Sanagavarapu在The Site Reliability Workbook (O’Reilly，2018)【3】中的文章。这可能看起来有些笨拙，但它消除了混乱，节省了时间。

参与模式也创造了一些不明显的好处。通过与团队合作开发工具，我们确信它可以长期为他们工作。这也让我们更深入地了解不同的团队如何工作和使用我们的工具。

这些参与(engagements)非常有效，但应该注意的是，它们花费了大量的精力。这些类型的投资对于处于重大工作初始阶段的团队非常有用，并且可以随着时间的推移而减少。我们现在将参与限制在涉及多个团队的更大的战略努力中。

请记住，这不是复制你在书上读到的流程或推出一个特定的工具。可靠性是一项团队运动。通过关注我们的互动，我们帮助双方建立信任和共鸣。与我们合作的团队非常欣赏我们所做的工作，并且更愿意在未来与我们合作。

我们如何构建本书的结构

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.Site Reliability Engineering-中文
   Site Reliability Engineering-english
2.ticket writing
3.SRE Engagement Model
Foundations of Agile Ticket Writing: A 4-Part Series
1. Defining product value.
2. Stating clear goals.
3. Getting implementation feedback from engineers.
4. Giving the team boundaries and success metrics.
5. Understanding and breaking down roadmaps into manageable pieces of work.
6. Shipping relevant software consistently.