ＩＴ屋もりたの今時パソコン日記

　
■ 原因は呼制御サーバーの不具合
　
　　同記事によると原因は「呼制御サーバー」の不具合のようです。
　
　　具体的には２つの部分の不具合で、
　1つ目は、ひかり電話ビジネスタイプ用の呼制御サーバーの不具合、
　もう１つは、各呼制御サーバーを束ねる中継系呼制御サーバーの不具合
　だそうです。
　
　　前者（ひかり電話ビジネスタイプ用の呼制御サーバーの不具合）の内容は
　設計上は毎秒100コール（呼）以上処理できるよう設計したが、その通りに
　実装（設計に基づいて、ソフトやハードを制作・テストして実現すること
　＝インプリメント(implement)）されていなかった、ということです。
　
　　後者（中継系呼制御サーバーの不具合）の内容は、
　ビジネスタイプ用の呼制御サーバーで不具合の結果、輻輳（ふくそう：混み合うこと）
　が頻繁に起こり，サーバーのメモリー上にデータが溜まり，処理領域を圧迫。
　中継系呼制御サーバーで所定の性能が発揮できず，輻輳が生じたということです。
　　溜まったデータをクリアするために19日にアプリケーションソフトの再起動を行った
　がクリアされず、20日午後にOSごと中継系呼制御サーバーを再起動した結果
　状況改善に向かった、ということのようです。
　
　
■ 不具合の原因の背景
　
　　直接の原因は上記の通りですが、根本の原因は何か考えて見たいと思います。
　　
　　前者（ひかり電話ビジネスタイプ用の呼制御サーバーの不具合）の原因は
　上記で述べたとおり、サーバー上の処理が設計どおりに作られていなかった
　ことです。つまりソフトウェアの制作、またはテストにミスがあったという
　ことです。
　　ソフトウェアの制作は、プログラム設計・制作（コーディング）・単体テスト
　という手順を踏みます。テストは結合テスト、総合テスト、最終ユーザテスト
　などの手順を踏むことが一般的です。従って例えばコーディングでミスがあった
　としても、それを取り除くチャンスは単体テスト、結合テスト、総合テスト、
　最終ユーザテストと決して少なくありません。
　　しかし、テスト終盤（結合テスト、総合テスト、最終ユーザテスト）の段階で
　プログラムの細部のテストを再現することは、針に穴針の穴に糸(注1)を通すより難しいと
　いえます。従ってこのようなテストはコーディングをした段階で見直したり、
　単体テストにより発見することが重要になります。
(注1) 誤りを訂正しました。（2006年9月28日 もりた）
　
　　後者（中継系呼制御サーバーの不具合）の場合は、
　「データをクリアするためには、OSの再起動が必要であること」を
　運用者が把握していなかった（ニュースだけからはそう思われます）ところに
　最大の問題があると思います。今回もそのことが判るまでに1.5日を要した
　ことになります。
　　「輻輳した場合、中継系呼制御サーバーのメモリー上にデータが溜まり
　クリアされないこと」が設計通りなのか否かは、詳細が明らかでないため
　わかりませんが、それよりも上記のことが重要と思われます。
　
　
　　以上２つの原因の背景を考えると、同社社長も述べている通り
　「復旧の手順や負荷分散機能の充実，サーバー/ネットワークの増強など
　　あらゆる手段で通信の信頼性向上をしていく」ことが必要と思われます。
　　
　　　システムは制作から運用の段階に入ったばかりであり、運用の経験や
　　そのフィードバックなど、ソフトウェア・ライフサイクルの概念を理解した
　　運用が必要だと思います。
　　
　　
--- 関連情報 ---
(1) 【続報】NTT東のひかり電話，トラブル原因の詳細が判明」2006/09/25 日経BP ITpro
(2) 光電話　2006年09月21日　ＩＴ屋もりたの今時パソコン日記