インシデント管理できてますか？

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

よく、運用部門の人たちは「インシデント管理はできている。」と自負されていますが、果たしで本当でしょうか？
これはあくまで個人的な意見ですが、その殆どの人達が「プロセスに従った作業ができている。」と言っているように聞こえてしまいます。
それは、その殆どのケースがプロセスを作り、それ則って作業していることがインシデント管理だ。
と勘違いしているように見えるのです。

そこでいくつかの質問をしてみます。

• 正しくプロセスが実行されていると証明できますか？
• どのようなイベントをインシデントとして扱っていますか？
• クリティカル・インシデントはどのように判断されていますか？
• インシデント管理におけるKPIは決まっていますか？
• KPIの値を定期的に集計し、問題を分析して改善策を提示していますか？
• インシデント対応作業においてサービスレベルは参照されていますか？
• エスカレーションタイミングは決められていますか？

などなど・・・。
Noと回答される場合、多くのケースにおいてルールが定着していない、マネジメントができていないのです。

プロセスや手順があっても、それをコントロールする仕組みがなければインシデント管理のゴールは果たせません。確かにプロセスや手順を文書化、ルール化しイレギュラーな対応をさせないことは重要なことですが、プロセスには意味があります。
インシデント管理のプロセスオーナーはKPIなどからプロセスを見直していくことが仕事となっています。

見直す視点は、
そのプロセスはサービスレベルを満たせるのか？
です。

インシデントの対応手順が決まっていても、目標とする解決（クローズ)時間に間に合わなければ、サービスの可用性という視点でサービスレベルを達成できなくなります。
つまり、インシデント対応をしている横で時間経過をウォッチし、期限をモニタし、タイミングを見て上位マネジメントを巻き込んだエスカレーションを発動する仕事も必要になるのです。（もちろん、インシデントの優先度、重要度にもよります）

また、軽微なインシデントでも一ヶ月に類似インシデントを数十件～数百件も対応しているなど、問題管理などで、このような問題を分析しておらず、類似インシデントを削減できていないケースも少なくないのではないのでしょうか？
このような場合は、KPIとして類似インシデント数の増減を定期的にモニタし、問題管理プロセスにおいて根本原因を分析し、ソリューションを提供する能力が必要になります。

そして、プロセスにおいてユーザに自己解決ナレッジ提供のセルフサービス化を行ったり、一次ラインのオペレータにナレッジを提供したり、記録やディスパッチのルールを自動化したり、トレーニングをしたりして、インシデント発生において、「ビジネス影響を最小限に抑える」施策を打つのです。

そのプロセスは、本来の目的に合った十分なものか？

を逐次見直しましょう。

次回は、間違いだらけの「運用の自動化」です。

備えよ常に！！

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

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

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

事象＝障害

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

事象∋障害

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

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

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

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

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

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

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

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

答えはNOです。

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

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

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

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

備えよ、常に！！

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

サービス、サービス。

っていっても、エヴァンゲリヲンの予告ではないです。
こんにちは。さすらいのIT運用コンサルタント・ウータイです。

最近IT運用業界ではクラウドなる言葉が流行っておりますな。クラウドは大雑把に言えば、ソレを使う人がコンピュータという資産を意識せずに、”サービス”ってという形態でITを提供することで、使う側がコンピュータやネットワークを所有しないことになります。
簡単にいえば、家でテレビを観るのにわざわざ発電機を買わなくてもよく、TVを観た時間分の電気代を支払うだけでいいよということです。（電気は基本契約料金があるので、使った分だけというのは正しくはないですが。）

ところで、サービスってなんでしょう？

日本ではサービス＝”無料”という感じが強いですね。

以前、香港に旅行した人の話でレストランでひと通り食事をした後に、注文していないフルーツが出てきたそうです。その人は”サービス？”ってレストランの人に聞くと、”イエス”との回答。
ですが、お会計の時にフルーツ分の料金もしっかりとられたというお話。
この場合、”フリー？”って確認すればよかったんですね。

ま、これは余談として・・・。

サービスには提供する側と受ける側が存在します。
プロバイダは、自組織の能力やキャパシティをコンシューマの需要を予測し提供します。
コンシューマはサービスを利用することで、リスクを下げ、価値を得ます。
そしてプロバイダに対価を支払います。更にそのサービスが期待通りの結果を生むことが出来れば更なる要求をします。

サービスは陳腐化します。しかし、この需要と供給を継続させることでコンシューマは継続的な成果を生み、プロバイダは需要を予測し先行的に能力と、キャパシティを向上させることができるはずなんです。
このプロバイダとコンシューマの間で取り交わされるサービスの内容や品質（サービスレベル）に関する合意がサービスレベル・アグリーメント（SLA)です。
ITILではプロバイダがIT組織内のサービスレベルマネージャ、コンシューマは顧客と呼ばれ、主にビジネス側の責任者になります。

サービスを作る（設計する）場合、二つの視点で考える必要があります。
それは、機能と非機能です。これについてはまた次回お話しします。

「サービスは受ける相手の需要を予測し提供することが重要です。そして継続的に劣化や陳腐化しないように改善することが求められます。」