月刊ビジネスコミュニケーションによるエキスパートブログ
HOME | ABOUT |
atom rss2.0

« previous next »

問題対応(1)

2008.09.25|通信ソフトウェア開発 このエントリーをはてなブックマークに追加Yahoo!ブックマークに登録この記事をクリップ!BuzzurlにブックマークBuzzurlにブックマーク

通信システム開発に長年携っていると、大規模故障等の緊急対処に関わることも出てくる。あってはならないし、起こしてはならないものであるが、何らかで関わることになってしまった場合に、何に注意したらいいかを体験談として述べていくこととしたい。

大規模故障の問題対応で支援に入る際、問題発生してから数時間経っており、現場は混乱の極みの状況になっている場合が多かった。問題発生して、解決の目処が立たなくなってからようやく何とかしろ(してくれ?)ということで呼ばれるのがほとんどのため、緊迫感漂う現場に丸腰で出向くこととなる。この時点でもすでに厳しいが、行くとすぐに一応の事情説明を受け、すぐにさてどうすれば良い?ということとなる。

さて、ざっと説明を受けただけでここがおかしい!なんていえるのは神のお告げのようなものでできるわけがない。しかしながら、現場では、すでに“きっとこんな問題では?”とか、“この対処でなおるだろう”とか、いくつかのデータの関連性から結論を急ぐ人も多く(当然ではあるが)存在する。こういう意見に耳を傾けているとうまくいかない場合が多いようだ。

それは、何故か?データがあいまいなものを取り扱われていることが多いからだと思う。 通常、問題発生すると、特に大規模故障では発生の時系列とか要約した情報を作成する人がいて、その内容を見て議論をすることが多いのだが、要約のため、問題を解析するのに必要な情報が抜け落ちていたり、要約者の主観が入り、こんな問題だろうという要約の仕方になっていたりする。

やはり、欲しいのは信頼のおけるデータだ。システムからそのまま出てくるメッセージ類や、トラヒックの変動情報、問題発生前にシステムに設定したデータや、工事についてシステムに直接関与したそのものをフィルターを介さず見ることで必ず解析は正しい方向に向かうし、解決までの時間も短縮されると思う。解析にあたっては、常にこれは信用のおけるデータかどうかを見定めながら、問題の核部分へ迫っていかないといけない。

トラックバック

このエントリーのトラックバックURL:
http://www.bcm.co.jp/mt/mt-tb.cgi/780

コメントを投稿

(投稿頂いたコメントは内容を確認させて頂くので、公開まで時間がかかります。また、適切でないと思われるコメントは公開されない場合があるので、予めご了承下さい。)

Latest