くらう道。（その２）

さてさて、IT運用においてクラウドを管理していく為には視点をかえた方がよいというお話です。
「○○○○視点」
の○○○○は、
サービス
だと私は考えています。運用だけではなくクラウドを企画、開発する部門も同じくサービスを考え、設計し、開発し、運用することになります。
更に言えば○○○○にはもう一つの答えもあります。
それは、
ビジネス
です。先のブログでサービスは機能と非機能を顧客に提供し、その対価を得る手段。
と書きました。つまりクラウドは顧客からビジネスとしてITでお金をいただくための手段なのでしょう。儲からないとサービスにはなり得ないのかもしれません。

ITを利用する顧客は特にコンピュータやネットワーク、データベースが欲しい訳ではなく、目的を達成する為の機能とそれを十分に保証できる非機能に対してお金を払いたいのです。なので、コンピュータやネットワーク、データベースなどのIT資産の購入と準備は提供側（プロバイダ）に任せ、資産を購入することなく、運用も含めて提供側（プロバイダ）にお任せしたい、顧客は使いたいだけ使って要らなくなったら返却したいという需要からできがったのがクラウドコンピューティングという言葉なのだと思います。（正確には知りませんので勝手に解釈してます。）

つまり、IT提供側に必要な能力は
××を予測する能力
という二つ目のキーワードは、
需要
です。顧客のニーズは変化します。サービスは放っておくと陳腐化します。サービスには提供する相手が必要です。
これを敏感にとらえてサービスを企画する能力が今IT組織に求められています。ところが、上流行程の部署やチームが作り上げたシステムを決まった手順で運用するという従来の請負型の運用の仕組みが染み付いてしまった運用部門が、提供型の運用に変わることも求められています。

じゃあ、実際にサービス視点で運用する、提供型の運用ってどういうことでしょう？
それは（その３）で！！

くらう道。（その１）

久しぶりの投稿だなぁ。
最近、クラウド環境の運用についてよく話すんだけど、「今までの運用となにが違うの？」って聞かれるんだけどね。
やってることは基本は変わらないんだと思う。クラウドっていうのは利用者から見た言葉なので提供側での運用のやるべきことはそんなに変わらない。変わるとすれば

「○○○○視点」

になること。かな？
もう一個重要なのは

「××を予測する能力」

だと思うけどみなさんどうでしょう？
今回はかなりゆる～く書いちゃいましたが、今までの技術積み上げ型のITではクラウドでビジネスはできないと思います。
（その２）（その３）では○○○○に入る言葉と××に入る言葉を考えてみたいと思います。

構成管理って結構難しいね。

こんにちは。さすらいのIT運用コンサルタント・ウータイです。
本日のテーマは「構成管理」です。この言葉を聞いてみなさんは何を想像するだろうか？
「あぁ、CMDBだろ？」とか、「サーバのOS情報とかパッチ情報でしょ？」とか、「Excelで管理してる奴でしょ？」とか色々だと思います。

「敢えて言おう、すべて外れであると。」（ギレン風）

「諸君、構成管理はプロセスなのだよ！！」

単にこれが書きたかっただけなんだけど、あまりにもこういった用語に関する意識の違いというのが、そこかしこで聞かれる。

簡単にいえば構成管理データベース（CMDB）を管理するプロセスと言ってもいいであろう。これはITILにも記載されているから、よく読んでおいたほうが良い。個人的にはv3より、v2の方が分かりやすいと思う。
構成管理プロセスには、

• 識別
• 更新
• 監査
• 報告

などの仕事があり、他の管理プロセスを支援する役割を持つ。

この支援というのが曲者で、よく運用管理部門で構成管理を導入したいという話がでるのだが、大抵は導入効果や構成管理自体に価値が見いだせずになかなか導入が進まない。
これは構成管理自体をやっても、構成データを管理する仕組みだけが出来上がって、誰が、どんなタイミングで、どんなデータを使うのかが全く定義、設計されずにCMDBだけ導入されてしまうケースによく見られる。
CMDBだけ構築してもこれを最新の情報に維持したり、実際の環境とデータの齟齬を監査したりするプロセスがないといずれはデータは陳腐化し、使いものにならないものとなる。
これならExcelでシコシコと個人で台帳管理しているのとなんら変わらない。

「利用目的のない（構成）データをお金を掛けて管理しても意味が無い。」

ってことだ。
構成管理データベースは大抵の運用のケースでは、「あったほうが良い」とか「なくてもなんとかなる」という声が多い。これは構成データを活用して運用品質の改善に貢献しようというアイデアが
浮かんでいないのであろうと考えてしまう。
しかしながら、通常運用、異常時の運用を含めて運用員や管理者は必ず構成情報を参照する。しないと運用できないはずだ。

だって、運用ってのは、「IT資産の運用」なのだから。

システムも、サービスもネットワークも、インシデントチケットも、IT資産も構成から出来ている。だから参照しなければITの運用はできない。

構成管理を理解するには、まずは運用のどのシーン（プロセス）で構成情報を参照しているかを知ることから初めて見てはいかがだろうか？そこから各プロセスの改善の糸口が見つかるかもしれない。

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

こんにちは。さすらいの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組織内のサービスレベルマネージャ、コンシューマは顧客と呼ばれ、主にビジネス側の責任者になります。

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

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

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処理待ちプロセスがどれだけいるのかがわかり、判定はしやすくなったりします。

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

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

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

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

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

どっちなのぉ？

さすらいのIT運用コンサルタント・ウータイです。
本日は「揺れる管理者ゴコロ」というお題で、一席うちたいと思います。

よく運用の改善をしたいとか、標準化したいとか言われるIT運用に携わっている方々がいらっしゃいます。つまり、今のやり方を変えていきたいというお話。

コンサル：「どのように変えていきたいか、イメージはありますか？」
管理者：「人に依存しない、誰でも管理できるようにしたいんだよね。」
コンサル：「じゃあ、運用情報を各部署で同じ粒度やフォーマットにして、最新の状態で共有したりできたらいいですよね。」
管理者：「そうですね。でも、みんな各担当者が個別に何か管理してるみたいで、それは変えられないと思います。」
コンサル：「・・・・・。」（心のなかで、「変えたくないのぉ？どっちなのぉ？」）

というオチになるケースが多いです。
要は、今までのやり方を自分は良くないと思っているのでしょうが、関係者の協力が得にくいとか、今までのやり方に慣れてるから、やっぱり・・・。っていう変わることへの抵抗感がだんだん大きくなってくるのってIT部門のカルチャが影響していることが多いのかなぁと思ってます。

欧米のIT部門であれば、有無を言わさずトップダウンで「やれ」と号令をかけるのでしょうが、残念ながら日本は現場からのボトムアップで、縦割り組織の文化。
何か今までの運用から脱却したいと思っても、周囲が協力してくれない、上級管理職が理解してくれないという残念な感じです。つまり、ガバナンスが効いていないんですね。

今、日本のITで最も変わらなければならないのはIT組織の上級管理職です。


強力なリーダーシップで現場をあるべき姿に引っ張ってあげることが、IT運用改善の特効薬なのです。
運用コストを下げろとだけ言っても、現場は何にコストがかかっているかすら、どうやってコストを下げるかすら論理的なアイデアが出ないことが多いんです。
教育や指導を含めて組織を牽引するパワーが必要なんです。

あ、あるべき姿は最初に決めておきましょうね。

やっぱ監視でしょ？

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

IT運用といえば、最初に出てくるのがやはり監視でしょう。
世の中にも監視ツールが氾濫してきており、最近ではオープンソース系の監視ソフトウェアなんかも出てきていますよね。

よく監視システムの要件を検討している人に言われるのが、

「この監視ツールで何が監視できるか提示してくれ。」

大抵、この回答をつくると膨大な項目を記載したExcelファイルとか、製品のマニュアルコピーが提出される。
そもそも、監視の仕組みが分かっている人であればこんな要求はしないはずである。

監視とはそもそも
ITサービスを構成しているコンポーネント（ITIL的には構成アイテム、CI）の状態の変化を情報化し評価すること
である。

この情報がレコード化されるとイベントと言ったりする。評価の際に平常時（標準状態）から乖離した場合にイレギュラーな状態と評価・判断され、その情報イベントはインシデントとなる。

ここで注意すべきは、
「イベントは必ずしもインシデントにはならない」
ということだ。

先にも述べたとおり、イベントは変化を情報化しているわけで異常とは限らない。
例えば、「定期的なジョブ実行が正常に終了した。」という変化は異常ではないし、「CPUのトータル使用率が60%を超過した。」からと言って異常とは言いきれない。

インシデントは、ITILぽく言うと
「ビジネスの停止や劣化を招く恐れのある全てのイベント」
であるからだ。

監視の仕組みの話に戻ろう。
監視というのは構成アイテムの状態の変化を捉えることであるから、その状態の変化をどうやって情報化するかが仕組みを知るということになる。

結論を言うと、監視するためにはデータソースが必要で監視ツールは、そのデータソースがないと情報を取得できない。

データソースはその構成アイテムを製造しているベンダが何らかの仕様をもって実装しているわけで、実装されていない情報は取得できるはずがない。

例えば、ネットワーク機器のCPU使用率を監視できるか？という質問については、以下のような仕組みを知っていればよい。
ネットワーク機器のCPU使用率はSNMPのMIBとして、製造元が実装していることが前提となる。
監視ツールがSNMP GETを実行出来る機能を装備しており、閾値を定義出来れば監視可能となる。これはネットワーク機器のメモリ使用率でも同じことだ。この場合、データソースはMIBであり、取得方式はSNMP GETである。


UNIXオペレーティングシステムであれば、sar(1m)やvmstat(1m)などのコマンドからデータソースであるUNIXカーネル情報にアクセスして目的の値を取得できる。この場合のデータソースはカーネル空間であり、取得方式はコマンドラインインターフェイスとなる。

つまり、
「この監視ツールで何が監視できるか提示してくれ。」
という回答を考えると、数百項目の情報になってしまい、あまり参考にならなかったという顛末になる。仕組みが分かっていれば応用が効くので、なにも一つ一つ洗いだして確認する必要はないのだ。この後に来るお客からの要求は、
「何を監視すればいいのか教えてくれ。」
だ。
この回答については、これまた長くなるので次回にしよう。

監視は何のためにするのか？

私は、

「ITサービスを構成するCIが正常に稼働していることを評価し、証明すること」

が目的だと考えている。
そうなれば、そもそも

• システムを構成しているCIは何か？
• それらが正常稼動している状態はどういう状態か？（逆を言えば何を持って異常とするか？）

を知っておく必要がある。
こう言ったことはシステムの特性によって異なるので、監視を含め運用を設計する人材を早めに開発工程に参画させる必要がある。

「監視するには監視対象がどんな仕組みになっているか知っておく必要がある。」

成功のポイント？

最近、運用管理の世界では”自動化”ってのが流行ってきているようだ。んでもって、某技術系コンサルタント様のお客さん向け資料で
「運用自動化成功のためのポイント」
ってのがあった。

「うーん・・・。」

お客さんは自動化を成功させたいんじゃなくて、

運用効率の向上を成功させたい

とか

運用コストを削減を成功させたい

んじゃないのかなぁ。で、その成功のポイントとして運用上で発生する管理作業なんかを自動化することだということだと思うんだけど・・・。

みんな自分中心の物言いなので、資料を読む人の立場に立っていない。これじゃ、良い提案はできないよね。

資料は読む側の立場で書くことを意識すべし。

表現が下手なITピーポー。

先日、某社IT運用コンサルタント様のソリューション紹介資料を拝見したときのお話。

タイトルは

「仮想化ソリューションのご紹介」

って書いてあった。
へぇ、うちもXenやESXを使ったインフラの提案もやるんだ・・・。ってちょっと感心しておもむろに
資料を見ると、仮想化されたインフラをどうやって運用するのかをそれっぽく書いてある。

「仮想化インフラ管理ソリューションのご紹介」

だね。せっかくかいた資料も残念なタイトルでした・・・。という話。

内容はあまり話せないが、どうも仮想化管理に必要なのは、標準化、可視化、自動化と書いてある・・・。

これまた残念な感じである。この三つの言葉が同じレベルで語られてはいけない。
可視化も、自動化も事前に標準化されてこそ行えることなのだから。

最近、こんな感じでキャッチーなキーワード先行でユーザ企業を扇動している感じの話が多い。ユーザ企業側の運用管理者の方々もこういった言葉が曖昧なまま、ベンダやSIに要望を伝えているケースが多い気がする。

ITの人って、

自分たちの伝えたいことを正しく、上手に伝えることが苦手なのかもしれない。

と最近感じている。


ある若手システム管理者と先輩の間でがこんな会話があったことを覚えてる。

若手「システムが動きません。どうしましょう？」（汗
先輩「そりゃそうだ。タイヤもモーターもついてねぇしな。」（怒

横で聞いていたおいらは、クスッとしてしまった。若手クンはシステムが動いていない状態をきちんと把握して伝える事ができなかったのだ。

先輩としては、

「電源投入後、ログイン画面が出て、ログインはできたんですが、アプリケーションプロセスが起動していなくて、ログにXXXというエラーが出ていました。対処方法ご存知ですか？」

ってなくらいの情報が欲しかったのだろう。それが、「動いてない・・。」じゃカチンと来るよね。

「正しく要望を伝えたいなら、正しい言葉の使い方から。」

これがITの人たちに身につけて欲しいスキルのひとつだと思う。

「可視化」ってのやめない？

よくIT関連の記事なんかで、
「ITの改善は現状の可視化が先決だ。」
なんて書いてあったりする。

なんとなく、聞こえのいい言い方なので、「そうだよねぇ。可視化って重要だよね。」って言ってしまいそうな感じ。

なんで可視化って重要なんだろう。と思う。

ITILでは、

「測定できないものは評価できない、評価できなければ改善できない。」

って言ってますね。

つまり、可視化ってのは

「評価をするために対象となる何かを測定すること」

のことなのかな？

でも

可視化＝測定すること

っていうのが、個人的にはどうもしっくりこない。

可視化って言うのやめて、

情報化ってどうでしょう？
情報って、数値だったり、文字だったり、図形だったり、色だったりです。
情報化される対象って、運用業務の成果だったり、ITの品質だったり、リスクだったり、コストだったり・・・です。

こういった対象を情報化するためのルールを作ってまずは測定してみることが、改善の糸口になるってことですね。

独り言
ITって情報技術のことで、それらを扱っているIT部門自信の状態を情報化出来ていない組織って実はちょっと恥ずかしいんじゃないかなぁと思っちゃったりします。

だから一生懸命頑張っても運用の成果を正しく評価してもらえないんじゃないでしょうか？

「IT運用の改善には、人・モノ・プロセスの情報化を行い、評価することが先決です。」

IT運用って評価されないよね。

IT運用の世界って３K（汚い、キツイ、苦しい）みたいな仕事ってイメージが強いよね？（違うかな？）
その割りに会社からの評価も低くて、予算も削減されて・・。と、もう飲んだくれるしかねぇ！！ってしたいけど、急にシステムトラブルの対応が入ったから、オチオチ酒も飲めないなんてこと多くありません？

かく言う私も前職でお客様サポートエンジニアをやっていたので、トラブルの時には朝夜問わずトラブルシュートの依頼が舞い込んできたものでした。

時にはパチンコで確変中にトラブル対応電話が入ってきて、確変捨てたことも何度か・・・。（涙

徹夜してトラブル解決しても、次の日にはトラブル報告でお客さんの上長から怒られるという顛末。
自分たちが構築したシステムの故障トラブル対応で、未だかつて「よく頑張ってくれたね。」って言葉は貰ったことなかったなぁ。

トラブルで疲れ果てて帰るバスの中で、つり輪にぶら下がって立ちながら、ボーッと噛んでいたガムが席に座っている少々髪の薄いオジサンの頭のてっぺんにナイスオンしてしまって困り果てたこともあったなぁ。（関係ないけど）


でも、自分の腕でトラブル解決した日は「やってやったぜ」感が強くてモチベーションが上がることもあったことを覚えています。

ITは使えて当たり前？　NO!!
会社のトップの方から見ればITシステムって使えて当たり前、止まるはずない。
高い金かけてるんだからってな感覚の人が未だ多いんじゃないかな？水道や電気と同じ感覚で使えるなんて思ってないだろうか？
だからその使えて当たり前のシステムを運用している人たちの評価も高くないし、お金も投資しない。

IT運用にも問題あり。
一方、運用している現場は自分たちがどれだけ苦労してシステムを止めない、もしくは止まってもすぐに復旧させているかっていう努力をアピールしたり、お金を取ってくる方法を知らないんじゃないだろうか・・・？
運用はプロジェクトで作られたシステムを決められたとおりにお守りする仕事って思ってないだろうか？

これじゃ、いつまで経ってもIT運用は評価されないですよね。

運用は結構楽しい要素満載。
個人的にはITの仕事の中で運用って一番オモシロイと思ってたりします。なぜって、色々なアイデアを使って仕事を快適にかつ、クールにできる要素が多いから。
みなさんの身の回りの運用業務でもっとスマートにできそうなことって多くありませんか？決まったことしかしていないから、やりたくてもできないとかお金がかかるからとかで諦めてませんか？

私は色々なお客さんの運用業務の状況を拝見させていただいていますが、やれることはたくさんあるはずです。まずはIT運用の仕組みを学んでみることから始めましょう。

今後、IT運用に関しての知識やあるある事例など色々ブログしていきますのでご期待ください。

はじめまして

まずは自己紹介から。

ウータイ　♂

某外資系ITベンダで運用管理ソリューションの提案活動をしているコンサルタント。

ITサービスマネジメントを中心に運用改善や運用管理システムの提案を行っています。

自分の仕事の中で面白かったこと、困ったお客などなど体験談をブログしていこうと思います。