# 運用設計ガイド

このドキュメントは、運用設計を行う際の詳細なガイドラインとベストプラクティスをまとめています。

## 目次

1. [運用設計の基礎](#運用設計の基礎)
2. [ITIL 4フレームワーク](#itil-4フレームワーク)
3. [SRE（Site Reliability Engineering）](#sresite-reliability-engineering)
4. [DevOps実践](#devops実践)
5. [SLO/SLI/SLAの設計](#sloslisl aの設計)
6. [運用プロセスの設計](#運用プロセスの設計)
7. [ツール選定](#ツール選定)
8. [コスト最適化](#コスト最適化)

---

## 運用設計の基礎

### 運用設計とは

運用設計は、システムやサービスを安定的に運用するための計画と設計を行うプロセスです。以下の要素を含みます：

- **運用方針**: サービスの運用における基本的な考え方と優先順位
- **運用体制**: 運用を実施する組織構造と役割分担
- **運用プロセス**: 定常運用、インシデント対応、変更管理等のプロセス
- **運用ツール**: 監視、ログ管理、デプロイ等のツール選定
- **運用メトリクス**: 運用品質を測定・改善するための指標

### 運用設計の目的

1. **サービス品質の確保**
   - 可用性、パフォーマンス、セキュリティの維持
   - ユーザー体験の向上
   - ビジネス継続性の確保

2. **運用効率の向上**
   - 定常作業の標準化と自動化
   - インシデント対応時間の短縮
   - 属人化の排除

3. **コストの最適化**
   - インフラコストの管理
   - 運用人件費の効率化
   - 無駄な作業の削減

4. **継続的改善**
   - 運用メトリクスの可視化
   - ボトルネックの特定と解消
   - ベストプラクティスの導入

### 運用設計のアプローチ

#### トップダウンアプローチ

ビジネス要件から運用要件を導出する方法：

```
ビジネス目標
    ↓
サービスレベル要件（SLA）
    ↓
運用目標（SLO）
    ↓
運用設計（体制・プロセス・ツール）
```

**メリット**:
- ビジネス価値との整合性が高い
- 経営層の理解を得やすい
- 優先順位が明確

**デメリット**:
- 現場の実態と乖離する可能性
- 実現可能性の検証が必要

#### ボトムアップアプローチ

現場の運用実態から設計を構築する方法：

```
現在の運用実態
    ↓
課題の洗い出し
    ↓
改善施策の立案
    ↓
運用設計（最適化された体制・プロセス・ツール）
```

**メリット**:
- 実現可能性が高い
- 現場の納得感が得られやすい
- 即効性がある

**デメリット**:
- ビジネス視点が不足しがち
- 部分最適に陥りやすい

#### 推奨：ハイブリッドアプローチ

トップダウンとボトムアップを組み合わせる方法：

1. ビジネス要件からSLOを定義（トップダウン）
2. 現在の運用実態を分析（ボトムアップ）
3. ギャップを特定
4. 実現可能な運用設計を策定
5. 段階的に理想形に近づける

---

## ITIL 4フレームワーク

### ITIL 4とは

ITIL 4は、IT サービスマネジメント（ITSM）のベストプラクティス集です。ITIL v3から進化し、以下の特徴があります：

- **サービスバリューシステム（SVS）**: サービス価値の創造に焦点
- **4つの側面**: 組織と人、情報と技術、パートナーとサプライヤー、価値の流れとプロセス
- **34のプラクティス**: 運用に必要な実践項目
- **アジャイル・DevOpsとの統合**: モダンな開発手法に対応

### ITIL 4の主要プラクティス

運用設計で特に重要な14のプラクティス：

#### 一般管理プラクティス

1. **継続的改善**
   - 定期的な運用レビュー
   - メトリクスに基づく改善
   - PDCAサイクルの実践

2. **情報セキュリティ管理**
   - セキュリティポリシーの策定
   - アクセス制御
   - セキュリティインシデント対応

3. **リスク管理**
   - リスクの識別と評価
   - リスク軽減策の実施
   - 継続的なリスク監視

4. **ナレッジ管理**
   - ドキュメントの体系化
   - ナレッジベースの構築
   - 暗黙知の形式知化

#### サービス管理プラクティス

5. **可用性管理**
   - 可用性要件の定義
   - SPOF（単一障害点）の排除
   - 冗長化設計

6. **キャパシティとパフォーマンス管理**
   - キャパシティ計画
   - パフォーマンス監視
   - スケーリング戦略

7. **インシデント管理**
   - インシデントの検知と記録
   - 優先度付けとエスカレーション
   - 復旧と事後対応

8. **問題管理**
   - 根本原因分析
   - 既知のエラー管理
   - 恒久対策の実施

9. **変更管理**
   - 変更要求の評価
   - 変更の承認プロセス
   - 変更のテストと実装

10. **リリース管理**
    - リリース計画
    - 段階的なロールアウト
    - リリース後のレビュー

#### 技術管理プラクティス

11. **デプロイ管理**
    - デプロイメント戦略
    - 自動化されたデプロイ
    - ロールバック計画

12. **インフラストラクチャとプラットフォーム管理**
    - インフラの構成管理
    - プラットフォームの標準化
    - Infrastructure as Code

13. **監視とイベント管理**
    - 監視項目の定義
    - アラート設定
    - イベントの相関分析

14. **サービス構成管理**
    - 構成アイテム（CI）の管理
    - 構成管理データベース（CMDB）
    - 構成の変更追跡

### ITIL 4の運用設計への適用

運用設計書の各セクションとITIL 4プラクティスのマッピング：

| 運用設計書セクション | 対応するITIL 4プラクティス |
|----------------------|----------------------------|
| 運用方針と目標 | 継続的改善、可用性管理 |
| 運用体制 | 組織と人（4つの側面） |
| 監視・通知 | 監視とイベント管理 |
| インシデント管理 | インシデント管理、問題管理 |
| 変更管理 | 変更管理、変更イネーブルメント |
| リリース管理 | リリース管理、デプロイ管理 |
| バックアップ・リカバリ | サービス継続性管理 |
| セキュリティ運用 | 情報セキュリティ管理 |
| キャパシティ管理 | キャパシティとパフォーマンス管理 |
| ナレッジ管理 | ナレッジ管理 |

---

## SRE（Site Reliability Engineering）

### SREとは

SREは、Googleが提唱したソフトウェアエンジニアリングの原則を運用に適用するアプローチです。

**SREの核心原則**:

1. **サービスレベル目標（SLO）の設定**
   - ユーザー中心の信頼性目標
   - 測定可能で現実的な目標値
   - ビジネス価値との整合

2. **エラーバジェット**
   - 許容されるエラーの範囲
   - 開発速度と信頼性のバランス
   - データドリブンな意思決定

3. **トイル（Toil）の削減**
   - 手作業の自動化
   - 運用効率の向上
   - エンジニアリング時間の確保

4. **監視と可観測性**
   - ユーザー視点の監視
   - 4つのゴールデンシグナル
   - 効果的なアラート設計

5. **インシデント対応**
   - 構造化された対応プロセス
   - ポストモーテム文化
   - 学習と改善

### 4つのゴールデンシグナル

SREで推奨される監視の基本指標：

1. **レイテンシ（Latency）**
   - リクエストの処理時間
   - 成功リクエストと失敗リクエストを分けて測定
   - P50、P95、P99などのパーセンタイル値

2. **トラフィック（Traffic）**
   - システムへの需要
   - リクエスト数/秒、トランザクション数等
   - ビジネスメトリクスとの相関

3. **エラー（Errors）**
   - 失敗したリクエストの割合
   - 明示的エラー（500系）と暗黙的エラー（不正な応答）
   - エラー率の推移

4. **サチュレーション（Saturation）**
   - システムリソースの飽和度
   - CPU、メモリ、ディスク、ネットワークの使用率
   - キャパシティの余裕

### SLO設計のベストプラクティス

#### 1. ユーザー視点のSLI選定

**良いSLI**:
- ユーザー体験に直結する
- 測定可能
- コントロール可能

**SLIの例**:

| サービスタイプ | 推奨SLI | 目標値例 |
|----------------|---------|----------|
| Webアプリケーション | ページロード時間（P95） | 500ms以下 |
| API | レスポンスタイム（P99） | 200ms以下 |
| バッチ処理 | 処理完了率 | 99.9% |
| ストレージ | データ可用性 | 99.999999% |

#### 2. 適切なSLO値の設定

**SLO設定の原則**:

- **現状+α**: 現在の実績値より少し高い目標
- **ビジネス要件**: ビジネス上必要な最低ライン
- **業界標準**: 同業他社のベンチマーク
- **コスト**: 達成にかかるコスト

**SLOの段階的設定**:

```
フェーズ1（3ヶ月）: 現状の実績値を SLOとして設定
    ↓
フェーズ2（6ヶ月）: 現状+10%の改善目標
    ↓
フェーズ3（1年）: 業界標準レベル
    ↓
フェーズ4（2年）: 業界トップレベル
```

#### 3. エラーバジェットの運用

**エラーバジェット計算**:

```
SLO: 99.9%の可用性
= 0.1%のダウンタイムが許容される

月間（30日）のエラーバジェット:
30日 × 24時間 × 60分 × 0.1% = 43.2分
```

**エラーバジェットポリシー**:

| エラーバジェット残量 | 対応方針 |
|----------------------|----------|
| 75%以上 | 新機能開発を優先 |
| 50-75% | バランスを保つ |
| 25-50% | 信頼性向上を優先 |
| 25%未満 | 新機能開発を停止し、信頼性改善に集中 |

### トイル削減の実践

**トイルの定義**:
- 手作業
- 繰り返し発生
- 自動化可能
- 戦術的（長期的価値なし）
- O(n)でスケール（線形増加）

**トイル削減の優先順位**:

1. **頻度 × 時間が大きい作業**
   - 毎日10分の作業 → 月間300分
   - 週1回60分の作業 → 月間240分
   - 前者を優先

2. **エラーが発生しやすい作業**
   - 手作業によるミスリスク
   - 影響範囲が大きい作業
   - 自動化で品質向上

3. **複雑な作業**
   - 属人化リスク
   - ドキュメント維持コスト
   - 自動化で標準化

**自動化の ROI計算**:

```
年間削減時間 = 作業頻度（回/年） × 作業時間（分）
自動化コスト = 開発時間（時間） × 時給（円）
年間削減コスト = 年間削減時間（分） ÷ 60 × 時給（円）

ROI = （年間削減コスト - 自動化コスト） ÷ 自動化コスト × 100%
```

**例**:
```
作業: 毎日実施するログチェック（30分）
年間削減時間: 365 × 30分 = 10,950分 = 182.5時間
自動化コスト: 40時間 × 5,000円 = 200,000円
年間削減コスト: 182.5時間 × 5,000円 = 912,500円

ROI = (912,500 - 200,000) ÷ 200,000 × 100% = 356%
```

---

## DevOps実践

### DevOpsとは

DevOpsは、開発（Development）と運用（Operations）の壁を取り払い、協働によってサービスの価値提供を加速するアプローチです。

**DevOpsの核心原則**:

1. **文化（Culture）**
   - 共同責任
   - 信頼とコラボレーション
   - 失敗から学ぶ文化

2. **自動化（Automation）**
   - CI/CDパイプライン
   - インフラのコード化
   - テストの自動化

3. **測定（Measurement）**
   - メトリクスの可視化
   - データドリブンな意思決定
   - 継続的フィードバック

4. **共有（Sharing）**
   - ナレッジの共有
   - ツールの共有
   - 責任の共有

### DevOpsのキーメトリクス

#### Four Keys（Google DORA）

ソフトウェアデリバリーのパフォーマンスを測る4つの指標：

1. **デプロイ頻度（Deployment Frequency）**
   - コードが本番環境にデプロイされる頻度
   - エリート: 1日複数回
   - ハイ: 週1回〜月1回
   - ミディアム: 月1回〜6ヶ月に1回
   - ロー: 6ヶ月に1回未満

2. **変更のリードタイム（Lead Time for Changes）**
   - コミットから本番デプロイまでの時間
   - エリート: 1日未満
   - ハイ: 1週間〜1ヶ月
   - ミディアム: 1ヶ月〜6ヶ月
   - ロー: 6ヶ月以上

3. **変更失敗率（Change Failure Rate）**
   - デプロイ後にロールバックや修正が必要になる割合
   - エリート: 0-15%
   - ハイ: 16-30%
   - ミディアム/ロー: 31-45%以上

4. **サービス復旧時間（Time to Restore Service）**
   - インシデント発生から復旧までの時間
   - エリート: 1時間未満
   - ハイ: 1日未満
   - ミディアム: 1週間未満
   - ロー: 1週間以上

### CI/CDパイプライン設計

#### 継続的インテグレーション（CI）

**CI の基本フロー**:

```
コミット
    ↓
自動ビルド
    ↓
ユニットテスト
    ↓
静的解析
    ↓
統合テスト
    ↓
アーティファクト作成
```

**CIのベストプラクティス**:

1. **高速なフィードバック**
   - CI実行時間: 10分以内を目標
   - 並列実行の活用
   - テストの最適化

2. **すべてのコミットでCI実行**
   - mainブランチだけでなくfeatureブランチも
   - プルリクエスト時の自動テスト
   - マージ前の品質保証

3. **失敗時の即時対応**
   - ビルド失敗の通知
   - 失敗の修正を最優先
   - グリーンビルドの維持

#### 継続的デプロイ（CD）

**CDの基本フロー**:

```
アーティファクト
    ↓
開発環境デプロイ
    ↓
自動テスト
    ↓
ステージング環境デプロイ
    ↓
受入テスト
    ↓
本番環境デプロイ（カナリア）
    ↓
モニタリング
    ↓
全体展開 or ロールバック
```

**デプロイ戦略の比較**:

| 戦略 | メリット | デメリット | 推奨ケース |
|------|----------|------------|------------|
| **Blue-Green** | ダウンタイムゼロ、即座にロールバック可能 | リソース2倍必要 | データベース変更が少ない場合 |
| **Rolling** | リソース効率的、段階的な展開 | ロールバックが複雑 | ステートレスなアプリケーション |
| **Canary** | リスク最小化、早期の問題検出 | 複雑な制御が必要 | ユーザー影響が大きいサービス |
| **Feature Toggle** | 柔軟なリリース制御 | コードが複雑化 | A/Bテストが必要な場合 |

### Infrastructure as Code（IaC）

**IaCのメリット**:
- バージョン管理
- 再現可能性
- ドキュメントとしての役割
- レビュープロセスの適用

**主要なIaCツール**:

| ツール | 用途 | 特徴 |
|--------|------|------|
| Terraform | インフラプロビジョニング | マルチクラウド対応、宣言的 |
| CloudFormation | AWS専用プロビジョニング | AWS完全統合 |
| Ansible | 構成管理、デプロイ | エージェントレス、手続き的 |
| Kubernetes | コンテナオーケストレーション | スケーラブル、クラウドネイティブ |

**IaCのベストプラクティス**:

1. **環境ごとの設定分離**
   ```
   environments/
   ├── dev/
   ├── staging/
   └── production/
   ```

2. **モジュール化と再利用**
   ```
   modules/
   ├── vpc/
   ├── database/
   └── application/
   ```

3. **状態管理**
   - リモートステートの使用
   - ステートのロック機構
   - バックアップ戦略

4. **CI/CDとの統合**
   - プルリクエストでのplan実行
   - マージ後のapply実行
   - 変更の自動テスト

---

## SLO/SLI/SLAの設計

### SLO/SLI/SLAの関係

```
SLA（Service Level Agreement）: 顧客との合意
    ↓ より厳しい目標
SLO（Service Level Objective）: 内部目標
    ↓ 測定
SLI（Service Level Indicator）: 実際の測定値
```

**例**:
- **SLA**: 可用性99.9%を保証（違反時は返金）
- **SLO**: 可用性99.95%を目標（SLAより余裕を持たせる）
- **SLI**: 実測値99.97%（現在の達成状況）

### SLI設計の詳細

#### SLIの種類

1. **可用性ベースのSLI**
   ```
   SLI = 成功したリクエスト数 / 全リクエスト数
   ```

   **測定方法**:
   - ロードバランサーのログから集計
   - ステータスコード200番台を成功とする
   - タイムアウトは失敗とする

2. **レイテンシベースのSLI**
   ```
   SLI = 閾値以下のレスポンスタイムのリクエスト割合
   ```

   **測定方法**:
   - P95、P99のパーセンタイル値
   - 500ms以下のリクエストが95%以上等

3. **正確性ベースのSLI**
   ```
   SLI = 正しい結果を返したリクエスト数 / 全リクエスト数
   ```

   **測定方法**:
   - レスポンスの検証
   - データの整合性チェック

4. **スループットベースのSLI**
   ```
   SLI = 実際のスループット / 期待されるスループット
   ```

   **測定方法**:
   - リクエスト数/秒
   - トランザクション数/分

#### SLI測定のベストプラクティス

1. **ユーザー視点で測定**
   - サーバーサイドだけでなく、クライアントサイドも測定
   - Real User Monitoring (RUM) の活用

2. **複数の測定ポイント**
   - エンドツーエンドの測定
   - 各コンポーネントでの測定
   - 外形監視と内部監視の組み合わせ

3. **異常値の扱い**
   - パーセンタイル値の使用（平均値は避ける）
   - 外れ値の除外ルール
   - サンプリング方法の明確化

### SLO設計の詳細

#### SLO設定の手順

1. **ユーザー体験の理解**
   ```
   質問: ユーザーはどの程度の遅延まで許容できるか？
   調査: ユーザーアンケート、離脱率分析
   結果: 500ms以下が理想、1秒以下なら許容範囲
   ```

2. **現状の測定**
   ```
   過去3ヶ月の実績:
   - P50: 200ms
   - P95: 450ms
   - P99: 800ms
   - 可用性: 99.87%
   ```

3. **目標値の設定**
   ```
   SLO提案:
   - レスポンスタイム（P95）: 500ms以下
   - 可用性: 99.9%
   - エラーレート: 0.1%以下
   ```

4. **実現可能性の検証**
   ```
   必要な施策:
   - データベースクエリの最適化
   - CDNの導入
   - 冗長化構成の強化
   → 実現可能と判断
   ```

5. **合意とコミット**
   ```
   ステークホルダーとの合意:
   - 開発チーム: SLO達成に必要なリソース確保
   - 運用チーム: 監視体制の整備
   - ビジネス: SLO未達時の対応方針
   ```

#### SLOウィンドウ

SLOを評価する期間の設定：

**短期ウィンドウ（例: 1日）**:
- メリット: 素早いフィードバック
- デメリット: ノイズが多い
- 用途: 日次の運用判断

**中期ウィンドウ（例: 28日ローリング）**:
- メリット: 安定した指標
- デメリット: 遅いフィードバック
- 用途: SLO達成状況の評価

**長期ウィンドウ（例: 四半期）**:
- メリット: トレンド把握
- デメリット: リアルタイム性なし
- 用途: 戦略的な改善計画

**推奨: 複数ウィンドウの併用**:
```
- 24時間ウィンドウ: アラート用
- 28日ローリングウィンドウ: SLO評価用
- 四半期ウィンドウ: 年間計画用
```

### SLA設計の詳細

#### SLAの構成要素

1. **サービス範囲**
   - 対象となるサービス・機能
   - 除外事項
   - メンテナンスウィンドウ

2. **サービスレベル**
   - 可用性保証
   - パフォーマンス保証
   - サポート対応時間

3. **測定方法**
   - 測定ツール
   - 測定頻度
   - レポート方法

4. **責任と義務**
   - サービス提供者の責任
   - 顧客の責任
   - 免責事項

5. **違反時の対応**
   - サービスクレジット
   - 返金ポリシー
   - エスカレーション

#### SLA値の設定戦略

**保守的なアプローチ**:
```
SLO: 99.95%
SLA: 99.9%（SLOより低く設定）

メリット: SLA違反リスク低減
デメリット: 競争力に欠ける可能性
```

**積極的なアプローチ**:
```
SLO: 99.95%
SLA: 99.95%（SLOと同じ）

メリット: 競争力が高い
デメリット: SLA違反リスクが高い
```

**推奨: バッファーを持たせる**:
```
SLO: 99.95%
SLA: 99.9%
バッファー: 0.05%

計算:
月間ダウンタイム許容（SLO）: 21.6分
月間ダウンタイム許容（SLA）: 43.2分
安全マージン: 21.6分
```

---

## 運用プロセスの設計

### インシデント管理プロセス

#### インシデントライフサイクル

```
検知 → トリアージ → 調査 → 復旧 → クローズ → ポストモーテム
```

**各フェーズの詳細**:

1. **検知（Detection）**
   - 監視アラート
   - ユーザー報告
   - 内部発見

   **目標**: 平均検知時間（MTTD）の最小化

2. **トリアージ（Triage）**
   - 影響範囲の評価
   - 優先度の判定
   - 担当者のアサイン

   **目標**: 5分以内に優先度判定

3. **調査（Investigation）**
   - 原因の特定
   - 影響範囲の詳細把握
   - 復旧策の検討

   **目標**: P1は15分以内に原因特定開始

4. **復旧（Remediation）**
   - 応急措置の実施
   - サービスの復旧
   - 動作確認

   **目標**: MTTR（平均復旧時間）の目標達成

5. **クローズ（Close）**
   - インシデントチケットのクローズ
   - ドキュメント更新
   - ステークホルダーへの報告

6. **ポストモーテム（Postmortem）**
   - 根本原因分析
   - タイムライン作成
   - 再発防止策の策定

   **目標**: P1/P2は48時間以内に完了

#### インシデント対応のベストプラクティス

1. **明確な役割分担**

   **インシデントコマンダー（IC）**:
   - インシデント対応の統括
   - 意思決定
   - コミュニケーションの調整

   **コミュニケーションリード**:
   - ステークホルダーへの情報共有
   - ステータス更新
   - 社内外への通知

   **テクニカルリード**:
   - 技術的な調査
   - 復旧作業の実施
   - 技術的判断

2. **効果的なコミュニケーション**

   **専用チャンネル**:
   - インシデントごとに専用Slack/Teamsチャンネル
   - 関係者の集約
   - ログの自動記録

   **定期的なステータス更新**:
   - P1: 15分ごと
   - P2: 30分ごと
   - P3: 1時間ごと

   **ステータス更新のテンプレート**:
   ```
   【ステータス更新 - HH:MM】
   - 現在の状況: [状況説明]
   - 影響範囲: [影響内容]
   - 次のアクション: [実施予定の作業]
   - 次回更新予定: [時刻]
   ```

3. **ドキュメント化**

   **リアルタイム記録**:
   - すべてのアクションをタイムスタンプ付きで記録
   - 決定事項と根拠を記録
   - 試行錯誤も含めて記録

   **ポストモーテムテンプレート**:
   ```markdown
   # インシデントポストモーテム

   ## 概要
   - 発生日時:
   - 検知日時:
   - 復旧日時:
   - 影響範囲:
   - 優先度:

   ## タイムライン
   | 時刻 | イベント | 担当者 |
   |------|----------|--------|
   | | | |

   ## 根本原因
   [5 Whys分析等]

   ## 影響
   - ユーザー影響:
   - ビジネス影響:
   - SLO影響:

   ## 対応の良かった点
   -

   ## 対応の改善点
   -

   ## アクションアイテム
   | アクション | 担当者 | 期限 | ステータス |
   |------------|--------|------|------------|
   | | | | |

   ## 学び
   -
   ```

### 変更管理プロセス

#### 変更諮問委員会（CAB）

**CABの役割**:
- 重要な変更のレビュー
- リスク評価
- 変更承認/却下の判断
- 優先順位付け

**CAB会議の頻度**:
- 定期CAB: 週次
- 緊急CAB: 必要に応じて

**CABメンバー**:
- 変更マネージャー（議長）
- 運用マネージャー
- 開発マネージャー
- セキュリティ担当
- ビジネス代表

#### 変更リスク評価

**リスク評価マトリクス**:

| 影響度 / 確率 | 低 | 中 | 高 |
|---------------|-----|-----|-----|
| **高** | 中リスク | 高リスク | 高リスク |
| **中** | 低リスク | 中リスク | 高リスク |
| **低** | 低リスク | 低リスク | 中リスク |

**影響度の評価基準**:
- 高: 全ユーザー・主要機能に影響
- 中: 一部ユーザー・一部機能に影響
- 低: 限定的な影響

**確率の評価基準**:
- 高: 過去に類似の問題発生、複雑な変更
- 中: 標準的な変更、テスト済み
- 低: 実績のある変更、単純な変更

#### 変更の自動化

**標準変更の自動化**:
```
条件:
- 事前承認済みの変更
- 十分にテスト済み
- 低リスク
- 高頻度で実施

例:
- セキュリティパッチ適用
- スケールアウト/イン
- 設定変更（ホワイトリスト追加等）
```

**自動承認のフロー**:
```
変更要求
    ↓
条件チェック（自動）
    ↓
標準変更に該当
    ↓
自動承認
    ↓
自動実行（CI/CD）
    ↓
結果通知
```

### リリース管理プロセス

#### リリース計画

**リリーストレイン方式**:
```
定期リリース: 毎週金曜日15:00

Week 1: 機能A, B をリリース
Week 2: 機能C をリリース
Week 3: 機能D, E をリリース
Week 4: バグフィックスのみ

ルール:
- 水曜日12:00が締切
- テスト完了していない機能は次回へ
- 緊急度の高いバグは随時ホットフィックス
```

**メリット**:
- 予測可能なリリースサイクル
- リリース作業の標準化
- リソース計画が容易

**デメリット**:
- 柔軟性の制約
- 待ち時間の発生

#### リリース判定

**Go/No-Go判定基準**:

**Go条件（すべて満たす必要あり）**:
- [ ] すべてのテストが合格
- [ ] パフォーマンステストが合格
- [ ] セキュリティレビューが完了
- [ ] ドキュメントが更新済み
- [ ] ロールバック手順が準備済み
- [ ] ステークホルダーの承認取得
- [ ] 現在のエラーバジェット残量 > 20%

**No-Go条件（1つでも該当すればリリース延期）**:
- 重大なバグが未解決
- パフォーマンス劣化が検出
- セキュリティ脆弱性が発見
- 本番環境で問題発生中
- エラーバジェット残量 < 20%

#### リリース後の監視

**監視強化期間**:
```
リリース直後: 1時間
- 5分間隔で主要メトリクス確認
- エラーログの監視
- ユーザーフィードバックの収集

リリース後1-24時間:
- 30分間隔でメトリクス確認
- SLI/SLOの監視
- 異常検知時は即ロールバック

リリース後24-72時間:
- 通常の監視体制
- トレンド分析
- ユーザー満足度調査
```

**ロールバック判断**:

自動ロールバック条件:
- エラーレート > 5%
- レスポンスタイム > SLO閾値の2倍
- 可用性 < 99%

手動ロールバック判断:
- 予期しない副作用の発見
- ユーザーからの問い合わせ急増
- ビジネスメトリクスの異常

---

## ツール選定

### 監視ツールの選定

#### 監視ツールの種類

1. **インフラ監視**
   - Prometheus + Grafana
   - Datadog
   - New Relic
   - CloudWatch（AWS）

2. **APM（Application Performance Monitoring）**
   - New Relic APM
   - Datadog APM
   - AppDynamics
   - Dynatrace

3. **ログ管理**
   - ELK Stack（Elasticsearch, Logstash, Kibana）
   - Splunk
   - Datadog Logs
   - CloudWatch Logs

4. **外形監視**
   - Pingdom
   - UptimeRobot
   - Datadog Synthetics

#### 選定基準

**機能要件**:
- [ ] 必要なメトリクスを収集できるか
- [ ] リアルタイム監視が可能か
- [ ] アラート機能が充実しているか
- [ ] ダッシュボードのカスタマイズ性
- [ ] APIによる自動化が可能か

**非機能要件**:
- [ ] スケーラビリティ
- [ ] 可用性（ツール自体の信頼性）
- [ ] セキュリティ
- [ ] パフォーマンス（オーバーヘッド）

**運用要件**:
- [ ] セットアップの容易さ
- [ ] 学習コスト
- [ ] サポート体制
- [ ] コミュニティの活発さ

**コスト**:
- [ ] 初期費用
- [ ] ランニングコスト
- [ ] データ量による従量課金
- [ ] ユーザー数による課金

#### ツール比較マトリクス例

| ツール | メトリクス収集 | ログ管理 | APM | 外形監視 | 月額コスト（概算） | 総合評価 |
|--------|----------------|----------|-----|----------|-------------------|----------|
| Datadog | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | $$$$ | ⭐⭐⭐⭐⭐ |
| Prometheus + Grafana | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | $ | ⭐⭐⭐⭐ |
| New Relic | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | $$$ | ⭐⭐⭐⭐ |
| CloudWatch | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | $$ | ⭐⭐⭐ |

### CI/CDツールの選定

#### 主要CI/CDツール

1. **GitHub Actions**
   - メリット: GitHubとの統合、無料枠が大きい
   - デメリット: GitHub依存
   - 推奨: GitHubを使用しているプロジェクト

2. **GitLab CI/CD**
   - メリット: 統合環境、セルフホスト可能
   - デメリット: 学習コスト
   - 推奨: GitLabを使用しているプロジェクト

3. **Jenkins**
   - メリット: 柔軟性、プラグイン豊富
   - デメリット: 保守コスト高
   - 推奨: 複雑なワークフローが必要な場合

4. **CircleCI**
   - メリット: 高速、使いやすい
   - デメリット: コストが高め
   - 推奨: パフォーマンス重視の場合

#### 選定のポイント

**既存ツールとの統合**:
- ソースコード管理ツール（GitHub, GitLab等）
- コンテナレジストリ
- デプロイ先（AWS, GCP, Azure等）

**パイプラインの要件**:
- 並列実行の必要性
- ワークフローの複雑さ
- セルフホストの要否

**コスト**:
- ビルド時間による課金
- 同時実行数による課金
- セルフホストの運用コスト

### インシデント管理ツールの選定

#### 主要ツール

1. **PagerDuty**
   - オンコール管理
   - インシデントレスポンス
   - ステータスページ

2. **Opsgenie**
   - アラート管理
   - オンコールスケジューリング
   - Atlassian製品との統合

3. **Jira Service Management**
   - チケット管理
   - SLA管理
   - ナレッジベース

4. **ServiceNow**
   - エンタープライズITSM
   - 豊富な機能
   - 高コスト

#### 選定基準

**アラート管理**:
- 複数ソースからのアラート集約
- 重複排除
- 優先度付け

**オンコール管理**:
- ローテーション設定
- エスカレーション
- シフト管理

**コラボレーション**:
- チャットツール統合
- リアルタイムコラボレーション
- ポストモーテム機能

---

## コスト最適化

### クラウドコスト最適化

#### 1. 適切なサイジング

**現状分析**:
```
調査期間: 過去30日
メトリクス: CPU使用率、メモリ使用率

結果:
- EC2 i-xxxxx: CPU平均15%, メモリ平均20%
  → 過剰スペック
- EC2 i-yyyyy: CPU平均85%, メモリ平均90%
  → スペック不足

推奨:
- i-xxxxx: t3.largeからt3.mediumへダウンサイジング
  → 月額コスト $80削減
- i-yyyyy: t3.mediumからt3.largeへアップサイジング
  → パフォーマンス改善
```

**定期的なレビュー**:
- 頻度: 月次
- 対象: すべてのリソース
- アクション: サイジングの見直し

#### 2. リザーブドインスタンス/Savings Plans

**購入戦略**:

| ベースライン | 変動部分 | 購入方法 |
|--------------|----------|----------|
| 常時稼働するインスタンス | ピーク時の追加インスタンス | リザーブドインスタンス（1年または3年） |
| 予測可能な使用量 | 予測不可能な使用量 | オンデマンド |

**ROI計算**:
```
オンデマンド価格: $100/月
リザーブド価格（1年、前払いなし）: $65/月

年間削減額: ($100 - $65) × 12 = $420
削減率: 35%

3年前払いの場合:
初期投資: $1,800
年間削減額: ($100 - $50) × 12 = $600
ROI: 33% per year
```

#### 3. スポットインスタンス

**適用シナリオ**:
- バッチ処理
- データ分析
- CI/CDビルド
- ステートレスなワーカー

**スポットインスタンス戦略**:
```
構成: オンデマンド + スポット

オンデマンド: 最小限の台数（ベースライン）
スポット: 追加の処理能力

中断対策:
- スポットインスタンス中断通知の監視
- 別のインスタンスタイプへの自動フェールオーバー
- ジョブの再実行メカニズム
```

#### 4. 不要なリソースの削除

**定期チェックリスト**:

**週次**:
- [ ] 未使用のEBS ボリューム
- [ ] 未アタッチのEIP
- [ ] 古いスナップショット（> 30日）

**月次**:
- [ ] 未使用のロードバランサー
- [ ] 未使用のNATゲートウェイ
- [ ] 開発環境の夜間・週末シャットダウン

**四半期**:
- [ ] 未使用のVPC
- [ ] 古いAMI
- [ ] 重複データの削除

**自動化スクリプト例**:
```python
# 未使用のEBSボリューム検出
import boto3

ec2 = boto3.client('ec2')
volumes = ec2.describe_volumes()

unused_volumes = [
    v for v in volumes['Volumes']
    if v['State'] == 'available'
]

for volume in unused_volumes:
    print(f"Unused volume: {volume['VolumeId']}")
    # アラート送信またはタグ付け
```

#### 5. データ転送コストの最適化

**戦略**:

1. **CDNの活用**
   - CloudFrontの利用
   - 静的コンテンツのキャッシュ
   - リージョン間転送の削減

2. **データ圧縮**
   - gzip/brotli圧縮の有効化
   - 画像の最適化
   - APIレスポンスの圧縮

3. **リージョン戦略**
   - ユーザーに近いリージョンの選択
   - マルチリージョン展開の最適化
   - データローカライゼーション

**削減例**:
```
Before:
- オリジンからの配信: 1TB/月 × $0.09 = $90
- リージョン間転送: 500GB/月 × $0.02 = $10
  合計: $100/月

After（CDN導入）:
- CloudFrontからの配信: 1TB/月 × $0.085 = $85
- オリジン→CloudFront: 100GB/月 × $0.00 = $0
  合計: $85/月

削減額: $15/月（15%削減）
```

### 運用コスト最適化

#### 1. 自動化による人件費削減

**自動化のROI**:

```
手作業: デプロイ作業
- 頻度: 週1回
- 所要時間: 2時間
- 時給: $50
- 年間コスト: 52週 × 2時間 × $50 = $5,200

自動化:
- 開発コスト: 40時間 × $80 = $3,200
- 年間運用コスト: $500

ROI（1年目）:
節約: $5,200 - $3,200 - $500 = $1,500
ROI: ($1,500 / $3,700) × 100% = 40%

ROI（2年目以降）:
節約: $5,200 - $500 = $4,700
ROI: 940%
```

**自動化優先度**:

| タスク | 頻度 | 時間 | 年間コスト | 自動化コスト | ROI | 優先度 |
|--------|------|------|------------|--------------|-----|--------|
| デプロイ | 週1回 | 2時間 | $5,200 | $3,200 | 40% | 高 |
| バックアップ確認 | 日次 | 15分 | $3,250 | $1,600 | 100% | 高 |
| レポート作成 | 月次 | 4時間 | $2,400 | $4,000 | -40% | 低 |

#### 2. オンコール体制の最適化

**現状の課題**:
```
現在のオンコール: 24/365体制、5名ローテーション

課題:
- オンコール手当: $200/週/人 × 52週 = $10,400/人/年
- 総コスト: $10,400 × 5人 = $52,000/年
- バーンアウトリスク
- 誤報によるアラート疲れ
```

**最適化施策**:

1. **アラートの精度向上**
   ```
   現状: 月間アラート100件、誤報率60%
   → 実際の問題: 40件

   改善策:
   - アラート閾値の見直し
   - 重複アラートの集約
   - ノイズの除去

   結果: 月間アラート50件、誤報率20%
   → 実際の問題: 40件
   → アラート対応時間50%削減
   ```

2. **営業時間外の対応範囲の見直し**
   ```
   分析結果:
   - P1インシデント: 月2件（即時対応必要）
   - P2インシデント: 月8件（翌営業日対応可能）
   - P3/P4: 月30件（計画的対応可能）

   新方針:
   - 営業時間外: P1のみオンコール対応
   - P2: 翌営業日朝一番で対応
   - P3/P4: 計画的に対応

   効果:
   - オンコール対応件数80%削減
   - オンコール人数を3名に削減
   - コスト削減: $52,000 → $31,200（40%削減）
   ```

#### 3. ツールコストの最適化

**ツール統合**:

```
Before:
- 監視ツールA: $500/月
- ログ管理ツールB: $300/月
- APMツールC: $400/月
  合計: $1,200/月

After:
- 統合プラットフォームD: $800/月
  （監視 + ログ + APM）

削減: $400/月（33%削減）
```

**ライセンス最適化**:

```
現状:
- 有償ツールX: 100ライセンス × $50 = $5,000/月
- 実際の利用者: 60人

最適化:
- 有償ライセンス: 65個（余裕を持たせて）
- 残り: 閲覧のみライセンス（無料）

削減: 35ライセンス × $50 = $1,750/月
```

### コスト可視化

#### コスト配分タグ

**タグ戦略**:

| タグ名 | 値の例 | 用途 |
|--------|--------|------|
| Environment | production, staging, development | 環境別コスト |
| Service | web, api, database | サービス別コスト |
| Team | platform, product, data | チーム別コスト |
| CostCenter | engineering, marketing | コストセンター別 |

**例**:
```
Resource: EC2 Instance
Tags:
  - Environment: production
  - Service: web
  - Team: product
  - CostCenter: engineering

→ プロダクトチームのWebサービス本番環境コストとして計上
```

#### コストダッシュボード

**主要メトリクス**:

1. **総コストトレンド**
   - 月次推移
   - 前月比
   - 予算との対比

2. **サービス別コスト**
   - コンピュート
   - ストレージ
   - ネットワーク
   - その他

3. **環境別コスト**
   - 本番環境
   - ステージング
   - 開発環境

4. **最大コスト要因**
   - トップ10リソース
   - トップ10サービス

**アラート設定**:
```
予算: $10,000/月

アラート閾値:
- 80%（$8,000）: Warning
- 90%（$9,000）: Critical
- 100%（$10,000）: Emergency

アクション:
- Warning: 運用チームに通知
- Critical: マネージャーに通知、レビュー実施
- Emergency: 新規リソース作成を一時停止
```

---

このガイドは運用設計の実践的な指針を提供しています。プロジェクトの特性に応じて、適切な部分を選択して活用してください。