NTTドコモの回線障害の根本原因を推測する
NTTドコモまた通信障害、背景にグループの足かせ 技術者が慢性的不足 カナ速
なところに、「技術者不足」とあるけど、単純にゼネコン体質だから、というのが結論
以前、ドコモの仕事をしていたので、内実を想像すると（10年前なので、今は違うかもしれない）、
- NTT は、NTT Docomo の親会社である。
- NTT Docomo が、基地局の設置、ソフトウェア開発を指揮している。
- 基地局のハードウェアは、外注（どこかしらないけど、NEC とか？）
- 回線のソフトウェアは、富士通などに外注
- 富士通から富士通の子会社に外注
- 子会社から、協力会社へ外注
- 協力会社から孫会社あるいは、派遣会社から人員を募集 ← ここが、ソフトウェア技術者
になっている。この体制は、建築業界のゼネコンと変わらない。
ドコモや、富士通は何をやっているかというと、親会社と協力会社（下請け会社）との調節。
ソフトウェア開発自体のマネジメントは、下請け自身が普通行う。
派遣社員は、大抵が、ソフトウェア開発歴が5年以下の新人（ソフトウェア業界では「新人」ではないけど、他の業界から云えば、5年以下の経験なんて、経験と言えない）が担当する。
なので、ソフトウェアの中身は、内実、新人が担当していると思っておけばよいのです。
じゃあ、設計はどうなっているかというと、確かにシステム設計っぽいもの、はできてはいるのですが、大抵は「机上の空論」が多くて、「日本語」でしか書かれてない仕様書、設計書が多い。なので、この手の障害に直結するような、ウエイトのかかる部分は、新人プログラマの力量に掛かっていると云えます。当然、お分かりの通り、「新人プログラマの力量」なので、たかが知れています。
受託開発の罠
http://moonmile.net/mymy/solution/008.html
を書いたころには、血気盛んなこともあって、なんとかできるのでは？と思ったものなのですが、いえいえ、なんともできませんね。記事自体は、2004年に書いたものですが、ほころびが今になって出てきているという感じです。
あと、この手の受託開発プロジェクトから、今の私は抜け出してしまった（稼ぐという意味では、どこかに派遣は行きますが、自分の意志でできるという点で今のほうが断然良い）ので、この手の大手の会社の技術力の無さによる（無さというか、もともと無いのだから、今後も技術力が付くわけがない）弊害は、私にとって別世界となっております。勝手にやってください、という感じです。
以前は、アジャイルとか、制約理論とか、プロジェクト管理に原因がとか考えていたのですが、いやいや、成功するプロジェクトは必ず成功します。失敗するプロジェクトは必ず失敗します、というだけです。プロジェクトの構成員（プロジェクトマネジャ、顧客の要望、技術的なバックグランドを持つメンバ、補充すべき指針）などが揃っていれば、ほぼ 100% でプロジェクトは成功します、というだけです。
～
さて、技術者不足...だけでは、解決にならないので具体的なドコモの障害の原因を推測するに、「制御機器のバッファオーバーラン」ではないか、と思っています。バッファオーバーランというのは、確保している以上のメモリにアクセスしてしまうハッキングの手段なのですが、初心者が頻発する初歩的なバグでもあります。
ドコモのような24時間運転の機器の場合、内部では java や c# のような vm を使うことはできません。大抵は、unix マシンに c 言語で書きます。vm を使うとメモリの浪費が多いのと、メモリ配置が予測できないので「使えない」のですね。そして、c 言語を使うにしても、malloc や free を禁止しています。malloc を使うと、同じくメモリの配置が予測できないので、使えないのです。なので、監視系の場合には new/delete を繰り返しても良いのですが、メモリのフラグメントが重大な「事故」になってしまう運用系の場合には、あらかじめ巨大なメモリ/配列を確保する、ということをやります。こうすると、あらかじめメモリの配置が分かるために、メモリ確保による不具合が出にくいのです。
で、配列にする場合、アクセスをインデックスで参照させるわけですが、このインデックスが範囲内で収まっている（回線が少ないとか、最大値以下だとか）間は、最大値のチェックを忘れていても動きます。おそらく、いままでのドコモの場合は、そんな感じです。ですが、ひとたび回線が混雑する状態となり、配列の最大値までアクセスしようとする場合に、一気に不具合がおきます。
この不具合がどういう現象になるかというと、通常は不正なメモリアクセスのためにコアを吐く（アプリケーションエラー）となることを想像するでしょうが、実は「あらかじめ配列」を確保しているために、バッファーオーバーランをしてしまうと、隣にある「一見正常そうなメモリにアクセスする」という現象が発生します。なので、アクセスしただけでは落ちないのです。なので、「一見正常な値」を拾ってくるために、一見正常そうな動きをします。以前もあった、sp メールの誤配信の状態がこれで、メモリアクセスが不正であれば配信自体が起こらないのですが、「誤配信」をするところみると、隣のメモリにアクセスしてしまった、と考えます。逆に、この現象から、現在の運用系のプログラムが、主に固定配列を使っていることが想像できます。
この固定配列の方式は、基地局自身に含まれるファームウェアにもあるわけで、いえ、むしろファームウェアのほうが固定メモリが多いのですが、ここでも似たような原因で不具合が発生します。通信障害のように通話ができない≒サブ機器が動かなかった、という問題は、実は２つの原因があります。
- 回線障害のもとの原因は何か？ハードウェアの故障？ソフトウェアの不備？
- 切り替えが正常にできなかったのは、何故か？ハードウェアの故障？ソフトウエアの不備？
前者のほうは、ハードウェア機器が壊れる確率も結構高いので、ソフトウェアの不備だけとは言えません。しかし、後者のほうは、スタンバイしているハードウェアの故障が重なった、とは考えにくいですよね。よく知られているように、この手のバックアップの器械って、きちんと動かないのが常なのです。なんのためのバックアップか分かりませんが....
なので、大抵、バックアップのほうが正常に起動できなかたのは、バックアップ機への切り替えを行う、ソフトウェアの障害（というか、不備）が原因です。自動切り替えができないのですが、手動切り替えができる、っていうのがミソですね。自動（ソフトウェアによる）切り替え試験が非常に足りないのです。かつ、切り替えソフトが駄目駄目すぎる。
となると、切替ソフトが駄目駄目なのですが、それと同じ技術力しかない開発者（この場合は、孫請けの新人開発者）が作った本体の運用機器だけが「頑丈に」できているワケがありませんね。同じぐらいの品質しかない、と想像できます。
そういう想像から、通常行われる固定配列操作に対して最大値のチェックを怠るような新人プログラマによる開発が主原因で、回線障害が頻発しているのでは？と思っているわけです。そうそう、ソフトウェアのバグは、GKB と同じように、ひとつ見つかれば、10個見つかるものですよ。このあたりは、テスト技法とかQAとかが詳しいでしょう。
そんな訳で、ソースのコードレビューから始めましょう、ドコモさん。いえいえ、コードレビューができる方は、ドコモ社内にいるわけはないのですが...頑張ってください。