« フィードパス「第8回 Web Business Shuffle 2.0」開催案内 | メイン | 10月・11月のIT関連 展示会・セミナー情報 »

2006年09月26日

NTT東日本「ひかり電話」トラブルの原因

 19日から21日にかけて発生したNTT東日本の「ひかり電話」サービスの
トラブル
の原因が、昨日同社社長から報告されたそうです。
 詳しい記事が、日系BP社のITproというニュースサイトに
掲載されています。
【続報】NTT東のひかり電話,トラブル原因の詳細が判明 2006/09/25 日経BP ITpro

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

投稿者 もりた : 2006年09月26日 19:29 このエントリーを含むはてなブックマーク この記事をクリップ!

トラックバック

このエントリーのトラックバックURL:
http://www.imadokipc.com/mt/mt-tb.cgi/207

コメント

おはよう御座います。

要するに、くだらないミスで

東証の時と似たような事を光電話でも~~~

色んな意味で、ソフト・検査。。。見直したほうが????

投稿者 ダーク : 2006年09月27日 09:00

 ダークさん、おはようございます。

 東証の時と今回と違うのは、東証の場合はシステムの大半は
1つのサブシステム、あるいは似たようなサブシステムの
集合で、サブシステムの中味の大部分はソフトウェアで
出来ている様に思われます。
 NTTの場合は、いくつかの交換機や回線など、種類の異なる
様々なコンポーネントから出来ているシステムであり、
その中のビジネスタイプ用の呼制御サーバーのソフトウェアの
不具合と中継系呼制御サーバーの運用ミスから発生しています。

 東証の場合は、ユーザである東証から依頼されたベンダーの
責任が少なくありませんが、NTTの件の場合は、ユーザである
NTT自身の責任の割合が大きいと思います。
 もちろん、ソフトを担当したベンダーにもそれ相応の責任は
ありますが。

投稿者 もりた : 2006年09月27日 11:02

こんばんは!

ひかり電話今のところあれから問題ありません。
どうもNTTさんは大事にならないと動かない体質らしいので
これだけ騒がれれば少しは対策に本腰入れるだろうと思います。

新設の事務所でひかり電話が週末に開通して3日後のトラブル
だったので、朝来たら電話がかからないのには正直参りました。

投稿者の表示がまちがっているようなので再度投稿します。

投稿者 8000 : 2006年09月27日 20:23

 8000さん、コメントありがとうございます。

> 新設の事務所でひかり電話が週末に開通して3日後のトラブル
> だったので、朝来たら電話がかからないのには正直参りました。

 びっくりしたことでしょう。とんだ災難でしたね。

> ひかり電話今のところあれから問題ありません。
> どうもNTTさんは大事にならないと動かない体質らしいので
> これだけ騒がれれば少しは対策に本腰入れるだろうと思います。

 なんといっても日本最大の通信会社ですので、光に関しては
同社ともうまくつきあって、いかなければいけないのかな、
と思っています。

投稿者 もりた : 2006年09月28日 08:39

コメントしてください




保存しますか?