# 障害対応・性能の運用設計

## バックアップ・リストア設計

### バックアップ・リストア方針

**基本方針**
- システム方式設計「可用性設計」で定義した方針に基づき、データ保護を実現する
- RPO（Recovery Point Objective）: 1時間以内
- RTO（Recovery Time Objective）: 4時間以内
- バックアップデータは暗号化して保存
- 定期的なリストアテストを実施（月次）

**バックアップ対象**
| データ種別 | バックアップ方式 | 頻度 | 保存期間 | 保存先 |
|-----------|---------------|------|---------|-------|
| DBデータ（フル） | mysqldump / pg_dump | 日次 03:00 | 30日 | S3 |
| DBデータ（増分） | バイナリログ / WALログ | 1時間ごと | 7日 | S3 |
| ファイルストレージ | rsync | 日次 04:00 | 30日 | S3 |
| 構成ファイル | Git管理 + S3 | コミット時 | 無期限 | GitHub + S3 |
| ログファイル | Fluentd → S3 | リアルタイム | 90日 | S3 Glacier |

### バックアップ手順

**手順の概要**
1. バックアップスクリプトの実行（cron / Lambda）
2. データのダンプ・圧縮
3. クラウドストレージへのアップロード
4. バックアップ成功の確認・通知
5. 古いバックアップの自動削除

**バックアップ実行タイミング**
- フルバックアップ: 日次 03:00（システム負荷が低い時間帯）
- 増分バックアップ: 1時間ごと
- 手動バックアップ: リリース前、大規模データ変更前

### リストア手順

**リストア実行フロー**
```mermaid
graph TD
    A[リストア要請] --> B[バックアップファイル選定]
    B --> C[ステージング環境でリストアテスト]
    C --> D{リストア成功?}
    D -->|No| E[別バックアップで再試行]
    E --> C
    D -->|Yes| F[本番環境へのリストア承認取得]
    F --> G[本番DBの現状バックアップ]
    G --> H[リストア実行]
    H --> I[データ整合性確認]
    I --> J[アプリケーション動作確認]
    J --> K[リストア完了報告]
```

**リストア時の注意事項**
- 本番環境へのリストアは必ず承認フローを経る
- リストア前に現在のDBのバックアップを取得
- まずステージング環境でリストアテストを実施
- リストア後はアプリケーションの動作確認を実施
- リストア作業のログを記録

---

## インシデント管理

### 障害検知方法

**検知経路**
```mermaid
graph TD
    A[障害発生] --> B[監視システム検知]
    A --> C[利用者報告]
    B --> D[自動アラート PagerDuty/Slack]
    C --> E[問い合わせ窓口 メール/電話]
    D --> F[オンコール担当者]
    E --> F
    F --> G[初動対応開始]
```

**監視項目と検知基準**
| 監視項目 | 検知基準 | アラートレベル | 通知先 |
|---------|---------|--------------|-------|
| サーバーダウン | ヘルスチェック3回連続失敗 | Critical | PagerDuty |
| CPU使用率 | 90%以上が5分継続 | Warning | Slack |
| メモリ使用率 | 95%以上 | Critical | PagerDuty |
| ディスク使用率 | 85%以上 | Warning | Slack |
| API応答時間 | 3秒以上が10回連続 | Warning | Slack |
| エラー率 | 5%以上 | Critical | PagerDuty |
| DB接続エラー | 1件でも発生 | Critical | PagerDuty |

### 初動対応手順

**障害発生時の対応フロー**
```mermaid
graph TD
    A[アラート受信] --> B[インシデント起票 JIRA/ServiceNow]
    B --> C[影響範囲の確認]
    C --> D{サービス影響あり?}
    D -->|Yes| E[ユーザー通知 ステータスページ更新]
    D -->|No| F[内部対応のみ]
    E --> G[ログ採取]
    F --> G
    G --> H[切り分け作業]
    H --> I{原因特定?}
    I -->|Yes| J[対応実施]
    I -->|No| K[エスカレーション]
    K --> L[上位担当者/開発チーム参加]
    L --> H
    J --> M[復旧確認]
    M --> N[ユーザー通知 復旧完了]
    N --> O[事後報告書作成]
```

**初動対応チェックリスト**
- [ ] インシデントチケット起票（件名、発生時刻、検知方法）
- [ ] 影響範囲の確認（対象サービス、ユーザー数、データ影響）
- [ ] ユーザー通知（ステータスページ更新、問い合わせ対応準備）
- [ ] ログ採取（アプリログ、アクセスログ、エラーログ、DBログ）
- [ ] 監視ダッシュボード確認（CPU、メモリ、ネットワーク）
- [ ] 直近の変更履歴確認（デプロイ、設定変更、データ変更）

**採取するログ**
- アプリケーションログ（過去1時間分）
- アクセスログ（過去1時間分）
- エラーログ（過去1時間分）
- システムログ（/var/log/messages, syslog）
- ミドルウェアログ（Web Server, App Server, DB）
- クラウドサービスログ（CloudWatch Logs など）

**切り分けの観点**
- いつから発生しているか（開始時刻）
- どの機能・画面で発生しているか
- 特定ユーザーのみか、全体か
- 外部要因（ネットワーク、外部API）の影響は？
- 直近の変更（デプロイ、設定変更）との関連性

### エスカレーション手順

**エスカレーションフロー**
```mermaid
graph LR
    A[Level 1 オンコール担当] -->|30分経過or判断不可| B[Level 2 運用リーダー]
    B -->|1時間経過or技術判断必要| C[Level 3 開発チーム]
    C -->|重大インシデント| D[経営層 広報担当]
```

**エスカレーション基準**
| レベル | 対応者 | 条件 | 通知方法 |
|-------|-------|------|---------|
| Level 1 | オンコール担当 | 全アラート | PagerDuty自動通知 |
| Level 2 | 運用リーダー | 30分以内に解決不可 / サービス影響大 | 電話 + Slack |
| Level 3 | 開発チーム | 技術的判断が必要 / コード修正必要 | 電話 + Slack + JIRA |
| Level 4 | 経営層・広報 | 重大インシデント / メディア対応必要 | 電話 + メール |

**エスカレーション時の情報共有**
- インシデントチケットURL
- 発生時刻・経過時間
- 影響範囲・ユーザー数
- 現在の対応状況
- 採取済みログの保存場所

### 障害区分（重大度分類）

| 重大度 | 定義 | 対応目標時間 | 例 |
|-------|------|------------|---|
| Critical | サービス全停止またはデータ損失 | 検知後15分以内に初動 | DBサーバーダウン、全ユーザーアクセス不可 |
| High | 主要機能が使用不可 | 検知後30分以内に初動 | 決済機能エラー、ログイン不可 |
| Medium | 一部機能の劣化 | 検知後2時間以内に初動 | レポート生成遅延、一部ページ表示遅延 |
| Low | 軽微な問題 | 営業時間内に対応 | UIの表示崩れ、ログ出力異常 |

**重大度判定のポイント**
- サービス停止の範囲（全体 / 一部）
- ユーザー影響の大きさ（全ユーザー / 特定ユーザー）
- ビジネスへの影響（売上損失、信用失墜）
- データ損失リスク

### 暫定対応から恒久対応の流れ

**対応フェーズ**
```mermaid
graph TD
    A[障害検知] --> B[初動対応 ログ採取・切り分け]
    B --> C[暫定対応 応急処置]
    C --> D[サービス復旧]
    D --> E[根本原因分析 RCA: Root Cause Analysis]
    E --> F[恒久対応策の検討]
    F --> G[恒久対応の実装 コード修正・設定変更]
    G --> H[テスト ステージング環境]
    H --> I[本番環境デプロイ]
    I --> J[効果確認 再発防止確認]
    J --> K[事後報告書作成 ポストモーテム]
```

**暫定対応の例**
- サーバー再起動
- 負荷の高いプロセスの停止
- 一時的な機能停止（機能フラグOFF）
- 手動でのデータ修正
- トラフィック制限
- キャッシュクリア

**恒久対応の例**
- コードのバグ修正
- インフラスペックの増強
- アーキテクチャの見直し
- 監視アラートの閾値調整
- 運用手順書の改善
- 自動化スクリプトの追加

**事後報告書（ポストモーテム）の記載内容**
- インシデント概要（発生日時、影響範囲、重大度）
- 発生原因（根本原因、直接原因）
- 対応経緯（タイムライン）
- 暫定対応内容
- 恒久対応内容
- 再発防止策
- 学んだ教訓

---

## キャパシティ・性能管理

### 基本方針

**参照先**
- システム方式設計「性能・拡張性設計」を参照
- 非機能要件「性能・拡張性」で定義した目標値を維持

**管理方針**
- リソース使用率を定期的に監視し、キャパシティ不足を予測
- トラフィック増加に対して事前にスケールアウト
- パフォーマンステストを定期実施し、劣化を早期検知
- キャパシティ計画を四半期ごとに見直し

### 予兆検知（潜在的ボトルネック）

**監視指標とアクション基準**
| 監視項目 | 警告閾値 | 対応アクション |
|---------|---------|--------------|
| CPU使用率 | 70%以上が1週間継続 | スケールアウト検討 |
| メモリ使用率 | 80%以上 | メモリリーク調査 / スケールアップ |
| ディスク使用率 | 70%以上 | 不要ファイル削除 / ストレージ拡張 |
| DB接続数 | 最大接続数の80%以上 | コネクションプール設定見直し |
| API応答時間 | 平均1.5秒以上 | スロークエリ調査 / キャッシュ導入 |
| ネットワーク帯域 | 80%以上 | CDN導入検討 / 帯域拡張 |

**予兆検知フロー**
```mermaid
graph TD
    A[リソース監視] --> B{閾値超過?}
    B -->|No| A
    B -->|Yes| C[警告通知 Slack]
    C --> D[トレンド分析 過去30日]
    D --> E{増加傾向?}
    E -->|Yes| F[キャパシティ拡張計画]
    E -->|No| G[一時的な高負荷 経過観察]
    F --> H[予算承認]
    H --> I[インフラ拡張実施]
```

**トレンド分析の観点**
- 過去30日間の平均値・最大値の推移
- 曜日・時間帯ごとのパターン
- イベント・キャンペーンとの相関
- 季節変動の考慮

### 定期負荷試験の方針

**実施頻度**
- 通常負荷試験: 四半期ごと（年4回）
- ピーク負荷試験: 半期ごと（年2回）
- リグレッション試験: リリース前（随時）

**負荷試験シナリオ**
| シナリオ | 目的 | 負荷条件 | 成功基準 |
|---------|------|---------|---------|
| 通常負荷 | 日常運用での性能確認 | 想定同時接続数の100% | 応答時間 < 1秒 |
| ピーク負荷 | 繁忙期の性能確認 | 想定同時接続数の150% | 応答時間 < 2秒 |
| 耐久試験 | 長時間運用での安定性確認 | 通常負荷を24時間継続 | メモリリークなし |
| スパイク試験 | 急激なトラフィック増加への対応 | 5分間で10倍の負荷 | エラー率 < 1% |

**負荷試験ツール**
- JMeter: APIエンドポイントの負荷試験
- Gatling: シ