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

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

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

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

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

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

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

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

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

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

健康的监控和警报系统应该是非常简单、易于理解的。紧急警报应该关注于现象，针对原因的一些启发性分析应该作为调试过程的补充，而不应该进行报警。监控的技术栈层面越高，监控现象越容易，但是监控某些子系统（如数据库）的饱和度和性能参数可能要在该子系统内部直接进行。E-mail警报的价值通常极为有限，很容易变成噪声。我们应该倾向于构建一个良好的监控台页面，直接显示所有的非紧急的异常情况。

长远来看，要建立一个成功的on-call轮值体系，以及构建一个稳定的产品需要选择那些正在发生和即将发生的问题来进行报警，设置一个可以实际达到的合理目标，保证监控系统可以支持快速的问题定位与检测。

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

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

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

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

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

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

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

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

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

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

健康的监控和警报系统应该是非常简单、易于理解的。紧急警报应该关注于现象，针对原因的一些启发性分析应该作为调试过程的补充，而不应该进行报警。监控的技术栈层面越高，监控现象越容易，但是监控某些子系统（如数据库）的饱和度和性能参数可能要在该子系统内部直接进行。E-mail警报的价值通常极为有限，很容易变成噪声。我们应该倾向于构建一个良好的监控台页面，直接显示所有的非紧急的异常情况。

长远来看，要建立一个成功的on-call轮值体系，以及构建一个稳定的产品需要选择那些正在发生和即将发生的问题来进行报警，设置一个可以实际达到的合理目标，保证监控系统可以支持快速的问题定位与检测。