システム運用における、5つの大間違いとは(4)

2014年3月21日(金)
株式会社アールワークス

負荷の原因追求は難しい

このようにシステムが変遷していくなかで、運用監視の場面では、いまだに個々のサーバー負荷を確認し、閾値を設け、閾値を超えた場合に障害として検知する手法を採用するケースが多く見受けられる。その閾値が適切かどうかという指摘ももっともだが、そもそも複数の機能を持つサーバーの負荷は、予測できるものなのだろうか。

サーバー負荷の予測は、「負荷上昇の原因となる機能が何なのか」「その機能を別サーバーに移動させれば問題は解決するのか」「別サーバーの負荷はどうなるのか」などといった複合要因が入り組んでいるため、なかなか負荷上昇の原因をつかむことは難しいものである。

そこで、このようなシステムを運用管理する運用担当者がまず行うべきことは、運用担当者自身の存在意義であるところの、「システム全体でサービスが利用可能であることを保証すること」である。言い換えると、「システム全体を俯瞰したうえで、サービスの価値を最大限に高めること」なのである。

サービスの価値を高めるために必要な監視ポイント

一方で、サービス利用者の立場に立ってみれば、「サービスが利用可能でさえあれば、サーバーの負荷などどうでもよい」のである。サービスが利用できなければ、その原因などはどうでもよいから利用可能な状態に戻してくれ、と利用者が思うことは容易に想像できるだろう。

しかし、システムの負荷状況といった些細な面に対して、ある一定の閾値を設けて監視・障害検知している例は多い。このことは、システムの問題を分析するための1つのデータにはなりうるが、障害検知してアラートをあげることには、ほとんど意味がない。

運用技術者の、サービスの価値を高めるために必要な監視ポイントは、

  1. 負荷上昇なのかそうでないのか
  2. 何を障害として検知すべきなのか

を日々考えることであり、それが運用技術者の業務なのである。

Sはその後、「DBサーバーの価値が応答時間で決まること」「応答時間が遅くなる原因の1つにディスクI/Oがあること」を勉強し、T先輩のすばらしさをひしひしと感じるのであった。

著者
株式会社アールワークス
1985年に株式会社アステックとして創業。2000年10月の株式会社アールワークス設立を経て、2005年6月より現在の1社体制に移行。同時に、社名を(株)アールワークス(Rworks, Inc.)に変更。
設立以来、IDC事業やITマネージドサービスを行い、そこで培ったネットワークインフラの運用ノウハウや、さまざまなソフトウェアを開発した技術力を結集し、現在、ITシステムのリモート運用サービスをはじめとして、インフラ構築、ハウジングやホスティングサービス、SaaS/ASP型のシステム監視基盤の提供を行う。単純なオペレーターではない技術提供をベースにした24時間365日の統合的なフルマネージドサービスを提供している。

連載バックナンバー

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

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

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

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