問題点1：手順書の管理ができない

監視サーバーの設置担当者が作成する対応手順書は、監視サーバー設置直後から劣化が始まる。なぜならば、システムは時を重ねるに従い、ログやデータの増加に伴うディスク使用率の変化、ユーザーの変遷、システムの増強、コンテンツの変更など、システムそのものの価値向上のため変化し続けるからだ。

システムが変化したとしても、当然、対応手順書は自動的に更新されない。そのため、手順のない障害通知が発生することになる。また、運用をアウトソースした先がシステムの変化に気づかないことで、手順書どおりに対応できなくなる場面も想定できる。

問題点2：手順書外の障害に対応できない

システムの障害は、実は単独で発生することは少ない。複数の障害が一度に発報され、その中から根本原因となっている障害を見抜く力が必要である。

手順書ベースの対応を実施するアウトソース先は、当然ながら、障害検知時に通知されたアラート毎に対応する手順書にしたがった業務としているため、ネットワーク切断などで多数の障害が同時に発報された場合には、ひとつずつ手順書に沿って対応しようとするか、あるいは手に負えなくなり、すべての対応を業務発注者であるあなたに任せるべく、電話を入れる（エスカレーションする）。

手順書外の障害に対応できない以上、アウトソース先からのエスカレーションを受ける社内部門を用意しなければならず、その結果、当初想定していたようなコストダウンは望めないであろう。

問題点3：監視ツールの管理ができない

運用アウトソース先は、手順書ベースでの対応を業務とするため、監視ツールの管理を行わない。たとえ監視ツールの管理を依頼したとしても、システムそのものを深く理解することなく、既存の手順書に紐づくような監視設定しか行わないことは容易に想定できる。

運用開始時点において、「監視ツールの管理手順」「新しい監視項目の設定方法」「手順書の書き方や考え方」などに関する資料はそろっているだろうか。また、監視ツール自体のセキュリティホールへの対応、アップデートなどは誰が行うのか。

このように、ツールの導入や手順書ベースで対応するアウトソースのみでは、システムの運用体制に必要な要素が不十分であると言えよう。

問題点4：システムの問題改善ができない

監視ツールを導入し、手順書ベースの障害対応だけをアウトソースするという考えの背景には、運用業者に、夜間や休日に検知した障害のうち、緊急性のないものをフィルタリングしてもらいたいという考えがあるのではないだろうか。しかし、これは、到底システムの問題解決ができる体制とは言えない。監視システムを自社で導入しておきながら、よく発生する障害の検知を外部の業者によってフィルタリングしてしまうと、問題の根本原因を把握することが困難になる。

本来、ツールや仕組みと障害対応体制は、一元化されて初めてシステムの改善につながる。したがって、自社で一連の対応を行うか、あるいはツールや仕組みの構築から高度な対応までを含めてアウトソースすることが重要である。