commit ebf56024ddb3d6ee06eecb1edc50277abb2152bb Author: Zhongwei Li Date: Sun Nov 30 09:06:28 2025 +0800 Initial commit diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json new file mode 100644 index 0000000..3cee5a9 --- /dev/null +++ b/.claude-plugin/plugin.json @@ -0,0 +1,12 @@ +{ + "name": "operations-design", + "description": "運用設計コンサルタントとして、対象業界の最新トレンドを調査し、サービス仕様をヒアリングした上で、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた運用設計書を作成します。推論を避け、不明点は必ず質問し、一貫性を保つよう客観的にレビューします。", + "version": "0.0.0-2025.11.28", + "author": { + "name": "Winds Chord", + "email": "zhongweili@tubi.tv" + }, + "skills": [ + "./skills/operations-design" + ] +} \ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 0000000..a444852 --- /dev/null +++ b/README.md @@ -0,0 +1,3 @@ +# operations-design + +運用設計コンサルタントとして、対象業界の最新トレンドを調査し、サービス仕様をヒアリングした上で、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた運用設計書を作成します。推論を避け、不明点は必ず質問し、一貫性を保つよう客観的にレビューします。 diff --git a/plugin.lock.json b/plugin.lock.json new file mode 100644 index 0000000..27ecfb5 --- /dev/null +++ b/plugin.lock.json @@ -0,0 +1,84 @@ +{ + "$schema": "internal://schemas/plugin.lock.v1.json", + "pluginId": "gh:windschord/claude_skils:operations-design", + "normalized": { + "repo": null, + "ref": "refs/tags/v20251128.0", + "commit": "08c699cdefe4511083e2723993e606a8c264fe70", + "treeHash": "1e68d87ac26da79ed31174aa4bb72860f3529c9e4af06fd97f9b386381ef7397", + "generatedAt": "2025-11-28T10:29:03.373792Z", + "toolVersion": "publish_plugins.py@0.2.0" + }, + "origin": { + "remote": "git@github.com:zhongweili/42plugin-data.git", + "branch": "master", + "commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390", + "repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data" + }, + "manifest": { + "name": "operations-design", + "description": "運用設計コンサルタントとして、対象業界の最新トレンドを調査し、サービス仕様をヒアリングした上で、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた運用設計書を作成します。推論を避け、不明点は必ず質問し、一貫性を保つよう客観的にレビューします。" + }, + "content": { + "files": [ + { + "path": "README.md", + "sha256": "a3469741193a3886594cf5b4c8c50b3bf11bab500f19a19cae1e8ce163046443" + }, + { + "path": ".claude-plugin/plugin.json", + "sha256": "447537608c48f2774ba1c62adb3ca90b8caa3ba351373c99bba4b99eeca8cfaf" + }, + { + "path": "skills/operations-design/README.md", + "sha256": "0153996e2d7c903c0914ff9c3675c42b7b08f5a1e0319075ae51d8ef54a4aafc" + }, + { + "path": "skills/operations-design/SKILL.md", + "sha256": "8978c1c9397b8eab86c3ec0fcef6a8c16d40f193cfa79ac36c61a2d55c51b059" + }, + { + "path": "skills/operations-design/hearing_items/2-9_security_compliance.md", + "sha256": "ee5ba62d21249108a2e90e48491ca3e65de359766f2e1842d668ef6a07edc689" + }, + { + "path": "skills/operations-design/references/industry_research_guide_ja.md", + "sha256": "2226b55d2baefe273134e193cfba967243cb93a3919499ee4c9db11c5a9ec69e" + }, + { + "path": "skills/operations-design/references/operations_design_guide_ja.md", + "sha256": "34a28be441db824f7a10c2e224d405c2bf12995b0e434632b4ec650f7a9a6d38" + }, + { + "path": "skills/operations-design/guides/conversation_logging.md", + "sha256": "5677fc44849ca24c23db01e1a832b8b8e118ce085b9e17cf10473a6c78a454ff" + }, + { + "path": "skills/operations-design/assets/templates/operations_design_template_cloud_instance_ja.md", + "sha256": "00c12dc6c7cb3720c1c641cc93fb30660504f79b12396b6e1bcbde25e47a974b" + }, + { + "path": "skills/operations-design/assets/templates/conversation_log_template_ja.md", + "sha256": "570ff222171d769901158461b4c392509ff863e5f40d4d48cdcedcf6fc2caea5" + }, + { + "path": "skills/operations-design/assets/templates/operations_design_template_cloud_native_ja.md", + "sha256": "4be6a5bb72d482b6f03faecbf955060526883de80f0ce453ea2145cdcbd0931c" + }, + { + "path": "skills/operations-design/assets/templates/operations_design_template_ja.md", + "sha256": "673738b091b0745463163c8fa36de4d472eff167efddfcede8f885f0f9a707db" + }, + { + "path": "skills/operations-design/assets/templates/operations_design_template_onpremise_ja.md", + "sha256": "1a027a2618c213c1a8fbe9cb8616a0f2b4bfc227cb76e59dd6ae48147cb11e57" + } + ], + "dirSha256": "1e68d87ac26da79ed31174aa4bb72860f3529c9e4af06fd97f9b386381ef7397" + }, + "security": { + "scannedAt": null, + "scannerVersion": null, + "flags": [] + } +} \ No newline at end of file diff --git a/skills/operations-design/README.md b/skills/operations-design/README.md new file mode 100644 index 0000000..35b7569 --- /dev/null +++ b/skills/operations-design/README.md @@ -0,0 +1,282 @@ +# 運用設計コンサルタントスキル + +運用設計の専門コンサルタントとして、対象業界の最新トレンドを調査し、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた実践的な運用設計書を作成するスキルです。 + +## 概要 + +このスキルは以下の機能を提供します： + +- 対象業界の最新トレンドと技術動向の調査 +- サービス仕様の体系的なヒアリング +- ITIL 4・SRE・DevOpsに基づいた運用設計 +- 包括的な運用設計書の作成 +- 設計内容の一貫性チェックと客観的レビュー +- 推論を避けた事実ベースの設計 + +## 主な特徴 + +### 1. AskUserQuestionツールによる確実な質問 + +**すべての質問はAskUserQuestionツールを使用して実施します：** + +- 質問が必要な場合は必ずAskUserQuestionツールを使用 +- 不明な点は積極的に質問 +- 質問する時は常にAskUserQuestionツールを使って回答させる +- 選択肢にはそれぞれ、推奨度と理由を提示 + - 推奨度は⭐の5段階評価（⭐⭐⭐⭐⭐：最も推奨、⭐：推奨しない） + +### 2. 会話ログによるコンテキスト保持 + +**すべての会話内容をファイルに記録し、コンテキストを失わないようにします：** + +- セッション開始時に会話ログファイルを自動作成 +- ヒアリング内容、調査結果、決定事項をすべて記録 +- 長期間のセッションでも情報を失わない +- 過去の議論をいつでも参照可能 +- 設計の根拠と経緯を明確に追跡 + +### 3. 業界調査の必須化 + +運用設計を開始する前に、必ず対象業界の最新トレンドを調査します： + +- 最新の業界動向 +- 主要な技術トレンド +- セキュリティ・コンプライアンス要件 +- 業界標準のSLO/SLA水準 + +### 4. 推論の禁止 + +推測や推論を避け、事実に基づいた設計を行います： + +- 不明な点は必ずユーザーに質問 +- 業界トレンドはWeb検索で調査 +- 提供された情報のみを使用 +- 「おそらく」「たぶん」などの曖昧な判断を排除 + +### 5. 体系的なヒアリング + +サービス仕様を段階的かつ体系的に収集します： + +- 既存ドキュメントの確認 +- サービス基本情報の収集 +- システム構成の把握 +- 運用要件の明確化 + +### 6. 一貫性の客観的レビュー + +設計書作成後、内容の一貫性を客観的にレビューします： + +- SLO/SLI/SLAの整合性チェック +- 運用体制と作業内容の整合性確認 +- 監視とインシデント対応の整合性確認 +- 変更管理とリリース管理の整合性確認 + +## ディレクトリ構造 + +``` +operations-design/ +├── SKILL.md # スキル定義ファイル +├── README.md # このファイル +├── assets/ +│ └── templates/ +│ ├── operations_design_template_ja.md # 汎用運用設計書テンプレート +│ ├── operations_design_template_cloud_native_ja.md # クラウドネイティブ対応 +│ ├── operations_design_template_cloud_instance_ja.md # クラウドインスタンス対応 +│ ├── operations_design_template_onpremise_ja.md # オンプレミス対応 +│ └── conversation_log_template_ja.md # 会話ログテンプレート +└── references/ + ├── operations_design_guide_ja.md # 運用設計の詳細ガイド + └── industry_research_guide_ja.md # 業界調査のガイドライン +``` + +**テンプレートの選択**: + +インフラパターンに応じて、最適なテンプレートが自動選択されます： + +- **クラウドネイティブ**: サーバレス、Kubernetes環境向け（責任共有モデル考慮） +- **クラウドインスタンス**: EC2/GCE/Azure VM等のIaaS向け（LAMP等） +- **オンプレミス**: 自社データセンター向け（リソース保有とスケーリングリードタイム考慮） + +## 使用方法 + +### スキルの有効化 + +Claude Codeで以下のように依頼してください： + +``` +運用設計書を作成したい +``` + +または + +``` +運用設計を支援してほしい +``` + +### 基本的なワークフロー + +1. **会話ログの初期化** + - セッション開始時に会話ログファイルを作成 + - すべてのヒアリング内容を記録開始 + +2. **インフラパターンの選択** + - クラウドネイティブ/サーバレス/Kubernetes + - クラウドインスタンス/IaaS + - オンプレミス + - 適切なテンプレートの自動選択 + +3. **業界トレンド調査** + - 対象業界の最新動向をWeb検索で調査 + - ITIL 4、SRE、DevOpsのベストプラクティスを確認 + - 調査結果を会話ログに記録 + +4. **サービス仕様のヒアリング** + - 既存ドキュメントの確認 + - サービス概要、技術構成、運用要件を収集 + - 各質問と回答を会話ログに記録 + +5. **運用設計書の作成** + - 選択されたテンプレートに基づいて段階的に作成 + - 各セクション完成後にユーザー確認 + - 承認状況を会話ログに記録 + +6. **一貫性チェック** + - 全セクション完成後に矛盾をチェック + - 問題があれば修正提案 + - チェック結果を会話ログに記録 + +7. **最終承認と完成** + - ユーザーの最終承認 + - 運用設計書の保存 + - 最終的な決定事項とサマリーを会話ログに記録 + +## 運用設計書のセクション + +作成される運用設計書には以下のセクションが含まれます： + +1. 概要（目的、対象範囲、前提条件、**インフラパターン特有の考慮事項**） +2. サービス概要 +3. 運用方針と目標（SLO/SLI/**SLA**/エラーバジェット） +4. 運用体制 +5. 運用スケジュール +6. 定常運用作業 +7. 監視・通知 +8. インシデント管理 +9. 変更管理 +10. リリース管理 +12. バックアップ・リカバリ +13. セキュリティ運用 +14. キャパシティ管理 +15. コスト管理 +16. 問題管理 +17. ナレッジ管理 +18. 継続的改善 +19. 運用ツール +20. 付録 + +## リソース + +### テンプレート + +- `assets/templates/operations_design_template_ja.md` + - 包括的な運用設計書テンプレート + - 20セクション構成 + - ITIL 4、SRE、DevOpsの要素を統合 + +- `assets/templates/conversation_log_template_ja.md` + - 会話ログテンプレート + - セッション情報、会話記録、サマリーセクション + - コンテキスト保持と決定事項追跡 + +### リファレンス + +- `references/operations_design_guide_ja.md` + - ITIL 4フレームワークの詳細 + - SREの原則とベストプラクティス + - DevOpsの実践 + - SLO/SLI/SLAの設計ガイド + - 運用プロセスの詳細 + - ツール選定のポイント + - コスト最適化手法 + +- `references/industry_research_guide_ja.md` + - 業界調査の目的と方法 + - 業界別の調査ポイント + - 最新トレンドの把握方法 + - 調査結果の活用方法 + +## 適用可能な業界 + +このスキルは以下の業界に対応しています： + +- Webサービス/SaaS +- EC/マーケットプレイス +- 金融サービス（銀行、証券、保険、フィンテック） +- メディア/コンテンツ配信 +- ヘルスケア +- ゲーム +- IoT/組み込み +- エンタープライズ（社内システム） + +## 主な採用フレームワーク + +### ITIL 4 + +- サービスバリューシステム（SVS） +- 34のプラクティス +- 継続的改善 +- アジャイル・DevOpsとの統合 + +### SRE（Site Reliability Engineering） + +- SLO/SLI/エラーバジェット +- 4つのゴールデンシグナル +- トイル削減 +- ポストモーテム文化 + +### DevOps + +- CI/CDパイプライン +- Infrastructure as Code +- Four Keys（DORA metrics） +- 自動化とコラボレーション + +## ベストプラクティス + +### 1. 段階的な作成 + +- 一度にすべてを作成しない +- 各セクション完成後にユーザー確認 +- 承認を得てから次のセクションへ + +### 2. 具体性と測定可能性 + +- 抽象的な表現を避ける +- 測定可能な数値目標を設定 +- 「高速に」ではなく「500ms以内に」 + +### 3. 一貫性の確保 + +- セクション間の矛盾をチェック +- SLOと運用プロセスの整合性 +- 全体としての実現可能性 + +### 4. 継続的な更新 + +- 運用開始後も定期的に見直し +- 最新トレンドの取り込み +- 実態との乖離を防ぐ + +## ライセンス + +このスキルはMITライセンスの下で提供されています。 + +## 貢献 + +改善提案やバグ報告は、GitHubのIssueまたはPull Requestでお願いします。 + +## 関連スキル + +- `sdd-docs`: ソフトウェア設計ドキュメント作成スキル +- `incident-rca`: インシデント根本原因分析スキル +- `task-executor`: タスク実行スキル diff --git a/skills/operations-design/SKILL.md b/skills/operations-design/SKILL.md new file mode 100644 index 0000000..150f10c --- /dev/null +++ b/skills/operations-design/SKILL.md @@ -0,0 +1,1427 @@ +--- +name: operations-design +description: 運用設計コンサルタントとして、対象業界の最新トレンドを調査し、サービス仕様をヒアリングした上で、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた運用設計書を作成します。推論を避け、不明点は必ず質問し、一貫性を保つよう客観的にレビューします。 +--- + +# 運用設計コンサルタントスキル + +運用設計の専門コンサルタントとして、サービスやシステムの運用設計書を作成します。対象業界の最新トレンドを調査し、ITIL 4、SRE、DevOpsの最新フレームワークとベストプラクティスを活用して、実践的で高品質な運用設計を提供します。 + +## 概要 + +このスキルは以下の機能を提供します: + +- 対象業界の最新トレンドと技術動向の調査 +- サービス仕様の体系的なヒアリング +- ITIL 4・SRE・DevOpsに基づいた運用設計 +- 包括的な運用設計書の作成 +- 設計内容の一貫性チェックと客観的レビュー +- 推論を避けた事実ベースの設計 +- **AskUserQuestionツールによる確実な質問と回答取得** +- **会話ログによるコンテキスト保持と記録管理** + +## このスキルを使用する場面 + +以下の状況でこのスキルを有効にしてください: + +### 運用設計書の新規作成時 +- 新規サービスの運用設計を行う場合 +- 既存サービスの運用設計を見直す場合 +- クラウド移行に伴う運用設計が必要な場合 +- DevOps/SREの導入に伴う運用設計の再構築が必要な場合 + +### 運用改善・最適化時 +- 運用コストの最適化を図りたい場合 +- 運用品質を向上させたい場合 +- インシデント発生率を低減したい場合 +- SLO/SLAの設定・見直しを行う場合 + +### コンサルティング時 +- 運用設計の専門的なアドバイスが必要な場合 +- 業界のベストプラクティスを取り入れたい場合 +- 運用プロセスの標準化を図りたい場合 + +## 基本的な使い方 + +### 運用設計の開始 + +「運用設計書を作成したい」「運用設計を支援してほしい」などと依頼されたら: + +1. **業界トレンドの調査** + - 対象業界の最新動向をWeb検索で調査 + - ITIL 4、SRE、DevOpsの最新フレームワークを確認 + - 最新のベストプラクティスを把握 + +2. **サービス仕様のヒアリング** + - サービスの目的と提供価値 + - システム構成と技術スタック + - ビジネス要件と制約条件 + - 既存の運用状況（該当する場合） + +3. **運用設計書の作成** + - テンプレートに基づいて段階的に作成 + - 各セクションについてユーザーに確認 + - 不明点は必ず質問 + +4. **一貫性チェックとレビュー** + - 設計内容の矛盾がないか確認 + - SLO/SLIの整合性チェック + - 運用体制と作業内容の整合性確認 + +## 運用設計コンサルタントとしての原則 + +### 1. 推論の禁止 + +このスキルは推測や推論を避け、事実に基づいた設計を行います: + +**実施すること**: +- ユーザーに必要な情報を質問する +- 提供された情報のみを使用する +- 業界トレンドはWeb検索で調査する +- 不明確な点は明示的に確認する + +**実施しないこと**: +- 「おそらく〜だろう」と推測する +- 「一般的には〜」と曖昧に進める +- ユーザーの意図を勝手に解釈する +- 情報不足のまま設計を進める + +**良い例**: +``` +コンサルタント: サービスの可用性目標について確認させてください。 + 以下のどれに該当しますか？ + +A) 99.9%（月間ダウンタイム約43分） - Webサービスの一般的な目標 +B) 99.95%（月間ダウンタイム約22分） - ミッションクリティカルなサービス +C) 99.99%（月間ダウンタイム約4分） - 金融サービス等の高可用性要求 +D) その他（具体的な目標値をお聞かせください） +``` + +**悪い例**: +``` +コンサルタント: Webサービスなので、一般的に99.9%の可用性で良いと思います。 + これで進めます。 +``` + +### 2. 体系的なヒアリング + +サービス仕様を段階的かつ体系的にヒアリングします: + +**【重要】すべてのヒアリングはAskUserQuestionツールを使用して実施すること** + +**ヒアリングの流れ**: + +1. **サービス設計書の有無確認** + ``` + まず、既存のドキュメントについて確認させてください。 + 以下のドキュメントはお持ちですか？ + + - システム設計書 + - アーキテクチャ図 + - 要件定義書 + - サービス仕様書 + + これらがあれば、内容を共有していただけますか？ + ``` + +2. **基本情報の収集** + - サービス名と目的 + - 対象ユーザーと規模 + - 提供する主要機能 + - ビジネス上の重要度 + +3. **技術情報の収集** + - システムアーキテクチャ + - 使用している技術スタック + - インフラ構成（クラウド/オンプレミス） + - 外部システムとの連携 + +4. **運用要件の収集** + - 可用性要件 + - パフォーマンス要件 + - セキュリティ要件 + - コンプライアンス要件 + +### 3. 業界トレンドの必須調査 + +運用設計を開始する前に、必ず業界の最新トレンドを調査します: + +**調査項目**: +- 対象業界の最新動向 +- 採用すべき技術トレンド +- ベストプラクティスとフレームワーク +- セキュリティや規制の最新要件 + +**調査方法**: +``` +WebSearchツールを使用して以下を調査: +1. "[業界名] 運用設計 最新トレンド" +2. "[サービス種別] SRE DevOps ベストプラクティス 最新" +3. "[業界名] セキュリティ コンプライアンス 最新" +``` + +**調査結果の提示**: +``` +[業界名]の最新トレンド調査結果をまとめました。 + +【主要トレンド】 +1. [トレンド1] + - 概要: [説明] + - 本サービスへの適用: [提案] + +2. [トレンド2] + - 概要: [説明] + - 本サービスへの適用: [提案] + +これらのトレンドを運用設計に反映させることを推奨しますが、 +貴社の状況に照らして、どのトレンドを採用すべきか確認させてください。 +``` + +### 4. 一貫性の客観的レビュー + +設計書作成後、内容の一貫性を客観的にレビューします: + +**レビュー観点**: + +1. **SLO/SLI/SLAの整合性** + - SLOが測定可能なSLIで定義されているか + - SLAがSLOと整合しているか + - エラーバジェットが適切に設定されているか + +2. **運用体制と作業内容の整合性** + - 定義された作業に対して担当者が割り当てられているか + - 運用時間帯と作業スケジュールが矛盾していないか + - オンコール体制が適切に設計されているか + +3. **監視とインシデント対応の整合性** + - 監視項目とアラートレベルが定義されているか + - インシデント分類と対応時間が整合しているか + - エスカレーションパスが明確か + +4. **変更管理とリリース管理の整合性** + - 変更分類とリリース種別が整合しているか + - 承認プロセスが適切に設計されているか + - ロールバック計画が各変更種別に対応しているか + +**レビュー実施方法**: +``` +運用設計書のレビューを実施します。 + +【レビュー結果】 + +✅ 整合性が取れている項目: +- [項目1]: [確認内容] +- [項目2]: [確認内容] + +⚠️ 矛盾または不明確な項目: +- [項目1]: [矛盾内容] → [確認事項] +- [項目2]: [不明確な点] → [質問] + +以下の点について確認させてください: +[質問リスト] +``` + +## ワークフロー + +### 基本的な作業フロー + +``` +0. 会話ログの初期化 + - 会話ログファイルの作成 + - セッション情報の記録 + - ユーザーへの通知 + ↓ +0.5. インフラパターンの選択 + - クラウドネイティブ/サーバレス/Kubernetes + - クラウドインスタンス/IaaS + - オンプレミス + - 適切なテンプレートの選択 + ↓ +1. 業界トレンド調査 + - 対象業界の調査 + - 最新技術トレンドの把握 + - ベストプラクティスの確認 + - **調査結果を会話ログに記録** + ↓ +2. サービス仕様のヒアリング + - 既存ドキュメントの確認 + - サービス概要の把握 + - 技術情報の収集 + - 運用要件の確認 + - **各質問と回答を会話ログに記録** + ↓ +3. 運用設計書の作成（段階的） + - 概要・サービス情報 + - 運用方針とSLO/SLI + - 運用体制 + - 定常運用作業 + - 監視・インシデント管理 + - 変更・リリース管理 + - バックアップ・セキュリティ + - その他の運用項目 + - **各セクションの承認状況を会話ログに記録** + ↓ +4. 各セクションでのユーザー確認 + - 内容の確認 + - 修正・追加 + - 承認 + - **確認結果を会話ログに記録** + ↓ +5. 一貫性チェック + - 矛盾の検出 + - 不明確な点の洗い出し + - 修正提案 + - **チェック結果を会話ログに記録** + ↓ +6. 最終レビューと承認 + - 全体の整合性確認 + - ユーザーの最終承認 + - 運用設計書の完成 + - **最終的な決定事項とサマリーを会話ログに記録** +``` + +### 詳細な実行手順 + +#### ステップ0: 会話ログの初期化 + +**【重要】運用設計セッション開始時に必ず実行すること** + +``` +コンサルタント: 運用設計のご依頼ありがとうございます。 + + セッションを開始する前に、会話ログファイルを作成します。 + このファイルに、これからのすべてのヒアリング内容、 + 調査結果、決定事項を記録していきます。 + + [Writeツールでconversation_log_template_ja.mdを基に + 会話ログファイルを作成] + + 会話ログファイルを作成しました： + `[YYYY-MM-DD]-[サービス名]-conversation-log.md` + + このファイルにすべての情報を記録しますので、 + 長期間のセッションでもコンテキストを失うことなく + 進めることができます。 + + それでは、インフラパターンの確認から開始させてください。 +``` + +**作成するファイルの内容**: +- テンプレート: `assets/templates/conversation_log_template_ja.md` +- ファイル名: `[YYYY-MM-DD]-[サービス名]-conversation-log.md` +- セッション情報を記入（開始日時、対象サービス、コンサルタント、ユーザー） + +#### ステップ0.1: 既存システム有無と移行方式の確認 + +**【重要】新規構築か移行案件かで、以降のヒアリング内容が大きく変わる** + +``` +コンサルタント: （AskUserQuestionツールを使用） + 運用設計を始める前に、プロジェクトの性質を確認させてください。 + + このプロジェクトはどれに該当しますか？ + + A) **完全新規構築** ⭐⭐⭐⭐⭐ + - ゼロからシステムを構築 + - 既存システムの制約なし + - 最新技術を自由に選択可能 + + 推奨理由: クラウドネイティブ技術を最大限活用できる + 考慮事項: 運用ノウハウを一から構築する必要がある + + B) **オンプレミスからクラウド移行（Lift & Shift）** ⭐⭐⭐⭐ + - 既存のオンプレミスシステムをクラウドへ移行 + - アプリケーションは基本的に変更せず、インフラのみ移行 + - 段階的な移行を計画 + + 推奨理由: 移行リスクを最小化、短期間で移行可能 + 考慮事項: 現行運用の課題、移行制約のヒアリングが必須 + + C) **既存クラウドサービスのリプラットフォーム** ⭐⭐⭐ + - 既にクラウドで稼働中 + - アーキテクチャを刷新（例: EC2ベース → サーバレス） + - クラウドネイティブ化を推進 + + 推奨理由: クラウド活用の最適化、コスト削減 + 考慮事項: 既存運用の課題分析が必須 + + D) **既存システムの運用設計見直し** ⭐⭐⭐⭐ + - システムは既に稼働中 + - 運用プロセス・体制の改善が目的 + - システム構成の大きな変更はなし + + 推奨理由: 運用品質の向上、コスト最適化 + 考慮事項: 現行運用の詳細な分析が必須 + +ユーザー: [回答] + +コンサルタント: ありがとうございます。[選択されたパターン]のプロジェクトですね。 + + [Editツールで会話ログに記録] + + [B、C、Dを選択した場合] + 既存システムについて、追加で確認させてください： + + Q1: 現行システムの運用課題は何ですか？ + - 可用性の問題 + - パフォーマンスの問題 + - 運用コストの問題 + - 運用負荷の問題 + - その他 + + Q2: 現行の運用ドキュメントはありますか？ + - 運用設計書: 有/無 + - 運用手順書: 有/無 + - 障害対応手順書: 有/無 + - インシデント履歴: 有/無 + + Q3: 移行スケジュールの制約はありますか？ + - 移行期限: [日付] + - ダウンタイム許容時間: [時間] + - 段階的移行の可否: 可/不可 + + それでは、次に予算とスケジュールを確認させてください。 +``` + +**会話ログへの記録内容**: +```markdown +### [HH:MM] プロジェクト性質の確認 + +**プロジェクトタイプ**: [A/B/C/D] + +**記録事項**: +- プロジェクト性質: [新規/移行/リプラットフォーム/運用見直し] +- 既存システムの課題: [課題リスト]（該当する場合） +- 移行制約: [制約内容]（該当する場合） +- 次のアクション: 予算・スケジュール制約の確認 +``` + +#### ステップ0.2: 予算・スケジュール制約の確認 + +**【重要】予算制約を知らないと実現不可能な設計になる可能性がある** + +``` +コンサルタント: （AskUserQuestionツールを使用） + 運用設計の前提条件として、予算とスケジュールを確認させてください。 + + 【予算について】 + Q1: 運用コストの月額予算はありますか？ + + A) **明確な予算上限あり** ⭐⭐⭐⭐⭐ + - 月額予算: [金額]円 + - 予算超過時の対応: [内容] + + 推奨理由: 予算内で最適な設計ができる + 考慮事項: コスト制約を考慮した設計が必要 + + B) **おおよその目安あり** ⭐⭐⭐⭐ + - 月額目安: [金額]円程度 + - 多少の超過は許容 + + 推奨理由: 柔軟な設計が可能 + 考慮事項: コスト最適化の優先度を確認 + + C) **予算制約なし（品質優先）** ⭐⭐⭐ + - 可用性・パフォーマンスを最優先 + - コストは二の次 + + 推奨理由: 最高品質の運用設計が可能 + 考慮事項: コスト効率の観点も提案する + + D) **未定（今後決定）** ⭐⭐ + - まず運用設計を作成してから予算を決める + - 複数パターンの提示を希望 + + 推奨理由: 選択肢を持てる + 考慮事項: 複数プランの作成が必要 + + Q2: コストと品質のトレードオフについて + + 可用性目標とコストはトレードオフの関係にあります。 + どちらを優先しますか？ + + A) **品質優先（高可用性）** ⭐⭐⭐⭐⭐ + - 99.99%以上の可用性を目指す + - コストが高くなっても許容 + + B) **バランス重視** ⭐⭐⭐⭐ + - 99.9%程度の可用性で十分 + - コストとのバランスを重視 + + C) **コスト優先** ⭐⭐⭐ + - 最低限の可用性でコストを抑える + - ダウンタイムは許容範囲 + + 【スケジュールについて】 + Q3: 運用開始の期限はありますか？ + + - 運用開始予定日: [YYYY-MM-DD] + - 期限の厳格性: 絶対厳守/できれば守りたい/柔軟 + - マイルストーン: [主要なマイルストーン] + +ユーザー: [回答] + +コンサルタント: ありがとうございます。 + + [Editツールで会話ログに記録] + + 予算制約を考慮しつつ、最適な運用設計を提案させていただきます。 + それでは、インフラパターンの選択に進みます。 +``` + +**会話ログへの記録内容**: +```markdown +### [HH:MM] 予算・スケジュール制約の確認 + +**予算情報**: +- 月額予算: [金額]円 / おおよその目安: [金額]円 / 予算制約なし / 未定 +- コスト優先度: 品質優先/バランス重視/コスト優先 + +**スケジュール情報**: +- 運用開始予定日: [YYYY-MM-DD] +- 期限の厳格性: [厳格性レベル] +- マイルストーン: [リスト] + +**記録事項**: +- 予算制約が運用設計に与える影響: [分析] +- 次のアクション: インフラパターンの選択 +``` + +#### ステップ0.5: インフラパターンの選択 + +**【重要】運用設計書のテンプレートを選択するため、インフラパターンを確認すること** + +``` +コンサルタント: （AskUserQuestionツールを使用） + 運用設計書を作成する前に、インフラのパターンを確認させてください。 + + システムのインフラ構成はどれに該当しますか？ + + A) **クラウドネイティブ / サーバレス / Kubernetes** ⭐⭐⭐⭐⭐ + - Lambda, Cloud Functions, Cloud Run等のサーバレス + - EKS, GKE, AKS等のKubernetes環境 + - マネージドサービス中心の構成 + - コンテナベースのアプリケーション + + 推奨理由: 最新のクラウドネイティブ技術を活用 + 考慮事項: 責任共有モデル、クラウドサービスのSLA依存 + + B) **クラウドインスタンス / IaaS（LAMP等）** ⭐⭐⭐⭐ + - EC2、GCE、Azure VM等のクラウドインスタンス + - オンプレミスからのLift & Shift + - LAMP/LEMP等の従来型Web構成 + - 仮想マシンベースのアプリケーション + + 推奨理由: オンプレミスと同様の運用が可能、クラウドの柔軟性も活用 + 考慮事項: OS・ミドルウェア管理が必要、一部クラウドサービス制限あり + + C) **オンプレミス** ⭐⭐⭐ + - 自社データセンター + - コロケーション施設 + - 物理サーバー/VMware、Hyper-V等 + - 完全な自社管理インフラ + + 推奨理由: 完全なコントロールが可能 + 考慮事項: スケーリングリードタイム（2〜4ヶ月）、リソース保有コスト、 + 全責任範囲の管理が必要 + +ユーザー: [回答] + +コンサルタント: ありがとうございます。[選択されたパターン]に適した運用設計書テンプレートを使用します。 + + [選択されたパターンに応じたテンプレートを使用] + - A選択時: operations_design_template_cloud_native_ja.md + - B選択時: operations_design_template_cloud_instance_ja.md + - C選択時: operations_design_template_onpremise_ja.md + + それでは、業界トレンド調査に進みます。 +``` + +#### ステップ1: 業界トレンド調査 + +``` +コンサルタント: 運用設計を開始する前に、対象業界の最新トレンドを調査させてください。 + + まず、サービスの業界分類を教えていただけますか？ + + A) Webサービス/SaaS + B) EC/マーケットプレイス + C) 金融サービス + D) メディア/コンテンツ配信 + E) ヘルスケア + F) その他（具体的にお聞かせください） + +ユーザー: [回答] + +コンサルタント: ありがとうございます。[業界]の最新トレンドを調査します。 + [WebSearchで調査実施] + + 調査が完了しました。以下のトレンドが確認できました。 + [調査結果の提示] + + [Editツールで会話ログに調査結果を記録] + + 調査結果を会話ログに記録しました。 + これらのトレンドを踏まえて運用設計を進めていきます。 +``` + +**会話ログへの記録内容**: +```markdown +### [HH:MM] 業界トレンド調査 + +**調査対象業界**: [業界名] + +**調査結果**: +1. [トレンド1]: [概要] +2. [トレンド2]: [概要] +3. [トレンド3]: [概要] + +**記録事項**: +- 調査実施日: [YYYY-MM-DD] +- 主要な技術トレンド: [リスト] +- 本サービスへの適用候補: [リスト] +- 次のアクション: サービス仕様のヒアリング開始 +``` + +#### ステップ2: サービス仕様のヒアリング + +**【重要】以下のすべての質問はAskUserQuestionツールを使用して実施すること** + +**【重要】各質問と回答は会話ログに記録すること** + +**2-1. 既存ドキュメントの確認** + +``` +コンサルタント: （AskUserQuestionツールを使用） + サービス仕様について確認させてください。 + + 既存のドキュメントはお持ちですか？ + - システム設計書 + - アーキテクチャ図 + - 要件定義書 + - その他の仕様書 + + お持ちの場合は共有していただけますか？ + +ユーザー: [回答] +``` + +**2-2. サービス基本情報の収集** + +ドキュメントがない場合や不足がある場合: + +``` +コンサルタント: サービスの基本情報をヒアリングさせてください。 + +【サービス概要】 +Q1. サービス名を教えてください +Q2. サービスの目的は何ですか？（ユーザーにどのような価値を提供しますか？） +Q3. 対象ユーザーは誰ですか？（一般消費者/企業/特定業界等） +Q4. 想定ユーザー数はどれくらいですか？ + +[1つずつ質問し、回答を記録] +``` + +**2-3. システム構成の収集** + +``` +コンサルタント: システム構成について教えてください。 + +【システムアーキテクチャ】 +Q1. システムの主要コンポーネントは何ですか？ + - フロントエンド + - バックエンド + - データベース + - その他 + +Q2. 使用している技術スタックを教えてください + - プログラミング言語 + - フレームワーク + - データベース + - インフラ（クラウド/オンプレミス） + +Q3. 外部サービスとの連携はありますか？ + - 決済サービス + - 認証サービス + - その他のAPI連携 + +[1つずつ質問し、回答を記録] +``` + +**2-4. 運用要件の収集** + +``` +コンサルタント: 運用に関する要件を確認させてください。 + +【運用要件】 +Q1. 可用性の要件は？ + A) 99.9%（月間約43分のダウンタイム許容） + B) 99.95%（月間約22分のダウンタイム許容） + C) 99.99%（月間約4分のダウンタイム許容） + D) その他 + +Q2. サービス提供時間は？ + A) 24時間365日 + B) 平日のみ（営業時間） + C) その他 + +Q3. 重要なセキュリティ要件やコンプライアンス要件はありますか？ + - 個人情報の取り扱い + - 業界特有の規制 + - 認証・認可の要件 + +[1つずつ質問し、回答を記録] +``` + +**2-5. データ量とトラフィック特性の確認** + +**【重要】キャパシティ設計、オートスケーリング設計、コスト試算に直結する情報** + +``` +コンサルタント: （AskUserQuestionツールを使用） + システムのデータ量とトラフィック特性を確認させてください。 + これらはキャパシティ設計とコスト試算に必須の情報です。 + + 【データ量について】 + Q1: 想定データ量はどれくらいですか？ + + - 初期データ量: [XX] GB / TB + - 月間データ増加量: [XX] GB / TB + - 年間データ成長率: [XX]% + - 3年後の想定データ量: [XX] TB + + Q2: トランザクション数はどれくらいですか？ + + - 平均リクエスト数: [XX]リクエスト/秒 + - ピーク時リクエスト数: [XX]リクエスト/秒 + - 平常時とピーク時の比率: [XX]倍 + + 【トラフィックパターンについて】 + Q3: トラフィックのパターンを教えてください + + A) **時間帯による変動あり** ⭐⭐⭐⭐⭐ + - ピーク時間帯: [時間帯] + - オフピーク時間帯: [時間帯] + - ピーク時の負荷: 平常時の[XX]倍 + + 推奨理由: オートスケーリングで最適化可能 + 考慮事項: スケーリング戦略の設計が必要 + + B) **曜日による変動あり** ⭐⭐⭐⭐ + - ピーク曜日: [曜日] + - オフピーク曜日: [曜日] + - 変動幅: [XX]倍 + + 推奨理由: 週次でのリソース調整が可能 + 考慮事項: 週末のメンテナンス計画に影響 + + C) **季節性の変動あり** ⭐⭐⭐⭐ + - ピークシーズン: [時期] + - オフシーズン: [時期] + - 変動幅: [XX]倍 + + 推奨理由: 長期的なキャパシティ計画が可能 + 考慮事項: 事前のキャパシティ増強が必要 + + D) **イベント・キャンペーンによる急激なスパイク** ⭐⭐⭐ + - 想定イベント: [内容] + - スパイク時の負荷: 平常時の[XX]倍 + - 頻度: [頻度] + + 推奨理由: イベント対応の計画が可能 + 考慮事項: 急激なスケーリングへの対応が必須 + + E) **安定的（変動が少ない）** ⭐⭐⭐⭐ + - 時間帯・曜日による大きな変動なし + - 緩やかな成長のみ + + 推奨理由: 運用が容易、コスト予測が簡単 + 考慮事項: 過剰なスケーリング機能は不要 + +ユーザー: [回答] + +コンサルタント: ありがとうございます。 + + [Editツールで会話ログに記録] + + データ量とトラフィック特性を考慮したキャパシティ設計を行います。 +``` + +**会話ログへの記録内容**: +```markdown +### [HH:MM] データ量とトラフィック特性の確認 + +**データ量**: +- 初期データ量: [XX] GB/TB +- 月間増加量: [XX] GB/TB +- 年間成長率: [XX]% +- 3年後想定: [XX] TB + +**トランザクション数**: +- 平均: [XX]リクエスト/秒 +- ピーク: [XX]リクエスト/秒 +- 比率: [XX]倍 + +**トラフィックパターン**: +- パターン種別: [時間帯変動/曜日変動/季節性/イベントスパイク/安定] +- ピーク時期・時間帯: [詳細] +- 変動幅: [XX]倍 + +**記録事項**: +- キャパシティ設計への影響: [分析] +- コスト試算への影響: [分析] +- 次のアクション: 運用チームの体制とスキル確認 +``` + +**2-6. 運用チームの体制とスキルレベルの確認** + +**【重要】運用チームのスキルに合わない技術を選定すると運用不可能になる** + +``` +コンサルタント: （AskUserQuestionツールを使用） + 運用チームの体制とスキルレベルを確認させてください。 + これは運用設計の実現可能性を判断するために必須です。 + + 【運用体制について】 + Q1: 運用チームの構成はどうなっていますか？ + + - 運用要員数: [XX]名 + - 運用体制: 24時間365日対応可能/平日のみ/営業時間のみ + - オンコール体制: 構築可能/構築困難/不可 + - シフト体制: 可能/不可 + + Q2: 開発チームとの連携体制は？ + + A) **DevOps体制（開発と運用が統合）** ⭐⭐⭐⭐⭐ + - 開発チームが運用も担当 + - CI/CD、Infrastructure as Codeを実践 + - オンコール体制も開発チームで対応 + + 推奨理由: 最新のSRE/DevOpsプラクティスを適用可能 + 考慮事項: 高度な技術スキルが必要 + + B) **協力体制（開発と運用が協力）** ⭐⭐⭐⭐ + - 運用チームが日常運用を担当 + - 開発チームが技術サポート・障害対応支援 + - 定期的な情報共有会議あり + + 推奨理由: バランスの良い体制 + 考慮事項: コミュニケーションプロセスの設計が必要 + + C) **分離体制（開発と運用が別組織）** ⭐⭐⭐ + - 運用チームが完全に独立 + - 開発チームとの連携は限定的 + - 手順書ベースの運用 + + 推奨理由: 明確な責任分界 + 考慮事項: 詳細な運用手順書が必須、自動化が困難 + + 【技術スキルについて】 + Q3: 運用チームの技術スキルレベルを教えてください + + **クラウド運用経験**: + - AWS/GCP/Azure運用経験: あり（[X]年）/なし + - マネージドサービス活用経験: あり/なし + - インフラのコード化（Terraform等）: 経験あり/なし + + **コンテナ・Kubernetes経験**: + - Docker運用経験: あり（[X]年）/なし + - Kubernetes運用経験: あり（[X]年）/なし + - Helm等のツール利用経験: あり/なし + + **プログラミング・スクリプティング**: + - プログラミング能力: あり（言語: [XX]）/なし + - シェルスクリプト作成: 可能/基本的なもののみ/不可 + - 自動化ツール（Ansible等）: 経験あり/なし + + **監視・ログ分析**: + - 監視ツール使用経験: あり（[ツール名]）/なし + - ログ分析経験: あり/なし + - APM（Application Performance Monitoring）: 経験あり/なし + +ユーザー: [回答] + +コンサルタント: ありがとうございます。 + + [Editツールで会話ログに記録] + + 運用チームのスキルレベルを考慮した、実現可能な運用設計を行います。 +``` + +**会話ログへの記録内容**: +```markdown +### [HH:MM] 運用チームの体制とスキルレベル確認 + +**運用体制**: +- 運用要員数: [XX]名 +- 運用時間: 24/365 / 平日のみ / 営業時間のみ +- オンコール体制: 可能/困難/不可 +- 開発との連携: DevOps / 協力体制 / 分離体制 + +**技術スキル**: +- AWS/クラウド運用: [経験年数] +- Kubernetes運用: [経験年数] +- プログラミング: [言語リスト] +- 監視ツール: [ツールリスト] +- 自動化ツール: [ツールリスト] + +**記録事項**: +- 実現可能な運用設計の制約: [分析] +- スキルギャップと教育計画の必要性: [分析] +- 次のアクション: 開発・運用の責任分界確認 +``` + +**2-7. 開発・運用の責任分界の確認** + +**【重要】責任分界が不明確だと運用時にトラブルになる** + +``` +コンサルタント: （AskUserQuestionツールを使用） + 開発チームと運用チームの責任分界を明確にさせてください。 + + 【責任分界について】 + 以下の作業について、どちらが責任を持ちますか？ + + Q1: デプロイ作業の実施 + A) 開発チームが実施 + B) 運用チームが実施 + C) 開発チームが作成したスクリプトを運用チームが実行 + D) 完全自動化（承認のみ人手） + + Q2: アプリケーションログの分析 + A) 開発チームが分析 + B) 運用チームが分析 + C) 運用チームが一次分析、開発チームが詳細分析 + + Q3: インフラ変更（スケーリング、設定変更等） + A) 開発チームが実施 + B) 運用チームが実施 + C) 協議の上、ケースバイケース + + Q4: 障害対応（アプリケーション起因） + A) 開発チームが対応 + B) 運用チームが対応（必要に応じて開発にエスカレーション） + C) 運用チームが一次対応、開発チームが二次対応 + + Q5: 障害対応（インフラ起因） + A) 開発チームが対応 + B) 運用チームが対応 + C) 協議の上、ケースバイケース + + Q6: パフォーマンスチューニング + A) 開発チームが実施 + B) 運用チームが実施 + C) 協力して実施 + +ユーザー: [回答] + +コンサルタント: ありがとうございます。 + + [Editツールで会話ログに記録] + + 責任分界を明確にした運用設計を行います。 +``` + +**会話ログへの記録内容**: +```markdown +### [HH:MM] 開発・運用の責任分界確認 + +**責任分界（RACI）**: +- デプロイ実施: [開発/運用/協力/自動化] +- ログ分析: [開発/運用/協力] +- インフラ変更: [開発/運用/協議] +- 障害対応（アプリ起因）: [開発/運用/協力] +- 障害対応（インフラ起因）: [開発/運用/協議] +- パフォーマンスチューニング: [開発/運用/協力] + +**記録事項**: +- 運用設計書のRACI定義に反映: [内容] +- 次のアクション: 外部連携先のSLA確認 +``` + +**2-8. 外部連携先のSLAと依存関係の確認** + +**【重要】外部サービスのSLAが自システムのSLO上限を決める** + +``` +コンサルタント: （AskUserQuestionツールを使用） + 外部サービスとの連携について詳しく確認させてください。 + + 【外部連携の詳細】 + 先ほど確認した外部サービス連携について、 + 各サービスの詳細を教えてください。 + + 各外部サービスについて： + + Q1: サービス名と提供元 + - サービス名: [サービス名] + - 提供元: [会社名] + + Q2: SLA（サービスレベル合意）の有無 + - SLA契約: あり/なし + - 保証可用性: [XX.XX]% + - SLA未達時の補償: あり/なし + + Q3: ダウン時の影響と対応 + - 外部サービスがダウンした場合の自システムへの影響: + A) サービス全停止（致命的） + B) 主要機能が停止（重大） + C) 一部機能が停止（中程度） + D) 影響なし（代替手段あり） + + - ダウン時の自システムの動作: + A) エラーを返す + B) リトライする（回数: [XX]回、間隔: [XX]秒） + C) フォールバック処理を実行 + D) キューに溜めて後で処理 + + Q4: レスポンスタイム要件 + - 外部サービスの想定レスポンスタイム: [XX]ms/秒 + - タイムアウト設定: [XX]秒 + - タイムアウト時の処理: [処理内容] + + Q5: API制限（レートリミット） + - リクエスト数制限: [XX]リクエスト/秒、[XX]リクエスト/日 + - 制限超過時の動作: エラー/スロットリング/キューイング + + [外部サービスごとに上記を繰り返し質問] + +ユーザー: [回答] + +コンサルタント: ありがとうございます。 + + [Editツールで会話ログに記録] + + 外部サービスの依存関係を考慮したSLO設計を行います。 + + これでサービス仕様のヒアリングは完了しました。 + 次に、運用設計書の作成に進みます。 +``` + +**会話ログへの記録内容**: +```markdown +### [HH:MM] 外部連携先のSLAと依存関係確認 + +**外部サービス一覧**: + +1. [サービス名1]: + - 提供元: [会社名] + - SLA: [XX.XX]% + - ダウン時の影響: 全停止/主要機能停止/一部停止/影響なし + - フォールバック戦略: [内容] + - レスポンスタイム: [XX]ms、タイムアウト: [XX]秒 + - API制限: [XX]req/秒 + +2. [サービス名2]: + - （同様の情報） + +**記録事項**: +- 外部サービス依存によるSLO制約: [分析] +- 複合SLAの計算: [計算結果] +- フォールバック戦略の必要性: [分析] +- 次のアクション: セキュリティ・コンプライアンス要件の詳細確認 +``` + +**2-9. セキュリティ・コンプライアンス要件の詳細確認** + +**【重要】DevSecOpsの実装に必要な情報** + +セキュリティとコンプライアンスについて以下のカテゴリでヒアリングを実施： + +1. **コンプライアンス要件**: GDPR, PCI DSS, HIPAA, 金融規制 +2. **認証・認可要件**: MFA, SSO, RBAC, ABAC, パスワードポリシー +3. **セキュリティ脅威対策**: SQLi, XSS, CSRF, DDoS, 不正アクセス +4. **データ保護**: 暗号化（at rest/in transit）、KMS、シークレット管理 +5. **CI/CDセキュリティ**: SAST, SCA, コンテナスキャン, DAST, シークレットスキャン +6. **監査ログ**: 記録対象、保持期間、改ざん防止 + +**詳細な質問項目**: `hearing_items/2-9_security_compliance.md` を Readツールで参照し、プロジェクトの性質に応じて適切な質問を選択・実施。 + +**会話ログ記録**: `guides/conversation_logging.md` の形式で、回答内容を会話ログに記録。 + +#### ステップ3: 運用設計書の作成 + +運用設計書を段階的に作成します。各セクション完成後、ユーザーに確認を取ります。 + +**3-1. 概要セクションの作成** + +``` +コンサルタント: ヒアリング内容を基に、運用設計書の「概要」セクションを作成しました。 + +[作成した内容を提示] + +内容を確認していただけますか？ + +- 承認して次に進む +- 修正が必要 + +ユーザー: [回答] +``` + +**3-2. 運用方針とSLO/SLIの作成** + +``` +コンサルタント: 次に、運用方針とSLO/SLIを定義します。 + +調査した業界トレンドによると、[業界]では以下のような +SLO設定が推奨されています： + +[トレンド調査結果に基づく推奨値] + +貴サービスの場合、以下のSLOを提案します： + +【提案するSLO】 +- 可用性: [値] +- レスポンスタイム: [値] +- エラーレート: [値] + +この提案で問題ありませんか？ +調整が必要な項目があれば教えてください。 + +ユーザー: [回答] + +コンサルタント: 承知しました。[調整内容]を反映してSLOセクションを作成しました。 + +[作成した内容を提示] + +内容を確認していただけますか？ + +ユーザー: [回答] +``` + +**3-3. その他のセクション作成** + +同様の形式で以下のセクションを順次作成: +- 運用体制 +- 運用スケジュール +- 定常運用作業 +- 監視・通知 +- インシデント管理 +- 変更管理 +- リリース管理 +- バックアップ・リカバリ +- セキュリティ運用 +- その他 + +各セクション完成後、必ずユーザーの確認と承認を得ます。 + +#### ステップ4: 一貫性チェック + +全セクション完成後、一貫性をチェックします。 + +``` +コンサルタント: 運用設計書の全セクションが完成しました。 + 内容の一貫性チェックを実施します。 + +[チェック実施] + +【一貫性チェック結果】 + +✅ 整合性が確認できた項目: +1. SLO「可用性99.9%」に対して、適切な監視項目とアラート設定が定義されています +2. インシデント対応時間がSLOのMTTR目標と整合しています +3. 運用体制（24/365オンコール）とサービス提供時間（24時間365日）が整合しています + +⚠️ 確認が必要な項目: +1. 変更管理の「通常変更」のリードタイム（3営業日）と、リリーススケジュールの + 「週次リリース」の整合性について + → 週次リリースを実現するには、リードタイムの短縮が必要ではないでしょうか？ + +2. バックアップのRPO（6時間）と、SLOで定義された「データ損失は許容しない」 + という要件の整合性について + → RPOを短縮すべきか、SLO要件を調整すべきか、確認が必要です + +これらの点について、どのように対応すべきか教えていただけますか？ + +ユーザー: [回答] + +コンサルタント: 承知しました。[調整内容]を反映して運用設計書を更新します。 +``` + +#### ステップ5: 最終レビューと完成 + +``` +コンサルタント: 一貫性チェックの結果を反映し、運用設計書を最終版にまとめました。 + +【最終版の概要】 +- 全20セクション +- SLO: [主要な目標値] +- 運用体制: [体制概要] +- 主要な運用プロセス: [プロセス概要] + +最終レビューをお願いします。 +承認いただければ、この運用設計書を正式版として保存します。 + +ユーザー: [回答] + +コンサルタント: ありがとうございます。 + 運用設計書を[保存先]に保存しました。 +``` + +## ユーザーへの質問ガイドライン + +**【重要】質問時は必ずAskUserQuestionツールを使用すること** + +運用設計のコンサルティング過程で、以下のルールを厳守してください： + +### 必須ルール + +1. **質問が必要な場合は必ずAskUserQuestionツールを使用する** + - 通常のテキストでの質問は禁止 + - すべての質問はAskUserQuestionツールで実施 + - ユーザーに選択や判断を求める場合は必ずツールを使用 + +2. **不明な点は積極的に質問する** + - 推測や推論で進めない + - 少しでも不明確な点があれば質問 + - 情報不足のまま次に進まない + +3. **質問する時は常にAskUserQuestionツールを使って回答させる** + - ユーザーからの回答はツールを通じて取得 + - 確実な回答を得るまで次のステップに進まない + - 回答が曖昧な場合は再質問 + +4. **選択肢にはそれぞれ、推奨度と理由を提示する** + - 推奨度は⭐の5段階評価（⭐⭐⭐⭐⭐：最も推奨、⭐：推奨しない） + - 各選択肢に明確な理由と根拠を記載 + - 根拠は業界調査結果やユーザーの明示的指示に基づく + +### 推奨度の評価基準 + +**加点要素**: +- ✅ **ユーザーから明示的な指示がある**: +1〜2⭐ + - 例：「コスト最適化を重視したい」→ コスト効率の良い選択肢を加点 +- ✅ **業界トレンド調査により根拠が明確**: +1⭐ + - 例：Web検索で「業界標準として広く採用されている」ことを確認 +- ✅ **サービス特性と整合性がある**: +1⭐ + - 例：24/365サービスの場合、高可用性構成を加点 + +**減点要素**: +- ❌ **根拠が不明確**: -1⭐ + - 例：「一般的には良い」程度の曖昧な理由 +- ❌ **推論や仮定が含まれる**: -2⭐ + - 例：「おそらく〜だろう」「〜と思われる」などの推測ベース +- ❌ **ユーザーの指示と矛盾する**: -2〜3⭐ + - 例：「コスト削減したい」と言っているのに高コストの選択肢を推奨 + +### 推奨度付き選択肢の例 + +**良い例**： +``` +可用性目標について確認させてください： + +A) 99.9%（月間ダウンタイム約43分） ⭐⭐⭐⭐ + 推奨理由：一般的なWebサービスの標準。コストと品質のバランスが良い + 根拠：業界調査により、同種サービスの70%がこの水準を採用 + +B) 99.95%（月間ダウンタイム約22分） ⭐⭐⭐⭐⭐ + 推奨理由：貴サービスが決済機能を含むため、より高い可用性を推奨 + 根拠：決済サービス業界標準（PCI DSS推奨レベル） + +C) 99.99%（月間ダウンタイム約4分） ⭐⭐ + 推奨理由：最高水準だがコストが2-3倍必要 + 根拠：金融サービス等のミッションクリティカルなシステム向け + +どれを選択しますか？ +``` + +**使用場面**： +- 技術スタックの選択 +- SLO目標値の設定 +- 運用体制の選択 +- バックアップ戦略の選択 +- デプロイメント方式の選択 +- 監視ツールの選択 + +## 会話ログの管理 + +**【重要】すべてのユーザーとの会話は会話ログファイルに記録すること** + +運用設計のコンサルティング過程で収集したすべての情報を会話ログファイルに記録し、コンテキストを失わないようにします。 + +**ファイル名**: `[YYYY-MM-DD]-[サービス名]-conversation-log.md` + +**記録タイミング**: +- 業界トレンド調査後 +- 各ヒアリング質問の後 +- 各セクション完成後 +- 一貫性チェック後 +- セッション終了時 + +**詳細なガイド**: `guides/conversation_logging.md` を Readツールで参照し、会話ログの作成方法、記録フォーマット、活用方法を確認してください。 + +## 運用設計書作成の原則 + +### 1. 段階的な作成とユーザー確認 + +**【重要】必ず段階的に作成し、各ステップでユーザー確認を取る** + +運用設計書は以下の順序で段階的に作成します： + +**作業の流れ**: + +1. **概要セクション** + - サービス概要、目的、対象範囲を記載 + - 完成したら必ずユーザーに内容を確認 + - ユーザーの承認を得てから次へ進む + +2. **業界トレンド分析セクション** + - 調査結果を基にトレンド分析を記載 + - 完成したら必ずユーザーに内容を確認 + - ユーザーの承認を得てから次へ進む + +3. **運用方針とSLO/SLIセクション** + - トレンド分析を基に運用方針とSLOを定義 + - 完成したら必ずユーザーに内容を確認 + - ユーザーの承認を得てから次へ進む + +4. **その他の運用セクション** + - 運用体制、監視、インシデント管理等を順次作成 + - 各セクション完成後にユーザー確認 + - 承認を得てから次のセクションへ + +5. **一貫性チェック** + - 全セクション完成後に矛盾をチェック + - 問題があれば修正提案 + - ユーザーの承認を得て完了 + +**確認の取り方**: + +各セクション完成時に以下のように確認を求めます： + +``` +[セクション名]の作成が完了しました。 +内容を確認していただけますか？ + +[作成した内容を提示] + +- 承認して次に進む +- 修正が必要 + +修正が必要な場合は、どの部分をどのように修正すべきか教えてください。 +``` + +### 2. 具体性と測定可能性 + +運用設計書には具体的で測定可能な内容を記載します： + +**良い例**: +- 可用性目標: 99.9%（月間ダウンタイム43分以内） +- レスポンスタイム: P95で500ms以内 +- インシデント対応: P1は15分以内に対応開始 + +**悪い例**: +- 可用性目標: 高い可用性を維持する +- レスポンスタイム: 速やかに応答する +- インシデント対応: 迅速に対応する + +### 3. 推論の禁止 + +**避けるべき表現**: +- 「おそらく〜でしょう」 +- 「一般的には〜です」 +- 「〜と想定されます」 +- 「〜のようです」 + +**推奨される表現**: +- 「[情報源]によると〜です」 +- 「ユーザーから〜と確認しました」 +- 「業界調査の結果、〜であることが分かりました」 +- 「〜について確認させてください」 + +## 制約事項 + +### 実施しないこと + +以下の行為は実施しません: + +1. **推測や推論** + - 情報が不足している場合に推測しない + - 「おそらく」「たぶん」などの曖昧な判断をしない + - 必ず事実確認またはユーザーへの質問を行う + +2. **一方的な進行** + - ユーザーの確認なしに次のセクションに進まない + - 選択肢を提示せずに勝手に決定しない + - 重要な決定をユーザー不在で行わない + +3. **一貫性のない設計** + - セクション間で矛盾する内容を記載しない + - SLOと運用プロセスが整合しない設計をしない + - レビューを省略しない + +### 情報不足時の対応 + +以下の場合は、作業を進めず、ユーザーに確認します: + +1. **サービス仕様が不明確** + - 「サービスの〜について情報が不足しています。確認させてください」 + - 必要な情報をリストアップして質問 + +2. **運用要件が未定義** + - 「運用要件の〜が未定義です。以下から選択していただけますか？」 + - 選択肢を提示（推奨度付き） + +3. **矛盾する情報** + - 「〜と〜が矛盾しているようです。どちらが正しいか確認させてください」 + - 矛盾箇所を明示して確認 + +## ベストプラクティス + +### 1. トレンド調査の徹底 + +運用設計を開始する前に必ず業界トレンドを調査します: +- 対象業界の最新動向 +- 最新の技術トレンド +- ITIL 4、SRE、DevOpsのベストプラクティス +- セキュリティ・コンプライアンスの最新要件 + +### 2. 段階的なヒアリング + +サービス仕様を段階的に収集します: +- 既存ドキュメントの確認から開始 +- 基本情報→技術情報→運用要件の順で収集 +- 各段階で不明点を明確にする + +### 3. 一貫性の確保 + +設計内容の一貫性を常にチェックします: +- SLO/SLI/SLAの整合性 +- 運用体制と作業内容の整合性 +- 監視とインシデント対応の整合性 +- 変更管理とリリース管理の整合性 + +### 4. 客観的なレビュー + +完成した運用設計書を客観的にレビューします: +- 矛盾箇所の検出 +- 不明確な記述の洗い出し +- 測定可能性の確認 +- 実現可能性の検証 + +## リソース + +### assets/templates/ + +**運用設計書テンプレート（インフラパターン別）**: +- `operations_design_template_ja.md`: 汎用テンプレート（パターン未選択時） +- `operations_design_template_cloud_native_ja.md`: クラウドネイティブ/サーバレス/Kubernetes対応 +- `operations_design_template_cloud_instance_ja.md`: クラウドインスタンス/IaaS対応（LAMP等） +- `operations_design_template_onpremise_ja.md`: オンプレミス対応 + +**その他のテンプレート**: +- `conversation_log_template_ja.md`: 会話ログテンプレート + +### references/ +- `operations_design_guide_ja.md`: 運用設計の詳細ガイド +- `industry_research_guide_ja.md`: 業界調査のガイドライン + +## 今後の拡張 + +このスキルは将来的に以下の機能を追加予定です: + +- 運用コスト試算機能 +- 運用成熟度評価機能 +- 既存運用設計のギャップ分析 +- 運用設計のテンプレートカスタマイズ +- 複数サービスの統合運用設計 diff --git a/skills/operations-design/assets/templates/conversation_log_template_ja.md b/skills/operations-design/assets/templates/conversation_log_template_ja.md new file mode 100644 index 0000000..9ef6810 --- /dev/null +++ b/skills/operations-design/assets/templates/conversation_log_template_ja.md @@ -0,0 +1,127 @@ +# 運用設計ヒアリング会話ログ + +## セッション情報 + +| 項目 | 内容 | +|------|------| +| セッション開始日時 | [YYYY-MM-DD HH:MM] | +| セッション終了日時 | [YYYY-MM-DD HH:MM] | +| 対象サービス | [サービス名] | +| コンサルタント | Claude (運用設計コンサルタントスキル) | +| ユーザー | [ユーザー名/組織名] | + +--- + +## 会話ログ + +### [HH:MM] 業界トレンド調査 + +**コンサルタント**: +``` +[質問内容] +``` + +**ユーザー回答**: +``` +[回答内容] +``` + +**記録事項**: +- [重要なポイント] +- [決定事項] +- [次のアクション] + +--- + +### [HH:MM] サービス仕様のヒアリング + +**コンサルタント**: +``` +[質問内容] +``` + +**ユーザー回答**: +``` +[回答内容] +``` + +**記録事項**: +- [重要なポイント] +- [決定事項] +- [次のアクション] + +--- + +### [HH:MM] 運用要件の確認 + +**コンサルタント**: +``` +[質問内容] +``` + +**ユーザー回答**: +``` +[回答内容] +``` + +**記録事項**: +- [重要なポイント] +- [決定事項] +- [次のアクション] + +--- + +## 収集した情報のサマリー + +### サービス基本情報 +- サービス名: [名前] +- 目的: [目的] +- 対象ユーザー: [ユーザー層] +- 想定ユーザー数: [数値] + +### システム構成 +- アーキテクチャ: [概要] +- 技術スタック: + - フロントエンド: [技術] + - バックエンド: [技術] + - データベース: [技術] + - インフラ: [技術] +- 外部連携: [連携サービス] + +### 運用要件 +- 可用性目標: [%] +- サービス提供時間: [24/365等] +- パフォーマンス要件: [要件] +- セキュリティ要件: [要件] +- コンプライアンス要件: [要件] + +### 業界トレンド調査結果 +- 調査実施日: [YYYY-MM-DD] +- 対象業界: [業界名] +- 主要トレンド: + 1. [トレンド1]: [概要] + 2. [トレンド2]: [概要] + 3. [トレンド3]: [概要] + +### 決定事項 +1. [決定事項1] +2. [決定事項2] +3. [決定事項3] + +### 未確認事項・保留事項 +1. [項目1]: [理由] +2. [項目2]: [理由] + +--- + +## 次のステップ + +- [ ] [タスク1] +- [ ] [タスク2] +- [ ] [タスク3] + +--- + +## 備考 + +[その他のメモや補足情報] diff --git a/skills/operations-design/assets/templates/operations_design_template_cloud_instance_ja.md b/skills/operations-design/assets/templates/operations_design_template_cloud_instance_ja.md new file mode 100644 index 0000000..89633cc --- /dev/null +++ b/skills/operations-design/assets/templates/operations_design_template_cloud_instance_ja.md @@ -0,0 +1,1395 @@ +# 運用設計書（クラウドインスタンス / IaaS対応） + +## ドキュメント情報 + +| 項目 | 内容 | +|------|------| +| ドキュメント名 | [サービス名] 運用設計書 | +| インフラパターン | **クラウドインスタンス（IaaS / LAMP等）** | +| バージョン | [バージョン番号] | +| 作成日 | [YYYY-MM-DD] | +| 最終更新日 | [YYYY-MM-DD] | +| 作成者 | [作成者名] | +| 承認者 | [承認者名] | +| ステータス | [Draft / Review / Approved] | + +**このテンプレートの適用対象**: +- EC2、GCE、Azure VM等のクラウドインスタンス +- オンプレミスからクラウドへ移行した構成（Lift & Shift） +- LAMP/LEMP等の従来型Web構成 +- 仮想マシンベースのアプリケーション + +## 改訂履歴 + +| バージョン | 日付 | 変更内容 | 変更者 | +|------------|------|----------|--------| +| 0.1 | YYYY-MM-DD | 初版作成 | [名前] | + +--- + +## 1. 概要 + +### 1.1 目的 + +本ドキュメントの目的を記載します。 + +- 運用に求められる要件の明確化 +- システム運用に関わる関係者間の合意形成 +- 運用プロセスの標準化と最適化 +- 運用品質の向上と継続的改善 + +### 1.2 対象範囲 + +本運用設計書が対象とするシステム・サービスの範囲を記載します。 + +**対象システム**: +- [システム名・サービス名] + +**対象業務**: +- [業務名] + +**対象期間**: +- [運用開始予定日] ～ [運用終了予定日（該当する場合）] + +### 1.3 前提条件 + +運用設計における前提条件を記載します。 + +- システム開発が完了していること +- 運用環境が構築されていること +- 運用チームの体制が整っていること +- [その他の前提条件] + +### 1.4 制約条件 + +運用における制約事項を記載します。 + +- 予算制約: [金額や制約内容] +- リソース制約: [人員やインフラリソースの制約] +- 技術制約: [技術的な制約] +- 法規制・コンプライアンス: [該当する法規制] + +### 1.5 クラウドインスタンス特有の考慮事項 + +**【重要】オンプレミスとクラウドのハイブリッド運用**: + +クラウドインスタンスは、オンプレミスと同様の運用が基本ですが、クラウド特有の制限と利点があります。 + +**オンプレミスと同様の運用責任**: +- OS管理（パッチ適用、セキュリティ更新） +- ミドルウェア管理（アップデート、設定変更） +- アプリケーション管理 +- バックアップ・リストア +- 監視設定 + +**クラウドサービスによる制限**: +- ハイパーバイザーレベルの制御不可 +- 物理ハードウェアへのアクセス不可 +- ネットワーク帯域の共有（ノイジーネイバー問題） +- インスタンスタイプによる性能制限 + +**クラウドの利点活用**: +- **柔軟なスケーリング**: Auto Scaling Groupsの活用 +- **高可用性**: マルチAZ配置 +- **マネージドサービスとの組み合わせ**: RDS、ELB等の活用 + +**パッチ管理の考慮**: +- OS・ミドルウェアのパッチ適用計画 +- メンテナンスウィンドウの設定 +- ゴールデンイメージ（AMI等）の管理戦略 + +**コスト管理の考慮**: +- インスタンスの適切なサイジング +- Reserved Instances / Savings Plansの活用 +- 未使用インスタンスの停止・削除 + +--- + +## 2. サービス概要 + +### 2.1 サービスの目的 + +サービスが提供する価値と目的を記載します。 + +**ビジネス目的**: +- [ビジネス上の目的] + +**提供価値**: +- [ユーザーに提供する価値] + +### 2.2 サービスの機能 + +主要な機能を記載します。 + +| 機能名 | 概要 | 重要度 | +|--------|------|--------| +| [機能1] | [機能の説明] | High / Medium / Low | +| [機能2] | [機能の説明] | High / Medium / Low | + +### 2.3 システム構成 + +システムのアーキテクチャと主要コンポーネントを記載します。 + +**アーキテクチャ図**: + +```mermaid +graph TB + subgraph "ユーザー層" + User[エンドユーザー] + end + + subgraph "アプリケーション層" + Web[Webサーバー] + App[アプリケーションサーバー] + end + + subgraph "データ層" + DB[(データベース)] + Cache[(キャッシュ)] + end + + User --> Web + Web --> App + App --> DB + App --> Cache +``` + +**主要コンポーネント**: + +| コンポーネント | 役割 | 技術スタック | 冗長化 | +|----------------|------|--------------|--------| +| [コンポーネント1] | [役割] | [技術] | Yes / No | +| [コンポーネント2] | [役割] | [技術] | Yes / No | + +### 2.4 外部連携 + +外部システムとの連携を記載します。 + +| 連携先 | 連携方式 | データフロー | 重要度 | +|--------|----------|--------------|--------| +| [システム名] | API / Batch / etc | [方向と内容] | High / Medium / Low | + +--- + +## 3. 運用方針と目標 + +### 3.1 運用基本方針 + +運用における基本的な方針を記載します。 + +1. **可用性重視**: [方針の詳細] +2. **セキュリティ優先**: [方針の詳細] +3. **継続的改善**: [方針の詳細] +4. **コスト最適化**: [方針の詳細] + +### 3.2 サービスレベル目標（SLO） + +**【重要】ユーザー中心のSLO設計原則**: + +SLOは「測りやすい指標」ではなく、「ユーザーが快適に使える範囲」を起点として設計します。 + +**設計アプローチ**: +1. **ユーザーの期待値を理解する** + - ユーザーはどの程度の応答速度を期待しているか + - どの程度のエラーなら許容できるか + - サービス停止はどの程度の影響を与えるか + +2. **ユーザー体験に基づいた目標設定** + - 「サーバーCPU使用率」ではなく「ユーザーが体感するレスポンスタイム」 + - 「データベース接続数」ではなく「ユーザーがエラーに遭遇する頻度」 + - 技術指標はユーザー体験指標の裏付けとして使用 + +3. **システム構成ごとの目標設定** + - 同期処理、非同期処理、バッチ処理でユーザー期待値は異なる + - それぞれに適切な目標値を設定 + +**SLO定義**: + +| システム構成/機能 | 指標名 | 目標値 | ユーザー視点での意味 | 測定方法 | 測定頻度 | +|-------------------|--------|--------|---------------------|----------|----------| +| [全体] | 可用性 | [例: 99.9%] | ユーザーがサービスを利用できる時間の割合 | [測定方法] | [頻度] | +| [Web同期リクエスト] | レスポンスタイム（P95） | [例: 500ms以下] | ユーザーが操作後に結果が表示されるまでの体感速度 | [測定方法] | [頻度] | +| [Web同期リクエスト] | エラーレート | [例: 0.1%以下] | ユーザーがエラーに遭遇する頻度 | [測定方法] | [頻度] | +| [非同期APIリクエスト] | 処理完了時間（P95） | [例: 5秒以内] | バックグラウンド処理が完了するまでの時間 | [測定方法] | [頻度] | +| [バッチ処理] | 処理完了時刻 | [例: 翌朝8時まで] | 業務開始時にデータが利用可能になっている状態 | [測定方法] | 日次 | +| [全体] | MTTR | [例: 30分以内] | 障害発生時にユーザーが待つ時間 | [測定方法] | [頻度] | + +### 3.3 サービスレベル指標（SLI） + +SLOを測定するための具体的な指標を記載します。 + +| SLI名 | 定義 | データソース | 計算式 | +|-------|------|--------------|--------| +| [SLI1] | [定義] | [ソース] | [計算式] | +| [SLI2] | [定義] | [ソース] | [計算式] | + +### 3.4 サービスレベル合意（SLA） + +顧客またはユーザーに対して約束するサービス品質の基準を記載します。 + +**SLA策定の重要性**: +- SLOとSLIに基づいた実現可能な目標設定 +- 顧客期待値の明確化 +- サービス品質保証の根拠 +- 違約時の対応方針の明確化 + +**SLA定義**: + +| システム構成/機能 | SLA項目 | 保証値 | 測定方法 | 測定期間 | 未達時の対応 | +|-------------------|---------|--------|----------|----------|-------------| +| [全体] | サービス可用性 | [例: 99.9%] | [測定方法] | 月次 | [対応内容] | +| [Web同期リクエスト] | レスポンスタイム（P95） | [例: 500ms以下] | [測定方法] | 月次 | [対応内容] | +| [非同期APIリクエスト] | 処理完了時間（P95） | [例: 5秒以内] | [測定方法] | 月次 | [対応内容] | +| [バッチ処理] | 処理完了時刻 | [例: 翌朝8時まで] | [測定方法] | 日次 | [対応内容] | + +**システム構成別のSLA設定指針**: + +1. **同期的なWebリクエスト（ユーザー対話操作）** + - ユーザーが快適に操作できる範囲を基準とする + - レスポンスタイム: 一般的に500ms以下（P95） + - エラーレート: 0.1%以下 + +2. **非同期APIリクエスト（バックグラウンド処理）** + - ユーザー体験に直接影響しない範囲で設定 + - 処理完了時間: 数秒〜数十秒 + - 再試行ポリシーを含む + +3. **バッチ処理（夜間処理等）** + - 業務開始時刻までの完了を保証 + - 処理時間: 数時間単位 + - 失敗時の再実行ポリシー + +**SLA未達時のペナルティまたは対応**: +- サービスクレジット: [内容] +- エスカレーション: [プロセス] +- 改善計画の提出: [内容] + +### 3.5 エラーバジェット + +許容されるエラーの範囲を定義します。 + +**エラーバジェット算出**: +- 可用性目標: 99.9% +- 許容ダウンタイム（月間）: [計算結果] +- エラーバジェット消費の閾値: [閾値] + +**エラーバジェットポリシー**: +- エラーバジェット残量 > 50%: [対応方針] +- エラーバジェット残量 20-50%: [対応方針] +- エラーバジェット残量 < 20%: [対応方針] + +--- + +## 4. 運用体制 + +### 4.1 運用組織体制 + +運用組織の体制を記載します。 + +```mermaid +graph TB + Manager[運用マネージャー] + + Manager --> Team1[運用チーム1] + Manager --> Team2[運用チーム2] + Manager --> Team3[SREチーム] + + Team1 --> Ops1[オペレーター1] + Team1 --> Ops2[オペレーター2] + + Team2 --> Ops3[オペレーター3] + Team2 --> Ops4[オペレーター4] + + Team3 --> SRE1[SREエンジニア1] + Team3 --> SRE2[SREエンジニア2] +``` + +### 4.2 役割と責任（RACI） + +主要な運用プロセスにおける役割と責任を記載します。 + +| プロセス/タスク | 運用マネージャー | 運用チーム | SREチーム | 開発チーム | 備考 | +|-----------------|------------------|------------|-----------|------------|------| +| 監視・アラート対応 | A | R | C | I | [備考] | +| インシデント対応 | A | R | C | C | [備考] | +| 変更管理 | A | I | C | R | [備考] | +| リリース管理 | A | C | R | R | [備考] | + +※ R=Responsible（実行責任）, A=Accountable（説明責任）, C=Consulted（相談）, I=Informed（報告） + +### 4.3 運用時間帯 + +運用体制の時間帯を記載します。 + +| 時間帯 | 運用体制 | 対応内容 | +|--------|----------|----------| +| 平日 9:00-18:00 | 通常体制 | [対応内容] | +| 平日 18:00-9:00 | オンコール体制 | [対応内容] | +| 休日・祝日 | オンコール体制 | [対応内容] | + +**オンコール体制**: +- 1次対応: [担当者・連絡先] +- 2次対応: [担当者・連絡先] +- エスカレーション先: [担当者・連絡先] + +### 4.4 コミュニケーション + +運用における コミュニケーション方法を記載します。 + +**定例会議**: + +| 会議名 | 頻度 | 参加者 | 目的 | +|--------|------|--------|------| +| 日次運用会議 | 毎日 | [参加者] | [目的] | +| 週次運用レビュー | 毎週 | [参加者] | [目的] | +| 月次運用報告 | 毎月 | [参加者] | [目的] | + +**コミュニケーションツール**: +- チャット: [ツール名・チャンネル] +- チケット管理: [ツール名] +- ドキュメント共有: [ツール名] +- インシデント管理: [ツール名] + +--- + +## 5. 運用スケジュール + +### 5.1 定期運用スケジュール + +定期的に実施する運用作業のスケジュールを記載します。 + +| 作業項目 | 頻度 | 実施日時 | 担当 | 所要時間 | +|----------|------|----------|------|----------| +| [作業1] | 日次 | [時刻] | [担当] | [時間] | +| [作業2] | 週次 | [曜日・時刻] | [担当] | [時間] | +| [作業3] | 月次 | [日・時刻] | [担当] | [時間] | + +### 5.2 メンテナンスウィンドウ + +計画メンテナンスの実施可能時間帯を記載します。 + +**定期メンテナンス**: +- 頻度: [週次/月次/四半期等] +- 実施日時: [曜日・時刻] +- 所要時間: [時間] +- 影響範囲: [影響内容] + +**緊急メンテナンス**: +- 実施判断基準: [基準] +- 承認プロセス: [プロセス] +- 通知方法: [通知手段] + +### 5.3 年間運用カレンダー + +年間の主要イベントとメンテナンススケジュールを記載します。 + +| 月 | イベント/作業 | 詳細 | +|----|---------------|------| +| 1月 | [イベント] | [詳細] | +| 2月 | [イベント] | [詳細] | +| ... | ... | ... | + +--- + +## 6. 定常運用作業 + +### 6.1 日次運用作業 + +毎日実施する運用作業を記載します。 + +#### 7.1.1 [作業名1] + +**目的**: [作業の目的] + +**実施タイミング**: [時刻] + +**手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +**確認項目**: +- [ ] [確認項目1] +- [ ] [確認項目2] + +**成果物**: [成果物があれば記載] + +**エスカレーション基準**: [異常時の対応] + +#### 7.1.2 [作業名2] + +[同様の形式で記載] + +### 6.2 週次運用作業 + +週単位で実施する運用作業を記載します。 + +#### 7.2.1 [作業名] + +[日次作業と同様の形式で記載] + +### 6.3 月次運用作業 + +月単位で実施する運用作業を記載します。 + +#### 7.3.1 [作業名] + +[日次作業と同様の形式で記載] + +--- + +## 7. 監視・通知 + +### 7.1 監視方針 + +**【重要】ユーザー中心の監視設計原則**: + +監視は「測りやすい技術指標」ではなく、「ユーザーが快適に使える状態」を維持するために実施します。 + +**監視設計アプローチ**: + +1. **ユーザー体験起点の監視** + - まず「ユーザーが体感する品質」を監視 + - 技術指標はユーザー体験指標が悪化した時の原因特定に使用 + - 例: レスポンスタイムの悪化を検知 → CPU使用率を確認して原因を特定 + +2. **外形監視を最優先** + - ユーザーと同じ視点でサービスを監視 + - エンドツーエンドの動作確認 + - 実際のユーザートランザクションをシミュレート + +3. **システム構成ごとの監視基準** + - 同期処理、非同期処理、バッチ処理で監視基準を分ける + - それぞれのユーザー期待値に基づいた閾値設定 + +**監視の目的**: +- **第一目的**: ユーザーが快適に利用できる状態の維持 +- サービスの可用性確保 +- パフォーマンス劣化の早期検知（ユーザー体感品質の観点から） +- セキュリティインシデントの検知 +- キャパシティ不足の予兆検知 + +**監視レベル**: +- レベル1（Critical）: ユーザーに直接影響がある状態 [具体的な定義と対応] +- レベル2（Warning）: ユーザーへ影響が及ぶ可能性のある状態 [具体的な定義と対応] +- レベル3（Info）: ユーザーに影響はないが注視すべき状態 [具体的な定義と対応] + +### 7.2 監視項目 + +**【重要】監視項目の優先順位**: + +**優先度1: ユーザー体験監視（SLI直結）** +- ユーザーが直接体感する品質指標 +- これらが正常であればサービスは正常 + +**優先度2: アプリケーション監視** +- ユーザー体験指標の裏付け +- 問題発生時の原因特定用 + +**優先度3: インフラ監視** +- アプリケーション指標の裏付け +- キャパシティ管理用 + +**監視項目定義**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 1 | 外形監視（Web同期） | レスポンスタイム（P95） | 500ms超 | 1分 | Warning | ユーザーが遅いと感じる | +| 1 | 外形監視（Web同期） | レスポンスタイム（P95） | 1000ms超 | 1分 | Critical | ユーザーがストレスを感じる | +| 1 | 外形監視（Web同期） | エラーレート | 0.1%超 | 1分 | Warning | ユーザーがエラーに遭遇し始める | +| 1 | 外形監視（Web同期） | エラーレート | 1%超 | 1分 | Critical | 多数のユーザーがエラーに遭遇 | +| 1 | 外形監視（非同期API） | 処理完了時間（P95） | 5秒超 | 5分 | Warning | バックグラウンド処理の遅延 | +| 1 | 外形監視（バッチ） | 処理完了時刻 | 7:00以降 | 1時間 | Warning | 業務開始に間に合わない可能性 | +| 1 | 外形監視（バッチ） | 処理完了時刻 | 8:00以降 | 1時間 | Critical | 業務開始に間に合わない | +| 2 | アプリケーション | エラーレート | [閾値] | 1分 | [レベル] | アプリケーションレベルのエラー発生状況 | +| 2 | アプリケーション | レスポンスタイム | [閾値] | 1分 | [レベル] | アプリケーション処理時間 | +| 3 | Webサーバー | CPU使用率 | 80%超 | 1分 | Info | リソース逼迫の予兆 | +| 3 | Webサーバー | CPU使用率 | 90%超 | 1分 | Warning | リソース逼迫 | +| 3 | Webサーバー | メモリ使用率 | [閾値] | [間隔] | [レベル] | メモリリソース状況 | +| 3 | データベース | 接続数 | [閾値] | [間隔] | [レベル] | DB接続リソース状況 | + +**システム構成別の監視設計**: + +1. **同期的なWebリクエスト** + - ユーザーは即座に結果を期待 + - レスポンスタイム: P95で500ms以下を目標 + - 監視間隔: 1分（迅速な検知が必要） + +2. **非同期APIリクエスト** + - ユーザーは数秒の待機は許容 + - 処理完了時間: P95で5秒以内を目標 + - 監視間隔: 5分（ある程度の猶予あり） + +3. **バッチ処理** + - ユーザーは完了時刻を期待 + - 処理完了時刻: 業務開始時刻まで + - 監視間隔: 1時間（処理時間が長いため） + +### 7.3 ログ管理 + +ログの収集・保管・分析方針を記載します。 + +**ログ種類**: + +| ログ種類 | 出力先 | 保管期間 | 用途 | +|----------|--------|----------|------| +| アクセスログ | [保存先] | [期間] | [用途] | +| アプリケーションログ | [保存先] | [期間] | [用途] | +| エラーログ | [保存先] | [期間] | [用途] | +| セキュリティログ | [保存先] | [期間] | [用途] | + +**ログ分析**: +- ツール: [ツール名] +- 分析頻度: [頻度] +- 分析内容: [内容] + +### 7.4 アラート通知 + +アラート通知のルールと方法を記載します。 + +**通知ルート**: + +```mermaid +graph LR + Alert[アラート発生] --> Level{レベル判定} + + Level -->|Critical| Notify1[即時通知
電話+メール+チャット] + Level -->|Warning| Notify2[メール+チャット] + Level -->|Info| Notify3[チャットのみ] + + Notify1 --> Oncall[オンコール担当] + Notify2 --> Team[運用チーム] + Notify3 --> Log[ログ記録] +``` + +**通知先**: + +| アラートレベル | 通知方法 | 通知先 | 対応時間 | +|----------------|----------|--------|----------| +| Critical | 電話+メール+チャット | [通知先] | 即時 | +| Warning | メール+チャット | [通知先] | 30分以内 | +| Info | チャット | [通知先] | 営業時間内 | + +--- + +## 8. インシデント管理 + +### 8.1 インシデント定義 + +インシデントの定義と分類を記載します。 + +**インシデント定義**: +サービスの計画外の中断、またはサービス品質の低下 + +**インシデント分類**: + +| 優先度 | 定義 | 対応目標時間 | 例 | +|--------|------|--------------|-----| +| P1（Critical） | サービス全停止 | 15分以内に対応開始 | [例] | +| P2（High） | 主要機能停止 | 30分以内に対応開始 | [例] | +| P3（Medium） | 一部機能停止 | 2時間以内に対応開始 | [例] | +| P4（Low） | 軽微な問題 | 営業時間内対応 | [例] | + +### 8.2 インシデント対応フロー + +インシデント対応の標準フローを記載します。 + +```mermaid +graph TD + Start[インシデント検知] --> Triage[トリアージ] + Triage --> Priority{優先度判定} + + Priority -->|P1/P2| Urgent[緊急対応] + Priority -->|P3/P4| Normal[通常対応] + + Urgent --> Investigate1[原因調査] + Normal --> Investigate2[原因調査] + + Investigate1 --> Fix1[復旧作業] + Investigate2 --> Fix2[修正作業] + + Fix1 --> Verify1[動作確認] + Fix2 --> Verify2[動作確認] + + Verify1 --> Close1[インシデントクローズ] + Verify2 --> Close2[インシデントクローズ] + + Close1 --> Postmortem[ポストモーテム] + Close2 --> Review[レビュー] +``` + +### 8.3 インシデント対応手順 + +インシデント対応の詳細手順を記載します。 + +#### 9.3.1 検知・報告 + +**検知方法**: +- 監視アラート +- ユーザー報告 +- 運用チーム発見 + +**報告フロー**: +1. インシデント管理ツールにチケット作成 +2. 運用チームに通知 +3. 優先度に応じてエスカレーション + +#### 9.3.2 トリアージ + +**トリアージ基準**: +- 影響範囲（全ユーザー / 一部ユーザー / 特定機能） +- ビジネスインパクト（売上損失 / 信用失墜 / 軽微） +- 緊急度（即時対応必要 / 計画的対応可能） + +**優先度判定**: +[優先度判定のマトリクスやルール] + +#### 9.3.3 対応・復旧 + +**対応原則**: +1. まず復旧、原因究明は後 +2. 影響範囲の最小化を優先 +3. コミュニケーションを密に + +**復旧手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +#### 9.3.4 ポストモーテム + +**実施タイミング**: +- P1/P2インシデント: 必須 +- P3インシデント: 必要に応じて +- P4インシデント: 任意 + +**ポストモーテム内容**: +- インシデントサマリー +- 影響範囲と期間 +- 根本原因分析（なぜなぜ分析） +- 再発防止策 +- アクションアイテム + +### 8.4 エスカレーション + +エスカレーションルールを記載します。 + +**エスカレーション基準**: +- 対応開始から[X]分経過しても復旧しない +- 影響範囲が拡大している +- 技術的な判断が必要 +- ビジネス判断が必要 + +**エスカレーションパス**: + +```mermaid +graph TB + L1[L1: 運用担当者] -->|15分| L2[L2: 運用リーダー] + L2 -->|30分| L3[L3: 運用マネージャー] + L3 -->|60分| L4[L4: 開発チーム] + L3 -->|重大影響| L5[L5: 経営層] +``` + +--- + +## 9. 変更管理 + +### 9.1 変更管理方針 + +変更管理の基本方針を記載します。 + +**変更管理の目的**: +- 変更に伴うリスクの最小化 +- 変更の影響評価と承認プロセスの明確化 +- 変更履歴の記録と追跡可能性の確保 + +**変更の定義**: +本番環境への以下の変更を対象とします +- システム構成の変更 +- アプリケーションのデプロイ +- インフラ設定の変更 +- セキュリティ設定の変更 + +### 9.2 変更分類 + +変更の種類と承認プロセスを記載します。 + +| 変更分類 | 定義 | 承認者 | リードタイム | +|----------|------|--------|--------------| +| 標準変更 | 手順化済みの低リスク変更 | 運用リーダー | 即時 | +| 通常変更 | 一般的な変更 | 運用マネージャー | 3営業日 | +| 緊急変更 | 緊急対応が必要な変更 | 運用マネージャー | 即時 | +| 重要変更 | 高リスクまたは大規模な変更 | 変更諮問委員会 | 1週間 | + +### 9.3 変更管理フロー + +変更管理のプロセスを記載します。 + +```mermaid +graph TD + Request[変更要求] --> Classification{変更分類} + + Classification -->|標準| Approve1[自動承認] + Classification -->|通常| Review1[レビュー] + Classification -->|緊急| Review2[緊急レビュー] + Classification -->|重要| CAB[CAB審査] + + Review1 --> Approve2[承認] + Review2 --> Approve3[承認] + CAB --> Approve4[承認] + + Approve1 --> Plan[実施計画] + Approve2 --> Plan + Approve3 --> Plan + Approve4 --> Plan + + Plan --> Implement[変更実施] + Implement --> Verify[検証] + Verify --> Close[クローズ] + + Verify -->|失敗| Rollback[ロールバック] + Rollback --> Review3[原因分析] +``` + +### 9.4 変更実施手順 + +変更を実施する際の標準手順を記載します。 + +**事前準備**: +1. 変更チケットの作成 +2. 変更内容の詳細記載 +3. 影響評価の実施 +4. ロールバック計画の作成 +5. 承認取得 + +**実施時**: +1. 事前バックアップの取得 +2. 変更作業の実施 +3. 作業ログの記録 +4. 動作確認の実施 + +**事後**: +1. 変更結果の報告 +2. ドキュメントの更新 +3. チケットのクローズ + +### 9.5 ロールバック計画 + +ロールバックの基準と手順を記載します。 + +**ロールバック判断基準**: +- 変更後の動作確認でエラーが検出された +- SLOを下回る性能劣化が発生した +- 予期しない副作用が発生した +- [その他の基準] + +**ロールバック手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +--- + +## 10. リリース管理 + +### 10.1 リリース方針 + +リリースの基本方針を記載します。 + +**リリース原則**: +- 定期リリースと緊急リリースの明確な区別 +- 本番環境へのリリース前の十分なテスト +- 段階的なロールアウト（カナリアリリース等） +- 自動化されたデプロイメントプロセス + +### 10.2 リリーススケジュール + +定期リリースのスケジュールを記載します。 + +| リリース種別 | 頻度 | 実施日時 | 対象 | +|--------------|------|----------|------| +| メジャーリリース | 四半期毎 | [日時] | 大規模機能追加 | +| マイナーリリース | 月次 | [日時] | 機能改善 | +| パッチリリース | 週次 | [日時] | バグフィックス | +| ホットフィックス | 随時 | 随時 | 緊急対応 | + +### 10.3 リリースフロー + +リリースプロセスを記載します。 + +```mermaid +graph LR + Dev[開発環境] --> Test[テスト環境] + Test --> Staging[ステージング環境] + Staging --> Canary[カナリア環境] + Canary --> Prod[本番環境] + + Test -.->|NG| Dev + Staging -.->|NG| Dev + Canary -.->|NG| Rollback[ロールバック] +``` + +**各環境の役割**: +- 開発環境: 機能開発とユニットテスト +- テスト環境: 結合テストと品質保証 +- ステージング環境: 本番環境と同等構成での最終確認 +- カナリア環境: 一部ユーザーでの先行リリース +- 本番環境: 全ユーザー向けリリース + +### 10.4 デプロイメント戦略 + +デプロイメント方式を記載します。 + +**採用戦略**: [選択した戦略] + +**デプロイメント方式の比較**: + +| 方式 | メリット | デメリット | 採用判断 | +|------|----------|------------|----------| +| Blue-Green | ダウンタイムゼロ | リソース2倍必要 | [○/×] | +| Rolling | リソース効率的 | 段階的な切り替え | [○/×] | +| Canary | リスク最小化 | 複雑な制御必要 | [○/×] | + +**自動化ツール**: +- CI/CDツール: [ツール名] +- デプロイツール: [ツール名] +- インフラ管理: [ツール名] + +--- + +## 11. バックアップ・リカバリ + +### 11.1 バックアップ方針 + +バックアップの基本方針を記載します。 + +**バックアップ目的**: +- データ損失時の復旧 +- ランサムウェア等のセキュリティインシデント対応 +- 監査・コンプライアンス要件への対応 + +**バックアップ原則**: +- 3-2-1ルール: 3つのコピー、2つの異なるメディア、1つはオフサイト +- 暗号化されたバックアップの保管 +- 定期的なリストアテストの実施 + +### 11.2 バックアップ設計 + +バックアップ対象と方式を記載します。 + +| バックアップ対象 | バックアップ方式 | 頻度 | 世代管理 | 保管場所 | +|------------------|------------------|------|----------|----------| +| データベース | フル+差分 | 日次フル+6時間毎差分 | 30世代 | [場所] | +| ファイルストレージ | フル | 日次 | 7世代 | [場所] | +| システム設定 | フル | 変更時 | 10世代 | [場所] | +| ログファイル | 増分 | 1時間毎 | 90日 | [場所] | + +**バックアップスケジュール**: + +```mermaid +gantt + title バックアップスケジュール（1日） + dateFormat HH:mm + axisFormat %H:%M + + section データベース + フルバックアップ :00:00, 2h + 差分バックアップ1 :06:00, 30m + 差分バックアップ2 :12:00, 30m + 差分バックアップ3 :18:00, 30m + + section ファイル + フルバックアップ :02:00, 1h +``` + +### 11.3 リカバリ設計 + +リカバリの目標値と手順を記載します。 + +**リカバリ目標**: + +| 対象 | RPO（目標復旧時点） | RTO（目標復旧時間） | +|------|---------------------|---------------------| +| データベース | 6時間以内 | 4時間以内 | +| ファイルストレージ | 24時間以内 | 2時間以内 | +| システム全体 | 24時間以内 | 8時間以内 | + +**リカバリ手順**: + +#### データベースリカバリ +1. [手順1] +2. [手順2] +3. [手順3] + +**リカバリテスト**: +- 頻度: 四半期毎 +- 対象: [テスト対象] +- 成功基準: [基準] + +### 11.4 災害対策（DR） + +災害復旧計画を記載します。 + +**DR方針**: +- DR サイト: [有/無] +- DR 構成: [Hot Standby / Warm Standby / Cold Standby] + +**DR切り替えシナリオ**: + +| シナリオ | 発生条件 | 切り替え判断 | 切り替え時間目標 | +|----------|----------|--------------|------------------| +| データセンター障害 | [条件] | [判断基準] | [時間] | +| リージョン障害 | [条件] | [判断基準] | [時間] | + +--- + +## 12. セキュリティ運用 + +### 12.1 セキュリティ運用方針 + +セキュリティ運用の基本方針を記載します。 + +**セキュリティ原則**: +- 多層防御（Defense in Depth） +- 最小権限の原則 +- ゼロトラストアーキテクチャ +- 継続的なセキュリティ監視 + +### 12.2 アクセス管理 + +アクセス権限の管理方針を記載します。 + +**権限管理**: + +| ロール | 権限範囲 | 承認者 | レビュー頻度 | +|--------|----------|--------|--------------| +| システム管理者 | 全権限 | [承認者] | 月次 | +| 運用担当者 | 運用操作のみ | [承認者] | 月次 | +| 開発者 | 開発環境のみ | [承認者] | 月次 | +| 閲覧者 | 読み取りのみ | [承認者] | 四半期 | + +**アクセスレビュー**: +- 頻度: [頻度] +- 実施者: [担当者] +- レビュー内容: [内容] + +### 12.3 脆弱性管理 + +脆弱性の検出と対応プロセスを記載します。 + +**脆弱性スキャン**: +- ツール: [ツール名] +- 頻度: [頻度] +- 対象: [対象システム] + +**パッチ適用**: + +| 脆弱性レベル | 対応期限 | 承認プロセス | +|--------------|----------|--------------| +| Critical | 24時間以内 | 緊急変更 | +| High | 7日以内 | 通常変更 | +| Medium | 30日以内 | 通常変更 | +| Low | 90日以内 | 計画変更 | + +### 12.4 セキュリティインシデント対応 + +セキュリティインシデントの対応手順を記載します。 + +**セキュリティインシデント分類**: + +| レベル | 定義 | 例 | 対応時間 | +|--------|------|-----|----------| +| L1 | 重大な侵害 | データ漏洩、ランサムウェア | 即時 | +| L2 | 侵害の疑い | 不正アクセス試行 | 1時間以内 | +| L3 | セキュリティ違反 | ポリシー違反 | 24時間以内 | + +**対応フロー**: + +```mermaid +graph TD + Detect[検知] --> Contain[封じ込め] + Contain --> Eradicate[根絶] + Eradicate --> Recover[復旧] + Recover --> PostIncident[事後対応] + PostIncident --> Improve[改善] +``` + +**インシデント対応チーム（CSIRT）**: +- リーダー: [担当者] +- メンバー: [担当者リスト] +- 外部連絡先: [セキュリティベンダー、警察等] + +### 12.5 コンプライアンス + +法規制・コンプライアンス要件への対応を記載します。 + +**適用法規制**: +- [法規制名]: [要件概要] +- [法規制名]: [要件概要] + +**監査対応**: +- 内部監査: [頻度・実施者] +- 外部監査: [頻度・監査法人] +- 証跡管理: [保管方法・期間] + +--- + +## 13. キャパシティ管理 + +### 13.1 キャパシティ管理方針 + +キャパシティ管理の基本方針を記載します。 + +**キャパシティ管理の目的**: +- サービス品質の維持 +- コストの最適化 +- 将来の需要予測と計画 + +### 13.2 キャパシティ監視 + +監視対象リソースと閾値を記載します。 + +| リソース | 現在の使用率 | 警告閾値 | 限界閾値 | 対応アクション | +|----------|--------------|----------|----------|----------------| +| CPU | [%] | 70% | 85% | [アクション] | +| メモリ | [%] | 75% | 90% | [アクション] | +| ディスク | [%] | 80% | 90% | [アクション] | +| ネットワーク帯域 | [%] | 70% | 85% | [アクション] | + +### 13.3 キャパシティ計画 + +将来の需要予測と増強計画を記載します。 + +**需要予測**: + +| 期間 | 予想ユーザー数 | 予想トラフィック | 必要リソース | +|------|----------------|------------------|--------------| +| 3ヶ月後 | [数値] | [数値] | [内容] | +| 6ヶ月後 | [数値] | [数値] | [内容] | +| 1年後 | [数値] | [数値] | [内容] | + +**増強計画**: +- 実施時期: [時期] +- 増強内容: [内容] +- 見積もりコスト: [金額] + +### 13.4 スケーリング戦略 + +スケーリングの方針と実装を記載します。 + +**スケーリング方式**: +- 垂直スケーリング（スケールアップ）: [適用箇所] +- 水平スケーリング（スケールアウト）: [適用箇所] + +**オートスケーリング設定**: + +| 対象 | スケールアウト条件 | スケールイン条件 | 最小/最大インスタンス数 | +|------|-------------------|------------------|------------------------| +| [対象1] | [条件] | [条件] | [最小数]/[最大数] | +| [対象2] | [条件] | [条件] | [最小数]/[最大数] | + +--- + +## 14. コスト管理 + +### 14.1 コスト管理方針 + +コスト管理の基本方針を記載します。 + +**コスト管理の目的**: +- 予算内での運用実現 +- コスト効率の最適化 +- コスト可視化と予測 + +### 14.2 コスト構造 + +運用コストの内訳を記載します。 + +| コスト項目 | 月額コスト | 年額コスト | 備考 | +|------------|------------|------------|------| +| インフラコスト | [金額] | [金額] | [内訳] | +| ライセンスコスト | [金額] | [金額] | [内訳] | +| 人件費 | [金額] | [金額] | [内訳] | +| 外部委託費 | [金額] | [金額] | [内訳] | +| その他 | [金額] | [金額] | [内訳] | +| **合計** | [金額] | [金額] | | + +### 14.3 コスト最適化施策 + +コスト削減・最適化の取り組みを記載します。 + +**実施中の施策**: +1. [施策1]: [効果] +2. [施策2]: [効果] + +**計画中の施策**: +1. [施策1]: [期待効果] +2. [施策2]: [期待効果] + +### 14.4 コスト監視 + +コストの監視とアラート設定を記載します。 + +**コスト監視**: +- ツール: [ツール名] +- 監視頻度: [頻度] +- レポート: [頻度・宛先] + +**コストアラート**: +- 月次予算超過アラート: [閾値] +- 異常なコスト増加アラート: [条件] + +--- + +## 15. 問題管理 + +### 15.1 問題管理方針 + +問題管理の基本方針を記載します。 + +**問題の定義**: +1つ以上のインシデントの根本原因、または潜在的なインシデントの原因 + +**問題管理の目的**: +- インシデントの根本原因の特定と除去 +- 既知のエラーの記録と回避策の提供 +- 再発防止策の実装 + +### 15.2 問題管理プロセス + +問題管理のフローを記載します。 + +```mermaid +graph TD + Incident[インシデント発生] --> Analysis[傾向分析] + Analysis --> Problem{問題として
管理すべきか？} + + Problem -->|Yes| Register[問題登録] + Problem -->|No| End1[終了] + + Register --> Investigate[根本原因分析] + Investigate --> Known[既知のエラー登録] + + Known --> Workaround[回避策の提供] + Known --> Solution[恒久対策の検討] + + Solution --> Implement[対策実装] + Implement --> Verify[効果検証] + Verify --> Close[クローズ] +``` + +### 15.3 既知のエラー管理 + +既知のエラーと回避策を記録します。 + +| エラーID | 問題概要 | 影響 | 回避策 | 恒久対策の状況 | +|----------|----------|------|--------|----------------| +| KE-001 | [概要] | [影響] | [回避策] | [状況] | +| KE-002 | [概要] | [影響] | [回避策] | [状況] | + +--- + +## 16. ナレッジ管理 + +### 16.1 ナレッジ管理方針 + +ナレッジの蓄積と共有の方針を記載します。 + +**ナレッジ管理の目的**: +- 運用ノウハウの蓄積と継承 +- 問題解決の効率化 +- 属人化の排除 + +### 16.2 ドキュメント体系 + +管理するドキュメントの種類と保管場所を記載します。 + +| ドキュメント種別 | 保管場所 | 更新頻度 | 管理者 | +|------------------|----------|----------|--------| +| 運用設計書 | [場所] | [頻度] | [担当] | +| 運用手順書 | [場所] | [頻度] | [担当] | +| 障害対応手順書 | [場所] | [頻度] | [担当] | +| FAQ | [場所] | [頻度] | [担当] | +| ポストモーテム | [場所] | 都度 | [担当] | + +### 16.3 ドキュメント管理ルール + +ドキュメントの作成・更新・レビューのルールを記載します。 + +**作成ルール**: +- テンプレートの使用 +- 命名規則の遵守 +- バージョン管理の実施 + +**更新ルール**: +- 変更履歴の記録 +- レビュープロセスの実施 +- 関連ドキュメントの同期更新 + +**レビュープロセス**: +- レビュー頻度: [頻度] +- レビュー担当: [担当者] +- レビュー基準: [基準] + +--- + +## 17. 継続的改善 + +### 17.1 改善活動方針 + +継続的改善の基本方針を記載します。 + +**改善の原則**: +- データドリブンな意思決定 +- 小さな改善の積み重ね +- チーム全体での取り組み +- 定期的な振り返りと学び + +### 17.2 改善プロセス + +改善活動のサイクルを記載します。 + +```mermaid +graph LR + Plan[計画
Plan] --> Do[実行
Do] + Do --> Check[評価
Check] + Check --> Act[改善
Act] + Act --> Plan +``` + +**改善活動の実施**: +- 週次: チーム振り返り +- 月次: メトリクスレビュー +- 四半期: 運用プロセスレビュー +- 年次: 運用戦略レビュー + +### 17.3 運用メトリクス + +運用品質を測定する指標を記載します。 + +| メトリクス | 目標値 | 測定方法 | レポート頻度 | +|------------|--------|----------|--------------| +| 可用性 | 99.9%以上 | [方法] | 月次 | +| MTBF（平均故障間隔） | [目標] | [方法] | 月次 | +| MTTR（平均復旧時間） | 30分以内 | [方法] | 月次 | +| 変更成功率 | 95%以上 | [方法] | 月次 | +| インシデント件数 | [目標] | [方法] | 月次 | +| デプロイ頻度 | [目標] | [方法] | 月次 | + +### 17.4 改善施策管理 + +改善施策の管理方法を記載します。 + +**改善施策リスト**: + +| 施策ID | 施策名 | 目的 | 担当 | 期限 | ステータス | +|--------|--------|------|------|------|------------| +| IMP-001 | [施策名] | [目的] | [担当] | [期限] | [ステータス] | +| IMP-002 | [施策名] | [目的] | [担当] | [期限] | [ステータス] | + +--- + +## 18. 運用ツール + +### 18.1 運用ツール一覧 + +使用する運用ツールを記載します。 + +| カテゴリ | ツール名 | 用途 | ライセンス | 管理者 | +|----------|----------|------|------------|--------| +| 監視 | [ツール名] | [用途] | [ライセンス] | [担当] | +| ログ管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| インシデント管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| 変更管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| CI/CD | [ツール名] | [用途] | [ライセンス] | [担当] | +| コミュニケーション | [ツール名] | [用途] | [ライセンス] | [担当] | + +### 18.2 ツール統合 + +ツール間の連携を記載します。 + +**統合フロー**: + +```mermaid +graph LR + Monitor[監視ツール] -->|アラート| Incident[インシデント管理] + Incident -->|通知| Chat[チャットツール] + Chat -->|トリガー| CICD[CI/CDツール] + CICD -->|ログ| LogTool[ログ管理ツール] + LogTool -->|メトリクス| Monitor +``` + +--- + +## 19. 付録 + +### 19.1 用語集 + +本ドキュメントで使用する用語の定義を記載します。 + +| 用語 | 定義 | +|------|------| +| SLO | Service Level Objective: サービスレベル目標 | +| SLI | Service Level Indicator: サービスレベル指標 | +| SLA | Service Level Agreement: サービスレベル合意 | +| MTTR | Mean Time To Repair: 平均復旧時間 | +| MTBF | Mean Time Between Failures: 平均故障間隔 | +| RPO | Recovery Point Objective: 目標復旧時点 | +| RTO | Recovery Time Objective: 目標復旧時間 | +| RACI | Responsible, Accountable, Consulted, Informed | + +### 19.2 参照ドキュメント + +関連ドキュメントへのリンクを記載します。 + +| ドキュメント名 | 場所/URL | 備考 | +|----------------|----------|------| +| システム設計書 | [リンク] | [備考] | +| セキュリティポリシー | [リンク] | [備考] | +| 運用手順書 | [リンク] | [備考] | + +### 19.3 連絡先 + +運用に関わる主要な連絡先を記載します。 + +| 役割 | 担当者 | 連絡先 | 対応時間 | +|------|--------|--------|----------| +| 運用マネージャー | [名前] | [連絡先] | [時間] | +| オンコール担当 | [名前] | [連絡先] | 24/365 | +| セキュリティ担当 | [名前] | [連絡先] | [時間] | + +### 19.4 承認 + +本ドキュメントの承認記録を記載します。 + +| 役割 | 氏名 | 承認日 | 署名 | +|------|------|--------|------| +| 作成者 | [名前] | [日付] | | +| レビュアー | [名前] | [日付] | | +| 承認者 | [名前] | [日付] | | + +--- + +## 運用設計書作成時の注意事項 + +本テンプレートを使用する際は、以下の点に注意してください： + +1. **プロジェクト特性に応じたカスタマイズ** + - すべてのセクションが必要とは限りません + - プロジェクトの規模や性質に応じて取捨選択してください + +2. **具体性の確保** + - 抽象的な記述ではなく、具体的な数値や手順を記載してください + - 「適切に」「十分に」などの曖昧な表現は避けてください + +3. **測定可能性** + - 目標値は測定可能な形で定義してください + - 測定方法も明記してください + +4. **継続的な更新** + - 運用開始後も定期的に見直し、更新してください + - 実態との乖離が生じないよう注意してください + +5. **ステークホルダーの合意** + - 関係者全員で内容を確認し、合意を形成してください + - 特にSLOや運用体制については十分な議論が必要です diff --git a/skills/operations-design/assets/templates/operations_design_template_cloud_native_ja.md b/skills/operations-design/assets/templates/operations_design_template_cloud_native_ja.md new file mode 100644 index 0000000..846c84c --- /dev/null +++ b/skills/operations-design/assets/templates/operations_design_template_cloud_native_ja.md @@ -0,0 +1,2223 @@ +# 運用設計書（クラウドネイティブ/サーバレス/Kubernetes対応） + +## ドキュメント情報 + +| 項目 | 内容 | +|------|------| +| ドキュメント名 | [サービス名] 運用設計書 | +| インフラパターン | **クラウドネイティブ（サーバレス/Kubernetes）** | +| バージョン | [バージョン番号] | +| 作成日 | [YYYY-MM-DD] | +| 最終更新日 | [YYYY-MM-DD] | +| 作成者 | [作成者名] | +| 承認者 | [承認者名] | +| ステータス | [Draft / Review / Approved] | + +**このテンプレートの適用対象**: +- サーバレスアーキテクチャ（Lambda, Cloud Functions, Cloud Run等） +- Kubernetes環境（EKS, GKE, AKS, 自前K8s等） +- マネージドサービス中心の構成 +- コンテナベースのアプリケーション + +## 改訂履歴 + +| バージョン | 日付 | 変更内容 | 変更者 | +|------------|------|----------|--------| +| 0.1 | YYYY-MM-DD | 初版作成 | [名前] | + +--- + +## 1. 概要 + +### 1.1 目的 + +本ドキュメントの目的を記載します。 + +- 運用に求められる要件の明確化 +- システム運用に関わる関係者間の合意形成 +- 運用プロセスの標準化と最適化 +- 運用品質の向上と継続的改善 + +### 1.2 対象範囲 + +本運用設計書が対象とするシステム・サービスの範囲を記載します。 + +**対象システム**: +- [システム名・サービス名] + +**対象業務**: +- [業務名] + +**対象期間**: +- [運用開始予定日] ～ [運用終了予定日（該当する場合）] + +### 1.3 前提条件 + +運用設計における前提条件を記載します。 + +- システム開発が完了していること +- 運用環境が構築されていること +- 運用チームの体制が整っていること +- [その他の前提条件] + +### 1.4 制約条件 + +運用における制約事項を記載します。 + +- 予算制約: [金額や制約内容] +- リソース制約: [人員やインフラリソースの制約] +- 技術制約: [技術的な制約] +- 法規制・コンプライアンス: [該当する法規制] + +### 1.5 クラウドネイティブ特有の考慮事項 + +**【重要】責任共有モデル**: + +クラウドサービスでは、クラウドプロバイダーと利用者の間で運用責任が分担されます。 + +| 責任範囲 | クラウドプロバイダーの責任 | 利用者の責任 | +|---------|--------------------------|-------------| +| **インフラ** | 物理インフラ、ネットワーク、ハイパーバイザー | - | +| **マネージドサービス** | サービスの可用性、パッチ適用、スケーリング | サービス設定、アクセス制御 | +| **コンテナ/K8s** | コントロールプレーン（マネージドの場合） | アプリケーションコンテナ、Pod設計、ワークロード管理 | +| **サーバレス** | 関数実行環境、スケーリング、可用性 | 関数コード、設定、イベント設計 | +| **データ** | ストレージの冗長化、バックアップ機能提供 | データ保護設定、暗号化、バックアップ取得 | +| **セキュリティ** | インフラレベルのセキュリティ | アプリケーションレベルのセキュリティ、IAM、ネットワーク設計 | + +**クラウドサービスのSLAへの依存**: +- 利用するマネージドサービスの SLAを確認し、サービス全体のSLO設計に反映 +- 例: RDS（99.95%）、Lambda（99.95%）、S3（99.99%） +- 複数サービスの組み合わせによるSLOへの影響を計算 + +**コスト最適化の考慮**: +- オンデマンドリソースの適切な設定（タイムアウト、メモリサイズ等） +- 未使用リソースの自動削減 +- Reserved Instances / Savings Plansの活用 + +**ベンダーロックインのリスク**: +- クラウド特有のサービスへの依存度 +- マルチクラウド/ハイブリッドクラウド戦略の有無 + +**コンテナ・Kubernetes運用の考慮事項**: +- **コンテナイメージ管理**: + - イメージレジストリ: ECR/GCR/ACR/DockerHub + - イメージスキャン: Trivy/Clair/Snyk等による脆弱性検査頻度 + - イメージライフサイクル: 保管期間、削除ポリシー、タグ戦略 + - ベースイメージの更新ポリシー: セキュリティパッチ適用のサイクル + +- **Kubernetes特有の運用課題**: + - クラスタバージョン管理: マネージドK8sのアップグレード戦略（インプレース/ブルーグリーン） + - Podのライフサイクル管理: Liveness Probe、Readiness Probe、Startup Probeの設計 + - リソース制限: Requests/Limitsの適切な設定とQoS（Guaranteed/Burstable/BestEffort） + - ノードのメンテナンス: ノードのドレイン・交換手順、計画的メンテナンス + - Namespaceによるマルチテナント: リソースクォータ、ネットワークポリシー + - ConfigMap/Secretの管理: 機密情報の暗号化、ローテーションポリシー + - PersistentVolumeの管理: スナップショット、バックアップ、リサイズ手順 + +- **GitOps による Infrastructure as Code 運用**: + - **GitOpsの原則**: + - Git を信頼できる唯一の情報源（Single Source of Truth）として扱う + - すべてのインフラ変更は Git リポジトリへのコミット・PR 経由で実施 + - 自動化されたエージェントが Git の状態をクラスタに同期 + - 宣言的な設定（Declarative Configuration）によるインフラ管理 + + - **GitOpsツールの選択**: + - **ArgoCD** ⭐⭐⭐⭐⭐: Kubernetes 専用、UI が優れている、多機能 + - **Flux** ⭐⭐⭐⭐: CNCF 卒業プロジェクト、軽量、GitOps Toolkit として拡張可能 + - **Jenkins X** ⭐⭐⭐: CI/CD と GitOps を統合、学習コスト高 + + - **GitOps ワークフロー**: + 1. 開発者が Infrastructure as Code（Terraform/Helm/Kustomize）を Git にコミット + 2. PR レビューによる変更承認プロセス + 3. マージ後、GitOps エージェント（ArgoCD/Flux）が自動的に変更を検知 + 4. クラスタの状態を Git リポジトリの定義に同期 + 5. 同期結果の監視とアラート + + - **GitOps 運用上の考慮事項**: + - **リポジトリ構成**: + - アプリケーションコードと Infrastructure as Code の分離 + - 環境ごとのブランチ/ディレクトリ戦略（dev/staging/production） + - マニフェストの再利用（Helm Charts / Kustomize Overlays） + + - **シークレット管理**: + - Git にシークレットをコミットしない（必須） + - Sealed Secrets / External Secrets Operator / SOPS による暗号化 + - AWS Secrets Manager / GCP Secret Manager との連携 + + - **ロールバック戦略**: + - Git の履歴を利用した簡易ロールバック（git revert） + - バージョンタグによる特定バージョンへの復元 + - カナリアリリース・ブルーグリーンデプロイメントとの組み合わせ + + - **監査とコンプライアンス**: + - すべての変更が Git 履歴に記録される（変更者、タイムスタンプ、理由） + - PR レビューによる変更承認の証跡 + - コンプライアンス要件を満たす監査ログとして活用 + + - **障害時の対応**: + - GitOps エージェントの障害時は手動デプロイも可能にしておく + - Git リポジトリの障害時のフォールバック手順 + - 同期の失敗アラートとエスカレーション設定 + +**サーバレス特有の制限と考慮事項**: +- **実行制限の考慮**: + - Lambda同時実行数制限: デフォルト1000（リージョンごと）、必要に応じて上限緩和申請 + - タイムアウト設計: 最大15分（Lambda）の制限、長時間処理はStep Functions等で分割 + - コールドスタート対策: + - Provisioned Concurrency（追加コスト発生） + - VPC Lambda使用時のENI作成時間考慮 + - 軽量ランタイムの選択（Python/Node.js推奨、Java/C#は起動遅い） + - ペイロードサイズ制限: + - 同期呼び出し: 6MB + - 非同期呼び出し: 256KB + - 大きなデータはS3経由で処理 + +- **料金最適化**: + - メモリサイズとCPU割り当ての最適化（メモリに比例してCPUも増加） + - タイムアウト値の適切な設定（無駄な待機時間を削減） + - Provisioned Concurrencyの費用対効果分析 + +**オブザーバビリティの実装**: +- **分散トレーシング**: + - AWS X-Ray / Jaeger / Zipkin / OpenTelemetry + - トレースサンプリング率の設定（コストと可視性のトレードオフ） + - サービスマップによる依存関係の可視化 + +- **ログ集約**: + - CloudWatch Logs Insights / ELK Stack / Loki / Splunk + - ログ保管期間とコスト管理 + - 構造化ログ（JSON形式）の推奨 + - ログレベル（DEBUG/INFO/WARN/ERROR）の運用ルール + +- **メトリクス収集**: + - Prometheus + Grafana / CloudWatch / Datadog / New Relic + - カスタムメトリクスの設計 + - ダッシュボードの標準化 + +**AWS特有の運用項目**: +- **IAM管理**: + - ロール・ポリシーの定期レビュー（四半期ごと推奨） + - 最小権限の原則の徹底 + - サービスロールとIAMユーザーの使い分け + - MFA強制ポリシー + - アクセスキーのローテーションポリシー + +- **タグ戦略**: + - コスト配分タグ（Environment、Service、Team、CostCenter）の必須化 + - リソース管理タグ（Owner、Project、Compliance） + - 自動タグ付けの実装（Terraform/CloudFormation） + - タグポリシーの強制（AWS Organizations Tag Policies） + +- **マルチアカウント戦略**: + - AWS Organizations による一元管理 + - アカウント分離戦略（本番/ステージング/開発、サービスごと、環境ごと） + - AWS Control Tower の活用（ガードレール、アカウントファクトリ） + - 請求の統合（Consolidated Billing） + +- **AWSサポート活用**: + - サポートプラン: Developer / Business / Enterprise（要件に応じて選択） + - TAM（Technical Account Manager）の活用（Enterprise Support） + - Trusted Advisor の定期確認（コスト最適化、セキュリティ、パフォーマンス） + - AWS Well-Architected Review の実施 + +- **コンプライアンスとガバナンス**: + - AWS Config によるリソース設定の記録と監査 + - AWS CloudTrail による API 操作の記録（改ざん検知） + - GuardDuty によるセキュリティ脅威検知 + - Security Hub による セキュリティポスチャの統合管理 + +--- + +## 2. サービス概要 + +### 2.1 サービスの目的 + +サービスが提供する価値と目的を記載します。 + +**ビジネス目的**: +- [ビジネス上の目的] + +**提供価値**: +- [ユーザーに提供する価値] + +### 2.2 サービスの機能 + +主要な機能を記載します。 + +| 機能名 | 概要 | 重要度 | +|--------|------|--------| +| [機能1] | [機能の説明] | High / Medium / Low | +| [機能2] | [機能の説明] | High / Medium / Low | + +### 2.3 システム構成 + +システムのアーキテクチャと主要コンポーネントを記載します。 + +**アーキテクチャ図**: + +```mermaid +graph TB + subgraph "ユーザー層" + User[エンドユーザー] + end + + subgraph "アプリケーション層" + Web[Webサーバー] + App[アプリケーションサーバー] + end + + subgraph "データ層" + DB[(データベース)] + Cache[(キャッシュ)] + end + + User --> Web + Web --> App + App --> DB + App --> Cache +``` + +**主要コンポーネント**: + +| コンポーネント | 役割 | 技術スタック | 冗長化 | +|----------------|------|--------------|--------| +| [コンポーネント1] | [役割] | [技術] | Yes / No | +| [コンポーネント2] | [役割] | [技術] | Yes / No | + +### 2.4 外部連携 + +外部システムとの連携を記載します。 + +| 連携先 | 連携方式 | データフロー | 重要度 | +|--------|----------|--------------|--------| +| [システム名] | API / Batch / etc | [方向と内容] | High / Medium / Low | + +--- + +## 3. 運用方針と目標 + +### 3.1 運用基本方針 + +運用における基本的な方針を記載します。 + +1. **可用性重視**: [方針の詳細] +2. **セキュリティ優先**: [方針の詳細] +3. **継続的改善**: [方針の詳細] +4. **コスト最適化**: [方針の詳細] + +### 3.2 サービスレベル目標（SLO） + +**【重要】ユーザー中心のSLO設計原則**: + +SLOは「測りやすい指標」ではなく、「ユーザーが快適に使える範囲」を起点として設計します。 + +**設計アプローチ**: +1. **ユーザーの期待値を理解する** + - ユーザーはどの程度の応答速度を期待しているか + - どの程度のエラーなら許容できるか + - サービス停止はどの程度の影響を与えるか + +2. **ユーザー体験に基づいた目標設定** + - 「サーバーCPU使用率」ではなく「ユーザーが体感するレスポンスタイム」 + - 「データベース接続数」ではなく「ユーザーがエラーに遭遇する頻度」 + - 技術指標はユーザー体験指標の裏付けとして使用 + +3. **システム構成ごとの目標設定** + - 同期処理、非同期処理、バッチ処理でユーザー期待値は異なる + - それぞれに適切な目標値を設定 + +**SLO定義**: + +| システム構成/機能 | 指標名 | 目標値 | ユーザー視点での意味 | 測定方法 | 測定頻度 | +|-------------------|--------|--------|---------------------|----------|----------| +| [全体] | 可用性 | [例: 99.9%] | ユーザーがサービスを利用できる時間の割合 | [測定方法] | [頻度] | +| [Web同期リクエスト] | レスポンスタイム（P95） | [例: 500ms以下] | ユーザーが操作後に結果が表示されるまでの体感速度 | [測定方法] | [頻度] | +| [Web同期リクエスト] | エラーレート | [例: 0.1%以下] | ユーザーがエラーに遭遇する頻度 | [測定方法] | [頻度] | +| [非同期APIリクエスト] | 処理完了時間（P95） | [例: 5秒以内] | バックグラウンド処理が完了するまでの時間 | [測定方法] | [頻度] | +| [バッチ処理] | 処理完了時刻 | [例: 翌朝8時まで] | 業務開始時にデータが利用可能になっている状態 | [測定方法] | 日次 | +| [全体] | MTTR | [例: 30分以内] | 障害発生時にユーザーが待つ時間 | [測定方法] | [頻度] | + +### 3.3 サービスレベル指標（SLI） + +SLOを測定するための具体的な指標を記載します。 + +| SLI名 | 定義 | データソース | 計算式 | +|-------|------|--------------|--------| +| [SLI1] | [定義] | [ソース] | [計算式] | +| [SLI2] | [定義] | [ソース] | [計算式] | + +### 3.4 サービスレベル合意（SLA） + +顧客またはユーザーに対して約束するサービス品質の基準を記載します。 + +**SLA策定の重要性**: +- SLOとSLIに基づいた実現可能な目標設定 +- 顧客期待値の明確化 +- サービス品質保証の根拠 +- 違約時の対応方針の明確化 + +**SLA定義**: + +| システム構成/機能 | SLA項目 | 保証値 | 測定方法 | 測定期間 | 未達時の対応 | +|-------------------|---------|--------|----------|----------|-------------| +| [全体] | サービス可用性 | [例: 99.9%] | [測定方法] | 月次 | [対応内容] | +| [Web同期リクエスト] | レスポンスタイム（P95） | [例: 500ms以下] | [測定方法] | 月次 | [対応内容] | +| [非同期APIリクエスト] | 処理完了時間（P95） | [例: 5秒以内] | [測定方法] | 月次 | [対応内容] | +| [バッチ処理] | 処理完了時刻 | [例: 翌朝8時まで] | [測定方法] | 日次 | [対応内容] | + +**システム構成別のSLA設定指針**: + +1. **同期的なWebリクエスト（ユーザー対話操作）** + - ユーザーが快適に操作できる範囲を基準とする + - レスポンスタイム: 一般的に500ms以下（P95） + - エラーレート: 0.1%以下 + +2. **非同期APIリクエスト（バックグラウンド処理）** + - ユーザー体験に直接影響しない範囲で設定 + - 処理完了時間: 数秒〜数十秒 + - 再試行ポリシーを含む + +3. **バッチ処理（夜間処理等）** + - 業務開始時刻までの完了を保証 + - 処理時間: 数時間単位 + - 失敗時の再実行ポリシー + +**SLA未達時のペナルティまたは対応**: +- サービスクレジット: [内容] +- エスカレーション: [プロセス] +- 改善計画の提出: [内容] + +### 3.5 エラーバジェット + +許容されるエラーの範囲を定義します。 + +**エラーバジェット算出**: +- 可用性目標: 99.9% +- 許容ダウンタイム（月間）: [計算結果] +- エラーバジェット消費の閾値: [閾値] + +**エラーバジェットポリシー**: +- エラーバジェット残量 > 50%: [対応方針] +- エラーバジェット残量 20-50%: [対応方針] +- エラーバジェット残量 < 20%: [対応方針] + +--- + +## 4. 運用体制 + +### 4.1 運用組織体制 + +運用組織の体制を記載します。 + +```mermaid +graph TB + Manager[運用マネージャー] + + Manager --> Team1[運用チーム1] + Manager --> Team2[運用チーム2] + Manager --> Team3[SREチーム] + + Team1 --> Ops1[オペレーター1] + Team1 --> Ops2[オペレーター2] + + Team2 --> Ops3[オペレーター3] + Team2 --> Ops4[オペレーター4] + + Team3 --> SRE1[SREエンジニア1] + Team3 --> SRE2[SREエンジニア2] +``` + +### 4.2 役割と責任（RACI） + +主要な運用プロセスにおける役割と責任を記載します。 + +| プロセス/タスク | 運用マネージャー | 運用チーム | SREチーム | 開発チーム | 備考 | +|-----------------|------------------|------------|-----------|------------|------| +| 監視・アラート対応 | A | R | C | I | [備考] | +| インシデント対応 | A | R | C | C | [備考] | +| 変更管理 | A | I | C | R | [備考] | +| リリース管理 | A | C | R | R | [備考] | + +※ R=Responsible（実行責任）, A=Accountable（説明責任）, C=Consulted（相談）, I=Informed（報告） + +### 4.3 運用時間帯 + +運用体制の時間帯を記載します。 + +| 時間帯 | 運用体制 | 対応内容 | +|--------|----------|----------| +| 平日 9:00-18:00 | 通常体制 | [対応内容] | +| 平日 18:00-9:00 | オンコール体制 | [対応内容] | +| 休日・祝日 | オンコール体制 | [対応内容] | + +**オンコール体制**: +- 1次対応: [担当者・連絡先] +- 2次対応: [担当者・連絡先] +- エスカレーション先: [担当者・連絡先] + +### 4.4 コミュニケーション + +運用における コミュニケーション方法を記載します。 + +**定例会議**: + +| 会議名 | 頻度 | 参加者 | 目的 | +|--------|------|--------|------| +| 日次運用会議 | 毎日 | [参加者] | [目的] | +| 週次運用レビュー | 毎週 | [参加者] | [目的] | +| 月次運用報告 | 毎月 | [参加者] | [目的] | + +**コミュニケーションツール**: +- チャット: [ツール名・チャンネル] +- チケット管理: [ツール名] +- ドキュメント共有: [ツール名] +- インシデント管理: [ツール名] + +--- + +## 5. 運用スケジュール + +### 5.1 定期運用スケジュール + +定期的に実施する運用作業のスケジュールを記載します。 + +| 作業項目 | 頻度 | 実施日時 | 担当 | 所要時間 | +|----------|------|----------|------|----------| +| [作業1] | 日次 | [時刻] | [担当] | [時間] | +| [作業2] | 週次 | [曜日・時刻] | [担当] | [時間] | +| [作業3] | 月次 | [日・時刻] | [担当] | [時間] | + +### 5.2 メンテナンスウィンドウ + +計画メンテナンスの実施可能時間帯を記載します。 + +**定期メンテナンス**: +- 頻度: [週次/月次/四半期等] +- 実施日時: [曜日・時刻] +- 所要時間: [時間] +- 影響範囲: [影響内容] + +**緊急メンテナンス**: +- 実施判断基準: [基準] +- 承認プロセス: [プロセス] +- 通知方法: [通知手段] + +### 5.3 年間運用カレンダー + +年間の主要イベントとメンテナンススケジュールを記載します。 + +| 月 | イベント/作業 | 詳細 | +|----|---------------|------| +| 1月 | [イベント] | [詳細] | +| 2月 | [イベント] | [詳細] | +| ... | ... | ... | + +--- + +## 6. 定常運用作業 + +### 6.1 日次運用作業 + +毎日実施する運用作業を記載します。 + +#### 7.1.1 [作業名1] + +**目的**: [作業の目的] + +**実施タイミング**: [時刻] + +**手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +**確認項目**: +- [ ] [確認項目1] +- [ ] [確認項目2] + +**成果物**: [成果物があれば記載] + +**エスカレーション基準**: [異常時の対応] + +#### 7.1.2 [作業名2] + +[同様の形式で記載] + +### 6.2 週次運用作業 + +週単位で実施する運用作業を記載します。 + +#### 7.2.1 [作業名] + +[日次作業と同様の形式で記載] + +### 6.3 月次運用作業 + +月単位で実施する運用作業を記載します。 + +#### 7.3.1 [作業名] + +[日次作業と同様の形式で記載] + +--- + +## 7. 監視・通知 + +### 7.1 監視方針 + +**【重要】ユーザー中心の監視設計原則**: + +監視は「測りやすい技術指標」ではなく、「ユーザーが快適に使える状態」を維持するために実施します。 + +**監視設計アプローチ**: + +1. **ユーザー体験起点の監視** + - まず「ユーザーが体感する品質」を監視 + - 技術指標はユーザー体験指標が悪化した時の原因特定に使用 + - 例: レスポンスタイムの悪化を検知 → CPU使用率を確認して原因を特定 + +2. **外形監視を最優先** + - ユーザーと同じ視点でサービスを監視 + - エンドツーエンドの動作確認 + - 実際のユーザートランザクションをシミュレート + +3. **システム構成ごとの監視基準** + - 同期処理、非同期処理、バッチ処理で監視基準を分ける + - それぞれのユーザー期待値に基づいた閾値設定 + +**監視の目的**: +- **第一目的**: ユーザーが快適に利用できる状態の維持 +- サービスの可用性確保 +- パフォーマンス劣化の早期検知（ユーザー体感品質の観点から） +- セキュリティインシデントの検知 +- キャパシティ不足の予兆検知 + +**監視レベル**: +- レベル1（Critical）: ユーザーに直接影響がある状態 [具体的な定義と対応] +- レベル2（Warning）: ユーザーへ影響が及ぶ可能性のある状態 [具体的な定義と対応] +- レベル3（Info）: ユーザーに影響はないが注視すべき状態 [具体的な定義と対応] + +### 7.2 監視項目 + +**【重要】監視項目の優先順位**: + +**優先度1: ユーザー体験監視（SLI直結）** +- ユーザーが直接体感する品質指標 +- これらが正常であればサービスは正常 + +**優先度2: アプリケーション監視** +- ユーザー体験指標の裏付け +- 問題発生時の原因特定用 + +**優先度3: インフラ監視** +- アプリケーション指標の裏付け +- キャパシティ管理用 + +**監視項目定義**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 1 | 外形監視（Web同期） | レスポンスタイム（P95） | 500ms超 | 1分 | Warning | ユーザーが遅いと感じる | +| 1 | 外形監視（Web同期） | レスポンスタイム（P95） | 1000ms超 | 1分 | Critical | ユーザーがストレスを感じる | +| 1 | 外形監視（Web同期） | エラーレート | 0.1%超 | 1分 | Warning | ユーザーがエラーに遭遇し始める | +| 1 | 外形監視（Web同期） | エラーレート | 1%超 | 1分 | Critical | 多数のユーザーがエラーに遭遇 | +| 1 | 外形監視（非同期API） | 処理完了時間（P95） | 5秒超 | 5分 | Warning | バックグラウンド処理の遅延 | +| 1 | 外形監視（バッチ） | 処理完了時刻 | 7:00以降 | 1時間 | Warning | 業務開始に間に合わない可能性 | +| 1 | 外形監視（バッチ） | 処理完了時刻 | 8:00以降 | 1時間 | Critical | 業務開始に間に合わない | +| 2 | アプリケーション | エラーレート | [閾値] | 1分 | [レベル] | アプリケーションレベルのエラー発生状況 | +| 2 | アプリケーション | レスポンスタイム | [閾値] | 1分 | [レベル] | アプリケーション処理時間 | +| 3 | Webサーバー | CPU使用率 | 80%超 | 1分 | Info | リソース逼迫の予兆 | +| 3 | Webサーバー | CPU使用率 | 90%超 | 1分 | Warning | リソース逼迫 | +| 3 | Webサーバー | メモリ使用率 | [閾値] | [間隔] | [レベル] | メモリリソース状況 | +| 3 | データベース | 接続数 | [閾値] | [間隔] | [レベル] | DB接続リソース状況 | + +**クラウドネイティブ/サーバレス固有の監視項目**: + +**【サーバレス（Lambda/Cloud Functions等）の監視】**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 1 | Lambda関数 | Errors | 1件以上/分 | 1分 | Critical | ユーザーリクエストが失敗している | +| 2 | Lambda関数 | Throttles | 1件以上 | 1分 | Critical | リクエストがスロットリングされている | +| 2 | Lambda関数 | 同時実行数 | アカウント上限の80%超 | 1分 | Warning | スロットリングの予兆 | +| 2 | Lambda関数 | Duration（P95） | タイムアウト値の80%超 | 5分 | Warning | タイムアウトの予兆、処理遅延 | +| 2 | Lambda関数 | Duration（P95） | タイムアウト値の95%超 | 5分 | Critical | タイムアウト直前、即座に対応必要 | +| 3 | Lambda関数 | Cold Start率 | 5%超 | 5分 | Info | レスポンスタイム悪化の要因 | +| 3 | Lambda関数 | メモリ使用率 | 設定値の90%超 | 5分 | Warning | メモリ不足によるパフォーマンス低下 | +| 3 | Lambda関数 | イテレーター経過時間 | 1時間超 | 5分 | Warning | ストリーム処理の遅延（Kinesis/DynamoDB Streams） | + +**【Kubernetes（EKS/GKE/AKS）の監視】**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 1 | Pod | CrashLoopBackOff | 発生 | 1分 | Critical | サービスが起動できない状態 | +| 1 | Pod | ImagePullBackOff | 発生 | 1分 | Critical | コンテナイメージ取得失敗 | +| 1 | Service | Endpoints数 | 0 | 1分 | Critical | バックエンドPodが全て停止 | +| 2 | Pod | PodのPending状態 | 5分以上 | 1分 | Warning | リソース不足でスケールできない | +| 2 | Pod | Restart回数 | 10回/1時間 | 5分 | Warning | 不安定な状態、調査必要 | +| 2 | Node | NodeNotReady | 発生 | 1分 | Critical | ノード障害、サービス影響の可能性 | +| 2 | Node | DiskPressure | 発生 | 1分 | Warning | ディスク容量不足 | +| 2 | Node | MemoryPressure | 発生 | 1分 | Warning | メモリ不足 | +| 3 | Pod | CPU使用率（Requests比） | 90%超 | 1分 | Warning | スケールアウトの必要性 | +| 3 | Pod | メモリ使用率（Requests比） | 90%超 | 1分 | Warning | スケールアウトの必要性 | +| 3 | HPA | desiredReplicas vs currentReplicas | 不一致が5分以上 | 1分 | Warning | スケールが追いついていない | +| 3 | Cluster | ノード数 | 最大ノード数の90%超 | 5分 | Warning | クラスタ拡張限界に近づいている | + +**【AWSマネージドサービス固有の監視】**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 1 | RDS | DBInstanceStatus | available以外 | 1分 | Critical | データベースが利用不可 | +| 1 | RDS | フェイルオーバー発生 | 発生 | 1分 | Critical | DBが一時的に利用不可になる | +| 1 | ALB/NLB | HealthyHostCount | 0 | 1分 | Critical | 全てのバックエンドが停止 | +| 1 | ALB/NLB | UnHealthyHostCount | 全ターゲット数 | 1分 | Critical | 全てのバックエンドが異常 | +| 2 | RDS | CPU使用率 | 80%超 | 5分 | Warning | パフォーマンス劣化の予兆 | +| 2 | RDS | 接続数 | 最大接続数の80%超 | 1分 | Warning | 新規接続が拒否され始める | +| 2 | RDS | FreeableMemory | 1GB未満 | 5分 | Warning | メモリ不足 | +| 2 | RDS | FreeStorageSpace | 10GB未満または10%未満 | 5分 | Warning | ストレージ容量不足 | +| 2 | RDS | ReadLatency/WriteLatency | 100ms超（P95） | 5分 | Warning | I/O性能劣化 | +| 2 | SQS | ApproximateAgeOfOldestMessage | 15分超 | 5分 | Warning | メッセージ処理の遅延 | +| 2 | SQS | DLQメッセージ数 | 1件以上 | 5分 | Warning | 処理失敗メッセージの蓄積 | +| 2 | DynamoDB | UserErrors | 1件以上/分 | 1分 | Warning | クライアントエラーの発生 | +| 2 | DynamoDB | SystemErrors | 1件以上 | 1分 | Critical | DynamoDB側のエラー | +| 2 | DynamoDB | ConsumedReadCapacity | プロビジョニング値の80%超 | 1分 | Warning | スロットリングの予兆 | +| 2 | DynamoDB | ConsumedWriteCapacity | プロビジョニング値の80%超 | 1分 | Warning | スロットリングの予兆 | +| 2 | S3 | 4xxErrors | 10件以上/分 | 5分 | Warning | クライアントエラーの多発 | +| 2 | S3 | 5xxErrors | 1件以上 | 5分 | Critical | S3側のエラー | +| 3 | CloudWatch Logs | IncomingBytes | 予算の80%超（月累計） | 1時間 | Info | ログコスト超過の予兆 | +| 3 | API Gateway | Latency（P95） | 1000ms超 | 5分 | Warning | API処理遅延 | +| 3 | API Gateway | 4XXError率 | 5%超 | 5分 | Warning | クライアントエラーの多発 | +| 3 | API Gateway | 5XXError率 | 1%超 | 5分 | Critical | サーバーエラーの多発 | + +**【コンテナイメージ・レジストリの監視】**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 2 | ECR/GCR/ACR | イメージプル失敗 | 発生 | 1分 | Critical | デプロイ・スケールができない | +| 3 | ECR/GCR/ACR | 脆弱性スキャン結果 | Critical/High検出 | 1日 | Warning | セキュリティリスク | +| 3 | ECR/GCR/ACR | ストレージ使用量 | 予算の80%超 | 1日 | Info | コスト超過の予兆 | + +**【分散トレーシング・オブザーバビリティ】**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 1 | X-Ray/Jaeger | エラートレース率 | 1%超 | 5分 | Warning | 分散システム内でのエラー発生 | +| 2 | X-Ray/Jaeger | エンドツーエンドレイテンシ（P95） | SLO超過 | 5分 | Warning | 複数サービスにまたがる処理遅延 | +| 3 | X-Ray/Jaeger | サンプリング率 | 設定値未満 | 1時間 | Info | トレースデータの欠損 | + +**システム構成別の監視設計**: + +1. **同期的なWebリクエスト** + - ユーザーは即座に結果を期待 + - レスポンスタイム: P95で500ms以下を目標 + - 監視間隔: 1分（迅速な検知が必要） + +2. **非同期APIリクエスト** + - ユーザーは数秒の待機は許容 + - 処理完了時間: P95で5秒以内を目標 + - 監視間隔: 5分（ある程度の猶予あり） + +3. **バッチ処理** + - ユーザーは完了時刻を期待 + - 処理完了時刻: 業務開始時刻まで + - 監視間隔: 1時間（処理時間が長いため） + +### 7.3 ログ管理 + +ログの収集・保管・分析方針を記載します。 + +**ログ種類**: + +| ログ種類 | 出力先 | 保管期間 | 用途 | +|----------|--------|----------|------| +| アクセスログ | [保存先] | [期間] | [用途] | +| アプリケーションログ | [保存先] | [期間] | [用途] | +| エラーログ | [保存先] | [期間] | [用途] | +| セキュリティログ | [保存先] | [期間] | [用途] | + +**ログ分析**: +- ツール: [ツール名] +- 分析頻度: [頻度] +- 分析内容: [内容] + +### 7.4 アラート通知 + +アラート通知のルールと方法を記載します。 + +**通知ルート**: + +```mermaid +graph LR + Alert[アラート発生] --> Level{レベル判定} + + Level -->|Critical| Notify1[即時通知
電話+メール+チャット] + Level -->|Warning| Notify2[メール+チャット] + Level -->|Info| Notify3[チャットのみ] + + Notify1 --> Oncall[オンコール担当] + Notify2 --> Team[運用チーム] + Notify3 --> Log[ログ記録] +``` + +**通知先**: + +| アラートレベル | 通知方法 | 通知先 | 対応時間 | +|----------------|----------|--------|----------| +| Critical | 電話+メール+チャット | [通知先] | 即時 | +| Warning | メール+チャット | [通知先] | 30分以内 | +| Info | チャット | [通知先] | 営業時間内 | + +--- + +## 8. インシデント管理 + +### 8.1 インシデント定義 + +インシデントの定義と分類を記載します。 + +**インシデント定義**: +サービスの計画外の中断、またはサービス品質の低下 + +**インシデント分類**: + +| 優先度 | 定義 | 対応目標時間 | 例 | +|--------|------|--------------|-----| +| P1（Critical） | サービス全停止 | 15分以内に対応開始 | [例] | +| P2（High） | 主要機能停止 | 30分以内に対応開始 | [例] | +| P3（Medium） | 一部機能停止 | 2時間以内に対応開始 | [例] | +| P4（Low） | 軽微な問題 | 営業時間内対応 | [例] | + +### 8.2 インシデント対応フロー + +インシデント対応の標準フローを記載します。 + +```mermaid +graph TD + Start[インシデント検知] --> Triage[トリアージ] + Triage --> Priority{優先度判定} + + Priority -->|P1/P2| Urgent[緊急対応] + Priority -->|P3/P4| Normal[通常対応] + + Urgent --> Investigate1[原因調査] + Normal --> Investigate2[原因調査] + + Investigate1 --> Fix1[復旧作業] + Investigate2 --> Fix2[修正作業] + + Fix1 --> Verify1[動作確認] + Fix2 --> Verify2[動作確認] + + Verify1 --> Close1[インシデントクローズ] + Verify2 --> Close2[インシデントクローズ] + + Close1 --> Postmortem[ポストモーテム] + Close2 --> Review[レビュー] +``` + +### 8.3 インシデント対応手順 + +インシデント対応の詳細手順を記載します。 + +#### 9.3.1 検知・報告 + +**検知方法**: +- 監視アラート +- ユーザー報告 +- 運用チーム発見 + +**報告フロー**: +1. インシデント管理ツールにチケット作成 +2. 運用チームに通知 +3. 優先度に応じてエスカレーション + +#### 9.3.2 トリアージ + +**トリアージ基準**: +- 影響範囲（全ユーザー / 一部ユーザー / 特定機能） +- ビジネスインパクト（売上損失 / 信用失墜 / 軽微） +- 緊急度（即時対応必要 / 計画的対応可能） + +**優先度判定**: +[優先度判定のマトリクスやルール] + +#### 9.3.3 対応・復旧 + +**対応原則**: +1. まず復旧、原因究明は後 +2. 影響範囲の最小化を優先 +3. コミュニケーションを密に + +**復旧手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +#### 9.3.4 ポストモーテム + +**実施タイミング**: +- P1/P2インシデント: 必須 +- P3インシデント: 必要に応じて +- P4インシデント: 任意 + +**ポストモーテム内容**: +- インシデントサマリー +- 影響範囲と期間 +- 根本原因分析（なぜなぜ分析） +- 再発防止策 +- アクションアイテム + +### 8.4 エスカレーション + +エスカレーションルールを記載します。 + +**エスカレーション基準**: +- 対応開始から[X]分経過しても復旧しない +- 影響範囲が拡大している +- 技術的な判断が必要 +- ビジネス判断が必要 + +**エスカレーションパス**: + +```mermaid +graph TB + L1[L1: 運用担当者] -->|15分| L2[L2: 運用リーダー] + L2 -->|30分| L3[L3: 運用マネージャー] + L3 -->|60分| L4[L4: 開発チーム] + L3 -->|重大影響| L5[L5: 経営層] +``` + +--- + +## 9. 変更管理 + +### 9.1 変更管理方針 + +変更管理の基本方針を記載します。 + +**変更管理の目的**: +- 変更に伴うリスクの最小化 +- 変更の影響評価と承認プロセスの明確化 +- 変更履歴の記録と追跡可能性の確保 + +**変更の定義**: +本番環境への以下の変更を対象とします +- システム構成の変更 +- アプリケーションのデプロイ +- インフラ設定の変更 +- セキュリティ設定の変更 + +### 9.2 変更分類 + +変更の種類と承認プロセスを記載します。 + +| 変更分類 | 定義 | 承認者 | リードタイム | +|----------|------|--------|--------------| +| 標準変更 | 手順化済みの低リスク変更 | 運用リーダー | 即時 | +| 通常変更 | 一般的な変更 | 運用マネージャー | 3営業日 | +| 緊急変更 | 緊急対応が必要な変更 | 運用マネージャー | 即時 | +| 重要変更 | 高リスクまたは大規模な変更 | 変更諮問委員会 | 1週間 | + +### 9.3 変更管理フロー + +変更管理のプロセスを記載します。 + +```mermaid +graph TD + Request[変更要求] --> Classification{変更分類} + + Classification -->|標準| Approve1[自動承認] + Classification -->|通常| Review1[レビュー] + Classification -->|緊急| Review2[緊急レビュー] + Classification -->|重要| CAB[CAB審査] + + Review1 --> Approve2[承認] + Review2 --> Approve3[承認] + CAB --> Approve4[承認] + + Approve1 --> Plan[実施計画] + Approve2 --> Plan + Approve3 --> Plan + Approve4 --> Plan + + Plan --> Implement[変更実施] + Implement --> Verify[検証] + Verify --> Close[クローズ] + + Verify -->|失敗| Rollback[ロールバック] + Rollback --> Review3[原因分析] +``` + +### 9.4 変更実施手順 + +変更を実施する際の標準手順を記載します。 + +**事前準備**: +1. 変更チケットの作成 +2. 変更内容の詳細記載 +3. 影響評価の実施 +4. ロールバック計画の作成 +5. 承認取得 + +**実施時**: +1. 事前バックアップの取得 +2. 変更作業の実施 +3. 作業ログの記録 +4. 動作確認の実施 + +**事後**: +1. 変更結果の報告 +2. ドキュメントの更新 +3. チケットのクローズ + +### 9.5 ロールバック計画 + +ロールバックの基準と手順を記載します。 + +**ロールバック判断基準**: +- 変更後の動作確認でエラーが検出された +- SLOを下回る性能劣化が発生した +- 予期しない副作用が発生した +- [その他の基準] + +**ロールバック手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +--- + +## 10. リリース管理 + +### 10.1 リリース方針 + +リリースの基本方針を記載します。 + +**リリース原則**: +- 定期リリースと緊急リリースの明確な区別 +- 本番環境へのリリース前の十分なテスト +- 段階的なロールアウト（カナリアリリース等） +- 自動化されたデプロイメントプロセス + +### 10.2 リリーススケジュール + +定期リリースのスケジュールを記載します。 + +| リリース種別 | 頻度 | 実施日時 | 対象 | +|--------------|------|----------|------| +| メジャーリリース | 四半期毎 | [日時] | 大規模機能追加 | +| マイナーリリース | 月次 | [日時] | 機能改善 | +| パッチリリース | 週次 | [日時] | バグフィックス | +| ホットフィックス | 随時 | 随時 | 緊急対応 | + +### 10.3 リリースフロー + +リリースプロセスを記載します。 + +```mermaid +graph LR + Dev[開発環境] --> Test[テスト環境] + Test --> Staging[ステージング環境] + Staging --> Canary[カナリア環境] + Canary --> Prod[本番環境] + + Test -.->|NG| Dev + Staging -.->|NG| Dev + Canary -.->|NG| Rollback[ロールバック] +``` + +**各環境の役割**: +- 開発環境: 機能開発とユニットテスト +- テスト環境: 結合テストと品質保証 +- ステージング環境: 本番環境と同等構成での最終確認 +- カナリア環境: 一部ユーザーでの先行リリース +- 本番環境: 全ユーザー向けリリース + +### 10.4 デプロイメント戦略 + +デプロイメント方式を記載します。 + +**採用戦略**: [選択した戦略] + +**デプロイメント方式の比較**: + +| 方式 | メリット | デメリット | 採用判断 | +|------|----------|------------|----------| +| Blue-Green | ダウンタイムゼロ | リソース2倍必要 | [○/×] | +| Rolling | リソース効率的 | 段階的な切り替え | [○/×] | +| Canary | リスク最小化 | 複雑な制御必要 | [○/×] | + +**自動化ツール**: +- CI/CDツール: [ツール名] +- デプロイツール: [ツール名] +- インフラ管理: [ツール名] + +--- + +## 11. バックアップ・リカバリ + +### 11.1 バックアップ方針 + +バックアップの基本方針を記載します。 + +**バックアップ目的**: +- データ損失時の復旧 +- ランサムウェア等のセキュリティインシデント対応 +- 監査・コンプライアンス要件への対応 + +**バックアップ原則**: +- 3-2-1ルール: 3つのコピー、2つの異なるメディア、1つはオフサイト +- 暗号化されたバックアップの保管 +- 定期的なリストアテストの実施 + +### 11.2 バックアップ設計 + +バックアップ対象と方式を記載します。 + +| バックアップ対象 | バックアップ方式 | 頻度 | 世代管理 | 保管場所 | +|------------------|------------------|------|----------|----------| +| データベース | フル+差分 | 日次フル+6時間毎差分 | 30世代 | [場所] | +| ファイルストレージ | フル | 日次 | 7世代 | [場所] | +| システム設定 | フル | 変更時 | 10世代 | [場所] | +| ログファイル | 増分 | 1時間毎 | 90日 | [場所] | + +**バックアップスケジュール**: + +```mermaid +gantt + title バックアップスケジュール（1日） + dateFormat HH:mm + axisFormat %H:%M + + section データベース + フルバックアップ :00:00, 2h + 差分バックアップ1 :06:00, 30m + 差分バックアップ2 :12:00, 30m + 差分バックアップ3 :18:00, 30m + + section ファイル + フルバックアップ :02:00, 1h +``` + +### 11.3 リカバリ設計 + +リカバリの目標値と手順を記載します。 + +**リカバリ目標**: + +| 対象 | RPO（目標復旧時点） | RTO（目標復旧時間） | +|------|---------------------|---------------------| +| データベース | 6時間以内 | 4時間以内 | +| ファイルストレージ | 24時間以内 | 2時間以内 | +| システム全体 | 24時間以内 | 8時間以内 | + +**リカバリ手順**: + +#### データベースリカバリ +1. [手順1] +2. [手順2] +3. [手順3] + +**リカバリテスト**: +- 頻度: 四半期毎 +- 対象: [テスト対象] +- 成功基準: [基準] + +### 11.4 災害対策（DR） + +災害復旧計画を記載します。 + +**DR方針**: +- DR サイト: [有/無] +- DR 構成: [Hot Standby / Warm Standby / Cold Standby] + +**DR切り替えシナリオ**: + +| シナリオ | 発生条件 | 切り替え判断 | 切り替え時間目標 | +|----------|----------|--------------|------------------| +| データセンター障害 | [条件] | [判断基準] | [時間] | +| リージョン障害 | [条件] | [判断基準] | [時間] | + +--- + +## 12. セキュリティ運用 + +### 12.1 セキュリティ運用方針 + +セキュリティ運用の基本方針を記載します。 + +**セキュリティ原則**: +- 多層防御（Defense in Depth） +- 最小権限の原則 +- ゼロトラストアーキテクチャ +- 継続的なセキュリティ監視 + +### 12.2 アクセス管理 + +アクセス権限の管理方針を記載します。 + +**権限管理**: + +| ロール | 権限範囲 | 承認者 | レビュー頻度 | +|--------|----------|--------|--------------| +| システム管理者 | 全権限 | [承認者] | 月次 | +| 運用担当者 | 運用操作のみ | [承認者] | 月次 | +| 開発者 | 開発環境のみ | [承認者] | 月次 | +| 閲覧者 | 読み取りのみ | [承認者] | 四半期 | + +**アクセスレビュー**: +- 頻度: [頻度] +- 実施者: [担当者] +- レビュー内容: [内容] + +### 12.3 脆弱性管理 + +脆弱性の検出と対応プロセスを記載します。 + +**脆弱性スキャン**: +- ツール: [ツール名] +- 頻度: [頻度] +- 対象: [対象システム] + +**パッチ適用**: + +| 脆弱性レベル | 対応期限 | 承認プロセス | +|--------------|----------|--------------| +| Critical | 24時間以内 | 緊急変更 | +| High | 7日以内 | 通常変更 | +| Medium | 30日以内 | 通常変更 | +| Low | 90日以内 | 計画変更 | + +### 12.4 DevSecOps: CI/CDパイプラインのセキュリティ + +**【重要】Shift Left Security - 開発の早期段階でセキュリティを組み込む** + +DevSecOpsは、従来の「開発→テスト→運用→セキュリティチェック」というフローを変革し、開発の初期段階からセキュリティを組み込む実践です。 + +**DevSecOpsの原則**: +- セキュリティは全員の責任（開発者・運用者・セキュリティチーム） +- 自動化されたセキュリティチェックをCI/CDパイプラインに組み込む +- 早期発見・早期修正によるコスト削減 +- 継続的なセキュリティ改善 + +**CI/CDパイプラインのセキュリティゲート**: + +```mermaid +graph LR + Code[コード作成] --> Commit[Git コミット] + Commit --> SecretScan[シークレットスキャン] + SecretScan --> SAST[SAST: 静的解析] + SAST --> DepScan[依存関係スキャン] + DepScan --> Build[ビルド] + Build --> ContainerScan[コンテナスキャン] + ContainerScan --> Deploy[デプロイ: ステージング] + Deploy --> DAST[DAST: 動的解析] + DAST --> ProdDeploy[本番デプロイ] + ProdDeploy --> Runtime[ランタイム保護] +``` + +#### 12.4.1 SAST（静的アプリケーションセキュリティテスト） + +**目的**: ソースコードの脆弱性を自動検出 + +**実装内容**: + +| 項目 | 内容 | +|------|------| +| **ツール** | SonarQube / Checkmarx / Snyk Code / Semgrep | +| **実施タイミング** | PR作成時、マージ前（必須）、定期実行（週次） | +| **検出対象** | SQLインジェクション、XSS、CSRF、ハードコードされたシークレット、安全でない関数使用 | +| **閾値設定** | Critical/High: ビルド失敗、Medium: 警告、Low: 情報 | +| **レポート** | PR コメントへの自動投稿、ダッシュボードでの可視化 | +| **False Positive対応** | ホワイトリスト管理、定期レビュー | + +**実装例（GitHub Actions）**: +```yaml +- name: Run SAST with SonarQube + run: | + sonar-scanner \ + -Dsonar.projectKey=${{ github.repository }} \ + -Dsonar.qualitygate.wait=true \ + -Dsonar.qualitygate.timeout=300 +``` + +#### 12.4.2 依存関係の脆弱性スキャン（SCA: Software Composition Analysis） + +**目的**: サードパーティライブラリの既知脆弱性を検出 + +**実装内容**: + +| 項目 | 内容 | +|------|------| +| **ツール** | Snyk / Dependabot / Trivy / OWASP Dependency-Check | +| **実施タイミング** | PR作成時、日次スキャン、デプロイ前 | +| **検出対象** | npm/pip/maven等のパッケージ、既知脆弱性（CVE）、ライセンス違反 | +| **自動修正** | Dependabot/Snykによる自動PR作成 | +| **閾値設定** | Critical: 即座に修正、High: 7日以内、Medium: 30日以内 | +| **除外ルール** | False Positiveやパッチ未提供の脆弱性を一時的に除外 | + +**対応フロー**: +1. 脆弱性検出 → Slack/GitHub Issue通知 +2. 自動PR作成（パッチ適用可能な場合） +3. 開発チームがレビュー・マージ +4. 修正不可能な場合: リスク受容判断または代替パッケージ検討 + +#### 12.4.3 コンテナイメージスキャン + +**目的**: コンテナイメージのOS/アプリケーション層の脆弱性検出 + +**実装内容**: + +| 項目 | 内容 | +|------|------| +| **ツール** | Trivy / Clair / Anchore / Snyk Container | +| **実施タイミング** | イメージビルド後、レジストリへのプッシュ前、定期スキャン（日次） | +| **検出対象** | OS パッケージ脆弱性、アプリケーション依存関係、設定不備（CIS Benchmark） | +| **閾値設定** | Critical: デプロイ不可、High: 承認必須、Medium以下: 警告 | +| **ベースイメージ戦略** | 最小限のイメージ使用（alpine/distroless）、定期的な再ビルド | + +**実装例（GitLab CI）**: +```yaml +container_scanning: + image: aquasec/trivy:latest + script: + - trivy image --exit-code 1 --severity CRITICAL,HIGH $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA +``` + +#### 12.4.4 DAST（動的アプリケーションセキュリティテスト） + +**目的**: 稼働中のアプリケーションに対する実際の攻撃シミュレーション + +**実装内容**: + +| 項目 | 内容 | +|------|------| +| **ツール** | OWASP ZAP / Burp Suite / Acunetix | +| **実施タイミング** | ステージング環境デプロイ後、本番デプロイ前、週次定期実行 | +| **検出対象** | XSS、SQLインジェクション、認証バイパス、CSRF、セキュリティヘッダー不備 | +| **実施環境** | ステージング環境（本番と同等の構成） | +| **テストシナリオ** | 自動スキャン + 手動ペネトレーションテスト（重要機能） | + +#### 12.4.5 シークレットスキャン（ハードコード検出） + +**目的**: ソースコード内の機密情報（パスワード、APIキー等）の漏洩防止 + +**実装内容**: + +| 項目 | 内容 | +|------|------| +| **ツール** | git-secrets / TruffleHog / Gitleaks / GitHub Secret Scanning | +| **実施タイミング** | コミット時（pre-commit hook）、PR作成時、リポジトリ全体の定期スキャン | +| **検出対象** | AWS/GCPアクセスキー、API トークン、パスワード、秘密鍵、証明書 | +| **対応** | コミット拒否、検出時の即時無効化、インシデント記録 | +| **False Positive対応** | ホワイトリスト設定、サンプルコードの除外 | + +**実装例（pre-commit hook）**: +```bash +#!/bin/sh +gitleaks protect --staged --verbose +``` + +#### 12.4.6 Infrastructure as Code (IaC) セキュリティスキャン + +**目的**: Terraform/CloudFormation等のインフラコードのセキュリティ設定不備を検出 + +**実装内容**: + +| 項目 | 内容 | +|------|------| +| **ツール** | tfsec / Checkov / Terraform Sentinel / CloudFormation Guard | +| **実施タイミング** | PR作成時、terraform apply前 | +| **検出対象** | S3バケットの公開設定、暗号化未設定、過度な権限、セキュリティグループの0.0.0.0/0許可 | +| **ポリシー** | CIS Benchmark、NIST、PCI DSS準拠チェック | +| **修正支援** | 自動修正候補の提示 | + +**実装例（Terraform）**: +```yaml +- name: Run tfsec + run: tfsec . --soft-fail +``` + +#### 12.4.7 ランタイムセキュリティ保護 + +**目的**: 本番環境での異常な振る舞いの検出と防御 + +**実装内容**: + +| 項目 | 内容 | +|------|------| +| **ツール** | Falco / Aqua Security / Sysdig Secure | +| **監視対象** | 予期しないプロセス起動、ファイル改ざん、異常なネットワーク通信、権限昇格試行 | +| **対応** | アラート通知、自動遮断（設定に応じて）、フォレンジック情報の記録 | +| **ポリシー** | Kubernetesセキュリティポリシー、Pod Security Standards準拠 | + +#### 12.4.8 セキュリティメトリクスとダッシュボード + +**可視化する指標**: + +| メトリクス | 測定内容 | 目標値 | +|-----------|----------|--------| +| **Mean Time to Remediate (MTTR)** | 脆弱性発見から修正までの平均時間 | Critical: 24時間以内、High: 7日以内 | +| **脆弱性密度** | コード1000行あたりの脆弱性数 | < 0.5件/1000行 | +| **スキャンカバレッジ** | スキャン対象のコード/リポジトリの割合 | 100% | +| **セキュリティゲート通過率** | CI/CDパイプラインでのセキュリティチェック通過率 | > 95% | +| **False Positive率** | 誤検知の割合 | < 10% | + +**ダッシュボード構成**: +- 脆弱性の重大度別分布 +- 修正状況のトレンド +- 各セキュリティツールの検出数 +- MTTR のトレンド + +#### 12.4.9 セキュリティチャンピオン制度 + +**目的**: 開発チーム内にセキュリティの専門知識を浸透させる + +**実施内容**: +- 各開発チームにセキュリティチャンピオンを配置 +- 定期的なセキュリティトレーニング（月次） +- 脆弱性レビュー会議への参加 +- セキュリティツールの使い方教育 + +#### 12.4.10 DevSecOps成熟度評価 + +**成熟度レベル**: + +| レベル | 状態 | 特徴 | +|--------|------|------| +| **Level 1: 基本** | セキュリティチェックなし | 本番デプロイ後にセキュリティ問題が発覚 | +| **Level 2: 管理** | 手動セキュリティレビュー | リリース前に手動でセキュリティチェック | +| **Level 3: 自動化** | CI/CDに基本的なスキャン統合 | SAST、依存関係スキャンを自動実行 | +| **Level 4: 最適化** | 包括的な自動化と継続的改善 | 全セキュリティゲート実装、メトリクス測定 | +| **Level 5: イノベーション** | 予測的セキュリティ | AIによる脆弱性予測、自動修正 | + +**現在のレベル**: [レベルを記載] +**目標レベル**: [目標レベルを記載] +**達成計画**: [計画を記載] + +### 12.5 セキュリティインシデント対応 + +セキュリティインシデントの対応手順を記載します。 + +**セキュリティインシデント分類**: + +| レベル | 定義 | 例 | 対応時間 | +|--------|------|-----|----------| +| L1 | 重大な侵害 | データ漏洩、ランサムウェア | 即時 | +| L2 | 侵害の疑い | 不正アクセス試行 | 1時間以内 | +| L3 | セキュリティ違反 | ポリシー違反 | 24時間以内 | + +**対応フロー**: + +```mermaid +graph TD + Detect[検知] --> Contain[封じ込め] + Contain --> Eradicate[根絶] + Eradicate --> Recover[復旧] + Recover --> PostIncident[事後対応] + PostIncident --> Improve[改善] +``` + +**インシデント対応チーム（CSIRT）**: +- リーダー: [担当者] +- メンバー: [担当者リスト] +- 外部連絡先: [セキュリティベンダー、警察等] + +### 12.6 コンプライアンス + +法規制・コンプライアンス要件への対応を記載します。 + +**適用法規制**: +- [法規制名]: [要件概要] +- [法規制名]: [要件概要] + +**監査対応**: +- 内部監査: [頻度・実施者] +- 外部監査: [頻度・監査法人] +- 証跡管理: [保管方法・期間] + +--- + +## 13. キャパシティ管理 + +### 13.1 キャパシティ管理方針 + +キャパシティ管理の基本方針を記載します。 + +**キャパシティ管理の目的**: +- サービス品質の維持 +- コストの最適化 +- 将来の需要予測と計画 + +### 13.2 キャパシティ監視 + +監視対象リソースと閾値を記載します。 + +| リソース | 現在の使用率 | 警告閾値 | 限界閾値 | 対応アクション | +|----------|--------------|----------|----------|----------------| +| CPU | [%] | 70% | 85% | [アクション] | +| メモリ | [%] | 75% | 90% | [アクション] | +| ディスク | [%] | 80% | 90% | [アクション] | +| ネットワーク帯域 | [%] | 70% | 85% | [アクション] | + +### 13.3 キャパシティ計画 + +将来の需要予測と増強計画を記載します。 + +**需要予測**: + +| 期間 | 予想ユーザー数 | 予想トラフィック | 必要リソース | +|------|----------------|------------------|--------------| +| 3ヶ月後 | [数値] | [数値] | [内容] | +| 6ヶ月後 | [数値] | [数値] | [内容] | +| 1年後 | [数値] | [数値] | [内容] | + +**増強計画**: +- 実施時期: [時期] +- 増強内容: [内容] +- 見積もりコスト: [金額] + +### 13.4 スケーリング戦略 + +スケーリングの方針と実装を記載します。 + +**スケーリング方式**: +- 垂直スケーリング（スケールアップ）: [適用箇所] +- 水平スケーリング（スケールアウト）: [適用箇所] + +**オートスケーリング設定**: + +| 対象 | スケールアウト条件 | スケールイン条件 | 最小/最大インスタンス数 | +|------|-------------------|------------------|------------------------| +| [対象1] | [条件] | [条件] | [最小数]/[最大数] | +| [対象2] | [条件] | [条件] | [最小数]/[最大数] | + +--- + +## 14. コスト管理とFinOps + +### 14.1 FinOps: クラウド財務管理の原則と文化 + +**【重要】FinOpsは単なるコスト削減ではなく、ビジネス価値の最大化を目指す文化** + +**FinOpsの定義**: +FinOps（Financial Operations）は、クラウドの変動費モデルにおいて、エンジニアリング・財務・ビジネスチームが協力し、データドリブンな支出決定を通じてビジネス価値を最大化するための実践です。 + +**FinOpsの3つの柱**: + +#### 1. チーム間のコラボレーション + +| ステークホルダー | 役割 | 責任 | +|--------------|------|------| +| **エンジニアリングチーム** | リソース利用の最適化 | アーキテクチャ設計、リソース選定、コスト効率的な実装 | +| **財務チーム** | 予算管理と予測 | 予算配分、コスト予測、支出承認、財務レポート | +| **ビジネスチーム** | 価値とコストのバランス | ビジネス要件定義、投資判断、ROI評価 | +| **FinOpsチーム** | 調整とガバナンス | コスト可視化、ポリシー策定、教育、ツール提供 | + +**コラボレーションモデル**: +- 月次FinOpsレビュー会議（全ステークホルダー参加） +- コストアラート時の迅速なコミュニケーション +- 四半期ごとのコスト最適化ワークショップ +- チーム別コスト予算とShowback/Chargebackの実施 + +#### 2. データドリブンな意思決定 + +**可視化すべきメトリクス**: + +| メトリクス | 測定単位 | 目標値 | ビジネスへの影響 | +|-----------|---------|--------|----------------| +| **Unit Economics** | コスト/ユーザー、コスト/トランザクション | 前月比±5%以内 | ユーザー獲得コストの最適化 | +| **Cloud Efficiency** | 実利用率/プロビジョニング率 | > 70% | 過剰プロビジョニングの削減 | +| **Cost Anomaly** | 異常コスト発生頻度 | < 5件/月 | 予期しないコスト増加の防止 | +| **RI/SP Coverage** | コミットメント適用率 | > 70% | 割引適用率の向上 | +| **Waste Ratio** | 未使用リソースコスト/総コスト | < 10% | 無駄の削減 | + +**レポーティング体制**: +- **リアルタイムダッシュボード**: Grafana/CloudWatch/Datadog +- **日次レポート**: コスト異常の早期検出（Slack通知） +- **週次レポート**: サービス別・チーム別コストトレンド +- **月次レポート**: 予実対比、Unit Economics分析、最適化提案 +- **四半期レポート**: 経営層向けコスト戦略レビュー + +#### 3. ビジネス価値の最大化 + +**コスト削減 vs 価値創出のバランス**: + +FinOpsは「安ければ良い」ではなく、「ビジネス価値に見合ったコスト」を追求します。 + +| 判断基準 | 削減重視 | 価値重視 | 推奨アプローチ | +|---------|---------|---------|--------------| +| 本番環境の可用性 | コスト削減のため99.9%に下げる | ビジネス要件を満たす99.99%を維持 | **価値重視** | +| 開発環境 | 夜間・週末は自動停止 | 24時間稼働 | **削減重視** | +| データ分析基盤 | 最小構成 | ビジネスインサイト獲得のため十分投資 | **価値重視** | +| 監視ツール | 無料ツールのみ | 有償APMで開発生産性向上 | **バランス** | + +**投資判断のフレームワーク**: +1. コスト削減施策のROI計算（削減額 vs 実装工数） +2. パフォーマンス改善の価値評価（UX向上 vs コスト増） +3. セキュリティ投資の必須性判断（リスク vs コスト） +4. 新技術導入の総保有コスト（TCO）評価 + +**FinOps成熟度モデル**: + +| フェーズ | 特徴 | アクション | +|---------|------|----------| +| **Crawl（初期）** | コストの可視化 | タグ付け、Cost Explorer活用、基本的なレポート | +| **Walk（発展）** | 予測と最適化 | 予算管理、アラート設定、RI/SP購入、無駄の削減 | +| **Run（成熟）** | 自動化と文化 | Unit Economics追跡、自動最適化、FinOps文化の浸透 | + +**現在のフェーズ**: [Crawl / Walk / Run] +**目標フェーズ**: [フェーズ] +**達成計画**: [計画] + +### 14.2 コスト構造とサービス別内訳 + +運用コストの内訳を記載します。 + +**【重要】クラウドネイティブ環境では、AWSコストの詳細な内訳把握が必須** + +**AWSコストの詳細内訳**: + +| サービスカテゴリ | サービス | 月額コスト | 年額コスト | 構成比 | コスト最適化施策 | +|----------------|---------|------------|------------|--------|----------------| +| **コンピュート** | Lambda | [金額] | [金額] | [XX]% | Reserved Concurrency見直し、メモリサイズ最適化 | +| **コンピュート** | ECS/EKS | [金額] | [金額] | [XX]% | Fargate Spot活用、EC2 Spot Instances活用 | +| **データベース** | RDS | [金額] | [金額] | [XX]% | Reserved Instances購入、Multi-AZの必要性見直し | +| **データベース** | DynamoDB | [金額] | [金額] | [XX]% | On-Demand vs Provisioned見直し、Auto Scaling設定 | +| **ストレージ** | S3 | [金額] | [金額] | [XX]% | ライフサイクルポリシー設定（IA/Glacier移行） | +| **ストレージ** | EBS | [金額] | [金額] | [XX]% | gp2→gp3移行、未使用ボリューム削除 | +| **ネットワーク** | Data Transfer | [金額] | [金額] | [XX]% | CloudFront活用、リージョン間転送削減 | +| **ネットワーク** | ALB/NLB | [金額] | [金額] | [XX]% | LCU使用量最適化、アイドルロードバランサー削除 | +| **監視** | CloudWatch | [金額] | [金額] | [XX]% | ログ保管期間短縮、メトリクス削減、S3へのエクスポート | +| **その他** | API Gateway | [金額] | [金額] | [XX]% | キャッシング活用、リクエスト数削減 | +| **その他** | SQS/SNS | [金額] | [金額] | [XX]% | メッセージサイズ最適化、ロングポーリング活用 | +| **サポート** | AWS Support | [金額] | [金額] | [XX]% | プラン見直し（Developer/Business/Enterprise） | +| **その他コスト** | 人件費 | [金額] | [金額] | [XX]% | [内訳] | +| **その他コスト** | サードパーティツール | [金額] | [金額] | [XX]% | Datadog、New Relic等 | +| **合計** | | [金額] | [金額] | 100% | | + +**コスト配分（タグ別）**: + +| タグキー | タグ値 | 月額コスト | 構成比 | +|---------|--------|------------|--------| +| Environment | production | [金額] | [XX]% | +| Environment | staging | [金額] | [XX]% | +| Environment | development | [金額] | [XX]% | +| Service | api-backend | [金額] | [XX]% | +| Service | web-frontend | [金額] | [XX]% | +| Service | batch-processing | [金額] | [XX]% | +| Team | platform | [金額] | [XX]% | +| Team | application | [金額] | [XX]% | + +### 14.3 コスト最適化施策 + +コスト削減・最適化の取り組みを記載します。 + +**実施中の施策**: +1. [施策1]: [効果] +2. [施策2]: [効果] + +**計画中の施策**: +1. [施策1]: [期待効果] +2. [施策2]: [期待効果] + +### 14.4 コスト監視 + +コストの監視とアラート設定を記載します。 + +**コスト監視**: +- ツール: [ツール名] +- 監視頻度: [頻度] +- レポート: [頻度・宛先] + +**コストアラート**: +- 月次予算超過アラート: [閾値] +- 異常なコスト増加アラート: [条件] + +### 14.5 タグ戦略とコスト配分 + +**【重要】適切なタグ戦略は、コスト管理の成否を決める** + +**必須タグの定義**: + +| タグキー | 必須/推奨 | 設定値 | 用途 | +|---------|----------|--------|------| +| Environment | 必須 | production / staging / development / test | 環境別コスト分析 | +| Service | 必須 | [サービス名] | サービス別コスト分析 | +| Team | 必須 | [チーム名] | チーム別コスト配分、予算管理 | +| CostCenter | 必須 | [コストセンター番号] | 会計上のコスト配分 | +| Project | 推奨 | [プロジェクト名] | プロジェクト別コスト追跡 | +| Owner | 推奨 | [所有者メールアドレス] | リソース所有者の特定 | +| ManagedBy | 推奨 | terraform / cloudformation / manual | リソース管理方法の識別 | +| Compliance | 推奨 | pci-dss / hipaa / gdpr / none | コンプライアンス要件の識別 | +| BackupPolicy | 推奨 | daily / weekly / none | バックアップポリシーの識別 | +| AutoShutdown | 推奨 | yes / no | 自動停止対象の識別（開発環境等） | + +**タグ付けルール**: +- すべての課金対象リソースに必須タグを付与 +- タグの命名規則: 小文字、ハイフン区切り（例: api-backend） +- タグ値の標準化: 定義された値のみ使用（自由記述禁止） +- 自動タグ付け: Terraform/CloudFormationでデフォルトタグを設定 + +**タグポリシーの強制**: +- AWS Organizations Tag Policiesで必須タグを強制 +- タグ未設定リソースの定期検出（AWS Config Rules） +- タグ未設定リソースへのアラート・自動停止 + +**Cost Explorerの活用**: + +**日次コストレポート**: +- 配信先: [メールアドレス/Slackチャンネル] +- 内容: 前日比コスト増減、上位コスト発生リソース +- 閾値: 前日比[XX]%増加で アラート + +**月次コスト予測**: +- 実施タイミング: 毎月[XX]日 +- 予測方法: Cost Explorerの予測機能 +- アクション: 予算超過予測時の対応プロセス + +**異常検知アラート**: +- AWS Cost Anomaly Detection の有効化 +- 異常検知閾値: [金額]または[XX]% +- 通知先: [通知先] +- 対応プロセス: [プロセス] + +**コスト最適化レポート**: +- 頻度: 月次 +- ツール: AWS Cost Explorer、Trusted Advisor、Compute Optimizer +- レビュー項目: + - 未使用リソース（EBS、EIP、ロードバランサー） + - 低使用率リソース（RDS、EC2インスタンス） + - RIカバレッジとUtilization + - Savings Plansカバレッジ + +### 14.6 Savings PlansとReserved Instances戦略 + +**【重要】適切なコミットメント購入で30-70%のコスト削減が可能** + +**Savings Plans vs Reserved Instances比較**: + +| 項目 | Compute Savings Plans | EC2 Instance Savings Plans | Reserved Instances | +|------|----------------------|---------------------------|-------------------| +| 割引率 | 最大66% | 最大72% | 最大72% | +| 柔軟性 | 高（EC2、Fargate、Lambda全対応） | 中（EC2のみ、ファミリー変更可） | 低（インスタンスタイプ固定） | +| コミットメント | 時間当たりの使用額（$/hour） | 時間当たりの使用額（$/hour） | インスタンス数 | +| 推奨用途 | 多様なサービス利用 | EC2中心だがサイズ変動あり | EC2で安定した利用 | + +**購入戦略**: + +**1. 利用パターン分析（3-6ヶ月）**: +- Cost Explorerで過去の使用量を分析 +- 最小使用量（ベースライン）を特定 +- ピーク時の変動幅を把握 + +**2. コミットメント対象の選定**: + +| リソース | 推奨コミットメント | 購入量の目安 | 理由 | +|---------|------------------|------------|------| +| 本番RDS | RDS Reserved Instances | 最小使用量の80-90% | 安定稼働、大幅割引 | +| 本番EC2（常時稼働） | EC2 Instance Savings Plans | 最小使用量の70-80% | ある程度の柔軟性維持 | +| Lambda/Fargate混在 | Compute Savings Plans | 最小使用量の60-70% | 最大の柔軟性 | +| 開発/検証環境 | On-Demand | 購入しない | 使用量が不安定 | + +**3. コミットメント期間の選択**: + +| 期間 | 割引率 | 支払いオプション | 推奨ケース | +|------|--------|----------------|----------| +| 1年・全額前払い | 高 | 初期コスト大 | キャッシュフロー良好、確実な利用 | +| 1年・一部前払い | 中 | バランス型 | 一般的な推奨 | +| 1年・前払いなし | 中 | 初期コスト不要 | 予算制約あり | +| 3年・全額前払い | 最高 | 初期コスト大 | 長期利用確実、最大割引 | +| 3年・前払いなし | 高 | 初期コスト不要 | 長期利用確実、キャッシュフロー重視 | + +**4. 購入計画**: + +| サービス | コミットメント種別 | 購入量 | 期間 | 支払いオプション | 年間節約額 | +|---------|------------------|--------|------|----------------|----------| +| [サービス1] | [種別] | [量] | [期間] | [オプション] | [金額] | +| [サービス2] | [種別] | [量] | [期間] | [オプション] | [金額] | +| **合計** | | | | | [金額] | + +**5. 購入後の管理**: +- RI/SPのUtilization監視（目標: 95%以上） +- カバレッジ監視（目標: [XX]%以上） +- 四半期ごとの購入見直し +- 未使用RI/SPの Marketplace出品検討 + +**Spot Instances活用**: + +| ワークロード | Spot使用可否 | 推奨構成 | 期待削減率 | +|-------------|------------|---------|----------| +| バッチ処理 | 最適 | 100% Spot | 70-90% | +| 開発環境 | 適 | 100% Spot | 70-90% | +| ステートレスなWebワーカー | 適 | 50-70% Spot + On-Demand | 35-60% | +| データベース | 不適 | On-Demand/RI | 0% | +| ステートフルアプリ | 不適 | On-Demand/RI | 0% | + +--- + +## 15. レジリエンステストとChaos Engineering（オプション） + +**【重要】このセクションは高可用性・高レジリエンスを目指すシステムにのみ適用** + +**適用判断基準**: + +以下のすべてに該当する場合、Chaos Engineeringの導入を強く推奨します： + +| 判断基準 | 条件 | 該当可否 | +|---------|------|---------| +| **SLA要件** | 99.99%以上の可用性が必要 | ✓ / ✗ | +| **ビジネス影響** | ダウンタイムが重大な金銭的損失をもたらす | ✓ / ✗ | +| **運用成熟度** | 基本的な監視・アラート・インシデント対応が確立済み | ✓ / ✗ | +| **チームスキル** | SRE/DevOpsチームがシステムアーキテクチャを深く理解 | ✓ / ✗ | + +**該当数による推奨**: +- **4つすべて該当**: Chaos Engineering導入を強く推奨 +- **3つ該当**: 段階的導入を検討 +- **2つ以下**: 基本的な運用の成熟化を優先（Chaos Engineeringは時期尚早） + +### 15.1 Chaos Engineeringとは + +**定義**: +Chaos Engineering（カオスエンジニアリング）は、本番環境で意図的に障害を注入し、システムの耐障害性を検証・改善する実践です。 + +**目的**: +- 未知の障害に対するシステムの耐性を高める +- 障害発生時の影響範囲を事前に把握する +- 自動復旧メカニズムの有効性を検証する +- チームの障害対応能力を向上させる + +**Chaos Engineeringの原則（Netflix Chaos Monkey）**: +1. 定常状態の定義（正常な動作の基準） +2. 仮説の立案（障害時の予想される振る舞い） +3. 実際の障害注入（実験） +4. 観察と検証（仮説との比較） +5. 改善と自動化 + +### 15.2 段階的な導入アプローチ + +**フェーズ1: 非本番環境でのテスト（必須）** + +| 実験内容 | 対象 | 期待結果 | ツール | +|---------|------|----------|--------| +| **Pod強制終了** | Kubernetes Pod | Pod再起動、サービス無停止 | kubectl delete pod | +| **ネットワーク遅延** | サービス間通信 | タイムアウト処理、リトライ機能の動作確認 | toxiproxy | +| **CPU負荷** | コンテナ | HPA発動、スケールアウト | stress-ng | +| **メモリ逼迫** | コンテナ | OOM Killer発動、Pod再起動 | stress-ng | + +**判定基準**: +- すべての実験で期待通りの結果が得られること +- 復旧時間が SLO 内に収まること +- アラートが正常に発火すること + +**フェーズ2: 本番環境でのカナリア実験（推奨）** + +**実施条件**: +- 非本番環境で十分な検証が完了 +- オンコール体制が整備済み +- ロールバック手順が確立 +- ビジネス影響が最小の時間帯を選定 + +**実験例**: + +| 実験内容 | スコープ | 開始条件 | 停止条件 | +|---------|---------|---------|---------| +| **単一AZの障害** | 1つのAZのトラフィックをブロック | 営業時間外、トラフィック低 | エラーレート3%超過、または5分経過 | +| **依存サービスの遅延** | 外部API呼び出しに500ms遅延注入 | 営業時間外 | タイムアウト率5%超過 | +| **データベース接続数制限** | DB接続数を通常の50%に制限 | ステージング環境で検証済み | 接続エラー発生 | + +**安全装置（Abort Conditions）**: +- ユーザー影響が閾値を超えた場合（エラーレート、レスポンスタイム） +- SLOバジェットを消費しすぎた場合 +- 手動での緊急停止 + +**フェーズ3: 自動化と継続的実行（高度）** + +- CI/CDパイプラインへの組み込み +- 定期的な自動実行（週次・月次） +- GameDay（計画的障害演習）の実施 + +### 15.3 Chaos Engineeringツール + +**ツール選定**: + +| ツール | 対象 | 特徴 | 推奨度 | +|--------|------|------|--------| +| **Litmus Chaos** | Kubernetes | CNCF プロジェクト、Kubernetes ネイティブ、豊富な実験テンプレート | ⭐⭐⭐⭐⭐ | +| **Chaos Mesh** | Kubernetes | CNCF プロジェクト、Web UI、スケジュール実行 | ⭐⭐⭐⭐⭐ | +| **AWS FIS** | AWS | AWSマネージドサービス、安全装置内蔵、EC2/ECS/RDS対応 | ⭐⭐⭐⭐ | +| **Gremlin** | 汎用 | 商用、エンタープライズサポート、充実したUI | ⭐⭐⭐⭐ | +| **Chaos Toolkit** | 汎用 | オープンソース、Python ベース、拡張可能 | ⭐⭐⭐ | +| **Pumba** | Docker/Kubernetes | 軽量、ネットワーク障害特化 | ⭐⭐⭐ | + +**ツール選定基準**: +- Kubernetes環境: Litmus Chaos または Chaos Mesh +- AWS中心: AWS FIS +- エンタープライズサポート必要: Gremlin + +### 15.4 実験カタログとシナリオ + +#### 15.4.1 インフラレベルの実験 + +| 実験名 | 障害内容 | 検証項目 | 実装方法 | +|--------|----------|----------|----------| +| **Pod Killer** | ランダムにPodを削除 | Pod再起動、サービス継続性 | Litmus: pod-delete | +| **Node Drain** | ノードを意図的にドレイン | Pod再スケジューリング、データ永続性 | kubectl drain | +| **AZ障害** | 1つのAZを分離 | マルチAZ構成の有効性 | AWS FIS: az-failure | +| **ディスク満杯** | ディスク容量を消費 | ディスク監視アラート、自動クリーンアップ | stress-ng --hdd | + +#### 15.4.2 ネットワークレベルの実験 + +| 実験名 | 障害内容 | 検証項目 | 実装方法 | +|--------|----------|----------|----------| +| **ネットワーク遅延** | 通信に遅延注入（100-500ms） | タイムアウト設定の妥当性、UX影響 | Chaos Mesh: NetworkChaos | +| **パケットロス** | パケット損失（5-20%） | リトライ機構、エラーハンドリング | toxiproxy | +| **帯域制限** | 帯域幅を制限 | 大容量データ転送の影響 | tc (traffic control) | +| **DNS障害** | DNS応答遅延・失敗 | DNS キャッシュ、フォールバック | Chaos Mesh: DNSChaos | + +#### 15.4.3 アプリケーションレベルの実験 + +| 実験名 | 障害内容 | 検証項目 | 実装方法 | +|--------|----------|----------|----------| +| **CPU負荷** | CPU使用率を90%以上に | HPA、パフォーマンス劣化 | Chaos Mesh: StressChaos | +| **メモリリーク** | メモリを徐々に消費 | OOM Killer、Pod再起動 | stress-ng --vm | +| **API エラー注入** | 特定APIが500エラーを返す | サーキットブレーカー、フォールバック | Fault Injection (Istio) | +| **データベース遅延** | DB応答を遅延 | 接続プール枯渇対策 | Chaos Toolkit | + +### 15.5 GameDay（障害演習）の実施 + +**GameDayとは**: +チーム全体で計画的に障害を起こし、対応手順を訓練するイベント。 + +**実施計画**: + +| 項目 | 内容 | +|------|------| +| **頻度** | 四半期に1回 | +| **参加者** | SREチーム、開発チーム、オンコール担当 | +| **所要時間** | 2-4時間 | +| **シナリオ** | 事前に用意したインシデントシナリオ（複合障害） | +| **評価項目** | MTTD（検知時間）、MTTR（復旧時間）、対応品質 | + +**GameDayシナリオ例**: +1. **マルチAZ障害**: 1つのAZが完全にダウン → 残りのAZでサービス継続を確認 +2. **データベースフェイルオーバー**: プライマリDBダウン → レプリカへの自動フェイルオーバー確認 +3. **依存サービス障害**: 決済APIダウン → フォールバック処理、キューイング確認 +4. **複合障害**: ネットワーク遅延 + CPU高負荷 → 複数の問題への同時対応能力確認 + +**GameDay後のアクション**: +- 振り返り会議（ポストモーテム） +- 改善項目の洗い出し +- ランブック（対応手順書）の更新 +- 自動化できる箇所の特定 + +### 15.6 成功指標とメトリクス + +**Chaos Engineering成功の測定**: + +| メトリクス | 測定方法 | 目標値 | +|-----------|---------|--------| +| **実験実施数** | 月次実行回数 | 月[XX]回以上 | +| **システムレジリエンス** | 障害注入時のサービス継続率 | 99%以上 | +| **未知の障害検出数** | 実験で発見された新たな脆弱性 | 四半期[XX]件 | +| **MTTR改善** | 実験前後のMTTR比較 | [XX]%短縮 | +| **SLO達成率** | 実験中のSLO遵守率 | 100% | + +**改善サイクル**: +1. 実験実施 +2. 脆弱性発見 +3. 対策実装 +4. 再実験で検証 +5. 自動化 + +### 15.7 注意事項とリスク管理 + +**実施前の必須条件**: +- ✅ 完全なバックアップ（データ・設定） +- ✅ ロールバック手順の確立 +- ✅ 監視・アラートの整備 +- ✅ オンコール体制の確保 +- ✅ ビジネスサイドへの事前通知 + +**禁止事項**: +- ❌ 本番環境で未検証の実験を実施 +- ❌ ピーク時間帯・重要イベント期間中の実施 +- ❌ 複数の実験を同時実施 +- ❌ 停止条件を設定せずに実行 +- ❌ チームメンバーへの通知なしで実施 + +**インシデント発生時の対応**: +1. 即座に実験を停止 +2. 通常のインシデント対応フローに従う +3. ポストモーテムで実験設計を見直し +4. 再発防止策の実装 + +### 15.8 導入ロードマップ + +**3ヶ月計画（推奨）**: + +| 月 | フェーズ | アクション | +|----|---------|----------| +| **1ヶ月目** | 準備 | ツール選定、非本番環境セットアップ、チームトレーニング | +| **2ヶ月目** | 非本番実験 | ステージング環境で10種類の実験実施、脆弱性修正 | +| **3ヶ月目** | 本番実験 | 本番環境で3種類の実験実施（低リスク）、GameDay開催 | + +**継続運用**: +- 月次: 定期的な実験実施（自動化） +- 四半期: GameDay開催 +- 半期: Chaos Engineering成熟度評価 + +--- + +## 16. 問題管理 + +### 16.1 問題管理方針 + +問題管理の基本方針を記載します。 + +**問題の定義**: +1つ以上のインシデントの根本原因、または潜在的なインシデントの原因 + +**問題管理の目的**: +- インシデントの根本原因の特定と除去 +- 既知のエラーの記録と回避策の提供 +- 再発防止策の実装 + +### 15.2 問題管理プロセス + +問題管理のフローを記載します。 + +```mermaid +graph TD + Incident[インシデント発生] --> Analysis[傾向分析] + Analysis --> Problem{問題として
管理すべきか？} + + Problem -->|Yes| Register[問題登録] + Problem -->|No| End1[終了] + + Register --> Investigate[根本原因分析] + Investigate --> Known[既知のエラー登録] + + Known --> Workaround[回避策の提供] + Known --> Solution[恒久対策の検討] + + Solution --> Implement[対策実装] + Implement --> Verify[効果検証] + Verify --> Close[クローズ] +``` + +### 15.3 既知のエラー管理 + +既知のエラーと回避策を記録します。 + +| エラーID | 問題概要 | 影響 | 回避策 | 恒久対策の状況 | +|----------|----------|------|--------|----------------| +| KE-001 | [概要] | [影響] | [回避策] | [状況] | +| KE-002 | [概要] | [影響] | [回避策] | [状況] | + +--- + +## 16. ナレッジ管理 + +### 16.1 ナレッジ管理方針 + +ナレッジの蓄積と共有の方針を記載します。 + +**ナレッジ管理の目的**: +- 運用ノウハウの蓄積と継承 +- 問題解決の効率化 +- 属人化の排除 + +### 16.2 ドキュメント体系 + +管理するドキュメントの種類と保管場所を記載します。 + +| ドキュメント種別 | 保管場所 | 更新頻度 | 管理者 | +|------------------|----------|----------|--------| +| 運用設計書 | [場所] | [頻度] | [担当] | +| 運用手順書 | [場所] | [頻度] | [担当] | +| 障害対応手順書 | [場所] | [頻度] | [担当] | +| FAQ | [場所] | [頻度] | [担当] | +| ポストモーテム | [場所] | 都度 | [担当] | + +### 16.3 ドキュメント管理ルール + +ドキュメントの作成・更新・レビューのルールを記載します。 + +**作成ルール**: +- テンプレートの使用 +- 命名規則の遵守 +- バージョン管理の実施 + +**更新ルール**: +- 変更履歴の記録 +- レビュープロセスの実施 +- 関連ドキュメントの同期更新 + +**レビュープロセス**: +- レビュー頻度: [頻度] +- レビュー担当: [担当者] +- レビュー基準: [基準] + +--- + +## 17. 継続的改善 + +### 17.1 改善活動方針 + +継続的改善の基本方針を記載します。 + +**改善の原則**: +- データドリブンな意思決定 +- 小さな改善の積み重ね +- チーム全体での取り組み +- 定期的な振り返りと学び + +### 17.2 改善プロセス + +改善活動のサイクルを記載します。 + +```mermaid +graph LR + Plan[計画
Plan] --> Do[実行
Do] + Do --> Check[評価
Check] + Check --> Act[改善
Act] + Act --> Plan +``` + +**改善活動の実施**: +- 週次: チーム振り返り +- 月次: メトリクスレビュー +- 四半期: 運用プロセスレビュー +- 年次: 運用戦略レビュー + +### 17.3 運用メトリクス + +運用品質を測定する指標を記載します。 + +| メトリクス | 目標値 | 測定方法 | レポート頻度 | +|------------|--------|----------|--------------| +| 可用性 | 99.9%以上 | [方法] | 月次 | +| MTBF（平均故障間隔） | [目標] | [方法] | 月次 | +| MTTR（平均復旧時間） | 30分以内 | [方法] | 月次 | +| 変更成功率 | 95%以上 | [方法] | 月次 | +| インシデント件数 | [目標] | [方法] | 月次 | +| デプロイ頻度 | [目標] | [方法] | 月次 | + +### 17.4 改善施策管理 + +改善施策の管理方法を記載します。 + +**改善施策リスト**: + +| 施策ID | 施策名 | 目的 | 担当 | 期限 | ステータス | +|--------|--------|------|------|------|------------| +| IMP-001 | [施策名] | [目的] | [担当] | [期限] | [ステータス] | +| IMP-002 | [施策名] | [目的] | [担当] | [期限] | [ステータス] | + +--- + +## 18. 運用ツール + +### 18.1 運用ツール一覧 + +使用する運用ツールを記載します。 + +| カテゴリ | ツール名 | 用途 | ライセンス | 管理者 | +|----------|----------|------|------------|--------| +| 監視 | [ツール名] | [用途] | [ライセンス] | [担当] | +| ログ管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| インシデント管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| 変更管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| CI/CD | [ツール名] | [用途] | [ライセンス] | [担当] | +| コミュニケーション | [ツール名] | [用途] | [ライセンス] | [担当] | + +### 18.2 ツール統合 + +ツール間の連携を記載します。 + +**統合フロー**: + +```mermaid +graph LR + Monitor[監視ツール] -->|アラート| Incident[インシデント管理] + Incident -->|通知| Chat[チャットツール] + Chat -->|トリガー| CICD[CI/CDツール] + CICD -->|ログ| LogTool[ログ管理ツール] + LogTool -->|メトリクス| Monitor +``` + +--- + +## 19. 付録 + +### 19.1 用語集 + +本ドキュメントで使用する用語の定義を記載します。 + +| 用語 | 定義 | +|------|------| +| SLO | Service Level Objective: サービスレベル目標 | +| SLI | Service Level Indicator: サービスレベル指標 | +| SLA | Service Level Agreement: サービスレベル合意 | +| MTTR | Mean Time To Repair: 平均復旧時間 | +| MTBF | Mean Time Between Failures: 平均故障間隔 | +| RPO | Recovery Point Objective: 目標復旧時点 | +| RTO | Recovery Time Objective: 目標復旧時間 | +| RACI | Responsible, Accountable, Consulted, Informed | + +### 19.2 参照ドキュメント + +関連ドキュメントへのリンクを記載します。 + +| ドキュメント名 | 場所/URL | 備考 | +|----------------|----------|------| +| システム設計書 | [リンク] | [備考] | +| セキュリティポリシー | [リンク] | [備考] | +| 運用手順書 | [リンク] | [備考] | + +### 19.3 連絡先 + +運用に関わる主要な連絡先を記載します。 + +| 役割 | 担当者 | 連絡先 | 対応時間 | +|------|--------|--------|----------| +| 運用マネージャー | [名前] | [連絡先] | [時間] | +| オンコール担当 | [名前] | [連絡先] | 24/365 | +| セキュリティ担当 | [名前] | [連絡先] | [時間] | + +### 19.4 承認 + +本ドキュメントの承認記録を記載します。 + +| 役割 | 氏名 | 承認日 | 署名 | +|------|------|--------|------| +| 作成者 | [名前] | [日付] | | +| レビュアー | [名前] | [日付] | | +| 承認者 | [名前] | [日付] | | + +--- + +## 運用設計書作成時の注意事項 + +本テンプレートを使用する際は、以下の点に注意してください： + +1. **プロジェクト特性に応じたカスタマイズ** + - すべてのセクションが必要とは限りません + - プロジェクトの規模や性質に応じて取捨選択してください + +2. **具体性の確保** + - 抽象的な記述ではなく、具体的な数値や手順を記載してください + - 「適切に」「十分に」などの曖昧な表現は避けてください + +3. **測定可能性** + - 目標値は測定可能な形で定義してください + - 測定方法も明記してください + +4. **継続的な更新** + - 運用開始後も定期的に見直し、更新してください + - 実態との乖離が生じないよう注意してください + +5. **ステークホルダーの合意** + - 関係者全員で内容を確認し、合意を形成してください + - 特にSLOや運用体制については十分な議論が必要です diff --git a/skills/operations-design/assets/templates/operations_design_template_ja.md b/skills/operations-design/assets/templates/operations_design_template_ja.md new file mode 100644 index 0000000..729efe9 --- /dev/null +++ b/skills/operations-design/assets/templates/operations_design_template_ja.md @@ -0,0 +1,1354 @@ +# 運用設計書 + +## ドキュメント情報 + +| 項目 | 内容 | +|------|------| +| ドキュメント名 | [サービス名] 運用設計書 | +| バージョン | [バージョン番号] | +| 作成日 | [YYYY-MM-DD] | +| 最終更新日 | [YYYY-MM-DD] | +| 作成者 | [作成者名] | +| 承認者 | [承認者名] | +| ステータス | [Draft / Review / Approved] | + +## 改訂履歴 + +| バージョン | 日付 | 変更内容 | 変更者 | +|------------|------|----------|--------| +| 0.1 | YYYY-MM-DD | 初版作成 | [名前] | + +--- + +## 1. 概要 + +### 1.1 目的 + +本ドキュメントの目的を記載します。 + +- 運用に求められる要件の明確化 +- システム運用に関わる関係者間の合意形成 +- 運用プロセスの標準化と最適化 +- 運用品質の向上と継続的改善 + +### 1.2 対象範囲 + +本運用設計書が対象とするシステム・サービスの範囲を記載します。 + +**対象システム**: +- [システム名・サービス名] + +**対象業務**: +- [業務名] + +**対象期間**: +- [運用開始予定日] ～ [運用終了予定日（該当する場合）] + +### 1.3 前提条件 + +運用設計における前提条件を記載します。 + +- システム開発が完了していること +- 運用環境が構築されていること +- 運用チームの体制が整っていること +- [その他の前提条件] + +### 1.4 制約条件 + +運用における制約事項を記載します。 + +- 予算制約: [金額や制約内容] +- リソース制約: [人員やインフラリソースの制約] +- 技術制約: [技術的な制約] +- 法規制・コンプライアンス: [該当する法規制] + +--- + +## 2. サービス概要 + +### 2.1 サービスの目的 + +サービスが提供する価値と目的を記載します。 + +**ビジネス目的**: +- [ビジネス上の目的] + +**提供価値**: +- [ユーザーに提供する価値] + +### 2.2 サービスの機能 + +主要な機能を記載します。 + +| 機能名 | 概要 | 重要度 | +|--------|------|--------| +| [機能1] | [機能の説明] | High / Medium / Low | +| [機能2] | [機能の説明] | High / Medium / Low | + +### 2.3 システム構成 + +システムのアーキテクチャと主要コンポーネントを記載します。 + +**アーキテクチャ図**: + +```mermaid +graph TB + subgraph "ユーザー層" + User[エンドユーザー] + end + + subgraph "アプリケーション層" + Web[Webサーバー] + App[アプリケーションサーバー] + end + + subgraph "データ層" + DB[(データベース)] + Cache[(キャッシュ)] + end + + User --> Web + Web --> App + App --> DB + App --> Cache +``` + +**主要コンポーネント**: + +| コンポーネント | 役割 | 技術スタック | 冗長化 | +|----------------|------|--------------|--------| +| [コンポーネント1] | [役割] | [技術] | Yes / No | +| [コンポーネント2] | [役割] | [技術] | Yes / No | + +### 2.4 外部連携 + +外部システムとの連携を記載します。 + +| 連携先 | 連携方式 | データフロー | 重要度 | +|--------|----------|--------------|--------| +| [システム名] | API / Batch / etc | [方向と内容] | High / Medium / Low | + +--- + +## 3. 運用方針と目標 + +### 3.1 運用基本方針 + +運用における基本的な方針を記載します。 + +1. **可用性重視**: [方針の詳細] +2. **セキュリティ優先**: [方針の詳細] +3. **継続的改善**: [方針の詳細] +4. **コスト最適化**: [方針の詳細] + +### 3.2 サービスレベル目標（SLO） + +**【重要】ユーザー中心のSLO設計原則**: + +SLOは「測りやすい指標」ではなく、「ユーザーが快適に使える範囲」を起点として設計します。 + +**設計アプローチ**: +1. **ユーザーの期待値を理解する** + - ユーザーはどの程度の応答速度を期待しているか + - どの程度のエラーなら許容できるか + - サービス停止はどの程度の影響を与えるか + +2. **ユーザー体験に基づいた目標設定** + - 「サーバーCPU使用率」ではなく「ユーザーが体感するレスポンスタイム」 + - 「データベース接続数」ではなく「ユーザーがエラーに遭遇する頻度」 + - 技術指標はユーザー体験指標の裏付けとして使用 + +3. **システム構成ごとの目標設定** + - 同期処理、非同期処理、バッチ処理でユーザー期待値は異なる + - それぞれに適切な目標値を設定 + +**SLO定義**: + +| システム構成/機能 | 指標名 | 目標値 | ユーザー視点での意味 | 測定方法 | 測定頻度 | +|-------------------|--------|--------|---------------------|----------|----------| +| [全体] | 可用性 | [例: 99.9%] | ユーザーがサービスを利用できる時間の割合 | [測定方法] | [頻度] | +| [Web同期リクエスト] | レスポンスタイム（P95） | [例: 500ms以下] | ユーザーが操作後に結果が表示されるまでの体感速度 | [測定方法] | [頻度] | +| [Web同期リクエスト] | エラーレート | [例: 0.1%以下] | ユーザーがエラーに遭遇する頻度 | [測定方法] | [頻度] | +| [非同期APIリクエスト] | 処理完了時間（P95） | [例: 5秒以内] | バックグラウンド処理が完了するまでの時間 | [測定方法] | [頻度] | +| [バッチ処理] | 処理完了時刻 | [例: 翌朝8時まで] | 業務開始時にデータが利用可能になっている状態 | [測定方法] | 日次 | +| [全体] | MTTR | [例: 30分以内] | 障害発生時にユーザーが待つ時間 | [測定方法] | [頻度] | + +### 3.3 サービスレベル指標（SLI） + +SLOを測定するための具体的な指標を記載します。 + +| SLI名 | 定義 | データソース | 計算式 | +|-------|------|--------------|--------| +| [SLI1] | [定義] | [ソース] | [計算式] | +| [SLI2] | [定義] | [ソース] | [計算式] | + +### 3.4 サービスレベル合意（SLA） + +顧客またはユーザーに対して約束するサービス品質の基準を記載します。 + +**SLA策定の重要性**: +- SLOとSLIに基づいた実現可能な目標設定 +- 顧客期待値の明確化 +- サービス品質保証の根拠 +- 違約時の対応方針の明確化 + +**SLA定義**: + +| システム構成/機能 | SLA項目 | 保証値 | 測定方法 | 測定期間 | 未達時の対応 | +|-------------------|---------|--------|----------|----------|-------------| +| [全体] | サービス可用性 | [例: 99.9%] | [測定方法] | 月次 | [対応内容] | +| [Web同期リクエスト] | レスポンスタイム（P95） | [例: 500ms以下] | [測定方法] | 月次 | [対応内容] | +| [非同期APIリクエスト] | 処理完了時間（P95） | [例: 5秒以内] | [測定方法] | 月次 | [対応内容] | +| [バッチ処理] | 処理完了時刻 | [例: 翌朝8時まで] | [測定方法] | 日次 | [対応内容] | + +**システム構成別のSLA設定指針**: + +1. **同期的なWebリクエスト（ユーザー対話操作）** + - ユーザーが快適に操作できる範囲を基準とする + - レスポンスタイム: 一般的に500ms以下（P95） + - エラーレート: 0.1%以下 + +2. **非同期APIリクエスト（バックグラウンド処理）** + - ユーザー体験に直接影響しない範囲で設定 + - 処理完了時間: 数秒〜数十秒 + - 再試行ポリシーを含む + +3. **バッチ処理（夜間処理等）** + - 業務開始時刻までの完了を保証 + - 処理時間: 数時間単位 + - 失敗時の再実行ポリシー + +**SLA未達時のペナルティまたは対応**: +- サービスクレジット: [内容] +- エスカレーション: [プロセス] +- 改善計画の提出: [内容] + +### 3.5 エラーバジェット + +許容されるエラーの範囲を定義します。 + +**エラーバジェット算出**: +- 可用性目標: 99.9% +- 許容ダウンタイム（月間）: [計算結果] +- エラーバジェット消費の閾値: [閾値] + +**エラーバジェットポリシー**: +- エラーバジェット残量 > 50%: [対応方針] +- エラーバジェット残量 20-50%: [対応方針] +- エラーバジェット残量 < 20%: [対応方針] + +--- + +## 4. 運用体制 + +### 4.1 運用組織体制 + +運用組織の体制を記載します。 + +```mermaid +graph TB + Manager[運用マネージャー] + + Manager --> Team1[運用チーム1] + Manager --> Team2[運用チーム2] + Manager --> Team3[SREチーム] + + Team1 --> Ops1[オペレーター1] + Team1 --> Ops2[オペレーター2] + + Team2 --> Ops3[オペレーター3] + Team2 --> Ops4[オペレーター4] + + Team3 --> SRE1[SREエンジニア1] + Team3 --> SRE2[SREエンジニア2] +``` + +### 4.2 役割と責任（RACI） + +主要な運用プロセスにおける役割と責任を記載します。 + +| プロセス/タスク | 運用マネージャー | 運用チーム | SREチーム | 開発チーム | 備考 | +|-----------------|------------------|------------|-----------|------------|------| +| 監視・アラート対応 | A | R | C | I | [備考] | +| インシデント対応 | A | R | C | C | [備考] | +| 変更管理 | A | I | C | R | [備考] | +| リリース管理 | A | C | R | R | [備考] | + +※ R=Responsible（実行責任）, A=Accountable（説明責任）, C=Consulted（相談）, I=Informed（報告） + +### 4.3 運用時間帯 + +運用体制の時間帯を記載します。 + +| 時間帯 | 運用体制 | 対応内容 | +|--------|----------|----------| +| 平日 9:00-18:00 | 通常体制 | [対応内容] | +| 平日 18:00-9:00 | オンコール体制 | [対応内容] | +| 休日・祝日 | オンコール体制 | [対応内容] | + +**オンコール体制**: +- 1次対応: [担当者・連絡先] +- 2次対応: [担当者・連絡先] +- エスカレーション先: [担当者・連絡先] + +### 4.4 コミュニケーション + +運用における コミュニケーション方法を記載します。 + +**定例会議**: + +| 会議名 | 頻度 | 参加者 | 目的 | +|--------|------|--------|------| +| 日次運用会議 | 毎日 | [参加者] | [目的] | +| 週次運用レビュー | 毎週 | [参加者] | [目的] | +| 月次運用報告 | 毎月 | [参加者] | [目的] | + +**コミュニケーションツール**: +- チャット: [ツール名・チャンネル] +- チケット管理: [ツール名] +- ドキュメント共有: [ツール名] +- インシデント管理: [ツール名] + +--- + +## 5. 運用スケジュール + +### 5.1 定期運用スケジュール + +定期的に実施する運用作業のスケジュールを記載します。 + +| 作業項目 | 頻度 | 実施日時 | 担当 | 所要時間 | +|----------|------|----------|------|----------| +| [作業1] | 日次 | [時刻] | [担当] | [時間] | +| [作業2] | 週次 | [曜日・時刻] | [担当] | [時間] | +| [作業3] | 月次 | [日・時刻] | [担当] | [時間] | + +### 5.2 メンテナンスウィンドウ + +計画メンテナンスの実施可能時間帯を記載します。 + +**定期メンテナンス**: +- 頻度: [週次/月次/四半期等] +- 実施日時: [曜日・時刻] +- 所要時間: [時間] +- 影響範囲: [影響内容] + +**緊急メンテナンス**: +- 実施判断基準: [基準] +- 承認プロセス: [プロセス] +- 通知方法: [通知手段] + +### 5.3 年間運用カレンダー + +年間の主要イベントとメンテナンススケジュールを記載します。 + +| 月 | イベント/作業 | 詳細 | +|----|---------------|------| +| 1月 | [イベント] | [詳細] | +| 2月 | [イベント] | [詳細] | +| ... | ... | ... | + +--- + +## 6. 定常運用作業 + +### 6.1 日次運用作業 + +毎日実施する運用作業を記載します。 + +#### 7.1.1 [作業名1] + +**目的**: [作業の目的] + +**実施タイミング**: [時刻] + +**手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +**確認項目**: +- [ ] [確認項目1] +- [ ] [確認項目2] + +**成果物**: [成果物があれば記載] + +**エスカレーション基準**: [異常時の対応] + +#### 7.1.2 [作業名2] + +[同様の形式で記載] + +### 6.2 週次運用作業 + +週単位で実施する運用作業を記載します。 + +#### 7.2.1 [作業名] + +[日次作業と同様の形式で記載] + +### 6.3 月次運用作業 + +月単位で実施する運用作業を記載します。 + +#### 7.3.1 [作業名] + +[日次作業と同様の形式で記載] + +--- + +## 7. 監視・通知 + +### 7.1 監視方針 + +**【重要】ユーザー中心の監視設計原則**: + +監視は「測りやすい技術指標」ではなく、「ユーザーが快適に使える状態」を維持するために実施します。 + +**監視設計アプローチ**: + +1. **ユーザー体験起点の監視** + - まず「ユーザーが体感する品質」を監視 + - 技術指標はユーザー体験指標が悪化した時の原因特定に使用 + - 例: レスポンスタイムの悪化を検知 → CPU使用率を確認して原因を特定 + +2. **外形監視を最優先** + - ユーザーと同じ視点でサービスを監視 + - エンドツーエンドの動作確認 + - 実際のユーザートランザクションをシミュレート + +3. **システム構成ごとの監視基準** + - 同期処理、非同期処理、バッチ処理で監視基準を分ける + - それぞれのユーザー期待値に基づいた閾値設定 + +**監視の目的**: +- **第一目的**: ユーザーが快適に利用できる状態の維持 +- サービスの可用性確保 +- パフォーマンス劣化の早期検知（ユーザー体感品質の観点から） +- セキュリティインシデントの検知 +- キャパシティ不足の予兆検知 + +**監視レベル**: +- レベル1（Critical）: ユーザーに直接影響がある状態 [具体的な定義と対応] +- レベル2（Warning）: ユーザーへ影響が及ぶ可能性のある状態 [具体的な定義と対応] +- レベル3（Info）: ユーザーに影響はないが注視すべき状態 [具体的な定義と対応] + +### 7.2 監視項目 + +**【重要】監視項目の優先順位**: + +**優先度1: ユーザー体験監視（SLI直結）** +- ユーザーが直接体感する品質指標 +- これらが正常であればサービスは正常 + +**優先度2: アプリケーション監視** +- ユーザー体験指標の裏付け +- 問題発生時の原因特定用 + +**優先度3: インフラ監視** +- アプリケーション指標の裏付け +- キャパシティ管理用 + +**監視項目定義**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 1 | 外形監視（Web同期） | レスポンスタイム（P95） | 500ms超 | 1分 | Warning | ユーザーが遅いと感じる | +| 1 | 外形監視（Web同期） | レスポンスタイム（P95） | 1000ms超 | 1分 | Critical | ユーザーがストレスを感じる | +| 1 | 外形監視（Web同期） | エラーレート | 0.1%超 | 1分 | Warning | ユーザーがエラーに遭遇し始める | +| 1 | 外形監視（Web同期） | エラーレート | 1%超 | 1分 | Critical | 多数のユーザーがエラーに遭遇 | +| 1 | 外形監視（非同期API） | 処理完了時間（P95） | 5秒超 | 5分 | Warning | バックグラウンド処理の遅延 | +| 1 | 外形監視（バッチ） | 処理完了時刻 | 7:00以降 | 1時間 | Warning | 業務開始に間に合わない可能性 | +| 1 | 外形監視（バッチ） | 処理完了時刻 | 8:00以降 | 1時間 | Critical | 業務開始に間に合わない | +| 2 | アプリケーション | エラーレート | [閾値] | 1分 | [レベル] | アプリケーションレベルのエラー発生状況 | +| 2 | アプリケーション | レスポンスタイム | [閾値] | 1分 | [レベル] | アプリケーション処理時間 | +| 3 | Webサーバー | CPU使用率 | 80%超 | 1分 | Info | リソース逼迫の予兆 | +| 3 | Webサーバー | CPU使用率 | 90%超 | 1分 | Warning | リソース逼迫 | +| 3 | Webサーバー | メモリ使用率 | [閾値] | [間隔] | [レベル] | メモリリソース状況 | +| 3 | データベース | 接続数 | [閾値] | [間隔] | [レベル] | DB接続リソース状況 | + +**システム構成別の監視設計**: + +1. **同期的なWebリクエスト** + - ユーザーは即座に結果を期待 + - レスポンスタイム: P95で500ms以下を目標 + - 監視間隔: 1分（迅速な検知が必要） + +2. **非同期APIリクエスト** + - ユーザーは数秒の待機は許容 + - 処理完了時間: P95で5秒以内を目標 + - 監視間隔: 5分（ある程度の猶予あり） + +3. **バッチ処理** + - ユーザーは完了時刻を期待 + - 処理完了時刻: 業務開始時刻まで + - 監視間隔: 1時間（処理時間が長いため） + +### 7.3 ログ管理 + +ログの収集・保管・分析方針を記載します。 + +**ログ種類**: + +| ログ種類 | 出力先 | 保管期間 | 用途 | +|----------|--------|----------|------| +| アクセスログ | [保存先] | [期間] | [用途] | +| アプリケーションログ | [保存先] | [期間] | [用途] | +| エラーログ | [保存先] | [期間] | [用途] | +| セキュリティログ | [保存先] | [期間] | [用途] | + +**ログ分析**: +- ツール: [ツール名] +- 分析頻度: [頻度] +- 分析内容: [内容] + +### 7.4 アラート通知 + +アラート通知のルールと方法を記載します。 + +**通知ルート**: + +```mermaid +graph LR + Alert[アラート発生] --> Level{レベル判定} + + Level -->|Critical| Notify1[即時通知
電話+メール+チャット] + Level -->|Warning| Notify2[メール+チャット] + Level -->|Info| Notify3[チャットのみ] + + Notify1 --> Oncall[オンコール担当] + Notify2 --> Team[運用チーム] + Notify3 --> Log[ログ記録] +``` + +**通知先**: + +| アラートレベル | 通知方法 | 通知先 | 対応時間 | +|----------------|----------|--------|----------| +| Critical | 電話+メール+チャット | [通知先] | 即時 | +| Warning | メール+チャット | [通知先] | 30分以内 | +| Info | チャット | [通知先] | 営業時間内 | + +--- + +## 8. インシデント管理 + +### 8.1 インシデント定義 + +インシデントの定義と分類を記載します。 + +**インシデント定義**: +サービスの計画外の中断、またはサービス品質の低下 + +**インシデント分類**: + +| 優先度 | 定義 | 対応目標時間 | 例 | +|--------|------|--------------|-----| +| P1（Critical） | サービス全停止 | 15分以内に対応開始 | [例] | +| P2（High） | 主要機能停止 | 30分以内に対応開始 | [例] | +| P3（Medium） | 一部機能停止 | 2時間以内に対応開始 | [例] | +| P4（Low） | 軽微な問題 | 営業時間内対応 | [例] | + +### 8.2 インシデント対応フロー + +インシデント対応の標準フローを記載します。 + +```mermaid +graph TD + Start[インシデント検知] --> Triage[トリアージ] + Triage --> Priority{優先度判定} + + Priority -->|P1/P2| Urgent[緊急対応] + Priority -->|P3/P4| Normal[通常対応] + + Urgent --> Investigate1[原因調査] + Normal --> Investigate2[原因調査] + + Investigate1 --> Fix1[復旧作業] + Investigate2 --> Fix2[修正作業] + + Fix1 --> Verify1[動作確認] + Fix2 --> Verify2[動作確認] + + Verify1 --> Close1[インシデントクローズ] + Verify2 --> Close2[インシデントクローズ] + + Close1 --> Postmortem[ポストモーテム] + Close2 --> Review[レビュー] +``` + +### 8.3 インシデント対応手順 + +インシデント対応の詳細手順を記載します。 + +#### 9.3.1 検知・報告 + +**検知方法**: +- 監視アラート +- ユーザー報告 +- 運用チーム発見 + +**報告フロー**: +1. インシデント管理ツールにチケット作成 +2. 運用チームに通知 +3. 優先度に応じてエスカレーション + +#### 9.3.2 トリアージ + +**トリアージ基準**: +- 影響範囲（全ユーザー / 一部ユーザー / 特定機能） +- ビジネスインパクト（売上損失 / 信用失墜 / 軽微） +- 緊急度（即時対応必要 / 計画的対応可能） + +**優先度判定**: +[優先度判定のマトリクスやルール] + +#### 9.3.3 対応・復旧 + +**対応原則**: +1. まず復旧、原因究明は後 +2. 影響範囲の最小化を優先 +3. コミュニケーションを密に + +**復旧手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +#### 9.3.4 ポストモーテム + +**実施タイミング**: +- P1/P2インシデント: 必須 +- P3インシデント: 必要に応じて +- P4インシデント: 任意 + +**ポストモーテム内容**: +- インシデントサマリー +- 影響範囲と期間 +- 根本原因分析（なぜなぜ分析） +- 再発防止策 +- アクションアイテム + +### 8.4 エスカレーション + +エスカレーションルールを記載します。 + +**エスカレーション基準**: +- 対応開始から[X]分経過しても復旧しない +- 影響範囲が拡大している +- 技術的な判断が必要 +- ビジネス判断が必要 + +**エスカレーションパス**: + +```mermaid +graph TB + L1[L1: 運用担当者] -->|15分| L2[L2: 運用リーダー] + L2 -->|30分| L3[L3: 運用マネージャー] + L3 -->|60分| L4[L4: 開発チーム] + L3 -->|重大影響| L5[L5: 経営層] +``` + +--- + +## 9. 変更管理 + +### 9.1 変更管理方針 + +変更管理の基本方針を記載します。 + +**変更管理の目的**: +- 変更に伴うリスクの最小化 +- 変更の影響評価と承認プロセスの明確化 +- 変更履歴の記録と追跡可能性の確保 + +**変更の定義**: +本番環境への以下の変更を対象とします +- システム構成の変更 +- アプリケーションのデプロイ +- インフラ設定の変更 +- セキュリティ設定の変更 + +### 9.2 変更分類 + +変更の種類と承認プロセスを記載します。 + +| 変更分類 | 定義 | 承認者 | リードタイム | +|----------|------|--------|--------------| +| 標準変更 | 手順化済みの低リスク変更 | 運用リーダー | 即時 | +| 通常変更 | 一般的な変更 | 運用マネージャー | 3営業日 | +| 緊急変更 | 緊急対応が必要な変更 | 運用マネージャー | 即時 | +| 重要変更 | 高リスクまたは大規模な変更 | 変更諮問委員会 | 1週間 | + +### 9.3 変更管理フロー + +変更管理のプロセスを記載します。 + +```mermaid +graph TD + Request[変更要求] --> Classification{変更分類} + + Classification -->|標準| Approve1[自動承認] + Classification -->|通常| Review1[レビュー] + Classification -->|緊急| Review2[緊急レビュー] + Classification -->|重要| CAB[CAB審査] + + Review1 --> Approve2[承認] + Review2 --> Approve3[承認] + CAB --> Approve4[承認] + + Approve1 --> Plan[実施計画] + Approve2 --> Plan + Approve3 --> Plan + Approve4 --> Plan + + Plan --> Implement[変更実施] + Implement --> Verify[検証] + Verify --> Close[クローズ] + + Verify -->|失敗| Rollback[ロールバック] + Rollback --> Review3[原因分析] +``` + +### 9.4 変更実施手順 + +変更を実施する際の標準手順を記載します。 + +**事前準備**: +1. 変更チケットの作成 +2. 変更内容の詳細記載 +3. 影響評価の実施 +4. ロールバック計画の作成 +5. 承認取得 + +**実施時**: +1. 事前バックアップの取得 +2. 変更作業の実施 +3. 作業ログの記録 +4. 動作確認の実施 + +**事後**: +1. 変更結果の報告 +2. ドキュメントの更新 +3. チケットのクローズ + +### 9.5 ロールバック計画 + +ロールバックの基準と手順を記載します。 + +**ロールバック判断基準**: +- 変更後の動作確認でエラーが検出された +- SLOを下回る性能劣化が発生した +- 予期しない副作用が発生した +- [その他の基準] + +**ロールバック手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +--- + +## 10. リリース管理 + +### 10.1 リリース方針 + +リリースの基本方針を記載します。 + +**リリース原則**: +- 定期リリースと緊急リリースの明確な区別 +- 本番環境へのリリース前の十分なテスト +- 段階的なロールアウト（カナリアリリース等） +- 自動化されたデプロイメントプロセス + +### 10.2 リリーススケジュール + +定期リリースのスケジュールを記載します。 + +| リリース種別 | 頻度 | 実施日時 | 対象 | +|--------------|------|----------|------| +| メジャーリリース | 四半期毎 | [日時] | 大規模機能追加 | +| マイナーリリース | 月次 | [日時] | 機能改善 | +| パッチリリース | 週次 | [日時] | バグフィックス | +| ホットフィックス | 随時 | 随時 | 緊急対応 | + +### 10.3 リリースフロー + +リリースプロセスを記載します。 + +```mermaid +graph LR + Dev[開発環境] --> Test[テスト環境] + Test --> Staging[ステージング環境] + Staging --> Canary[カナリア環境] + Canary --> Prod[本番環境] + + Test -.->|NG| Dev + Staging -.->|NG| Dev + Canary -.->|NG| Rollback[ロールバック] +``` + +**各環境の役割**: +- 開発環境: 機能開発とユニットテスト +- テスト環境: 結合テストと品質保証 +- ステージング環境: 本番環境と同等構成での最終確認 +- カナリア環境: 一部ユーザーでの先行リリース +- 本番環境: 全ユーザー向けリリース + +### 10.4 デプロイメント戦略 + +デプロイメント方式を記載します。 + +**採用戦略**: [選択した戦略] + +**デプロイメント方式の比較**: + +| 方式 | メリット | デメリット | 採用判断 | +|------|----------|------------|----------| +| Blue-Green | ダウンタイムゼロ | リソース2倍必要 | [○/×] | +| Rolling | リソース効率的 | 段階的な切り替え | [○/×] | +| Canary | リスク最小化 | 複雑な制御必要 | [○/×] | + +**自動化ツール**: +- CI/CDツール: [ツール名] +- デプロイツール: [ツール名] +- インフラ管理: [ツール名] + +--- + +## 11. バックアップ・リカバリ + +### 11.1 バックアップ方針 + +バックアップの基本方針を記載します。 + +**バックアップ目的**: +- データ損失時の復旧 +- ランサムウェア等のセキュリティインシデント対応 +- 監査・コンプライアンス要件への対応 + +**バックアップ原則**: +- 3-2-1ルール: 3つのコピー、2つの異なるメディア、1つはオフサイト +- 暗号化されたバックアップの保管 +- 定期的なリストアテストの実施 + +### 11.2 バックアップ設計 + +バックアップ対象と方式を記載します。 + +| バックアップ対象 | バックアップ方式 | 頻度 | 世代管理 | 保管場所 | +|------------------|------------------|------|----------|----------| +| データベース | フル+差分 | 日次フル+6時間毎差分 | 30世代 | [場所] | +| ファイルストレージ | フル | 日次 | 7世代 | [場所] | +| システム設定 | フル | 変更時 | 10世代 | [場所] | +| ログファイル | 増分 | 1時間毎 | 90日 | [場所] | + +**バックアップスケジュール**: + +```mermaid +gantt + title バックアップスケジュール（1日） + dateFormat HH:mm + axisFormat %H:%M + + section データベース + フルバックアップ :00:00, 2h + 差分バックアップ1 :06:00, 30m + 差分バックアップ2 :12:00, 30m + 差分バックアップ3 :18:00, 30m + + section ファイル + フルバックアップ :02:00, 1h +``` + +### 11.3 リカバリ設計 + +リカバリの目標値と手順を記載します。 + +**リカバリ目標**: + +| 対象 | RPO（目標復旧時点） | RTO（目標復旧時間） | +|------|---------------------|---------------------| +| データベース | 6時間以内 | 4時間以内 | +| ファイルストレージ | 24時間以内 | 2時間以内 | +| システム全体 | 24時間以内 | 8時間以内 | + +**リカバリ手順**: + +#### データベースリカバリ +1. [手順1] +2. [手順2] +3. [手順3] + +**リカバリテスト**: +- 頻度: 四半期毎 +- 対象: [テスト対象] +- 成功基準: [基準] + +### 11.4 災害対策（DR） + +災害復旧計画を記載します。 + +**DR方針**: +- DR サイト: [有/無] +- DR 構成: [Hot Standby / Warm Standby / Cold Standby] + +**DR切り替えシナリオ**: + +| シナリオ | 発生条件 | 切り替え判断 | 切り替え時間目標 | +|----------|----------|--------------|------------------| +| データセンター障害 | [条件] | [判断基準] | [時間] | +| リージョン障害 | [条件] | [判断基準] | [時間] | + +--- + +## 12. セキュリティ運用 + +### 12.1 セキュリティ運用方針 + +セキュリティ運用の基本方針を記載します。 + +**セキュリティ原則**: +- 多層防御（Defense in Depth） +- 最小権限の原則 +- ゼロトラストアーキテクチャ +- 継続的なセキュリティ監視 + +### 12.2 アクセス管理 + +アクセス権限の管理方針を記載します。 + +**権限管理**: + +| ロール | 権限範囲 | 承認者 | レビュー頻度 | +|--------|----------|--------|--------------| +| システム管理者 | 全権限 | [承認者] | 月次 | +| 運用担当者 | 運用操作のみ | [承認者] | 月次 | +| 開発者 | 開発環境のみ | [承認者] | 月次 | +| 閲覧者 | 読み取りのみ | [承認者] | 四半期 | + +**アクセスレビュー**: +- 頻度: [頻度] +- 実施者: [担当者] +- レビュー内容: [内容] + +### 12.3 脆弱性管理 + +脆弱性の検出と対応プロセスを記載します。 + +**脆弱性スキャン**: +- ツール: [ツール名] +- 頻度: [頻度] +- 対象: [対象システム] + +**パッチ適用**: + +| 脆弱性レベル | 対応期限 | 承認プロセス | +|--------------|----------|--------------| +| Critical | 24時間以内 | 緊急変更 | +| High | 7日以内 | 通常変更 | +| Medium | 30日以内 | 通常変更 | +| Low | 90日以内 | 計画変更 | + +### 12.4 セキュリティインシデント対応 + +セキュリティインシデントの対応手順を記載します。 + +**セキュリティインシデント分類**: + +| レベル | 定義 | 例 | 対応時間 | +|--------|------|-----|----------| +| L1 | 重大な侵害 | データ漏洩、ランサムウェア | 即時 | +| L2 | 侵害の疑い | 不正アクセス試行 | 1時間以内 | +| L3 | セキュリティ違反 | ポリシー違反 | 24時間以内 | + +**対応フロー**: + +```mermaid +graph TD + Detect[検知] --> Contain[封じ込め] + Contain --> Eradicate[根絶] + Eradicate --> Recover[復旧] + Recover --> PostIncident[事後対応] + PostIncident --> Improve[改善] +``` + +**インシデント対応チーム（CSIRT）**: +- リーダー: [担当者] +- メンバー: [担当者リスト] +- 外部連絡先: [セキュリティベンダー、警察等] + +### 12.5 コンプライアンス + +法規制・コンプライアンス要件への対応を記載します。 + +**適用法規制**: +- [法規制名]: [要件概要] +- [法規制名]: [要件概要] + +**監査対応**: +- 内部監査: [頻度・実施者] +- 外部監査: [頻度・監査法人] +- 証跡管理: [保管方法・期間] + +--- + +## 13. キャパシティ管理 + +### 13.1 キャパシティ管理方針 + +キャパシティ管理の基本方針を記載します。 + +**キャパシティ管理の目的**: +- サービス品質の維持 +- コストの最適化 +- 将来の需要予測と計画 + +### 13.2 キャパシティ監視 + +監視対象リソースと閾値を記載します。 + +| リソース | 現在の使用率 | 警告閾値 | 限界閾値 | 対応アクション | +|----------|--------------|----------|----------|----------------| +| CPU | [%] | 70% | 85% | [アクション] | +| メモリ | [%] | 75% | 90% | [アクション] | +| ディスク | [%] | 80% | 90% | [アクション] | +| ネットワーク帯域 | [%] | 70% | 85% | [アクション] | + +### 13.3 キャパシティ計画 + +将来の需要予測と増強計画を記載します。 + +**需要予測**: + +| 期間 | 予想ユーザー数 | 予想トラフィック | 必要リソース | +|------|----------------|------------------|--------------| +| 3ヶ月後 | [数値] | [数値] | [内容] | +| 6ヶ月後 | [数値] | [数値] | [内容] | +| 1年後 | [数値] | [数値] | [内容] | + +**増強計画**: +- 実施時期: [時期] +- 増強内容: [内容] +- 見積もりコスト: [金額] + +### 13.4 スケーリング戦略 + +スケーリングの方針と実装を記載します。 + +**スケーリング方式**: +- 垂直スケーリング（スケールアップ）: [適用箇所] +- 水平スケーリング（スケールアウト）: [適用箇所] + +**オートスケーリング設定**: + +| 対象 | スケールアウト条件 | スケールイン条件 | 最小/最大インスタンス数 | +|------|-------------------|------------------|------------------------| +| [対象1] | [条件] | [条件] | [最小数]/[最大数] | +| [対象2] | [条件] | [条件] | [最小数]/[最大数] | + +--- + +## 14. コスト管理 + +### 14.1 コスト管理方針 + +コスト管理の基本方針を記載します。 + +**コスト管理の目的**: +- 予算内での運用実現 +- コスト効率の最適化 +- コスト可視化と予測 + +### 14.2 コスト構造 + +運用コストの内訳を記載します。 + +| コスト項目 | 月額コスト | 年額コスト | 備考 | +|------------|------------|------------|------| +| インフラコスト | [金額] | [金額] | [内訳] | +| ライセンスコスト | [金額] | [金額] | [内訳] | +| 人件費 | [金額] | [金額] | [内訳] | +| 外部委託費 | [金額] | [金額] | [内訳] | +| その他 | [金額] | [金額] | [内訳] | +| **合計** | [金額] | [金額] | | + +### 14.3 コスト最適化施策 + +コスト削減・最適化の取り組みを記載します。 + +**実施中の施策**: +1. [施策1]: [効果] +2. [施策2]: [効果] + +**計画中の施策**: +1. [施策1]: [期待効果] +2. [施策2]: [期待効果] + +### 14.4 コスト監視 + +コストの監視とアラート設定を記載します。 + +**コスト監視**: +- ツール: [ツール名] +- 監視頻度: [頻度] +- レポート: [頻度・宛先] + +**コストアラート**: +- 月次予算超過アラート: [閾値] +- 異常なコスト増加アラート: [条件] + +--- + +## 15. 問題管理 + +### 15.1 問題管理方針 + +問題管理の基本方針を記載します。 + +**問題の定義**: +1つ以上のインシデントの根本原因、または潜在的なインシデントの原因 + +**問題管理の目的**: +- インシデントの根本原因の特定と除去 +- 既知のエラーの記録と回避策の提供 +- 再発防止策の実装 + +### 15.2 問題管理プロセス + +問題管理のフローを記載します。 + +```mermaid +graph TD + Incident[インシデント発生] --> Analysis[傾向分析] + Analysis --> Problem{問題として
管理すべきか？} + + Problem -->|Yes| Register[問題登録] + Problem -->|No| End1[終了] + + Register --> Investigate[根本原因分析] + Investigate --> Known[既知のエラー登録] + + Known --> Workaround[回避策の提供] + Known --> Solution[恒久対策の検討] + + Solution --> Implement[対策実装] + Implement --> Verify[効果検証] + Verify --> Close[クローズ] +``` + +### 15.3 既知のエラー管理 + +既知のエラーと回避策を記録します。 + +| エラーID | 問題概要 | 影響 | 回避策 | 恒久対策の状況 | +|----------|----------|------|--------|----------------| +| KE-001 | [概要] | [影響] | [回避策] | [状況] | +| KE-002 | [概要] | [影響] | [回避策] | [状況] | + +--- + +## 16. ナレッジ管理 + +### 16.1 ナレッジ管理方針 + +ナレッジの蓄積と共有の方針を記載します。 + +**ナレッジ管理の目的**: +- 運用ノウハウの蓄積と継承 +- 問題解決の効率化 +- 属人化の排除 + +### 16.2 ドキュメント体系 + +管理するドキュメントの種類と保管場所を記載します。 + +| ドキュメント種別 | 保管場所 | 更新頻度 | 管理者 | +|------------------|----------|----------|--------| +| 運用設計書 | [場所] | [頻度] | [担当] | +| 運用手順書 | [場所] | [頻度] | [担当] | +| 障害対応手順書 | [場所] | [頻度] | [担当] | +| FAQ | [場所] | [頻度] | [担当] | +| ポストモーテム | [場所] | 都度 | [担当] | + +### 16.3 ドキュメント管理ルール + +ドキュメントの作成・更新・レビューのルールを記載します。 + +**作成ルール**: +- テンプレートの使用 +- 命名規則の遵守 +- バージョン管理の実施 + +**更新ルール**: +- 変更履歴の記録 +- レビュープロセスの実施 +- 関連ドキュメントの同期更新 + +**レビュープロセス**: +- レビュー頻度: [頻度] +- レビュー担当: [担当者] +- レビュー基準: [基準] + +--- + +## 17. 継続的改善 + +### 17.1 改善活動方針 + +継続的改善の基本方針を記載します。 + +**改善の原則**: +- データドリブンな意思決定 +- 小さな改善の積み重ね +- チーム全体での取り組み +- 定期的な振り返りと学び + +### 17.2 改善プロセス + +改善活動のサイクルを記載します。 + +```mermaid +graph LR + Plan[計画
Plan] --> Do[実行
Do] + Do --> Check[評価
Check] + Check --> Act[改善
Act] + Act --> Plan +``` + +**改善活動の実施**: +- 週次: チーム振り返り +- 月次: メトリクスレビュー +- 四半期: 運用プロセスレビュー +- 年次: 運用戦略レビュー + +### 17.3 運用メトリクス + +運用品質を測定する指標を記載します。 + +| メトリクス | 目標値 | 測定方法 | レポート頻度 | +|------------|--------|----------|--------------| +| 可用性 | 99.9%以上 | [方法] | 月次 | +| MTBF（平均故障間隔） | [目標] | [方法] | 月次 | +| MTTR（平均復旧時間） | 30分以内 | [方法] | 月次 | +| 変更成功率 | 95%以上 | [方法] | 月次 | +| インシデント件数 | [目標] | [方法] | 月次 | +| デプロイ頻度 | [目標] | [方法] | 月次 | + +### 17.4 改善施策管理 + +改善施策の管理方法を記載します。 + +**改善施策リスト**: + +| 施策ID | 施策名 | 目的 | 担当 | 期限 | ステータス | +|--------|--------|------|------|------|------------| +| IMP-001 | [施策名] | [目的] | [担当] | [期限] | [ステータス] | +| IMP-002 | [施策名] | [目的] | [担当] | [期限] | [ステータス] | + +--- + +## 18. 運用ツール + +### 18.1 運用ツール一覧 + +使用する運用ツールを記載します。 + +| カテゴリ | ツール名 | 用途 | ライセンス | 管理者 | +|----------|----------|------|------------|--------| +| 監視 | [ツール名] | [用途] | [ライセンス] | [担当] | +| ログ管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| インシデント管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| 変更管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| CI/CD | [ツール名] | [用途] | [ライセンス] | [担当] | +| コミュニケーション | [ツール名] | [用途] | [ライセンス] | [担当] | + +### 18.2 ツール統合 + +ツール間の連携を記載します。 + +**統合フロー**: + +```mermaid +graph LR + Monitor[監視ツール] -->|アラート| Incident[インシデント管理] + Incident -->|通知| Chat[チャットツール] + Chat -->|トリガー| CICD[CI/CDツール] + CICD -->|ログ| LogTool[ログ管理ツール] + LogTool -->|メトリクス| Monitor +``` + +--- + +## 19. 付録 + +### 19.1 用語集 + +本ドキュメントで使用する用語の定義を記載します。 + +| 用語 | 定義 | +|------|------| +| SLO | Service Level Objective: サービスレベル目標 | +| SLI | Service Level Indicator: サービスレベル指標 | +| SLA | Service Level Agreement: サービスレベル合意 | +| MTTR | Mean Time To Repair: 平均復旧時間 | +| MTBF | Mean Time Between Failures: 平均故障間隔 | +| RPO | Recovery Point Objective: 目標復旧時点 | +| RTO | Recovery Time Objective: 目標復旧時間 | +| RACI | Responsible, Accountable, Consulted, Informed | + +### 19.2 参照ドキュメント + +関連ドキュメントへのリンクを記載します。 + +| ドキュメント名 | 場所/URL | 備考 | +|----------------|----------|------| +| システム設計書 | [リンク] | [備考] | +| セキュリティポリシー | [リンク] | [備考] | +| 運用手順書 | [リンク] | [備考] | + +### 19.3 連絡先 + +運用に関わる主要な連絡先を記載します。 + +| 役割 | 担当者 | 連絡先 | 対応時間 | +|------|--------|--------|----------| +| 運用マネージャー | [名前] | [連絡先] | [時間] | +| オンコール担当 | [名前] | [連絡先] | 24/365 | +| セキュリティ担当 | [名前] | [連絡先] | [時間] | + +### 19.4 承認 + +本ドキュメントの承認記録を記載します。 + +| 役割 | 氏名 | 承認日 | 署名 | +|------|------|--------|------| +| 作成者 | [名前] | [日付] | | +| レビュアー | [名前] | [日付] | | +| 承認者 | [名前] | [日付] | | + +--- + +## 運用設計書作成時の注意事項 + +本テンプレートを使用する際は、以下の点に注意してください： + +1. **プロジェクト特性に応じたカスタマイズ** + - すべてのセクションが必要とは限りません + - プロジェクトの規模や性質に応じて取捨選択してください + +2. **具体性の確保** + - 抽象的な記述ではなく、具体的な数値や手順を記載してください + - 「適切に」「十分に」などの曖昧な表現は避けてください + +3. **測定可能性** + - 目標値は測定可能な形で定義してください + - 測定方法も明記してください + +4. **継続的な更新** + - 運用開始後も定期的に見直し、更新してください + - 実態との乖離が生じないよう注意してください + +5. **ステークホルダーの合意** + - 関係者全員で内容を確認し、合意を形成してください + - 特にSLOや運用体制については十分な議論が必要です diff --git a/skills/operations-design/assets/templates/operations_design_template_onpremise_ja.md b/skills/operations-design/assets/templates/operations_design_template_onpremise_ja.md new file mode 100644 index 0000000..17ca1a3 --- /dev/null +++ b/skills/operations-design/assets/templates/operations_design_template_onpremise_ja.md @@ -0,0 +1,1414 @@ +# 運用設計書（オンプレミス対応） + +## ドキュメント情報 + +| 項目 | 内容 | +|------|------| +| ドキュメント名 | [サービス名] 運用設計書 | +| インフラパターン | **オンプレミス** | +| バージョン | [バージョン番号] | +| 作成日 | [YYYY-MM-DD] | +| 最終更新日 | [YYYY-MM-DD] | +| 作成者 | [作成者名] | +| 承認者 | [承認者名] | +| ステータス | [Draft / Review / Approved] | + +**このテンプレートの適用対象**: +- 自社データセンター +- コロケーション施設 +- 物理サーバー/仮想化環境（VMware、Hyper-V等） +- 完全な自社管理インフラ + +## 改訂履歴 + +| バージョン | 日付 | 変更内容 | 変更者 | +|------------|------|----------|--------| +| 0.1 | YYYY-MM-DD | 初版作成 | [名前] | + +--- + +## 1. 概要 + +### 1.1 目的 + +本ドキュメントの目的を記載します。 + +- 運用に求められる要件の明確化 +- システム運用に関わる関係者間の合意形成 +- 運用プロセスの標準化と最適化 +- 運用品質の向上と継続的改善 + +### 1.2 対象範囲 + +本運用設計書が対象とするシステム・サービスの範囲を記載します。 + +**対象システム**: +- [システム名・サービス名] + +**対象業務**: +- [業務名] + +**対象期間**: +- [運用開始予定日] ～ [運用終了予定日（該当する場合）] + +### 1.3 前提条件 + +運用設計における前提条件を記載します。 + +- システム開発が完了していること +- 運用環境が構築されていること +- 運用チームの体制が整っていること +- [その他の前提条件] + +### 1.4 制約条件 + +運用における制約事項を記載します。 + +- 予算制約: [金額や制約内容] +- リソース制約: [人員やインフラリソースの制約] +- 技術制約: [技術的な制約] +- 法規制・コンプライアンス: [該当する法規制] + +### 1.5 オンプレミス特有の考慮事項 + +**【重要】リソース保有とスケーリングの制約**: + +オンプレミス環境では、すべてのインフラリソースを自社で保有・管理するため、クラウドとは異なる運用が必要です。 + +**全責任範囲の管理**: +- **物理層**: データセンター、電源、空調、ネットワーク配線 +- **ハードウェア層**: サーバー、ストレージ、ネットワーク機器 +- **仮想化層**: ハイパーバイザー（該当する場合） +- **OS層**: OS、パッチ、セキュリティ更新 +- **ミドルウェア層**: Webサーバー、APサーバー、DB等 +- **アプリケーション層**: アプリケーション、設定、データ + +**スケーリングのリードタイム**: +- **垂直スケーリング（スケールアップ）**: + - サーバー購入: 1〜3ヶ月 + - ラックスペース確保: 数週間〜数ヶ月 + - ネットワーク配線: 数日〜数週間 + - セットアップ・テスト: 数日〜1週間 + - **合計リードタイム: 2〜4ヶ月** + +- **水平スケーリング（スケールアウト）**: + - 追加サーバー購入・設置: 同上 + - ロードバランサー設定: 数時間〜数日 + - **合計リードタイム: 2〜4ヶ月** + +**リソース削減の制約**: +- 一度購入したハードウェアは削減不可 +- 不要になったリソースもコスト発生（電源、冷却、保守） +- 減価償却期間中の資産管理 +- **結論: ピーク時に合わせた過剰リソース保有が必要** + +**キャパシティ計画の重要性**: +- 需要予測の精度が重要（購入後の変更困難） +- 1〜2年先の成長を見越したリソース確保 +- バッファ（余裕）の確保（一般的に30〜50%） + +**ハードウェア障害対応**: +- 保守契約（オンサイト保守、翌営業日対応等） +- スペアパーツの確保 +- ハードウェア交換のリードタイム考慮 + +**コスト構造**: +- 初期投資（CapEx）が大きい +- 運用コスト（OpEx）: 電源、冷却、保守、人件費 +- 利用率に関わらず固定コスト発生 + +**災害対策の考慮**: +- DR サイトの設計・運用 +- データセンター間のネットワーク +- バックアップデータの物理的な分散 + +--- + +## 2. サービス概要 + +### 2.1 サービスの目的 + +サービスが提供する価値と目的を記載します。 + +**ビジネス目的**: +- [ビジネス上の目的] + +**提供価値**: +- [ユーザーに提供する価値] + +### 2.2 サービスの機能 + +主要な機能を記載します。 + +| 機能名 | 概要 | 重要度 | +|--------|------|--------| +| [機能1] | [機能の説明] | High / Medium / Low | +| [機能2] | [機能の説明] | High / Medium / Low | + +### 2.3 システム構成 + +システムのアーキテクチャと主要コンポーネントを記載します。 + +**アーキテクチャ図**: + +```mermaid +graph TB + subgraph "ユーザー層" + User[エンドユーザー] + end + + subgraph "アプリケーション層" + Web[Webサーバー] + App[アプリケーションサーバー] + end + + subgraph "データ層" + DB[(データベース)] + Cache[(キャッシュ)] + end + + User --> Web + Web --> App + App --> DB + App --> Cache +``` + +**主要コンポーネント**: + +| コンポーネント | 役割 | 技術スタック | 冗長化 | +|----------------|------|--------------|--------| +| [コンポーネント1] | [役割] | [技術] | Yes / No | +| [コンポーネント2] | [役割] | [技術] | Yes / No | + +### 2.4 外部連携 + +外部システムとの連携を記載します。 + +| 連携先 | 連携方式 | データフロー | 重要度 | +|--------|----------|--------------|--------| +| [システム名] | API / Batch / etc | [方向と内容] | High / Medium / Low | + +--- + +## 3. 運用方針と目標 + +### 3.1 運用基本方針 + +運用における基本的な方針を記載します。 + +1. **可用性重視**: [方針の詳細] +2. **セキュリティ優先**: [方針の詳細] +3. **継続的改善**: [方針の詳細] +4. **コスト最適化**: [方針の詳細] + +### 3.2 サービスレベル目標（SLO） + +**【重要】ユーザー中心のSLO設計原則**: + +SLOは「測りやすい指標」ではなく、「ユーザーが快適に使える範囲」を起点として設計します。 + +**設計アプローチ**: +1. **ユーザーの期待値を理解する** + - ユーザーはどの程度の応答速度を期待しているか + - どの程度のエラーなら許容できるか + - サービス停止はどの程度の影響を与えるか + +2. **ユーザー体験に基づいた目標設定** + - 「サーバーCPU使用率」ではなく「ユーザーが体感するレスポンスタイム」 + - 「データベース接続数」ではなく「ユーザーがエラーに遭遇する頻度」 + - 技術指標はユーザー体験指標の裏付けとして使用 + +3. **システム構成ごとの目標設定** + - 同期処理、非同期処理、バッチ処理でユーザー期待値は異なる + - それぞれに適切な目標値を設定 + +**SLO定義**: + +| システム構成/機能 | 指標名 | 目標値 | ユーザー視点での意味 | 測定方法 | 測定頻度 | +|-------------------|--------|--------|---------------------|----------|----------| +| [全体] | 可用性 | [例: 99.9%] | ユーザーがサービスを利用できる時間の割合 | [測定方法] | [頻度] | +| [Web同期リクエスト] | レスポンスタイム（P95） | [例: 500ms以下] | ユーザーが操作後に結果が表示されるまでの体感速度 | [測定方法] | [頻度] | +| [Web同期リクエスト] | エラーレート | [例: 0.1%以下] | ユーザーがエラーに遭遇する頻度 | [測定方法] | [頻度] | +| [非同期APIリクエスト] | 処理完了時間（P95） | [例: 5秒以内] | バックグラウンド処理が完了するまでの時間 | [測定方法] | [頻度] | +| [バッチ処理] | 処理完了時刻 | [例: 翌朝8時まで] | 業務開始時にデータが利用可能になっている状態 | [測定方法] | 日次 | +| [全体] | MTTR | [例: 30分以内] | 障害発生時にユーザーが待つ時間 | [測定方法] | [頻度] | + +### 3.3 サービスレベル指標（SLI） + +SLOを測定するための具体的な指標を記載します。 + +| SLI名 | 定義 | データソース | 計算式 | +|-------|------|--------------|--------| +| [SLI1] | [定義] | [ソース] | [計算式] | +| [SLI2] | [定義] | [ソース] | [計算式] | + +### 3.4 サービスレベル合意（SLA） + +顧客またはユーザーに対して約束するサービス品質の基準を記載します。 + +**SLA策定の重要性**: +- SLOとSLIに基づいた実現可能な目標設定 +- 顧客期待値の明確化 +- サービス品質保証の根拠 +- 違約時の対応方針の明確化 + +**SLA定義**: + +| システム構成/機能 | SLA項目 | 保証値 | 測定方法 | 測定期間 | 未達時の対応 | +|-------------------|---------|--------|----------|----------|-------------| +| [全体] | サービス可用性 | [例: 99.9%] | [測定方法] | 月次 | [対応内容] | +| [Web同期リクエスト] | レスポンスタイム（P95） | [例: 500ms以下] | [測定方法] | 月次 | [対応内容] | +| [非同期APIリクエスト] | 処理完了時間（P95） | [例: 5秒以内] | [測定方法] | 月次 | [対応内容] | +| [バッチ処理] | 処理完了時刻 | [例: 翌朝8時まで] | [測定方法] | 日次 | [対応内容] | + +**システム構成別のSLA設定指針**: + +1. **同期的なWebリクエスト（ユーザー対話操作）** + - ユーザーが快適に操作できる範囲を基準とする + - レスポンスタイム: 一般的に500ms以下（P95） + - エラーレート: 0.1%以下 + +2. **非同期APIリクエスト（バックグラウンド処理）** + - ユーザー体験に直接影響しない範囲で設定 + - 処理完了時間: 数秒〜数十秒 + - 再試行ポリシーを含む + +3. **バッチ処理（夜間処理等）** + - 業務開始時刻までの完了を保証 + - 処理時間: 数時間単位 + - 失敗時の再実行ポリシー + +**SLA未達時のペナルティまたは対応**: +- サービスクレジット: [内容] +- エスカレーション: [プロセス] +- 改善計画の提出: [内容] + +### 3.5 エラーバジェット + +許容されるエラーの範囲を定義します。 + +**エラーバジェット算出**: +- 可用性目標: 99.9% +- 許容ダウンタイム（月間）: [計算結果] +- エラーバジェット消費の閾値: [閾値] + +**エラーバジェットポリシー**: +- エラーバジェット残量 > 50%: [対応方針] +- エラーバジェット残量 20-50%: [対応方針] +- エラーバジェット残量 < 20%: [対応方針] + +--- + +## 4. 運用体制 + +### 4.1 運用組織体制 + +運用組織の体制を記載します。 + +```mermaid +graph TB + Manager[運用マネージャー] + + Manager --> Team1[運用チーム1] + Manager --> Team2[運用チーム2] + Manager --> Team3[SREチーム] + + Team1 --> Ops1[オペレーター1] + Team1 --> Ops2[オペレーター2] + + Team2 --> Ops3[オペレーター3] + Team2 --> Ops4[オペレーター4] + + Team3 --> SRE1[SREエンジニア1] + Team3 --> SRE2[SREエンジニア2] +``` + +### 4.2 役割と責任（RACI） + +主要な運用プロセスにおける役割と責任を記載します。 + +| プロセス/タスク | 運用マネージャー | 運用チーム | SREチーム | 開発チーム | 備考 | +|-----------------|------------------|------------|-----------|------------|------| +| 監視・アラート対応 | A | R | C | I | [備考] | +| インシデント対応 | A | R | C | C | [備考] | +| 変更管理 | A | I | C | R | [備考] | +| リリース管理 | A | C | R | R | [備考] | + +※ R=Responsible（実行責任）, A=Accountable（説明責任）, C=Consulted（相談）, I=Informed（報告） + +### 4.3 運用時間帯 + +運用体制の時間帯を記載します。 + +| 時間帯 | 運用体制 | 対応内容 | +|--------|----------|----------| +| 平日 9:00-18:00 | 通常体制 | [対応内容] | +| 平日 18:00-9:00 | オンコール体制 | [対応内容] | +| 休日・祝日 | オンコール体制 | [対応内容] | + +**オンコール体制**: +- 1次対応: [担当者・連絡先] +- 2次対応: [担当者・連絡先] +- エスカレーション先: [担当者・連絡先] + +### 4.4 コミュニケーション + +運用における コミュニケーション方法を記載します。 + +**定例会議**: + +| 会議名 | 頻度 | 参加者 | 目的 | +|--------|------|--------|------| +| 日次運用会議 | 毎日 | [参加者] | [目的] | +| 週次運用レビュー | 毎週 | [参加者] | [目的] | +| 月次運用報告 | 毎月 | [参加者] | [目的] | + +**コミュニケーションツール**: +- チャット: [ツール名・チャンネル] +- チケット管理: [ツール名] +- ドキュメント共有: [ツール名] +- インシデント管理: [ツール名] + +--- + +## 5. 運用スケジュール + +### 5.1 定期運用スケジュール + +定期的に実施する運用作業のスケジュールを記載します。 + +| 作業項目 | 頻度 | 実施日時 | 担当 | 所要時間 | +|----------|------|----------|------|----------| +| [作業1] | 日次 | [時刻] | [担当] | [時間] | +| [作業2] | 週次 | [曜日・時刻] | [担当] | [時間] | +| [作業3] | 月次 | [日・時刻] | [担当] | [時間] | + +### 5.2 メンテナンスウィンドウ + +計画メンテナンスの実施可能時間帯を記載します。 + +**定期メンテナンス**: +- 頻度: [週次/月次/四半期等] +- 実施日時: [曜日・時刻] +- 所要時間: [時間] +- 影響範囲: [影響内容] + +**緊急メンテナンス**: +- 実施判断基準: [基準] +- 承認プロセス: [プロセス] +- 通知方法: [通知手段] + +### 5.3 年間運用カレンダー + +年間の主要イベントとメンテナンススケジュールを記載します。 + +| 月 | イベント/作業 | 詳細 | +|----|---------------|------| +| 1月 | [イベント] | [詳細] | +| 2月 | [イベント] | [詳細] | +| ... | ... | ... | + +--- + +## 6. 定常運用作業 + +### 6.1 日次運用作業 + +毎日実施する運用作業を記載します。 + +#### 7.1.1 [作業名1] + +**目的**: [作業の目的] + +**実施タイミング**: [時刻] + +**手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +**確認項目**: +- [ ] [確認項目1] +- [ ] [確認項目2] + +**成果物**: [成果物があれば記載] + +**エスカレーション基準**: [異常時の対応] + +#### 7.1.2 [作業名2] + +[同様の形式で記載] + +### 6.2 週次運用作業 + +週単位で実施する運用作業を記載します。 + +#### 7.2.1 [作業名] + +[日次作業と同様の形式で記載] + +### 6.3 月次運用作業 + +月単位で実施する運用作業を記載します。 + +#### 7.3.1 [作業名] + +[日次作業と同様の形式で記載] + +--- + +## 7. 監視・通知 + +### 7.1 監視方針 + +**【重要】ユーザー中心の監視設計原則**: + +監視は「測りやすい技術指標」ではなく、「ユーザーが快適に使える状態」を維持するために実施します。 + +**監視設計アプローチ**: + +1. **ユーザー体験起点の監視** + - まず「ユーザーが体感する品質」を監視 + - 技術指標はユーザー体験指標が悪化した時の原因特定に使用 + - 例: レスポンスタイムの悪化を検知 → CPU使用率を確認して原因を特定 + +2. **外形監視を最優先** + - ユーザーと同じ視点でサービスを監視 + - エンドツーエンドの動作確認 + - 実際のユーザートランザクションをシミュレート + +3. **システム構成ごとの監視基準** + - 同期処理、非同期処理、バッチ処理で監視基準を分ける + - それぞれのユーザー期待値に基づいた閾値設定 + +**監視の目的**: +- **第一目的**: ユーザーが快適に利用できる状態の維持 +- サービスの可用性確保 +- パフォーマンス劣化の早期検知（ユーザー体感品質の観点から） +- セキュリティインシデントの検知 +- キャパシティ不足の予兆検知 + +**監視レベル**: +- レベル1（Critical）: ユーザーに直接影響がある状態 [具体的な定義と対応] +- レベル2（Warning）: ユーザーへ影響が及ぶ可能性のある状態 [具体的な定義と対応] +- レベル3（Info）: ユーザーに影響はないが注視すべき状態 [具体的な定義と対応] + +### 7.2 監視項目 + +**【重要】監視項目の優先順位**: + +**優先度1: ユーザー体験監視（SLI直結）** +- ユーザーが直接体感する品質指標 +- これらが正常であればサービスは正常 + +**優先度2: アプリケーション監視** +- ユーザー体験指標の裏付け +- 問題発生時の原因特定用 + +**優先度3: インフラ監視** +- アプリケーション指標の裏付け +- キャパシティ管理用 + +**監視項目定義**: + +| 優先度 | 監視対象 | 監視項目 | 閾値 | 監視間隔 | アラートレベル | ユーザー視点での意味 | +|--------|----------|----------|------|----------|----------------|---------------------| +| 1 | 外形監視（Web同期） | レスポンスタイム（P95） | 500ms超 | 1分 | Warning | ユーザーが遅いと感じる | +| 1 | 外形監視（Web同期） | レスポンスタイム（P95） | 1000ms超 | 1分 | Critical | ユーザーがストレスを感じる | +| 1 | 外形監視（Web同期） | エラーレート | 0.1%超 | 1分 | Warning | ユーザーがエラーに遭遇し始める | +| 1 | 外形監視（Web同期） | エラーレート | 1%超 | 1分 | Critical | 多数のユーザーがエラーに遭遇 | +| 1 | 外形監視（非同期API） | 処理完了時間（P95） | 5秒超 | 5分 | Warning | バックグラウンド処理の遅延 | +| 1 | 外形監視（バッチ） | 処理完了時刻 | 7:00以降 | 1時間 | Warning | 業務開始に間に合わない可能性 | +| 1 | 外形監視（バッチ） | 処理完了時刻 | 8:00以降 | 1時間 | Critical | 業務開始に間に合わない | +| 2 | アプリケーション | エラーレート | [閾値] | 1分 | [レベル] | アプリケーションレベルのエラー発生状況 | +| 2 | アプリケーション | レスポンスタイム | [閾値] | 1分 | [レベル] | アプリケーション処理時間 | +| 3 | Webサーバー | CPU使用率 | 80%超 | 1分 | Info | リソース逼迫の予兆 | +| 3 | Webサーバー | CPU使用率 | 90%超 | 1分 | Warning | リソース逼迫 | +| 3 | Webサーバー | メモリ使用率 | [閾値] | [間隔] | [レベル] | メモリリソース状況 | +| 3 | データベース | 接続数 | [閾値] | [間隔] | [レベル] | DB接続リソース状況 | + +**システム構成別の監視設計**: + +1. **同期的なWebリクエスト** + - ユーザーは即座に結果を期待 + - レスポンスタイム: P95で500ms以下を目標 + - 監視間隔: 1分（迅速な検知が必要） + +2. **非同期APIリクエスト** + - ユーザーは数秒の待機は許容 + - 処理完了時間: P95で5秒以内を目標 + - 監視間隔: 5分（ある程度の猶予あり） + +3. **バッチ処理** + - ユーザーは完了時刻を期待 + - 処理完了時刻: 業務開始時刻まで + - 監視間隔: 1時間（処理時間が長いため） + +### 7.3 ログ管理 + +ログの収集・保管・分析方針を記載します。 + +**ログ種類**: + +| ログ種類 | 出力先 | 保管期間 | 用途 | +|----------|--------|----------|------| +| アクセスログ | [保存先] | [期間] | [用途] | +| アプリケーションログ | [保存先] | [期間] | [用途] | +| エラーログ | [保存先] | [期間] | [用途] | +| セキュリティログ | [保存先] | [期間] | [用途] | + +**ログ分析**: +- ツール: [ツール名] +- 分析頻度: [頻度] +- 分析内容: [内容] + +### 7.4 アラート通知 + +アラート通知のルールと方法を記載します。 + +**通知ルート**: + +```mermaid +graph LR + Alert[アラート発生] --> Level{レベル判定} + + Level -->|Critical| Notify1[即時通知
電話+メール+チャット] + Level -->|Warning| Notify2[メール+チャット] + Level -->|Info| Notify3[チャットのみ] + + Notify1 --> Oncall[オンコール担当] + Notify2 --> Team[運用チーム] + Notify3 --> Log[ログ記録] +``` + +**通知先**: + +| アラートレベル | 通知方法 | 通知先 | 対応時間 | +|----------------|----------|--------|----------| +| Critical | 電話+メール+チャット | [通知先] | 即時 | +| Warning | メール+チャット | [通知先] | 30分以内 | +| Info | チャット | [通知先] | 営業時間内 | + +--- + +## 8. インシデント管理 + +### 8.1 インシデント定義 + +インシデントの定義と分類を記載します。 + +**インシデント定義**: +サービスの計画外の中断、またはサービス品質の低下 + +**インシデント分類**: + +| 優先度 | 定義 | 対応目標時間 | 例 | +|--------|------|--------------|-----| +| P1（Critical） | サービス全停止 | 15分以内に対応開始 | [例] | +| P2（High） | 主要機能停止 | 30分以内に対応開始 | [例] | +| P3（Medium） | 一部機能停止 | 2時間以内に対応開始 | [例] | +| P4（Low） | 軽微な問題 | 営業時間内対応 | [例] | + +### 8.2 インシデント対応フロー + +インシデント対応の標準フローを記載します。 + +```mermaid +graph TD + Start[インシデント検知] --> Triage[トリアージ] + Triage --> Priority{優先度判定} + + Priority -->|P1/P2| Urgent[緊急対応] + Priority -->|P3/P4| Normal[通常対応] + + Urgent --> Investigate1[原因調査] + Normal --> Investigate2[原因調査] + + Investigate1 --> Fix1[復旧作業] + Investigate2 --> Fix2[修正作業] + + Fix1 --> Verify1[動作確認] + Fix2 --> Verify2[動作確認] + + Verify1 --> Close1[インシデントクローズ] + Verify2 --> Close2[インシデントクローズ] + + Close1 --> Postmortem[ポストモーテム] + Close2 --> Review[レビュー] +``` + +### 8.3 インシデント対応手順 + +インシデント対応の詳細手順を記載します。 + +#### 9.3.1 検知・報告 + +**検知方法**: +- 監視アラート +- ユーザー報告 +- 運用チーム発見 + +**報告フロー**: +1. インシデント管理ツールにチケット作成 +2. 運用チームに通知 +3. 優先度に応じてエスカレーション + +#### 9.3.2 トリアージ + +**トリアージ基準**: +- 影響範囲（全ユーザー / 一部ユーザー / 特定機能） +- ビジネスインパクト（売上損失 / 信用失墜 / 軽微） +- 緊急度（即時対応必要 / 計画的対応可能） + +**優先度判定**: +[優先度判定のマトリクスやルール] + +#### 9.3.3 対応・復旧 + +**対応原則**: +1. まず復旧、原因究明は後 +2. 影響範囲の最小化を優先 +3. コミュニケーションを密に + +**復旧手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +#### 9.3.4 ポストモーテム + +**実施タイミング**: +- P1/P2インシデント: 必須 +- P3インシデント: 必要に応じて +- P4インシデント: 任意 + +**ポストモーテム内容**: +- インシデントサマリー +- 影響範囲と期間 +- 根本原因分析（なぜなぜ分析） +- 再発防止策 +- アクションアイテム + +### 8.4 エスカレーション + +エスカレーションルールを記載します。 + +**エスカレーション基準**: +- 対応開始から[X]分経過しても復旧しない +- 影響範囲が拡大している +- 技術的な判断が必要 +- ビジネス判断が必要 + +**エスカレーションパス**: + +```mermaid +graph TB + L1[L1: 運用担当者] -->|15分| L2[L2: 運用リーダー] + L2 -->|30分| L3[L3: 運用マネージャー] + L3 -->|60分| L4[L4: 開発チーム] + L3 -->|重大影響| L5[L5: 経営層] +``` + +--- + +## 9. 変更管理 + +### 9.1 変更管理方針 + +変更管理の基本方針を記載します。 + +**変更管理の目的**: +- 変更に伴うリスクの最小化 +- 変更の影響評価と承認プロセスの明確化 +- 変更履歴の記録と追跡可能性の確保 + +**変更の定義**: +本番環境への以下の変更を対象とします +- システム構成の変更 +- アプリケーションのデプロイ +- インフラ設定の変更 +- セキュリティ設定の変更 + +### 9.2 変更分類 + +変更の種類と承認プロセスを記載します。 + +| 変更分類 | 定義 | 承認者 | リードタイム | +|----------|------|--------|--------------| +| 標準変更 | 手順化済みの低リスク変更 | 運用リーダー | 即時 | +| 通常変更 | 一般的な変更 | 運用マネージャー | 3営業日 | +| 緊急変更 | 緊急対応が必要な変更 | 運用マネージャー | 即時 | +| 重要変更 | 高リスクまたは大規模な変更 | 変更諮問委員会 | 1週間 | + +### 9.3 変更管理フロー + +変更管理のプロセスを記載します。 + +```mermaid +graph TD + Request[変更要求] --> Classification{変更分類} + + Classification -->|標準| Approve1[自動承認] + Classification -->|通常| Review1[レビュー] + Classification -->|緊急| Review2[緊急レビュー] + Classification -->|重要| CAB[CAB審査] + + Review1 --> Approve2[承認] + Review2 --> Approve3[承認] + CAB --> Approve4[承認] + + Approve1 --> Plan[実施計画] + Approve2 --> Plan + Approve3 --> Plan + Approve4 --> Plan + + Plan --> Implement[変更実施] + Implement --> Verify[検証] + Verify --> Close[クローズ] + + Verify -->|失敗| Rollback[ロールバック] + Rollback --> Review3[原因分析] +``` + +### 9.4 変更実施手順 + +変更を実施する際の標準手順を記載します。 + +**事前準備**: +1. 変更チケットの作成 +2. 変更内容の詳細記載 +3. 影響評価の実施 +4. ロールバック計画の作成 +5. 承認取得 + +**実施時**: +1. 事前バックアップの取得 +2. 変更作業の実施 +3. 作業ログの記録 +4. 動作確認の実施 + +**事後**: +1. 変更結果の報告 +2. ドキュメントの更新 +3. チケットのクローズ + +### 9.5 ロールバック計画 + +ロールバックの基準と手順を記載します。 + +**ロールバック判断基準**: +- 変更後の動作確認でエラーが検出された +- SLOを下回る性能劣化が発生した +- 予期しない副作用が発生した +- [その他の基準] + +**ロールバック手順**: +1. [手順1] +2. [手順2] +3. [手順3] + +--- + +## 10. リリース管理 + +### 10.1 リリース方針 + +リリースの基本方針を記載します。 + +**リリース原則**: +- 定期リリースと緊急リリースの明確な区別 +- 本番環境へのリリース前の十分なテスト +- 段階的なロールアウト（カナリアリリース等） +- 自動化されたデプロイメントプロセス + +### 10.2 リリーススケジュール + +定期リリースのスケジュールを記載します。 + +| リリース種別 | 頻度 | 実施日時 | 対象 | +|--------------|------|----------|------| +| メジャーリリース | 四半期毎 | [日時] | 大規模機能追加 | +| マイナーリリース | 月次 | [日時] | 機能改善 | +| パッチリリース | 週次 | [日時] | バグフィックス | +| ホットフィックス | 随時 | 随時 | 緊急対応 | + +### 10.3 リリースフロー + +リリースプロセスを記載します。 + +```mermaid +graph LR + Dev[開発環境] --> Test[テスト環境] + Test --> Staging[ステージング環境] + Staging --> Canary[カナリア環境] + Canary --> Prod[本番環境] + + Test -.->|NG| Dev + Staging -.->|NG| Dev + Canary -.->|NG| Rollback[ロールバック] +``` + +**各環境の役割**: +- 開発環境: 機能開発とユニットテスト +- テスト環境: 結合テストと品質保証 +- ステージング環境: 本番環境と同等構成での最終確認 +- カナリア環境: 一部ユーザーでの先行リリース +- 本番環境: 全ユーザー向けリリース + +### 10.4 デプロイメント戦略 + +デプロイメント方式を記載します。 + +**採用戦略**: [選択した戦略] + +**デプロイメント方式の比較**: + +| 方式 | メリット | デメリット | 採用判断 | +|------|----------|------------|----------| +| Blue-Green | ダウンタイムゼロ | リソース2倍必要 | [○/×] | +| Rolling | リソース効率的 | 段階的な切り替え | [○/×] | +| Canary | リスク最小化 | 複雑な制御必要 | [○/×] | + +**自動化ツール**: +- CI/CDツール: [ツール名] +- デプロイツール: [ツール名] +- インフラ管理: [ツール名] + +--- + +## 11. バックアップ・リカバリ + +### 11.1 バックアップ方針 + +バックアップの基本方針を記載します。 + +**バックアップ目的**: +- データ損失時の復旧 +- ランサムウェア等のセキュリティインシデント対応 +- 監査・コンプライアンス要件への対応 + +**バックアップ原則**: +- 3-2-1ルール: 3つのコピー、2つの異なるメディア、1つはオフサイト +- 暗号化されたバックアップの保管 +- 定期的なリストアテストの実施 + +### 11.2 バックアップ設計 + +バックアップ対象と方式を記載します。 + +| バックアップ対象 | バックアップ方式 | 頻度 | 世代管理 | 保管場所 | +|------------------|------------------|------|----------|----------| +| データベース | フル+差分 | 日次フル+6時間毎差分 | 30世代 | [場所] | +| ファイルストレージ | フル | 日次 | 7世代 | [場所] | +| システム設定 | フル | 変更時 | 10世代 | [場所] | +| ログファイル | 増分 | 1時間毎 | 90日 | [場所] | + +**バックアップスケジュール**: + +```mermaid +gantt + title バックアップスケジュール（1日） + dateFormat HH:mm + axisFormat %H:%M + + section データベース + フルバックアップ :00:00, 2h + 差分バックアップ1 :06:00, 30m + 差分バックアップ2 :12:00, 30m + 差分バックアップ3 :18:00, 30m + + section ファイル + フルバックアップ :02:00, 1h +``` + +### 11.3 リカバリ設計 + +リカバリの目標値と手順を記載します。 + +**リカバリ目標**: + +| 対象 | RPO（目標復旧時点） | RTO（目標復旧時間） | +|------|---------------------|---------------------| +| データベース | 6時間以内 | 4時間以内 | +| ファイルストレージ | 24時間以内 | 2時間以内 | +| システム全体 | 24時間以内 | 8時間以内 | + +**リカバリ手順**: + +#### データベースリカバリ +1. [手順1] +2. [手順2] +3. [手順3] + +**リカバリテスト**: +- 頻度: 四半期毎 +- 対象: [テスト対象] +- 成功基準: [基準] + +### 11.4 災害対策（DR） + +災害復旧計画を記載します。 + +**DR方針**: +- DR サイト: [有/無] +- DR 構成: [Hot Standby / Warm Standby / Cold Standby] + +**DR切り替えシナリオ**: + +| シナリオ | 発生条件 | 切り替え判断 | 切り替え時間目標 | +|----------|----------|--------------|------------------| +| データセンター障害 | [条件] | [判断基準] | [時間] | +| リージョン障害 | [条件] | [判断基準] | [時間] | + +--- + +## 12. セキュリティ運用 + +### 12.1 セキュリティ運用方針 + +セキュリティ運用の基本方針を記載します。 + +**セキュリティ原則**: +- 多層防御（Defense in Depth） +- 最小権限の原則 +- ゼロトラストアーキテクチャ +- 継続的なセキュリティ監視 + +### 12.2 アクセス管理 + +アクセス権限の管理方針を記載します。 + +**権限管理**: + +| ロール | 権限範囲 | 承認者 | レビュー頻度 | +|--------|----------|--------|--------------| +| システム管理者 | 全権限 | [承認者] | 月次 | +| 運用担当者 | 運用操作のみ | [承認者] | 月次 | +| 開発者 | 開発環境のみ | [承認者] | 月次 | +| 閲覧者 | 読み取りのみ | [承認者] | 四半期 | + +**アクセスレビュー**: +- 頻度: [頻度] +- 実施者: [担当者] +- レビュー内容: [内容] + +### 12.3 脆弱性管理 + +脆弱性の検出と対応プロセスを記載します。 + +**脆弱性スキャン**: +- ツール: [ツール名] +- 頻度: [頻度] +- 対象: [対象システム] + +**パッチ適用**: + +| 脆弱性レベル | 対応期限 | 承認プロセス | +|--------------|----------|--------------| +| Critical | 24時間以内 | 緊急変更 | +| High | 7日以内 | 通常変更 | +| Medium | 30日以内 | 通常変更 | +| Low | 90日以内 | 計画変更 | + +### 12.4 セキュリティインシデント対応 + +セキュリティインシデントの対応手順を記載します。 + +**セキュリティインシデント分類**: + +| レベル | 定義 | 例 | 対応時間 | +|--------|------|-----|----------| +| L1 | 重大な侵害 | データ漏洩、ランサムウェア | 即時 | +| L2 | 侵害の疑い | 不正アクセス試行 | 1時間以内 | +| L3 | セキュリティ違反 | ポリシー違反 | 24時間以内 | + +**対応フロー**: + +```mermaid +graph TD + Detect[検知] --> Contain[封じ込め] + Contain --> Eradicate[根絶] + Eradicate --> Recover[復旧] + Recover --> PostIncident[事後対応] + PostIncident --> Improve[改善] +``` + +**インシデント対応チーム（CSIRT）**: +- リーダー: [担当者] +- メンバー: [担当者リスト] +- 外部連絡先: [セキュリティベンダー、警察等] + +### 12.5 コンプライアンス + +法規制・コンプライアンス要件への対応を記載します。 + +**適用法規制**: +- [法規制名]: [要件概要] +- [法規制名]: [要件概要] + +**監査対応**: +- 内部監査: [頻度・実施者] +- 外部監査: [頻度・監査法人] +- 証跡管理: [保管方法・期間] + +--- + +## 13. キャパシティ管理 + +### 13.1 キャパシティ管理方針 + +キャパシティ管理の基本方針を記載します。 + +**キャパシティ管理の目的**: +- サービス品質の維持 +- コストの最適化 +- 将来の需要予測と計画 + +### 13.2 キャパシティ監視 + +監視対象リソースと閾値を記載します。 + +| リソース | 現在の使用率 | 警告閾値 | 限界閾値 | 対応アクション | +|----------|--------------|----------|----------|----------------| +| CPU | [%] | 70% | 85% | [アクション] | +| メモリ | [%] | 75% | 90% | [アクション] | +| ディスク | [%] | 80% | 90% | [アクション] | +| ネットワーク帯域 | [%] | 70% | 85% | [アクション] | + +### 13.3 キャパシティ計画 + +将来の需要予測と増強計画を記載します。 + +**需要予測**: + +| 期間 | 予想ユーザー数 | 予想トラフィック | 必要リソース | +|------|----------------|------------------|--------------| +| 3ヶ月後 | [数値] | [数値] | [内容] | +| 6ヶ月後 | [数値] | [数値] | [内容] | +| 1年後 | [数値] | [数値] | [内容] | + +**増強計画**: +- 実施時期: [時期] +- 増強内容: [内容] +- 見積もりコスト: [金額] + +### 13.4 スケーリング戦略 + +スケーリングの方針と実装を記載します。 + +**スケーリング方式**: +- 垂直スケーリング（スケールアップ）: [適用箇所] +- 水平スケーリング（スケールアウト）: [適用箇所] + +**オートスケーリング設定**: + +| 対象 | スケールアウト条件 | スケールイン条件 | 最小/最大インスタンス数 | +|------|-------------------|------------------|------------------------| +| [対象1] | [条件] | [条件] | [最小数]/[最大数] | +| [対象2] | [条件] | [条件] | [最小数]/[最大数] | + +--- + +## 14. コスト管理 + +### 14.1 コスト管理方針 + +コスト管理の基本方針を記載します。 + +**コスト管理の目的**: +- 予算内での運用実現 +- コスト効率の最適化 +- コスト可視化と予測 + +### 14.2 コスト構造 + +運用コストの内訳を記載します。 + +| コスト項目 | 月額コスト | 年額コスト | 備考 | +|------------|------------|------------|------| +| インフラコスト | [金額] | [金額] | [内訳] | +| ライセンスコスト | [金額] | [金額] | [内訳] | +| 人件費 | [金額] | [金額] | [内訳] | +| 外部委託費 | [金額] | [金額] | [内訳] | +| その他 | [金額] | [金額] | [内訳] | +| **合計** | [金額] | [金額] | | + +### 14.3 コスト最適化施策 + +コスト削減・最適化の取り組みを記載します。 + +**実施中の施策**: +1. [施策1]: [効果] +2. [施策2]: [効果] + +**計画中の施策**: +1. [施策1]: [期待効果] +2. [施策2]: [期待効果] + +### 14.4 コスト監視 + +コストの監視とアラート設定を記載します。 + +**コスト監視**: +- ツール: [ツール名] +- 監視頻度: [頻度] +- レポート: [頻度・宛先] + +**コストアラート**: +- 月次予算超過アラート: [閾値] +- 異常なコスト増加アラート: [条件] + +--- + +## 15. 問題管理 + +### 15.1 問題管理方針 + +問題管理の基本方針を記載します。 + +**問題の定義**: +1つ以上のインシデントの根本原因、または潜在的なインシデントの原因 + +**問題管理の目的**: +- インシデントの根本原因の特定と除去 +- 既知のエラーの記録と回避策の提供 +- 再発防止策の実装 + +### 15.2 問題管理プロセス + +問題管理のフローを記載します。 + +```mermaid +graph TD + Incident[インシデント発生] --> Analysis[傾向分析] + Analysis --> Problem{問題として
管理すべきか？} + + Problem -->|Yes| Register[問題登録] + Problem -->|No| End1[終了] + + Register --> Investigate[根本原因分析] + Investigate --> Known[既知のエラー登録] + + Known --> Workaround[回避策の提供] + Known --> Solution[恒久対策の検討] + + Solution --> Implement[対策実装] + Implement --> Verify[効果検証] + Verify --> Close[クローズ] +``` + +### 15.3 既知のエラー管理 + +既知のエラーと回避策を記録します。 + +| エラーID | 問題概要 | 影響 | 回避策 | 恒久対策の状況 | +|----------|----------|------|--------|----------------| +| KE-001 | [概要] | [影響] | [回避策] | [状況] | +| KE-002 | [概要] | [影響] | [回避策] | [状況] | + +--- + +## 16. ナレッジ管理 + +### 16.1 ナレッジ管理方針 + +ナレッジの蓄積と共有の方針を記載します。 + +**ナレッジ管理の目的**: +- 運用ノウハウの蓄積と継承 +- 問題解決の効率化 +- 属人化の排除 + +### 16.2 ドキュメント体系 + +管理するドキュメントの種類と保管場所を記載します。 + +| ドキュメント種別 | 保管場所 | 更新頻度 | 管理者 | +|------------------|----------|----------|--------| +| 運用設計書 | [場所] | [頻度] | [担当] | +| 運用手順書 | [場所] | [頻度] | [担当] | +| 障害対応手順書 | [場所] | [頻度] | [担当] | +| FAQ | [場所] | [頻度] | [担当] | +| ポストモーテム | [場所] | 都度 | [担当] | + +### 16.3 ドキュメント管理ルール + +ドキュメントの作成・更新・レビューのルールを記載します。 + +**作成ルール**: +- テンプレートの使用 +- 命名規則の遵守 +- バージョン管理の実施 + +**更新ルール**: +- 変更履歴の記録 +- レビュープロセスの実施 +- 関連ドキュメントの同期更新 + +**レビュープロセス**: +- レビュー頻度: [頻度] +- レビュー担当: [担当者] +- レビュー基準: [基準] + +--- + +## 17. 継続的改善 + +### 17.1 改善活動方針 + +継続的改善の基本方針を記載します。 + +**改善の原則**: +- データドリブンな意思決定 +- 小さな改善の積み重ね +- チーム全体での取り組み +- 定期的な振り返りと学び + +### 17.2 改善プロセス + +改善活動のサイクルを記載します。 + +```mermaid +graph LR + Plan[計画
Plan] --> Do[実行
Do] + Do --> Check[評価
Check] + Check --> Act[改善
Act] + Act --> Plan +``` + +**改善活動の実施**: +- 週次: チーム振り返り +- 月次: メトリクスレビュー +- 四半期: 運用プロセスレビュー +- 年次: 運用戦略レビュー + +### 17.3 運用メトリクス + +運用品質を測定する指標を記載します。 + +| メトリクス | 目標値 | 測定方法 | レポート頻度 | +|------------|--------|----------|--------------| +| 可用性 | 99.9%以上 | [方法] | 月次 | +| MTBF（平均故障間隔） | [目標] | [方法] | 月次 | +| MTTR（平均復旧時間） | 30分以内 | [方法] | 月次 | +| 変更成功率 | 95%以上 | [方法] | 月次 | +| インシデント件数 | [目標] | [方法] | 月次 | +| デプロイ頻度 | [目標] | [方法] | 月次 | + +### 17.4 改善施策管理 + +改善施策の管理方法を記載します。 + +**改善施策リスト**: + +| 施策ID | 施策名 | 目的 | 担当 | 期限 | ステータス | +|--------|--------|------|------|------|------------| +| IMP-001 | [施策名] | [目的] | [担当] | [期限] | [ステータス] | +| IMP-002 | [施策名] | [目的] | [担当] | [期限] | [ステータス] | + +--- + +## 18. 運用ツール + +### 18.1 運用ツール一覧 + +使用する運用ツールを記載します。 + +| カテゴリ | ツール名 | 用途 | ライセンス | 管理者 | +|----------|----------|------|------------|--------| +| 監視 | [ツール名] | [用途] | [ライセンス] | [担当] | +| ログ管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| インシデント管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| 変更管理 | [ツール名] | [用途] | [ライセンス] | [担当] | +| CI/CD | [ツール名] | [用途] | [ライセンス] | [担当] | +| コミュニケーション | [ツール名] | [用途] | [ライセンス] | [担当] | + +### 18.2 ツール統合 + +ツール間の連携を記載します。 + +**統合フロー**: + +```mermaid +graph LR + Monitor[監視ツール] -->|アラート| Incident[インシデント管理] + Incident -->|通知| Chat[チャットツール] + Chat -->|トリガー| CICD[CI/CDツール] + CICD -->|ログ| LogTool[ログ管理ツール] + LogTool -->|メトリクス| Monitor +``` + +--- + +## 19. 付録 + +### 19.1 用語集 + +本ドキュメントで使用する用語の定義を記載します。 + +| 用語 | 定義 | +|------|------| +| SLO | Service Level Objective: サービスレベル目標 | +| SLI | Service Level Indicator: サービスレベル指標 | +| SLA | Service Level Agreement: サービスレベル合意 | +| MTTR | Mean Time To Repair: 平均復旧時間 | +| MTBF | Mean Time Between Failures: 平均故障間隔 | +| RPO | Recovery Point Objective: 目標復旧時点 | +| RTO | Recovery Time Objective: 目標復旧時間 | +| RACI | Responsible, Accountable, Consulted, Informed | + +### 19.2 参照ドキュメント + +関連ドキュメントへのリンクを記載します。 + +| ドキュメント名 | 場所/URL | 備考 | +|----------------|----------|------| +| システム設計書 | [リンク] | [備考] | +| セキュリティポリシー | [リンク] | [備考] | +| 運用手順書 | [リンク] | [備考] | + +### 19.3 連絡先 + +運用に関わる主要な連絡先を記載します。 + +| 役割 | 担当者 | 連絡先 | 対応時間 | +|------|--------|--------|----------| +| 運用マネージャー | [名前] | [連絡先] | [時間] | +| オンコール担当 | [名前] | [連絡先] | 24/365 | +| セキュリティ担当 | [名前] | [連絡先] | [時間] | + +### 19.4 承認 + +本ドキュメントの承認記録を記載します。 + +| 役割 | 氏名 | 承認日 | 署名 | +|------|------|--------|------| +| 作成者 | [名前] | [日付] | | +| レビュアー | [名前] | [日付] | | +| 承認者 | [名前] | [日付] | | + +--- + +## 運用設計書作成時の注意事項 + +本テンプレートを使用する際は、以下の点に注意してください： + +1. **プロジェクト特性に応じたカスタマイズ** + - すべてのセクションが必要とは限りません + - プロジェクトの規模や性質に応じて取捨選択してください + +2. **具体性の確保** + - 抽象的な記述ではなく、具体的な数値や手順を記載してください + - 「適切に」「十分に」などの曖昧な表現は避けてください + +3. **測定可能性** + - 目標値は測定可能な形で定義してください + - 測定方法も明記してください + +4. **継続的な更新** + - 運用開始後も定期的に見直し、更新してください + - 実態との乖離が生じないよう注意してください + +5. **ステークホルダーの合意** + - 関係者全員で内容を確認し、合意を形成してください + - 特にSLOや運用体制については十分な議論が必要です diff --git a/skills/operations-design/guides/conversation_logging.md b/skills/operations-design/guides/conversation_logging.md new file mode 100644 index 0000000..02fa127 --- /dev/null +++ b/skills/operations-design/guides/conversation_logging.md @@ -0,0 +1,167 @@ +# 会話ログ管理ガイド + +**【重要】すべてのユーザーとの会話は会話ログファイルに記録すること** + +運用設計のコンサルティング過程で収集したすべての情報をファイルに記録し、コンテキストを失わないようにします。 + +## 会話ログの目的 + +1. **コンテキストの保持** + - ヒアリング内容を確実に記録 + - 過去の会話内容をいつでも参照可能 + - 長期間のセッションでも情報を失わない + +2. **決定事項の追跡** + - ユーザーの選択と判断を記録 + - 決定の理由と背景を保持 + - 設計の根拠を明確化 + +3. **未確認事項の管理** + - 保留事項の追跡 + - 後で確認すべき項目の管理 + - 情報不足箇所の可視化 + +## 会話ログファイルの作成と管理 + +**ファイル名**: `[YYYY-MM-DD]-[サービス名]-conversation-log.md` + +**保存場所**: 運用設計書と同じディレクトリ + +**初期化タイミング**: 運用設計セッション開始時（業界トレンド調査の前） + +**初期化手順**: + +``` +1. セッション開始時にWriteツールを使用して会話ログファイルを作成 +2. assets/templates/conversation_log_template_ja.md をテンプレートとして使用 +3. セッション情報（開始日時、対象サービス等）を記入 +4. ユーザーに会話ログファイルの作成を通知 +``` + +**初期化の例**: + +``` +コンサルタント: 運用設計セッションを開始します。 + + まず、会話ログファイルを作成しました： + `2025-11-17-ECサイト-conversation-log.md` + + このファイルに、これからのすべての会話内容、収集した情報、 + 決定事項を記録していきます。 + + それでは、業界トレンド調査から開始させてください。 +``` + +## 会話ログの記録タイミング + +**以下のタイミングで必ず会話ログを更新すること**: + +1. **業界トレンド調査後** + - 調査した内容をログに記録 + - 主要なトレンドと調査結果を記載 + +2. **各ヒアリング質問の後** + - 質問内容と回答を記録 + - 重要なポイントや決定事項を記載 + - 次のアクションを記録 + +3. **各セクション完成後** + - セクション内容の承認状況を記録 + - 修正要求や追加要望を記載 + +4. **一貫性チェック後** + - 発見した矛盾点を記録 + - ユーザーの判断と対応を記載 + +5. **セッション終了時** + - 最終的な決定事項をまとめる + - 未確認事項・保留事項を整理 + - 次のステップを記録 + +## 会話ログの更新方法 + +**Editツールを使用して更新する**: + +``` +1. 会話が発生したら、その内容を整理 +2. Editツールで会話ログファイルの該当セクションを更新 +3. タイムスタンプと内容を追加 +4. 重要なポイント、決定事項、次のアクションを記録 +``` + +**更新の例**: + +```markdown +### [14:30] 可用性要件の確認 + +**コンサルタント**: +``` +可用性目標について確認させてください： + +A) 99.9%（月間ダウンタイム約43分） ⭐⭐⭐⭐ +B) 99.95%（月間ダウンタイム約22分） ⭐⭐⭐⭐⭐ +C) 99.99%（月間ダウンタイム約4分） ⭐⭐ + +どれを選択しますか？ +``` + +**ユーザー回答**: +``` +B) 99.95%を選択します。決済機能があるため、 +より高い可用性が必要だと考えています。 +``` + +**記録事項**: +- 可用性目標: 99.95%に決定 +- 理由: 決済機能を含むため、高い可用性が必要 +- 次のアクション: SLO設定に99.95%を反映 +``` + +## 会話ログのサマリー更新 + +**セッション中、定期的にサマリーセクションを更新する**: + +```markdown +## 収集した情報のサマリー + +### サービス基本情報 +- サービス名: ECショッピングサイト +- 目的: オンラインでの商品販売 +- 対象ユーザー: 一般消費者（B2C） +- 想定ユーザー数: 月間10万人 + +### システム構成 +- アーキテクチャ: マイクロサービス +- 技術スタック: + - フロントエンド: React + - バックエンド: Node.js + - データベース: PostgreSQL + - インフラ: AWS + +### 運用要件 +- 可用性目標: 99.95% +- サービス提供時間: 24/365 +- パフォーマンス要件: P95レスポンス < 500ms +- セキュリティ要件: PCI DSS準拠 + +### 決定事項 +1. 可用性目標を99.95%に設定 +2. 24時間365日のオンコール体制を構築 +3. AWS Auto Scalingを使用したスケーリング戦略 + +### 未確認事項・保留事項 +1. バックアップのRPO目標: 後日確認 +2. 災害対策のRTO目標: 次回セッションで決定 +``` + +## 会話ログの活用 + +**設計書作成時の参照**: +- 会話ログの情報を基に運用設計書を作成 +- 決定事項の根拠として会話ログを参照 +- 不明点が出た場合は会話ログで過去の議論を確認 + +**一貫性チェック時の参照**: +- 会話ログの決定事項と設計書の整合性を確認 +- 矛盾がある場合は会話ログで経緯を確認 +- ユーザーに再確認が必要な場合は過去の議論を提示 diff --git a/skills/operations-design/hearing_items/2-9_security_compliance.md b/skills/operations-design/hearing_items/2-9_security_compliance.md new file mode 100644 index 0000000..9d3076a --- /dev/null +++ b/skills/operations-design/hearing_items/2-9_security_compliance.md @@ -0,0 +1,234 @@ +# セキュリティ・コンプライアンス要件ヒアリング + +**【重要】DevSecOpsの実装に必要な情報。セキュリティ要件が不明確だとCI/CDに組み込むべきチェック項目が決まらない** + +## ヒアリング実施方法 + +``` +コンサルタント: （AskUserQuestionツールを使用） + セキュリティとコンプライアンスについて詳しく確認させてください。 + DevSecOps実践のため、CI/CDパイプラインに組み込むセキュリティチェックを設計します。 +``` + +## Q1: コンプライアンス要件 + +準拠すべき法規制や業界標準はありますか？ + +### A) 個人情報保護法・GDPR ⭐⭐⭐⭐⭐ +- 個人情報を扱う +- GDPR準拠が必要（EU圏ユーザー対象） +- データ保持期間の制限あり + +**推奨理由**: データ保護とプライバシー要件を満たす +**考慮事項**: データの暗号化、アクセスログ、削除機能が必須 + +### B) PCI DSS（クレジットカード情報） ⭐⭐⭐⭐ +- クレジットカード情報を取り扱う +- PCI DSS準拠が必要 +- 定期的なセキュリティ監査が必要 + +**推奨理由**: 決済セキュリティの業界標準 +**考慮事項**: カード情報の非保持化、トークン化を推奨 + +### C) 医療系規制（HIPAA等） ⭐⭐⭐⭐ +- 医療情報を取り扱う +- HIPAA等の医療系規制に準拠 + +**推奨理由**: 医療データ保護の必須要件 +**考慮事項**: 厳格なアクセス制御、監査ログが必須 + +### D) 金融系規制（金融商品取引法等） ⭐⭐⭐⭐⭐ +- 金融商品・サービスを提供 +- 金融庁の規制に準拠 + +**推奨理由**: 金融サービスの法的要件 +**考慮事項**: 高レベルのセキュリティと監査証跡が必須 + +### E) 特になし ⭐⭐⭐ +- 特定の規制要件なし +- 一般的なセキュリティベストプラクティスのみ + +**推奨理由**: 最小限のコンプライアンス負担 +**考慮事項**: 将来の規制対応を考慮した設計を推奨 + +## Q2: 認証・認可要件 + +### 認証方式 +- A) ID/パスワード（基本） +- B) 多要素認証（MFA）必須 +- C) SSO（SAML/OAuth/OIDC）対応 +- D) 生体認証対応 + +### セッション管理 +- セッションタイムアウト: [XX]分 +- 同時ログイン: 許可/禁止 +- デバイス管理: 必要/不要 + +### パスワードポリシー +- 最小文字数: [XX]文字 +- 複雑性要件: あり/なし +- 有効期限: [XX]日/無制限 +- 履歴管理: 過去[XX]回分 + +## Q3: アクセス制御（認可） + +### ロール設計 +- ロール数: [XX]種類 +- 主要ロール: [管理者/一般ユーザー/読み取り専用/等] +- ロールの詳細度: 粗い/細かい + +### アクセス制御モデル +- A) RBAC（ロールベース） +- B) ABAC（属性ベース） +- C) リソースオーナーベース +- D) 組織階層ベース + +## Q4: セキュリティ脅威への対応 + +以下の脅威について、対策の優先度を教えてください： + +- SQLインジェクション: 対策必須/対策不要（理由: [XX]） +- XSS（クロスサイトスクリプティング）: 対策必須/対策不要 +- CSRF（クロスサイトリクエストフォージェリ）: 対策必須/対策不要 +- DDoS攻撃: 対策必須/対策不要 +- 不正アクセス（総当たり攻撃）: 対策必須/対策不要 +- APIの不正利用: 対策必須/対策不要 + +## Q5: データ保護要件 + +### 保存時の暗号化（Encryption at Rest） +- A) すべてのデータを暗号化 ⭐⭐⭐⭐⭐ +- B) 機密データのみ暗号化 ⭐⭐⭐⭐ +- C) 暗号化不要 ⭐⭐ + +### 通信時の暗号化（Encryption in Transit） +- A) すべての通信をTLS/HTTPS化 ⭐⭐⭐⭐⭐（必須） +- B) 外部通信のみTLS/HTTPS ⭐⭐⭐⭐ +- C) 暗号化不要 ⭐（推奨しない） + +### 鍵管理 +- A) クラウドKMS使用（AWS KMS/GCP KMS等） ⭐⭐⭐⭐⭐ +- B) 自社で鍵管理 ⭐⭐⭐ +- C) ハードコード（推奨しない） ⭐ + +## Q6: 機密情報の管理方法 + +### 環境変数・シークレット管理 +- A) AWS Secrets Manager / GCP Secret Manager ⭐⭐⭐⭐⭐ +- B) HashiCorp Vault ⭐⭐⭐⭐ +- C) Kubernetes Secrets ⭐⭐⭐ +- D) 環境変数のみ ⭐⭐ +- E) 設定ファイル（推奨しない） ⭐ + +### シークレットのローテーション +- ローテーション頻度: [XX]日ごと/月次/年次/不要 +- 自動ローテーション: 必要/不要 + +## Q7: CI/CDセキュリティ要件 + +以下のチェックについて、導入の可否を教えてください： + +### SAST（静的アプリケーションセキュリティテスト） +- 導入: 必須/推奨/不要 +- ツール候補: SonarQube/Checkmarx/Snyk Code/等 +- 失敗時の動作: ビルド失敗/警告のみ + +### 依存関係の脆弱性スキャン +- 導入: 必須/推奨/不要 +- ツール候補: Snyk/Dependabot/Trivy/等 +- スキャン対象: すべての依存関係/直接依存のみ +- 失敗時の動作: ビルド失敗/警告のみ + +### コンテナイメージスキャン +- 導入: 必須/推奨/不要 +- ツール候補: Trivy/Clair/Anchore/等 +- 重大度の閾値: Critical/High/Medium以上でビルド失敗 + +### DAST（動的アプリケーションセキュリティテスト） +- 導入: 必須/推奨/不要 +- 実施タイミング: ステージング環境/本番前/定期実行 + +### シークレットスキャン（ハードコード検出） +- 導入: 必須/推奨/不要 +- ツール候補: git-secrets/TruffleHog/Gitleaks/等 + +## Q8: 監査・ログ要件 + +### 記録対象 +- ユーザーアクション: すべて/重要なもののみ +- システム変更: すべて/重要なもののみ +- データアクセス: すべて/機密データのみ +- 認証イベント: すべて/失敗のみ + +### ログ保持期間 +- 最低保持期間: [XX]ヶ月/[XX]年 +- 法的要件による保持: あり（期間: [XX]）/なし + +### ログの改ざん防止 +- 必要/不要 +- 手段: 署名/ブロックチェーン/イミュータブルストレージ + +--- + +## ヒアリング終了メッセージ + +``` +ユーザー: [回答] + +コンサルタント: ありがとうございます。 + + [Editツールで会話ログに記録] + + セキュリティ要件を踏まえた、DevSecOpsパイプラインと運用設計を行います。 + これでサービス仕様のヒアリングは完了しました。 + 次に、運用設計書の作成に進みます。 +``` + +## 会話ログ記録フォーマット + +```markdown +### [HH:MM] セキュリティ・コンプライアンス要件の詳細確認 + +**コンプライアンス要件**: +- 準拠法規: [GDPR/PCI DSS/HIPAA/金融規制/特になし] +- 業界標準: [リスト] + +**認証・認可要件**: +- 認証方式: [ID・パスワード/MFA/SSO/生体認証] +- セッションタイムアウト: [XX]分 +- パスワードポリシー: [詳細] +- ロール数: [XX]種類 +- アクセス制御モデル: [RBAC/ABAC/その他] + +**セキュリティ脅威対策**: +- SQLインジェクション: [対策必須/不要] +- XSS: [対策必須/不要] +- CSRF: [対策必須/不要] +- DDoS: [対策必須/不要] +- 総当たり攻撃: [対策必須/不要] +- API不正利用: [対策必須/不要] + +**データ保護**: +- 保存時暗号化: [すべて/機密データのみ/不要] +- 通信暗号化: [すべてTLS/外部のみTLS] +- 鍵管理: [クラウドKMS/自社管理/ハードコード] +- シークレット管理: [Secrets Manager/Vault/K8s Secrets/環境変数] +- ローテーション頻度: [XX]日/月次/年次 + +**CI/CDセキュリティチェック**: +- SAST: [必須/推奨/不要]、ツール: [ツール名] +- 依存関係スキャン: [必須/推奨/不要]、ツール: [ツール名] +- コンテナスキャン: [必須/推奨/不要]、ツール: [ツール名] +- DAST: [必須/推奨/不要]、タイミング: [タイミング] +- シークレットスキャン: [必須/推奨/不要]、ツール: [ツール名] + +**監査ログ要件**: +- 記録対象: [すべて/重要なもののみ] +- 保持期間: [XX]ヶ月/年 +- 改ざん防止: [必要/不要]、手段: [手段] + +**記録事項**: +- DevSecOpsパイプラインへの反映: [内容] +- セキュリティ運用への反映: [内容] +- 次のアクション: 運用設計書の作成開始 +``` diff --git a/skills/operations-design/references/industry_research_guide_ja.md b/skills/operations-design/references/industry_research_guide_ja.md new file mode 100644 index 0000000..7b96e06 --- /dev/null +++ b/skills/operations-design/references/industry_research_guide_ja.md @@ -0,0 +1,765 @@ +# 業界調査ガイドライン + +このドキュメントは、運用設計を開始する前に実施する業界調査の方法とベストプラクティスをまとめています。 + +## 目次 + +1. [業界調査の目的](#業界調査の目的) +2. [調査の進め方](#調査の進め方) +3. [業界別の調査ポイント](#業界別の調査ポイント) +4. [最新トレンドの把握](#最新トレンドの把握) +5. [調査結果の活用](#調査結果の活用) + +--- + +## 業界調査の目的 + +### なぜ業界調査が必要か + +運用設計において業界調査は以下の理由で重要です： + +1. **業界標準の把握** + - 同業他社のベンチマーク + - 業界で期待されるサービスレベル + - 一般的な運用プラクティス + +2. **最新トレンドの取り込み** + - 新しい技術の活用 + - モダンな運用手法の導入 + - 競争優位性の確保 + +3. **規制・コンプライアンス要件の理解** + - 業界固有の法規制 + - セキュリティ基準 + - データ保護要件 + +4. **リスクの事前把握** + - 業界特有のリスク + - 過去の事例からの学び + - セキュリティ脅威の理解 + +### 調査のスコープ + +**必須調査項目**: +- 業界の最新動向 +- 主要な技術トレンド +- セキュリティ・コンプライアンス要件 +- 一般的なSLO/SLA水準 + +**任意調査項目**（プロジェクトに応じて）: +- 競合分析 +- ユーザー期待値 +- コスト構造 +- 運用組織体制 + +--- + +## 調査の進め方 + +### ステップ1: 業界分類の特定 + +まず、対象サービスがどの業界に属するかを明確にします。 + +**主要な業界分類**: + +| 分類 | サブカテゴリ | 特徴 | +|------|--------------|------| +| **Webサービス/SaaS** | B2B SaaS, B2C SaaS, プラットフォーム | 高可用性、スケーラビリティ重視 | +| **EC/マーケットプレイス** | EC, マーケットプレイス, 決済サービス | トランザクション精度、PCI DSS | +| **金融サービス** | 銀行, 証券, 保険, フィンテック | 高セキュリティ、監査要件 | +| **メディア/コンテンツ** | 動画配信, 音楽配信, ニュース | 高トラフィック、CDN | +| **ヘルスケア** | 電子カルテ, 遠隔医療, 健康管理アプリ | HIPAA, 個人情報保護 | +| **ゲーム** | モバイルゲーム, オンラインゲーム | リアルタイム性、ピーク対策 | +| **IoT/組み込み** | スマートホーム, 産業IoT | エッジコンピューティング | +| **エンタープライズ** | 社内システム, ERP | 業務継続性、セキュリティ | + +### ステップ2: Web検索の実施 + +**推奨検索クエリパターン**: + +``` +基本パターン: +"[業界名] 運用設計 最新トレンド" +"[業界名] IT運用 ベストプラクティス 最新" +"[サービスタイプ] SRE DevOps 事例" + +英語での検索（より多くの情報）: +"[industry] operations design latest trends" +"[industry] IT operations best practices" +"[service type] SRE case study" + +フレームワーク特化: +"ITIL 4 [業界名] 適用事例" +"SRE [業界名] 実践" +"DevOps [業界名] 導入" + +セキュリティ・コンプライアンス: +"[業界名] セキュリティ 規制 最新" +"[業界名] コンプライアンス 要件" +"[industry] security compliance requirements" +``` + +**検索ソースの優先順位**: + +1. **公式ドキュメント・標準規格** + - ITIL公式サイト + - SRE Workbook（Google） + - 業界団体の公式サイト + +2. **技術ブログ・カンファレンス資料** + - 大手テック企業のエンジニアリングブログ + - SREcon, DevOpsDays等の資料 + - Medium, Qiita, Zenn等の技術記事 + +3. **調査レポート・市場分析** + - Gartner + - IDC + - Forrester + +4. **ニュースサイト** + - TechCrunch + - InfoQ + - DZone + +### ステップ3: 情報の整理 + +調査した情報を以下のカテゴリで整理します： + +#### 1. 業界トレンド + +**整理フォーマット**: + +```markdown +## [業界名]の最新トレンド + +### トレンド1: [トレンド名] +- **概要**: [トレンドの説明] +- **背景**: [なぜこのトレンドが生まれたか] +- **主要技術**: [関連する技術・ツール] +- **採用企業**: [採用している企業例] +- **本サービスへの適用可能性**: [高/中/低] +- **適用する場合の方針**: [どのように適用するか] +- **参照URL**: [情報源] +``` + +**例**: + +```markdown +### トレンド1: サーバーレスアーキテクチャの採用拡大 +- **概要**: AWS Lambda, Google Cloud Functions等のサーバーレス + 技術を活用し、インフラ管理の負荷を削減 +- **背景**: 運用コスト削減とスケーラビリティの向上 +- **主要技術**: AWS Lambda, API Gateway, DynamoDB +- **採用企業**: Netflix, Coca-Cola, Airbnb +- **本サービスへの適用可能性**: 中 + （一部のバッチ処理やAPI機能で適用検討） +- **適用する場合の方針**: + - まずはバッチ処理から試験導入 + - コールドスタート対策を検討 + - コスト監視を徹底 +- **参照URL**: https://... +``` + +#### 2. 技術スタック + +**整理フォーマット**: + +```markdown +## 推奨技術スタック + +| カテゴリ | 推奨技術 | 理由 | 採用率 | 参照 | +|----------|----------|------|--------|------| +| インフラ | [技術名] | [理由] | [%] | [URL] | +| 監視 | [技術名] | [理由] | [%] | [URL] | +| CI/CD | [技術名] | [理由] | [%] | [URL] | +``` + +#### 3. SLO/SLA水準 + +**整理フォーマット**: + +```markdown +## 業界標準のSLO/SLA + +| メトリクス | 標準値 | トップレベル | 参照 | +|------------|--------|--------------|------| +| 可用性 | 99.9% | 99.99% | [URL] | +| レスポンスタイム（P95） | 500ms | 200ms | [URL] | +| エラーレート | 0.1% | 0.01% | [URL] | +``` + +#### 4. セキュリティ・コンプライアンス + +**整理フォーマット**: + +```markdown +## セキュリティ・コンプライアンス要件 + +### 適用法規制 +- [法規制名1]: [概要と要件] +- [法規制名2]: [概要と要件] + +### セキュリティ基準 +- [基準名1]: [要求事項] +- [基準名2]: [要求事項] + +### 必須対策 +1. [対策1] +2. [対策2] +``` + +--- + +## 業界別の調査ポイント + +### Webサービス/SaaS + +**重点調査項目**: + +1. **可用性とパフォーマンス** + - 業界標準: 99.9%以上 + - レスポンスタイム: P95で500ms以下 + - スケーラビリティ戦略 + +2. **マルチテナンシー** + - データ分離方式（DB分離 vs スキーマ分離 vs行レベル分離） + - テナント間の影響隔離 + - リソース配分 + +3. **API設計** + - RESTful API vs GraphQL + - レート制限 + - バージョニング戦略 + +4. **認証・認可** + - OAuth 2.0, OpenID Connect + - SSO対応 + - MFA（多要素認証） + +**推奨検索クエリ**: + +``` +"SaaS 可用性 ベストプラクティス" +"マルチテナント アーキテクチャ 設計" +"SaaS セキュリティ 最新" +"API design best practices" +``` + +**主要参照先**: + +- [The Twelve-Factor App](https://12factor.net/) +- AWS SaaS Factory +- Microsoft SaaS Architecture Guide + +### EC/マーケットプレイス + +**重点調査項目**: + +1. **トランザクション管理** + - ACID特性の保証 + - 分散トランザクション + - 在庫管理の整合性 + +2. **決済セキュリティ** + - PCI DSS準拠 + - トークン化 + - 不正検知 + +3. **ピーク対策** + - セール時のトラフィック急増対策 + - キューイングシステム + - キャッシュ戦略 + +4. **検索・レコメンデーション** + - 検索エンジン（Elasticsearch等） + - パーソナライゼーション + - リアルタイム在庫連携 + +**推奨検索クエリ**: + +``` +"EC サイト 運用設計" +"PCI DSS 対応 要件" +"EC ピーク対策 アーキテクチャ" +"マーケットプレイス スケーラビリティ" +``` + +**主要参照先**: + +- PCI Security Standards Council +- Amazon Architecture Blog（Black Friday対策等） +- Shopify Engineering Blog + +### 金融サービス + +**重点調査項目**: + +1. **規制対応** + - 金融商品取引法 + - 銀行法 + - 各国の金融規制（日本:金融庁、米国:SEC, FINRA等） + +2. **高可用性** + - 99.99%以上の可用性 + - ゼロダウンタイムデプロイ + - DR（災害復旧）対策 + +3. **セキュリティ** + - 暗号化（転送時、保管時） + - アクセス制御 + - 監査ログ + +4. **データ整合性** + - 二重引き落とし防止 + - データ復旧手順 + - バックアップ戦略 + +**推奨検索クエリ**: + +``` +"金融システム 可用性 要件" +"金融機関 セキュリティ ガイドライン" +"fintech 規制 コンプライアンス 最新" +"banking system architecture" +``` + +**主要参照先**: + +- 金融情報システムセンター（FISC） +- 金融庁ガイドライン +- Basel Committee on Banking Supervision + +### メディア/コンテンツ配信 + +**重点調査項目**: + +1. **CDN戦略** + - グローバル配信 + - エッジキャッシング + - DDoS対策 + +2. **動画配信** + - アダプティブビットレート + - トランスコーディング + - DRM（デジタル著作権管理） + +3. **スケーラビリティ** + - バイラルコンテンツ対策 + - ライブ配信のピーク対策 + - オートスケーリング + +4. **コンテンツ管理** + - メタデータ管理 + - バージョン管理 + - コンテンツ配信ワークフロー + +**推奨検索クエリ**: + +``` +"動画配信 アーキテクチャ" +"CDN ベストプラクティス 最新" +"ライブストリーミング スケーラビリティ" +"content delivery network optimization" +``` + +**主要参照先**: + +- Netflix Tech Blog +- YouTube Engineering Blog +- Cloudflare Blog + +### ヘルスケア + +**重点調査項目**: + +1. **個人情報保護** + - HIPAA（米国） + - 個人情報保護法（日本） + - GDPR（EU） + +2. **医療データ管理** + - HL7 FHIR標準 + - 電子カルテ連携 + - 医療画像管理（DICOM） + +3. **可用性** + - 医療業務継続性 + - 緊急時対応 + - バックアップ・DR + +4. **監査対応** + - アクセスログ + - 変更履歴 + - 監査レポート + +**推奨検索クエリ**: + +``` +"ヘルスケア システム セキュリティ" +"HIPAA 準拠 要件" +"電子カルテ 連携 標準" +"healthcare IT security latest" +``` + +**主要参照先**: + +- HIPAA Journal +- HL7 International +- 厚生労働省「医療情報システムの安全管理に関するガイドライン」 + +### ゲーム + +**重点調査項目**: + +1. **リアルタイム性** + - 低レイテンシ（<100ms） + - リアルタイム同期 + - チート対策 + +2. **スケーラビリティ** + - 同時接続数の急増対応 + - ワールドサーバーのスケーリング + - マッチングシステム + +3. **データ管理** + - プレイヤーデータの永続化 + - セーブデータの整合性 + - ランキングシステム + +4. **運用** + - ライブオペレーション + - イベント運営 + - ゲームバランス調整 + +**推奨検索クエリ**: + +``` +"オンラインゲーム サーバー アーキテクチャ" +"ゲーム 低レイテンシ 設計" +"multiplayer game server architecture" +"game backend scalability" +``` + +**主要参照先**: + +- Unity Blog +- Epic Games Engineering +- PlayFab Documentation（Microsoft） + +--- + +## 最新トレンドの把握 + +### 主要トレンド + +#### 1. 生成AI/LLMの運用への統合 + +**トレンド概要**: +- ChatGPT、Claude等のLLMを活用した運用自動化 +- インシデント対応の支援 +- ドキュメント生成の自動化 + +**調査ポイント**: +- 業界での採用事例 +- セキュリティ・プライバシー対策 +- コスト管理 +- プロンプトエンジニアリング + +**検索クエリ**: +``` +"AI 運用自動化 最新" +"LLM インシデント対応" +"generative AI operations" +"AI ops automation latest" +``` + +#### 2. クラウドネイティブアーキテクチャ + +**トレンド概要**: +- Kubernetes採用の拡大 +- サーバーレスアーキテクチャ +- マイクロサービス化 + +**調査ポイント**: +- コンテナオーケストレーション +- サービスメッシュ（Istio, Linkerd） +- オブザーバビリティ（OpenTelemetry） + +**検索クエリ**: +``` +"Kubernetes 運用 ベストプラクティス 最新" +"サーバーレス アーキテクチャ 事例" +"cloud native operations" +"service mesh adoption latest" +``` + +#### 3. Platform Engineering + +**トレンド概要**: +- 開発者体験（DX）の向上 +- セルフサービスプラットフォーム +- Internal Developer Portal + +**調査ポイント**: +- プラットフォームチームの組織 +- ツールチェーンの統合 +- ゴールデンパスの定義 + +**検索クエリ**: +``` +"プラットフォームエンジニアリング 最新" +"Internal Developer Portal" +"platform engineering best practices" +"developer experience latest" +``` + +#### 4. FinOps（クラウドコスト最適化） + +**トレンド概要**: +- クラウドコストの可視化と最適化 +- FinOpsプラクティスの確立 +- コスト配分の明確化 + +**調査ポイント**: +- コスト最適化手法 +- ツール（Kubecost, CloudHealth等） +- 組織体制 + +**検索クエリ**: +``` +"FinOps ベストプラクティス 最新" +"クラウドコスト 最適化" +"cloud cost optimization latest" +"FinOps framework" +``` + +#### 5. セキュリティの強化 + +**トレンド概要**: +- ゼロトラストアーキテクチャ +- DevSecOpsの浸透 +- SBOM（Software Bill of Materials） + +**調査ポイント**: +- ゼロトラスト実装 +- セキュリティの左シフト +- サプライチェーンセキュリティ + +**検索クエリ**: +``` +"ゼロトラスト アーキテクチャ 最新" +"DevSecOps 実践" +"zero trust implementation" +"software supply chain security latest" +``` + +#### 6. SRE/DevOpsの成熟 + +**トレンド概要**: +- SLO文化の浸透 +- エラーバジェットの活用 +- カオスエンジニアリング + +**調査ポイント**: +- SRE組織の作り方 +- オブザーバビリティの実践 +- レジリエンス向上施策 + +**検索クエリ**: +``` +"SRE 組織 最新" +"エラーバジェット 運用" +"observability best practices latest" +"chaos engineering adoption" +``` + +### 情報鮮度の確認 + +**最新情報の判定基準**: + +1. **公開日の確認** + - 過去1年以内: 最新情報として信頼度高 + - 過去2年以内: 比較的新しい、採用可 + - 3年以上前: 古い可能性あり、他の情報源と照合 + +2. **更新履歴の確認** + - 定期的に更新されているドキュメントか + - 最終更新日が最近か + +3. **バージョン情報の確認** + - ツール・フレームワークのバージョンが最新か + - EOL（サポート終了）が近くないか + +**信頼性の評価**: + +| ソース種別 | 信頼度 | 注意点 | +|------------|--------|--------| +| 公式ドキュメント | ⭐⭐⭐⭐⭐ | 最新バージョンを確認 | +| 大手企業の技術ブログ | ⭐⭐⭐⭐ | 企業規模と自社の差を考慮 | +| カンファレンス資料 | ⭐⭐⭐⭐ | 開催年を確認 | +| 個人ブログ | ⭐⭐⭐ | 複数ソースで裏取り | +| ニュース記事 | ⭐⭐ | 技術的詳細は別途確認 | + +--- + +## 調査結果の活用 + +### 調査結果のドキュメント化 + +調査結果を運用設計書の「業界トレンド分析」セクションに反映します。 + +**記載形式**: + +```markdown +## 3. 業界トレンド分析 + +### 3.1 業界の最新動向 + +**調査日**: [調査実施日] + +**主要トレンド**: + +1. **[トレンド1]** + - 概要: [説明] + - 本サービスへの影響: [影響分析] + - 対応方針: [対応内容] + - 参照: [URL] + +2. **[トレンド2]** + - 概要: [説明] + - 本サービスへの影響: [影響分析] + - 対応方針: [対応内容] + - 参照: [URL] + +### 3.2 採用フレームワーク・ベストプラクティス + +**採用フレームワーク**: + +- **ITIL 4**: [採用する実践項目] + - インシデント管理 + - 変更管理 + - ... + +- **SRE**: [採用する原則・プラクティス] + - SLO/SLIの設定 + - エラーバジェット + - ... + +- **DevOps**: [採用するプラクティス] + - CI/CD + - Infrastructure as Code + - ... + +**根拠**: [調査結果からの判断理由] + +### 3.3 競合分析 + +| 競合サービス | 運用品質の特徴 | 本サービスとの差別化 | 参照 | +|--------------|----------------|----------------------|------| +| [サービス名] | [特徴] | [差別化ポイント] | [URL] | +``` + +### 調査結果の運用設計への反映 + +調査結果を以下のセクションに反映します： + +1. **SLO/SLIの設定** + - 業界標準を参考に目標値を設定 + - 競合との比較で差別化ポイントを決定 + +2. **技術スタックの選定** + - 業界トレンドの技術を優先検討 + - 実績のある技術の採用 + +3. **セキュリティ・コンプライアンス** + - 業界固有の規制要件を反映 + - 必須対策の実施 + +4. **運用プロセス** + - ベストプラクティスを参考にプロセス設計 + - 業界標準との整合性確保 + +### ユーザーへの提案 + +調査結果を基に、ユーザーに推奨事項を提案します。 + +**提案フォーマット**: + +``` +[業界名]の最新トレンド調査結果に基づき、以下を提案します： + +【推奨する対応】 + +1. [トレンド/技術名]の採用 ⭐⭐⭐⭐⭐ + - 理由: [根拠] + - 効果: [期待される効果] + - リスク: [想定されるリスク] + - 実装難易度: [高/中/低] + +2. [トレンド/技術名]の採用 ⭐⭐⭐⭐ + - 理由: [根拠] + - 効果: [期待される効果] + - リスク: [想定されるリスク] + - 実装難易度: [高/中/低] + +【検討が必要な項目】 + +1. [トレンド/技術名] ⭐⭐⭐ + - 概要: [説明] + - メリット: [利点] + - デメリット: [欠点] + - 貴社の状況に照らして採用すべきか、ご意見をお聞かせください + +【採用を推奨しない項目】 + +1. [トレンド/技術名] ⭐ + - 理由: [不採用の理由] + +これらの提案について、ご意見をお聞かせください。 +``` + +### 継続的な調査 + +運用設計書作成後も、定期的に業界動向を調査します。 + +**調査頻度**: + +| 調査内容 | 頻度 | 目的 | +|----------|------|------| +| 業界トレンド | 四半期 | 新しいトレンドのキャッチアップ | +| セキュリティ脅威 | 月次 | 新しい脅威への対策 | +| 規制変更 | 随時 | コンプライアンス維持 | +| ツール・技術の更新 | 月次 | 技術スタックの最新化 | + +**調査結果の反映**: +- 運用設計書の更新 +- 改善計画への組み込み +- ステークホルダーへの共有 + +--- + +## まとめ + +業界調査は運用設計の成功に不可欠です。以下のポイントを押さえて調査を実施してください： + +1. **体系的な調査** + - 業界分類の特定 + - 網羅的な情報収集 + - 信頼性の高いソースの活用 + +2. **最新情報の重視** + - 直近の情報を優先 + - トレンドの把握 + - 技術の進化への対応 + +3. **実践的な活用** + - 調査結果の運用設計への反映 + - ユーザーへの明確な提案 + - 継続的な情報更新 + +4. **推論の排除** + - 事実に基づく分析 + - 情報源の明示 + - 不明点はユーザーに確認 + +この調査ガイドラインに従って、高品質な運用設計を実現してください。 diff --git a/skills/operations-design/references/operations_design_guide_ja.md b/skills/operations-design/references/operations_design_guide_ja.md new file mode 100644 index 0000000..2c22b9f --- /dev/null +++ b/skills/operations-design/references/operations_design_guide_ja.md @@ -0,0 +1,1536 @@ +# 運用設計ガイド + +このドキュメントは、運用設計を行う際の詳細なガイドラインとベストプラクティスをまとめています。 + +## 目次 + +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: 新規リソース作成を一時停止 +``` + +--- + +このガイドは運用設計の実践的な指針を提供しています。プロジェクトの特性に応じて、適切な部分を選択して活用してください。