監視ツールを導入しても障害対応が回らない中小企業が陥りがちな落とし穴と、現場で機能する運用体制の作り方を実案件ベースで解説します。
「監視してるのに、気づいたのは翌朝」——その原因、ツールじゃありません
こんな経験、ありませんか？
「夜中にサーバーが落ちていたらしいが、誰も気づかず朝になってから発覚した」 「監視ツールからアラートメールは届いていた。でも誰も対応しなかった」
監視体制を構築したはずなのに、いざ障害が起きると対応が後手に回る——これは中小企業のWeb運用でもっとも多く見られるパターンのひとつです。Fivenineでも過去20年以上の支援の中で、同じような相談を何度も受けてきました。
原因はツールの性能不足ではありません。「誰が・いつ・どのように対応するか」というルールが定まっていないことが本質的な問題です。
この記事では、監視ツールを「仕組み」として機能させるための運用体制の構築方法を、実案件での失敗談と解決策を交えながら解説します。Web担当者として自社の運用を整備したい方、またはエンジニアとしてクライアントに提案したい方に向けた実践的な内容です。
なぜ「監視ツールだけ入れる」は機能しないのか
多くの中小企業では、サーバー監視の体制構築が次のような順序で進みます。
- 障害が発生して損害が出る
- 「監視しなきゃ」という意識が芽生える
- UptimeRobotやMackerelを導入し、アラート通知を設定する
- 「これで大丈夫」と安心する
しかし、4のあとに「誰がそのアラートを受け取り、何を判断し、どう動くか」を決めていないケースがほとんどです。
たとえばSlackやメールにアラートが届いても、チーム全員に通知が飛ぶ設定になっていると「誰かが対応するだろう」という心理が働き、誰も対応しない事態が起きます。これは有名な「傍観者効果」そのものです。
また、担当者が一人しかいない場合、その人が休暇中や体調不良のときに誰も対応できなくなります。属人化したオンコール体制は、運用体制の見た目を作っているだけで、実質的には機能していません。
運用体制の構築：4つのレイヤーで考える
機能するサーバー監視体制は、次の4つのレイヤーで整備します。
レイヤー1：監視設計（何を監視するか）
まず「監視対象の優先度づけ」から始めます。すべてを同じ重みで監視すると、アラートの嵐で担当者が疲弊し、重要な通知を見落とします。
flowchart TD
A[監視対象の洗い出し] --> B{ビジネス影響度}
B -->|高: 売上・問い合わせに直結| C[Criticalアラート\n即時対応必須]
B -->|中: ユーザー体験に影響| D[Warningアラート\n数時間以内に対応]
B -->|低: 内部処理・ログ| E[Infoアラート\n翌営業日対応可]
C --> F[オンコール担当者に電話/SMS]
D --> G[Slackチャンネルに通知]
E --> H[ログ蓄積のみ]典型的な優先度の分類例は以下のとおりです。
Critical（即時対応）
- サイトの死活監視（HTTP 5xxエラー、タイムアウト）
- SSL証明書の有効期限（残7日以下）
- ディスク使用率 90%超
Warning（数時間以内）
- CPU使用率が5分間継続して80%超
- メモリ使用率 75%超
- SSL証明書の有効期限（残30日以下）
Info（翌営業日）
- 定期バックアップの完了確認
- ログローテーションの確認
レイヤー2：通知設計（誰にどう届けるか）
アラートの重要度ごとに通知先と手段を変えます。Mackerelを例に挙げると、以下のような設定が実用的です。
# mackerel-agent.conf の監視ルール例
[plugin.metrics.custom_check]
command = "/usr/local/bin/check_disk.sh"
# アラートルール（APIまたはWeb UIで設定）
# Critical: Slackの #critical チャンネル + SMS（PagerDutyなど）
# Warning: Slackの #monitoring チャンネルのみ
# Info: メール通知のみ（週次ダイジェスト）
ポイントは「Critical通知はSlackだけにしない」ことです。Slackは見落とされる可能性があります。PagerDutyやOpsGenieのような電話・SMSで呼び出せるオンコールツールと組み合わせることで、確実な一次連絡を実現できます。
レイヤー3：対応設計（誰が・何をするか）
ここが最も軽視されがちで、かつ最も重要なレイヤーです。**ランブック（Runbook）**と呼ばれる対応手順書を整備します。
flowchart LR
A[アラート受信] --> B[一次確認担当者]
B --> C{自己解決可能?}
C -->|Yes| D[対応・復旧\nRunbook参照]
C -->|No| E[二次対応担当者へエスカレーション]
E --> F{解決?}
F -->|Yes| G[復旧確認・報告]
F -->|No| H[外部ベンダー（制作会社等）へ連絡]
D --> G
G --> I[事後レポート作成]Runbookの最低限の記載項目は以下のとおりです。
- アラート名：何が検知されたか
- 初期確認手順：まず何を確認するか（コマンド例も記載）
- 一次対応手順：Nginxの再起動、キャッシュのクリア等
- エスカレーション基準：何分経っても解決しなければ誰に連絡するか
- 連絡先：名前・電話番号・Slackアカウント
# Runbook記載例：Nginxが応答しない場合の一次対応
# 1. Nginxのプロセス確認
sudo systemctl status nginx
# 2. エラーログの確認（直近50行）
sudo tail -n 50 /var/log/nginx/error.log
# 3. 設定ファイルの構文チェック
sudo nginx -t
# 4. 問題なければ再起動
sudo systemctl restart nginx
# 5. 復旧確認
curl -I https://example.com
レイヤー4：オンコールローテーション（いつ誰が担当するか）
一人に集中させない体制を作ります。週単位でプライマリ（一次対応）とセカンダリ（バックアップ）を決め、カレンダーで共有します。
小規模チームでも「2名でローテーション」するだけで、属人化リスクを大幅に軽減できます。担当者不在時の連絡先として、制作会社やインフラベンダーとのSLA（対応時間の取り決め）を契約上明確にしておくことも有効です。
実案件での失敗：「体制表を作っただけ」になったケース
ある神奈川県内のEC事業者では、Mackerelを導入してSlack通知も設定し、一見完璧な監視体制を構築しました。しかし半年後に深夜の決済エラーが発生した際、対応が翌朝まで遅れ、数件の機会損失が発生しました。
原因を追うと、次の3点が抜けていました。
- Slackの通知が全員に飛んでいて、誰も「自分が対応すべき」と思わなかった
- Runbookはあったが、EC決済システム固有のエラーコードへの対処が書かれていなかった
- 夜間のオンコール担当が名目上は決まっていたが、スマートフォンのSlack通知をオフにしていた
改善後は「Critical通知はPagerDuty経由でスマートフォンに電話着信」「担当者不在の場合は5分後に自動でセカンダリに転送」という設定に変更し、その後の深夜障害はすべて30分以内に一次対応が完了するようになりました。
よくある失敗パターンと対処法
**対処法**：まず「今すぐ対応が必要なもの」だけをCriticalに設定し、最初の1ヶ月は運用しながら閾値を調整します。完璧な設定を最初から目指さないことが重要です。
**対処法**：Runbookをコードと同じGitリポジトリで管理し、インフラ変更時にプルリクエストレビューの対象に含めます。最低でも四半期に一度、手順書の棚卸しを実施しましょう。
**対処法**：制作会社と保守契約を結ぶ際、「障害発生から○時間以内に一次回答」「対応時間帯：平日9〜18時 / 緊急時は24時間」といった内容をSLAとして書面で確認します。
**対処法**：ステージング環境も最低限の死活監視を行い、本番環境とは別チャンネルで通知します。ステージングのアラートは優先度を下げつつも、見える場所に通知を残します。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まとめ：ツールより先に「ルール」を作る
サーバー監視は、ツールを導入した瞬間ではなく、「誰が・いつ・何をするか」が全員に共有された瞬間に初めて機能します。
監視設計・通知設計・対応設計・オンコールローテーションの4つのレイヤーを順番に整備することで、「監視してるのに誰も動かない」という状態から脱却できます。
小規模な体制でも、まずは「Criticalアラートの担当者を一人決める」「その人の電話番号に通知が届く設定にする」という最小構成から始めることをおすすめします。完璧な体制を一度に作ろうとするより、動く体制を少しずつ育てる方が現実的です。
Fivenine Designでは、監視ツールの選定・導入支援から、Runbook作成・オンコール体制の整備まで、運用体制の構築をトータルでサポートしています。 「今の体制で本当に大丈夫か確認したい」という相談も歓迎しています。
