运维故障管理的思考（内含开源故障管理系统）

云栈技术CSTC
4,128 阅读4分钟
原文链接： mp.weixin.qq.com

检测故障、预防故障、处理故障、故障自愈、杜绝故障处理时扯皮

为什么要做故障管理

故障一般是指生产环境出现服务不可用、不稳定、服务性能降低等事件导致用户或玩家体验变差或功能不可用的问题;墨菲定律告诉我们:

  1. 任何事都没有表面看起来那么简单

  2. 所有的事都会比你预计的时间长

  3. 会出错的事总会出错

  4. 如何你担心某种情况发生，那么它就更有可能发生

无论故障发生的概率有多小，只要有出现的可能，它总会发生；同样海恩法则也警告我们：每一起严重事故的背后，必然有29次轻微事故和300次未遂先兆，以及1000个事故隐患，也就是说任何严重事故背后都是有很多次小问题的积累，当达到一定量级时就会导致质变，出现严重的问题；所以为了保证SLA，提前发现、准确定位、避免二次出现故障，解决责任界限不清晰，主导改进不明确等问题，甚至故障自愈，减少对项目的影响，我们需要一个规范可遵循的故障管理原则

故障管理目标

  • 减少故障，提升故障处理效率

  • 增强线上产品稳定性，提升SLA

  • 运维问题总结，作为知识库

  • 完善故障问题的检测监控

  • 为故障自愈提供依据

故障定级标准

为了衡量影响范围及影响程度，与PM、产品、开发共同确定统一的判断标准，避免后期复盘故障出现推卸责任及无所谓的问题。故障等级一般会根据MTBF(平均故障间隔时间，越长表示可靠性越高)、MTTR(平均恢复时间，越短表示影响越小)、MTTF(平均失效时间，系统平均正常运行多长时间，发生一次故障;可靠性越高，平均无故障时间越长)等作为衡量标准。根据我们游戏运营情况，按照影响玩家数量及故障时间来进行故障的定级：

  • S开头表示影响玩家的故障

  • T是指不影响玩家的故障

  • 1、2、3严重程由大到小

影响玩家 故障范围 故障级别
核心业务不可用(登陆、游戏、支付)，且影响用户>=15%在线;受影响集群不可用时间>4h S1级故障
核心业务不可用(登陆、游戏、支付), 且影响用户>=5%在线<=15%;1h<受影响集群不可用时间<4h S2级故障
游戏周边功能不可用且轻微影响用户;受影响游戏集群不可用时间<=1h S3级故障
不影响玩家 游戏周边功能不可用,但基本不影响用户正常使用 T1级故障
游戏周边功能可用,部分节点服务器故障等 T2级故障

故障管理流程

  1. 通过玩家反馈、监控告警以及计划内变更(如停服版本更新等),确认故障后，通知项目质量保障群

  2. 运维初步了解判断故障现象、范围及原因，通知开发、DBA等是否介入

  3. 根据故障影响确认处理优先级

  4. 定位、处理故障

  5. 故障恢复后，若重大故障，开发、运维、DBA等分析复盘故障

  6. 改进方案、是否需要完善监控、应急措施

  7. FMS故障管理系统记录故障：故障处理过程、改进措施等

故障分析报告模板：

故障自愈

针对未知故障，抽象检测脚本，在遇到二次故障告警时，通过Zabbix远程执行相关处理逻辑；可以参考蓝鲸的做法，将自愈作为套餐去消费

FMS故障管理系统

1. 功能模块

根据上述故障管理思路，开发了FMS故障管理系统，功能点如下图： 

2. 裸照

3. FMS项目

https://github.com/geekwolf/fms 有什么好的建议欢迎提issue~

avatar
文章
阅读
粉丝