Q1
他們的問法
不是「怎麼讓機器不要壞」，而是：
「既然機器一定會壞，那要怎麼做，才能讓看片的人完全感覺不到？」
兩種問法導向的行動完全不同：
| 常見問法 | 他們的問法 | |
|---|---|---|
| 問題 | 怎麼讓電腦不要壞？ | 壞掉時怎麼讓使用者感覺不到？ |
| 力氣花在 | 硬體、合約、災難手冊 | 讓服務之間不要互相牽連 |
| 怎麼算成功 | 壞了幾次 | 壞的時候有沒有人被影響 |
| 改變的對象 | 機器（改不了） | 自己的架構（改得了） |
✦
Q2
他們的分類
改不了
租來的機器會壞
改得動
一台壞了，會拖垮全部
放左邊的理由：要改變它，唯一辦法是自己蓋回全球規模的機房 ─ 代價大到不合理，而且本業不是蓋機房。
✦
Q3
他們的動作
2011 年，工程師 Greg Orzell 提出一個叫 Chaos Monkey 的程式。它做的事只有一件：
在真正服務客人的系統上，隨機關掉一台電腦。
而且是上班時間關。
而且是上班時間關。
三個看似瘋狂的設計，各有理由：
在正式環境，不在測試環境
只在測試環境殺主機，你證明的只是測試環境有韌性。
挑上班時間
半夜壞掉沒人在，痛感被拖延；白天壞掉，工程師立刻痛。而痛必須即時，否則「把系統改得更耐壞」永遠會被排在新功能後面。
隨機
可預測的演練會被準備。知道下週二要演練，你會先偷偷把系統調好。
它不靠開會、喊口號、寫規範來要求大家做好，
而是讓「做不好」這件事馬上會痛。
而是讓「做不好」這件事馬上會痛。
驗收拆成三關，規模由小到大
1
關掉一台電腦
剩下的能不能自動頂上？
Chaos Monkey
2
關掉一整棟機房
能不能自動搬到別棟，客人無感、不需人工介入？
Chaos Gorilla
3
關掉一整個地區
流量能不能整批搬到別的地區？
Chaos Kong
先在小規模證明可以安全模擬、建立信心，才敢做更大的演練。
點子從哪來：類比
疫苗
主動施加小劑量、可控的壓力來建立抵抗力（所以從殺一台開始，不是一上來就關整個地區）。
消防演習
不等火災才知道逃生動線有問題，而且有效的演習不會事先公布時間。
闖進機房亂扯線的猴子
名字本身就是一個類比。
✦ ✦ ✦
✦
但是 ─ 2012 年 12 月 24 日，聖誕夜
工具建好了，三個層級的演練也都在跑了。然後：
供應商那邊負責「把客人的連線分配到各台電腦」的系統出了問題。從下午 12:30 左右開始，影響持續擴大。
“
他們自己的電腦全都好好的、正常運轉。
但沒有任何客人能連進來。
- 美、加、拉美的電視連網裝置看不到服務
- 遊戲主機等裝置受影響約 7 小時，當晚 10:30 才大致恢復
- 他們的架構本來設計成能承受「單一地區內部分或全部機房故障」 ─ 跨三個機房運行，掉兩個仍能運作
- 關鍵細節：英國、愛爾蘭與北歐完全沒事，因為那些地區跑在不同的系統上
這是執行問題，還是問題定義問題？
是定義問題。他們那張「改不了 / 改得動」的分類表，漏掉了一格：「整個地區的入口一起出事」從來不在驗收範圍裡。
他們怎麼回應
他們沒有花力氣讓供應商不要再出包 ─ 那是限制條件。他們回到第一步，重新問一次：
「如果整個地區的入口都掛了，怎麼還能讓客人看片？」
新解法：把服務同時開在好幾個地區、平常就都在跑；一個地區出事，流量整批搬走。而且真的做了一次大規模切換測試：
18TB
跨地區搬運的流量
9Gbps
峰值流量
0 筆
超過一百萬次讀寫
零遺失
零遺失
然後把那次翻車的教訓，變成一個每天都在跑的常態演練。
✦ ✦ ✦
✦
比對討論
1你的路跟他們的路，第一個岔開的判斷是哪一個？
2他們的哪一個決定，你不同意？在什麼前提下，你的做法會比他們的好？
3如果把「租來的機器會壞」搬到右欄（當成改得動的障礙），會長出什麼完全不同的路？那條路在什麼情況下才是對的？
✦
✦
補充：後來模仿的人大多失敗了
Chaos Monkey 2012 年開源，被大量模仿。多數失敗的樣子是：
- ✓導入工具
- ✓排定每季演練
- ✓產出報告
- ✓把「每季 N 次演練」寫進 KPI
- ✕系統韌性沒有提升
兩層原因：
1
學的是動作，不是問題定義
他們敢隨機關機器，是因為系統早就被改成「壞一台也沒差」了。如果你的系統還是「一台壞全部停」，隨機關機器得到的不是韌性，是真的停業。
2
更根本 ─ 你的限制條件跟他不一樣
如果你的機器在自己公司、自己管、不會無預警壞，你根本不需要做這件事。
想看完整版
這份參考路徑的完整敘事、資料來源與更多脈絡，都在長文版。