原因のないエラー・障害はありません、真実はいつもひとつ

たまには、システムエンジニアらしいことをアウトプットしようかな、と思いつきました。

技術的には、Microsoft 系列のエンジニアであり、運用・構築・設計・提案もひととおりこなしてきたつもりです。
その中で、今でも役に立っている考え方というか、エンジニアだけに留まらない、抽象的な方法論をアウトプットします。

それは、エラー・障害の向き合い方です。

困ったときにどうするのか

コンピューターは、何もしていないのに壊れることはほとんどありません。
誰かの言葉で、
「コンピューターは思った通りには動くわけではない、書いた通りに動く」
この言葉は、当たり前でありながら、意識しなければならないことだと感じています。

コンピューターは、何かしらの環境的要因・人的操作などによって、作成者が意図しない動き(エラー・障害など)を引き起こします。

エアコンの電源が切れていた。
設定のオンオフを間違えていた。
スペルミスをしていた。
などなど。

本当に些細なことでも、コンピューターは壊れたり、暴走したり、赤いマークを乱発したりします。

そして、その状態を早く解消しなければ、二次・三次障害へとつながり、あらゆるところに迷惑がかかることがあります。

では、その状態をいち早く解消するには、どうすればよいのか。

個人的な結論から言えば、

推理力

この力が試される瞬間だと感じています。

以下、それを説明していきます。

エラー・障害が発生すると？

エラー・障害が発生した場合、すぐに状態の改善をできれば良いですが、あくまでそれは一時的な対応になることが多いです。

ユーザー影響や他のシステムに影響が出ないように、バックアップに切り替えたり、ネットワークから切り離したりします。
そして、そこから原因調査を行い、同じエラー・障害が起きないように対策を練ります。

対策をするうえで、この原因調査はしっかりやらなければなりません。
中途半端な原因調査では、中途半端な対策にしかならず、同じエラー・障害が再発する、最悪の場合、悪化する場合があります。

では、この原因調査をどう行うのか。

それは、まさに探偵(エンジニア)が、遺体(コンピューター)と向き合い、真犯人(原因)を見つけ出す手順にとても近いです。

エラー・障害を解決するには

だれが何をしたのか

単純に、誤った操作をしたことによるエラー・障害であれば、その誤った操作を行ってしまった環境(動機)に問題があります。
また、誰も触っていないときのエラー・障害については、それを引き起こすきっかけや自動実行システムが動いていたのかもしれません。

そのため、エラー・障害発生時にだれが何をしたのかをきちんと把握する必要があります。

この手順を一言でいえば、
犯行のトリック推理です。

見えないエラー・障害を確認する

原因が直接的にエラー・障害を引き起こすとは限りません。
まるで、玉突き事故のようにまったく別の原因から、エラー・障害が発生することがあります。

具体的に言えば、ネットワークの遅延による自動実行システムの処理時間オーバーみたいなことがあったります。
深夜1時～2時くらいに、コンピューターはよく自動実行システムを動かしていたりします。いくつも同時に。。

そのため、別のコンピューターで同時期にエラー・障害が発生していないかをきちんと把握する必要があります。

この手順を一言でいえば、
共犯の推理です。

時系列を把握する

エラー・障害がひとつであれば、そんなに難しい問題ではないかもしれません。
しかし、複数のエラー・障害が同時期に発生することがあります。しかも、連鎖的なエラー・障害であることがとても多いです。

具体的に言えば、とある設定のオンオフによって、アクセス権限が変更になり、その権限を使用していたシステムが動かなくなり、画面に何も表示されなくなったことで、初めてエラー・障害のアラートが来るようなことがあります。

そのため、どの順番でエラー・障害が発生しているのかを時系列に沿ってきちんと把握する必要があります。

この手順を一言でいえば、
連続殺人のアリバイチェックです。

まとめ

犯行のトリック推理、共犯の推理、連続殺人のアリバイチェック。
この3つの観点を持って、私は、真相を突き止めています。

IT業界の人に、ボードゲームやリアル脱出ゲームが好きな人が多いのは、日頃からこういった考え方を無意識的に身に付けているのかもしれません。

逆を考えれば、名探偵コナンや金田一少年などの探偵は、もしかしたらエンジニアに向いているのかもしれませんね。

以上、たろいもでした。