资讯专栏INFORMATION COLUMN

有效运维的 on-call 机制

DirtyMind / 1170人阅读

摘要:如何有效处理紧急事件驱动的工作,成为特别是运维主管运维工作的关键。通知到位和及时响应。机器学习领域是未来的重要发展方向,目前我们还在摸索中。机器学习告警合并事件单的处理如果告警量很大,告警后续处理和跟踪往往会依赖于外部团队部门外或公司外。

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

正文

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

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

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

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

监控告警事件集中化。

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

通知到位和及时响应。

告警风暴关联合并。

事件单记录和团队协作。

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

监控告警集中化

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

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

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

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

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

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

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

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

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

建立支撑流程和机制

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

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

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

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

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

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

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

提醒级别:依次更低。

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

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

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

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

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

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

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

分派升级

排班管理

通知到位和及时响应

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

邮件通知,简单有效,就是不够及时。

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

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

电话,救命线,电话通知可以应对特别重要的告警,例如晚上严重的电话通知,目前这一点国内也有不少服务商,需要对接下。

QQ,钉钉、worktile等协作类工具,这一点属于彩蛋性质。

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

告警关联合并

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

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

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

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

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

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

机器学习合并,包括实时计算和离线计算,算法方面参考了相似度、决策树、分类等算法。以相似度来说:首先采集告警的多维度信息,包括时间、主机、服务、分组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 官方博客

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/7976.html

相关文章

  • 有效维的 on-call 机制

    摘要:如何有效处理紧急事件驱动的工作,成为特别是运维主管运维工作的关键。通知到位和及时响应。机器学习领域是未来的重要发展方向,目前我们还在摸索中。机器学习告警合并事件单的处理如果告警量很大,告警后续处理和跟踪往往会依赖于外部团队部门外或公司外。 编者按]本文作者为陈伯龙,云告警平台[OneAlert创始人,著《云计算与OpenStack》,在IT运营管理、云计算方面从业10多年。 正文 互联...

    binaryTree 评论0 收藏0
  • 中小企业 IT 运维福利:快速构建 on-call 机制

    摘要:避免手机网络不稳定引起的微信邮件移动不及时现象,基本上电话是不可抗拒的,除非关机。中小企业运维支撑同学就可构建一个团队,告警事件的处理会逐渐进入正轨,并有序处理。结束语这次新版本发布,已经实现两个中国领先通知渠道领先和接入监控平台领先。 大多 IT 运营支撑同学都有过深夜业务应用突然故障的经历,监控系统准确告警,但是白天筋疲力尽的运维同学在熟睡中,经常会遗漏告警提醒;往往是接到主管电话...

    fobnn 评论0 收藏0
  • 从鹿晗关晓彤恋情事件看维的节假日准备工作

    摘要:导语鹿晗关晓彤公布恋情,造成微博服务短暂不可用。业务运维团队负责业务的整体运维,包括业务规划架构部署容灾演练节假日保障等整体协作性工作。 作者:李雄政,10年+ 证券、电信、互联网领域开发、系统集成、运维经验。 现任腾讯高级工程师,负责社交平台业务运维组管理工作。 导语:鹿晗关晓彤公布恋情,造成微博服务短暂不可用。相关的运维们也不得不提前结束国庆假期,执行各种紧急扩容预案。 而腾讯S...

    zhaot 评论0 收藏0
  • 《跟阿铭学Linux》作者李世明:谈不上告白,就是帮女友转型而已

    摘要:年,阿铭开始为女友撰写电子版入门教程,到目前为止已经累计帮助数十万人。年创建阿铭培训,目前已经培训多期学员。创办阿铭培训班和猿课的初衷是什么最早仅仅是为了满足群里朋友的需求,通过录制一套视频,再结合我写的电子版教程,帮助群友学习。 本文仅用于学习和交流目的,不得用于商业目的。非商业转载请注明作译者、出处,并保留本文的原始链接:http://www.ituring.com.cn/art....

    Render 评论0 收藏0
  • 如烹小虾: 运维自动化闭环,腾讯是这样做的

    摘要:我加入了腾讯,腾讯企业文化很好,经常会有很多小组活动部门活动什么的,但是做运维很苦。所以,年的时候我们几个腾讯的同事一同创业,希望把我们的想法和经验能够传递出来。这里我列出了腾讯互联网运维团队所经历的三个阶段。 本文是数人云深圳技术分享课上优维科技联合创始人彭鲤航的演讲实录,演讲主题是《运维自动化实践》。 精彩观点抢鲜看 实现运维自动化闭环,最主要就是配置管理、状态管理和变更管理能力。...

    RyanQ 评论0 收藏0

发表评论

0条评论

DirtyMind

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<