いつどこからでも改善 第三回「統合運用サービスの改善」

IT・IT製品TOP > Key Conductors > 岩村 郁雄(特定非営利活動法人itSMF Japan) > いつどこからでも改善 第三回「統合運用サービスの改善」
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

いつどこからでも改善 第三回「統合運用サービスの改善」

運用管理 2013/02/22

「いつどこからでも改善」第一回では継続的サービス改善(CSI)の概念と活用の勘所をお伝えし、第二回ではサービスオペレーションを起点としたCSIの事例について説明した。本稿、第三回では、サービスデザインとサービスストラテジのフェーズを起点としたCSIの事例について説明する。

統合運用サービスにおける一元的な監視設計

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

図1 「サーバ統合と統合運用管理」

このケースはサーバ統合を契機にそれまでサイロ化されていた運用管理業務を統合することになり(図1)、一元的に運用管理業務ができるよう既存の運用設計を見直す中で、大きく3つの改善に至った事例である。

ITサービスが動くインフラごとに個別の運用チームが編成され、個別の運用業務を実施しているケースは未だに多い。このような運用形態は「運用サイロ」と呼ばれるが、かつては五月雨式に構築したシステムを五月雨式に運用するために、サイロ化して個別最適化された運用を行う方がメリットが大きい時代があった。昨今は、仮想化やクラウド基盤への移行という顕著な傾向もあり、共通化されたインフラストラクチャーを活用し、運用対象の物理サーバの台数を抑制することで、技術的な側面で運用管理業務の共通化、自動化が後押しされている。

このように、複数のITサービスの運用管理業務を、共通化し自動化する技術の発展により、統合運用管理、すなわち運用業務をサービス化する取り組みは、多くの企業で行われている。統合運用サービスを効率的に実現するためのポイントはいくつかある。
■運用サイロの中のベストプラクティスを抽出し、一元的に適用する
■モニタリングのベースラインを確立する
■インシデント管理、問題管理、変更管理を一元的に確立する
■エンドーツーエンドのモニタリング手法を適用する
■計画停止における誤報、無視対応、通知看過を極力回避する
■「監視の監視」をスマートに実装する
■ワークフロー技術を利用した手順の自動化を促進する
これらのポイントは、特にサービスデザインのフェーズで熟考しておく必要があり、このケースでも既存の運用設計を発展させる形でこれらのポイントを盛り込むための設計を実施した。上記のポイントの中でも、特に顕著な効果があった3つの改善について説明する。

【改善ポイントその1】モニタリングのベースライン確立

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

図2 「モニタリングのベースライン」
統合運用サービスにおけるモニタリングは、ツールを一元化することのメリットが大きい。個別の運用サイロにおいては、例えば運用担当者が定期的にWindowsサーバにログインして、特定のサービスが稼働中であることを目視確認していたり、cron※1から起動されるシェルスクリプトで個々にファイルシステム使用率やプロセス死活を監視したり、モニタリングの方法自体が個別であることが多い。ツールを一元化して適用することで、監視の設定や変更の手順が一元化され、監視コンソールといった通知インタフェースも一元化される。さらに、これらのツールが提供する機能/メリットを活かす上で一番のポイントは、設計段階でモニタリングのベースライン(図2)を確立することである。具体的には監視の間隔、閾値基準、重大度を設計時に共通化することで、検知と通知の基準を共通化し、「モニタリング・サービス」として最低限適用するべき基準=ベースラインを確立することができる。検知事象が標準化された結果、検知時の対応手順も標準化でき、対応手順の自動化が促進される。またこの事例では、ベースライン確立後も、検知精度や検知から復旧までの時間、原因と結果の重複通知など、一定の測定基準から分析されるモニタリングの精度と品質評価を継続的に実施し、ベースラインのレベルアップや作業効率化などの改善を実現している。
※1. cron:ジョブ(スクリプト)単位にスケジュールを設定して自動的に実行するためのUNIX/LinuxのOS提供の機能

【改善ポイントその2】計画停止における誤報、無視対応、通知看過の回避

リブートや保守作業などの計画停止中にモニタリングを継続すると、実際には障害が発生していないのに障害通知が上がることがある。従って、それらが通知されることを前提として、特定の通知は無視することで運用的に対応しているケースも多い。無視対応は、例えば「日曜日の00:00から01:15は監視コンソールを全面的に無視する」といった簡便な方法で対応できれば文字通り無視対応であるが、ほとんどのケースでは、「日曜日の00:00から01:15までに通知されたメッセージを確認し、『無視対応』のリストに含まれている特定の通知であれば無視する」といった、神経を使う対応業務となっている。
誤報、無視対応を回避するためには、計画停止中はモニタリング機能も計画停止し検知されないようにする、もしくは計画停止中の通知を表示しないようにする、という大きく2つの手法がある。この手法は、計画停止終了のタイミングでモニタリングを再開、もしくは表示を再開することになるが、再開を手動で制御する場合の実施漏れや再開の僅かなタイミングでモニタリングが遅延することで、本来は障害として通知されなければならない検知事象が通知されなかったり、通知されても無視されたりするという通知看過が発生する可能性もある。
このケースでは計画停止における誤報、無視対応、通知看過という課題のために、次の2つの設計要素を取り入れ、課題を極力回避できるようにした。

■モニタリング機能の計画停止/再開方法の統一

複数の運用サイロで別々に実装されていたモニタリングの計画停止/再開方法を統一し、手動操作を排除した。具体的には、従来はcron、アプリケーション起動スクリプト、モニタリング製品の持つスケジューラ機能、手動スクリプト実行など、多様な計画停止方法が適用されていたものを、cronにより制御する方法に統一した。これにより定常的に行われていた無視対応が回避されるとともに再開を手動で制御する場合の実施漏れを排除した。さらにその後に計画されていた災対センター構築における「災対発動」の切替え方式に応用することもできた。

■エンドツーエンドのモニタリング手法の適用

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

図3 「エンドツーエンドのモニタリング」
「エンドツーエンドのモニタリング」(図3)とは、ネットワーク、オペレーティングシステム、ミドルウェア、アプリケーションすべてが関係する処理を実際のユーザー操作をシミュレートした形で実行させる手法である。
この手法はWebベースのアプリケーションではポピュラーで、クライアントPC側にブラウザーアクセスをシミュレートするプログラムを導入し、それを利用して一連のブラウザー操作を記憶させ、シナリオに従ってそれを実行させたり、外部からのアクセスが難しい場合でも内部サーバからスクリプトベースでアクセスをシミュレートさせたりしている。このモニタリング手法を適用することで、「何か通常と違う状態」であることを検知できるので、モニタリング再開の僅かなタイミングで通知看過が起きた場合でも、後追いでサービス全体としての稼働状況を把握することができる。
この手法は、Webアプリケーションだけでなく、開始と終了のサイクルをスクリプトによってコントロールできるものすべて処理に応用することができ、次の「【改善ポイントその3】監視の監視をスマートに実装」でも適用することとなった。

【改善ポイントその3】「監視の監視」をスマートに実装

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

図4 「擬似通知による監視機能の稼働確認」
多くの監視設計では、監視ツールの利用を前提として、対象を監視する方法を定義する。「監視の監視」という要件は、監視ツールも監視の対象とする考え方であり、「通知がないことは正常とは限らない」という原則に基づいている。
監視ツールを監視するためには、監視ツール自体の監視機能は使うことができない。そこでスクリプトを開発して、監視ツールのプロセスチェックやツールのコマンドによるチェックを実施しているケースが多い。しかし監視ツールやOSのアップグレードの都度、開発したスクリプトのリグレッション・テストが必要となり、前述の計画停止との連携も考慮が必要となる。
この課題に対し、筆者が2004年から提唱してきた擬似通知を利用した監視機能の稼働確認(図4)は、複数の監視ツール(モニタリング・ツール、イベント管理ツール、ネットワーク監視ツールなど)を組み合わせて一元監視を実現している環境で特に効果が高い。前述のエンドツーエンドのモニタリング手法の応用編として、エンドツーエンドで監視機能を「監視」することができる。その原理は次のようなものである。
(1)実際の監視対象サーバで例えば「あるプロセスが存在したら通知」のような監視設定を行い、稼動時に必ず常駐するプロセスを対象として監視する
(2)監視ツールは監視対象サーバから設定した間隔で「プロセスアップ」の擬似障害通知を送出する
(3)監視ゲートウェイ(もしくは個別のモニタリング・ツールの管理サーバ)経由で、一元監視を行う監視サーバに擬似通知が送られる
(4)監視サーバでは、擬似通知が到達したら、到達したことをログファイルに書き込み、擬似通知自体は削除する
(5)監視サーバのOSが提供するcron機能から起動されたユーザスクリプトを使って、一定間隔でログファイルをチェックし、監視対象サーバから一定間隔で通知が生成されていることを確認する。通知の生成が途絶えていたら、監視サーバへの通知に加えて、監視サーバ障害も考慮してOSが提供するメール機能などで監視機能の障害を通知する

この擬似通知手法は、(4)と(5)で若干の工夫が必要であるが、あとは通常の監視ツールの機能を使った設定作業だけであり、実装は至って簡単である。前述の計画停止とも親和性が高く、「通知を送れない」という監視ツールの障害事象をプロアクティブに監視するスマートな実装方法として、その後のサービスに対する監視設計でも採用されている。

運用サービスの統合に向けた技術支援体制の一元化

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

図5 「サイロ型組織編成と技術支援要件」

サービスストラテジ・フェーズを起点としたサービス改善の実例として「サイロ型組織に対する技術支援体制の一元化」の改善事例を述べる。サーバ統合に伴う運用サービスの統合に関して、サイロ型チーム編成を横串に技術支援することで、サービスの質を向上し、効率を高めることができるようになったケースを説明する。
このサーバ統合環境では、統合運用チームが本番のインフラストラクチャ運用を一元的に担当し、それとは別に各ITサービスを担当するアプリケーションチームが存在していた。また、ITサービスの大規模な変更や、プロジェクト型の新規サービス追加などでは、運用機能を変更または開発するために、個別の運用管理開発チームが作られる。このケースでは、一元的な運用を実現するために、マルチプラットフォームに対応する運用管理ツールが利用されている。各ITサービスで同一の運用管理ツールを利用することで、ライセンスやサポート契約の合理化を図れる。その結果、運用管理ツールを利用する個々のチームが、ツールの技術支援を必要としていた。(図5)

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

図6 「 技術支援の一元化」

このような技術支援の要件はサーバ統合により共通化されるサーバのハードウェアサポートやネットワークのサポートにおいても顕著であるが、特に運用管理に関してはその適用範囲が広く、同じ運用管理ツールであっても運用要件によって使い方も大きく異なる。そのため運用管理ツールに関しては、個々のチームに対し個別の技術支援チームを設けて対応することも多い。しかし個別の技術支援チームで対応すると、次のような弊害がある。
■ITサービス特有の運用要件を充足することにフォーカスが当たり、サイロ単位の運用設計方針が採用されがちになる
■培ってきた運用のナレッジ、ベストプラクティスの活用が難しい
■運用上の問題が発生したときにすべての運用サイロに対して類似見直し(全量見直し)作業が発生する
当ケースでは、8年以上の長期間に数回の大きなシステム更改があり、その全期間を通じていずれかのチームに運用管理ツールの技術支援を実践してきた。この実績を踏まえ、運用サービス統合のための戦略立案の一環として、個別のチームの組織統合ロードマップに沿って、技術支援を包括的に実施する新しい単一の技術支援チームを編成することを提言し、ほとんどの関連チームを対象とする技術支援担当チームが編成された。(図6)
この結果、次のような効果が得られた。
■支援体制の一元化による支援工数の削減
■一貫した高いサポート品質の提供
■ツール製品のDefectに関する影響調査の効率化、および問題の未然予防
■運用管理ツールを利用した開発成果物に関する問題が発生した時の類似見直しの効率化
■運用ナレッジ、ベストプラクティスの共有化
技術支援を行う対象チームのフェーズには、SD、ST、SOのどのフェーズも含まれているので、この技術支援活動では多くの改善の機会を得ている。例えばSOフェーズのチームで洗い出された改善をSDフェーズのチームへのInputとし、SDフェーズのチームで発見された考慮点をSTフェーズのチームでワークアラウンドとして検証し、STフェーズのチームで考案した手順の効率化手法をSOフェーズのチームに適用している。このように、運用サイロの弊害を利点に転換してCSIを実践することが可能となっている。  

次回は第四回「DevOpsに備えたプロセス自動化」(サービストランジション起点) というテーマで、サービストランジションを起点とした改善について説明し、最終回としたい。

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

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

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

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


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


30005930


IT・IT製品TOP > Key Conductors > 岩村 郁雄(特定非営利活動法人itSMF Japan) > いつどこからでも改善 第三回「統合運用サービスの改善」

このページの先頭へ

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

ページトップへ