ぷりんしぷる。

こんにちは、さすらいの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の人たちに身につけて欲しいスキルのひとつだと思う。