---
name: analyzing-operation
description: 運用フロー、監視設計、バックアップ、障害対応、変更管理の運用要件を定義。「運用要件を定義したい」「監視設計をしたい」「障害対応手順を作りたい」「バックアップ方針を決めたい」「運用フローを整理したい」といった場面で発動する。運用要件を事前に設計することで、本番稼働後の「運用できない」問題を防ぐ。
---

# 運用要件定義

運用フロー、監視、バックアップ、障害対応、変更管理の運用要件を定義する。

運用はシステムのライフサイクルの中で最も長い期間を占める。開発時に運用を考慮しないと、リリース後に「監視がない」「復旧手順がない」「変更のたびにダウンタイムが発生する」といった問題が噴出する。運用設計は「作った後どう維持するか」を先に決める活動。

## 参照ドキュメントとテンプレート

| 種類 | パス | 備考 |
|------|------|------|
| ガイド | @docs/reference/運用要件定義ガイド.md | 運用要件定義の進め方詳細 |
| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
| 入力 | @docs/design/architecture_infrastructure.md | インフラストラクチャアーキテクチャ |
| 入力 | @docs/design/non_functional.md | 非機能要件定義 |
| 成果物 | `docs/design/operation.md` | 運用要件定義 |

## 運用フロー設計

定常運用を自動化前提で設計する。手動運用が多いほど人的ミスのリスクが上がる。

- **日次運用**: ログローテーション、バッチ処理、ヘルスチェックなど
- **月次運用**: セキュリティパッチ適用、容量管理、レポート生成など
- **年次運用**: ライセンス更新、DR テスト、監査対応など

## 監視設計

SLA/SLO を満たすために必要な監視を設計する。アラート疲れを防ぐため、本当に対応が必要なアラートのみを設定せよ。

- **監視項目の定義**: CPU、メモリ、ディスク、レスポンスタイム、エラー率など
- **アラート閾値の設定**: Warning/Critical の閾値を非機能要件の数値に基づいて設定する
- **エスカレーションフロー**: アラート重要度に応じた通知先と対応フローを定義する

## バックアップ設計

RPO（データ復旧時点）を満たすバックアップ方式を設計する。リストア手順のテストまでがバックアップ設計。

- **バックアップ方式**: フルバックアップ/差分バックアップ/増分バックアップの組み合わせを決定する
- **バックアップスケジュール**: RPO に基づいた頻度を設定する
- **リストア手順**: 復旧手順を文書化し、定期的にテストする

## 障害対応設計

RTO（障害復旧時間）を満たす復旧手順を設計する。障害時にゼロから考えるのは最悪のパターン。

- **障害検知方法**: 自動検知の仕組みとその精度を定義する
- **復旧手順**: 障害パターンごとの復旧手順を事前に文書化する
- **連絡体制**: オンコール体制とエスカレーションパスを定義する

## 変更管理設計

本番環境への変更を安全に行うための手順を設計する。ロールバック手順がないリリースは許可するな。

- **リリース手順**: デプロイの自動化手順を定義する
- **ロールバック手順**: 問題発生時の切り戻し手順を事前に準備する
- **変更承認フロー**: 変更の影響範囲に応じた承認プロセスを定義する

## 作成の進め方

1. 入力ドキュメント（非機能要件、インフラアーキテクチャ）を確認する
2. @docs/reference/運用要件定義ガイド.md を読み込む
3. 運用フロー→監視→バックアップ→障害対応→変更管理の順に設計する
4. `docs/design/operation.md` として出力する

## 途中から再開する場合

既存の `docs/design/operation.md` がある場合は、まずその内容を確認する。不足している運用領域や更新が必要な手順のみを修正する。

**Example:**

```
ユーザー: 「監視設計はできた。障害対応手順を作りたい」
回答: 既存の operation.md の監視設計を確認し、
      監視で検知されるアラートに対応する障害対応手順を設計する。
      障害パターンの分類→復旧手順→連絡体制の順で作成する。
```

## 注意事項

- 非機能要件とインフラアーキテクチャが完了していることが前提。未完了でも進めて構わない
- 運用手順は自動化を前提に設計する。IaC（Infrastructure as Code）を活用し、手動手順を最小化せよ
- リストア手順とロールバック手順は必ずテスト可能な形で文書化する
- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）

## 関連スキル

- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
- `analyzing-non-functional` — 前段の非機能要件定義（SLA/SLO が入力）
- `analyzing-architecture` — インフラアーキテクチャが運用設計の基盤
- `managing-operations` — 開発フェーズでの実際の環境構築・デプロイ