软体工程师该如何做好监控 (monitoring)？

很多人可能会觉得，监控与事故处理，不是应该属于 SRE (Site Reliability Engineer 又称网站可靠性工程师) 的范畴吗? 在过去确实是这样子，但近几年趋势的改变下，多数公司也都抱持着开发者要第一线处理事故的做法。

先前 Increment 有做一份调查 (连结)，结果发现包含 Amazon、Dropbox、Meta、Google 还有 Netflix 等公司，现在基本上都是开发者负责监控与轮班处理事故。

这是因为如果跟应用层相关的问题，仍是开发者最了解，如果是进到应用层的问题，SRE 处理不了的话，最终也需要拉开发者来解决问题，所以多数公司仍需要软体工程师来参与监控、轮班，以及处理的事故。

因此，身为开发者，对于监控、轮班处理事故等主题，仍需要有所掌握，而本篇会先从监控开始谈。

监控什么? 为什么要监控?

所谓的监控，就是针对系统整体、各部分的持续观察，借由搜集不同指标的资料，来判断系统目前是否有异状。透过监控，我们能够提早发现问题，而不是等使用者端回报问题后才发现。这边提到的发现问题，可能包含系统有故障、系统有潜在的效能问题，或者是系统的使用量到达上限需要进一步扩展。

举例来说，我们可以透过埋点，持续观察每天的使用者流量，如果平常每天系统的使用者流量为 1 万，但某天突然暴增成 100 万，这种反常的状况，就代表有可能某些不对劲的事情正在发生 (例如网站正在被 DDoS 攻击)，而工程师就可以进一步去排查问题。

如果没有监控，不知道网站流量突然飙高，也就没办法第一时间跳下去排查，很可能要等到灾情传出后，才能被动地去回应问题 (例如被 DDoS 后，使用者跟客服说进不去网站，客服再反应给工程团队，这样就会慢半拍)。

要监控就需要有指标

想要做好监控，就必须知道要监控什么。而监控的东西，我们又会称为指标 (metrics)，如果该观察的指标没有观察，那很可能的导致出问题后不自知。

Google 的 SRE 专书 (连结) 提到，有四个推荐一定要看的指标 (当然，每个系统可能因为有不同的元件，所以需要监控不同的指标，最推荐的做法，是拆解系统的各个部分，然后确保该监控的都有覆盖到)。

• 延迟度 (效能)：
  • 拆解每一段的耗时 (延迟度)，从前端到后端
• 流量：
  • UV / PV (UV 是看使用者，而 PV 是看页面)
  • QPS 波动 (QPS 是看请求量)
• 错误 (稳定性)：
  • 错误率
  • 成功率 (或失败率)
  • 正常执行时间 (uptime)
• 饱和度 (资源使用率)：
  • CPU 使用率
  • 记忆体使用率
  • 网路频宽使用率

这边特别提在看效能指标时，要先注意先行指标。举例来说，慢查询、消息堆积可能会导致后面的请求无法被处理，就会引发后续的其他警报被触发，所以这种先行指标要先注意。

另外，效能指标的监控，推荐要监控百分位数，例如 P50、P90、P95、P99、P99.9。所谓的百分位数，就是指多少比例的请求在这个百分位数当中。举例来说，页面加载 P90 的延迟度是 1 秒钟，表示有 90% 的使用者都在 1 秒钟内完成加载 (有 10% 的使用者，超过 1 秒才完成加载)。

会推荐这样看，是因为这能让我们更清楚整体与极端的状况。特别在使用者量级大的状况，百分之一也是很多人，如果不看 P90，只看中位数或平均，很可能会以为效能很好，殊不知其实有不少人在用的时候效能很不好

监控警报需要有等级设定

在做监控时，一般都会加上自动的警报 (alert)，当某些特定的条件发生时，会触发警报，通知工程团队要去注意与排查问题。

举例来说，假如原本某个 API 的请求成功率是 99.99% 以上，团队设定警报为成功率低于 95% 就会发送警报。这时如果某天突然跌到 80%，那监控系统就会发出警报，让团队知道有异常状况。

然而，在设定警报时，推荐要设定等级。在业界有所谓的服务水准协议 (Service Level Agreement，也就是大家常听到的 SLA ) 设定，其中「响应时间承诺」也会在 SLA 的规范中。举例来说，在 SLA 中可能会写，对于客户的服务请求的响应，不得超过 12 小时。

一般来说，如果没有达到 SLA，是会有相对应的罚则或补偿。例如 Google Cloud 就有写出，如果没有达到，会给 Google Cloud 的免费使用额度 (连结)。

当然，不是所有的问题都该视为均等，例如 API 请求成功率跌到 95%，跟跌到 20%，两者严重性不同，该给予的关注度，以及响应时间也会不同。身为工程师，需要有效辨别什么该优先响应。

在业界普遍会用分级的方式，来为不同的监控警报分级。举例来说会用 P0、P1，等以此类推。所谓的 P 是指 Priority，也就是优先顺序的意思。一般来说，P0 是最重要的项目 (有些公司会是定义，常态时期最重要的是 P0，而临时遇到紧急且重要的，会是 P00。只有真的出现 P00 的紧急任务时，才能够中断 P0 项目来把人力与资源投入在 P00 事情上。)。 P1 是次重要，然后再来是 P2、P3 以此类推。

又另一种分法是用 SEV，而 SEV 是指 Severity，也就是严重性的问题。而 SEV-1 会是最严重 (例如客户的资料丢失)，而 SEV-2 会是次严重 (例如某个功能不能用)，而 SEV-3 会是轻微严重度，以此类推下去。

依据不同监控指标的优先级，我们也会定义不同的响应时间与解决时间：

• 响应时间: 所谓的响应时间，是指当收到监控的警报后，隔了多久才回应收到警报。一般业界会用 Ack 来表示，所谓的 Ack 是 Acknowledge 的简写，意思就是指「收到了」。以下表为例，如果是 P0 的监控警报响了，负责值班的团队就需要在一分钟内回应说收到了。但假如是 P2 的监控警报响了，那么晚一点回应收到了也相对不要紧。

• 解决时间: 而解决时间则是当警报开始，到问题实际被解决的时间。实际被解决是指在生产环境中问题不再存在。一般来说，即使是透过临时的解决方案，只要能先确保线上问题被解决，即使不是缜密的解决方案也没关系。通常会先确保问题能快速被解决，让线上的损害不继续扩大，然后才去重新设计更缜密的解决方案。

备注：下面这张表是参考范例，不同团队的 SLA 设置可能不同，推荐可以根据自己团队所在的脉络来设定。

当监控发出警报时，该如何处理?

前面谈到了监控会设置警报，而如果某天警报响了后，该如何处理呢?

首先要响应，一般来说相关的监控系统发出警报时，会有一个可以点的按键，点下去会发送 Ack 代表负责的人有收到并着手处理。

在点完 Ack 后，要接着判断异常是属于什么等级的异常，然后实际查询来判断是否真的有问题。如果是伪阳性 (false positive)，要去思考是否调整监控的阈值；如果是真的出问题，则着手排查，处理过程如果发现是新上线的问题导致，第一时间要回滚，同时要通告相关人员。

在处理事故的过程，有一个务必要放在脑中的观念是「时时通报」，让相关人员都能知道目前处理的最新状况。解决完问题后，在群组通报相关人员问题已排除，请相关人员协助二次确认。而如果是有一定影响力的事故，在解决完问题后，要开事故检讨会议。

如果你对于监控这主题，想了解更深入，欢迎加入 E+ 成长计划 (连结)。我们在 E+ 有更深入的版本包含讨论如何降低无效噪音、如何避免警报疲乏 (alert fatigue) 与警报风暴 (alert storms)

相关文章

• 软体工程师该如何值班 (on-call)?