运维故障管理的思考
文| Geekwolf
Geekwolf
《FastDFS分布式存储实战》作者,国内第一本《Ansible中文手册》译者、Flamingo、FMS作者
RHCA/RHCVA,混迹开源社区,专注高效运维、DevOps、Docker、MySQL
为什么要做故障管理
故障一般是指生产环境出现服务不可用、不稳定、服务性能降低等事件导致用户或玩家体验变差或功能不可用的问题。
墨菲定律告诉我们:
1.任何事都没有表面看起来那么简单
2.所有的事都会比你预计的时间长
3.会出错的事总会出错
4.如何你担心某种情况发生,那么它就更有可能发生
无论故障发生的概率有多小,只要有出现的可能,它总会发生。
同样海恩法则也警告我们:
每一起严重事故的背后,必然有29次轻微事故和300次未遂先兆,以及1000个事故隐患,也就是说任何严重事故背后都是有很多次小问题的积累,当达到一定量级时就会导致质变,出现严重的问题。
所以为了保证SLA,提前发现、准确定位、避免二次出现故障,解决责任界限不清晰,主导改进不明确等问题,甚至故障自愈,减少对项目的影响,我们需要一个规范可遵循的故障管理原则
故障管理目标
▲减少故障,提升故障处理效率
▲增强线上产品稳定性,提升SLA
▲运维问题总结,作为知识库
▲完善故障问题的检测监控
▲为故障自愈提供依据
故障定级标准
为了衡量影响范围及影响程度,与PM、产品、开发共同确定统一的判断标准,避免后期复盘故障出现推卸责任及无所谓的问题。故障等级一般会根据MTBF(平均故障间隔时间,越长表示可靠性越高)、MTTR(平均恢复时间,越短表示影响越小)、MTTF(平均失效时间,系统平均正常运行多长时间,发生一次故障;可靠性越高,平均无故障时间越长)等作为衡量标准。根据我们游戏运营情况,按照影响玩家数量及故障时间来进行故障的定级:
▲S开头表示影响玩家的故障
▲T是指不影响玩家的故障
▲1、2、3严重程由大到小
故障管理流程
1.通过玩家反馈、监控告警以及计划内变更(如停服版本更新等),确认故障后,通知项目质量保障群
2.运维初步了解判断故障现象、范围及原因,通知开发、DBA等是否介入
3.根据故障影响确认处理优先级
4.定位、处理故障
5.故障恢复后,若重大故障,开发、运维、DBA等分析复盘故障
6.改进方案、是否需要完善监控、应急措施
7.FMS故障管理系统记录故障:故障处理过程、改进措施等
故障分析报告模板:
故障自愈
针对未知故障,抽象检测脚本,在遇到二次故障告警时,通过Zabbix远程执行相关处理逻辑;可以参考蓝鲸的做法,将自愈作为套餐去消费
FMS故障管理系统
1. 功能模块
根据上述故障管理思路,开发了FMS故障管理系统,功能点如下图:
2. 裸照
3. FMS项目
https://github.com/geekwolf/fms
有什么好的建议欢迎提issue