日本第二大電信商KDDI,突然在7月2日凌晨發生VoLTE語音系統大當機,3千萬名用戶超過兩天半不能打電話,也無法上網,甚至氣象廳緊急宣布在颱風艾利來襲期間無法提供完整氣象資訊。數千通報案電話無法打通,不只偏遠山上登山者受傷無法通報,差點危及性命,超過5家醫院聯繫不上外科醫生,無人能幫重病患者進行緊急手術。
突如其然的日本全國大當機,不只打亂許多人的生活步調,連帶也讓許多企業的營運大受影響,不少仰賴網路提供的服務都中斷,也導致系統故障出問題。
這起通訊當機事件,不只是KDDI成立22年來最嚴重的通訊故障事故,更是日本史上最大規模的電信服務中斷事故。
4周後,KDDI公布了事故調查結果,造成當機事故的導火線,竟是拿錯維護手冊。為何一個錯誤,造成了日本史上最大規模的中斷事故,高達2,278萬戶無法使用VoLTE通話、765萬戶無法上網,彷彿回到沒有網路和手機的時代。這得先從7月2日凌晨發生的事,開始講起。
2022年 7月2日 01:35
KDDI營運中心監測到異常飆高的流量警訊,顯示位於東京都多摩市區的VoLTE語音服務系統出現異常,KDDI發現後,開始調查出錯原因。
01:50
初步檢查,發現事故源頭是多摩VoLTE系統在全國傳輸網路中的中繼路由器設備,當時正在進行新舊硬體更換作業,但更換過程中,因不明原因出錯而導致通訊故障。
KDDI盤點初步災情,多摩地區語音通話只有部分地區中斷,其餘地區的語音通訊仍維持正常,由於無法確定故障是硬體或人為失誤造成,診斷出問題後,KDDI於是決定將設備回復到更換前的正常狀態,嘗試來恢復通訊。
02:00
KDDI成立這次事故對策總部,來因應後續可能的影響。
02:17
故障設備退回舊版設定無效,災情開始擴大。
依照KDDI原有的系統設計,單一VoLTE的網路節點出現壅塞時,可以透過傳輸網路分散式架構,將流量導向其他站點的VoLTE的網路節點(全部共有18座VoLTE節點),來達到分散流量的目的。
但是,KDDI發現,切換到舊版設定後,多摩VoLTE系統的負載仍舊沒有下降,語音通訊依舊困難。這個退回前版的做法,沒有發揮效果,反而造成其他VoLTE的節點壅塞,災情開始擴大。
不只更多VoLTE節點出狀況,連KDDI的用戶註冊資料庫也開始出現塞爆的情況。
手機連上VoLTE系統時須先註冊才能啟用通話功能,這些註冊資料都會寫入到用戶註冊資料庫中,但在退回舊版設定後,這個資料庫的查詢量突然暴增,甚至壅塞,進而影響了更多手機的註冊行為。
不只多摩地區,KDDI在日本各地的VoLTE語音服務接連出現異常,無法或難以通話,越來越多用戶反應手機不能打電話,也無法上網(Android品牌手機裝置占多數)。這起斷訊事故從單一地區的語音通訊中斷,擴大為全國規模的通訊中斷事故。
02:52
第一次公告。發布全國語音和數據通訊故障事故的通知,影響旗下au手機品牌的通訊服務和使用au線路提供相關服務的MVNO業者(如UQ mobile)。
03:00
KDDI開始實施分階段的流量管制措施,將網路流量限制在50%,造成KDDI在國內的語音通話或數據通訊功能,變得更難或無法使用。另一方面,嘗試透過控制VoLTE與網路各節點對數據及語音的連線請求,與重啟VoLTE系統呼叫處理流程方式管控進出流量,試圖減輕整體VoLTE的負載。
12:00
電信斷訊災情逐漸蔓延到許多產業,不只銀行戶外ATM無法使用,物流業者更新包裹配送資訊系統大當機,汽車業者車聯服務也故障不能用,許多靠網路提供服務的業者也開始無法使用。其他影響還包括公車刷卡付費的驗票機、電子站牌無法使用,就連政府119緊急電話,氣象局天氣預報資訊都出狀況。
15:22
KDDI從行動網路層斷開了PGW數據封包網路閘道器,以此來比對用戶資料庫中的欄位資料,來修正資料不匹配的狀態。
17:31
KDDI擴大修正不同層網路(包括行動網路、IP傳輸網、VoLTE系統)之間因網路壅塞產生的資料不一致。KDDI公告,行動緊急電話開始難以使用。總務省當晚指派一名代表擔任KDDI事故的聯絡窗口。
7月3日 01:00
經過一天限流後,KDDI決定展開復原作業階段,因為VoLTE系統和用戶資料庫壅塞導致資料不匹配,評估需較長修復時間,KDDI決定先恢復數據通訊,讓行動用戶可以先上網。從1:00開始作業,3點時初步完成修復15%數據通訊。不過,災情仍舊持續蔓延,KDDI公告,家用電話、家用VoLTE小型基站、SMS簡訊收發等,也開始無法使用。
10:00
日本總務大臣金子恭之在臨時記者會上,稱KDDI的通訊故障為重大事故,KDDI依法須於30天內向總務省提交事故檢討報告。
11:00
KDDI完成日本西部通訊修復工作
11:02
召開第一次事故說明會。KDDI社長高橋誠和KDDI技術管理總部本部長吉村和幸,出面說明事故過程和無法恢復通訊的理由。KDDI初步排除硬體故障的可能,研判是路由器設定過程出錯。KDDI也在記者會澄清,這起事件無關3G網路退場,也沒有受轉換5G行動網路的影響。
17:30
KDDI完成東部的通訊修復工作。但是,在進行網路測試和驗證時,KDDI發現,在限制流量的情況下,用來提供語音服務的各地區VoLTE系統和用戶資料庫的負載仍然超重,壅塞情況沒有得到控制。
7月4日 07:00
KDDI公告全國數據通訊已大部分恢復。但語音通訊仍難以使用。
12:18-13:18
經過KDDI一天調查,終於查明原因。有6座VoLTE交換器系統故障,持續向用戶資料庫重傳過多不必要的訊令,導致用戶資料庫持續負載過重,阻礙了語音訊通訊的恢復。KDDI最後改用非預期的斷網措施,才解決了這個問題。
14:51
KDDI解除流量管制。
16:00
全國語音通話和數據通訊幾乎已恢復先前水平。為求謹慎,KDDI決定多觀察一天,預計在隔日事故對策會議上進行最終確認,確定服務使用狀況和網路流量一切正常。
20:00
召開第二次事故說明會。KDDI說明恢復狀況和後續事故原因調查,以及擬定未來防範對策。KDDI也公布受事故影響的行業,涵蓋物流運輸、銀行、汽車、交通、氣象單位及政府機構等
7月5日 15:36
公告完全恢復正常。
7月28日
KDDI向日本國務省提交事故檢討報告書。
7月29日
召開第三次事故說明會。KDDI解釋事故發生詳細原因,也公布第一份通訊故障調查報告,坦言,中繼路由器的設定出錯。KDDI也宣布要成立一個「加強通訊基礎設施和客戶支援對策委員會」的組織(以高橋誠和董事會成員組成),來提出防範類似事故再發生的對策。在這個組織下設立四大工作小組,將協同各部門強化作業品質、營運、設備及客戶支援。
KDDI報告指出,這次發生通訊故障的中繼路由器,屬於傳輸網路中的核心路由器(core router),是用來連接行動網路和VoLTE語音通訊系統很重要的網路通訊設備。
這起7月2日凌晨的事故,KDDI正在進行多摩市在全國傳輸網路中的核心路由器汰換作業,卻因為一個設定出錯,竟然造成大規模長期的通訊中斷災情。為何一開始就設定出錯?這是許多人第一個疑問。KDDI坦承,這是在更換成新的核心路由器時,不小心誤用了舊的工作程序手冊來設定所導致的指令錯誤。
執行維護作業程序時,KDDI通常會參考兩種工作程序手冊,一種是舊程序手冊,一種是新程序手冊,分別對應到新舊工作環境,新環境下的程序手冊用於設定新產品,舊環境的程序手冊設定舊產品。操作人員會依照手冊中的程序操作來完成路由表中的路徑變更。每本手冊的程序及操作步驟也都經過測試環境、正式環境的驗證。
當時,KDDI原本正在安裝新的核心路由器,來取代舊設備,作業上,應該要使用新的程序手冊來替這臺新路由器設備做設定,但操作人員卻誤用了只能用在舊設備工作環境中使用的舊手冊來設定,設定時也沒有發現指令錯誤,就完成了設定程序。
這就導致,在這次事件中,新的核心路由器一啟用就發生通訊故障,只允許轉發從終端裝置接收到的資料,但遇到VoLTE系統從反方向回傳的資料就無法處理,因為人為設定失誤,造成路由配置不正確,只能傳送上行資料,下行資料就不通。
手冊拿到舊的版本,是造成設定出錯的原因。KDDI本來也有一套事前檢查程序,確保整個維護和更新作業流程沒有問題,在這個流程中,也有包含手冊項目的檢查,但僅以目視檢查來確認手冊是否正確,沒有採取更嚴謹的系統來檢驗,才導致了這次的設定出錯。
但是設定出錯,並不是造成這起事故擴大為全國災情的主因,而是發生設定出錯後,KDDI錯估了通訊故障可能引起的連鎖反應造成系統崩潰的風險。
依照VoLTE的系統設計,正常作業時,用戶終端裝置每50分會自動向VoLTE重新註冊,以保持始終連網,但是,就在KDDI發現設定出錯而緊急回復至舊版設定時,因為先前斷線,VoLTE系統向所有終端裝置發起了重新註冊的請求,所以,全部終端裝置都在同時間重註冊,造成多摩這座VoLTE系統迅速壅塞。接著因為啟動分流措施,其餘VoLTE節點也跟著出狀況。
各地VoLTE節點接連傳出壅塞災情,也造成用戶註冊資料庫的查詢迅速增加而塞爆,加上網路中其他設備(如PGW)也出現大量重傳,導致用戶資料庫與VoLTE連線不一致,引起VoLTE系統的重置,重置後又引起重註冊,造成網路內的重傳迅速增加,成了加速系統崩潰的催化劑。
從KDDI事後數據顯示,當時流量不到幾分鐘就突然暴增7倍,只要1分鐘就能塞爆VoLTE系統,就算把流量導向下一座,下一座也很快會被塞爆。
KDDI坦言,對特殊網路條件下的擁塞緩解的考量不足,是造成這次大規模故障的原因。
不只要應變大規模災情來減災,事故第二天進到災害復原的階段,對KDDI更是另一大艱困挑戰。
在恢復策略上,KDDI先恢復全國數據通訊,並根據地理位置來分區,依序復原西部和東部地區通訊。KDDI從7月3日凌晨1:00展開數據通訊復原作業後,也在當天早上11:00、下午17:30就恢復這兩個區域的數據通訊。
但進到語音恢復作業時,KDDI馬上就遇到了挑戰,因為當時,語音通訊仍處於塞爆的狀態, 直到7月3日下午數據通訊修復,仍沒有獲得明顯改善,加上這個時候,日本正面臨颱風艾利步步進逼,為了加快復原速度,他們按原訂計畫展開語音通訊恢復作業,因為不像恢復數據通訊那樣,是災情控制後才進行恢復,這也大大增加了KDDI恢復作業執行的難度。
另一方面,從恢復流程及機制來看,由於不同網路層之間存在複雜交互作用,使得語音通訊比數據通訊復原要複雜許多,所以,KDDI才決定一開始先恢復數據通訊服務,加上這次同時遇到多節點VoLTE壅塞、用戶資料庫壅塞和各層網路之間的狀態不一致所帶來的多重考驗,這也讓語音通訊復原的挑戰加劇。
KDDI在2013年時也曾遭遇過重大通訊中斷事故,去年更從其他家電信公司的事故經驗中,來模擬這種大規模中斷情境下的恢復策略,但碰上這次事故,不論是規模或複雜度都是前所未見,以致於難以或無法套用。
在搶修復原過程中,KDDI還要應付大規模壅塞後衍生的新問題,例如誤用了壞掉的備份對VoLTE系統做還原,有6座VoLTE系統出現異常,導致又多花了一天找原因,而延誤到恢復進度,直到7月4日中午發現原因後採斷網解決才恢復運作。
之後經過一天反覆測試確認所有語音、數據通訊都正常,才在隔天15:36宣布全面恢復。
KDDI強調,維護工作考量不足、對大規模又長期網路壅塞的應變考量不足,是造成這次大規模又長時間通訊中斷的原因。KDDI也提出補償方案,說明對用戶的賠償金額及其範圍。若以合約加上道歉退款的金額來計算,賠償總額為73億日元。
8月3日
收到事故調查報告隔幾日,國務省對KDDI及旗下沖繩行動電話公司給予書面行政指導,要求採取各種措施防止類似事故再發生。11月10日前匯報執行情況,之後每3個月完成進度檢討報告。
KDDI作業面對策:
事故發生兩周後,完成所有工作手冊管理規則和批准辦法的徹底檢查。7月底前完成對作業風險評估、標準限制。
KDDI系統面對策:
事故發生一周後,重建立一套用來解決長期網路壅塞的恢復程序和相關機制。7月底導入新的壅塞檢測工具,不只提供異常偵測通報,也能詳細掌握各站點VoLTE系統的壅塞變化情況。8月下旬完成開發壅塞復原工具,並重新審視和規畫大規模通訊中斷下的壅塞緩解設計,以此制定新對策。
KDDI客戶支援面對策:
重新檢視事故後的資訊公開流程並提出改進作法,也強化對於用戶資訊揭露與訊息公告提供的優化做法。9月底前全面實施。
KDDI語音通訊系統大當機過程示意圖
事故過程:7月2日凌晨1:35,在東京都多摩市一座VoLTE語音交換器系統,用來連接該系統與行動網路的新款核心路由器發生通訊故障①,KDDI監測到異常流量,雖緊急切回舊設備卻引起大量終端與其他設備的重複註冊,導致多摩的VoLTE系統壅塞②。KDDI隨後啟動分流機制,卻阻止不了災情持續擴大,連帶使得其他的VoLTE節點也塞爆③。多處VoLTE節點發生壅塞後,對用戶資料庫的寫入和查詢迅速增加而出現壅塞④。KDDI於2:52正式對外公告語音和數據通訊全面故障,並分階段實施流量管制。KDDI在隔天7/3凌晨1:00展開復原作業,於傍晚完成恢復東、西地區的數據通訊,但復原語音通訊過程中遇到多處VoLTE系統出現異常。經過一天調查,KDDI在7/4 13:18將有問題的VoLTE系統斷開⑤才恢復運作。經過一天測試驗證,最後順利在7/5 15:36公告全面恢復正常⑥。資料來源:iThome整理,2022年9月
熱門新聞
2024-12-03
2024-11-29
2024-12-02
2024-12-02
2024-12-03