学完这一课，你能：
- 定义能反映系统是否健康的关键指标
- 用时间线和影响范围记录线上事件
- 把复盘结论转换成有优先级的迭代任务
1. 监控用户结果，不只监控机器
可用性用户能否进入系统
首页成功访问、关键接口成功率、证书与域名是否有效。
正确性核心流程是否成功
新增问题成功率、状态更新是否保存、数据是否一致。
速度用户是否需要等待
页面加载时间、关键请求耗时和慢操作数量。
错误哪里正在失败
前端异常、服务错误、失败请求和数据库异常。
容量资源是否接近上限
磁盘、内存、连接数与数据增长趋势。
业务结果系统是否真的有用
问题记录数量、解决周期、重复问题和长期未处理项。
第一版不需要几十个图表。优先选择能直接反映核心流程的 3–5 个信号，并为每个信号定义正常范围和需要行动的阈值。
2. 事件发生时先控制影响
- 确认影响谁受影响、哪些功能不可用、数据是否有风险。
- 建立时间线记录发现、发布、异常变化、处置和恢复的准确时间。
- 优先恢复服务能安全回滚就先回滚，避免在生产环境长时间试错。
- 保留证据保存日志、请求、版本、配置变化和关键截图。
- 恢复后再深挖根因把紧急处置与永久修复分开。
3. 复盘不找“谁犯错”，而找系统缺口
事件标题：____
影响范围与持续时间：____
用户如何发现：____
完整时间线：____
直接原因：____
根因：____
为什么现有检查没有提前发现：____
如何恢复：____
防止复发的行动项、负责人和期限：____
影响范围与持续时间：____
用户如何发现：____
完整时间线：____
直接原因：____
根因：____
为什么现有检查没有提前发现：____
如何恢复：____
防止复发的行动项、负责人和期限：____
行动项必须改变系统“下次更仔细”不是可靠行动项。更有效的是增加输入校验、自动测试、发布门禁、告警或可执行手册。
4. 用影响和证据安排迭代
| 候选改进 | 用户影响 | 证据 | 成本与风险 | 决定 |
|---|---|---|---|---|
| 保存失败显示具体原因 | 高 | 3 次事件均难以判断 | 低 | 本周完成 |
| 增加多人账号 | 未知 | 尚无真实需求 | 高 | 暂缓 |
| 状态更新自动测试 | 高 | 核心流程曾回归失败 | 中 | 下一版本 |
每次迭代仍要回到需求与验收标准。不要因为“技术上可以做”就自动增加功能。
结课交付 · 30 分钟
完成系统运行手册
- 列出 3–5 个健康信号、正常范围和行动阈值。
- 写出核心流程的冒烟测试与检查频率。
- 记录部署、回滚、备份和恢复步骤。
- 用模板模拟一次事件复盘，并产生两个可执行行动项。
- 建立下一版本清单：每项都写用户影响、证据、成本和验收标准。
三级课程结课自测
完成第三阶段
你已经拥有一条完整闭环：定义问题、设计路径、控制开发、验证发布、观察运行并持续改进。接下来最重要的不是增加更多技术名词，而是用这套方法完成一个真实项目，并让真实用户使用。