运维五一不加班，从一套On-Call响应机制开始！

互联网技术的发展，离不开运维支撑工作，没有零 BUG 的程序，没有不出问题的系统，问题故障不可怕，可怕的是没能有序的处理故障。尤其对于有数字化服务需要始终在线的业务团队，一个流畅的应用服务增加了对技术团队的要求，要求他们随时准备提供响应。而对于不熟悉 On-Call 的团队来说，要想做到运维开发人员可以随叫随到可能会有一定的挑战。

在现实的运维场景中一旦突发紧急事件太多，团队成员会疲于应付，从而造成团队士气低下，效率低迷。而重要告警事件被淹没在大量重复而混杂的告警消息中，没有有序跟进处理，会引发严重业务影响。如何有效处理紧急事件驱动的工作，成为运维工作的重中之重。

而对于睿象云智能告警平台 Cloud Alert（以下简称：CA）来说，这一功能是我们平台的一个重要的组成部分，【精准分派相关人员】是我们智能告警平台的一个重要功能关键，可以帮助您与您的团队，促成一个优秀的排班计划，形成一个随叫随到的技术团队。睿象云经过多年与各类型的运维团队的沟通，围绕人、流程、工具三方面，形成了一套告警的全生命周期管理系统。

监控告警集中化管理

大多公司都使用了 Zabbix 和 Nagios、Open-Falcon 等监控工具去对自己系统中的硬件、网络、应用进行监控。

而这就会存在监控分散的问题：

• 遇到复杂环境的时候，就用到多个监控工具，如 Cacti 监控网络，Zabbix 监控应用和服务器；

• 如果存在有多个异地数据中心时，还需要同时部署多个 Zabbix 和工具；

• 部分关键业务，需要单独的开发监控脚本／工具进行独立监测；

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

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

建立支撑流程和机制

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

• 建立一线、二线甚至三线支撑团队，一线好理解，一般是 7x24 小时值班的同学们；

• 二线一般是资深工程师，或者是对应的应用开发／测试同学；

• 三线一般是主管或者是外部的厂家，如涉及硬件、IDC 机房等相关服务方。

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

1. 严重级别：如大范围影响业务／终端用户的，需要及时处理，一般要求多长时间响应处理，如3-10分钟有人响应，无响应立刻升级；2. 警告级别：影响范围和严重程度会低一些的故障，处理时长可以长一些；3. 提醒级别：依次更低。

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

而对于 CA 的用户来说即可用技术的方式实现：CA 可以通过分派策略、通知策略以及排班机制等，实现告警的灵活通知。

【自定义分派策略】可以进行流程的设计，根据级别、应用设置对应的一、二线负责人，以及处理时限，超时未响应（确认告警）自动升级。

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

多渠道通知必达

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

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

• 邮件通知：简单有效，就是不够及时；

• 短信通知：需要开发对接，目前很多公司都有自己的短信服务通道。要注意一个限制：部分运营商会限制一天相类似内容只能发送10－30条；

• 移动APP通知：适应移动大潮。微信方式，好处是人人都有，坏处就是告警消息和正常沟通消息会混淆；

• 电话语音通知：这个可以说是最重要的救命线了，电话通知可以应对特别重要的告警，例如晚上严重的电话通知；

• QQ、钉钉、企业微信、JIRA 等协作类工具：这一点属于彩蛋性质，找到团队的前后端共同来解决告警问题。
  
  

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

  告警智能化去重降噪

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

  • 静态规则方式：需要知识经验积累，根据业务逻辑梳理出一些父子关系。就比如出现服务器 Down 的告警，肯定该机器上的业务应用也会 Down ，那么就整理为一条规则。需要一套告警的过滤引擎，根据告警字段信息进行匹配；

  • 关联关系分析：依赖 CMDB，服务关联关系，根据调用依赖关系进行告警的根源追溯。CMDB 的建设和维护是非常困难的事情，数据准确性和实时性是决定 CMDB 效果的根本因素。CMDB 国内落地效果理想的很少，只能依赖自动化，微服务、docker、Devops 大量应用让IT环境更动态、更复杂，没有自动化机制保障是非常困难的；

  • 机器学习方式：相比前两种方式，机器学习更取巧一些，或者是说应该是未来的方向，可以节省大量人力物力。

  
  

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

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

  • 将批量告警转为事件工单，这里包括手动转发和自动匹配规则转发；

  • 手动生成事件工单，一般属于非告警类触发，如人工发现或用户投诉等引发的事件；

  • 事件工单包括影响范围、严重程度，两者的交叉矩阵影响到处理的优先级。包括分类、子类、自定义标签，分类和标记有助于后续的统计分析；

  • 责任人和责任组，分派到其他团队或个人，并通知提醒。