見えない「運用」 - 疲弊する運用現場

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

インターネットのインフラ化と運用現場の疲弊

インターネットの急速な普及および発展により、インターネットを含むIT情報基盤は、社会基盤(インフラ)としての性格を色濃く帯びてきています。

しかし、これらのシステムやサービスを運用している現場では、メンバーに対する恒常的な高負荷、属人的な運用、トラブルの多発に悩まされるなど、事業継続面でのリスクを抱え、コストや効率面での課題に追われながらも、現場の個々人の過大な努力によって日々の運用を維持しているのが現状です。

なお、システムやサービスを「運用している現場」とは、例えば組織や企業において社内向け、対外向けなどを問わず「ユーザーや相手に対して何らかのサービスを提供している人たち」をイメージしています。

本連載では、従来であれば「現場ごとの個別事情に応じて、やり方が異なるため、標準化が難しい」と言われてきた「運用」について、「運用設計」という観点から諸要素を整理し直し、

  1. サービスの安定(安定した運用)
  2. 業務負荷の平準化(楽な運用)
  3. 運用に対する評価の適正化(稼ぐ運用)

の3つを実現するためには何が必要なのか、手掛かりを探っていきます。

図1: 運用方法論の目的(クリックで拡大)


第1回の今回は、インターネットを運用している現場が抱えている悩みや問題点について整理していきます。

運用現場の悩み

冒頭にも書いた通り、近年のインターネット・サービスの急激なインフラ化によって、信頼性の要求が高まっています。この一方で、コスト削減の要求や、生産性向上の要求があります。運用現場は、これらの要求で板ばさみになっているのが実情です。

以下は、こうした状況下で運用に携わっている方々の現場の悩みとして、代表的なものです。


運用現場内部の悩みの声

  • 業務が多岐にわたり、すべてを把握することが困難になっている。
  • 次々と新しいサービスが開発され、その運用に現場での対応が十分でないまま、次の新たなサービスの受け入れに追われている。
  • 運用のためのドキュメントが作られていない。あっても更新されていない。
  • どんなドキュメントが必要なのかが分からない。書き方が分からない。
  • 特定の人間にしかできない業務があり、その人に業務が集中している。
  • 属人化が進み、ノウハウの継承ができていない。
  • 異動により、現場が混乱することが多い。
  • 設計思想が失われた、古い運用業務がある。これが現場の負担になっている。
  • 人が育たない。優秀な人が入ってこない、定着しない。
  • 突発的な業務が多く、計画通りに作業が進まない。残業でカバーしている。
  • 目標が後ろ向き(稼働率など100%からのマイナス評価)で、がんばっても評価されない。
  • トラブルが多く、前向きな改善に着手する余裕がない。
  • ツールが使いにくいが、改修にはコストと期間が必要なため、我慢して使っている。
  • 新規のツールを設計したいが、どんな要求があるのか現場でも分かっていない。

対外組織や関連部署との関係における悩みの声

  • サービス設計導入時の検討漏れや実装が間に合わない部分を「運用でカバーする」というように、設計側による"その場しのぎ"の影響を直接受ける。「えー、カバーするの俺たちなの?」という声が運用現場から上がるものの、上から「がんばれ」と言われるとやるしかない、という現場も多い。
  • 設計と運用を両方やっているため、つい「運用でカバー」することにしてしまう。こうして自分たちの業務を圧迫しながら、次の設計に追われ、疲弊しつつある現場もある。
  • 依頼されてから動き出すまでのリード・タイムが長くなってしまっている。変化のスピードが速い昨今では、特にリード・タイムに対する要求が厳しくなっているが、応えきれていない。
  • 声の大きいユーザーや部署に対して、通常の想定を大幅に超えたサポートを強いられている。
  • コスト削減要求が強いが、どこをどう削減すべきなのかが見えない。

多くの運用現場の人々は、「自分たちだけが苦労し悩んで」いて、それが「自分たちの努力不足のため」と考えているようです。

しかし、上記の現場の声にあるように、実は多くの現場が似たような悩みを抱えています。程度の差はあれど、大企業、ベンチャー、上位レイヤーのWebサービス企業、下位レイヤーのインフラ企業を問わず、国内のIT基盤運用現場においては、非常に似た悩みを抱えて同じように苦しんでいるのが実情ではないでしょうか。

次ページでは、運用現場が「何に困っているのか」、「その要因は何なのか」について分析していきます。

運用現場は何に困っているのか

1ページで見てきたように、運用現場は、非常に多くの悩みや問題を抱えています。これらは一見非常に複雑に絡みあっているようにも見えます。しかし、シンプルに考えなおすと、運用現場は、主に以下の3つの問題点に悩まされていると考えられるのではないでしょうか。

問題点1: 高負荷

まず、運用現場は、業務負荷が高くて困っています。

これは、「運用」の守備範囲が不明確な現場が多く、タスクが落ちてきやすく断りにくい「なんでも運用」に陥いりがちになっている現状によるものと考えられます。「なんでも運用」はまた、サービス設計側の都合による「運用でのカバー」や、特定の顧客や部署に対する「特別対応」による新規フロー追加を日常的に生みます。その結果として、タスクやフローが多岐にわたって非効率になり、ミスやトラブルを誘発しやすい状況を作り出します。実際にトラブルが起これば、そのリカバリによってさらに工数が圧迫されます。このように、タスクがバーストしやすい状況を恒常化させることにつながっています。

問題点2: 属人的

2つ目に、運用現場は、属人的で、暗黙知が多くて困っています。

1つ目の「高負荷」で説明したように、タスクやフローが多岐にわたるため、ドキュメントの作成や更新が追いつかなくなり、属人化が生じやすくなっています。このドキュメント不足が、運用現場のメンバー間での「業務能力や業務品質のばらつき」を生じさせ、そのばらつきが特定の「できる人」への仕事の集中を生んで「さらなる属人化」を促進する、という悪循環を生み出しています。各運用現場では、特定メンバーの異動や退職によるノウハウの消失のリスクを常に抱えています。

問題点3: 費用対効果が見えない

3つ目に、運用現場は、費用対効果が見えにくくて困っています。

「運用」は、サービスのライフ・サイクル上に占める時間的ボリュームが「設計/導入」に比べて圧倒的に大きいにもかかわらず、ポジショニングがあいまいで重要視されていないのが現状です。現実には、運用のためにキャッシュ・アウトが発生することから、運用を任せている側からは「運用コストが高い」と認識されやすく、「コストの一律カット」など後ろ向きの「効率化」が横行します。コスト・カットは、運用の本質的な改善活動を制約することにつながります。これが、現場のモチベーションの低下や、定常的な負荷上昇の要因ともなっています。

運用現場が困っていることの「要因」は何か

上記の通り、運用現場の悩みの多くは、1「高負荷」、2「属人的」、3「費用対効果が見えにくい」という3つの「問題点」が複合化した結果として起こっています。もちろん、悩みのすべてがこの3つだけで説明できるわけではありませんが、多くの現場では、その悩みの8割程度はこの3点で説明できるのではないでしょうか。

この「3つの問題点」の要因は、下記の3つではないかと考えています。

要因1: 運用への期待が明確でない

1つ目の問題点である「高負荷」は、「運用への期待が明確でない」ために起こっています。

みなさんの運用現場では、「運用に何が求められているのか」をきちんと把握できているでしょうか。求められるものは、例えば「一瞬のダウン・タイムも生じさせない高品質のネットワーク運用」だったり、「冗長システムも監視も要らない、低コストのシステム運用」だったり、実は「納期」だったりするかもしれません。これらを、ここでは幅広く「期待」と表現します。

本来、「期待」にはトレード・オフが付きものです。ところが、それがあいまいで明確ではない現場が多いのではないでしょうか。あらゆるステーク・ホルダー(顧客、上司、関連部署)からのあらゆる期待に対応していては、無限にリソースが必要になります。これでは、どうやっても業務は溢れますし、実際にあふれている現場は多いと思います。

主軸となる期待が明確になっていないために、実は本質的でないことにリソースを取られ、本来やらなくてはいけないところ(例えば基幹業務のドキュメント保守など)にリソースがまわっていないケースがあります。適切な優先順位が付けられずに、全部やろうとして、いっぱいいっぱいになって疲弊している、ということになってしまっていると考えられます。

要因2: 運用設計の不在

2つ目の問題点である「属人的」は、「運用設計の不在」のために起こっています。

運用組織の業務設計が適切になされていない、もしくは、そもそも「運用設計」自体がされていないために、自らの業務をきちんと把握できない状況が恒常化しているケースがあります。業務のブレ、モレを生み、トラブルやミスの原因となり、また、業務引き継ぎ(ノウハウ留保)の困難化につながっていると考えられます。

要因3: 期待と消費リソースのひも付けが不明確

3つ目の問題点である「費用対効果が見えない」は、「期待と消費リソースのひも付けが不明確」であるために起こっています。

要因1にあるように、運用現場に対しては、日々いろいろなステークス・ホルダーから多くの期待(作業依頼、要望)が寄せられています。ところが、それぞれの期待に対して消費する(人的、金銭的)リソースのひも付けが実現できておらず、適切な分析や説明ができていないケースがあります。運用を任せている側の満足が得られにくく、「コストが高い」と言われたときに、適切な削減もしくは反論ができない状況を生み出していると考えられます。

運用現場の問題点とその要因(まとめ)

これら3つの要因を、やや強引ですが、分かりやすい言葉に置き換えると、

  1. 「自分たちへの期待というインプット」が見えていない(高負荷)
  2. 「自分たちがやっていること」が見えていない(属人的)
  3. 「自分たちの実績というアウトプット」が見えていない(費用対効果が見えない)

になるかと思います。

図2: 運用現場の問題点とその要因(クリックで拡大)


「要因が見えたからすぐ悩みが解消する」というほど、運用現場は単純なものではありません。ただ、要因が見えたことで悩み解消のためのアプション・プランを立てることは可能になったのではないでしょうか。このあたりは、第2回で言及する予定です。

次ページでは、これら3つの要因をさらに複雑化させる「運用でカバー」による弊害について考察していきます。

「運用でカバー」の弊害

1~2ページで「運用でカバー」という言葉が何度か出てきました。皆さんの現場でも、この言葉が使われたことはないでしょうか。

この「運用でカバー」という言葉には、要求や期待が持っている「想定」と、運用現場で起こる「現実」との差分を、運用現場の努力で回避し続けること、という意味合いが強く含まれています。運用現場に対して、何らかの特別で機動的な対処能力と、高度な判断能力が求められています。このことから、運用業務に対して、工数面においてもリスク面においても、大きな影響を及ぼす危険性を秘めています。

「運用でカバー」の起因は、「もやっとわたして、よしなに」という、あいまいさを容認する日本独特の文化の影響もあるでしょう。また、設計・開発側での何らかの事情(工期不足、開発遅延、仕様が固まらない、詰めが甘いなど)や、運用現場の事情(人手不足、能力不足、予算不足、情報不足など)、外部の事情(声の大きい顧客や部署への対応、想定外の事象の発生)など、さまざまな事情もあるでしょう。いずれにせよ、「困ったら運用でカバー」というのが"お約束"になっている感があります。

「あいまいな期待や突発的な事情に対応できるのが、良い運用現場である」と、依頼側はもちろん、運用現場も前向きにとらえがちです。しかし、実は、これが大きな弊害を生んでいます。

もしかして日本人だけ?

余談ですが、日本人の運用現場では、「運用でカバーしたことはない」という現場がすぐには見当たらないほど、日常的に「運用でカバー」が見られるのが現状です。ある時、「そもそも『運用でカバー』は、外国語には翻訳できないんじゃないか」という疑問を提起した人がいて、一同「うーん」と唸ってしまいました。

日本では、欧米のジョブ・ディスクリプションに該当するものが、あまり意識されていません。現場の士気は高く、教育レベルも相応に高いため、自律的に回避行動を行うことができます。この結果として、日本では「運用でカバー」というものが成立している、と言えるのではないでしょうか。

社会情勢の変化による「運用でカバー」の変質

このように日本の運用現場で多用される「運用でカバー」ですが、以前は、あまり問題になっていなかったように感じます。依頼する方も受ける方も、あえてジョブ・ディスクリプションを明確にしないことで、あうんの呼吸で物事が進められる「柔軟な」体制を組むことができました。そして、そこに掛かるコストについても、ある程度は大目に見るという暗黙の合意があったように思います。

しかし、このことは「頼めば、よしなにやってくれるだろう」という、運用現場に対する一種の甘えを恒常化させます。さらに、ドキュメント化できない「運用でカバー」を増大させて「業務のアンドキュメンテッド化」や属人化を進めます。また、客観的合理性よりも"あうん"の呼吸による、非合理的主観に立脚した業務の日常化をもたらしはじめます。

「運用でカバー」が先鋭化した現場では、「(社内外で)ユーザーの神様化」や、書面外の期待や、「行間のナニカを読め」という際限のない要求にさらされているところもあるようです。

このような状況の中、特に近年は、企業のコスト体質改善が急務となり、お互いにあいまいにしてきたジョブ・ディスクリプション(すなわち期待)とコストのうち、コストの説明責任だけが降ってきています。このことが、今の運用現場を苦しめている起因だと思われます。「もやっと渡されたものに対しての説明責任なんて果たせない」というのが、分かりやすい今の運用現場の心の声ではないでしょうか。

「運用でカバー」がもたらすもの

このように、「運用でカバー」というものは、運用現場に対していくつもの弊害を招いています。 大きなものだけでも、

  • あいまいかつ際限のない要求の増大(もやっと頼めばよしなにやってくれる)
  • 非合理的主観の日常化(アンドキュメンテッド、属人化)
  • 隠れ運用コストの発生(費用対効果説明のさらなる困難化)

が挙げられます。これらは、運用現場が困っている3つの問題点「高負荷、属人的、見えぬ費用対効果」を増幅し、運用現場の機能不全をもたらしています。

さらに、「運用でカバー」のほとんどは「マイナスをゼロにするための努力」に過ぎず、努力の結果が組織的に評価されにくい、という問題があります。運用現場の努力に対して、残念な結果になっていると考えられます。

厳しい言い方でまとめると、「運用でカバー」は「運用の見えない化」をもたらすものであり、安易に実施すると「運用業務価値の棄損」ひいては「評価されない運用現場」を生む。つまり、「運用でカバー」は自分たちの価値を下げる、と言えるのではないでしょうか。

次回は

第2回では、サービスの安定、業務負荷の平準化、運用に対する評価の適正化を実現するために、今回分析した問題点に対してどう解決の糸口を探していけばよいのかを探ります。さらに、そのために必要な、運用現場視点での「運用設計」の考え方や、各種の要素について解説していきます。

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

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

連載バックナンバー

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

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

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

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