IT部門で仕事をする上で直面せざるを得ない現実の1つは、システムの障害やダウンなど不慮のできごとから避けられないということです。故障してはならないものを修理しなければならないのも困ったものですが、筆者が最も嫌うのは、学ぼうとしない人々と仕事をしなければならないことです。かつての同僚には、決して事後検証に時間を割こうとしない者がいました。

ITにおける「教訓から学ぶこと」への元々のアプローチは、従来のプロジェクト管理のプロセスから借用したものでした。簡単に言えば、プロジェクトの終わりにチームが一堂に会して結果をレビューするのです。プロジェクトは目的から逸脱しなかったか？予算はオーバーしなかったか？リソースは適切にアサインされたか？そしてこれらの情報は次のプロジェクトに生かされます。この手法はこの10年間で時代に沿って手直しされ、教訓から得られた情報が現在のプロジェクトにも適用できるようになっています。

コンサルタントの一人として、筆者自身のプロジェクトマネージャ時代の経験はアップグレードやマイグレーション、ディザスタリカバリなどへのアプローチを構築する上で大変役立っています。しかし同時に、ITの障害に対する対応がいかに不十分であるかに気づかされることもあります。

例えば、マルウェアによりハッカーが会社のデータにアクセスすることが可能になっていることを発見したとします。どのぐらいの期間マルウェアが侵入していたかを知ることはできませんが、とにかく除去しなければなりません。うまく除去できて脅威は去り、ネットワークの保護が回復できたとして、それで仕事は終わりでしょうか。それとも、マネージャにデータ漏えいの可能性があることを報告するべきでしょうか。あるいは、法務部に対しコンプライアンス違反があった可能性を知らせるべきでしょうか。あるいは、別のシステム管理者に問題があったことを教えるべきでしょうか。それとも、これは自分の管轄なのだから、誰にも言わないで済ませるでしょうか。

ネットワーク管理者として、上記の全ては果たしてあなたの一存で決められることなのでしょうか？それとも、「このような情報はどこに伝達されるべきか」を明確にした「インシデントレスポンスプラン」をお持ちでしょうか？何がこの問題の原因であるかを冷静に評価する方法はありますか？このインシデントから得た教訓を、ネットワークの改善に生かすことができますか？

正しい「教訓の実践」は、正しい「インシデントレスポンス手順」に繋がります。これが将来的な問題発生を防ぎ、会社が継続的に学び成長していくことの助けになります。

もし「インシデントレスポンスプラン」を持っていないのなら、今が考え始める良いタイミングかもしれません。プランには、連絡先の氏名や電話番号、問題対応のフローチャート、タスクの完了を確認するチェックリストなどを入れるとよいでしょう。これさえ用意しておけば、問題の対応に忙殺されている中でも、いちいち思い出さなければならないといったストレスから解放されます。レスポンスプランが準備できたら、手順を一通り試してみるテストシナリオを考えてみてください。本番でプランをテストする羽目にならないためにも。

「教訓から学ぶこと」を実践し、インシデントレスポンスプランを構築することは、一見煩わしいことのようですが、サービスの一貫性を保つには必要なことです。プロはこういう姿勢が評価されるのです。それに、真夜中に頭をかきむしるような事態に陥ったとしても、全てを記憶に頼らなくてよいことはありがたいことです。

本稿は、バラクーダネットワークスのWebサイトに掲載されている『バラクーダラボ』8月2日付の記事の転載です。