《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.2 云上大型赛事流程管理——7.2.1 基于业务影响的流程分级（上）： https://developer.aliyun.com/article/1226049?groupCode=supportservice

7.2.1.2 故障问题应急

云上大型赛事一旦产生故障，其带来的负面影响不可估量，甚至可能会有政治性影响。对于故障问题，必须争分夺秒处理，和时间赛跑，因此基于前中后台的把服务过程做重的普通问题处理思路已不再适用，必须设计专门的短平快的故障应急流程。

7.2.1.2.1 故障应急流程之一：故障上报及通报

在感知故障的第一时刻，由前线上报故障，并迅速拉齐所有的相关方一起实时讨论，这里的相关方指客户、前线、中台、产品、决策层等。前线需要能及时准确的传递当前情况，中后台需要能快速的给出技术止血方案及优劣势，供决策层决策。在每一个重大进展节点，例如故障发现、决策止血方案、实施止血方案、故障恢复，需要及时同步到各相关方，做到信息的一致性。

得益于阿里云的技术风险建设，我们有专门的故障处理工具"云鼎"，该工具可以基于故障情况，一键创建故障应急协同群，引入故障应急值守人员及决策者，并把当前进展及时通报给内部所有相关方，做到信息实时同步。

7.2.1.2.2 故障应急流程之二：故障应急原则

故障应急的第一原则为"止血快速"，即如何以最快的速度把故障抹平恢复业务，具体的问题根因可留待之后详细排查，应急处置过程中以恢复运转为第一要义。举一个简单的例子，当发生流量突增触发EIP限速引发丢包导致业务受损时，不必详细排查流量突增的原因，第一件事一定是先把EIP的带宽升配。

故障应急的第二原则为"协同"，故障的应急处置可能需要多个产品方参与，在这个过程中，各产品方需要协同合作，不仅仅考虑自己的细分领域是否故障，也需要有整体框架思维，以协同的方式一起参与快恢。

阿里云的应急协同工具"云鼎"，提供了产品化的故障应急协同相关能力，确保故障应急的高效、有序和透明。在一键拉起的故障应急协同群，提供了便于应急的签到响应、应急作战室、电话会议、邀请排查等相关功能，同时还提供了舆情聚类平台、GOC应急工作台、应急基础信息、应急看板作为底层支撑。

7.2.1.2.3 故障应急流程之三：故障复盘

复盘源于围棋术语。指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。当故障发生后，如果不及时去对故障的根因和处理过程进行复盘，很难保证下次类似的问题不会出现甚至扩大化，所以故障复盘对于故障应急流程非常重要。

复盘过程包括：过程回溯，即抽丝剥茧的检查本次故障发生原因、处置过程中各个团队如何处理、处理流程是否可以再优化等；问题剖析，即深层次剖析问题根因，是客户侧问题还是产品侧问题、有没有优化点、如何防范再次发生等；经验总结，即给出可落地的短期治标Action、长期治本Action、以及沉淀经验和教训等。