本章描述的理念整合起来就成为Google SRE广泛接受和遵循的监控与警报设计哲学。虽然这个设计哲学有一定理想性，但是书写和评审某个新警报时可以依赖的好方法。该哲学同时有助于鼓励团队在解决问题时向正确的方向进行。

当为监控系统和警报系统增加新规则时，回答下列问题可以帮助减少误报∶

● 该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生或者已经发生的用户可见故障?

● 是否可以忽略这条警报?什么情况可能会导致用户忽略这条警报，如何避免?

● 这条警报是否确实显示了用户正在受到影响?是否存在用户没有受到影响也可以触发这条规则的情况?例如测试环境和系统维护状态下发出的警报是否应该被过滤掉。

●收到警报后，是否要进行某个操作?是否需要立即执行该操作，还是可以等到第二天早上再进行?该操作是否可以被安 全地自动化?该操作的效果是长期的，还是短期的?

● 是否也会有其他人收到相关的紧急警报，这些紧急警报是否是不必要的?

以上这些问题其实反映了在应对紧急警报上的一些深层次的理念∶

●每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致"狼来了"效应。

● 每个紧急警报都应该是可以具体操作的。

● 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。

● 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。

从这种角度出发，我们可以得出以下结论∶如果某个紧急警报满足上述四点，那么不论是从白盒监控系统还是黑盒监控系统发出都一样。最好多花一些时间监控现象，而不是原因。针对"原因"来说，应该只监控那些非常确定的和非常明确的原因。

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

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

本章描述的理念整合起来就成为Google SRE广泛接受和遵循的监控与警报设计哲学。虽然这个设计哲学有一定理想性，但是书写和评审某个新警报时可以依赖的好方法。该哲学同时有助于鼓励团队在解决问题时向正确的方向进行。

当为监控系统和警报系统增加新规则时，回答下列问题可以帮助减少误报∶

● 该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生或者已经发生的用户可见故障?

● 是否可以忽略这条警报?什么情况可能会导致用户忽略这条警报，如何避免?

● 这条警报是否确实显示了用户正在受到影响?是否存在用户没有受到影响也可以触发这条规则的情况?例如测试环境和系统维护状态下发出的警报是否应该被过滤掉。

●收到警报后，是否要进行某个操作?是否需要立即执行该操作，还是可以等到第二天早上再进行?该操作是否可以被安 全地自动化?该操作的效果是长期的，还是短期的?

● 是否也会有其他人收到相关的紧急警报，这些紧急警报是否是不必要的?

以上这些问题其实反映了在应对紧急警报上的一些深层次的理念∶

●每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致"狼来了"效应。

● 每个紧急警报都应该是可以具体操作的。

● 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。

● 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。

从这种角度出发，我们可以得出以下结论∶如果某个紧急警报满足上述四点，那么不论是从白盒监控系统还是黑盒监控系统发出都一样。最好多花一些时间监控现象，而不是原因。针对"原因"来说，应该只监控那些非常确定的和非常明确的原因。

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

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