4つのタイプから想定する、適切なシステム運用のサイクル

適切なタイミングでのシステム拡張：「監視（対応）」⇒「分析」⇒「拡張」

システムは、運用を続けるにつれて、ユーザー数や蓄積する情報の増大が避けられなくなる。その結果、次第に少々の設定変更による改善では間に合わなくなるケースも発生する。その際には、不足しているシステムリソースを見極めて、増強を図る。または、現状にそぐわなくなったアプリケーションを、部分的に改修する。

例えば、データ肥大に対しては、データベースサーバーの増強やWebサーバーアプリケーションのDBに対するクエリー（処理要求）の改修が考えられるし、またユーザー数の増大に対しては、Webサーバーの台数追加やアプリケーションのパフォーマンスチューニング^※2が考えられる。

※2：プログラムをより処理効率の良いものへ修正すること。

それでは、どの部分を拡張すればよいのだろうか？この指針は、当然データ分析結果の中にある。

このサイクルでは、サービスの利用傾向の変化にシステムを適応させていくことによって、システムリソースの不足などによる障害が、未然に防がれるようになっていく。なお、分析結果からボトルネックが判明しないのであれば、それは収集ポイントが不足しているからなので、ポイントの増強を図り、改めて分析をすることになる。

将来の大障害を防止する計画的なシステム刷新：「監視（対応）」⇒「分析」⇒「刷新」

システムには寿命があり、それはとても短い。

サーバーやネットワーク機器などのハードウェアであれば、故障なく稼働できるのは運がよくて5年程度だろう。このようなハードウェアの寿命については、各ハードウェアベンダーのサポート期間を確認すれば簡単に判明する。

同様に、OSにも寿命があるし、ミドルウェア群にもそれぞれ寿命がある。そして忘れてはいけないのは、アプリケーションにも寿命は存在することだ。アプリケーションは一旦完成すると、微修正を続ければ永久に使えるように思うかもしれないが、このような発想で運用を続けると、最終的に破滅的な事態を招く可能性がある。

前項で述べた「拡張」で、修正を重ねる度に、アプリケーションは必ず初期段階よりもプログラムが肥大し、処理内容が複雑化していく。同時に担当者や責任者も変遷し、次第にアプリケーションの全体像を把握している人材が失われてしまう。その先でアプリケーションに起因する障害が発生した場合、原因を突きとめることができるだろうか。

このように、ハードウェアの老朽化やアプリケーションの複雑化による問題が顕在化する＂前に＂、全面的にシステムを刷新する必要がある。一番最後に説明するこの「刷新」だが、刷新タイミングは運用サイクルの一番最初、システム導入時に決定しておくべき事項である。

「システムが老朽化して最近故障率が…」や、「もう誰にも今のアプリケーションの全体像は把握できないし…」となってからでは、手遅れに近い状態なのだ。普段から十分にシステムを把握して運用されてきたのであれば、計画的に行われる刷新において、焦ることなく確実に新システムへ移行できるだろう。

そして運用サイクルを繋いでいく

まずは小さな日々の運用サイクルで構わないので、明日から回し始めてみよう。

小さな成功や失敗を積み重ねることによって、システムは、必ず良くなっていく。自身から始まった輪は次第に大きくなり、周囲を巻き込むようになる。その結果、問題の原因は明らかになり、改善手法は共有されていくのだ。

そうなれば、いつしか、次のシステムに対する構想はできあがっていることだろう。その中心にいるのはあなた、つまりはシステム運用担当者だ。