明日の運用現場のために - 運用フレームワークという視点

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

前回までに、

  • 「運用方法論」の目的
  • 「運用現場の問題点」の分析
  • 運用の「フレームワーク」化

の3点について、説明してきました。

最終回の今回は、運用現場において実際に運用設計をする上でのリファレンスとなる「運用フレームワーク」について触れ、運用設計の今後について展望していきます。

「運用フレームワーク」 とは

ここで「運用フレームワーク」とは、各運用現場における業務について「客観的な立場に立ち、科学的/論理的手法を用いて分析し、継続的に見直すサイクルを構築する」手助けをする枠組みのことを言います。運用設計を行うときや、運用業務の分析/評価時にも参照されることを想定しています。

その立場や価値観によって、いろいろな「運用フレームワーク」があってもよいと考えています。ここでは、筆者を含む有志による「運用研究会」で継続的に検討・議論している「運用フレームワーク fwop」(FrameWork of OPeration)について、駆け足ですが概要と利用場面を見ていきます。

「運用フレームワーク fwop」 の概要

第1回第2回とエラそうなことを書いていますが、われわれも運用現場で直接もしくはその支援で日々苦労しています。fwopは、このような現場の人間が「なんとか楽したい」という思いからスタートしています。そしてまだまだ道半ばです。

もし何かしら参考になるところがあれば「いいとこ取り」もOKですし、足りないところがあればツッコミを入れていただき、より良いものにしていければ、という思いを持っています。

fwop 3つの特徴

「運用フレームワーク fwop」は、以下の3つの特徴を持っています。

1. 現場への負荷による作業分類: 「作業カタログ」
fwopでは、運用の各業務について「作業カタログ」という作業一覧を作成して「やっていることの見える化」を行ないます。一覧化された各作業について「現場に対する負荷」により分類することで、その運用現場の負荷状況を定性的に分析できるようにします。短期的には「実績の見える化」はこの「作業カタログ」上で行われ、負荷状況の定量的な分析をすることも想定しています。
2. 運用業務プロセスのモデル化: 「業務機能ユニット」
fwopでは、業務プロセスを「業務機能ユニット」という10種類の機能ユニットで表現することで、標準化による効率化、モデル化による柔軟性を実現しようとしています。中長期的には「実績の見える化」はこの業務機能ユニット上で自動的に行われることになると想像しています。
3. 現実の直視と理想の提示: 「ポリシー・レベル」
fwopでは、運用業務の各要素について、現実と理想を"0"から"3"の4段階の「ポリシー・レベル」という相対的な尺度で表現します。これによりさらに具体的な、運用に対する「期待」や「やらないこと」の見える化を実現しようとしています。

fwopの全体像

fwopの全体像は、現時点で以下のようになっています。

fwop本体(運用設計リファレンス)
運用設計を行う上で必要な検討事項や評価基準を集めた、運用設計のリファレンスとなるものです。
  • 運用の定義
  • 運用概要設計(期待分析、成果設計、組織設計)
  • 運用詳細設計(作業一覧設計、運用基盤設計、業務プロセス設計)
  • 改善スキーム(測定、分析、計画、棚卸し)

図1: fwopの全体像
運用設計ガイドライン
運用設計を手軽に実践するためのテンプレートやアプローチ手法(第2回の図4)をまとめたものです。 fwop本体を参照しなくても最低限の運用設計が可能になるガイドブック的なものを目指しています。 また、その支援ツールについても試行錯誤中です。

やりたいことは非常に多いのですが、具体化するにはまだまだ時間が必要なのが現状です。

運用業務の分類方法と「運用基盤」

今回は、紙面の関係もあり、運用現場の「やっていることの見える化」をしていく上で重要と考えている「作業カタログ」について簡単に触れていきます。まず運用業務の各作業の分類方法を説明し、各作業を支える「運用基盤」について見ていきます。

現場への負荷による作業分類(3つの負荷要素)

「作業カタログ」では、以下の3つの評価軸で、運用業務の各作業を、定時作業、申請作業、緊急作業、属人(専門)作業という4つの分類に各業務を振り分けていきます。

  1. ドキュメントの有無(有/無)
  2. 突発具合(3段階)
  3. 起因組織(内部/外部)

図2: 負荷による作業分類

1. ドキュメントの有無

各作業について、ドキュメントがあるかどうかは運用現場にとって非常に重要です。ドキュメントが無いということは、その作業について特定の個人への依存性が高いことを意味します。個人依存性の高さは、特定の人に負荷がかかりやすいかどうか、メンバーの異動や退職による業務継続性リスクが高いかどうかを見える化します。

2. 突発具合

各作業について、その発生を事前予測することは、必要な業務リソースを確保する上で重要です。事前予測が不可能な作業が多い運用現場では、業務バーストするリスクが非常に高いと考えられます。負荷予測性の高さは、業務リソース・コントロールの難易度、要員に対する過負荷リスクを見える化します。

3. 起因組織

各作業について、ステーク・ホルダーとの調整の難易度を知ることは大切です。運用現場が高負荷になった場合の短期的な納期調整や、各作業の改善など根本的な見直しを検討する際の障壁の高さを見える化します。

4つの作業分類

4つの作業分類は、下記のような特性を持ちます。

図3: 作業分類の特性

定時作業

定常運用の1つで、計画ベースで事前に定まった時間に実施されるものです。 外的な変動要因が少なく、最も安定運用が容易で、一般的に少ないリソースで高品質化しやすいのが特徴です。定時ジョブ実行や定型レポート作成などのイメージに近いでしょう。

申請作業

これも定常運用の1つで、外部からの依頼ベースで、定常手順に従って実施されるものです。 発生が外部要因なので、定時作業ほど発生予測の精度は高くありませんが、実績ベースで、事前にある程度は予測が可能となります。定時作業に次いで、少ないリソースで高品質化しやすいのが特徴です。構成変更申請や登録情報変更申請などのイメージに近いでしょう。

緊急作業

これは非定常運用の1つで、外部から突発ベースで発生し、定常手順に従い実施されるものです。本来は発生しないことが望ましい作業ですが、実際に発生を抑えることは難しく、運用組織への期待が大きい領域です。しかし、あくまでもリアクティブな対応なので、なかなか評価されにくい点は意識しておく必要があります。トラブル対応やクレーム対応などのイメージに近いでしょう。

属人作業

非定常運用の1つで、手順書のない作業はすべて属人作業として扱います。「運用でカバー」している部分もここに含まれます。第2回で、運用現場の「属人化」には2つの側面がある、と書いた通り、各作業についてどちらの側面が強いのか検討が必要ですが、今回は割愛します。

次ページでは

次ページでは、各作業を支える「運用基盤」について俯瞰(ふかん)し、「作業カタログ」の最初の版を完成させていきます。

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

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

連載バックナンバー

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

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

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

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