くらう道。（その２）

さてさて、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を回す。

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

では、また次回。