颱風虛驚一場：產品經理如何像抗颱一樣，熬過至暗時刻

先說一句可能得罪人的話：你這輩子經歷的絕大多數「至暗時刻」，結局都會和這次颱風一樣——虛驚一場。而「虛驚一場」這四個字，比颱風本身更能害死一個產品經理。

今年第 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 分鐘，遲早會輪到你。