告警平台设计及告警收敛通用解决方案
先有监控，后有告警。如果说监控是一瓶红酒，那么告警就是开瓶器，不然只能望酒兴叹「哈哈，想了半天没有找到合适的比喻，刚好有喝酒撸文的习惯，一口下肚觉得很应景，特此做的借喻」。
告警很重要，想想「三体」中人类星际舰队被水滴攻击，人工智能系统却无法发现攻击源，这实在太可怕了。结合日常工作，我抛以下几个问题，作为文章的开始：
- 问题
告警平台正常运行，因紧急变更、人为失误等异常情况导致告警风暴和连锁故障，那么如下：
- 在风暴告警中，如何分辨有效告警和误告警「告警收敛反而会屏蔽运维视野」，如何精准发现问题根源？
- 针对连锁故障，在服务治理实现前，有什么推荐解决方案？
一、告警平台的数据链条
告警，讲究：
- 有效性
- 及时性
- 精准性
看似简单，却和Consistency(一致性)、Avaliability(可用性)、Partition tolerance(分区容错性)「CAP原则」一样，通常只能三选二！
告警处理流程
如图，为告警处理逻辑，分三段：
- 事件输入
- 事件决策
- 事件处理
事件输入：通常遇到的问题是事件太多；
事件决策：通常遇到的问题是决策名存实亡，狼来了的故事太多；
事件处理：未知因素太多，绝大多数公司都做不好，停留在表层，效果好坏，全看老板是否关注，NOC团队是比较好的解决方案之一；
所以，如下情况很常见：
告警太慢被老板骂，告警太多被同事骂。出了问题，开发比运维先知道，还老在群里喊。这谁受的了！
人人都觉得监控工作很LOW B,但却没几个做的好的！
二、告警平台究竟要解决哪些问题？
- 输入端
数据精准、详实、全面、及时。为决策层夯实基础
- 决策端
策略有效、可自动执行、有收敛、有自愈。一句话，就是去人化！
- 处理层
有告警必处理！ 看起来简单，但实际几乎做不到。
三、通用告警平台功能集
告警平台功能集
通知告警平台最少需要具备如下功能：
- 多通道告警接口
邮件、短信、电话、企微/钉钉/飞书。短信，电话必备
- 告警渠道健康检测
告警来源号码被屏蔽，标记为广告常见。虽厂商有自动换号机制，但健康检测不可少
- 级联告警
为告警收敛打基础，减少告警信息，避免告警风暴
- 告警收敛
特别重要，依次要有告警自愈、级联告警、告警收敛
- 告警权重
针对不同告警权重，做对应告警策略。
- 告警分层
分业务、分模块、分团队、分时段，必不可少
- 告警升级
包括告警通道告警和告警职级升级
四、告警收敛通用解决方案
告警收敛首先要解决的问题是告警风暴！ 回到文首的问题，假设告警平台正常，如何在海量告警中定位到问题根源，或罪魁祸首！
- 告警分组
分业务、分模块、分团队，简单的如DB类的告警通知DBA团队，Nginx的告警通知业务运维。精细化的案例，如：A业务模块告警只通知A运维，而非通知GROUP组。但没有解决Leader要接受所有告警的场景。
- 告警抑制
有告警自动抑制功能，需事先做告警级联。上游告警屏蔽下流告警。但不容易解决跨团队信息同步的问题。如路由器挂了，如不通知业务侧，会造成重大生产事故无法及时处理。如DB Master挂了，如果不通知 Replication 同步失败，会容易遗漏处理主从失败问题。
- 告警静默
有手动入口设置告警静默，如常规发布窗口，需有入口关闭告警。如明知A告警会引发B类告警，可以提前关闭B类告警。但不容易解决告警遗忘的问题。如维护期结束，告警静默却没有关闭导致告警无法发出。定时告警静默的功能，也不能覆盖全场景。且已经了出来的告警，再静默无效。
- 告警收敛
收敛有很多方式，常见的如：同属性维度收敛、时间维度收敛、次数收敛。但和告警及时性冲突，收敛做的越好，越容易造成告警不及时。导致开发比运维先发现问题，容易造成部门间关系紧张。
同属性维度收敛：zabbix相同事件名、相同主机名、相同业务名称、告警统一ID，等可以做为唯一标识的字段，做频次收敛，或告警合并
时间维度收敛：判断单位时间内告警条数，做告警合并。时间单位通常以秒为单位，和业务属性强相关。通常也会结合属性维度。
最后，总结如下：
- 找共性问题！！ 但依然无法解决降维打击的问题！！；
- 级联分析！标注重要程度和关联关系！ 交换机坏了必然会产生大量网络不通的问题；
- 权重算法，同类型问题高权重收敛低权限；
- 智能(相似性)算法，绝大多数公司无法实现，有误判情况；