监控系统的长期维护

在现代生产环境中，监控系统需要跟随不断演变的软件一起变化，软件经常重构，负载特性和性能目标也经常变化。现在的某个不常见的、自动化比较困难的警报可能很快就会变成一个经常触发、需要一个临时的脚本来应对的问题。这时，某个人应该去寻找和消除背后的根源问题：如果这种解决办法不可行，那么这条警报的应对就必须要完全自动化。

关于监控系统的设计决策应该充分考虑到长期目标。今天发出的每个紧急警报都会占用优化系统的时间，所以经常会牺牲一些短期内的可用性和性能问题，以换取未来系统性能的整体提升。以下是两个具体的案例。

Bigtable SRE：警报过多的案例

Google 内部的基础设施通常提供某个SLO（参见第4章），并且伴随有相应的SLO监控。很多年以前，Bigtable SLO是基于某个假想的客户端的平均性能得出的。由于Bigtable和底层存储技术栈中的一些问题，平均性能受很大的“长尾”所影响：请求中最差的5% 比其他的请求要慢很多倍。

当接近SLO目标的时候，系统会发出E-mail警报；当低于SLO目标时，系统则会发出紧急警报。这两种警报一旦触发都是数量巨大的，将消耗工程师非常多的时间来处理：团队花费了很多时间来甄别每条警报，以便找出那些真正可以应对的警报。同时，我们经常会错过那些真正影响用户的警报，因为大部分的警报都不会影响用户。很多紧急警报其实并不紧急，因为基础设施中存在一些大家都知道的问题，所以这些警报经常没人回复，或是回复得很消极。

为了解决这个问题，团队采用了三阶段方式：首先，在重点提升Bigtable性能的同时，团队临时将SLO目标降低，采用了请求延迟的75%百分位作为SLI。同时关闭了E-mail警报，因为数量巨大，一个一个检测是不可能的。

该策略给团队带来了喘息空间，提供了一些时间修复Bigtable的长期问题，以及底层的存储技术栈，而不是不停地修复一些战术性问题。on-call工程师可以真正做一些事情，而不是整天被紧急警报打断。最终，通过对警报策略的临时性调整使得团队可以更好地优化服务，在未来提供更好的服务质量。

Gmail：可预知的、可脚本化的人工干预

在Gmail服务的早期，整个服务是基于一个分布式进程管理系统构建的，称为“Workqueue”，该系统最初是为搜索索引批处理任务构建的。Workqueue针对长期运行的进程做了一些适应，最终应用于Gmail。但是相对不透明地调度代码中的某些Bug一直没有被消除。

当时，Gmail的监控系统会在某个任务被Workqueue系统干掉时发出警报。即使是在当时，这种配置也很差劲：Gmail有几千个任务，每个任务都代表了百分之几的用户。虽然我们非常关注Gmail用户的体验，但是这样的警报规则是不可持续的。

为了解决这个问题，Gmail SRE构建了一个工具来操作调度器尽量减小对用户的影响。整个团队就这个问题进行了多次讨论：是否应该自动化整个方案？但是一些团队成员坚持认为开发这样的自动化方案会影响对真实问题的最终修复。

团队中出现的这种冲突是合理的，这反映出团队自我约束方面的信任危机：一些团队成员想要实现某种“hack”从而为真正的修复方案争取时间，而另外一些成员则担心实现这个“hack”会使得真正的修复优先级无限降低。这种担心是正确的，确实这种打补丁的形式会造成无法维护的系统债务。管理者和技术领导者在这个过程中应该起到直接作用，在紧急警报带来的压力减轻之后应该继续支持和优先处理那些长期修复问题的工作。

任何一个可以死记硬背，或者基于某种公式的紧急警报的响应都应该引起注意。团队中一部分人不愿意打补丁的原因是因为他们不相信未来能够处理这些技术债务。这是一个值得与上级讨论的问题。

长跑

上面的Gmail和Bigtable的例子有个共同点：短期与长期的可用性的冲突。经常，通过一些“暴力”因素，可以使一个摇摇晃晃的系统保持一定的高可用性。但是这种方案通常是不能持久的，而且这经常依赖于某个团队成员的个人英雄主义。短期内，接受某种可控的可用性的降低可以换取一些系统长期性的提升。将所有紧急警报作为一个整体来审视是很重要的，要考虑当前的紧急警报的级别是否对未来的一个高可用、高可靠性的系统有帮助。Google管理团队会按季度进行紧急警报的频率统计（经常以每次on-call轮值发生的故障数量统计，某个故障可能由多个紧急警报组成），保证每个决策者都理解目前的运维压力，以及系统的健康状况。