运维故障的分析在每个运维团队都是一个重点的事项,以史明鉴,尤其对于未经历过该故障新加入团队的成员起到很关键的作用,这一版故障管理系统并非首版,为什么需要再上一版这里做一下简要说明。
- 1、流程上的变化,目前企业微信通知已经取代短信变为主流,企业微信方式的通知在加大而增加了信息传递量的同时可以允许运维进行反馈式交互,可以更全面全面的记录一个报警或者故障的完整处理流程。
- 2、故障标签的管理,在上一版本中标签的管理是固定式的,当进行标签的变化时需要开发团队配合对系统进行升级,极大的限制了运维团队对于故障管理的灵活性
- 3、故障描述,大部分的运维人员对于一个故障的总结能力还是比较弱的,以大段的文字形描述一个故障从发生到发现到结束往往让人听的晕头转向
- 4、绩效,太多的绩效计算以及规则在使用几个月以后就让所有人搞不明白了,及时连产品设计人员都不能很明确的解释绩效的算法
基于以上的痛点,我们进行了新一版本的系统设计。
逻辑关系
报警-故障-紧急响应
报警引发故障,故障产生紧急响应,可能存在报警引发故障,或者多个报警同时指向一个故障,故障下可能存在紧急响应也可能不存在
报警处理
报警的发起采用网页端由专门的值班人员发起,处理由运维人员通过手机端企业微信APP处理
故障处理
当确定为一个故障后,待故障处理结束后有指定运维人员担任故障负责人,对故障进行全面的复盘与分析记录
紧急响应流程
如果存在紧急响应(3天内处理完成)则记录紧急响应,并标记完成情况
人员与组关系&业务与业务属性
系统设计组概念,每个业务下均有4种人员设置,允许设置组,方便业务轮值
时间点与时长关系
阐述一个故障的时长如何进行计算
标签与解释
固定标签与选填标签含义
角色定义
角色含义
状态
状态含义