倫敦救護車服務 CAD 系統崩潰：34 年後回看代價最高昂的「正式上線」教訓
London Ambulance CAD collapse, 34 years on: the costliest “go-live” lesson
倫敦救護車服務於 1992 年 10 月 26 日在全市啟用新的電腦輔助派遣（CAD）系統，數小時內便因延誤、重複派遣及例外訊息陷入混亂。官方調查指出，軟件未完成且測試不足，備援未經測試，車輛狀態和位置資料不可靠，員工亦未受充分訓練。這次故障提醒軟件團隊，正式上線前須驗證備援，並保留人工判斷和介入方式。
A picture first.
On 26 October 1992, the London Ambulance Service put a new computer-aided despatch (CAD) system live across the city. Paper backups were removed. Controllers were told to lean on computer-generated allocations. The system was supposed to be faster and more accurate — within hours it drowned in delays, duplicate dispatches, and scrolling exception messages.
It wasn’t a simple “the computer crashed.” The official inquiry was blunt: the software was incomplete and under-tested; hardware resilience under full load hadn’t been proven; fallback to a second server hadn’t been tested; vehicle status and location data were unreliable; staff weren’t fully trained; and the control-room layout changed the same day, making mutual cover harder. Technically the system often “did what it was designed to do” — but the design assumed near-perfect live data. The real world doesn’t. Imperfections stacked until the service failed as a system. Semi-manual workarounds returned; around 4 November the system locked up for good.
Three reminders for anyone shipping software — or agents — into the real world:
💡 “Demo-ready” ≠ “production-ready.” Green checks in a demo don’t survive dirty data and peak load.
💡 Fallback is a feature. An untested rollback is no rollback. Paper backup, human override, and degrade modes are product, not afterthoughts.
💡 Automation must not erase judgment. When data goes bad, “more automatic” means “wrong faster.” Keep confirmation and override in the design.
Ever lived through a go-live that went sideways? Drop a lesson in the comments — not to scare, but to ship safer next time.
來源：DEV Community · dev.to