自分たちの「運用」を知る - 運用設計の本質

2010年12月9日(木)
波田野 裕一

運用業務のライフサイクル

運用業務における改善プロセスを検討する前提として、ここでは運用業務の基本プロセスとなる「運用業務のライフサイクル」について考察します。

一般的に、運用業務のライフサイクルは、下記の3つのプロセスで構成されています。(1)運用業務の概要設計(サービス設計/Plan)、(2)運用業務の詳細設計(運用設計/Do)、(3)運用実績の蓄積(測定/Check)、です。

1. 運用業務の概要設計(サービス設計/Plan)

まず最初に、運用への期待が、明示的または暗黙的に発生します。

明示的な期待であれば、運用現場の都合を考慮した「サービス設計」を通じて「運用業務の概要設計」が行なわれます。

一方、暗黙的な期待の場合、運用現場の知らないところで人知れずに生まれているかもしれません。例えば、システム障害の通知先として、知らない間に運用現場が指定される、といったケースがあります。概要設計がされないまま運用業務に直接影響を与えてしまうリスクとして潜伏していきます。

2. 運用業務の詳細設計(運用設計/Do)

次に、1で行なわれた設計に従って、「運用業務の詳細設計」とも呼ぶべき「運用設計」を実施します。

まず、運用業務上のキーとなる「運用作業の一覧」を作成します。次に、各運用作業に必要な「ドキュメント」「スキルセット」「ツール」、すなわち「運用の三種の神器」の仕様を確定・整備します。運用の開始とともに、運用の三種の神器を利用してサービスを提供していきます。

3. 運用実績の蓄積(測定/Check)

運用の開始とともに運用実績の蓄積を開始します。測定結果はサービス設計に従って一定期間ごとに報告します。

この測定結果を基にサービス設計が変更されます。これを受けて運用設計が変更されます。こうして運用業務のライフサイクルが回りはじめます。最終的には、サービス自体の廃止によって、ライフサイクルが終了します。

運用業務における改善プロセスの全体像

運用業務の基本プロセスである「運用業務のライフサイクル」と、1ページ目の図1に示した、運用現場の「悩み」を解消するためのサイクルは、ともに同じ「PDSサイクル」となっています。これらを重ねあわせると、図3のようになります。

図3: 運用業務における改善プロセスの全体像(クリックで拡大)


図3が示すように、「運用業務のライフサイクル」を構成する個々のプロセスにおけるステーク・ホルダーと調整することによって、運用現場が持つ「悩み」の解消につながるアクションをとれるようになります。運用現場にとって、外部の主要なステーク・ホルダーは予算を握る「経営層」であり、内部の主要なステーク・ホルダーは実働する「運用メンバー」となるでしょう。

2つの「運用設計アプローチ」

「経営層との調整」と「運用設計」のどちらを優先するかによって、「運用設計アプローチ」は下記の2つに分かれます。

  • トップダウン・アプローチ
  • ボトムアップ・アプローチ

トップダウン・アプローチ

トップダウン・アプローチは、「運用業務のライフサイクル」に従って「運用設計」を行なうアプローチです。

経営層との調整後に「運用設計」が行なわれる、本来あるべき正しいアプローチです。運用に関して明確な設計思想やベスト・プラクティスが確立されている運用現場では、こちらが用いられているでしょう。

一貫した設計思想を適用しやすく、設計作業に必要な時間も短かくなることが期待できます。また、トップダウン・アプローチを実践できているということは、「運用への期待が不明確」という運用現場を悩ませる最大の「要因」が起こりにくいことが期待できます。このため、非常に大きなアドバンテージになると考えられます。

ただし、運用への期待や、運用設計の手法や方針が確立されていない場合は、運用開始後の軌道修正が頻ぱんに発生するといったリスクが考えられます。

ボトムアップ・アプローチ

ボトムアップ・アプローチは、すでに稼動している運用に対し、ミニマムな部分から「運用設計のやりなおし」に着手して、徐々に対象範囲を拡大していくアプローチです。必要となった時点で、経営層との調整に入ります。それまでは、影響範囲に注意しながら運用設計を進めます。

これは、運用業務のリバース・エンジニアリングとも言うべきものです。「設計思想」が失われた運用業務や、やり方が古くなった運用業務に対して、業務プロセスを解析しながら、仕様、目的、業務要素などを棚卸して再構成します。業務のシンプル化、非ブラックス・ボックス化、費用対効果の見直しを図ること、などを目的に実施します。

対症療法的であまり望ましくはないのですが、一番難しい「経営層との認識あわせ」をとりあえず保留して、まず「現状の見える化」と「現状からの見直し」に着手します。自分たちの実績と仕組みを固めてから経営層と同じテーブルに着くことで、論理的・合理的な議論へと誘導できることが期待できます。

まず運用現場での洗い出しから始めるため、「運用設計」の前に1回以上、改善プロセスを回わさなくてはなりません。この分、オーバー・ヘッドが発生します。一方で、運用現場だけで着手できるため、比較的現実的なアプローチとも言えます。また、ミニマムな部分から着手するため、その運用設計に無理があった場合でも、影響範囲が狭くて軌道修正が簡単である点もメリットです。

現時点では、ボトムアップ・アプローチの方が現実的という運用現場が多いのではないでしょうか。

図4: 2つの運用設計アプローチ(クリックで拡大)


そして「運用設計」へ

次ページでは、「ボトムアップアプローチ」を行なう場合に、運用現場が最初に直面する課題である「運用設計」について、その内容を考察していきます。

運用設計ラボ合同会社 / 日本UNIXユーザ会

ADSLキャリア/ISPにてネットワーク運用管理、監視設計を担当後、ASPにてサーバ構築運用、ミドルウェア運用設計/障害監視設計に従事。システム障害はなぜ起こるのか? を起点に運用設計の在り方に疑問を抱き、2009年夏より有志と共同で運用研究を開始し、2013年夏に運用設計ラボ合同会社を設立。日本UNIXユーザ会幹事(副会長)、Internet Week 2013プログラム委員、Internet Conference 2013実行委員など各種コミュニティ活動にも積極的に参加している。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています