一、背景

容器云平台本身比较稳定，但是外界有很多不可控因素，我们如何在突发情况发生时，采取最有效的行动，将影响控制在合理区间内，这就是我们“紧急预案”需要做的事情，也是稳定性建设工作中必不可少的一环，如果我们认为稳定性工作中排第一的是“预防处理”，那么排第二的肯定是故障发生后“及时止损”，预案建设和实施比较依赖工具，而且还需要不断有计划的“操练”，如果能将预案建设前置到产品需求设计中，就会有事半功倍的效果。

二、容器云平台异常问题排查之现状

容器云平台本身比较稳定，但是受到影响之后会发生各种异常：

• 数据中台占用带宽导致大面积延时
• 资源大户占用过多cpu和io导致其他服务卡顿
• 磁盘问题导致服务延时或者不可用

三、预案构成

一般情况下，一个完整的紧急预案，至少需要包含如下几个部分：
1.触发条件
执行预案的时机，一般从监控大盘、告警或者用户反馈告知感知故障后，通过预案设定的触发标准来决定我们是否需要执行预案、执行哪些预案。
2.执行步骤
预案执行过程，这里需要注意一点，预案的执行步骤是需要分角色的，不同角色分工不同：
（1）系统Owner负责操作回滚命令或者脚本来止损
（2）其他同学负责问题定位和查看监控大盘
（3）Team Leader需要组织团队内同学协作并且将故障处理进展同步给业务方和客服
具体的预案操作一定要“傻瓜化”，即任何同学只要有权限就都能轻易操作，当然得提前给一些同学配置好权限。
还有一点也需要注意，在整个预案执行过程中，如何观察执行的效果也很重要，可以提前配置好对应的观察大盘，并记录在预案中。
3.恢复步骤
等故障恢复后终止预案，是“执行步骤”的逆操作。
4.善后方案
为了保证故障对业务影响最低，维护云平台形象，一般故障修复后，我们需要对故障进行复盘，确保下次不再犯此类错误。
因此，在制定预案的时候能将常规善后方案和工具准备好也是很有必要的。

预案组成

四、预案的产品化

为了更有效的管理预案平台，云平台开始规划911预案平台，预案平台需要和运维体系全面打通，真正做到预案操作的可管控、可观察、可细分。

1.打通OAP观测平台

接到告警或者用户反馈的第一时间，借助于一键巡检机制快速的排查故障范围内的各个可疑点：
云网关是否正常
网络插件是否正常
pod是否正常
磁盘是否正常
etcd是否正常
......

2.拉齐自动化运维平台

借助于chatops能力和一键巡检机制定位的故障范围，通过自动化运维机制快速处理故障。