オンコールと運用体制

オンコールとは

オンコール（On-Call） は、営業時間外にアラートを受け取り初期対応を行う当番制度です。 『入門監視』第 3 章が強調するとおり、オンコールは「必要悪」ではなく、設計すべきシステムの一部です。 持続可能なオンコールを実現するには、ローテーション・エスカレーション・補償の 3 つを整備する必要があります。

ローテーション設計

オンコールのローテーションは最低 2 名以上で回し、連続担当日数は 7 日以内に制限します。 プライマリ（一次対応）とセカンダリ（バックアップ）の 2 層体制にすることで、対応漏れや疲弊を防ぎます。 休日明けの翌日に代休を付与するなど、人間への配慮をプロセスに組み込むことが長続きの秘訣です。

# PagerDuty スケジュール定義例
schedule:
  name: "backend-oncall"
  timezone: "Asia/Tokyo"
  layers:
    - name: "primary"
      rotation_turn_length_seconds: 604800  # 7日
      users:
        - id: "user_tanaka"
        - id: "user_suzuki"
        - id: "user_yamada"
    - name: "secondary"
      rotation_turn_length_seconds: 604800
      users:
        - id: "user_sato"
        - id: "user_ito"

エスカレーションポリシー

アラート発火後、プライマリが 5 分以内に応答しなければセカンダリへ自動エスカレーションします。 Sev1 の場合はチームリードとエンジニアリングマネージャーにも同時通知し、War Room を自動開設します。 エスカレーション先と条件を事前に定義し、深夜の判断負荷をゼロに近づけることが目標です。

トイルの削減

オンコール中に繰り返し発生する手動作業を記録し、月次で上位 3 件を自動化ターゲットにします。 「同じ Runbook を 3 回実行したら自動化する」をチームルールにすると、改善が継続的に回ります。 自動化の投資対効果は (手動対応時間 × 頻度) − 自動化開発コスト で見積もれます。

セルフヒーリング

セルフヒーリング（Self-Healing） は、既知の障害パターンに対してシステムが自動で復旧する仕組みです。 Pod の再起動、コネクションプールのリセット、サーキットブレーカーの発動などが代表例です。 自動復旧が実行された場合もログを記録し、根本原因の修正を忘れないことが重要です。

# Kubernetes の自動復旧例: livenessProbe によるセルフヒーリング
kubectl describe pod api-server-7d8f9c | grep -A5 "Liveness"
# Liveness:   http-get http://:8080/healthz delay=10s timeout=3s period=10s
# => ヘルスチェック失敗で自動再起動される

開発者とオペレーターの責任バランス

「作った人が運用する（You Build It, You Run It）」は理想ですが、全員がオンコールを担うと専門性が分散します。 現実的には、プラットフォームチームが共通基盤（監視・デプロイ・アラート基盤）を提供し、サービスチームが自サービスのオンコールを担当するモデルが多く採用されます。 どちらの場合も、オンコール負荷のメトリクス（アラート件数、対応時間、深夜起床回数）を可視化して改善サイクルを回すことが不可欠です。

まとめ

📖 参考: 『入門監視』第 3 章 — オンコール