我们可能会过度痴迷于正常运行时间。我们实际上可以把服务水平目标（SLOs）定得太高。如果我们一味地追求5-9，我们就有可能影响到我们的团队成员的创新能力。而且我们可能会增加倦怠感。正如Marc Alvidrez在谷歌SRE原书中所说。
"你可能会期望谷歌试图建立100%可靠的服务--那些永不失败的服务。然而，事实证明，过了某一点，增加可靠性对一个服务（和它的用户）来说是更糟而不是更好......用户通常不会注意到一个服务中高可靠性和极端可靠性之间的区别，因为用户体验是由不太可靠的组件主导的，比如蜂窝网络或他们正在使用的设备。简单地说，一个使用99%可靠的智能手机的用户无法分辨出99.99%和99.999%的服务可靠性之间的区别!考虑到这一点， 网站可靠性工程不是简单地将正常运行时间最大化，而是寻求将不可用的风险与快速创新和高效服务运营的目标相平衡，从而使用户的整体幸福感--功能、服务和性能--得到优化。"
但这在现实中是什么样子的呢？你如何在实验和永远在线之间找到正确的平衡？因为消防演习只能让你准备这么多。
Honeycomb的首席开发者倡导者 Liz Fong-Jones在今年的 混沌嘉年华上分享了团队搞砸SLO的三个令人震惊的时刻。这是一个关于考虑什么时候应该 炸掉它的教训。或者至少要更新它。以及如何让你的错误预算成为SLO的阴阳。
我们不希望事情经常出错，但正如Fong-Jones所展示的，中断和失败的实验可以成为不定期的学习机会。
SLO是对你的用户很重要的东西
SLO策略的一部分是减少你的 "呼叫器负荷"--你不希望在半夜为你的用户并不关心的事情叫醒队友。
Fong-Jones在演讲中首先解释了 什么是SLO--衡量对你的用户有意义的东西的目标指标。"你的目标应该是达到这一水平的可靠性，而不是更多。这样你就不会花钱去追求那些无关紧要的九分之一"。
这一切都始于你对什么是对你的用户有意义的理解。"我们的想法是，你不应该计划100%的正常运行时间。你应该对实际对你的用户有意义的可靠性水平有一些了解，"她解释说。然后，你可以在你的SLO中计划一个允许混乱工程实验的脆弱性水平，并为不可避免的、不可预测的系统行为提供一些回旋余地。
Honeycomb是一个面向DevOps的可观察性工具，它从用户那里获取遥测数据，帮助他们了解他们越来越不可预测的分布式系统。可观察性与传统的监控不同，其目标是收集尽可能多的原始数据，然后利用这些数据来探索系统的实时行为，而不是为特定场景预先定义警报和数据收集。正如Honeycomb的首席开发者布道者Jessica Kerr 去年在Strangeloop所说的那样，"Observability把监控变成了一个整体"。
为了实现这一目标，Fong-Jones说："我们允许人们对该数据的每一列进行搜索和查询，不管有多少cardinality，不管有多少列"。Honeycomb的SLO与真实的用户旅程和目标相匹配。
例如，他们希望确保Honeycomb产品的主页加载速度相对较快，为250毫秒，以免客户在了解自己的方向时感到沮丧。如果用户试图运行一个查询，应该少于十秒，但Honeycomb团队知道，如果他们不得不点击刷新和重新加载，并不会极大地影响用户体验。但他们的面包和主食是他们不能冒险的遥测摄取。
"对我们来说最重要的是，我们在大多数时候只有一次机会来摄取你的数据，"Fong-Jones说。"我们不想放弃你的客户数据，因为，如果我们放弃了你的客户数据，特别是对于足够多的客户，这些客户将在他们的数据上留下一个巨大的坑，直到最后。"
因此，这个过程就是蜂巢专注于打四九的地方--即99.99%的时间里，用户发送给蜂巢的事件被无错误地摄取，在30天的追踪期内，每个事件的摄取时间小于5毫秒。
这只相当于每个月不到4.5分钟的允许停机时间。这不是一个很大的回旋余地。
除了大多数故障不是100%。蜂巢公司已经设计了它的系统，所以它们只经历部分的退化。
在正常情况下如何在SLO内发货
"在现实中，如果我们有1%的故障，我们有400分钟的时间来修复它，然后我们就会耗尽整个[每月]错误预算。我们仍然在跟踪这个想法，即我们还有多少错误预算，以及我们实现的目标是什么，"Fong-Jones解释说。
现在跟踪误差率并不那么容易。这就是渐进式交付的意义所在。蜂窝网不是向100%的用户推出新功能，而是逐步推出新功能，用功能标志开发设计。它将事情100%出错的风险降到最低，允许团队沿途进行测试以检查预期行为。每次发布都涉及到自动化持续集成测试和人工审查的混合，都是在快速部署周期中进行。
蜂窝网的发布周期也是以绿色按钮合并的方式运行，在一小时内自动到达生产现场，准备时间很短。这牢牢记住了技术工人是真正的知识工作者，这意味着如果他们在部署之间等待的时间太长，他们可能会忘记细节。Fong-Jones说，更快的部署周期，"最大限度地提高了编写变更的人在发布前头脑中的信息量"。每个版本在转入生产之前都要经过逐渐严格的环境。
但事情并不总是这样。正如她所说，"不是每个实验都会成功。总有一些实验会出现灾难性的失败，因此，如果你破坏了你的SLO或者有破坏SLO的危险，知道你该怎么做很重要。
Fong-Jones谈话的其余部分集中在当事情失败时，Honeycomb团队如何能够保持相对平静并继续发货。
几乎是史诗般的失败#1：摄入失败
首先，让我们回到2020年12月。Honeycomb的摄取API服务是由 无状态的 "牧羊人 "工作者运行的，他们通过自定义的JSON API摄取OpenTelemetry格式的数据。由于OpenTelemetry原生支持使用gRPC作为远程过程调用协议，该团队希望从JSON转移到它，这又需要默认绑定一个特权端口。在本地开发者工作站的暂存环境中，一切工作都很顺利。
但是，在生产中，它试图绑定到特权端口，结果全部崩溃。开发者能够停止他的部署，但是，由于Honeycomb还没有在Kubernetes上，没有能力回滚。这意味着任何被破坏的构建都将继续被破坏。而且它仍然是默认的新版本，所以任何新的主机都会试图拉下那个新的破碎的新版本。
"我们无法迅速扩大规模，因为亚马逊的每一个工人都会同时尝试拉动新的二进制文件，然后它将启动二进制文件，二进制文件将崩溃，然后它将显示0%的CPU使用率。"然后，Fong-Jones继续说，亚马逊网络服务把这个0%的CPU解释为扩展得太远，浪费了CPU。
亚马逊网络服务 "会扩大一些其他工作者的规模，甚至从繁忙的工作者中扩大。因此，我们会得到这样一个循环，即有流量从我们正常工作的工作器上移开，转到被破坏的新工作器上。因此，我们处于这种悠悠的循环中，延迟不断上升，因为我们的用户无法获得他们的数据。
在部署停止之前，更新不是只影响到用户，而是最终同时影响到所有的蜂窝用户。
如果他们遵循谷歌SRE书中的建议，既然他们搞砸了他们的SLO，团队应该通过冻结部署来应对。然而，这样做违背了Honeycomb的信念，即部署机器在任何情况下都应该继续工作，因为它应该总是有可能进行可靠性改进。
"相反，需要改变的是，作为一个工程团队，你需要转移你的时间花在哪里。所以你不要只是堆积一堆没有发货的东西，而是要专注于使用你现有的运行部署管道来部署可靠性的改进，"Fong-Jones说。
他们仍然想在AWS作为合作伙伴的最后期限前完成任务，所以他们选择继续发货，但要在一个专门的功能分支。他们为gRPC设置了一套单独的隔离工作者，同时保持原始JSON端点上99.99%的流量流向原始工作者。
几乎史诗般的失败#2：缓冲失败
2021年2月，Honeycomb团队希望解决另一个可靠性问题。该产品使用Apache Kafka进行牧羊人索引工作者和他们的查询工作者之间的解耦。这通过增加依赖性增加了复杂性：例如，如果Kafka中断，他们就无法摄取数据。因此，他们正在用一个新的架构部署Kafka，以及Confluent的一套新技术，并将存储从本地磁盘转移到亚马逊弹性块存储（EBS）。这三者同时进行。
在处理所有新引入的变量时，他们花了两个月的时间在他们的狗粮Docker环境中对所有东西进行了测试--这并不是生产工作负载压力的真正复制品，而是生产规模的三分之一左右。他们知道，一旦投入生产，就会出现混乱的风险，但随之而来的混乱比他们预期的要多得多。
"我们知道在这种情况下会有一些失败的风险，但我们低估了它会有多糟糕。所以我们最终遇到了我们没有预料到的三个不同层面。就像我们知道可能会有一些缩放问题，但我们不断地遇到一个又一个问题。"Fong-Jones说，首先，他们耗尽了每个AWS实例提供给EBS的磁盘带宽数量。然后，他们把每个实例允许进出的网络容量的网络维度炸开了。
他们意识到，他们部署的实例大小不正确，所以他们修复了这一点，但事情仍在发生变化。他们运行得很好，但当他们开始复制数据时，实例就会崩溃，亚马逊说有人终止了这个实例，但没有人终止。他们意识到他们必须再次默认一个安全的配置，保持在本地SSD和Intel上。他们部署的一个变化是将旧的数据转移到Amazon S3。
最后，他们 又等了10个月，等待AWS Graviton2存储实例的发布，才觉得有足够的安全感来做这些动作。因为他们当时意识到，"对我们来说，为了追逐一小笔钱而烧掉我们的人是不值得的"。
Fong-Jones继续说，这并不是从那个真正推动Honeycomb进入2022年的泥潭中得到的唯一教训："即使你预计到做出改变可能会有一些混乱，你也应该始终有一个机制和安全绳可以拉，说，'你知道吗？这不是按计划进行的。我们需要从实验中退回来，尝试别的东西。我们需要先照顾好我们的人，因为尽管我们在服务方面没有搞砸我们的SLO--我们通过英雄主义保持了我们的SLO正常工作，但人类的代价是不值得的。"
蜂巢团队意识到，一些队友整日不眠不休地试图修复它。因此，他们确保每个人都知道他们应该为自己的家庭支出食品交付，以减少一个担忧。然后他们重申了这样的期望：如果有什么事情看起来不对，或者他们需要把事情交给别人去做，以便当之无愧地休息一下，每个人都应该说出来。毕竟， Honeycomb的核心价值是透明、自主、实验和亲切、直接的反馈，所有这些都在这次试验中得到强调。
几乎史诗般的失败#3：查询失败
最近，他们意识到Honeycomb在AWS Lambda按毫秒计费方面有 "极端的成本"，而性能并不在他们预期的范围内，遇到了他们可以扩展的限制。 AWS刚刚宣布，它将允许在11个功能中使用64位ARM处理器的Graviton2。
该团队一开始就对现有的和新的进行了50/50的A/B测试。正如Fong-Jones所描述的那样。"事实证明，在一个巨大的工作负载上做这么冷的事情，而这个工作负载是流式的容量[是]不是一个好主意。因此，我们直接进行了50%的测试，结果马上就在我们面前炸开了锅--延迟上升了三倍。"
但是，这一次，一切都没有失去，因为它在LaunchDarkly中被标记为功能。他们没有冒着SLO的风险，因为他们能够在大约20秒内迅速回滚并补救影响，将有问题的流量降至1%。
"她解释说："因此，如果你有功能标记，这种实验就会变得正常和常规，因为它确实使你能够在某些方面进行迭代，知道你在出错的情况下有一个出路，并知道你对你能影响的用户数量有一个上限。
他们将实验向前推进了几个百分点，到演讲的时候，他们已经达到了30%的用户。每一步都是为了获得更多关于如何安全前进的反馈。
Fong-Jones用学习骑自行车来作比喻。你走得越慢，越犹豫，你就越有可能失去平衡。"但是，如果你继续前进，取得进展并保持势头，这意味着你将处于一个更稳定的状态，而不是你冷不丁地停下来，然后每次都要从头开始"。
通过利用功能标志或隔离出更多的实验性流量，她说你能够分散风险，以改善客户体验。
归根结底，SLO只是一个数字。
Fong-Jones警告说，黑天鹅事件可能而且将会发生，但这不应该阻止你进行实验。
"你的SLO在一天结束时，只是一个数字。客户的快乐和客户的满意才是最重要的。她说："客户会理解，他们宁愿容忍一点点不可靠，也不愿意让他们所有的客户数据在互联网上被泄露。
这种满意度始于客户、工程师和主要利益相关者之间的讨论，以了解什么是真正重要的。一个SLO只是更广泛的社会技术系统的反映。
记住：冒着打击你的SLO的风险，最终可能会使你的系统、流程和团队更加强大。这些实验和测试实际上可以发现未知的风险来源，否则你就不会发现，直到为时已晚。通过不断验证你的基础设施，你能够为将来达到你的SLO做好准备。
同时，继续寻找那些不定期的学习机会。
