【手冊驗證不足、缺乏全局判斷、無必斷備案的三大教訓】日本KDDI七二大斷訊教訓的3堂課

日本第二大電信公司KDDI在7月29日公布七二全國大斷訊事故調查報告，每個看到報告的人，第一時間都想問，為何一個設定出錯，會造成如此嚴重災情？在日本三千萬名KDDI用戶將近3天沒網路也不能打電話，KDDI這起當機事故，更是日本有史以來最大規模的一次通訊中斷事故。

但是，如果進一步深入探究，這一起重大通訊中斷事件，不單是人為疏失那麼簡單，更是一連串連鎖反應影響加乘下的結果，可從3大面向來看，也是造成KDDI大規模又長期災情的三個教訓。

教訓1：過度依賴紙本手冊，又沒有更有效驗證方式來防呆

KDDI事故發生後，隔天上午的記者會中，由負責技術統籌的KDDI技術管理總部本部長吉村和幸親自解釋，引發全日本這起電信大斷訊事故的源頭，就是VoLTE系統在全國IP傳輸網路中的設備發生故障。這臺設備，是KDDI在東京都多摩地區設置的核心路由器，用來連接行動網路與該地區VoLTE網路節點很重要的通訊設備。

事故當時，KDDI正在對核心路由器進行硬體變更，將舊的核心路由器更換成新版本，KDDI發現後立即切換回原本的舊版本設定，事後也展開調查。經過幾天，KDDI排除硬體故障，研判是路由器設定出錯。7月29日更詳細的事故調查結果出爐，確定設定失誤的肇因，是現場作業人員拿錯維護手冊，才在新路由器中選了錯誤的設定。

一般來說，電信營運商遇到重要系統或設備更新，通常會先在測試環境經過測試驗證確認沒問題後，才部署到正式環境中，包含制定完整更新步驟、步驟失敗的回復機制，以及所有檢驗清單的測試等。在制定更新步驟中，維護手冊就是維運人員用來維護或更新設定的那本操作手冊。

但是，KDDI有兩本維護手冊，一本是新程序手冊，用來設定新型路由器，另一本舊程序手冊則適用於舊型。維護人員需依據機型的新舊，來決定使用哪一本手冊。舊程序手冊中描述的指令，只適於舊機型，不能用在新機型。

但是，在這次釀災的更新時，維修人員拿了舊手冊來設定新款路由器，甚至當事人沒有發現手持的手冊不是新版，而是舊版本，就用了舊款設定來設定新機款。

這就導致，這臺核心路由器一啟用就出狀況，這個人為設定失誤，造成了路由配置出錯，才出現了非預期的狀況，只能傳送上行資料，而下行資料就不通，造成通訊失靈。

這是一起人為操作失誤的事故。使用了舊版手冊，才造成這次設定出錯的原因。KDDI過去也曾發生過因為維護手冊內容的錯誤，而導致設定出錯的大規模災情事故，事後訂定了一整套確保手冊內容正確性的驗證和檢查程序，不論新版或舊版手冊的內容雖然各自都正確無誤，但是，這些維護手冊只有實體而沒有數位化，僅靠人員目視判斷所拿的手冊版本是否符合要設定的設備款式，而沒有採用系統化的檢驗，就沒有第二道確認機制，阻止這類拿錯手冊的風險。

KDDI過度依賴紙本手冊，但又沒有一套更有效的驗證方式，才導致設定出錯。這正是KDDI得到的第一個教訓。

但是，設定出錯只是導火線，就算造成單點故障，還是可以透過高可用架構、冗餘設計等做法來避災，然而，此事故並非單點故障，而是由滾雪球般的多點事故，還有更致命的原因，放大了這次的災情。

教訓2：過於聚焦單點故障，缺乏整體判斷錯失救援時機

KDDI在路由器故障後15分鐘，就退回舊版設定試圖恢復運作，但是，這決定沒有解決問題，反而引發更大的連鎖反應，從單一地區VoLTE網路節點壅塞，擴大到多個地區VoLTE節點也跟著壅塞，進而衍變成全國大規模災情。

造成連鎖性災情的關鍵點，是用戶資料庫的重新註冊行為。由於手機連上VoLTE系統須先註冊才能啟用通話功能，這些註冊資料都會寫入到用戶註冊資料庫中。在退回舊版設定後重啟設備時，多摩地區所有手機都必須重新註冊才能通話，但同時註冊對用戶資料庫帶來爆量寫入和查詢請求，塞爆了這個全國性的資料庫，進而影響了更多地區的手機註冊行為，引發一連串的連鎖反應，產生了訊令風暴（Signaling Storm）的危機，也就是，不同層網路之間的狀態不一致，導致大量終端裝置重複註冊引發連鎖效應，造成整個系統崩饋。

從KDDI事後數據顯示，當時流量不到幾分鐘就突然暴增7倍，只要1分鐘就能塞爆VoLTE系統。

這種訊令風暴也是所有電信業者最擔心、也最不想遇到的災情類型，因此許多大型電信商都會有一個何時會發生訊令風暴的判斷依據，來提早發現可能的問題，避免造成更嚴重的海嘯災情。

但是，KDDI一開始沒有判斷出這次是訊令風暴危機，以為只是單點故障的災情，因而錯失了阻斷這場風暴的黃金時機，如果能更早發現，在還沒對系統運作造成全面影響前，就先啟用用戶分批進入系統的程序，或許就有機會可以把災情降到最低。

KDDI雖然後來開始採取分流措施，希望將流量導到其餘地區VoLTE網路節點，來抑制壅塞災情擴大，但是，分流緩解機制，不僅沒有發揮作用，反而造成了其他地區的VoLTE節點跟著塞爆。

但是，用原有設定重啟後的壅塞原因，已經不是原本的設定出錯，而是資料庫塞爆後不斷大量重新註冊的連鎖效應，KDDI沒有設想到這個解決單點壅塞問題，才讓災情迅速延燒到全日本。KDDI坦言，對特殊單點故障會造成惡性連鎖反應的應變考量不足，誤以為只要繼續透過分流機制，就能緩解壅塞。

KDDI只瞄準單點故障來解決，缺乏整體性評估，正是導致這起事故的另一個關鍵因素。KDDI正是因為欠缺全局的思考，事故當下沒有發現一個小地方出錯，會大大影響到其他地方出問題，要避免類似情況發生，就不能只看單點或局部的影響，必須看整體影響，才有機會在產生連鎖反應前阻擋其發生。

一個人為設定出錯，造成一連串的連鎖錯誤而當機，才導致了這起大規模又長期的災情。

教訓3：參考歷史災情應變老是不夠，沒有思考全面必斷的極端備案

日本這4年就出現3起這種大規模通訊故障事件，只是不同家電信公司，KDDI這次參考了去年其他家電信公司的事故經驗設計，來設想應變對策，但碰上這次事故，不論是規模或複雜度都是前所未見，以致於難以或無法套用。

原因是，KDDI以往只是不斷預估規模，依據過去歷史經驗、災情規模來思考對策，但沒有進一步考慮到徹底解決不了的情況，應該採取什麼樣的對策。遇到這次事故超出KDDI原本預期的災情時，應變機制就會慢半拍。

KDDI以往對大規模電信災情的應變對策，都是以因應爆量的思維為前提，但是，當災情大到無法掌握，像這次事故，就不能還是像以前採取緩解式的解法，而是必須設想一個電信徹底斷線的解法，甚至必須要有徹底通訊中斷的備案，也就是營運不中斷強調的韌性。

好比說採用壓測因應方式，就是以因應爆量的思維為前提，盡量模擬最大的壓力，依據量來做反應，但是壓測永遠會有不足，實際發生狀況總是會比壓測高更多 。相較之下，採用混沌工程因應方式，就是以韌性或斷線思維為前提，預設就是會遇到當機，甚至全面通訊中斷的狀況，來思考因應對策。

尤其，進到5G時代，電信網路架構走向軟體定義架構，雖然可以讓電信服務更有彈性、可程式化控制，但是，發生單一營運商大當機的機率也大幅提升。不論是5G基地臺、核網功能現在幾乎全面軟體化，跑在通用伺服器上，和以前都是電信專屬設備、由專家操作的做法有很大不同。當電信網路架構越來越像企業IT架構，以前企業會遇到的軟體出錯問題，同樣電信業者也會遇得到，也因此更容易有服務中斷風險。

對於電信商來說，現在必須要轉變思維，從以前是因應爆量的思維，現在要改為因應斷線來思考，要用斷線思維來考慮備援，而不是用壓測或爆量思維來考慮備援。這也是從KDDI事故學到的第三個教訓。

正因為沒記取這三個教訓，才釀成重大災情，但如果想知道更多的事故細節，得從7月2日這一天開始說起。（請見：＜日本KDDI大當機事件過程追追追＞報導）

 ＜日本KDDI事故＞完整報導