大型互联网系统的服务和指标都是海量的，对应的告警也特别多，即使做了很多的分级和收敛，往往很多小问题依然会触发一堆P0，反应不出产品的真实影响。因为是P0，所以大家都是绷紧神经处理，可能只是几个边缘服务异常抖动，并不影响网民用户，但循环往复，弄的大家很疲惫，长此以往，大家对P0也就不那么敏感了，和狼来了的游戏一样，质量的隐患也就这么埋下了。
举例几年前我刚接手小爱、米家的运维时，发现工程师基本是通过告警数量来判断要不要处理，一堆告警瞬间过来，短信铃音连成一条线，说明遇到严重故障要马上响应，日常零散的告警陆续不断，基本上看下也不怎么处理，习以为常的惯性非常大。到故障复盘时，如果故障严重，有同学响应慢没有关注到P0告警，那说明要改进的是增加告警数量、告警次数。
分析其中的原因，不是工程师不负责任，也不是大家不重视告警，恰恰相反是因为大家太重视，每个指标都想关注，不明白少就是多的道理，把每一个能反映出问题的告警都往高级别、多数量上升级，形成了告警级别和数量的恶性内卷，造成P0越来越多。再就是，实际工作中，因服务、技术人员众多，在没有从产品角度全局拉通通盘考虑的情况下，每个人都会从自己的服务里找出几个核心指标作为P0告警，拿小爱举例，400多个服务，如果每个服务设置2个P0，整个系统就会有800多个P0指标，再加上每个实例独立告警，就又会有一个指数级别的膨胀，有些上下游、服务本身再打一遍点，P0告警爆炸是必然的，这就是真实工作中的客观事实。
生死告警—大型系统的最优解
综上，要使工程师在Oncall时对最重要的告警保持敏感，必须提高告警的有效性，必须要从机制和技术上找解法，单纯责怪告警分级执行不到位和历史包袱大是不对的，必须从客观事实出发考虑问题。
所谓有效，我认为有两层意思：一个是少、一个是准。如果告警收敛到极致，整个系统只留一个指标反应其健康情况，然后对这个指标建立告警，和所有工程师讲清楚告警出现的严重性，是不是就解决了有效性？答案是YES，经过实践论证这个是化繁为简，复杂问题下的最优解，建设成本最低、周期最短，可以绕过一切历史包袱，解决问题。
这个指标对应的告警我称之为生死告警，从产品的角度看，这个告警报出来产品就严重不可用了，例如小爱的生死告警报出来，肯定是有很多用户无法进行语音交互了，米家的生死告警报出来，肯定是很多用户无法刷新设备列表进行设备控制了。
生死告警是告警的最顶层收敛，围绕系统最核心的指标建立，原则上一旦生死告警报出，无论有没有其他告警，代表系统已经挂掉了，需要*别的响应，同样如果系统虽然有大量的告警，但是并没有触发生死告警，说明并不是灾难性的故障，系统主干功能还是可用的。生死告警一旦建立，就要不断修正确保其准确，因为生死告警代表系统的生死，任何人在任何时候任何地点看到都需要立刻响应。
我在负责小爱SRE后，每天看到海量的告警，真心头疼，所以第一件事儿就是拉通研发普及了生死告警的认识，并建立了生死告警，刚开始还有一些同学不理解，觉得不缺告警，但后面所有技术团队深受其益，大型系统下有一个所有技术团队对齐的生死告警真的是太重要了，晒两张小爱的生死告警截图如下，原子弹爆炸蘑菇云群头像（当年小乔找的，觉得甚好），群内平时安安静静，只要有任何消息所有人立马紧张行动起来，为了保护大家的神经，此群禁止任何聊天，生死告警同时配有电话，PS小爱的工程师真的都太在意小爱了，我看到过好多次因为出故障吓哭、或者自责哭泣的同学。
生死告警建设思考
首先生死告警是一个产品指标、全局指标，而不是一个简单的技术指标、局部指标，用它来表示产品的可用程度，一般都是百分比，这是一个基本认识，例如小爱同学所有的指标加起来至少百万级别以上，但代表小爱生死的只此一个。
制定生死告警要站在产品的角度通盘考虑，从用户角度先识别产品的核心功能、用户的核心体验。比如小爱的核心功能是语音，那么语音的正常交互对于小爱而言就是生死，除此之外都是支线功能，以此为出发点建立用户的可用性作为生死告警，端上的可用性打点很难保证时效，影响因素太多，所以这个指标还是要在云端建立，那么多服务要怎么建设呢？继续化繁为简，与用户直接交互的是接入层服务ai-access，那么ai-access的正常响应直接代表着对用户的正常服务，所以以此服务建立可用性指标，将总访问量和总错误量（制定好错误码规则，将所有串联的骨干服务错误传递上来）做好埋点统计，计算出可用性百分比，配上告警就是生死告警了。
再比如米家的核心功能是设备列表、设备控制，生死告警就围绕着这两个操作来建立，其他功能和服务都是支线；电商的对应可能就是下单的成功率，可以把下单的全过程当做一个数据库事务来处理……总之每个产品都会有它为用户解决的核心问题，这个核心对应的可用性就是产品的生死所在，围绕它把指标建好在响应告警时就会心中有乾坤、坐怀而不乱。
僚机—常规告警分级
生死告警解决的是产品生死线问题，单纯靠它解决不了大型系统告警的所有问题，因为除了生死还有很多重要的告警要处理，只是紧迫性要低一些，但重要性依然很高，而且不能不处理，一旦不处理，风险积累下来，下一次告警可能就是生死了。所以要体系化的看告警的治理，除生死告警外常规告警的分级必不可少，它就像是生死告警的僚机，使整个体系更加完善，协同配合着生死告警，将整个系统的各种问题暴漏出来，交给工程师诊断、治疗、修复，让整个系统越来越牢固。
告警的分级要从用户可用性出发，比如说我们所有服务在架构上都做了单机容灾，所以从业务的角度看，某台机器的任何故障都不会影响到用户可用性，所以单机的所有告警都放在P2，其他的分级考虑也都一样，晒一下我带着团队讨论后形成的告警分级。
- P0+ 产品生死告警（面向整个产品，非某个服务功能）
- P0 一级服务（可用性、业务核心指标[开发]、5XX）、域名网络告警
- P1
- P2 三级服务（可用性、业务核心指标[开发]、5XX）、Ping、内存、磁盘、网络、CPU、GC、CORE、证书告警、4XX、服务端口、进程重启
当故障发生时，很多告警指标会同时报出来，我们制定这套规则，为的就是从用户可用性出发，把直接反应用户体验的指标设置成更高的响应级别。比如说服务的可用性、时延、QPS分别代表业务的质量、性能、容量，当上述指标触发告警后，肯定是对用户有感的，用户体验下降，再排查发现会伴随着一些CPU、内存、进程重启、磁盘等低级别告警，它们对应的可能就是故障的原因了，总之就是要识别出能反映出真实服务可用的指标放到高级别，高级别告警首先是为了发现问题暴漏故障，而不是眉毛胡子一把抓，还想诊断还想其他，要用结构化思维来考虑这个事情。
我们认为告警的最终目标是：只要收到的告警就是要处理的，就是有效的（非通知），这个目标还是非常有挑战的。
研发工具为SRE赋能
在告警的处理上，因为数量还是太多（每个人管的服务太多），所以我们设计研发了团队的AiFault告警分析工具（由惠燕歌同学研发，非常优秀的女SRE，毕业就来到了我们团队）来协助工程师管理告警，将未恢复的告警进行统计分析、可视化展现，防止告警一多、工程师一忙，忘记重要告警的处理，也避免了人肉聚合分析，速度太慢，系统的示意图如下，真的是一个告警处理的神器，相当好用。
