台风虚惊一场：产品经理如何像抗台风一样，熬过至暗时刻

先说一句可能得罪人的话：你这辈子经历的绝大多数”至暗时刻”，结局都会和这次台风一样——虚惊一场。而”虚惊一场”这四个字，比台风本身更能害死一个产品经理。

今年第 9 号台风”巴威”昨夜往南拐了。它没有正面砸向舟山，而是减弱成台风级、朝着浙江温岭到福建霞浦一带的海岸去了。于是舟山、普陀这边，7 月 9 日就停掉的轮渡、取消的航班、连夜从锚地转移到沈家门西码头的那一船一船渔船，事后看，好像都白忙了。今天早上已经有人在群里说：“早知道不用连夜把船开走。”

停在这句话上。因为整件事最值得琢磨的地方，就藏在这句”早知道不用”里。

上一篇我写普陀山，说的是别去求观音替你挡台风，去修海堤——别把”没被命中”归功于神秘护佑，那是错误归因。这一篇接着往下走一步：海堤修好了，警报真的拉响的那一夜，你这个操盘的人，到底该干什么？

我的答案是：抗台从来不是一个动作，是三个连着的动作——台风来之前，做足准备；台风正中间，承担风雨；台风走之后，打扫垃圾。 这三件事，哪怕十次里有九次是虚惊一场，也一件都不能省。产品经理的至暗时刻，就是这么熬过去的。

一、台风来之前：你能从容，全是从前囤下的

至暗时刻里，最骗人的东西是”从容”。

你会看到有的人，系统半夜崩了、数据不对了、老板电话打进来了，他还能坐得住，一条一条把事情理清楚。你以为这是天生的心理素质，是临场发挥。不是。至暗时刻里的从容，没有一克是当场长出来的，全是平时那些”没有台风的日子”里，一点点囤下来的。

对一个做产品、做系统的人来说，“囤”的是些很具体的东西：一个随时能按下去的回滚开关；一套灰度发布，让你先放 1% 的流量出去试错，而不是一次性把 100% 的用户推下水；一圈监控告警，让你在用户骂之前先知道哪里出血了；一份写下来、而且真的演练过的预案；平时一点点攒起来的、还没到用的时候的信任和现金流缓冲。

这里的关键词是”真的演练过”。

2017 年 1 月 31 日，GitLab 出了一次到今天还被反复讲的事故。一个工程师深夜在错误的数据库上敲了一条删除命令，把生产库的数据删掉了。删库本身不算世界末日——真正让所有人后背发凉的是接下来发生的事：他们有五种备份和复制机制，结果排查下来，没有一种是真正能用的。自动的 pg_dump 备份因为一个配置错误，其实从来没成功跑过；备份失败本该发邮件告警，可那些告警邮件被 DMARC 设置静默拒收了，没人收到；Azure 的磁盘快照倒是有，但恢复起来要 18 个小时以上。最后把 GitLab 从悬崖边拉回来的，是一个工程师在事故前六个小时、碰巧手动打的一个快照。就靠这一个”碰巧”，他们才只丢了六个小时的数据。

这件事把”做足准备”这四个字的真正含义，血淋淋地摆了出来：你以为你修了海堤，台风来了才发现那是画上去的。 五种备份，听上去固若金汤，可没有一种被认真验证过、演练过。没演练过的预案不叫预案，叫许愿。你写在文档里的那句”我们有完善的容灾方案”，在台风来之前，和一句祝福没有区别。

更狠一点的做法，是干脆不等台风来。Netflix 养了一只叫”混沌猴子”（Chaos Monkey）的程序，它每天的工作，就是在生产环境里，专挑风平浪静的大白天，随机关掉几台正在服务的机器。听上去像自残，其实是最诚实的一种演练——与其等真台风来了才发现海堤是画上去的，不如自己天天放一条疯猴子进机房，把还没出事的系统先弄崩一次，看它到底补得上补不上。能扛过混沌猴子的那种从容，才是真的从容；没被这么折腾过的从容，都是运气还没用完。

所以第一层的”虚惊一场”就出现在这里：你囤的那些回滚、演练、备份，绝大多数，一辈子都用不上一次。用不上，会让你觉得白做了。但你换个角度想——你过的那些平安日子，不是命好，是准备买来的。 一个从不”白做准备”的人，只是还没轮到他而已。

二、台风正中间：你得站在最前面淋雨

准备做得再足，台风真扑到脸上的那一刻，还是会疼。这时候考的是另一样东西：承担。

危机正中间，一个操盘的人，有两件事是绝对不能做的——逃，和甩锅。

逃，是把自己藏起来，等风头过去；甩锅，是急着找”是谁按的那个按钮”。这两个动作，在当下都能让你舒服一点，但它们会同时干掉一样最贵的东西：你的团队还敢不敢往前冲。承担，说白了就是反过来做——站到最前面去，做那个当下最难、但必须马上做的决定。 先止血：该回滚就回滚，该下线就下线，该砍就砍，该认错就认错，该通知用户就别拖到明天。账，你先认下来。

还是 GitLab 那天。他们做了一件在今天看依然很反直觉的事：开着公开直播恢复数据库。 几千个人在线看着他们把删库的丑事、把五层备份全废的家底，一点一点摊开、一点一点修回来。这不是作秀。这是”承担”最硬的形态——我搞砸了，我当着所有人的面把它修好，我不躲。一家公司敢这么干，团队里的工程师才会知道：在这儿出事，第一反应是修，不是藏。

对照一下那种一出事就先开会追责的地方。事故一发生，所有人第一件事是想怎么撇清自己，日志赶紧备份、聊天记录赶紧截图、“这个模块不是我负责的”脱口而出。承担的反面不是慌乱，是推卸。 一个把责任往下推给团队、往外推给”运气不好”的人，风停之后大家记住的，只有他缩在后面的那个背影。

这一段是三件事里最难的，因为淋雨是真的冷。半夜三点，事情还没头绪，所有眼睛都盯着你，那种滋味不好受。但你的团队那一刻看的，从来不是你慌不慌、有没有标准答案——他们看的是,火最大的时候,你是往前站了一步,还是往后缩了一步。 至暗时刻真正在称量的，就是这一步的方向。

三、台风走了之后：满地垃圾才是真考场

台风过境，天放晴了，最危险的松懈也就来了。很多人扛过了风雨，最后却死在”懒得打扫”上。

风停之后满地的狼藉，才是真正见功夫的地方。打扫，不只是把摊子收拾干净、让系统重新跑起来——那只是恢复。真正的打扫，是把这一次的疼，变成一条下次不会再踩的规则：复盘要复到机制上，把这次的教训，变成下次自动生效的一道校验、一个删掉的隐患、一份更新过的预案。

Knight Capital 就是死在没打扫上的。2012 年 8 月 1 日早上，这家做高频交易的公司上线一段新代码，工程师手动往 8 台服务器上部署，漏了 1 台。偏偏那台服务器上，还留着一段早就废弃、却一直没人删掉的旧功能代码，代号”Power Peg”。新代码复用了一个和它同名的开关，于是在那台没更新的机器上，这段本该躺在坟里的死代码被唤醒了，开始疯狂地往市场里发订单。45 分钟，成交了将近 4 亿股、涉及 154 只股票，税前亏损 4.4 亿美元。这家公司当年年底就被收购，没了。

你看这条链子有多短：一段本该删掉、却懒得删的废代码，加上一次没有校验、漏了一台机器的部署，直接要了一整家公司的命。 这就是”不打扫”的极致——垃圾留在系统里不会自己消失，它只是安静地等一个把它点着的火星。

再回头看 GitLab。同样是能致命的事故，他们事后写了一份公开到近乎自虐的复盘报告，把五层备份每一层是怎么失效的，一条一条列清楚，然后逐条去修。一个把垃圾扫成了免疫力，一个把垃圾留在原地等它爆炸。两家公司今天分别是什么样子，你也知道了。

打扫还有一个特别容易做反的地方：扫机制，别扫人。 复盘的目的是让”下次这个坑会自动被填上”，不是揪出那个倒霉的按错按钮的人。你一旦开始揪人，所有人学会的第一件事就是下次出事先藏；你只修机制、不问是谁，大家才敢在第一时间把问题喊出来。这套”对事不对人”的复盘，最早不是互联网发明的，是从航空业里长出来的：一架飞机掉了，调查组的全部目的，是让同一型号的飞机以后不再从天上掉下来，而不是把那个飞行员钉在耻辱柱上——因为只要开始钉人，下一个犯错的机组就会选择瞒，而瞒会让下一架飞机掉得更惨。Google 后来把这套东西写进了它的 SRE 手册，起了个名字，叫”无指责复盘”（blameless postmortem）。GitLab 那个删库的工程师没有被公开处刑，这不是心软，这是清醒——疼过一次不算成长，把疼变成一条不会再犯的规则，才算。

四、回到那句”早知道不用连夜转移”

现在再回到开头，回到今天早上那句”早知道不用连夜把船开走”。

这句话，其实是上一篇那个错误归因的镜像。上次，人们把”平安”归功于观音的护佑；这次，人们把”平安”归功于”本来就不会出事”。一个把功劳记给菩萨，一个把功劳记给运气——两个都在悄悄地，替你取消掉下一次的准备。

可真相是：绝大多数”虚惊一场”，恰恰是准备成功的样子。 一个组织如果它这些年从来没经历过一次”白忙一场”，只有两种可能——要么它在骗自己，把每一次侥幸都当成了”我们系统没问题”；要么它已经真的被掀翻过一次，付过血的学费。Knight Capital 没有”虚惊一场”过，因为它把上线前每一次没出事，都读成了”流程没毛病”，一路读到那 45 分钟。

台风”巴威”这次往南去了，舟山大概率能平安过去。但让那些渔民今晚睡得着觉的，不是台风临时改主意的那点心情，是昨夜连夜从锚地开走的那些船。

下一个至暗时刻会不会正面砸下来，你决定不了。你能决定的，只有那三件抗台的人从不落下的事：台风来之前，把海堤修到真能挡浪、而不是画在纸上；台风正中间，站到队伍最前面去淋那场雨；台风走之后，把满地的垃圾扫干净、扫成一条以后不会再犯的规矩。这三件事做全了，别人会说你运气好；这三件事偷懒了，Knight Capital 那 45 分钟，迟早会轮到你。