BCM-BCP-DRP-运维管理之故障管理——故障的分类与处理流程
ITSM
Business Continuity Manage(BCM)
Business Continuity Plan (BCP) 偏业务
Disaster Recovery Plan(DRP) 偏IT
天塌了，考虑在天塌了的状态下做什么，怎么开展业务就是BCP；
天塌了，考虑怎么把天撑回去，就是DRP。
DRP+BCP+供应链管理+危机管理等就是BCM (业务连续性管理)。
故障分类与应对；
线上事故处理流程1线: 对于一线服务台，同时也承担着客户服务的角色。在故障发现发生时，要做好客户安抚，客户反馈，客户协调，客户沟通等相关客服服务工作。
线上事故处理流程2线：
----------------------------------------------------------------------------------------------------
故障分类：
按级别：
p0
关键链路不可用，导致业务停止。
如：
数据库不可写
消息队列不可消费
etcd不可读
程序单点 agg，这是目前影响可用性的最大风险点
应对，目前中间件都是高可用版本，出现故障可做高可用切换。ucloud上的中间件服务及服务器高可用由ucloud提供协议保障。
灾难故障，ucloud数据中心不可用。目前没有灾备
此类故障主要解决方式就是切换，切换到standby
p1
系统一部分不可用，不影响业务最终结果，但会影响业务的响应时间，效率，吞吐。
次类故障要根据领域知识，针对性解决。另外，第一时间记录现场后，以类似重启置零的方式可以快速恢复业务做故障处理。
如果现场反应出了系统性问题和重复性问题，则做问题管理解决。
p2
系统可用，但性能下降，影响业务体验。
一般是某个细分的技术问题。但不会影响使用，比如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
