備えよ常に！！

こんにちは。さすらいのIT運用コンサルタント・ウータイです。

前回のブログで、今回はサービスを機能と非機能という二つの側面でお話しするはずでしたが、主旨を変更し今回はインシデント管理について考えてみたいと思います。

さて、インシデントという言葉は日本語に訳すと「事象」となります。よく国内のIT運用では障害というような言われ方をしますが、言葉的に考えても

事象＝障害

という数式は成り立ちそうにないですね。
どちらかというと、

事象∋障害

という感じでしょうか。（∋：”含む”という数学上の記号です。）
ITILでは、インシデントの定義を以下のようにしています。（私の解釈も含まれていますが・・）
「ビジネス・サービスの可用性を低下させる可能性の高い、もしくは停止させるすべてのイベント」
あるWebサイトでは
「標準の運用に属さないイベント」
とか、
「ユーザーが正常にサービスを受けることができない状態、もしくはそうなる可能性が高く、何らかの緊急対応が必要な出来事」
とも書かれています。
重要なことはビジネス視点であるということと、エンド・ツー・エンドであること、IT部門内で同じ定義が共有されていることです。

言い換えれば、データセンタのシステムが正常に動作していても、エンドユーザ利用出来ていない状態（イレギュラー、異常である）であればこれはインシデントになりえるということです。

IT運用のインシデント管理においては、
インシデントをいち早く検知、対応しソリューション、もしくはワークアラウンドを提供してサービスを正常状態に戻す。
ことが求められます。
これがインシデント管理の目的です。

こんな話をしていくと、
「じゃあ、監視をリアルタイムにしないと。」
とか、
「１秒間隔で監視できる？」
とか監視機能について訪ねてくる方々いらっしゃいます。

確かにいつなんどき、インシデントが発生するかもしれないというリスクに対していち早く対応できるように、構成アイテムを定期的にモニタリングしておくことは非常に重要なことで、これを否定する気はありません。

ですが、モニタリングをした結果様々な情報が生成されます。
これらの情報はイベントと呼ばれ、先の定義によるとインシデントの元になります。モニタリングされた結果はイベントとしてイベント管理で扱われます。
この管理でイベントの重要度決定や通知が行われ、一般的に重要度の高いイベントがインシデントチケットとしてインシデント管理に送られるということになります。

最近の監視ツールはこのようなイベントの処理を自動的に行うことができるようになっています。
ですので、IT運用において監視というとイベント管理プロセスを実行することと同義になっているケースが殆どです。

ではモニタリングを綿密にしかも数秒という短時間で行っておけば、
ビジネス・サービスの可用性を低下させる可能性の高い、もしくは停止させるすべてのイベント
を迅速に平常状態に回復させる目的を十分に達成できると言えるでしょうか？

答えはNOです。

殆どのインシデントにおいては、モニタリングしてインシデントを検知した後の工程の方が時間がかかります。
どんなに複雑なインシデントの対応でも、以下のようなプロセスを踏むはずです。

①モニタリング
②イベント検知
③確認と通知
④インシデント・オープン
⑤インシデント所有
⑥調査、診断
⑦修理、復旧、回復
⑧インシデントのクローズ（平常状態）

①～③はモニタリングやイベント管理で処理されるプロセスです。
④～⑧がインシデント管理で処理されるプロセスです。
IT運用に携わった人であれば、ダレがどう見ても④～⑧の所要時間の方が長いことは明白ですね。
ですが、先のIT管理者の方々は①～③をできるだけ短くしたいと言っているわけです。
早くシステム障害を発見したい気持ちはよくわかりますが、そこに拘り過ぎていては本来の目的を達成できなくなってしまいます。

IT運用では、発生するであろうインシデント（リスク）に対して、④～⑧のプロセスをシンプル化かつ標準化し、体制を固め、教育を行い、テクノロジを活用し、もしもの場合に常に備えておく必要があるのです。

備えよ、常に！！

次回は、「インシデント管理は実はプロセスではない！？」をテーマにお送りします。
お楽しみに。