2010年9月 Archive

先日、「構成管理の成功事例はないみたいです」
とお伝えしたばかりで恐縮ですが、
「これは！」と思うデモを、最近、セミナーで拝見しました。
クラウドで運用管理のPDCAが自動化される様に、目を見張りました。

9/15（水）に行われました、G-Cloud（主催：技術評論社）のプログラム。
富士通研究所　クラウドコンピューティング研究センターの安達基光様が、
「高信頼なクラウドコンピューティングを実現する障害対処技術の開発」
と題して行われた研究発表です。

クラウドはここに来て日本のサービスプロバイダが次々に対応を発表し、
企業でも導入が加速しています。
安達様は、クラウドにおける障害対応の課題を整理し、
運用管理の考え方に変革が必要であるとしました。
　[大規模化/複雑化]障害の影響が拡大しやすいため、スピードが求められる
　[安定性重視]「事後処理」から「事前回避」へ

すると、運用管理の方針は、これまでの事後処理から、
早期発見・迅速な対処、すなわち事前回避が方針となり、
故障機器は交換せず放置することで、低コストで高可用性を実現できるとしました。

夜中にシステム管理者が、機器交換のために、人里離れたデータセンターに飛んでいく...
そんな姿は、近い将来、笑い話になってしまうのでしょうか。

そして、いよいよデモです。クラウド障害対応技術のデモですが、
こんな障害対応プロセスが自動化していました。

　○監視：高速パケットキャプチャと品質/性能分析
→○予兆：メッセージ分析による予知
→○診断：構成要素の症状を追跡し、原因箇所特定
→○対処：過去のトラブル対応手順を実行
　すべてのフェーズでCMDBの参照、書き込みが行われる。

例えば、こんな感じです。
システム内のすべてのノードは常時、パケットがキャプチャーされており、
同時にエラーメッセージの分析がリアルタイムで行われています。
過去のメッセージのパターンと照合し、またパケットの微細な変化を読み取り、
障害の兆候があると、構成アイテムがラックの見取り図で、視覚的に特定されます。
異常があるノードが、赤く光るんですね。
概ね、障害が発生する、30分前にはわかるようです。
そのノードをクリックすると、更に関連する構成アイテムや附属文書が参照できます。
過去の対応履歴から、対応フローが確認できるばかりでなく、
定型化できている対応フロー(63%が定型化できるとのこと！）は、
自動化して、障害対応が未然に完結してしまうのです。
例えば、再起動とか、切り離してしまうとか。
そのあたりが、意識しなくても、完了してしまうというのです。

我が意を得たり！「これ、これ！」と思わず口にするところでした。
もしかしたら、会場にいたシステム管理者の多くが、
同じように思っていたかもしれませんね。

私達がCMDBの構築を進めていたときは、障害発生後の迅速な対応を意識していましたが、
ここまでプロアクティブな対応ができるとは。
システム管理者が安眠できる日が、近づいていますね！
クラウドにより、ITILの考え方は運用管理のベースになりそう。
そんな確信を得た講演でした。

先日、現事務局の方から衝撃のコメントがありました。
「審査員の先生にちらっと聞いたんですけど、
　構成管理で成功している企業ってないみたいですよ」

そう聞いて、なんだか残念なような、ほっとしたような...

というのもかつて、ISO20000を導入するときに力を入れたのが、、
インシデント管理と構成管理でした。
構成管理は、機器の「親子関係」までを管理するデータベース、
CMDBが要件に入っています。

CMDBの概念の肝は、親子関係の紐付け。頭のよい仕組みだととても関心しました。
例えば、一つのサーバーの情報には、親になるデータセンターや、IPアドレス、
顧客名、子になるOSや、アプリケーションの情報などが、
網羅的に紐付けいているのです。
もちろん顧客名から引くこともできますし、IPアドレスからも引くことができる。

これはホスティング屋さんからしたら、夢のシステムです。
「データセンターの障害だ！」と言えば、
データセンタに紐づく顧客のリストが一覧で示され、一次連絡が迅速にできます。
「ハードウェアの障害だ！」と言えば、
同じ機種のリストが一覧で出て、そこから過去の障害対応の履歴などを参照できます。
「○○というアプリケーションに脆弱性がでたよ」と言えば、
○○をインストールしているサーバーと、顧客一覧が示され、
パッチあて作業の時間を見積り、作業スケジュールが迅速に作成できます。

...とこのように、ISO20000の構築チームでは夢が広がり、
CMDBの開発にあたり、ありとあらゆる要件が盛り込まれました。
要件確定後も、みんなが思いついたアイデアを、次から次に開発担当者に伝え、
カスタマイズは膨らみに膨らみました。

気がつくと。カスタマイズ部分のドキュメンテーションが追いつかず、
（中小企業にはよくあることですね...）
CMDBが故障した際の復旧方法を、十分にCMDBの運用担当者に引き継げず、
カスタマイズ部分はリスクが大きいから、と部分的な運用にとどまることになりました。
夢の実現は、感覚値で10～20%程度でしょうか。
高機能なCMDBを入れることで、審査の際、有利に進みましたが、
現状の使い方であればAccessで低予算で身の丈に合ったDBを作ることでも、
実務では十分だったかもしれません。

それでも世の中には高機能なCMDBツールが各種存在し、
ITILを導入しているデータセンターもずいぶん増えました。
きっと成功事例があるんだろうな、と夢見ていた矢先の、現事務局さんからのヒトコト。
もちろん、CMDBツールが全く機能しないわけではなく、
構成管理というのは、どのサービスプロバイダにも存在しますが、
ITILのベストプラクティスは、やはりあるべき姿。
ユーザ側の期待が大きすぎるのかもしれません。
夢のシステムなんて、やはりないんだなぁ、と感じられた一件でした。

身の丈にあった仕組みからスタートし、
PDCAで夢に近づけていくのが、現実解なのだと思います。

さて、今日は改善のためのフレームワークをご紹介します。
案を考えるというと、柔軟な発想や、奇抜なアイデアが必要なように思いますが、
考え方にも「型」があり、トレーニングで量産できるようになるものです。
あ、あくまで「質」じゃなくて「量産」ですよ（言い訳、言い訳...）。

改善提案のフレームワークで代表的なものをひとつ上げてみます。

「改善のECRS」
そのまま「イーシーアールエス」とか、人によっては「イクルス」とか読みます。
ある業務について、E→C→R→Sの順に考えていくというものです。

排除(Eliminate)
やめてみる。なくしちゃう。
例：
「書類の廃棄期間を決めていなかったが、保存期間を3年間と決め残りを廃棄したことで、探す時間が短くなった。」
「障害を15区分に分類し、分析していたが、5区分に整理し、10区分減らしたことで、傾向がつかみやすくなった」

結合(Combine)
くっつけてみる。
例：
「設定情報をAシステムに入力した後、Bシステムにも入力していたが、Bシステムの機能を、Aシステムに統合したのでAシステムへの入力だけで済むようになった」
「毎週決まった時間にデータセンターにオンサイト確認のために社員を派遣していたが、同じ週に他のデータセンターの作業があるときは、スケジューリングを工夫し一緒に済ませるようにした」

交換(Rearrange)
とりかえてみる。
例：
「本部長が作業の確認をしていたが、チームリーダーがやるようにしたことで、作業の確認の際に、細かなアドバイスもできるようになった」
「データで管理していた作業履歴を、紙にすることで、見える化が促進され、抜けや漏れが少なくなった」

簡素化(Simplify)
単純に、シンプルにしてみる。
例：
「A作業、B作業、C作業...それぞれに価格をつけ、お客様に都度お見積りをだし、受注していたが、定額サービスにしたので、依頼から作業まで迅速になった」
「文書のうち、決まって記入する項目や図をフォーマットにしたので、数カ所変更するだけで、文書が完成するようになった」

生産管理系の研修の中には、ECRSを使って、改善案をドリルのように考えさせるものがあるようです。なんてたくましい！

ECRSの中で、一番改善効果が高くて、一番難しいのが、Eであるとされています。
数年前には「捨てる技術」という本が流行りました。捨てることの価値は、誰もが認めるところですね。

と、こんな記事を書きながら、私の机は「いつか使うかも」と取っておいた書類が山を成し、作業スペースを圧迫しかけています。
本当に、捨てるのは難しいことだと実感します...

9月になりましたが、まだまだ暑いですね。
1箇月間ぶりのエントリとなりますが、
スカイアーチのISO20000の取り組みも、相変わらずアツイです！

先月より、新しい取り組みが始まりました。
「業務改善提案制度」
なんともISO企業らしい取り組みです！

この取組みの背景の取り組みは、「ITIL資格の奨励」。
全社でITIL Foundation資格の取得を奨励しているのは、先日お話したとおりです。
取り組みも半年を数え、先々月には既に取得者が10名（全社員の2割）を超えました。

エンジニアやセールス、事務局だけでなく、最近では、経理部門のマネージャーも取得！
社内の各所で、ITIL用語が聞こえ、全社の共通言語になりつつあります。
取り組みを継続すると、組織は変わるものですね。

「せっかく勉強したんだから、アウトプットの場も」
と社長の一声で、この制度が始まりました。

業務改善提案制度の仕組みはシンプル。
1.社員に業務改善の提案を広く募集。
　社員はエクセルの様式に提案を記入します。
2.月末に提出を締切り、役員会で評価・採否を検討。
3.月末の月次報告会で全社員に、すべての業務改善提案の概要と公表。
4.優秀者には、賞金！（お小遣い）

先日8月31日には、第1回目の発表がありました。
提出者は2名。1人は営業担当の方。身近なことが「すぐにできる」と高評価。すぐにできる小さな改善こそ、業務改善の要諦ですね。
もう1名は、情シスリーダの方。4件もの提案を提出。さすが、情シス。社内に目が光っています。

先月は2名。要領を学び、また来月は提出が増えることでしょう。楽しみですね。

提案制度というと、コンテストのようで、ちょっと敷居が高く思えますが、
案を量産するためのフレームワークが、世の中にはたくさん存在します。
改善案に特化したフレームワークというのもあるのです。
社員の方は、これで改善案を量産して、がっちりお小遣いを稼ぎましょう！

と、ここまで引っ張りつつ、長くなりましたので、
具体的なフレームワークは、また明日ご案内します。