由戴夫·伦森
与Betsy Beyer，Niall Richard Murphy和Liz Fong-Jones撰写
从我们开始在Google实践SRE至今已有14年了。回顾过去，当时发生的某些事情似乎显而易见，而其他事态发展令人震惊。自我们的第一本SRE书出版以来的过去两年中，特别有趣。现在，实践SRE准则的公司数量以及我们在会议上和与客户讨论该问题所花费的时间已经超出了我们以前的想象。
尤其是这种变化-围绕SRE的非Google生态系统的迅速扩展-是最令人振奋的发展，但它使预测SRE行业的未来变得更加困难。尽管如此，在我们自己在Google的SRE工作中，我们开始看到一些趋势，这些趋势可能会为该行业的未来提供一个轮廓。本章介绍了我们与全球SRE同事分享的经验以及迄今为止所得出的结论。
充分利用未来的唯一方法就是从一系列原则开始并向前迈进。接下来的一些事情应该没有争议。不是很多。不过，在每种情况下，这些原则都是基于我们在世界上看到的真实事物。
可靠性是最重要的功能
当我们断言"可靠性是任何系统的最重要特征"时，人们通常不会与我们意见相左。只要我们注意指出"可靠性"通常涵盖广泛的领域即可。
论据很简单:
-
如果系统不可靠，用户将不会信任它。
-
如果用户不信任系统，则在选择时将不会使用该系统。
-
由于所有软件系统都受网络效应的支配，因此，如果一个系统没有用户，那么它一文不值。
-
您就是要衡量的对象，因此请仔细选择指标。
您的用户,而不是您的监控来决定您的可靠性
由于系统的价值与用户有关，因此，唯一重要的可靠性衡量标准就是用户如何体验可靠性。如果您的用户担心您的平台是造成他们不稳定的原因，那么告诉他们"我们的监控看起来很好；问题一定在您自己身上"不会使他们变得脾气暴躁。他们觉得您的系统不稳定，这就是当您和竞争对手之间进行选择时他们会记住的事情。(这种现象称为峰值规则)。
您的监控，日志和警报仅在帮助您先于客户发现问题之前，才有价值。
如果您运行平台，那么可靠性就是合作伙伴
如果某人使用您的系统的唯一方法是通过可视用户界面(例如网页)，并且您的系统仅由实际的人(而不是机器)使用，那么您的可靠性用户体验几乎完全取决于您作为SRE保持系统健康所完成的工作。
但是，一旦添加了API，并且某些"用户"实际上是其他机器，则您正在运行平台，并且规则也会更改。
当您的产品扮演平台时，用户体验的可靠性不仅限于您做出的选择。可靠性成为一种伙伴关系。如果您的用户在平台上构建或运行的系统永远无法获得高于99％的可用性-即使您以99.999％的可用性运行平台-则他们的[best-case体验](http: //bit.ly/2HbIiDl)是98.99901％。
这些用户做出的选择将直接影响他们的体验并与您的服务相关联。您可能不喜欢它，但是即使他们不是您的错，他们也会让您对自己经历的一切负责。
一切最终都会成为平台
由于系统的价值会随着使用该系统的人数的增加而增加，因此，您将想方设法找到其他庞大的已建立用户池。随着您吸引更多用户，其他软件系统也将希望吸引您的受众。
这是其他公司开始使他们的机器通过API与您的机器对话的时候。如果您的系统甚至不受欢迎，那么集成是您发展的必然步骤。
即使您决定不关心其他用户社区，并且决定从不创建机器消费的API，您仍然无法避免这种未来。其他人只会将您的UI包装到机器API中并使用它。唯一的区别是您将无法控制结果。
一旦您的系统成为通往大量用户的门户，它就变得很有价值。API(正式或非正式)将成为您未来的一部分。
当客户遇到困难时，您必须放慢速度
当您的客户遇到困难时，他们的挫败感会为您带来磨擦。即使您没有传统的支持方式(麻烦的工单，电子邮件，电话等)，您仍然会花时间对问题进行分类，并通过StackOverflow甚至Twitter，Facebook和其他社交平台来答复投诉。
无论您投入什么精力来帮助用户度过难关，都无法投入精力来改善系统。我们已经看到许多团队(和公司)允许他们的时间被打破/修复客户问题所占用，从而使创新预算不断减少。这些团队被琐碎工作消耗。
一旦处于这种状态，就很难进行挖掘(请参阅第6章)。更好的计划是领先于即将到来的工作。您可能正在阅读此书，并在想，Gee，我在一个内部平台团队中。这不适用于我！
很抱歉通知您，此"加倍"适用于您！在您的情况下，您的客户就是您公司内部系统的客户。这使我们得出下一个结论。
您需要与客户一起练习SRE
如果您希望客户使用平台设计和运行可靠的系统，则必须教他们如何做。是的，这也包括您的内部客户。仅仅因为您在内部平台团队中工作并不意味着您会摆脱这种动态状态-实际上，您最有可能首先遇到这种动态情况。
即使您可以将信息完美地提取为高度缩放的一对多形式(书籍，博客文章，体系结构图，视频等)，您仍然需要一种方法来
我们坚持不言而喻的真理
找出要包括的内容和培训。随着您成长和改进平台，这些课程将改变。您将始终需要一种方法来防止这些资源过时。
学习这些课程的最好方法是与客户"做SRE"。
这不一定意味着您需要为客户的系统使用呼叫，但是您确实需要承担通常导致呼叫切换(意味着系统已满足某些最低可行可靠性要求)的大部分工作。至少是您的用户的代表性样本。
如何:与您的客户SRE
与客户一起进行SRE旅程的想法似乎有些艰巨。您可能正在阅读这本书，因为您不确定自己如何走路！别担心。可以同时做两个。实际上，前者可以帮助您加速后者。
这是我们要遵循的步骤。它们对我们来说效果很好，我们认为它们对您也很有用。
第1步:SLO和SLI是您的说话方式
您希望客户将您的系统视为可靠的。否则，您可能会失去它们。因此，有理由推论，您应该非常在乎它们如何形成这些意见。他们测量什么？他们如何衡量？最重要的是，他们向他们的客户做出什么承诺？
如果您的客户测量SLI和关于SLO的警报，并且与您共享这些测量，那么您的生活就会好很多。否则，您将在以下对话中花费大量精力:
客户: API调用X通常花费时间T，但是现在花费时间U。我认为您遇到了问题。请调查一下，并立即与我联系。
您: 该性能似乎符合我们的期望，并且一切看起来都很好。API调用X花这么长时间会不会有问题？
客户: 我不知道。通常不需要很长时间，因此很明显有些变化，我们对此感到担心。
这次谈话将循环往复，永远不会获得满意的答案。您将花费大量时间说服客户不要理会他们，或者您将花费大量时间从根本上引起更改，以便说服客户不要理会。无论哪种情况，您都将花费很多精力在其他地方使用。
此问题的根本原因是客户没有使用SLO来确定他们是否应该关心他们所看到的性能。他们只是注意到一个意想不到的变化，并决定担心它。请记住，在没有明确的SLO的情况下，您的客户将不可避免地发明一个，并且直到您没达到这个SLO才告诉您！您宁愿进行以下对话:
客户: 我们对于应用程序FOO的SLO燃烧得太快了，应用程序处于危险之中。SLI X和Y似乎从悬崖上掉下来了。它们都取决于您的API X。
您: 好的。让我研究一下API X在我们系统中的运行情况和/或特定于您的运行情况。
这是一个更加富有成效的对话，因为(a)仅在SLO受到威胁时才会发生，并且(b)它依赖于相互理解的指标(SLI)和目标(SLO)。
如果您正在使用SRE实践来运行系统，那么您内部就是在说SLO。如果他们也说SLO，那么您的生活会更好，客户也会更加快乐，因为这使你们两个之间的交谈变得更加容易。
我们建议您做一个简单的练习，以改善与客户的工作关系:与客户坐下来。解释SLO，SLI和错误预算-尤其是您在团队中的实践方式。然后帮助他们以这些术语描述他们在平台上构建的关键应用程序。
第2步:审核监控和构建共享仪表板
一旦您的客户为他们的应用选择了一些基本的SLO，下一个问题就是他们是否正在测量正确的事物以确定他们是否满足这些目标。您应该帮助他们确定他们使用的测量是否合适。
根据我们的经验，您的客户要衡量(和发出警报)的事情中，多达一半对他们的SLO零影响。当您向他们指出这一点时，您的生活会更好，他们会关闭令人讨厌的警报。对于他们和您来说，这意味着更少的呼叫！
其余的测量值是有用的候选SLI。帮助您的客户组合这些度量以计算其SLO。
一旦开始此练习，您将很快发现SLO的某些没有被覆盖的部分-没有适当的度量值可以说出这些维度的有用信息-被"发现"了。您还应该帮助客户涵盖其SLO的这些部分。
现在，您的客户可以开始在您的平台上谈论他们的应用程序的SLO性能。
最后，与您的客户构建一组共享的SLO仪表板。您应该能够看到他们的应用程序SLO，并且应该共享与他们体验系统性能有关的任何信息。你的目标是
每当您的客户因为他们的SLO受到威胁而与您联系时，您不必交换太多其他信息。所有这些信息都应该在共享监控中。
第3步:衡量并重新谈判
整理好测量值后，您应该收集一个月或两个月的数据。为您的客户的猛然觉醒做好准备。与他们闪亮的新SLO相比，他们认为应用程序以"五个9"(99.999％；每个人认为他们得到五个9s)运行的应用程序只能达到99.5％-99.9％。
在最初的冲击消散之后，这是个绝佳的时机，指出他们的用户并没有一直在大喊大叫，因此他们可能永远不真正需要从来没有得到的五个9。
关键问题是，他们的用户对应用程序的性能有多满意？如果他们的用户感到满意，并且没有证据表明提高性能或可用性会增加用户的采用/保留/使用率，那么您就完成了。您应该定期问自己这个问题，以确保您的预算和优先级仍然正确。(有关此主题的更深入的处理，请参阅第2章。)
如果客户认为他们仍然需要使事情变得更好，请继续下一步。
第4步:设计审查和风险分析
与您的客户坐下来，真正了解他们的应用程序是如何设计和操作的。他们是否有任何隐藏的单点故障(SPOF)？他们的部署和回滚是手动的吗？基本上，请执行与内部应用程序相同的练习。
接下来，根据每个项目消耗的错误预算来对找到的问题进行排名。(有关更多操作方法的信息，请访问Google Cloud Platform博客。。请注意客户选择修复的项目，以"赚回9" (例如，从99.5％变为99.9％)。您将从这些评论中学到的内容将告诉您:
-
您的客户如何使用您的平台
-
这样做时会犯什么可靠性错误
-
他们在尝试改善时会选择哪些权衡
此练习还将帮助您的客户围绕他们在当前应用程序中应经历的可靠性设定切合实际的期望。他们的期望会影响他们的看法，因此适当地设置他们只会有助于赢得并保持他们的信任。
第5步:练习，练习，练习
最后一步是与您的客户建立一些严格的操作。练习模拟的问题(灾难轮演，灾难和恢复测试，呼叫游戏日等)。
在团队之间建立健康的肌肉记忆，以在危机期间进行有效沟通。这是建立信任，降低MTTR并了解可作为增强功能集成到平台功能中的怪异操作边缘情况的好方法。
当确实发生事件时，不要仅仅与客户分享您的事后报告。实际进行一些联合事后总结。这样做还将建立信任，并教给您一些宝贵的经验教训。
深思和纪律
超过一小部分客户将很快无法执行这些步骤。请不要尝试将此模型扩展到所有人。相反，请就如何选择做出一些原则性的决定。以下是一些常用方法:
收入覆盖率
选择最少的客户数量以占您收入的XX％。如果您的收入主要集中在几个大客户上，那么这可能是您的正确选择。
功能覆盖
选择最少数量的客户来覆盖您平台功能的XX％以上。如果您运行高度多样化的平台，并且有很多客户在做很多不同的事情，那么这种方法将帮助您避免意外。
工作量覆盖
您平台的使用情况可能由几个不同的用例或客户类型决定。在这些类型中，也许没有单个客户占主导地位，但是您可以轻松地将它们归为一组。在这种情况下，从每个同类群组中抽样一个或两个客户是获取平台覆盖范围并发现用例之间运营差异的一种好方法。
无论选择哪种方法，都请坚持下去。混合和匹配将使您的涉众困惑，并迅速使您的团队不知所措。
结论
在过去的几年中，SRE的职业和角色已广泛传播到Google之外。尽管我们从未期望过这一点，但是我们对此感到非常兴奋。对于我们认为该学科将如何在Google内部发展，我们也许可以说些可信的方法，但是在大千世界，这是"令人不舒服的兴奋的"提议。
我们非常确定的一件事是，当您在组织中采用SRE原则时，您将遇到许多我们曾经做过的相同的拐点(有些还没有！)–包括需要在各个地方之间进一步划分界限您的客户结束了，您从哪里开始。
在这种运维深度级别上与单个客户进行互动对于我们而言是一个令人振奋的新领域，而我们仍处在前进的道路上。(您可以在线访问Google Cloud Platform Blog。但是，我们走的越远，我们就越确信这也是您需要采取的旅程。