在新西兰时，我在电信公司 Spark 的网络运维部门干过一年。那份工作留给我的教训很简单：人会犯错，系统会宕机，而且专挑你没准备好的时候。你唯一能控制的变量，是事情发生时你准备到了什么程度。

让人敢承认错误：无责复盘

#

见效最大的改进不是技术层面的。要是犯错就挨罚，大家就会把错误藏起来，而被藏起来的错误，修复时间会比应有的晚上几小时甚至几天。一个能让人在几分钟内说出“是我搞坏的，我具体做了这些”的团队，恢复速度永远更快。事后的处理同样重要：别只把症状糊上就算完，要挖到根因，否则同一个错误会换张脸再回来。

这个“事后的处理”，就是无责复盘要做的事。只要是值得吸取教训的事故，就有人把它写下来：发生了什么、影响有多大、怎么修好的。这份复盘默认每个人在当时掌握的信息下都是出于好意行事，所以它不问该怪谁，而是问是什么让这个错误这么容易发生：少了一步确认、仪表板容易看错、根本没有运维手册。“工程师误在生产环境跑了数据库迁移”就变成了“部署脚本允许不经任何确认就在生产环境跑迁移”。写完之后要分享出去，让别的团队也能学到；最后列出行动项，每一项都有负责人和截止日期，不然它就会变成一份没人执行的文档。想看完整版，可以读 Google SRE 书里讲复盘的那一章 Postmortem Culture: Learning from Failure，书里还附了一份完整示例。

无责复盘模板

#

刚开始用下面这样的就够了。要短到大家真的愿意填。

# 复盘：<简短标题>
日期：YYYY-MM-DD · 作者：<姓名> · 状态：草稿 / 已评审

## 概要
两三句话：什么坏了、持续多久、怎么修好的。

## 影响
谁受了影响、多少人、多长时间。有没有丢数据或损失收入。

## 时间线
全程用同一个时区。
- 14:02 开始部署
- 14:09 第一条告警触发
- 14:15 开始回滚
- 14:21 错误率恢复正常

## 促成因素
系统、流程或工具里的哪些地方让这件事得以发生。不写人名。

## 做得好的

## 做得不好的

## 行动项
| 行动                 | 负责人 | 截止日期   |
|----------------------|--------|------------|
| 给迁移脚本加一步确认 | <姓名> | YYYY-MM-DD |

把犯错的概率先降下来

#

这里有三件无聊的事，能干掉大部分风险。一是别让技能生锈——错误最爱过时的知识，所以定期培训不是福利，是保养。二是把流程写成文档——很多“人为失误”其实是“含糊失误”：文档不存在，只好有人靠猜。三是把重复劳动自动化——让人把同一件事正确地做五百遍是强人所难，而计算机生来就是干这个的。在这些之上，凡是有风险的操作都多加一双眼睛：同事评审也好，按清单自查也好，都能在上线前拦下多到让人脸红的问题。

在大事来临之前把计划写好

#

先做一次诚实的风险评估：内部的薄弱点，比如 IT 基础设施；外部的威胁，比如自然灾害。实时监控要提前架好，那是你的预警系统。然后把计划写出来：应对各种业务中断的业务连续性计划（BCP），以及专门针对 IT 的灾难恢复计划（DR）。灾难恢复计划里要写清楚每个系统最多能停多久、最多能丢多少数据，也就是恢复时间目标（RTO）和恢复点目标（RPO）。

没演练过的计划只是猜想，所以要搞演习。谁在什么时候向利益相关方通报什么，也要提前定好——危机当中临场发挥的沟通，正是恐慌蔓延的方式。最后别漏掉那些不体面的杂事：跟当地相关部门保持联系，按时做维护，买对保险。

这些事没一件让人兴奋，大概正因如此才管用。能把故障处理好的公司不是运气好，只是趁一切安好时提前做了打算。