Day 5：浅谈警报 (alert) 的设计

前天使用 updown.io 架设了 status page，并且让它可以在服务无法连上的时候，自动发通知到 slack 频道。这便算是一种警报，告诉相关人员说，有一些警急状况需要处理。

然而仅仅这样是不够的，毕竟在实际的环境中，可能会遇到各种状况导致服务出问题，所以若是在意外发生之前，就能提供我们一些资讯的话，就有机会可以更快的解决问题（或是找出潜在的 bug，在他们实际影响到使用者之前就着手进行修复）。

举个例子来说，以前 NOJ 曾经遇过一个挺蠢的问题，我们沙盒的 log 把硬碟撑爆了，因为当初 log 写了太多没用的资讯（像是这个案例就是把题目的 IO 都记录下来），最终产生了好几 GB 的 log 档，加上没有做 logrotate，导致整台机器挂掉。然而若是有在硬碟快被塞爆之前，就有发出警报的话，或许就可以避免这次悲剧了。

几个原则

那麽究竟该怎麽判断什麽时候该发出警报，这就是一个困难的议题，对於每个不同的专案，可能都会有些不同，但还是有些大方向是可以遵守的。

简化

在实际运行的服务中，我们可能会监控各式各样的数值，写了各种规则去表示「某件事情发生了，需要人力介入处理」。然而若是规则太过於复杂的话，可能会造成它难以维护，复杂的规则通常代表着复杂的逻辑，而复杂的逻辑通常也是难以理解的，当服务本身的需求有变更以至於警报的规则要修改时，可能会是一场辛苦的战斗。

应当避免误报

警报的出现意味着需要人力的处理，然而若是警报常常误报，便会造成类似童话「狼来了」里面的放羊的小孩一样，形成警报疲劳，导致真正的问题发生的时候，被忽略掉而没有处理造成损失。

所以当一个警报它并不需要立即的处理，或是说仅需要一些机械化的操作便可以解决，那麽我们就不应该浪费宝贵的人力去做这些事情，应该要尝试使用自动化的方法解决它。

明确的处理流程

当一个警报是需要人工处理的，那麽它应当要有明确的处理流程，确保收到通知的当下，我们知道要如何应对。所以在这部分应当留下良好的文件，避免只有少数人清楚流程，而是让团队里的每个人都知道怎麽做。

小结

这个章节我写一写才发现...好像应该先讨论监控的，毕竟警报是基於监控得到的数值来设立规则的嘛，所以希望明天我有办法写一些有关监控系统的架设与设计指标 (metrics) 的讨论。

不过这些主题对我来说就算是非常陌生的议题了，若是有不小心写错的地方还请各位多多包涵。