24時間監視体制の構築
24時間監視は「通知を鳴らす仕組み」ではなく、ユーザー影響を最小化する運用システムです。何を見張るか、どこまで自動で直すか、誰がいつ判断するかをあらかじめ設計し、平常時から回せるようにします。重要なのは、技術・オペレーション・ビジネスの指標を一本の線で結ぶことです。
監視対象とアラートの設計基準を決める
SLI/SLOとアラート設計
最初に決めるのは「ユーザー視点の健康状態」です。代表的なSLI（サービス指標）は次の通りです。
- 成功率：注文/ログイン/決済の成功割合
- レイテンシ：API p95, p99
- 可用性：主要エンドポイントの外形監視の稼働率
これにSLO（目標値）を設定し、SLOをどのくらいの速度で食い潰しているか（バーンレート）でアラートを出します。例：2時間窓でバーンレート14倍はP1、24時間窓で6倍はP2。インフラ指標（CPU、ディスクIO、キュー滞留）はSLOに紐づかない単独アラートにしないか、重要なものだけに絞ります。通知はグルーピング・デデュープ・遅延（例：60秒以内の連打を1件化）でノイズを抑えます。
自動化の境界とランブック
自動復旧は「効果が高く、誤動作リスクが低い」範囲から。
- 即自動化：プロセス再起動、Kubernetesのliveness/readiness、スケールアウト
- 半自動：キャッシュフラッシュ、接続先フェイルオーバー（人の承認つき）
- 手動：データ移行、セキュリティ関連、広範な設定変更
各アラートには1つのランブック（前提/確認コマンド/判定/ロールバック）を紐づけます。たたき台づくりや要約はChatGPTやClaudeに投げると初速が上がりますが、最終責任は当番者に置きます。変更時は実行ログを残し、再発時の学習材料にします。
24時間を止めない運用オペレーション
当番・交代の設計
24時間は「L1（監視・一次切り分け）」「L2（サービス担当）」「L3（開発/プラットフォーム）」の多層で回すと安定します。L1は夜間・休日も常時起床前提、L2/L3は呼び出し。交代時はテンプレート化したハンドオフ（直近のP1/P2、保留チケット、リスク項目、重要メトリクスのスナップショット）を5分で共有します。
運用KPIと疲弊対策
- KPI：MTTA/MTTR、時間帯別ページ数、誤検知率、SLO違反時間、アラート1件あたり作業時間
- 疲弊対策：1シフトのページ上限、連続呼出し後の強制休憩、代休、深夜帯の二重ページ禁止
- レビュー：週次で「ノイズ上位10件の抑止」「閾値・バーンレート再調整」「ランブック改善」
訓練は小さく高頻度に。障害想定問答やGameDayを月1回、過去インシデントを再現して対応の筋肉を作ります。Geminiで模擬インシデント文面を自動生成すると準備時間が削れます。
可観測性スタックの実装ステップ
計測と集約
- 計測：アプリにOpenTelemetryを組み込み、重要ユーザーフローのトレースを必ず取得
- メトリクス：Prometheus（Pull）＋Exporter群、SLO計算用Recording Rule
- ログ/トレース：Loki/Elastic、Jaeger/Tempo。相関IDで横断検索できるようにする
- アラート配信：Alertmanagerでルーティング（P1はPagerDuty/電話、P2はSlack）、サイレンス運用を徹底
合成監視と自動復旧
外形監視は複数リージョンからHTTP・ブラウザシナリオ・DNS/TLS期限を監視。KubernetesならHPA、PodDisruptionBudget、Podのリスタート上限で暴走を防ぎます。復旧スクリプトはAnsibleや軽量Runbookツールでコード化し、Copilotに補完させると記述ミスが減ります。
知識化とポストモーテム
インシデント終了から24時間以内にポストモーテムを作成。タイムライン・影響・原因・再発防止の4点だけは必ず書くルールにし、長文要約はClaude、図表埋めや見出し整理はChatGPTに任せると時短になります。最終版はナレッジベースに紐づけ、関連アラートから検索できるようにしておきます。
身近な企業の失敗と改善
小売ECの事例として、夜間のカート障害で機会損失が増え、監視はPingとCPUのみ、Slackが深夜に鳴り続けるのに誰も気づかないことがありました。失敗の核心は「ユーザー指標がない」「通知が多すぎ」「一次切り分け不在」の3点でした。
改善は90日で段階導入。
- 1〜30日：注文成功率99.9%、API p95 800msのSLOを設定。OpenTelemetryで主要フローを計測し、Prometheus＋Alertmanagerでバーンレートアラートを構築。Slack通知はグルーピング、P1は電話ページへ。
- 31〜60日：L1当番を平日日中は社内、夜間休日はローテーション1名＋バックアップで運用。ハンドオフとランブックを雛形化し、ChatGPTで初稿を作成、Claudeで日本語表現を整備。
- 61〜90日：合成監視を追加、KubernetesのlivenessProbeと自動再起動、決済系は手動承認付きフェイルオーバー。ポストモーテムのテンプレを整備し、Geminiで要約を作って週次レビューにかける。
結果、MTTAは25分→6分、夜間ページは月60件→12件、誤検知は70%削減。売上影響は四半期で約18%改善しました。運用者の負荷も可視化され、当番の満足度は向上しました。
24時間監視は、プロダクトのSLOと運用の型、可観測性が三位一体で回ると強くなります。生成AI（ChatGPT/Claude/Gemini）や開発支援（Copilot）は補助輪として有効ですが、最後は現場の判断と仕組み化がものを言います。こうした設計・実装・運用を粘り強く積み重ねる営みこそ、サーバ監視運用事業の土台そのものです。
