正体是原文中的内容，斜体是我个人的想法。雷竞技最新网站内容和原文不一定完全对应，原文的翻译可以参考这篇，本文编写后也通过翻译进行了一些校对，确保没有理解错作者的意思，十分感谢译者。

文章中涉及到的一些名词：

Summary

如何设置告警规则，或者要设置哪些告警规则，才能让我们更愉悦的值班：

Introduction

作者对告警和处理告警的观点：

以此为标准，设置告警规则时需要审视一下这些问题：

当然如果都能做到未免太理想化，不过作者下面提供了一些技巧可以帮助我们更接近这个目标。

Monitor for your users

作者将监控分为两类，称之为「基于症状的监控」，与之相对的是「基于原因的监控」。作者认为监控的关注点应该是用户，例如用户其实并不会关心我们的 MySQL 服务器宕机了，他只关心他的查询是否失败；用户也不会关心我们的软件在反复重启，他只关心功能是否正常；同样用户也不会关心我们的推送是否失败，他只关心消息是否及时。

并且用户关心的东西其实很少：

所以，数据库不可用和用户查询不可用看上去很相似，实际前者是原因，而后者是症状。当我们没有办法模拟用户的真实行为时，我们其实很难区分出这两者的区别，但是如果我们有办法，则应该去尝试关注后者。

我个人比较推崇建设和关注端到端成功率，有些时候可能数据库频繁断连接，但是用户的程序有重试逻辑，只要最终没有报错，那么就没有任何影响。反过来，也许数据库只是延迟上升了一些，但是刚好触发了用户的超时和熔断，那么很可能会出现数据库看上去没有异常，而用户已经大面积报错了的故障。

Cause-based alerts are bad (but sometimes necessary)

为什么作者不推荐配置基于原因的告警，有以下几个理由：

但是在一些场景下，我们也需要基于原因的告警，例如内存或是磁盘空间即将耗尽，这些问题没有症状，并且即将导致严重问题。除此之外，不推荐为能够配置症状告警的问题配置同样的原因告警。

以前有个系统，对 uptime 配置了告警，用于监控异常退出后重启的情况。但是滚动重启时也会导致 uptime 归零，因此当时的逻辑是在滚动重启时禁用掉该告警五分钟，看上去这不是一个优雅的做法，因为依赖外部工具动态修改告警配置增加了告警规则的复杂度。也许更好的做法是直接监控异常退出和 OOM。

Alerting from the spout (or beyond!)

在 client/server 架构中，在客户端配置告警要优于在服务端配置告警。有以下几个原因：

对很多服务来说，意味着在离用户最近的负载均衡去评估延迟和错误，这样只会在故障真正影响到用户时才会发送告警信息，也能比服务端发现更多的问题。

但是也要注意将告警控制在能掌控的范围内，作者举了个例子是如果能够配置基于浏览器的告警，那么就几乎可以感知所有用户可以感知到的问题了。但是同时也会带来大量的噪音（例如用户本身的网络质量或是电脑性能），所以不太可能当做唯一依赖的来源。

之前也遇到过同样的问题，在做分布式事务时，计算层会将一个 2pc 请求并行的发送给所有的存储层参与者，并等待所有参与者返回，因此计算层完整的 2pc 的响应时间由最慢的参与者的响应时间所决定。当某台存储节点的负载明显高于其他节点时，计算层的执行 999 线就可能和存储层的执行 999 线截然不同。

前段时间我收到了一个端到端可用性直接降到 80% 的告警（配置的告警阈值是 99.9%），后来发现是因为业务的新写的逻辑没有考虑到数据库中的已有数据，产生了大量主键冲突的异常，这个异常和数据库的可用性其实没有明显关系，但是因为我们这边统一监控了 JDBC 层面的所有异常，很难区分出系统异常（例如超时、断连接等）和用户异常（例如语法错误、主键冲突）等情况。比较有意思的是业务侧没有收到任何告警，而数据库侧光看告警的内容会吓死人。

Causes are still useful

基于原因的告警仍然是有用的，它的作用是帮助我们快速的从问题的症状跳转到问题的根因。

如果我们希望能够自动将症状和原因关联起来，就需要减少一些无法控制的原因告警，作者提倡使用以下方法：

1. 当编写一个基于原因的告警时，需要检查对应的症状是否也有相应的告警，如果没有的话，需要补上

2. 在每个告警中简要描述可能产生的原因，帮助处理告警的人能够快速的确认问题是否已经有确定的对应原因，例如：

   1
   2
   3
   4
   5
   6
   

   TooMany500StatusCodes
   Served 10.7% 5xx results in the last 3 minutes!
   Also firing:
           JanitorProcessNotKeepingUp
           UserDatabaseShardDown
           FreshnessIndexBehind
   

   这里出现了 5xx 过多，可以快速的推断出最大的可能是数据库异常，而如果出现了磁盘空间不足或是页面返回空结果，则更有可能是另外两个原因。

3. 删除或调整其他低价值的原因告警，以减少噪音

最后，作者提到基于原因的告警更多是和监控面板的复杂度做取舍，如果我们需要一个干净的监控面板，那么就可以配置更多的原因告警。相反如果我们已经有了一个很完善的监控面板，那么其实不需要原因告警也可以快速的定位问题。

监控面板的复杂度也是我最头疼的问题之一，很多时候监控面板看上去很完善，但是出现问题后其实很难快速的找到某一个异常的指标，也就是从症状推到原因的效率并不高。

Tickets, Reports and Email

这里主要介绍如何处理一些不需要立刻处理的告警，作者称为「sub-critical alerts」，下面为了方便称为隐患，作者也提供了一些经验：

作者想表述的重点在于，需要有一个系统能够同时满足两个目标：一定有人会对这类隐患负责，并且没有人需要为此付出高昂的成本。

大公司的常见毛病，每天都会有乱七八糟的无用告警发来发去，而且没人在乎，想推动相关人员把这些无用告警去掉，他们又怕之后出问题了担责任，从没有认真思考过如何改善这个问题。

Playbooks

Playbook 是告警系统中的另一个重要组成部分，作者建议给每一个告警项都编写对应的 Playbook，进一步解释告警的含义以及如何解决。

一般来说每个 Playbook 会是一个详细的流程图，大部分的篇幅是介绍哪里可能出现问题，少部分的篇幅介绍如何修复它。此外还有一些情况是这个问题超出控制，必须寻求人工协助。因为一般篇幅不是很多，记录在 wiki 中是一个好的选择。

这里作者介绍的信息很少，可能是因为 google sre 都太牛逼了没什么需要人工处理的问题…

Tracking & Accountability

如果一个告警正在触发，但是有人说“我看过了，没什么问题”，这表明我们需要重新调整这个告警的规则，或是干脆将它删掉。准确率低于 50% 的告警可以认为是坏掉的，及时是 10% 的误报也需要考虑是否能进行调整。

需要有个系统（例如每周审查所有告警，或是每个季度统计告警数据）帮助我们了解系统的现状，以及分析一些告警在不同人之间转移时出现的问题。

You’re being naïve!

理想很丰满，但是现实很骨感，一些可能会出现的情况将会违反上述的规则，但仍然是合理的：

个人很赞同最后一点，不要通过复杂的告警规则或是人肉运维去解决系统设计问题，很多问题的发现和降级都应该在系统内部完成。