資料查證截至 2026-09-11。本篇以 Derek Sivers 的個人就醫經驗作為敘事起點，不把單一個案當成醫療體系品質的普遍結論；文中談到投資與家庭財務的部分，也不是個別投資建議。
摘要
- Derek Sivers 在 Bangalore 的就醫經驗很混亂：系統故障、臨時換醫院、原定手術醫師沒有出現，但他一直能換一條路繼續往前。
- 工程上的 reliability 也不是要求零故障。Google SRE 與 AWS 的做法更接近「預期故障、限制連鎖反應、準備 recovery 與 fallback」。
- 把這件事放回人生，我更在意的不是把 Plan A 排得多漂亮，而是工作、投資、家庭遇到意外時，自己還剩多少選擇。
最近讀 Derek Sivers 的 〈Bangalore India hospital flow〉，我一直記得其中一段。
他到 Bangalore 的醫院做檢查，到了現場才被告知系統當天掛掉，要他改天再來。他沒有等，直接搭車去另一家醫院。新的窗口一開始也說今天做不了，後來換了一位協調人員，檢查又全部做完。
幾天後，他原本排早上六點手術，五點就報到、換好衣服，醫師卻一直沒出現。等了四個小時後，他離開，重新找另一位醫師，後續手術順利完成。Sivers 把這種狀態叫做 Adaptive Systems：像水流遇到石頭，不會要求石頭消失，而是繞過去。
我不會把這段故事讀成「混亂比秩序好」。對病人來說，失約、資訊不透明和臨時變動都有真實成本；Sivers 自己的經驗也只是個案，不足以拿來比較不同國家的醫療品質。
真正讓我停下來想的，是另一件事：
一個系統可靠不可靠，不能只看它平常排得多整齊，還要看原本那條路斷掉時會發生什麼。
工程早就把「一定會壞」當成前提
做系統的人其實很熟這件事。
Google 的 SRE production best practices 不要求服務在任何負載下都維持完整功能。過載時，比較好的系統會降級服務、丟掉部分負載，保住還能完成的工作。另一章談 cascading failures 時更直接：重試如果沒有上限和 backoff，原本的小錯誤反而可能被放大，最後拖垮更多服務。
AWS 的 Well-Architected Reliability guidance 也把 recovery 當成設計本身的一部分。自動復原之外，還要能觀察 recovery 是否正在造成新的風險，必要時可以中止，並且準備無法自動修復時的 fallback playbook。
這些原則很樸素：不要假設每個 component 都會乖乖工作，也不要讓「救援動作」本身變成下一個故障來源。
最近在玩 AI agent，我對這件事特別有感。模型卡住、API 掛掉、context 爆掉、tool 回傳錯誤，這些都不是奇怪的例外，而是長時間運作後一定會碰到的狀況。真正麻煩的通常不是第一次失敗，而是失敗之後整條 workflow 就停在那裡，只能等人回來重新貼提示詞、重新交代一次做到哪裡。
所以我現在看一個 agent workflow，會比以前更在意幾件事：有沒有 bounded retry、失敗後能不能換 route、什麼時候應該 stop、以及人不在場時能不能留下足夠狀態讓下一個執行者接手。
這些東西不會讓 demo 變得比較炫，但會決定它能不能真的長期用。
投資也是在設計「錯了以後怎麼辦」
投資很容易把注意力全放在 entry。
買在哪裡、什麼訊號、哪個產業、明年 EPS 多少、目標價多少。
但任何 thesis 都可能錯。更實際的問題是：錯的時候，整個組合會發生什麼？
Investor.gov 對 asset allocation and diversification 的基本說明，就是把資金分散在不同投資上來降低風險。這當然不是說分散就不會賠錢，而是在承認一件事：我們不可能保證每個判斷都對，所以不要讓單一判斷有能力把所有選擇一起拿走。
同樣的想法也適用在交易策略。
停損、部位上限、槓桿限制、不同 regime 下暫停某些策略，看起來都像是在犧牲一點效率。行情一路照預期走時，這些限制甚至會顯得很多餘。
它們真正有價值的時候，是你看錯的那一天。
我現在比較喜歡把風控理解成：不是讓自己永遠不犯錯，而是讓一次錯誤不要順便取消下一次決策的資格。
家庭裡的 redundancy，不一定長得像備援伺服器
這個概念放回生活，反而更清楚。
CFPB 在介紹 financial well-being 時，核心不只是收入或資產淨值，而是財務狀況能不能帶來 security and freedom of choice，包括吸收 financial shock 的能力。
我很喜歡「freedom of choice」這個說法。
一筆沒有被投資出去的現金，看起來效率不高；行程留一段空白，看起來沒有把時間用滿；家裡有一個平常很少動用的備援方案，好像也有點浪費。
但這些東西買到的，可能是出事時不用立刻接受唯一答案。
工作突然改變時，不必在最慌的那幾天做一個不能回頭的決定；家裡有人臨時需要照顧時，行程還有調整空間；原本安排失效時，知道可以找誰、哪些事情可以延後、哪筆錢能先撐過去。
這些都不是「把人生規劃好」之後才需要的額外保險，它們本來就是規劃的一部分。
當然，備援也不是越多越好。工程上過多的 fallback 會增加複雜度，人生也一樣。永遠替自己保留十條退路，可能變成什麼都不願意承諾；持有太多閒置資源，也有機會成本。
所以我想留下的不是「凡事都準備 Plan B、Plan C、Plan D」。
而是一個比較簡單的檢查：
如果這條路明天突然走不通，我還剩下什麼？
如果答案是「整件事只能停住，等某一個人、某一個系統、某一個判斷恢復正常」，那它即使今天運作得很漂亮，可能也沒有想像中可靠。
Sivers 那篇文章最吸引我的地方就在這裡。表面上，他遇到的是一套不夠整齊、甚至讓人抓狂的流程；但他自己保有移動、退出、重選的能力，所以事情仍然往前走。
我們不需要把生活變成 Bangalore 的車流，也不需要崇拜混亂。
只是可以少花一點力氣追求「所有事情都照原定計畫發生」，多留意一件更實際的事：
當原定計畫失效時，自己是不是還有下一步。
參考資料
- Derek Sivers｜Bangalore India hospital flow｜2026-09-03
- Google SRE｜Production Services Best Practices
- Google SRE｜Addressing Cascading Failures
- AWS Well-Architected Framework｜REL13-BP05 Automate recovery
- Investor.gov｜Asset Allocation and Diversification
- Consumer Financial Protection Bureau｜Why financial well-being?