どうも皆さん、ハマってますか？誰でもハマりたくはないですよね？早く終わって早く帰って早く自分の時間に使いたい！しかし、この仕事をしていると当然トラブルが発生するわけです。考えられない仕様、ありえないバグ、安定していた環境を全く同じ設定でよりハイエンドなハードウェア/ソフトウェアにしたらアップグレードしたのはトラブルだけ等々….不条理に襲い掛かるトラブルにエンジニアは常に直面する事を宿命付けられてしまいます。

“ハードウェア/ソフトウェアベンダーの仕様がおかしいんだ！”、“SIベンダーの設計・検証が甘いんだ！”、“スケジュールが無茶なんだ!”、“開発者がやる気なさすぎるんだ!”といった阿鼻叫喚がそこらじゅうで聞こえるという事態に陥り、そして“一番悪い奴は誰だ！(うちを除いて)”というような話まで飛び出してきます。解決するまでに心折れる人、開き直る人、延々と責任転嫁する人、トップダウンという名の裏ワザで納める人と多種多様な対処方でトラブルに立ち向かうのです。

一般的にトラブルシューティングと言うのは大まかに以下のプロセスではないでしょうか。

１．トラブル箇所の特定

２．原因の究明

３．原因に対する対処法の検討

４．対処法の検証と影響調査

５．対処法の実施

６．実施した対処法の観察

しかしながら、インフラなのか？アプリなのか？さえも分からず、どこに原因があるのかを探り当てるのにも時間が掛かったり、障害箇所が判明し原因が分かるまでは、“設計・設定がおかしいのか？”、“手順が間違っているのか？”、“技術仕様認識が間違っているのか？”、“既存・新規バグなのか？”、”環境依存の問題か？”、“仕様やアーキテクチャにミスがあるのか？”、“運用プロセスにミスがないか？”と色々な事が頭の中を駆け巡りますよね。

試行錯誤するなかで、各情報取集ツールでの解析、各種設定変更、何度も再起動、バージョンの変更、それでも全くらちが明かないような修羅場に送り込まれてしまい、どうしようもない状況でエンジニアが試す最終手段はやはりこれではないでしょうか？

“システムエンジニア・ネットワークエンジニアだけが知っている！

サーバルームでの最終手段！”

すみません、真面目な記事かと思わせて実はふざけた記事でした！最終手段として皆さんも是非試してみてください！チーム全員でやれば、きっとお客さんも笑顔で良い病院を紹介してくることでしょう！