Home | 简体中文 | 繁体中文 | 杂文 | Github | 知乎专栏 | Facebook | Linkedin | Youtube | 打赏(Donations) | About
知乎专栏

12.6. Incident Management(突发事件管理)

12.6.1. 突发事件处理流程

升级处理流程是指随着事态严重性,故障处理等级不断上升,此时运维已经解决不了,需要其他部门参与配合一起解决。运维是一线支持,测试是二线支持,开发是三线支持,最高级是四线支持,例如受到DDOS攻击,需要阿里云方介入,甚至公安机关参与。

12.6.2. 事件处理方式

很多人遇到突出时间,处理的方式是顺着惯性思维,简单而直接地做出反应,典型的 “事件 > 反应 > 结果” 连锁行为。例如:先重启一下服务,看看能不能解决。

这种不由自主或未经过思考的机械反应有时会导致灾难性的后果,还可能掩盖故障的真实原因。

更好的选择是:

			
事件 -> 结果 -> 反应
			
		

说白了就是,遇事想清楚再动手不迟。

12.6.3. 监控与警告分级

什么是有效的监控和警告?

如果监控警告信息不加分级,广播方式发送给所有人,当接受者每次看到的警告大部分跟自己无关,久而久之就不会在看这些信息了,当真正的故障出现,这些警告信息起不到任何作用,人们早已经不看它们。

三级:预警,例如CPU/内存/硬盘使用率达到 80% 这种警告只是提前通知运维做好准备,发给一线运维处理即可,甚至都无需通知到运维部门管理层。

二级:故障,例如硬件损坏,服务不可用,整体业务仍能服务,部分功能受到影响。

一级:事故,核心业务收到影响,整体不可用

12.6.4. 事故分级

12.6.5. 故障处理手册