Sniffer症候群

ソフトウェア開発会社に発注した会社のシステムが、使っているうちに不定期に原因不明なエラーが発生したり、パフォーマンスが低下したりなんてことはよくある話だ。原因はさまざまで、単純なバグからデータ量・処理量の見積もり違い、機器の経年劣化やハブの故障など、非常に多岐に渡る。

こんな障害をうまくさばくのがシステム屋というもので、何といっても「システム」を構築するのを売りにしている人たちである。ハードであれソフトであれ、システム全体を効率よく見渡して瞬く間に原因を見つけ出し、対処を講じるのが売りだ。またこういった会社は「SIer」、すなわち「システムインテグレータ」とも自称している。さまざまなベンダーのシステムを統合し、障害があれば適切に切り分けてベンダー企業と協力しつつ、迅速に解決への道筋を見出す能力を誇示しているのだ。

保守チームの苦悩

理論上はそういうことになっているが、現実はどうかというと、当然そううまくはいかない。システムの開発フェーズが終わり、保守フェーズに入れば多くの場合開発チームは解散してしまう。後事は保守チームに託されるわけだが、ユーザと開発会社の契約にもよるが、保守チームはシステム開発能力を持たないオペレータやサービスエンジニア的な要員から構成されたりする。このようなチームはソフトウエアのバグなどには対処できないので、そういった場合には別途開発者が対応するという建前になっている。

しかし、いざユーザから問題が報告された時、こういった保守チームはどのような反応を示すだろうか？問題がハードウェア的なものであることが明らかな場合は、たいてい速やかに解決することができる。故障した機器を特定し、同等品を手配して置き換えるのは彼らの得意とするところだ。しかし、そうでない場合はどうだろうか？

元の開発チームリーダなどが責任をもって対処してくれればラッキーだが、そうそう都合よく行くことはあまりない。そういった人は多分別のプロジェクトで忙しかったり、もう退職したりしていたりする。リーダは無理でも開発メンバーを、と思ってもリーダ以外は全部外注さんだったりして、そう簡単に対応を依頼することもできない。

で、しかたなく保守チームがなんとかしようとするのだが、これも難しい。もともとプログラマではないし、テスト環境が存在せず、本番環境しかなかったりするのであれこれいじりまわすこともできない。そうこうしている間にユーザからの突き上げも激しくなってくる。あたふたとあちこちのベンダーのサポートにメールを出すが、現象をうまく把握できていないのでベンダーも役に立つ助言をすることができない。他に相談したくても、守秘義務がうるさくって必要な情報を外部に出すこともできない。

そのうちユーザは保守チームに見切りをつけ、開発会社の上層部にクレームを突き付けることになる。営業が出てくる。お詫びと怒声が飛び交い、メンバーが交代し、大人同士の話し合いが行われ、酒と涙が酌み交わされる。ハッピーエンドになることもあるし、ならないこともある。何らかのエンディングへと到達する場合もあるし、しないこともある。

このような、ユーザにとっても開発会社にとっても不幸な事態が展開される場合、ユーザの怒りが爆発する前段階に私がSniffer症候群と呼ぶ症状が観察されることがある。SnifferとはLANアナライザなどとも呼ばれ、ネットワークを流れる通信を記録したり分析したりするツールのことである。調査担当者が、このSnifferを使ってネットワークに流れるパケットの大量のダンプをとりまくり、日がな一日ログを眺めたり、やたらとベンダーに送りまくったりしはじめるのだ。小規模なSIerよりも大手・中堅クラスのSIerに多く見受けられる症状だ。

もちろん、こんな事をしても問題の解決につながる可能性は低い。本当にハブやルータの問題ならともかく、ソフトウエア的な問題であれば解決の糸口となる情報はまず得られないだろう。「IEがハングします」という障害報告に対して、そのときに流れていたパケットを調査しても、なにが起きているのかはまずつかめないのだ。通信内容が暗号化されていれば、Snifferで読み取ることのできるのは単なる記号の羅列にすぎない。それでも彼らはダンプを調べ続ける。

なぜこんな事をするのだろうか？もちろん、これは彼らにできる、ほぼ唯一のアクティブな作業だからだ。基本的に、非プログラマからなる保守チームはシステムの内部に踏み込むとこができない。必要な知識を持たなかったり、突っ込んだ調査や実験を実施するための予算も環境も権限も持たない場合が多いためだ。開発者からみれば、パケットのダンプを取るぐらいだったらサーバのログレベルを変更したりアプリケーションにログを入れて調査すれば、とおもうが、それはできない。それらはシステムの内部に存在するものだからである。

つまり彼らはシステム内部に手を触れることなく、外部からの観察だけに頼って、障害を解析しなければならないのだ。当然、できることはあまりない。しかしパケットのダンプならいつでもとれるし、大量のログを調査すればたっぷりと時間をかけることができる。Sniffer症候群とは必要な支援なしでユーザのクレームに立ち向かう保守チームの、哀しい思考停止状態なのだ。

保守フェーズ以外でも…

昔はSniffer症候群が現れるのはほぼ保守フェーズに限られていたが、最近では開発フェーズのかなり早い段階から発症するケースが目立ってきた。これはシステム開発の外注化が進み、特にオフショアへの発注が増えたことの影響だろう。開発中に原因不明なエラーが出るが、世界各国に散らばる外注さんたちは誰も積極的に調査してくれない。外注化のため社内では技術の空洞化が進行しており、障害解析のスキルが育っていない。ここでプロジェクトリーダという名の下級管理職はSniffer症候群を発症してしばらく思考停止状態に陥る。しかし、きっと本番環境では大丈夫だろうという根拠のない希望を胸に立ち上がり、粛々とプロジェクトを遂行して行くのだ。