有效运维的 on-call 机制

[编者按]本文作者为云告警平台OneAlert负责人，著《云计算与OpenStack》，在IT运营管理、云计算方面从业10多年。

正文

互联网技术的发展，离不开运维支撑工作，没有零bug的程序，没有不出问题的系统，问题故障不可怕，可怕的是没能有序的处理：

1. 突发紧急事件太多，疲于应付，团队士气低下，效率不高。

2. 重要事情淹没在大量事件中，没有有序跟进处理，会引发严重业务影响。

如何有效处理紧急事件驱动的工作，成为（特别是运维主管）运维工作的关键。我接触了大量的各类型公司运维，从初创、中小、大型公司，总结和分享一些大多公司通用的on-call机制，帮助有序的处理紧急事件：

1. 监控告警事件集中化。

2. 建立多层次和职责划分的支撑团队。

3. 通知到位和及时响应。

4. 告警风暴关联合并。

5. 事件单记录和团队协作。

基本上都是围绕人、流程、工具三方面进行，参考了ITIL的管理思路，大家感兴趣也可以参考下，特别是其中的ITIL V3的运营管理。

监控告警集中化

大多公司都用了zabbix和nagios、open-falcon等监控工具，对硬件、网络、应用进行监控。可能会存在监控分散问题：

1. 环境比较复杂的时候，可能会用多个工具，如cacti监控网络，zabbix监控应用和服务器。

2. 如果有多个异地数据中心时，可能需要部署多个zabbix和工具。

3. 部分关键业务，需要单独的开发监控脚本／工具进行独立监测。
   如果没有集中告警机制，容易出现邮件满天飞的现象，也很难跟进和处理，邮件也容易遗漏。

告警集中化，就是所有的生产监控发现的告警事件集中到一起，这样我们盯着一个平台就够了，同样也容易分析问题，是不是相同和类似原因。

1. 能够直观掌握现有环境的状况。

2. 发现事件相关性的，有些问题有较强关联性的，如网络稳定性影响主机，数据库性能影响业务等。

3. 方便跟踪和后续的统计分析。

4. 集中处理，就不用查看各种监控工具了，效率更高。

建立支撑流程和机制

如果监控工具单一，集中化不是最必要的，如何有序处理才是最核心的。特别运维团队是3-5人到数十／百人，就很有必要梳理下支撑流程和响应机制了。

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

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

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

如果管理比较细一些，还会进行业务拆分，形成一个矩阵，例如一线、二线根据不同专业，如负责网络和负责不同应用的团队。
另外还要考虑告警严重的程度级别，进行差异化处理，要求严格的同学一般会建立响应级别[1-3]或[1-5]：

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

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

• 提醒级别：依次更低。

那么问题来了，规划和设计挺好，如何落地呢？目前看zabbix、nagios、open-falcon等监控工具更多是聚焦如何发现问题，支撑流程属于处理问题的范畴，或者是说管理范畴，这一点目前市面上合适工具较少：

1. 人肉方式：一个监控班，7x24值班，人为处理和通知。大多运营商和金融及其他超大规模公司的管理方式。

2. 技术实现方式：通过分派策略、标签识别、排班机制等：

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

   • 标签技巧，如何识别不同业务和应用，一般来说可以在告警的标题打标签，如[HOST][NETWORK]等，或者是通过zabbix／nagios的hostgroup, applications等字段打标签。这样在分派策略就可以进行（正则）匹配了。

   • 排班，7x24小时紧绷状态不是谁都能扛得住的，适当轮班缓解下压力。可以通过排班机制，白夜班，按周等模式进行轮流。

接触过一个互联网金融公司，设计了非常规范化的流程和P0-P5级别应急处理方案，涉及了网络、云平台、近50个应用研发团队。

分派升级

排班管理

通知到位和及时响应

再好的流程和设计，当时没有及时收到通知和处理，那么就会很郁闷了，最后一公里问题解决方式：

• 邮件通知，简单有效，就是不够及时。
• 短信方式，需要开发对接，目前很多公司都有自己的短信服务通道。要注意一个限制：部分运营商会限制一天相类似内容只能发送10－30条。
• 微信、移动APP通知，适应移动大潮。微信方式，好处是人人都有，坏处就是告警消息和正常沟通消息会混淆。
• 电话，救命线，电话通知可以应对特别重要的告警，例如晚上严重的电话通知，目前这一点国内也有不少服务商，需要对接下。
• QQ，钉钉、worktile等协作类工具，这一点属于彩蛋性质。

还支持几点：不同级别、不同时间段的设置，例如晚上严重的电话通知，白天工作时间就不用了。
这里面还存在一个问题，当告警规模大了后，特别是告警风暴的话，很容易撑爆邮箱或者是手机短信了，所以接下来就聊下告警风暴规避的问题。

告警关联合并

这个问题比较大，基本上有些监控工具做了一部分，目前看也是一个业界难题，简单来说：

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

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

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

我们目前做了一些尝试分享下：

• 时间序列合并，如同一个告警信息，每个几分钟发生一次，就会合并，直到告警恢复／关闭掉。

• 机器学习合并，包括实时计算和离线计算，算法方面参考了相似度、决策树、分类等算法。以相似度来说：首先采集告警的多维度信息，包括时间、主机、服务、分组hostgroups、应用applications、标签tags等基本维度信息，计算不同告警之间相似度，如果达到阈值，如告警A和告警B有70%相似就关联起来。目前没有一种算法是最合适的，以相似度为例因为根据业务不同，各维度的权重，阈值灵敏度有些差异。例如某些应用的机器名规范化很高，如portal_mysql_master,portal_mysql_slave1,portal_mysql_slave2之类的，机器名权重可以高一些。机器学习领域是未来的重要发展方向，目前我们还在摸索中。

• 通知合并，瞬间告警通知量大的情况下，降频合并发送通知，如有16条告警未处理。

机器学习告警合并

事件单Incident的处理

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

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

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

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

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

事件单

影响范围	紧急程度	优先级
1-高	1-高	1-关键
1-高	2-中	2-重要
1-高	3-低	3-普通
2-中	1-高	2-重要
2-中	2-中	3-普通
2-中	3-低	4-次要
3-低	1-高	3-普通
3-低	2-中	4-次要
3-低	3-低	5-待定

影响范围和紧急程度的交叉矩阵影响到优先级

小结

On-Call机制建立后，通过告警和事件数据分析、建立起以数据指标驱动的团队文化，有机会和大家分享。

OneAlert 是 OneAPM 旗下产品，是国内第一个 SaaS 模式的云告警平台，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有 IT 事件，提升 IT 可靠性。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客