在先前治理后端稳定性的一些实战经验这篇文章里，笔者聊过稳定性治理的大致路径，先定指标，再保证可监控可观测，之后才是解决具体的技术问题。今天这篇文章就聚焦在可观测跟止损这两个环节，简单聊一下端到端的告警应该怎么梳理，以及严重告警的处理预案应该怎么做。这两块做扎实了，稳定性保障才算是有底子的，说到底目的还是稳定性本身，而不是把监控大盘做得多好看。
首先是端到端告警的梳理。对于复杂的链路场景，笔者认为只了解架构本身是不够的。常见的做法是把服务依赖图画出来，然后照着架构图一层层配指标，CPU、内存、QPS、错误率都配上，看起来挺全，但真出问题的时候还是定位不到。比起技术架构来讲，更重要的是识别哪一类业务场景比较容易出问题，然后针对这个业务场景的链路，去梳理有哪些指标水位是比较敏感的，再针对性地设定告警做监控。
举个例子，一个任务类的业务场景，从上游触发到中间调度再到下游执行，链路上涉及的服务可能有很多个，但真正需要盯的可能就是其中几个关键节点，比如中间调度那一层的MQ消费方，它的消息积压量和消费时延，是最能反映这个场景健康度的水位。如果只按架构维度去配告警，每个服务的资源指标都告一遍，反而会把这类关键信息盖住。所以梳理的顺序应该是先业务场景，再链路，再指标，最后才是告警规则，这个顺序反了的话，配出来的告警大概率是不好用的。
然后是严重告警的处置，这一块就需要预案了。对于复杂链路而言，一个严重告警出来，通常一个人是解决不了的，一方面问题可能横跨好几个团队，另一方面值班同学未必熟悉这条链路的全部细节。预案为什么要有，笔者的理解是两点，一是能够有一套效率的线上问题解决办法，不用每次出事都从零开始想，二是不管谁值班，照着这个预案执行都能把问题解决掉。第二点其实更重要，因为线上出事是不挑时间的，凌晨被叫起来的人，未必是当初设计这条链路的人。
所以预案不能是一份躺在文档里的架构说明，要写清楚具体的动作，比如先关哪个降级开关、限流调到多少、要不要切流、什么情况下直接回滚，最好是能够一键触发的。预案也要跟告警关联起来，严重告警出来的时候直接带出对应的预案，值班同学不需要自己再去翻文档找。
再往后是预案的演练。预案写完了如果不去演练，等真出事的时候大概率是执行不下去的，因为预案里写的降级开关、限流阈值这些东西，很可能已经跟当前线上的配置对不上了，这样执行下去止不了损，还可能导致二次故障，影响面进一步扩大。笔者的建议是周期性地对复杂的链路场景做故障注入演练，比如把某个下游依赖打挂，或者把某个中间件的时延拉高，然后看告警有没有按时出来，预案执行下去能不能真的止损，整个耗时是多少。演练出来的问题要回流到告警和预案里做迭代，这样重点的业务链路才能长期稳定下来。
总体来看，端到端告警的梳理还是要从业务场景出发，去识别哪些指标水位比较敏感，而不是照着架构图铺指标。严重告警的处置靠的是预案，预案要能快速止损，还要保证谁值班都能照着执行。最后再配上周期性的故障演练，重点业务链路的稳定性才算是有保障的。这几块最终还是要靠实战出真知，不管是告警预案还是演练，都得多实战几轮，把问题在演练里暴露完，真出事的时候才接得住。