有效运维的 on-call 机制

  1. 云栖社区>
  2. 博客>
  3. 正文

有效运维的 on-call 机制

oneapm_official 2016-06-20 15:40:42 浏览1967
展开阅读全文

[编者按]本文作者为陈伯龙,云告警平台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等,或者是通过zabbix/nagios的hostgroup, applications等字段打标签。这样在分派策略就可以进行(正则)匹配了。
    • 排班,7x24小时紧绷状态不是谁都能扛得住的,适当轮班缓解下压力。可以通过排班机制,白夜班,按周等模式进行轮流。

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

cmd-markdown-logo有效运维的 on-call 机制

分派升级

cmd-markdown-logo有效运维的 on-call 机制

排班管理

通知到位和及时响应

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

  • 邮件通知,简单有效,就是不够及时。
  • 短信方式,需要开发对接,目前很多公司都有自己的短信服务通道。要注意一个限制:部分运营商会限制一天相类似内容只能发送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条告警未处理。

cmd-markdown-logo有效运维的 on-call 机制

机器学习告警合并

事件单Incident的处理

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

  • 将批量告警转为事件工单,这里包括手动转发和自动匹配规则转发。
  • 手动生成事件工单,一般属于非告警类触发,如人工发现或用户投诉等引发的事件。
  • 事件工单包括影响范围、严重程度,两者的交叉矩阵影响到处理的优先级。包括分类、子类、自定义标签,分类和标记有助于后续的统计分析。
  • 责任人和责任组,分派到其他团队或个人,并通知提醒。

cmd-markdown-logo有效运维的 on-call 机制

事件单

影响范围 紧急程度 优先级
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机制建立后,通过告警和事件数据分析、建立起以数据指标驱动的团队文化,有机会和大家分享。

本文转自 OneAPM 官方博客

网友评论

登录后评论
0/500
评论
oneapm_official
+ 关注