🎯 什麼情境該想到我
當你「build 已經紅了好幾天，大家還是繼續往上疊新的 commit」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：在部署管線斷掉時建立一條虛擬安燈繩（virtual Andon Cord），類比豐田生產系統的實體安燈繩，讓系統快速回到綠燈可部署狀態。
由來（豐田原型）：在豐田工廠，每個工作站上方都有一條繩子，每位工人與管理者都受過訓練，在出問題時拉它（零件有瑕疵、需要的零件沒到、甚至工作耗時超過文件所載）。拉下之後組長會被通知並立刻著手解決；若問題無法在特定時間內（例如五十五秒）解決，整條產線就停下來，讓整個組織動員協助，直到發展出有效的對策。
這條的重點：管線早期與後期的處置要分開。
A. 管線「早期」階段壞掉（build、unit tests）→ 全面停線
- 只要有人引入的變更導致 build 或自動化測試失敗，在問題被修好之前，不允許新工作進入系統。
- 需要協助的人可以把任何需要的援手拉進來。
- 至少要通知整個團隊發生失敗，讓任何人都能修問題或 roll back 該 commit。
- 甚至可以設定版控系統，阻擋後續的 code commit，直到管線第一階段（builds 與 unit tests）回到綠燈狀態。
- 若失敗肇因於自動化測試產生的 false positive，該測試應該被改寫或移除。
- 團隊的每一位成員都應該被賦權（empowered）roll back 那個 commit，讓系統回到綠燈。
B. 管線「後期」階段壞掉（acceptance tests、performance tests）→ 不停下所有新工作
- 這時不是停掉所有新工作，而是由on-call 的開發者與測試者負責立即修復這些問題。
- 他們同時應該在管線更早的階段建立新的測試來攔截未來的回歸：在驗收測試中發現的缺陷，就寫一個單元測試來抓它；在探索性測試中發現的缺陷，就寫單元測試或驗收測試。
C. 可見性手段
- 建立高度可見的指示器，讓整個團隊都看得到 build 或自動化測試正在失敗：掛在牆上的 build 燈、熔岩燈（lava lamps）、播放語音片段或歌曲、警笛（klaxons）、**紅綠燈（traffic lights）**等。
書中提醒：這一步在許多方面比架設 build 與測試伺服器更難——那些是純技術活動，而這一步要求改變人的行為與誘因。
原文：「Whenever someone introduces a change that causes our build or automated tests to fail, no new work is allowed to enter the system until the problem is fixed.」（L5542–5543）
原文：「When later stages of the deployment pipeline fail, such as acceptance tests or performance tests, instead of stopping all new work, we will have developers and testers on-call who are responsible for fixing these problems immediately.」（L5569–5571）
原文（豐田原型的五十五秒）：「If the problem cannot be resolved within a specified time (e.g., fifty-five seconds), the production line is halted so that the entire organization can be mobilized to assist with problem resolution until a successful countermeasure has been developed.」（L1939–1942）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 不要對「後期階段失敗」也全面停線——書中明確區分兩種處置，全部停線會讓團隊很快放棄這個機制。
- 若測試本身不可信，安燈繩會被拉爆然後被無視；只自動化可信的測試是它的前提。
- 這是行為與誘因的改變，不是工具設定。Randy Shoup（前 Google App Engine 工程總監）強調的是「團隊目標優先於個人目標」、「我們的工作不只是寫程式，而是運行一個服務」。