システムトラブル対応が楽しい話

さぷさんです。会社でも共演NG制度があるといいですよね。

さて、僕は以前業務アプリケーションのSEをやっていたんですが、「たまにトラブル対応するもいいよね、緊張感があって」と言ったら他の人にドン引きされたのを覚えています。

今はシステムとはあまり関係ない仕事をしているんですが、この前社内でシステムトラブルが発生しまして、日頃は在宅勤務なのですが、たまたま出社日だったのと「あいつはシステムに詳しい」という理由で招集されてトラブルシュートしまして、やはり楽しかったのでその事について書いてみたいと思います。

まず、システムトラブルが発生したときは現状の正確な認識が大切です。いつ何処でどのような状況が発生したのかを短時間で時系列で事実を出来る限りしっかり掴みます。

また、障害の内容によりますが、社内ポータルで第一報を発信します。

情報を集めつつ、トラブルの原因の切り分けを考えて行動することが大切です。

ヒューマンエラーなのか、夜間バッチなどの自動処理が上手くいかなかったのか、ネットワーク系のエラーか、サーバー関係か、アプリケーションのプログラムミスか、だいたいこの5種類くらいに分類出来ると思うのですが、発生原因もだいたいこの順序な気がしています。

正常稼働しているシステムがトラブルを起こすというのは当初想定外のレアケースを踏んだと言うことですから、確率的には低いと思っていますし、僕自身も自分のミスで全社システムを止めてしまった事があっていやな汗を書いた記憶がありまして、稼働中のシステムトラブルはヒューマンエラーが比較的多いものです。

ただ、あたりをつける(仮説を立てる)は大変重要ですが、思い込みで動くと外した時の時間のロスが致命的になります。原因が明確に特定されるまでは、推定無罪であるとの原則が必要だと思います。

ヒューマンエラーでリカバリーが自分達でできる場合はいいのですが、ベンダーに対応してもらわないといけないケースもありますので、その可能性が高いと判断した場合は電話して至急来てもらうようにします。

関係者にも集まってもらって、ホワイトボードにシステムの概要図と時系列を書き込んでいき、原因を特定させていきます。

上にも書きましたが、時系列で状況を掴む事によって、原因はかなり絞れますし、システム概要図も同時に使う事によって、トラブル発生箇所がより明確になります。

僕はここでホワイトボード係になる事が多いのですが、おそらく楽しそうにホワイトボードに書き込んでると思います。

それで、原因が特定出来たらリカバリー対応を行い、社内ポータルにその旨をアップし、経緯報告と再発防止策を提出して終了です。

もちろん、原因が全く判明しないトラブルもありますし、リカバリーが出来ないケースもあり、上記のように進められるものばかりではありません。

さて、なぜ僕がシステムトラブル対応が好きなのか、おそらく以下が理由なのではないかと思います。

日頃は答えのないような仕事をしている中で、システムトラブル対応は明確な答えを見つける作業に他なりません。

また、原因不明なトラブルを関係者にヒアリングしたり、仕様書を引っ張り出して確認して事実を一つひとつ積み上げる事で原因に迫るという行為は探偵物の小説と同じです。

自らが探偵となり、真実は常に一つと思いながら仕事が出来るケースはあまりないと思います。

ただ、原因がヒューマンエラーだった場合は本人を問い詰めない事が大切ですね。トラブルを起こしたくて起こしてる訳ではないので、フェールセーフの仕組みを考えるようにして、人を責めない事が大切だと思います。