前言：這篇文章想解決的問題
《密涅瓦的思考習慣訓練》第三章講「問題解決」，核心只有一件事——先「問問題」，才「想解方」。書裡舉了疫調工具、Grammarly、廠商延誤、育兒焦慮、線上遊戲限遊令五個案例，涵蓋公衛、學術、工作與教養。
但有一段書裡點到、卻沒有展開：
如果卡關了，再度回到問對問題的環節，找出真正要解決的問題，前方的路自然展開。
《密涅瓦的思考習慣訓練》· 第三章問題解決不是一條直線，是一個圈。 你可能問對了問題、分對了類、想出了解方，然後現實還是打你一巴掌——這時候該做什麼？
Netflix 的這個案例，剛好把整個圈完整走了一遍，包括那一巴掌。
這篇文章會用兩層來寫：先用生活語言說清楚發生了什麼，再對應回書裡的思考習慣。沒有技術背景也能完整讀完。
事情的開頭：三天，一片 DVD 都寄不出去
先說一件很多人不知道的事：Netflix 最早不是做線上看片的。
它是一家寄 DVD 到你家的公司。你在網站上點想看的片，他們就把光碟裝進紅色信封寄給你；你看完寄回去，他們再寄下一片。這在二〇〇〇年代的美國是個很大的生意。
2008 年 8 月，他們存放訂單資料的那台「大電腦」壞了。
資料損毀，整套系統癱瘓。全美 55 個出貨中心，連續三天寄不出任何一片 DVD。 週二完全沒出貨，週三勉強出了一些，週四又停擺。這是他們九年 DVD 業務史上最大的一次服務中斷。
全數停擺
任何一片 DVD
最大服務中斷
請注意，這不是「網站有點慢，使用者晚點再看」的等級。這是整門生意停止運轉三天。
問題出在哪裡？
他們把所有東西都放在同一個地方、押在同一台機器上。那台壞了，全公司就跟著停。
一家餐廳只有一個廚房、一個廚師。廚師病倒，整家店關門。
用專業一點的說法，這叫單點故障（single point of failure）——某一個環節壞掉，全部跟著壞。Netflix 自己事後的描述是：他們必須從「垂直擴展的單點故障」，轉向高可靠、可水平擴展的分散式系統。
換了戰場，麻煩換了形狀
那次事件之後，Netflix 做了一個當時很大膽的決定：不再自己養機房，改成跟 Amazon 租電腦。
也就是我們現在說的「上雲端」。（順帶一提，Amazon 後來自己也做串流，等於是把生意租給了未來的競爭對手。這個決定本身就很值得聊，但那是另一個故事。）
但租來的電腦，帶來一個新麻煩：
因為那是別人的機器。別人在維護、別人在調度、別人決定什麼時候把它下線。你管不到。
於是問題來到了真正的分岔點。
面對「電腦隨時會壞」這個現況，你會怎麼定義這個問題？
如果你正在讀這篇文章，這裡建議你先停一分鐘，想想自己的第一個念頭是什麼。
分岔點：一句話的差別，做的事完全不同
大多數人會這樣問
這是非常自然的問法。而且一旦問題被這樣定義，接下來的動作幾乎是自動長出來的：
- 買更貴、更可靠的機器
- 多買幾台備用
- 跟廠商簽更嚴格的合約
- 寫一本厚厚的「出事怎麼辦」手冊
- 建立更嚴格的變更審核流程
每一項都很合理，每一項都要花錢，而且——每一項都在對抗一件他們改不了的事。
Netflix 換了一個問法
他們往下多問了一層：我們為什麼要避免電腦壞掉？因為會員會拿不到 DVD、看不到片。那我們真正在乎的到底是什麼？
這兩件事聽起來幾乎一樣，但它們導向的行動完全不同。於是問題被改寫成：
兩種問法的差別
| 大多數人的問法 | Netflix 的問法 | |
|---|---|---|
| 問題 | 怎麼讓電腦不要壞？ | 壞掉時怎麼讓使用者感覺不到？ |
| 力氣花在 | 硬體、合約、災難手冊 | 讓服務之間不要互相牽連 |
| 怎麼算成功 | 壞了幾次 | 壞的時候有沒有人被影響 |
| 改變的對象 | 機器（改不了） | 自己的架構（改得了） |
注意最後一列。這才是關鍵。
這就是 #問對問題——界定初始狀態與目標狀態，以及兩者之間的障礙。而且書裡特別強調：這兩者不能只是形容詞，必須定義得越具體越好。
「壞掉時使用者感覺不到」是具體的、可以驗收的；「系統要更穩定」則是一個永遠沒有終點的形容詞。
整個案例最關鍵的動作：分清改不了的，跟改得動的
這是第三章的靈魂，也是 Netflix 這個案例裡最值得學的一步。書裡把複雜問題裡的東西分成兩類：
#限制條件
障礙
Netflix 的判定是這樣的：
這是限制條件（改不了，接受它）
為什麼歸在這一類？因為要改變它，唯一的辦法是自己蓋回全球規模的機房——花的錢跟時間大到不合理，而且他們的本業是給人看片，不是蓋機房。
這跟書裡疫調案例中「隱私權是憲法保障的基本人權，是最外圍不可逾越的限制條件」是同一個性質：不是不能碰，是碰的代價遠遠超過收益。
這是障礙（改得動，資源全投這裡）
這才是他們真正該動手的地方。機器壞掉之所以會變成災難，不是因為它壞了，而是因為其他東西全都依賴它，而且沒有備案。
與其祈禱廚師不要生病，不如改成有五個廚師——任何一個請假，客人都吃得到一樣的菜。
為什麼這一步這麼重要
因為多數人的浪費，都發生在拚命對抗一個改不了的東西。
書裡有一段話講得很好：當你可以先區分出問題現況中，哪些是你必須符合的限制條件、哪些是你有能力動手排除的障礙，你就會得到清楚的優先順序，不用再模糊地「平衡」兩種價值。
把限制條件當作一個限制，反而可以讓我們更把注意力放在解決限制條件以外的障礙。
— 劉劭穎
框畫出來了，你才知道力氣要往哪裡使。
想解方：把合理的想法，推向不合理的極限
問題定義好了，分類也做完了。接下來是「想解方」。
一般人接受了「機器會壞」這個前提之後，會做的事是：加強備援、寫好演練手冊、每季辦一次災難演習。
Netflix 沒有停在那裡。
書裡介紹 #捷思法（heuristic）時，提到幾種常見的發想方式，其中一種是「將合理的想法推向不合理的極限」。
機器偶爾會壞，我們要能應付。
如果機器「隨時都在壞」呢？
於是有了「搗蛋猴」
2011 年，主導雲端遷移的工程師 Greg Orzell 提出一個想法，後來變成一個叫 Chaos Monkey（混亂猴子） 的程式。它做的事只有一件：
而且是上班時間關。
第一次聽到這個做法的人，反應通常都是「瘋了吧」。哪有人主動破壞自己的生意？
但每一個設計細節，背後都有理由。
三個看起來瘋狂的設計
因為測試環境永遠跟真實環境不一樣。如果你只在測試環境殺主機，你證明的只是測試環境有韌性。
這是我覺得最漂亮的一步。半夜壞掉，沒人在，等隔天再說——痛感被拖延了。白天壞掉，工程師立刻痛。
而痛必須即時。否則「把系統改得更耐壞」這種事，永遠會被排在「這週要上的新功能」後面。
因為可預測的演練會被準備。你知道下週二要演練，你會先偷偷把系統調好，然後演練「順利通過」。隨機才測得到真實狀況。
這招真正厲害的地方
卡內基美隆大學軟體工程研究所的分析講得很直白：Chaos Monkey 讓 Netflix 的開發者在寫程式時，就持續處於一個「服務不可靠、隨時會出意外」的環境。這不只給了他們在異常條件下測試軟體的機會，更是用誘因逼他們去建構容錯系統，好讓自己的日常工作不那麼痛苦。
換句話說：
而是讓「做不好」這件事，馬上會痛。
以前「機器壞掉」是一年幾次的災難，現在變成每天都在發生的家常便飯。而人只要每天都會痛一次，就會想辦法讓自己不痛。
別一次玩太大：拆解到可以驗收的層級
「讓系統有韌性」——這個目標太大、太模糊。
這正是書裡批評「給孩子最好的」那種壞目標：沒有具體的定義，就永遠沒有達成的一天。
所以 Netflix 把它拆開了。書裡的說法是 #拆解問題：當問題規模太大、現在的主客觀條件無法解決，就拆成更小的處理單位。
他們拆成三層，而且是規模由小到大逐步推進的：
Netflix 自己說明過這個順序的邏輯：策略是先在「微觀的小規模混沌」中證明可以安全地模擬和測試，藉此建立信心，才敢執行更大規模的演練——所以是先做 Chaos Monkey，再嘗試 Chaos Gorilla，接著才是 Chaos Kong。
而且注意：每一關的驗收標準都是具體的、可以判定的，不是形容詞。
這一點對照書裡黃禮宏那個機械業的案例——「通過客戶驗收」被拆成「機器精度驗證 OK」「加工成品精度驗證 OK」「自動上下料系統連續運作 8 小時無異常」三個條件——是完全一樣的拆法。
這個點子從哪裡來的：類比
Chaos Monkey 不是軟體業原創的想法。它是從兩個完全不同的領域借來的。
疫苗
主動施加小劑量、可控的壓力，來建立抵抗力。
關鍵字是「小劑量」和「可控」——這也解釋了為什麼要從殺一台機器開始，而不是一上來就關掉整個地區。疫苗打的是減毒的病毒，不是直接讓你染疫。
消防演習
不是等火災發生，才知道逃生動線有沒有問題。而且真正有效的消防演習，不會事先公布時間。
還有那隻猴子本身
這個名字也是一個類比。想像一隻猴子闖進機房，隨機扯掉線路、破壞設備。挑戰在於——你要把系統設計成，就算有這種猴子隨時會出現，也還是能運作。
這是 #類比（analogies）——搜尋類似情境下已經有的解法，以特定方式比較兩件事物的相似性，就可以參考類似問題的解決方案。
如果只在「怎麼維護伺服器」這個領域裡找解法，你只會找到更好的備援方案。要跳出去，得去別的領域找。
做對了那麼多，聖誕夜還是掛了
這一段是整個案例最有價值的地方。
Chaos Monkey 做出來了。整套工具建起來了。三個層級的演練也在跑了。然後——
Amazon 那邊負責「把客人的連線分配到各台電腦」的那套系統出了問題。從太平洋時間下午 12:30 左右開始，影響範圍在下午持續擴大。結果是：
Netflix 自己的電腦全都好好的、正常運轉。
但沒有任何客人能連進來。
美國、加拿大、拉丁美洲的電視連網裝置看不到 Netflix。遊戲主機等裝置受影響約七個小時，直到當晚 10:30 左右才大致恢復。
英國、愛爾蘭與北歐地區沒有受影響——因為那些地區跑在不同的系統上。
Netflix 事後的檢討報告裡有一句話很關鍵：這次特別痛，除了時間點之外，更因為根本原因超出他們自己能修正的範圍——他們的應用程式明明都健康地跑著，只是沒有任何流量能到達。
用第三章的語言來說，發生了什麼？
他們原本以為自己已經處理完的障礙，其實有一部分被錯誤分類了。
他們的架構是設計來承受「單一地區內部分或全部機房故障」——跨三個機房運行，掉兩個仍能維持功能。
但「整個地區的入口一起出事」，不在他們原本的驗收範圍裡。
也就是說：他們對「哪些改不了、哪些該處理」的判斷，漏掉了一塊。
卡關了，就回到第一步
接下來 Netflix 做的事，才是這個案例真正的價值所在。
他們沒有把力氣花在「怎麼讓 Amazon 不要再出包」——那是限制條件，改不了。（這一點呼應書裡那個機械業的案例：與其花時間對付廠商，不如聚焦在自己真正要達成的目標。）
他們做的是回到最開始，重新問一次問題：
新的解法
把服務同時開在好幾個地區，平常就都在跑。一個地區出事，流量整批搬到別的地區。
而且他們真的演練了
這一點特別值得講。他們沒有寫完架構文件就宣告完成，而是實際做了一次大規模的故障切換測試：
沒有遺失任何資料
同時，Chaos Kong 也在這之後加入了工具箱——一個會隨機模擬「整個地區中斷」的程式。
這一段在教什麼
你對「哪些改不了、哪些改得動」的分類，會隨著現實給你的回饋而修正。第一次分錯不是罪過——分錯了卻不知道自己當初是怎麼分的，才是。
決策沒有絕對的對錯，只要你知道自己到底是怎麼做出來的，下一個決策點你都有捲土重來的機會。
《密涅瓦的思考習慣訓練》· 第三章Netflix 之所以能在七小時的災難後很快提出正確方向，正是因為他們知道自己當初的判斷邏輯是什麼，所以知道要修哪一格。
為什麼後來的模仿者大多失敗了
Chaos Monkey 的原始碼在 2012 年開源。之後這套做法被大量模仿，還發展成一個獨立的領域。
但多數模仿失敗了。 而且失敗的方式，跟書裡「限遊令」那個案例是同一個結構。
失敗的樣子長這樣
- ✓導入混沌工程工具
- ✓排定每季演練
- ✓產出演練報告
- ✓把「每季執行 N 次演練」寫進團隊 KPI
- ✕系統韌性沒有提升
這跟限遊令想改善遊戲沉迷、結果衍生出租號與在單位時間內課更多錢，是完全一樣的失焦。書裡把這叫做失焦風險：解決方案沒有真的改善問題，甚至製造了新問題。
為什麼會這樣？兩層原因
Netflix 敢隨機關自己的機器，是因為他們的系統早就被改造成「壞一台也沒差」了。他們還有完整的監控、有降級機制、有自動復原。
如果你的系統還是「一台壞全部停」，你去隨機關機器，得到的不是韌性，是真的停業。
這其實就是書裡那個「削足適履」的反向版本：把別人的鞋子硬穿到自己腳上。
Netflix 的前提是「機器會無預警壞掉，我管不到」。
如果你的機器在自己公司、自己管、不會無預警壞——那你根本不需要做這件事。
「每一個要素只要有所調整，後面的解方也會完全不同。」
問題不一樣，答案就不該一樣。
結語：這個故事在講什麼
四句話
對照表：這個案例用到了第三章哪些思考習慣
| 思考習慣 | 在這個案例中的對應 |
|---|---|
| #問對問題 | 不是「怎麼讓機器不壞」，是「壞掉時使用者怎麼感覺不到」 |
| #限制條件 | 租來的機器會壞——接受它，不投資源去對抗 |
| 障礙 | 一台壞了會拖垮全部——資源全投這裡 |
| #拆解問題 | 一台機器 / 一棟機房 / 一個地區，三個可獨立驗收的層級 |
| #類比 | 疫苗、消防演習、闖進機房的猴子 |
| #捷思法 | 推向不合理的極限：如果機器「隨時都在壞」會怎樣？ |
| 回到問對問題 | 2012 聖誕夜翻車 → 發現分類漏了一塊 → 重新定義問題 |
| 失焦風險 | 模仿者把「演練次數」當 KPI，複製動作而非問題定義 |
資料來源
- 01 Netflix 官方部落格：Completing the Netflix Cloud Migration about.netflix.com/en/news/completing-the-netflix-cloud-migration
- 02 Netflix TechBlog：The Netflix Simian Army netflixtechblog.com/the-netflix-simian-army-16e57fbab116
- 03 Netflix TechBlog：A Closer Look at the Christmas Eve Outage netflixtechblog.com/a-closer-look-at-the-christmas-eve-outage-d7b409a529ee
- 04 Netflix TechBlog：Isthmus — Resiliency against ELB outages netflixtechblog.com/isthmus-resiliency-against-elb-outages-d9e0623484f3
- 05 CMU SEI：DevOps Case Study — Netflix and the Chaos Monkey sei.cmu.edu/blog/devops-case-study-netflix-and-the-chaos-monkey
- 06 InfoQ：Netflix's Chaos Engineering to Advance Failure Injection infoq.com/news/2014/09/netflix-chaos-engineering
- 07 NBC News（2008 年出貨中斷報導） nbcnews.com/news/amp/wbna26202698