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