Table of Contents

Bytes per User Value

每位用户的字节值

我记得有一段时间，我们的业务在稳步增长，但支持我们产品的系统团队却一直停滞不前，而且负担过重，其增加人数的论点也有点平淡。我们的领导并不理解我们的团队需要更多的人。在他们看来，业务正在增长，值得投资的领域不是系统团队，而是需要建立新功能的产品团队，需要加入新用户的销售团队，以及需要帮助开发人员与我们的API整合的现场工程团队(field engineering teams)【1】。我们的系统团队严重缺乏与我们的用户和利益相关者对话的能力。我们不知道如何把涉及最终用户和他们所依赖的基础系统的故事拼接起来。

因此，我们没有从自己开始，而是从这些终端用户开始。我们调取了用户增长的数据，并问自己如何能够证明对基础设施的投资与我们的业务增长有着内在的联系。

从那里，我们能够讲述一个故事，说明用户的业务增长如何带来API量的增加，这反过来又给我们的基础设施带来了相应的负担。我们并没有展示我们比以前更频繁地扩展服务器，而是量化了我们增加的规模中有多少是由Stripe增长最快的用户所要求的，并利用这一论点来衡量我们在可靠性方面的投资。

我们也能够向其他人展示我们已经知道的东西：系统团队吸收了大量的人工劳作，以保持我们的业务运作。我们接收告警的次数越来越多，我们的用户要求也越来越多，我们被告警打扰的时间也越来越长。最重要的是，我们表明，这些中断平均来说是我们一些用户意外增长的直接结果，解决这些问题对我们企业的健康发展是最有利的。

仅仅说 ”我们没有足够的人，所以给我们更多“ 是不够的。仅仅说 ”本季度我们每笔交易处理的字节数更多，所以给我们更多的钱“ 也是不够的。每个人都需要更多的钱，更多的人，更多的服务器，以及组织内更多的资源，这种说法往往是一种零和游戏。最终，帮助我们做出有说服力的论据支持对我们的团队进行投资的原因是向我们的领导层证明，他们最关心的力量的变化会渗透到我们的系统团队中。

更广泛地说，我一直在思考，为什么这似乎是基础设施行业的一个挑战。产品团队有很好的程序来完全理解他们的用户。对他们来说，这不仅仅是给用户他们想要的东西，而是要了解他们是什么样的人：他们的使用情况，他们的担忧，以及他们的限制。在系统工程中，我们还没有建立起类似的用户服务范式。我们不知道如何雇用它，不知道如何教它，也不太知道如何理解它的价值。我们的错误在于，我们首先只为我们所运营的服务的直接消费者进行优化，并迅速将他们的任何其他问题归类为不属于我们的范围。这在某种程度上是有机的；与产品团队相比，我们自然倾向于在更大程度上与终端用户分离，但这仍然是值得修正的方向。我们需要教会自己从系统的技术性中解脱出来，理解我们的系统最终影响到的人。

我们如何构建本书的结构

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.field engineering