いつどこからでも改善 第二回「重大トラブル解決からCSI」

IT・IT製品TOP > Key Conductors > 岩村 郁雄(特定非営利活動法人itSMF Japan) > いつどこからでも改善 第二回「重大トラブル解決からCSI」
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

いつどこからでも改善 第二回「重大トラブル解決からCSI」

運用管理 2013/02/15

ITILは英国The Minister for the Cabinet Officeの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。

「いつどこからでも改善」 第一回では、ITIL® V3 継続的サービス改善(CSI)書籍の概念とフレームワークを説明した。CSIの本質は、測定し、評価し、それをフィードバックすることで、フェーズに沿ったサービスとプロセスの改善を促進し、改善の成功を推進力として改善活動を継続的に繰り返すことであり、サービス・ライフサイクルを通じた改善ループによって、サービスによる顧客への提供価値を促進する。
(【参考】第一回・図5 「CSIを中心としたサービス・ライフサイクルの改善ループ」)
第二回では、サービス・ライフサイクルの中で、サービスが本番稼働するフェーズであるサービスオペレーションを起点としたCSIの取り組みについて事例をベースに説明する。

「消火」と「防火」 〜リアクティブ対プロアクティブ〜

CSIによるサービスとプロセスの改善は、経営層がリードして全社レベルで取り組む必要がある。このようなトップダウンによる改善活動は、前向きで効果が見えやすく「プロアクティブな活動」と呼ばれる。例えば、ITガバナンス強化に伴い、サービスの管理プロセスを改善するための活動は、CIOやCSOなどエグゼクティブ主導のプロアクティブな活動として実施されることがほとんどである。あるいは、IT運用の効果を定量的に評価できるようにするために、その評価基準を設定し、結果を評価する活動を繰り返すことで、サイクルの都度、何らかの改善が繰り返される。このような活動はCSIの改善サイクルそのものを形成する。その他、業界で成功したベストプラクティスを導入する、新しい技術やアーキテクチャを適用する、あるいは競合他社に対する競争力を高めるため、戦略的な方針や革新を目論むことなども、プロアクティブな活動によるCSIへの取り組みと言える。(図1)
プロアクティブな活動には次の特徴と効果がある。

■SSからSD、SDからST、STからSOと、後続のフェーズで改善活動を継続できる※
■成果を繰り返し活用できる
■効果が上がることを推進力に次の効果を上げるようなプラスのスパイラルを形成する
■雪だるま方式で付加価値を付ける

一方で、サービスを運用する現場では、トラブルや課題の解決のため、何らかの制約を取り除く活動が日々繰り返されている。一見すると後向きで効果が見えにくいこれらのボトムアップの「対応」活動は、「リアクティブな活動」と呼ばれる。プロアクティブな活動を防火活動とすると、リアクティブな活動は消火活動として対比されることもある。
リアクティブな活動は「火事が起きたから火を消す」ような、イベントドリブンで制約除去を目的とした一過性の対応になりがちで、CSIに結び付けにくいと思われている。リアクティブな活動として顕著なものに、SOフェーズの障害対応、STフェーズで発覚した不具合による手戻り、SDフェーズでの設計横展開が招くサイロ型運用体制と作業重複/反復、SSフェーズで見直しせずに前例を踏襲した戦略立案により引き継がれた非効率な慣習や慣例などがある。このようにリアクティブな活動は事実、あらゆるフェーズに存在し、改善の機会を識別されることのないまま「対応」が行われている。(図2)

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図1 「プロアクティブな活動とCSI」

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図2 「リアクティブな活動とCSI」
※ITIL V3 サービス・ライフサイクルの5つのフェーズ

1. サービスストラテジ(Service Strategy:以降「SS」と略記) 「どのようにサービスを提供するか」を考える戦略段階。
2. サービスデザイン(Service Design:以降「SD」と略記) 「どのようにサービスを設計するか」を定義する設計段階。
3. サービストランジション(Service Transition:以降「ST」と略記) 「どのようにサービスを本番稼働させるか」を実装する移行段階。 4. サービスオペレーション(Service Operation:以降「SO」と略記) 「サービスによる価値を提供」を実現する運用段階。
5. 継続的サービス改善(Continual Service Improvement:以降「CSI」と略記) すべてのフェーズで継続的にサービスを改善する。

本稿第二回では、特にリアクティブな活動と見られることが多いサービスオペレーション・フェーズでの「障害対応」を取り上げ、特に重大トラブルを解決する中で、大きな改善効果をあげた事例を順を紹介する。

「対応」から「改善」へ 〜リアクティブな活動に潜む改善機会〜

このトラブルは、PCの構成情報(H/W、S/W情報)を収集するPC構成情報管理システムで発生した。
このケースの顕著な特徴として、20000台を超えるPCの構成情報を単一のツールで吸い上げるという、ツール面で日本最大規模の環境であったことが挙げられる。また、トラブルの最中も月間200〜300台のペースで新しいPCが増加していて、それらの新PCをツール登録する処理と構成情報を収集する処理が累積することもシステムに対する負荷増につながっていた。
ツールで集めたPC構成情報は上位の資産管理アプリケーションにエクスポートされ、H/W、S/Wの資産管理やライセンス管理に利用されていた。このシステムは、4年前にツールのエキスパートにより実装されたが、規模やリソースの観点で、システムのキャパシティーが限界に近づいている点と、新しいオペレーティング・システムのサポートが無い点で、資産管理システムを刷新することを検討していた。
この環境において、多くのPCからのアクセス要求がツールの管理サーバに集中し、管理サーバの処理がオーバーフローし、構成情報の収集が滞る問題が発生していた。この問題によって連携する資産管理サービスが、目標としていた稼働状況を下回る事態が約3ヶ月間続いていた。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図3 「ITIL問題管理プロセス」

トラブルをITIL問題管理プロセス(図3)に沿って原因究明したところ、真の原因はPCで稼動するパーソナル・ファイアウォール(以降P-FW)であった。P-FWは初期設定でOutboundパケットの送出を許すが、Inboundパケットはブロックする。これにより、PC構成管理ツールが利用しようとしたログインのパケットがブロックされていた(図4)。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図4 「P-FWによるログインのブロック」

しかしこのケースを最終的に解決に導いたソリューションは、P-FWでログインをブロックさせないようにした対応ではなく、ログインのリクエスト生成頻度を下げることであった。そのアプローチを簡単に説明する。
まず、P-FWによりログインが失敗する現象は、調査の初期段階で判明していたが、詳細に調べるうちに次のことが分かってきた。 

■ツールの管理サーバーに極端な負荷がかかり一定の負荷レベルに達すると管理サーバーがダウンする
■管理サーバーの配下で、他に10台のゲートウェイサーバーがログインリクエストを受け付けているが、これらのサーバーにもかなりの負荷がかかっている

最初に管理サーバーのチューニングを試みたが、管理サーバーがダウンするまでの時間が長くなるだけ、すなわちPC構成情報の収集処理が不能のままの高負荷の状態が長く続くだけ、という全く解決の見込みが無い状態に陥った。そこで今度は視点を変えて、PCからのリクエストを減らすことができないか、CSIの測定-評価のテクニックを利用して調査した。すると、次が判明した。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図5 「P-FW PC3600台からのリクエスト生成分布」

■全PC 20000台中、3600台はログインパケットを繰り返し生成し、決してログインしない(P-FWが推定原因)
■その3600台のPCからのリクエスト発生状況は、一般的な管理サーバーでの処理レベルを超え、「バースト」している(図5)
■リクエスト発生頻度を設定するPC上のパラメータは、初期構築時に「一つのゲートウェイサーバーがダウンしていても他のゲートウェイサーバーへ迅速にログインできる」ように、製品初期値の10倍の頻度になるようにカスタマイズされていた

運用チームを通じて、全ユーザー向けの掲示板でP-FWを無効にするよう、ガイドしたが、3600台のPCのユーザーがそれに気づいて対応が完了するまでには相応の時間がかかるため、リクエスト数は顕著には減らなかった。そこで次の策として、前述のリクエスト発生頻度を設定するパラメータを変更するために、PC上で実行するDOS バッチスクリプトを作成した。これを全ユーザーにメール配布し、1クリックで実行してもらい、PC上のパラメータがDefaultの1/60の頻度に変更されるようにした。結果としてこれが決定打となり、PC構成情報管理システムは、完全に復旧し、トラブルが顕著になる前のデータ収集率(50%)をはるかに上回るレベル(90%)で、PCからの構成情報収集が成功するようになった(図6)。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図6 「リクエスト生成の頻度低減策」

このケースで得られた教訓としては2点挙げられる。
1点目として、初期設定よりもインターバルを短くする方策は、当初の環境では可用性を向上させるためのベストプラクティスであった。しかしP-FWのようなPCに対するセキュリティ要件が後から登場し、それが従来の通信との齟齬を生んでしまった。すると可用性向上の対策が逆に、ビジネスを阻害する問題を引き起こすことになった。効率向上策に対する潜在的なリスクについて常に考慮する習慣が求められる。そのためにはCSIの「測定-評価-フィードバック」の改善サイクルを利用して、適用したベストプラクティスによる効果を継続的に把握することが重要である。
2点目は、大規模な環境では、正常処理の累積が問題の引き金になることを、先入観を取り除いて見極めることが、遠回りのようで問題解決の近道であることを十分に理解した。こちらも、問題判別の場面で、「データの収集(測定)」、「データの処理」、「データの分析」、「情報の提示と利用」というCSIで解説されている「7ステップの改善プロセス」のテクニックを利用して、定量的な分析と効果測定を行うことで正常処理と原因との関係を正確に把握することができた。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図7 「 課題-活動-CSIへの貢献」

また、このケースでは、資産管理サービスに関するマネジメントの課題として当初から次が挙げられていた。
■ITガバナンスの観点でユーザとPCに対する統制の強化が必要
■PC構成管理ツールに新しいOSのサポートがなく、PC構成管理ツール自体のサポート切れが近い
■PC増加に対する管理システムのキャパシティが限界に達してきている
■サービスデスクと運用チームの活動が問題対応中心となり、その効果の把握や評価が難しい

これらの課題に対し、このケースを通じて次のような改善に貢献した。
■活動を通じ、現システムの限界について事実と実直な展望をご説明した結果、マネジメントに新資産管理システムの設計着手を決定していただいた
■運用チームへの支援を機会に、クリティカルな状況における連絡体制が確立され、既知のエラー発生時の確実な復旧手順が現在も続々とナレッジ化されている
■正常なビジネスの運用に運用チームが大きく貢献していることをCIOに評価いただき、両者の関係強化と、活発な議論の展開を可能にする体制作りを促進した
■「掲示板による即効性のあるユーザ周知」、「メールを通じたPC遠隔バッチ実行方式の確立」といったサービスデスクを起点としたプロアクティブな問題予防の基盤作りのプラクティスとなった

このように、サービス運用の活動における「対応」には、CSIに発展させることができるヒントが隠されていることが多い。サービスオペレーション・フェーズでは、まず運用活動の改善に取り組み、課題から活動、活動からCSIへの貢献(図7)というように、CSIに発展させる機会を日常の運用の中から探すことがポイントである。

次回は、第三回「統合運用サービスの改善」というテーマで、サービスデザインとサービスストラテジを起点とした改善事例を紹介する。

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30005929


IT・IT製品TOP > Key Conductors > 岩村 郁雄(特定非営利活動法人itSMF Japan) > いつどこからでも改善 第二回「重大トラブル解決からCSI」

このページの先頭へ

キーマンズネットとは
IBMサービスマネジメント・エバンリジェリスト。日本IBMシステムズ・エンジニアリング(株)にて、15年にわたりサービスマネジメントのためのシステム設計や構築、プロセス確立案件をリード。ITIL V2 ManagerおよびITIL V3 Expert資格を保有。

ページトップへ