“三步走”构建告警自愈能力,提升风险处置效率
案例供稿:王福强、陈星
文章来源:《华为云确定性运维案例集(第2期)》
一、业务背景
随着系统业务规模逐渐扩大,GTS云服务面临的告警量也逐步攀升,其中存在大量高频的基础告警,例如文件系统利用率过高等,仍依赖人工及时处理,投入产出比不高,但处理稍有延迟却可能造成重大故障。针对该问题,我们一直在探讨如何减少人力投入的同时,还能保障风险得到及时处理,支撑系统稳定运行。
二、业务现状
以某业务全年的告警为例分析,典型场景如下,其中部分告警例如VPN通道异常、run目录磁盘超80%、SQL拥塞等,处理措施非常标准和确定,可将此类告警定义为“确定性告警”。
然而对于此类确定性告警,当前处理仍然非常复杂,耗时长,投入人力高,导致告警处理不及时,且手工处理存在人因差错导致的不可控风险。优化前告警处理流程如下:
以某业务云地VPN通道异常告警为例,该告警每月上报500+,每月投入人力20人天,全年由于该告警未及时处理,导致客户地端无法正常访问云端,引发客户报障20+次,严重影响客户满意度。
那如何在减少人力投入的同时,还能保证并提升告警得到及时处理?一般首先会想到通过自动化实现。仍然以云地VPN通道异常为例,一个通常的思路如下:
(1)开发脚本自动判断VPN通道状态并重置;
(2)在目标服务器上配置定时任务;
(3)由定时任务自动触发该脚本执行。
这种方案乍看可行,但海量运维场景下,一个脚本要部署和运行在成千上万台服务器上,管理和维护难度将难以想象。我们再回到确定性告警上,既然处理措施是确定的,那能否自动触发自动化任务?由此,故障自愈应运而生。
三、方案实践
一个标准的自愈流程应该在收到告警后,能够自动化执行自愈任务,检测任务是否成功,如果失败则需要自动派单以便人工接入处理,流程机制如下图所示:
继续以某业务VPN通道异常告警为例,自愈流程为:
(1)识别该告警为自愈场景告警,触发自愈任务;
(2)判断5分钟内该VPN通道是否触发过该规则的自愈,如果是,则本次不执行自愈并派单,以避免短时间内重复执行;如5分钟内未自愈过,则执行自愈策略;
(3)执行自愈任务,将该VPN通道重置;
(4)判断该告警是否恢复,如恢复则告警消除,如未恢复上报告警。
实现如上自愈流程需要构建告警模式库、构建自愈框架及平台、编排自愈资产,具体方案如下:
第一步:识别告警模式,建立告警模式库
一个完整的告警模式库分析维度可参考下表:
根据以上维度,分析出某业务当前有17类告警可以自愈。
第二步:构建告警自愈平台
为支持以上自愈机制落地,平台需具备以下能力:
(1)支持自愈场景编排:基于告警模式库定义自愈场景,支持SRE开发自愈处理脚本、API、原子能力等,结合业务场景,编排为场景化的自愈资产。
(2)自动化的自愈处理:具备自动化通道能力,支持根据匹配的自愈场景自动化执行。
(3)告警和任务状态通知:支持实时通知,及灵活的通知方式。
(4)异常处理和防呆:应支持任务容错和防呆,同一个自愈对象或自愈规则的任务能自动合并,任务超时控制等。
第三步:编排自愈场景资产
一个完整的自愈资产需包括:
(1)场景名称:自愈资产名称。
(2)触发条件:可自定义触发条件,可通过告警名称等多维方式进行匹配。
(3)自愈执行方式:自动/手动。
(4)自愈触发时间:时间延迟、指定时间范围、选择执行周期等。
(5)自愈对象:触发对象、自定义对象。
(6)自愈模板:特定场景原子能力、API、自定义脚本等。
(7)通知方式:通过及时通信软件、短信等发送通知,或者不发送。
四、 业务提升
自愈总体提升情况:自愈平台构建完成后,SRE将高频、重复、处理方式确定的告警通过自愈闭环,已实现60+自愈资产,覆盖文件系统利用率、SQL拥塞、实例/服务异常、VPN通道异常等10+大类15+子场景的告警场景,并已覆盖7个业务,优化后全年累计触发告警自愈次数10000+,月度告警自愈2000+次;
提升告警恢复及时性:实现分钟级告警自愈。
减少人力投入:当前已覆盖的15+类子场景月度2000+告警0人工介入;
以某业务VPN通道告警为例,自愈前后对比如下:
五、案例总结
本案例基于现网高频、重复、确定性场景的告警,结合运维经验及实践,实现告警分钟级自愈,提升告警处理的及时性,减少人力投入。同时告警处理是一个持续改进和运营的过程,自愈场景需要在运维实践中逐步识别和挖掘,自愈资产也会随着产品版本的优化而迭代和日落。另外,确定性场景的自愈仅是短期手段,SRE将继续积极推动研发实现相关产品缺陷在产品中改进,从根本上解决问题。
- 点赞
- 收藏
- 关注作者
评论(0)