3.4 报警治理
监控报警需要具有告知线上异常和辅助定位问题的能力。对大多报警系统而言，告知线上异常并不困难。随着支持的数据源持续增加，报警规则在不断完善，报警死角在逐渐减少，且服务间存在关联和依赖，即使故障源没有配置监控，关联服务也会表现出行为异常从而触发报警。
告知线上异常通常能够实现，但辅助定位问题的实现并不容易。多个服务经由关联关系形成服务网，附着在服务上的报警借由服务的关联关系形成报警网。当线上服务出现故障时，故障会在报警网上蔓延，形成报警风暴，处于风暴中心的运维工程师，难以从大量报警消息中快速发现问题根源，解决线上问题。
如何收敛报警消息和提升故障定位效率，涉及报警治理的相关概念和方法，可以从以下几个角度入手。
1.报警阈值
设置合理的报警阈值能减少大量无效报警。部分监控系统会提供缺省报警规则，但缺省报警不会完全契合业务实际运行状态。例如，网络流量报警，部分离线服务在离线任务执行过程中会频繁使用网卡传输数据，提高网卡流量数据直至触发网卡报警。针对此类离线服务，可以适当调整网络流量报警阈值，避免正常业务行为造成的报警误报。调整报警阈值通常不是一步到位的，而是随着业务行为变迁、监控数据变化，也要持续调整报警阈值。针对通用型报警阈值配置，可以要求监控系统提供批量配置管理能力。
2.报警发送方式
使用不同报警发送方式区分报警消息优先级是报警治理的有效手段。监控系统通常会提供多种报警发送方式，典型的报警发送方式有电话、短信、即时通信App、邮件等。其中电话报警优先级最高，适用于重要监控报警，但同时要控制电话报警的数量，以明确界定电话报警的重要性。短信报警优先级次之，其特点是到达率高，在没有特殊原因被限流的情况下，短信报警通常都会到达用户，但考虑到流控和成本等问题，短信报警渠道不适合发送大量报警。即时通信App的报警渠道通常能承载大量报警，部分App还能提供运维能力，但即时通信 App 的报警到达率和唤醒率都不如短信，Android平台尤其明显，因此即时通信App适合发送重要性不高但需要用户感知的报警。邮件报警的优先级最低，但邮件报警内容的排版方式灵活多样，适用于报表类报警。
3.发送目标
配置合适的发送目标能提升报警响应和处理效率，要避免有些人员收到大量报警后做二次分流。运维团队可以配置不同服务下的报警消息发送给服务对应的开发团队。在线上业务出现异常时，相关服务的开发工程师会分别收到自己负责服务的报警消息，从而能够快速进入业务问题排查工作。由开发工程师负责相关业务问题排查，不仅缩小了问题排查范围和提高了问题排查效率，还培养了开发工程师的线上服务运维意识，这是一种非常有效的排查手段。对于持续发送且未处理的报警消息，可以配置报警自动转发给后备责任人或直接主管，避免报警遗失。
4.报警抑制
在满足报警抑制条件的情况下，用户可以屏蔽部分报警消息。典型的报警抑制手段有次数抑制、时间抑制和集群抑制。所谓次数抑制，是指监控数据在一段时间内连续触发异常达到指定次数后才会产生报警行为。次数抑制的主要目的是防止监控数据抖动造成的报警误报，虽然能过滤监控数据抖动，但也会造成报警延迟，抑制次数并不是越高越好。
所谓时间抑制，是指报警发送后，一段时间内不发送重复报警，抑制间隔通常是1小时。时间抑制能减少重复报警，但短时间只发送1条消息容易被其他报警消息淹没，因此对于重要报警消息，可以适当缩短抑制间隔，提高报警消息对用户的到达概率。
所谓集群抑制，是指对同业务内的多个节点做报警抑制。线上服务通常使用集群模式部署，一套代码部署在多个节点上，执行相同的工作。不同节点上的相同服务通常会依赖相同的中间件或下游服务，如当多个节点共同依赖的MySQL服务出现故障时，每个节点都会出现相同的异常。集群抑制控制集群中报警节点的总数量，如集群下有100个节点同时出现一种报警时，只有3个节点会发送报警消息，剩下97个节点的报警消息都会被抑制，最终会有一份统计信息发送给用户。
除上述报警抑制方式外，还有一些智能报警抑制手段，通过分析单条报警的持续性、周期性和多条报警的相关性等，实现报警抑制和合并，最终减少用户收到的报警消息数量。
5.报警处理
报警处理完善了故障处理制度，有助于多人协同和故障复盘。与此同时，报警处理过程中反馈的处理信息，包含报警有效性和报警重要性等内容，传递了报警接收人对报警消息的判断。针对多次标记无效的报警消息，监控系统可以自动调整报警触发级别和报警触发频率，减少无效报警消息的发送量。报警处理记录形成的报表还能指导运维工程师梳理报警配置，复盘模拟线上故障。
报警处理的本质是运维工程师和开发工程师借助监控系统提供的能力，表达对业务重要性和关联关系的理解，最终提升报警有效性。由于监控系统智能判断业务重要性和关联关系的方式相对有限且精度不足，因此报警处理需要运维工程师和开发工程师共同参与。在这个过程中，监控系统要承担辅助角色，为用户运维报警数据提供便利。