システム運用における、5つの大間違いとは（4）［2ページ目］

負荷の原因追求は難しい

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

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

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

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

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

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

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

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

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

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