运维技术入门（从一套On-Call响应机制开始）

但是如果没有集中的告警机制进行管理，就会面临大量的告警噪音的困扰，难及时地跟进处理，而重要的告警信息也容易被遗漏。

CA 可以实现告警的集中化管理，即将生产监控发现的告警事件集中到一起，这样只看着一个平台就够了，同样地也会更容易分析告警问题，在这一步相同和类似的告警就会被过滤掉，即可直观掌握现有环境的状况，发现事件相关性的，有些问题有较强关联性的，方便跟踪和后续的统计分析。集中处理，效率就会更高。

建立支撑流程和机制

如果您的系统只采用了一种监控工具，集中化管理则不是必要的，如何有序处理告警信息才是最核心的问题。特别运维团队是 3-5 人到数十／百人，就很有必要梳理下支撑流程和响应机制了。

如果管理比较细一些，还应该对业务进行拆分，形成一个矩阵，例如一线、二线根据不同专业，如负责网络和负责不同应用的团队。同时还要考虑告警严重的程度级别，进行差异化处理，对于运维管理严格的团队一般会建立不同的响应级别。

1. 严重级别：如大范围影响业务／终端用户的，需要及时处理，一般要求多长时间响应处理，如3-10分钟有人响应，无响应立刻升级；

2. 警告级别：影响范围和严重程度会低一些的故障，处理时长可以长一些；

3. 提醒级别：依次更低。

那么问题来了，这一切如何落地呢？目前看 Zabbix、Nagios、Open-Falcon 等监控工具更多是聚焦如何发现问题，支撑流程属于处理问题的范畴，或者是说管理范畴，这一点还有很多运维团队采用“码人”的方式：一个监控班，7x24值班，人为处理和通知。

而对于 CA 的用户来说即可用技术的方式实现：CA 可以通过分派策略、通知策略以及排班机制等，实现告警的灵活通知。【自定义分派策略】可以进行流程的设计，根据级别、应用设置对应的一、二线负责人，以及处理时限，超时未响应（确认告警）自动升级。

【自建排班规则】7x24 小时紧绷状态不是谁都能扛得住的，适当轮班缓解下压力。CA 中可以通过排班机制，实现白夜班、按周等模式进行轮流值班。

多渠道通知必达

再好的流程和设计，如果没有及时收到通知并处理，那么整个运维团队仍然会很郁闷的，关于告警的最后一公里的问题更是至关重要！

目前被运维团队选择最多的就是以下这几种方式：

当然如果您正在使用我们的 CA 平台，可以根据您企业的自身使用习惯，选择电话、短信、微信、邮件、APP、钉钉、企业微信、飞书、JIRA 等通知方式，也可以根据自身需求，设置指定级别的告警使用不同的通知方式，也可以自定义工作时间，让告警在不同的时间段，用不同的通知方式。

告警智能化去重降噪

如果您前 3 步都已经完成了，那么这里面还存在一个问题，就是当告警大规模触发时，特别是遇到告警风暴的话，很容易撑爆邮箱或者是手机短信了，所以接下来就聊下告警风暴规避的问题。这个问题比较大，基本上有些监控工具做了一部分，但是目前来看这还是一个难点：

目前，在 CA 平台中对于接收到的所有告警第一步就是自动去重，就是根据告警的 Event ID 来判断是否合并，Event ID 相同的告警就会自动合并到主告警之中，这样的告警只会通知主告警，直到告警恢复/关闭。

当然 CA 并不满足于此，目前 CA 支持的智能降噪包括时间窗口智能降噪和实时智能降噪的通知前降噪以及高聚合智能算法和仿阅读智能算法的通知后降噪。这里面包括实时计算和离线计算，算法方面参考了相似度、决策树、分类等算法。以相似度来说：首先采集告警的多维度信息，包括时间、主机、服务、分组 hostgroups、应用 applications、标签 tags 等基本维度信息，计算不同告警之间相似度，如果达到阈值，如告警 A 和告警 B 有70%相似就关联起来。以相似度为例因为根据业务不同，各维度的权重，阈值灵敏度有些差异。

事件单记录和团队协作处理

如果告警量很大，告警后续处理和跟踪往往会依赖于外部团队（部门外或公司外）。但是监控告警粒度太细了，可能很多告警都是一个事情。如上面的告警风暴中，由于应用程序故障，引发引发了大量的异常，之后又产生连锁反应，其实就是一个事件，只需要处理一个事情就行。一般来说一线人员会采用邮件或者电话方式，直接通知对应负责人，但是这个就很难追踪和事后分析，所以一套事件管理机制。ITIL规范的事件 Incident 流程很有参考价值，事件工单需要：