参照公司事故定级标准，填写确定的故障级别

填写故障是通过什么方式发现的，比如：监控，人工保障等。

【故障概要描述】

对故障进行概要描述，写清楚何时何系统因何原因发生什么故障，总体影响是什么（PV有损，服务拒绝还是功能错误？）

【故障关键时间点】

请按如下格式描述：

1，故障发生时间：yyyy-mm-dd hh24:mi

2，故障感知时间：yyyy-mm-dd hh24:mi

3，止损完成时间：yyyy-mm-dd hh24:mi

【故障影响和损失】

详细描述故障对业务造成的影响以及具体的损失数据，格式：
1，故障影响范围及程度说明
2，损失量情况
损失数据包括：流量损失、收入损失、流水损失、损失占当天的比例。

【故障原因分析】

描述故障根本原因，以及此原因导致故障发生的逻辑。如录入case时，故障根本原因未定位，可后续补录。如最终故障根本原因未定位，可填写原因未明。

【故障过程详情&问题&改进】

现象&处理

暴露的问题

改进措施

以时间顺序详细描述故障发生（诱发）、发展（扩散、隔离）、发现（监控、测试）、处理（止损）过程及其间系统的表现，重点关注诱发原因、扩散条件、止损动作、止损效果等关键要素，每句以时间开头，每个关键节点单独写一行。下面以历史case给出了示例：

描述对应“现象&处理”中暴露出来的问题，包括技术、流程、意识方面的问题。下面以历史case给出了示例：

针对暴露的问题，提出具体改进措施，每条措施需要包含五方面内容：针对的问题、措施具体内容、负责人、完成时间、措施落地效果计划如何验证或措施落地产出物。下面以历史case给出了示例：

2015年9月23日 13:27 BFE公共集群上线劫持统计功能，开始在所有机房进行单机发布回归，流量较小，监控无感知。
14:36 BFE单机房上线发布回归，此机房无糯米服务，糯米不受影响。

问题1：BFE和业务之间缺少联动信息通报。
问题2：公共集群分级发布未能覆盖其所有核心业务。

改进措施1：针对问题1，短期内强化BFE和业务之间的联动信息通报，BFE变更操作通知各个业务线，糯米关键指标变化通知BFE。***负责，****时间内完成，产出物：BFE和各业务条线信息通报机制文档。
改进措施2： 针对问题2，BFE分级发布的流程优化，关注重点产品线的业务部署，定制分级发布策略。***负责，****时间内完成，产出物：BFE分级发布流程优化方案。

15:37 BFE所有机房全量上线。
15:40 全量上线完成，糯米服务开始受到影响。

问题3：BFE上线有bug，测试阶段未发现。

改进措施3：针对问题3，强化测试环节，后续BFE协议相关的修改，都要联合业务线，针对核心做功能性case回归。***负责，****时间内完成。产出物：BFE与业务线功能性回归测试方案
改进措施4：针对问题3，BFE添加关键产品的业务指标，变更期间时时关注指标变化。***负责，****时间内完成，通过查看BFE关键产品业务指标及变化验证。

15:55 糯米业务波动监控预警发出，糯米运维和研发团队开始排查问题。
16:22 确认BFE有上线。

问题4：端上的服务质量检测能力不足：缺少快速定位手段

改进措施5：针对问题4，补充app端的监控，建设端上的可用性数据指标和异常判断能力。***负责，****时间内完成。通过展示app端的监控效果验证。

改进措施6：针对问题4，继续推动完成糯米依赖和自身服务变更数据的汇总，与糯米业务监控omon系统联动，提升故障定位效率。***负责，****时间内完成。通过展示与omon系统联动效果进行验证。

16:29 完成BFE配置回滚，同时糯米业务完成BFE故障预案(绕过BFE)，服务开始恢复。
16:31 服务全面恢复。

无

无

【事故责任认定】

描述最终决定的事故责任认定情况

【标准问题checklist】

下面是一些标准问题。如果在原因分析/改进措施中已经处理，请写上改进措施序号。对于没有处理的，说明为什么不需要处理。

1. 为什么会发生这个问题？design、coding、操作？
2. 为什么测试阶段没有发现?
3. 系统为什么不能容错？
4. 能不能更早发现问题？
5. 解决过程能否更快？
6. 怎么防止类似的事情发生？