Series ID: EDKS-BASIC-ZH-0105 · Lesson No.105 · Expert Maintenance: Incident Learning
Incident Reports, Postmortems and Learning Reviews | 事故报告、复盘与学习回顾
A good incident report explains what happened clearly enough that the next team can act. A good postmortem explains why it happened clearly enough that the system can improve.
High-level professional English must handle failure without turning the document into blame, vagueness or self-protection. The goal is an accurate record: timeline, impact, evidence, contributing factors, decisions, ownership and follow-up.
高质量复盘不是“找一个人负责”。它要让团队看清：发生了什么、什么时候发生、影响是什么、哪些条件共同造成失败、下一步谁负责修复，以及如何验证修复真的有效。
Chinese Edition Hub · 中文版入口 · ← Lesson No.104 · Expert Maintenance Cycle and Deliberate Practice
The incident-learning map | 事故学习地图
- incident summary
- timeline
- impact
- detection
- response
- contributing factors
- root-cause claims
- corrective actions
- owners
- verification
1. Incident report vs postmortem | 报告 vs 复盘
An incident report records what happened. A postmortem analyses why and what to improve.
2. Learning review | 学习回顾
A learning review may be broader than a technical postmortem and can include process, communication, decision and organisational lessons.
3. Start with the summary | 先写摘要
Useful structure:
- what happened
- impact
- duration
- current status
4. Example summary | 摘要例子
From 14:10 to 14:47, customers could not complete payment. The issue affected the payment service only; login and browsing remained available. Service was restored at 14:47 and monitored for two hours.
5. Timeline | 时间线
Use absolute times and consistent time zone.
6. Timeline entries | 时间线条目
| Time | Event |
|---|---|
| 14:10 | alert triggered |
| 14:14 | on-call engineer acknowledged |
| 14:22 | suspected cause isolated |
| 14:47 | service restored |
7. Fact vs inference | 事实 vs 推断
Fact:
Error rate rose to 18%.
Inference:
This suggested a failure in the payment dependency.
8. Label suspected causes | 标记疑似原因
Do not call something “root cause” before investigation supports it.
9. Impact | 影响
State:
- users affected
- services affected
- duration
- financial/operational effect if known
10. Avoid dramatic wording | 避免戏剧化
Use measured language rather than “disaster” unless an official severity system requires such terminology.
11. Detection | 检测
How was the incident first noticed?
- automated alert
- customer report
- manual check
- downstream failure
12. Detection gap | 检测缺口
If users noticed before monitoring did, that may be a learning point.
13. Response | 响应
Who acknowledged? What action came first? Which action restored service?
14. Workaround vs fix | 临时方案 vs 修复
Separate:
- temporary workaround
- mitigation
- permanent corrective action
15. Contributing factors | 促成因素
Complex failures often have several contributing factors.
16. Do not force one cause | 不要强行找一个原因
Possible categories:
- technical
- process
- communication
- training
- tooling
- decision rule
17. Root cause language | 根因语言
Use only where the analysis supports a causal mechanism.
18. “Five whys” caution | 五个为什么的边界
Repeated “why” questions can reveal deeper conditions, but they should not be used to force a single linear cause in a complex system.
19. System conditions | 系统条件
Ask:
- What made the error possible?
- What allowed it to spread?
- What delayed detection?
- What prevented fast recovery?
20. Human action in context | 人的行为要放进情境
Instead of:
The engineer forgot the check.
Ask:
Why was the critical check dependent on memory rather than a reliable control?
21. Accountability still matters | 责任仍然重要
System-focused analysis should not erase ownership. Corrective actions still need named owners.
22. Blame language | 责备语言
Avoid motive claims and personal labels. Describe actions and conditions.
23. Weak sentence | 弱句
Someone carelessly changed the configuration.
24. Better sentence | 更好
A configuration change bypassed the review step because the emergency-change procedure did not require a second approval.
25. Counterfactual test | 反事实测试
Ask:
If this one action had been different, would the incident definitely not have happened?
If not, the explanation may be incomplete.
26. Corrective action | 纠正行动
Each action should have:
- owner
- deadline
- success criterion
- verification method
27. Weak corrective action | 弱行动
Be more careful.
28. Strong corrective action | 强行动
Add automated validation that blocks deployment when the configuration field is empty.
29. Action hierarchy | 行动层级
Stronger controls often change the system rather than relying only on reminders.
30. Prevention vs detection | 预防 vs 检测
- prevention reduces probability
- detection reduces time to discovery
31. Recovery improvements | 恢复改进
Sometimes the most valuable improvement is faster containment or rollback.
32. Verification of repair | 验证修复
Do not close an action merely because the change was implemented. Test whether it works.
33. Evidence of closure | 关闭证据
- test result
- monitoring result
- drill
- audit
34. Learning review questions | 学习回顾问题
- What surprised us?
- What worked well?
- What made recovery harder?
- Which assumption was wrong?
- What should change?
35. What worked well | 成功部分也要记录
Postmortems should preserve successful practices, not only failures.
36. Communication review | 沟通复盘
Check:
- owner clarity
- handoff
- escalation
- status updates
- audience fit
37. Decision review | 决策复盘
Ask whether the decision was reasonable given the evidence available at the time—not only whether the outcome was good.
38. Hindsight bias | 后见之明偏误
After the outcome is known, earlier uncertainty can look smaller than it really was.
39. Preserve historical context | 保留当时信息
Record what was known at each decision point.
40. Incident severity | 事件严重度
Use the organisation’s existing severity framework if one exists. Do not invent labels.
41. Customer-facing vs internal report | 对外 vs 内部
Public updates should be clear and accurate without exposing irrelevant internal detail. Internal reviews may need deeper method/process analysis.
42. Legal/compliance caution | 法律合规谨慎
Follow applicable organisational and legal requirements for records, privacy and disclosure.
43. Privacy | 隐私
Include only personal information necessary for the incident record.
44. Mandarin transfer: “复盘”不只是 review | 可根据功能选择 postmortem / learning review
Choose the English term by context.
45. Mandarin transfer: “责任人”常用 owner | 但要说明负责什么
Action owner is clearer than a vague “responsible person”.
46. Template | 模板
- Summary
- Impact
- Timeline
- Detection
- Response
- Contributing factors
- What worked
- Corrective actions
- Owners/deadlines
- Verification
47. Practice A | 练习 A
Turn a vague narrative into a timestamped timeline.
48. Practice B | 练习 B
Rewrite three blame sentences into mechanism-focused language without erasing ownership.
49. Practice C | 练习 C
Convert “be more careful” into a testable corrective action.
50. Error clinic | 常见问题
| Problem | Repair |
|---|---|
| Cause declared too early. | Label suspected cause. |
| Timeline vague. | Use absolute times. |
| Blame replaces mechanism. | Describe system conditions. |
| Action has no owner. | Name owner/deadline. |
| Fix implemented but not tested. | Add verification. |
51. First weak link diagnosis | 第一个卡点诊断
- facts unclear → timeline/evidence.
- why unclear → contributing-factor analysis.
- action vague → corrective-action design.
- same failure returns → verification problem.
- review becomes blame → language/process problem.
52. Seven-day training cycle | 七天训练
| Day 1 | timeline | 时间线 |
| Day 2 | impact/detection | 影响检测 |
| Day 3 | contributing factors | 促成因素 |
| Day 4 | corrective actions | 纠正行动 |
| Day 5 | ownership/verification | 责任验证 |
| Day 6 | learning review | 学习回顾 |
| Day 7 | full postmortem | 综合 |
53. Self-test | 自测
Write an incident report and postmortem that separate fact from inference, identify contributing factors, preserve accountability, and assign verifiable corrective actions.
54. For parents and teachers | 给家长和老师
This lesson can be practised with school projects, missed deadlines or team mistakes—not only technical incidents.
Teach learners to ask what the system can improve, not only who made the mistake.
55. Final real-world challenge | 最终真实任务
- Choose a real or fictional incident.
- Write a one-paragraph summary.
- Build timeline.
- Separate fact/inference.
- Identify three contributing factors.
- Record one successful response.
- Write three corrective actions.
- Assign owners/deadlines.
- Define verification evidence.
- Write a 700-word learning review.
Next: Lesson No.106 | 下一课
The next lesson develops model literacy: explaining what a model represents, which assumptions it depends on, where it works, and where its simplifications stop being useful.
Lesson No.106 · Explaining Models, Assumptions and Limits · 解释模型、假设与边界
Reference floor: expert-maintenance incident learning. Postmortems are treated as evidence-preserving learning systems, not blame documents.
