スタジオＦくん

システムには二重の障害対策をとっていた。

①パッケージの二重化
　「パッケージ」とはサービス制御装置のハードモジュール。
　１基のサービス制御装置に８台のパッケージを搭載。
　４台は本番系、４台はホットスタンバイ。
　４台あるのは分散化のため。

②サービス制御装置全体の二重化
　０系：本番系
　１系：待機

１．パッケージ故障
　本来なら故障した１パッケージだけが１系に切り替わるはずだった。

２．すべて１系に切り替え
　０系の中で故障した１パッケージだけが１系に変わるはずだった。
　しかし、０系４台すべてが異常とみなされ、１系に切り替わってしまった。
　実は前夜からソフト更新があり、０系は更新が終わっていた。
　しかし１系はまだだったの、両系のプログラムが異なり、「異常」と認識されてしまった。

３．切り替わり時刻
　AM8:37
　４台のパッケージ処理がすべて１系に代わった。
　通勤時間帯と重なったため、多くの端末が主と共に移動中。
　０系と１系は15分間隔で位置情報を同期させている。
　通常の６～７倍のトラフィックが一気に押し寄せた。

４．業務プログラムの不具合
　位置情報データを登録してから、メモリーを解放するまで時間がかかることはわかっていた。
　しかし高負荷時だけに顕在化する不具合だった。
　そのため位置情報の登録要求の待ち行列が解消されず、輻輳状態に。
　通信規制を実施したため、ドコモの社内連絡さえも滞ってしまった。

５．原因特定ミス
　PM0:46
　０系の修理を終え、１系から０系に再度手動で切り替えた。
　原因は０系の故障なのだから、直った０系に戻せば解決すると考えた。

６．現状把握ミス
　しかし、ここでまた位置情報の登録要求が一気に押し寄せた。
　利用者の移動は少なかったが、朝からつながりにくかったので多くの人が何度もかけ直していた。
　実は発信時にも位置情報は更新されるのだが、このような状況を把握していなかった。

　ここでサービス制御装置の切り替えを自動判別する「切り替えソフトウエア」を止めた。
　システムを再起動させて回復を図ろうと考えたが、「再起動」を障害発生と認識してしまう恐れがあり、これを避けるためにとった対策だった。

７．切り替えソフトの不具合
　
　システムを再起動。
　緊急対応を進めながら通信規制を継続。
　18:30頃から安定してきたので、「切り替えソフト」を起動した。
　そこで、本来読まないはずの、“切り替えソフトを止めていた間の０系のログ”を読み込んでしまった。
　そのため、再び自動的に１系に切り替わってしまった。
　実は、切り替えソフトを止めてから再起動するのは初めてだった。
　

　18:52
　帰宅時間と重なり、またもや位置情報の更新が相次ぎ、輻輳状態に。
　再度通信規制をかけ、位置情報の更新要求の処理を待った。

　21:36
　ようやく正常化。

.｡.:**:.｡..｡.:**:.｡..｡.:**:.｡..｡.:**:.｡..｡.:**:.｡..｡.:**:.｡..｡.:**:.｡..｡.:**:.｡.

いやぁ、担当者さん、この日は長かったでしょうね。
心中お察しします。