在新西兰时，我在电信公司 Spark 的网络运维部门干过一年。那份工作留给我的教训很简单：人会犯错，系统会宕机，而且专挑你没准备好的时候。你唯一能控制的变量，是事情发生时你准备到了什么程度。
让人敢承认错误#
见效最大的改进不是技术层面的。要是犯错就挨罚，大家就会把错误藏起来，而被藏起来的错误，修复时间会比应有的晚上几小时甚至几天。一个能让人在几分钟内说出“是我搞坏的，我具体做了这些”的团队，恢复速度永远更快。事后的处理同样重要：别只把症状糊上就算完，要挖到根因，否则同一个错误会换张脸再回来。
把犯错的概率先降下来#
这里有三件无聊的事，能干掉大部分风险。一是别让技能生锈——错误最爱过时的知识，所以定期培训不是福利，是保养。二是把流程写成文档——很多“人为失误”其实是“含糊失误”：文档不存在，只好有人靠猜。三是把重复劳动自动化——让人把同一件事正确地做五百遍是强人所难，而计算机生来就是干这个的。在这些之上，凡是有风险的操作都多加一双眼睛：同事评审也好，按清单自查也好，都能在上线前拦下多到让人脸红的问题。
在大事来临之前把计划写好#
先做一次诚实的风险评估：内部的薄弱点，比如 IT 基础设施；外部的威胁，比如自然灾害。实时监控要提前架好，那是你的预警系统。然后把计划写出来：应对各种业务中断的业务连续性计划（BCP），以及专门针对 IT 的灾难恢复计划。没演练过的计划只是猜想，所以要搞演习。谁在什么时候向利益相关方通报什么，也要提前定好——危机当中临场发挥的沟通，正是恐慌蔓延的方式。最后别漏掉那些不体面的杂事：跟当地相关部门保持联系，按时做维护，买对保险。
这些事没一件让人兴奋，大概正因如此才管用。能把故障处理好的公司不是运气好，只是趁一切安好时提前做了打算。