距离我们开始在Google上练习SRE已有14年了。 回想起来，当时的一些成果似乎是显而易见的，而其他发展则令人震惊。 我们出版第一本SRE书的两年以来特别有趣。 现在正在实施SRE的公司数量以及我们在会议和客户的谈论中关于它的时间已经超出了我们之前的想象。
特别是这种变化 – 围绕SRE的非谷歌生态系统的快速扩张 - 是最令人兴奋的，但它使得预测SRE行业的未来变得更加困难。 尽管如此，我们自己在谷歌的SRE工作中，开始看到一些可能为行业未来提供概述信息的趋势。 本章代表了我们分享 自己以及全球SRE同事所看到的，以及迄今为止所努力得出的结论。
真理不言而喻
对未来有任何意义的唯一方法就是从基本的原则开始，然后继续前进。接下来的事情应该是没有争议的。其他的就没那么多了。然而，在任何情况下，这些原则都是基于我们在世界上看到的真实事物。
可靠性是最重要的特征
当我们断言“可靠性是任何系统最重要的特征”时，人们通常不会进行反驳，只要我们小心地指出“可靠性”通常覆盖很广的领域。
很容易找出充足的证据：
- 如果一个系统不可靠，用户就不会信任它。
- 如果用户不信任一个系统，当有其他的选择时，他们不会使用它。
- 由于所有软件系统都受网络效应控制，如果一个系统没有任何用户，那么它就一文不值。
- 你就是衡量标准，因此请仔细选择您的指标。
决定你的可靠性是用户，而不是监控，
系统的价值与它的用户息息相关，因此可靠性的唯一衡量标准的关键就是用户体验的可靠性。如果你的用户怀疑是你的平台造成了他们的故障，在这时告诉他们“我们的监控一切正常，因此问题一定出现在你们那边”，不会让用户的情绪好转，用户体验到你的系统不稳定，当你和你的竞争对手之间做出选择时，客户会想起这一点。（这种现象被称为峰值规则）
你的监控，日志和报警只有帮助你赶在客户之前发现问题的情况下才有价值。
如果你运行一个平台，那么可靠性就是合伙人
如果其他人使用你系统的唯一方式是通过可视化用户界面（例如，网页），并且你的系统仅由真人（而不是机器）使用，那么你用户体验的可靠性几乎只与你作为一名SRE所从事的保障系统可靠性的工作有关。
但是，一旦你添加了一个API，并且你的一些“用户”实际上是其他机器，那么你的运行平台的规则就已经改变了。
当您的产品充当平台时，用户体验的可靠性并不局限于您的选择。 可靠性就成为一种合作关系。 如果您的用户在您的平台上构建或运行的系统永远不会达到99％以上的可靠性 - 即使您以99.999％的可靠性运行您的平台 - 那么他们的最佳案例体验是98.99901％。
这些用户的选择直接影响他们的体验，并与您的服务相关联。你可能不会喜欢，但他们会让你对他们所经历的一切负责，即使这不是你的错。
任何重要的东西最终都会成为一个平台
由于系统的价值随着使用它的人数的增加而增加，因此你需要找到访问其他大型已建立的用户池的方法。当您吸引更多的用户时，其他软件系统也想要接触您的用户。
这是其他公司开始让他们的机器通过API与您的机器通信的时候。如果您的系统非常流行，那么集成是您的发展中不可避免的一步。
即使您决定不关心其他用户社区，并决定永远不会创建机器可使用的API，您仍然无法避免这种未来。 其他人会简单地把您的UI包装到机器API中并使用它。 唯一的区别是你无法控制结果。
一旦您的系统成为大量用户的网关，它就变得很有价值。 APIs – 官方或非官方的 – 将成为您未来的一部分。
当你的客户遇到困难时，你必须放慢速度
当你的客户遇到困难时，他们的挫败会变成对你的摩擦。即使您没有传统的支持模式(故障工单、电子邮件、电话等)，您仍然会花时间通过StackOverflow，甚至Twitter、Facebook和其他社交平台来处理问题和回复投诉。
无论你投入到帮助用户度过难关的精力有多少，你都不能投入于改进你的系统。我们已经看到许多团队(和公司)允许他们的时间慢慢地被中断/修复客户问题所占用——留下一个不断减少的创新预算。这些团队被辛劳所消耗。
一旦进入这种状态，就很难发现(见第6章)。你可能在读这篇文章的时候会想，哎呀，我只是内部平台团队的一员。这对我不适用!
我们很抱歉地通知您，这对您来说是加倍适用的!在您的案例中，您的客户是您公司系统的消费者。
这就引出了下一个结论。
你需要和你的客户一起练习SRE
如果你想让你的客户使用你的平台来设计和运行可靠的系统，你必须教会他们如何操作。是的，这也包括你的内部客户。仅仅因为您在内部平台团队工作并不意味着您可以逃离这个动态过程——事实上，您最有可能首先遇到它。
即使您可以将这些信息完美地提炼成高度伸缩的一对多表单(书籍、博客帖子、架构图、视频等)，您仍然需要一种方法来确定要包含哪些内容和培训。随着你平台的成长和完善，这些经验教训将会改变。您总是需要一种方法来防止这些资源变得陈旧。
学习这些经验的最好方法就是和你的用户一起“do SRE”。
这并不一定意味着您需要为用户的系统创建页面调度程序，但您确实需要承担通常导致页面调度程序切换的大部分工作（意味着系统已满足某些最低可行的可靠性要求）， 至少是您用户的代表性样本。
怎样: 和你的用户一起实践SRE
与用户一起实践SRE的想法似乎有点令人生畏，你读这本书的原因可能是你自己都不知道该如何去做。不过不同担心，两者可以同时进行，实际上，前者可以帮助你加速后者。
下面是我们要遵循的步骤，它对我们很有帮助，并且我们认为也同样会对你有所帮助。
步骤一: SLOs and SLIs Are How You Speak
你希望你的用户认为你的系统是可靠的。否则，你就有可能失去他们。因此，你应该非常关心他们是如何形成这些观点的。它们度量什么？它们是如何度量？最重要的是，这些度量对用户做出了什么承诺？
如果您的用户度量SLIs并对SLOs保持警惕，并且与你共享这些度量值，您的生活会好得多。否则，你会花费很多的精力在这样的对话中:
用户：API调用X通常需要时间T，但现在需要时间U.我认为你们出现了一些问题。 请仔细研究并立即回复我。
你：这种表现符合我们的预期，一切看起来都很正常。 如果API调用X确实需要这么长时间，这有问题吗？
用户：我不清楚。 这个过程通常不需要这么长时间，所以中间发生了一些变化，我们对这种变化感到担忧。
这场对话将会循环下去，并且永远不会有一个满意的结果。你要么花费大量时间去说服你的用户这不是他们应该关心的，要么您将花费大量时间在这个变化产生的根本原因上，以便你可以说服你的用户他们没必要关心。在任何一种情况下，你都花费了很多精力，而这些精力本可以用在其他地方。
这个问题的根本原因是用户没有使用SLO来确定他们是否应该关心他们所看到的性能。 他们只是注意到一个无法解决的问题，你的用户将不可避免地发明一个而不会告诉你，直到你不满足它！ 你更喜欢这个对话：
用户: 我们对应用程序FOO的SLO消耗得太快，应用程序处于危险之中。SLIs的 X和Y都呈现断崖式下跌，它们都依赖于你的API X。
你：好的。让我看一下API X是如何在我的系统中执行的/或它的具体表现。
这是一个更有效的对话，因为：
（a）它只会在SLO受到威胁时才会发生。
（b）它依赖于相互理解的度量（SLIs）和目标（SLOs）。
如果你使用SRE实践来运行你的系统，那么你在内部说的是SLOs。如果你的用户也讲SLO，你的日子会更好过，你的用户也会更舒心，因为这会让你们更容易对话。
我们建议你做一个简单的练习，让你与用户的工作关系变得更好: 与用户坐下来，解释一下SLOs、SLIs和错误预算——尤其是如何在团队中实践它们。然后帮助他们用这些术语描述他们在你的平台上构建的关键应用程序。
步骤二: 审核监控和构建共享仪表板
一旦您的用户为他们的应用程序选择了一些基本的SLOs，下一个问题就是他们是否度量了正确的东西来确认他们是否达到了这些目标。您应该帮助他们确定他们使用的度量是否合适。
根据我们的经验，您的用户度量（和报警）的事物中有多达一半对他们的SLOs没有任何影响。 当你向他们指出这一点时，你的生活将变得更好，他们会关闭令人讨厌的报警。 这对他们来说意味着更少的页面，对你而言也是如此！
其余的度量是有用的候选SLIs。帮助您的用户聚合这些度量数据，以计算他们的SLOs。
一旦开始这个练习，您很快就会很快知道SLOs的一部分已经被发现——没有相关的度量方法来说明这些维度的任何有用之处。您还应该帮助客户覆盖他们SLOs的这些部分。
现在，你的客户可以开始在你的平台上谈论他们的应用程序的SLO性能了。
最后，与客户构建一组共享的SLO仪表板。您应该能够看到他们的应用程序SLOs，并且应该共享您所拥有的任何与他们体验您的系统性能相关的信息。您的目标是，当您的客户因为他们的SLO似乎受到威胁而联系您时，您都不必交换太多额外的信息。所有这些信息都应该在共享的监控中。
步骤三: 测量和协商
一旦你把测量数据整理出来，你应该收集一两个月的数据。准备好面对你的客户可能会突然觉醒的可能性。他们认为应用程序运行在“五个9”(99.999%;每个人都认为他们得到了五个9)的情况下，如果与他们闪亮的新SLOs相比，可能只有99.5%-99.9%。
在最初的震撼消失之后，是指出他们的用户并不是一直在大喊大叫的好时机，所以他们可能从来不需要他们真正没有得到的5个9。
问题的关键在于，他们的用户对应用程序的性能有多满意?如果他们的用户满意，并且没有证据表明提高性能或可靠性会增加用户的采用/保留/使用，那么您的目的就达到了。你应该定期问自己这个问题，以确保你的预算和优先事项是正确的。(有关此主题的更深入的讨论，请参阅第2章。)
如果客户认为他们仍然需要做得更好，那就继续下一步。
步骤四: 设计评审和风险分析
与客户坐下来，真正了解他们的应用程序是如何设计和操作的。他们是否有隐藏的单点故障（SPOFs）？他们有部署和回滚的预案吗？基本上，对你自己的内部应用再进行同样的练习。
接下来，根据每个项目消耗的错误预算的大小对您找到的问题进行排名。(阅读更多关于如何在Google云平台博客上执行此操作的信息。)，注意客户选择修复哪些项目以“赚取他们想要的9”(例如，从99.5%调整到99.9%)。
您从这些评论中所学到的知识将告诉您：
- 您的客户如何使用您的平台
- 这样做会造成什么样的可靠性错误？
- 当他们试图改进时，会如何进行权衡。
此练习还将帮助您的客户围绕他们当前应用程序应该具有的可靠性来设定切合实际的期望。 他们的期望会影响他们的看法，因此恰当地设定期望只会有助于赢得和保持他们的信任。
步骤五: 练习,练习,再练习
最后一步是为您的客户创建一些操作严谨性。 模拟故障（不幸之轮练习，故障与恢复测试，纸质游戏日等）。
在团队之间建立健康的肌肉记忆，以便在危机期间进行有效的沟通。 这是建立信任，降低MTTR以及了解一些奇怪操作极少cases好方法，您可以将其作为增强功能集成到平台功能中。
当故障发生后，不要只与您的客户分享您的结论。 实际上进行一些故障复盘。 这样做也将建立信任并教给你一些宝贵的经验教训。
需要考虑和训练的
在一小部分客户之外，很快就不可能执行以上这些步骤。请不要尝试将此模型扩展到每个人身上。相反，你应该做一些有原则的决定来决定如何做出选择。以下是一些常见的方法:
收入范围
选择占你收入XX%的最小客户数量。如果你的收入主要集中在几个大客户身上，那么这可能是你的正确选择。
功能范围
选择覆盖平台特性XX%以上的最小客户数量。如果你运行一个高度多样化的平台，有很多客户做着不同的事情，那么这种方法将帮助你避免意外。
工作范围
您的平台的使用可能由几个不同的用例或客户类型主导。 也许这些类型的客户中没有一个是占主导地位的，但您可以轻松地将他们分类成不同的群组。 在这种情况下，从每个群组中抽取一个或两个客户是获得平台覆盖率并发现用例之间的操作差异的好方法。
无论你选择什么方法，坚持下去。 混合和匹配使用会使您的利益相关者感到困惑，并迅速压垮您的团队
结论
在过去的几年里，SRE的职业和角色已广泛传播到谷歌之外。 尽管我们从未预料到这一点，但我们仍然为之激动不已。 我们或许可以说一些关于我们如何认为该学科将在谷歌内部发展的值得信赖的话，但在外界，这是一个“令人不安又刺激”的主张。
我们非常确定的一点是，当您将SRE原则应用到您的组织中时，您将跨越许多与我们相同的拐点(有些我们没有!)—包括需要在您客户的终点和您的起点之间模糊界限。
在这样的操作深度下与个别客户打交道，对我们来说是一个很有价值的新领域，我们仍在这条道路上走得很远。(你可以在线关注谷歌云平台博客。)然而，我们走得越远，我们就越确信这是你们也需要经历的。