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

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

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

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

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

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

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

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

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

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

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

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

を逐次見直しましょう。

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

備えよ常に！！

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

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

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

事象＝障害

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

事象∋障害

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

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

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

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

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

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

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

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

答えはNOです。

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

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

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

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

備えよ、常に！！

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

サービス、サービス。

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

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

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

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

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

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

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

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

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

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

IT運用はルールだらけ。

こんにちは。さすらいのIT運用コンサルタント・ウータイです。
今回のお題は、「IT運用の原理原則」というかなりハードルの高いお話しをしたいと思います。

さて、いきなりですが

「どうして、IT運用は必要なのでしょう？」

私はこう考えます。
ITシステムが何も変化しなければ運用は必要ないのではないか・・・・。と。
つまり、無人のデータセンターで粛々とシステムが動いてるわけですから、運用オペレータもシステム管理者も不要ですね。
ですが、現実はそうは問屋が卸しません。
ITシステムは、

• 故障
• バグによるシステムダウン
• バージョンアップや不具合対応
• 悪意のあるアタック
• 予測以上のユーザアクセス数増加によるスローダウン
• 業務上の変更要求
• 作業ミス（変更）による不慮のシステム停止
• 災害

などなど、システムをサービスインしてからも状況が変化します。

よく、運用はシステムのお守りとも言われます。

要は、ITシステムを赤ちゃんに例えてみれば良いわけで、ぐずったり泣いたり、病気にならないように世話をする訳です。夜泣き出したら眠い目をこすって親は泣き止むまで世話をします。熱が出たら、専門の医者で診断を受けますよね。

つまり、IT運用はITシステムが健康ではなくなりそうな状態に陥る前や陥った後に早く平常状態に戻すような仕事をしているわけです。

では、どんな状態が健康ではない状態なのでしょう？
システムの状態であれば、事前に仕様に基づいて開発・テストされた状態と言えるかもしれません。
また、子供のあやし方もそれなりにおっかさんのテクニックがあって王道みたいな技もあるかもしれません。

こういった状態やルールは標準として定義され、運用中は常に参照されます。
標準からずれた状態は異常（イレギュラー）ですから、運用でなんらかの対策を打ち、標準の状態に戻すことをする訳です。

異常は標準（正常）である状態と比較されて初めて異常とみなされるのです。

ITシステムは赤ちゃんと同じで24時間動いています。管理者は24時間ずっと標準と現状を比較し続け、異常を見つけることに心を砕く仕事をさせられることになります。
更に標準と一言で片付けられないほど多くの比較しなければならない仕事があります。

• アプリケーションの応答時間⇔サービスレベル
• システムリソースの使用状態⇔閾値
• ログファイルの内容⇔エラー番号
• 作業結果⇔テスト済み手順書
• 実際の構成情報⇔管理上の承認済み構成情報
• 障害発生からの時間経過⇔インシデント解決目標時間

などなど現実⇔有るべき姿（標準）を比較しているわけです。常に比較していると中長期での予測も付きやすくなり、予防保全的な活動により不慮の停止などを回避することもできるようになります。

IT運用は現実と標準をいつも比較してイレギュラー状態の発生を予測、検知対応するお仕事なのです。

次回はITサービスって何よ？というお話をしたいと思います。
では！

ぷりんしぷる。

こんにちは、さすらいのIT運用コンサルタント・ウータイです。
今回はプリンシプルのお話をしたいと思います。

プリンシプルとは日本語では「原則、原理原則」などと言われます。では、なぜIT運用に原理原則が必要なのでしょう？
これはIT運用に限ったことではなく、ITの企画、開発など多くの部門に影響を与える内容です。
原理原則は基本的な決まりのことですから、基本的なルールと言い換えたほうが分かりやすいかもしれません。

よく、IT運用で運用プロセスを標準化するために「ITILをやりたい」とか、「プロセスを作る」とか言う方々がいらっしゃいますが、大抵は運用に関係する部署とその関係をフローチャートにして、ツールに実装するという事を目的にプロジェクトを進めてしまいがちです。

多くの人達が、このようなプロセス設計や実装に携わると必ず考え方の違いで話がまとまらない、改善をすべきなのに従来通りの自分たちの都合の良いやり方で設計をしてしまいがちです。
大抵のプロジェクトって軸のぶれたコマのような状態ですよね？

このような場合に、必ず原点に立ち戻って客観的に自分たちの行動や成果を見直すことが必要になってきます。
「そもそもインシデント管理ってどんな事で、何のための管理だったんだろう？」と。
これが、プリンシプルです。

プリンシプルは、憲法のようなもので、法律（詳細なルール）を取り決める際の原典となります。
ITILで記載されている管理プロセスには原理原則があり、これをきちんと理解しておき、自社の運用改善に活かすことが求められます。

プロセスを作る前にプリンシプルを決めましょう。


次回は、「IT運用における原理原則」についてお話ししたいと思います。
それでは、また！

怖いのはわかったつもり。

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

こんなタイトルでブログを書いてしまうことは、かなり勇気が必要ですね。自分もわかったような事を書いているけど、実は間違ってたりして。というツッコミが入りそうで怖いです。(^^;

さて、なんでこんなタイトルにしたかと申しますと”ITIL”というIT運用に携わっている方々にはキャッチーな言葉をメディアやIT関係者が結構わかったふりして使っているのではないか？という事を感じたからなのです。

某、ITの記事にこんなことが書いてありました。

「構成管理や変更管理の目的の一つは、トラブル対応を迅速に行えるようにすることです。」

構成管理と変更管理は密接に関係しますので、一緒に扱って話すことは重要なことです。これは間違ってません。が、その後がイケてないぃぃ。

変更管理の本来の目的は

「構成アイテムに対する変更のリスクをできるだけ減らしつつ、コストとのバランスをとりながらビジネス要求に応えること。」

だったと、私は記憶しています。

つまり、先の記事に書かれていることは、”リアクティブ（事後対応）”に対する効果を狙っているといっているわけで、本来、変更管理は”プロアクティブ（予防保全）”的な要素が最も強いのです。

確かに、構成管理だけを取り上げればインシデント管理の手順の中で構成アイテムを参照し、その構成アイテムのサービスレベルに応じたインシデント解決時間を達成するために管理される訳で、全く間違っているというわけではないのですが・・・。

なんで、こんなことを取り立ててギャーギャー言っているのかというと、ほとんどのIT運用のシーンにおいて、

• この仕事は何のためにやっているのか？
• 何を狙っているのか？

を気にしながら運用されていることが殆ど無いそうに見えるからなのです。

重要なのはプリンシプル（原理原則）です。その管理はなぜ必要で、どう有るべきなのか？

を運用者全員が役割に応じて正しく理解しておくことが、IT運用における統制の鍵となります。

怖いのは、情報を鵜呑みにしてわかったふりをしてしまうこと。コンサルタントだってすべてが正しいとは限りません。

間違った解釈を持って運用に携わってしまうと、間違った判断や評価をしてしまいます。
いろんな情報を鵜呑みにせずに、情報は参考にして自分の腹に落ちるように理解することを工夫しましょう。

といいつつ、自分の書いてることも見なおしておこうっと。

次回、プリンシプルについてお話ししたいと思います！！

ではまた。

なにを監視すれば正解？

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

先の監視についてのブログで、

管理者：「御社の監視ツールで何が監視できるか教えて。」

という依頼について、監視機能のリストを提出すると

管理者：「何を監視すべきか教えて。」


っていうような、要求をされて困るなぁ。って話がありました。

また、
監視はITサービスを構成する構成アイテムのステータスを収集することから始まる。
ステータスはデータソースからなんらかのインターフェースを使って取り出す。
ということも書きました。

では、IT運用のコンサルタントとして、管理者さんのお悩みにどう答えましょう・・・？

監視対象となるITシステムは、主に

• ハードウェア（ネットワーク、サーバ、ストレージなど）
• オペレーティングシステム（Windows, Linux, UNIXなど）
• ミドルウェア（データベース、アプリケーションサーバ）
• アプリケーション

などなどの構成タイプが存在しますよね？
で、市販の監視ツールにはテンプレートなるある程度、上記の製品の監視項目をまとめた定義体がそろっています。

ところが、これらのテンプレートは取得できるほとんどの項目を含んでいるため、管理者さんの「監視すべき項目」の答えにはマッチしないようです。
大抵、テンプレートなる監視項目群を適用すると、訳の解らんアラームがバンバン表示されて使えないってな事になりがちです。
つまり、ツールベンダが用意しているテンプレートはあくまで参考として、管理者は自分でその中から選択して使用するという心構えが必要なのです。

では、監視すべき項目をどう決めるのか？
という事に関しての考え方ですが、目的をいくつか設定してみます。

1. 障害やその予兆検知のため
2. 障害発生後の詳細な分析のため
3. 今後のシステム増強計画（キャパシティ計画）のため

ってな感じです。
上記３つは全て構成アイテムのステータスを収集したデータを基礎として利用されます。

１は監視そのものです。何らかのルール（ポリシー）を決めておき、ステータスがイレギュラーになったかどうか逐次評価を行います。

２は評価は行わず、詳細情報として直近の期間だけ記録しておき、トラブルシューティングに利用するという目的で使われます。

３は１や２を中長期のサマリとして記録しておき今後のシステムリソースの使用状態傾向などを推測するために使用します。

監視すべき項目は１の目的を果たす項目になります。これを構成アイテムのKPIと私は呼んでいます。つまり、その構成アイテムがITサービスに貢献できているかどうかを測る基準ということです。
KPIの数値が事前に設定した閾値以下であればシステムの稼働要件を満たしているということになり、閾値を超過すると稼働要件を満たせない状態に陥っており、イレギュラーとなる。
という感じの解釈になります。

これらKPIは、そのシステムの仕様や動作によって変化することがあります。
単純な故障やエラーは検知しやすいですが、性能劣化の予兆を検知するには監視項目の吟味が必要かもしれません。

例えば、データベースサーバのデータ領域のディスク容量は監視しておいたほうが良いと考える方が多いかもしれませんが、あまりデータの書き込みが少ないようなWebサーバはディスクフルは動作上起こりにくいから監視しなくてもいいかな？という感じです。
また、CPUのトータル使用率（％）も何パーセント以上が性能劣化なのかは判断しずらいですが、ロードアベレージなどを見ればCPU処理待ちプロセスがどれだけいるのかがわかり、判定はしやすくなったりします。

このように、システムがどのような原理で動いているのかを知り、性能劣化の予兆がでやすい状態はどんな状態なのかを知ることが重要になるわけです。

なので、事前の負荷テストなどでシステムの稼働状態を記録しておき、ボトルネックになりやすい構成アイテムとその項目を探しておくということが推奨されます。

ま、一般的にサーバならシステムログのエラーやシステムリソースの全体使用率やキューサイズ、使用されているプロセスの死活などを監視することが一般的でしょう。

監視項目の設計には、「それを監視してどんなイレギュラーを検知したいか？」という目的意識を持つこと。

が重要です。
なので、「イレギュラーではない状態の定義、何を持って正しいとするか？」を必ず取り決めることになります。