スモールスモール。クイッククイック。

こんにちは。さすらいのIT運用コンサルタント・ウータイです。
最近ブログ更新が停滞していました・・・。
さてさて今回のお題ですが、スモールスタートについてのおはなしです。

この数年IT運用改善のプロジェクトを計画しているお客さんで、よく聞くキーワードに

スモールスタート＆クイックウィン

という言葉があります。つまり小さく初めてすぐに成果を出しましょうということなのですが、計画を進めているうちに

あれれ？

という感じで、この計画大丈夫なのかな？と心配になることが多々あります。
スモールスタートと言う言葉が、費用を捻出できないために小さく始めるしかないという逃げの言葉に使われ始めるのです。

子供の頃に、木の上になったブドウを食べられないキツネが「あのブドウは酸っぱいに違いない。」
という捨て台詞をはくという童話？を読んだ記憶があります。大きく始められない言い訳になってしまっているのです。

そうなると、今度は「何を小さく始めるのか？」という事がそもそも決まっていないのでお客さんの中でも計画の推進の軸ブレが起こります。

運用対象数を絞るのか、改善するべきプロセスや仕事の範囲を絞るのか？

そんなことすら決まっていないでスモールスタートと決定してしまうのです。

小さく始めれば効果も小さくなることが殆どですので、仮にクイックにウィンできても大きな効果が得られないという試算になってしまいがちで、担当者は上司に説明できずに結局稟議を通すことができない。なんてことがよくあります。

仮に稟議が通ってプロジェクトがスタートしても、何をウィン（成功）とするのか？が決まっておらず、
「プロセスができました」
とか、
「システムがカットオーバーしました」
とかがウィンにすり替ってしまう事もよくあります。

先のブログでもこのことはお話ししましたが、プロセスを作るとかカットオーバーしたとかは、マイルストーンであってそれらの仕事が、実務やビジネスにどれだけ貢献できたかを証明できるものではありません。

更に苦笑してしまうケースとしては、プロジェクトにおけるSIや利用製品を提案しているSI会社やベンダは自分たちの提案が受け入れられ受注することをウィンと勘違いしてユーザ企業に提案しまっていることもあります。
提案した内容が実際に実行され当初の期待する効果が得られることが真のウィンなのですから、プロジェクト終了後に効果をきちんと測定し、お客さんと共有できることを提案していないのであれば、クイックスタート＆クイックウィンというコンセプトで提案しないほうがいいんじゃないかと個人的には思います。

スモールスタート＆クイックウィンを狙って運用改善を計画する場合には、

• より効果が得られるという範囲や規模についてアタリを事前に付けておくこと。（事前調査と試算が重要）
• 試算結果をウィンとして証明できるようにしておくこと。（KPIの定義と計測）
• 特にスモールスタートの場合は、改善成果などをパーセンテージで算出したほうがよい。（XXパーセント削減など）
• いきなりウィンのハードルを上げない。（７割位できれば良しとする、残りは継続的な改善で良くしていく）
• クイックウィン後のロードマップを明確にしておく（スモールスタートは継続的なPDCAサイクルの一転がり目です。）

などなど事前にある程度の戦略を持ってゴール設定し計画立案することをお勧めします。

ホントに管理出来てる？

こんにちは。さすらいのIT運用コンサルタント・ウータイです。
私はお仕事上、色々なユーザ企業IT部門の方々とお話をすることが多いのですが、プロジェクトなどの提案の際にいつもこんなことを訪ねます。

「そのプロジェクトは何をもって成功としていますか？」

と。大抵は回答が出てきません。
出てきてもコストダウンとか、品質向上、システム化などと抽象的な言葉が多く、明確なゴールが出てこないのです。
そして、プロジェクトが始まると最終的なゴールは、サービスインできる事になってきたりします。これはベンダから見れば検収を上げてもらうためにそこにマイルストーンを置くことが多いので、ベンダとしてはこれはアリなのでしょう。
ですが、ユーザ企業のITは違います。そのシステムを管理しビジネス成果を出していくことが本来のゴールなのではないでしょうか？

例えば、監視システムを導入し、やっとのことでカットオーバーしても、その監視の機能が有効に活用できているのかということを継続的に検証していくことが運用で求められるはずです。
監視が出来ているから安心。うまく管理できているというのは間違いだと思います。
監視データが取れているだけではテクニカルには成功と言えるかもしれませんが、その機能がどれだけ会社にとって有効なのかということを測定、検証し改善するという行為を継続的に行わなっていなければそれは単なる放置です。マネジメントとは呼べません。
監視は機能であり、管理ではありません。
監視した結果をイベントというデータで管理することが必要となります。結果がデータになれば、有効性やリスク、コストなどをはじき出せるようになるはずです。

他にも資産管理をしているという人は多いですが、これは
「パソコンのインベントリを収集しています。」
ということが殆どで、収集したインベントリデータを活用しているケースはあまり聞きません。
しかも、パソコンだけが資産ではありません。ITにはその他様々な資産があるはずです。
そんなところからも、ホントに管理できていますか？という感じになってしまいます。

Wikipediaでは管理について以下のように説明されています。

社会学において管理とは、組織においてある目的を効果的でなおかつ能率的に達成するために組織そのものの維持や発展を図ることである。また、企業においては企業の目的を達成しつつ活動を円滑にするためにといった諸活動のことである。これらの活動では人員、資金、物品、情報の4つの資源を重要視しており、これらの資源を調達及び配分、活用するために人事や財務制度などを整備、組み合わせや、目的活動にかかわる企画や評価機能の充実などがその代表例とされる。

情報を集めることは、頑張って行うのですがそれをどう使っているのでしょう？
利用目的はあるのでしょうか？

情報技術（IT）の人々は目的を持って管理対象を情報化し分析、意思決定することが苦手なようです。

そんなことはないでしょうか？

悪いのはいつも運用なの？

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

とあるニュースで、某銀行のシステム障害の件が掲載されていました。
「XXでシステム障害。原因は停電からの復旧作業ミス」
記事で気になった部分だけ切りだしてみました。



<中略>
停電からの復旧作業時に、「人為的なミスが発生したことが原因とみている」
という。
<中略>
利用できなくなった原因は、余震による停電で停止した機器を再起動する際に、「人為的な設定ミスが発生したため」・・
<以下略>


この記事を読んで、気になったことは減員についての表現が


人為的なミス、人為的な設定ミス

と二通り書かれていたことです。
私としては、

「作業ミスなのか、設定ミスなのか? どっちなんだぁぁ??」

と言いたくなってしまいます。

これは記事を書いた記者の言葉なのか、話をした銀行側の人の言葉なのかという議論はありますが、
人為的なミス＝設定ミス
ではないと思います。数式的には
人為的なミス∋設定ミス
だと思うんです。

更に言うと、停電に対応するためにシステムを停止させることは良いのですが、
設定ミスと言われると、
「復電時の起動手順に設定の変更という作業が入っていたのだろうか？」
という点に非常に気持ち悪さが残ります。

このような記事の書き方をされると、なんか運用が悪いんだ的な物言いに読み取れてしまい嫌な気分になってしまいます。

システムを設計する立場から言うと電源投入時にいちいち設定作業が入るなんて、毎回起動失敗というリスクを孕んだシステム設計になっているということで、これはシステムの設計ミスとして、記事を理解してしまいますね。そうなるとSIをやったベンダさんと発注した責任者の方が悪者になってしまいそうです。

電源の投入順序が間違っていたということであればなんとなく納得が行きます。システム間通信などをしているシステムであれば、接続が確立するまで待って時間切れで接続できずに起動失敗なんてこともありえるからです。

同じような人為的なミスでシステムを停止に至らしめるケースはよく新聞などで散見します。
IT運用において人為的ミスはゼロにはなりません。とはいえ発生させるわけにもいきません。
でも、

ミスを低減させる方法はあります。

そのお話は次回。
今回はなんとなく書いてしまいまとまりのないブログになってしまいしたがご勘弁を。

勘違いしていない？運用の自動化。

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

今回はIT運用の自動化ってな話題に触れてみようかと思います。

昨今のIT運用で自動化自動化と言われていますが、一体何を自動化するんでしょう？
ある人はシステムを仮想化するから自動化するんだとかいっていたりします。ほとんどのケースにおいて自動化という便利でキャッチーな言葉に踊らされている感があります。
ジャガイモと人参と豚肉が冷蔵庫にあるから、今日はカレーだね！と決めつけてしまっているのと似ている気がします。

余談ですが、関西圏ではカレーは牛肉が定番らしく上記の決めつけはあり得ないらしいです。
仮想化したからって、自動化というわけではありません。以前より自動化しやすくなったというのが正解だと思います。

自動化は人が行っている仕事を肩代わりする方法です。つまり、IT運用の至る所に自動化の機会いがうもれているはずなのです。仮想化だからっていうのはあくまで自動化のきっかけであり、あまり狭い視野で検討する事は得策ではありません。自動化は規模が大きくなればなるほど効果が出やすいからです。

IT運用の内訳としては、


①情報の収集
②マネジメント
③構成アイテムへの作業

の三つがほとんどだと思いますが、これらは多かれ少なかれ自動化できる領域です。
例えば
①システム監視からアラームが発生。
②重要度を判断、調査、回避策を提示しつつ、ダウンタイムをモニタ。
③回避策を適用。

という流れが当てはまるとおもいますが、これらはイベント管理～インシデント管理プロセスの流れです。

更に、
①緊急の脆弱性に関する報告を受ける。
②変更要求を提出、分析、承認、テスト、計画を明文化し管理。
③作業依頼に下が手tパッチ適用作業。

といった場合もプロセスです。
つまり、自動化は人がプロセス（ルール）に従って行動する手順を肩代わりする方法なのです。
プロセスを作ることはよく”標準化”という言葉に置き換えられますが、IT運用のプロセスが明文化されていない、もしくは決まっていなければ、自動化も局所的になり効果の得られない結果になってしまいます。

大きな効果を得るためには、運用プロセス全体を視野にいれた自動化戦略を検討するべきです。一方、自動化を目的としたプロジェクト化は避け、自動化された後に

どの様な運用になっているべきか？

という明確なゴールイメージと数値化された効果を事前に設定しておく事をお勧めします。
大抵のケースでは自動化システムを構築してチャンチャン。うまく動きました。おめでとう。という話が多いです。あくまでも自動化は方法であり、目標ではないことをお間違えなく。

最近のITインフラのトレンドは仮想化です。この仮想化の目的はリソースの有効活用や集約化による物理インフラ数の削減など色々ありますが、仮想化を行うことでインフラをある程度、標準構成にできるというメリットあります。つまり、個別の一戸建て住宅くではなく、マンション型のインフラになるという事です。扱う構成のタイプやテクノロジーがある程度決まっていれば、運用はスーパーエンジニアを個々の製品ごとに用意する必要もなくなりますし、ファミリーレストランのようにある程度誰でも料理ができ、お安く、すぐにテーブルに出せるメニューが作れるわけです。
これで管理手順は標準構成に合わせたもにだけが残り、シンプルになるはずです。
なので自動化が推奨されているという裏があるのです。

IT運用を自動化しようかと考えているみなさんにとって重要なことは

• まず、運用効率、コスト削減の対象とその目標値を明確にする。
• そして運用される構成と運用業務を標準化、シンプル化する。
• 方法として詳細な手順に落とした上で自動化する。
• 更に効果を継続的に測定しPDCAを回す。

ことを視野に入れておくということだと思います。

では、また次回。

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

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

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

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

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

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

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

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

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

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

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

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

を逐次見直しましょう。

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

備えよ常に！！

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

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

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

事象＝障害

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

事象∋障害

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

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

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

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

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

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

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

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

答えはNOです。

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

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

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

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

備えよ、常に！！

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

サービス、サービス。

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

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

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

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

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

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

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

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

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

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