BCM-BCP-DRP-运维管理之故障管理——故障的分类与处理流程

ITSM

Business Continuity Manage(BCM)

Business Continuity Plan (BCP) 偏业务

Disaster Recovery Plan(DRP) 偏IT

天塌了，考虑在天塌了的状态下做什么，怎么开展业务就是BCP；

天塌了，考虑怎么把天撑回去，就是DRP。

DRP+BCP+供应链管理+危机管理等就是BCM (业务连续性管理)。

故障分类与应对；

线上事故处理流程1线: 对于一线服务台，同时也承担着客户服务的角色。在故障发现发生时，要做好客户安抚，客户反馈，客户协调，客户沟通等相关客服服务工作。

线上事故处理流程2线：

----------------------------------------------------------------------------------------------------

故障分类：

按级别：

关键链路不可用，导致业务停止。

如：

数据库不可写

消息队列不可消费

etcd不可读

程序单点 agg，这是目前影响可用性的最大风险点

应对，目前中间件都是高可用版本，出现故障可做高可用切换。ucloud上的中间件服务及服务器高可用由ucloud提供协议保障。

灾难故障，ucloud数据中心不可用。目前没有灾备

此类故障主要解决方式就是切换，切换到standby

系统一部分不可用，不影响业务最终结果，但会影响业务的响应时间，效率，吞吐。

次类故障要根据领域知识，针对性解决。另外，第一时间记录现场后，以类似重启置零的方式可以快速恢复业务做故障处理。

如果现场反应出了系统性问题和重复性问题，则做问题管理解决。

系统可用，但性能下降，影响业务体验。

一般是某个细分的技术问题。但不会影响使用，比如kafka重平衡，数据库qps下降，程序运行时间复杂度较高。

按领域：p0以下

系统故障

由ucloud提供相关协议服务。

中间件故障

针对领域知识进行处理

程序故障

编译发布新版

---------------------------------------------------------------------------------------------------------

问题管理：

磁盘满问题，磁盘是一种慢性消耗资源，对磁盘的消耗是可枚举的。那么在处置完备的情况下，只需要定期扩容，就可以解决这个问题。

磁盘满问题	收到报警-快速处理	常规处理	特别注意	关注异常	长久处理
磁盘满问题	收到报警-快速处理	常规处理	特别注意	关注异常	长久处理
存储密集型业务，数据库，文件存储等	登录机器执行df -hT 找出满的挂载使用du -sh ./* 查出哪个目录哪个文件占用多，进行删除。	定期清理日志，包括：系统日志 /var/log/message 数据库日志使用日志平台长期收集日志	一些临时存放的文件数据。当使用完及时删除。若未来一段时间内需长期使用，可放对象存储。	因为不恰当的程序或运维问题引发容量爆增，如程序bug大量打印日志。	按业务容量增长进行扩容
非存储	同上	同上	同上	同上
118复盘			1.删除了/data/enginebench下的样本，测试用的临时样本。 2.删除了/data/Malware下的下载样本。 3.清理了多余的引擎备份

----------------------------------------------------------------------------------------------------------

故障处理流程：

一，故障发现
用户主动反馈
1）C端用户反馈
2）产品反馈
3）业务反馈

观测系统发现
1）系统报警发现异常
2）服务日常巡检发现异常

故障确认
不管是收到报警信息，还是收到业务用户反馈，我们都需要进一步确认并验证服务或功能是否正常，

确认问题的同时通知反馈方我们正在跟踪处理。

二，确定问题边界。确定故障级别。
根据反馈信息，快速判断问题归属。
1）若是使用问题，直接通知反馈方。
2）若是服务问题，协调对应服务负责人一起排查。

确定故障主导人
故障主导人的作用
1）协调相关人员排查并处理故障
2）及时跟踪汇总故障处理进度
3）及时同步故障处理进度
确定故障主导人后，需同步出来
故障主导人：XXX
相关处理人：XXX、XXX、XXX
预计完成时间：
紧急处理方案：

三、故障分析
可根据经验来快速判断，若不能快速判断问题所在，则可结合观测系统日志，metric，trace，监控资源图来分析。

根据反馈信息，快速排查日志并分析定位问题。
注：可先根据提供的信息找到类trace id，然后通过trace id找到该请求相关的所有日志。

根据监控指标分析
包含主机，中间件，网络，系统资源等维度的监控分析。

四、故障处理进度同步
确认故障后，若故障非常严重，由故障主导人建立群聊沟通平台，把相关负责人和小伙伴都加入进来，

同时告知反馈方当前情况及解决预案或方案，让反馈方有心理准备，预留buffer时间做好应对措施。

如果不能及时解决，不要等待或死磕问题，请迅速联系其他同事或者把问题上报来寻求支持和帮助。

参考同步格式
@相关人员
故障主导人：XXX
相关处理人：XXX、XXX、XXX
预计完成时间：2022-4-22 20:00:00
紧急处理方案：如回滚/重启/紧急更新等。核心是必须要在最短时间内快速修复问题。
后续优化方案：提供彻底优化方案。
后续优化时间：xxxx-xx-xx xx:xx:xx

同步机制
每隔30分钟同步一次。
注：故障恢复后务必通知反馈方，告知问题已解决。

五、故障恢复
确认故障后，首先要做的就是恢复故障，常用手段如下：（可参考图片标红）

注：快速恢复时，对于应对手段需要找一个人进行review，以免着急修复出错，产生新的问题。

服务回滚
如果属于发版更新的代码BUG导致的问题，一般可通过回滚到上一个程序版本来迅速恢复。

重启
部分问题可以通过重启的手段来临时恢复，以保障系统的暂时可用，但后续还需有其他方法彻底解决问题。

紧急更新
在明确问题所在后，迅速修复代码，然后快速更新上线。

限流和降级
通过将部分非核心服务或接口进行降级和限流处理，来避免核心业务受到影响。

六、故障报告
首先要明确，并不是所有故障都需要写故障报告。如果能快速恢复且影响很小，就不用写。

故障报告格式
故障标题：YYYYMMDD-xxx引起xxx服务不可用
故障发生时间：
故障报告时间：
故障恢复时间：
故障持续时间：
故障影响范围：
故障等级：P0/P1/P2/…
PN故障处理人：xxx、xxx、xxx
故障责任人：xxx
故障描述：xxx
故障处理过程：xxx
故障原因分析：xxx
故障总结：xxx
后续改进：xxx (需确定任务、执行人、执行时间)

七、故障复盘
邀请参与人员：反馈人、部门相关同事。

故障处理过程回顾
需要详细的记录下故障发现的时间，什么途径发现的，用了什么样的排查手段，什么样子的处理流程，

处理过程中，几点几分做了什么事情，将整个过程都一一的记录下来。

故障原因分析
需要讨论分析故障发生的原因，这里的原因不是指表象的原因，需要剖析出问题的根源。

故障改进计划
针对当前故障要做哪些改进措施，应对类似问题，如何预防。给出可实施的方案以及时间计划。

同时对故障等级进行认定。
复盘后，可看情况发送邮件给相关部门和同事。

---------------------------------------------------------------------------------------------------------------------

故障报告：

一、故障问题概况
　　简要说明故障发生的时间、场景、当时系统环境、故障现象、影响范围
　　二、处理经过
　　如何快速恢复的，有没有什么遗漏
　　四、故障问题分析与现象解释
　　怎么样的过程，触发了什么问题，导致了现在的结果。

系统存在哪些问题漏洞。
　　五、改进方式
　　应用什么方式，以后就能杜绝这个问题

参考连接：

https://www.alaska.edu/files/oit/ITSM_Program/Incident-Management-Process-Description-v1.pdf