Monitoring operations

運用・監視・障害対応

目的

リリースして終わりにしない。本番稼働中のシステムが「いつ・何が・どこで壊れたか」を素早く把握し、 ユーザー影響を最小化しながら復旧・再発防止まで完結させる手順と成果物を定める。

使うタイミング

• 新機能リリース前に監視設計・アラート設計を行うとき
• 本番障害が発生し、対応フローを回すとき
• 障害後にポストモーテムを書くとき
• 既存の監視を見直す(アラート疲れが起きている・夜中に何度も起こされる)とき
• 個人開発でも「最低限の監視」を構築したいとき

観測性の3本柱

1. 構造化ログ

• JSON形式で出力。timestamp / level / requestId / userId / message / error を標準フィールドとする
• リクエストIDを全ログに付与し、1リクエストの流れを追跡可能にする
• レベル運用: ERROR=人手対応要、WARN=劣化の兆候、INFO=正常な主要操作、DEBUG=本番OFF

2. メトリクス(RED指標を中心に)

• Rate(スループット): 単位時間あたりリクエスト数
• Errors(エラー率): 5xx / 全リクエスト比率
• Duration(レイテンシ): p50 / p95 / p99。平均値だけでは外れ値を見落とす
• リソース(CPU・メモリ・ディスク)は二次的シグナル。RED指標が正常なら深追い不要

3. 分散トレース

• マイクロサービス構成では必須。サービス間の呼び出しを単一トレースIDで紐付ける
• モノリスでも「どのミドルウェアで時間がかかっているか」可視化に有効
• 参照: [[microservices]]

進め方

1. SLOを決める([[non-functional-requirements]] で定義済みならそれを使う)

   • 例: 可用性 99.9% / 月、p95レイテンシ 500ms 以内、エラー率 0.1% 以下
   • SLOが決まると「何を監視するか」が自動的に決まる。ユーザー影響起点で考える

2. 監視設計シートを書く(後述テンプレート使用)

   • 監視項目・閾値・重大度・通知先・対応手順を表にまとめる
   • 「これが鳴ったら誰が何をするか」を書けないアラートは設定しない

3. アラートを設計する

   • 鉄則: アクション可能なものだけ鳴らす
   • 重大度3区分: P1=即時対応(24h)、P2=営業時間内対応、P3=記録のみ
   • P1: ページャー/電話で通知。P2: チャット通知。P3: ダッシュボードのみ
   • アラート疲れ(鳴り続けて誰も見なくなる状態)は最悪。鳴ったら必ず対応 or 閾値見直し

4. ダッシュボードを1枚作る

   • エラー率・レイテンシ(p95)・スループット・直近デプロイマーカーを1画面に配置
   • 一目で「健全/異常」が分かることが最重要。詳細は別ダッシュボードへ

5. ランブックを書く

   • 頻出障害シナリオごとに: 症状 / 確認コマンド / 対処手順 / エスカレーション先
   • 「午前3時に眠い目をこすりながら実行できる粒度」 で書く
   • コマンドはコピペ可能な形式で。環境変数や接続先も明記

6. バックアップ・リストアを検証する

   • 自動バックアップを設定したら必ずリストア訓練を実施する
   • 「リストアしたことのないバックアップは無いのと同じ」
   • 復旧時間(RTO)と復旧時点(RPO)を計測・記録する

7. 個人開発の最小構成

   • 外形監視: UptimeRobot 無料枠(5分間隔・メール通知)
   • エラートラッキング: Sentry 無料枠(エラー集約・スタックトレース)
   • メトリクス: Railway / Render / Vercel 等のプラットフォーム標準メトリクス
   • 参照: [[solo-development]]

障害対応フロー

検知(アラート/ユーザー報告)
  ↓
[5分以内] インシデント宣言・担当者アサイン
  ↓
[15分以内] 影響範囲の把握(何が・どのくらい・誰に影響しているか)
  ↓
[30分以内] ユーザー・ステークホルダーへの状況告知(「調査中」だけでもよい)
  ↓
復旧を最優先(原因調査より先)
  - 直近デプロイがあればロールバックを第一候補にする([[cicd-deployment]])
  - トラフィック切り替え・機能フラグOFF・スケールアウトなど手段を選ぶ
  ↓
サービス復旧確認・ユーザーへの復旧通知
  ↓
根本原因調査([[debugging]] のフローを適用)
  ↓
[5営業日以内] ポストモーテム作成・共有

成果物テンプレート

ポストモーテム

# ポストモーテム: [インシデント名]

**原則: 非難なし(blameless)。個人でなくシステムと手順に目を向ける。**

## 概要
- 発生日時: YYYY-MM-DD HH:MM (JST)
- 検知方法: [アラート名 / ユーザー報告 / 社内報告]
- 復旧日時: YYYY-MM-DD HH:MM (JST)
- ダウンタイム: X時間Y分

## ユーザーへの影響
- 影響ユーザー数: 約X人
- 影響内容: [例: ログイン不可 / 決済エラー / ページ表示遅延]

## タイムライン
| 時刻 | 出来事 |
|---|---|
| HH:MM | アラート発報 |
| HH:MM | 担当者が確認開始 |
| HH:MM | 原因仮説Aを確認 |
| HH:MM | ロールバック実施 |
| HH:MM | サービス復旧確認 |

## 根本原因
[Why→Why→Why で掘り下げた根本原因を記述]

## うまくいったこと
- [例: アラートが3分以内に発報した]
- [例: ロールバック手順が整備されており10分で完了した]

## 再発防止アクション
| アクション | 担当 | 期限 | 状態 |
|---|---|---|---|
| [具体的な改善策] | @xxx | MM-DD | TODO |
| [監視閾値の調整] | @yyy | MM-DD | TODO |

監視設計シート

| 監視項目 | 閾値(警告) | 閾値(緊急) | 重大度 | 通知先 | 対応ランブック |
|---|---|---|---|---|---|
| エラー率 | 0.5% | 1.0% | P1 | PD/Slack#alert | runbook/error-rate.md |
| p95レイテンシ | 800ms | 2000ms | P1 | PD/Slack#alert | runbook/latency.md |
| 可用性(外形) | - | 1回失敗 | P1 | PD/メール | runbook/downtime.md |
| CPU使用率 | 70% | 90% | P2 | Slack#warn | runbook/cpu.md |
| ディスク使用率 | 80% | 95% | P2 | Slack#warn | runbook/disk.md |

チェックリスト

• SLOを数値で定義した(可用性・レイテンシ・エラー率)
• 全アラートに「誰が・何をする」が紐付いている
• ダッシュボードで30秒以内に健全/異常を判断できる
• 頻出障害シナリオのランブックが存在する
• バックアップのリストアを実際に試した
• ポストモーテムを非難なしで書く文化がある(または個人開発なら自己振り返りの習慣がある)
• アラートが鳴ったら必ず対応 or 閾値見直しのルールがある

アンチパターン

• リリース後に監視を後付け: 監視設計はリリース前。本番稼働後に気づいても手遅れになることがある
• 全アラートをチャットに垂れ流し: 誰も見なくなる。通知先と重大度を必ず区別する
• 平均レイテンシだけ監視: p95/p99を見ないと遅いユーザーを見逃す
• ポストモーテムが犯人探しになる: 個人を責めても再発は防げない。システムと手順に目を向ける
• ランブックなしで属人対応: 担当者が休んでいると何もできない状態になる
• バックアップのリストア未検証: バックアップが壊れていても気づかない。定期的なリストア訓練が必須
• SLOなしで「なんとなく監視」: 何が正常で何が異常か分からないため、アラートが多すぎるか少なすぎるかのどちらかになる

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割	担当	担当する作業
司令塔(メインモデル)	最終判断者	障害時の影響判断・復旧判断・ステークホルダーへの報告文作成・ポストモーテムの統括
Opus相当	深い分析	根本原因分析(Why連鎖)・SLO設計の妥当性評価・複雑なシステム全体の障害仮説立案
Sonnet相当	実装・構築	監視設定の実装・ダッシュボード構築・ランブック作成・アラートルール記述・ポストモーテムドラフト
Haiku相当	収集・一次解析	ログ・メトリクスの収集・タイムライン整理・エラーカウント集計・コマンド実行と結果転記

関連スキル

• [[orchestration]] - モデル委譲の共通原則
• [[non-functional-requirements]] - SLO/SLAの定義
• [[cicd-deployment]] - ロールバック・デプロイ管理
• [[debugging]] - 根本原因調査の手順
• [[microservices]] - 分散トレーシングの設計
• [[security]] - セキュリティインシデント対応
• [[solo-development]] - 個人開発での現実的な監視構成
• [[performance-optimization]] - レイテンシ・スループット改善