故障处理团队
- 故障指挥：
- 沟通人：
- 操作团队：
故障概览
以下数据都是从故障发生开始计算，故障恢复的定义是消除了对于所有用户的影响，全部以 minute 为单位
MTTD：故障从发生到发现的耗时
MTTR：故障从发生到恢复的耗时
MTTL：故障从发生到找到 root cause 的时间，可能是小于 MTTR 的
责任团队与其负责人，必需由责任团队的负责人打勾进行确认才会生效
|
故障级别
|
故障响应级别
|
关键词
|
主要原因（简洁概括）
|
定级标准（给出链接）
|
是否为工程师首先发现
|
MTTD（minute）
|
MTTR（minute）
|
MTTL（minute）
|
是否为低级故障 低级故障的分类定义
|
责任团队
|
受影响团队
|
|---|---|---|---|---|---|---|---|---|---|---|---|
|
xxx 团队 @xxx |
故障状态
简要描述当前处理的状态，尽量给出预计恢复时间
处理中
故障现象和影响范围
故障用户：
https://shimo.zhenguanyu.com/docs/t28BA3NU2KcHCcra
现象：
跟读失败，返回 401
范围：
绑定了国际手机号的国内版用户
直接原因:
国内版的海外用户，在请求接口的时候默认填的 productId 是 871，导致鉴权失败，返回 401 。
其他信息：
马来西亚用户没问题。新西兰用户跟读都失败。目前不确定国家不同导致结果不同的原因。
处理方案
- 建立故障处理企业微信群，并把二维码发到 「斑马-产品研发部」 与 「斑马运维」大群
- 鉴权服务把 local 逻辑下线，确认用户问题解决
- 语音组增加一个 default productId 用于且仅用于鉴权。
- default productId 为 513
- 鉴权服务 local 重新上线
故障过程
这里描述故障的过程，包括发现、排查和处理等事情的时间点（在处理过程中不需要很精确），例如:
- 20:10 左右收到家长反馈，TV 课进入之后黑屏无音视频
- 20:15 确定问题
- 20:38 修改问题数据，切换到回放
故障原因
描述故障原因。注意：在故障处理过程中恢复服务比找到原因更重要！
问题复盘
尽可能详细的分析故障的原因，分析原因应该努力避开主观和自负的假设和逻辑陷阱，从表象出发，沿着因果关系链条，顺藤摸瓜，直至找出问题的根本所在。例如一台机器不转动了，你就要问：
为什么机器停了：因为超负荷保险丝断了
为什么超负荷了呢：因为轴承部分的润滑不够
为什么润滑不够：因为润滑泵吸不上油来
为什么吸不上油来呢：因为油泵轴磨损松动了
为什么磨损了呢：因为没有安装过滤器，混进了铁屑这样我们可以得到解决方案，要安装过滤器，从根本上解决问题，而不是只是换个保险丝。
为什么 Code Review 发现不了这个问题 ?
为什么 自测/测试验收 不能发现这个问题 ?
为什么在大规模报障时不能及时定位?
故障是否有先兆？是否有机会在先兆阶段就消灭问题？
从数据监控上能否及时发现这个报障和影响范围？
之前是否有类似的故障？为什么之前的处理方案没有生效？
短期 TODO
务必遵守 SMART；需要有切实可执行的改进方案，避免我们在同样的问题上犯第二次错误。改进任务应当 @到具体的人，并且给出 check 时间点。
- 在此输入任务，用"@+人名"将任务分派并用"//"选择到期日
长期规划
重要但是相对不紧急的工作，不用设置任务勾选款