日本第二大電信公司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大當機事件過程追追追>報導)
熱門新聞
2024-10-11
2024-10-13
2024-10-11
2024-10-11
2024-10-11
2024-10-12