GitLab 2017
救命的是一份临时快照

B。这里有两个问题，而它们的紧迫性不一样。负载是眼前的痛，「为什么会有这个删除任务」是真正危险的问题——事实上它删的是一名员工的数据，起因是账号被恶意举报后误判 [S1]。一个能被外部人员触发、且会硬删除数据的自动流程，本身就是事故源。暂停它同时解决了负载和数据安全两件事。

A 是当晚实际发生的路径的近似：把注意力全放在压负载上。它的问题在于，删除任务跑完之后数据就真的没了——而且没有人在那个时刻问过"它凭什么在删"。故障处置里最贵的错误，往往不是做错了动作，而是没问一个问题。

C 是本能反应，也是本书反复出现的错误答案。扩容需要时间（第 5 章我们已经算过这笔时间账），而且它解决的是"扛得住"，不是"该不该发生"。给一个不该运行的任务扩容，等于花钱加速一场事故。

D 方向对，力度不够。限速能立刻缓解数据库压力，是个合理的止血动作——但它默认了"这个删除是应该发生的"。如果这个前提本身是错的，限速只是让错误发生得更慢。先暂停、再判断、最后才决定要不要限速重跑，顺序不能反。

B。这不是技术判断，是人因工程。四个半小时的连续故障处置之后，人对"我在哪台机器上"这类基础事实的把握会显著下降——而接下来要执行的恰好是一条不可逆的命令。换人的成本是十五分钟的交接，不换人的成本是 300 GB。事实上，那个"挂住"的真相正是由一位当时不在场的工程师后来指出的 [S1]：新鲜的眼睛看见了疲惫的眼睛看不见的东西。

A 就是当晚实际走的那一步，并且它的推理完全合理——工程师确实怀疑之前几次 pg_basebackup 在数据目录里留下了文件 [S1]。合理的推理 + 疲劳 + 两个长得一模一样的终端，就是这一夜的全部配方。请注意：这个选项之所以是错的，不是因为推理错了，而是因为它把一条不可逆命令交给了一个已经工作四个半小时的人。

C 的直觉非常好，但它在这一夜救不了场——它救的是下一夜。动手前先给主库留一个快照，正是「危险操作前先建立退路」的标准做法。它之所以只能算半对，是因为此刻主库并没有出问题，团队完全意识不到自己正在接近主库；真正让 C 有价值的，是把它变成制度：任何触碰数据目录的操作前一律先快照，而不是靠当事人当场想起来。

D 会让你更快地走到同一个悬崖边。「彻底重装」意味着更多的删除动作、更多次在两台机器之间切换终端，而你的判断力正在下降。判断力已经下降时，正确动作是减少不可逆操作的次数，不是增加。

B。关键区别在于让系统回答，而不是让人回忆。窗口标题、提示符颜色、你三分钟前敲的 ssh——这些都是记忆，而记忆正是凌晨最不可靠的东西。让机器当场打印出主机名和"我是主库还是从库"，这个事实无法被疲劳篡改。这也是为什么现代运维会给危险命令加"说出目标身份再确认"的护栏：护栏防的不是无知，是疲劳。

A 是绝大多数人的做法，也确实拦下过很多事故——但它拦不住这一次。当晚的问题恰恰是工程师确信自己在从库上 [S1]。当一个人已经确信时，再看一眼只会强化确信，因为你看到的是你以为会看到的东西。视觉确认对抗不了"我以为"。

C 是整页最危险的一个选项，因为它听起来最专业。命令来自手册这件事是真的，手册本身也没错。但手册假设你在正确的机器上——手册管的是「怎么做」，从来管不了「在哪做」。这一夜之后，GitLab 复盘里反复出现的正是这类"流程正确但上下文错误"的问题。

D 有价值，但它把一个 30 秒的问题变成了一个要等人回复的问题。凌晨的群里可能没人醒着，而等待本身会推着你去点那个回车。四眼原则的正确形态是阻塞式的——工具要求第二个人确认才放行，而不是靠你自觉去问。这一点在关卡三（Knight Capital）会以 4.6 亿美元的标价重新出现。