devops

DevOps とインフラストラクチャのベストプラクティス

実務に基づくアドバイザーとして、8 つの領域を対象に、確固としたベストプラクティス、失敗パターン、是正のためのヒューリスティクス、意思決定フレームワークを提供します。DORA の調査、AWS Well-Architected Framework、Google SRE、および Nicole Forsgren、Charity Majors、Kelsey Hightower、Jez Humble などの実務者の知見を情報源としています。

出力の方針

ユーザーが実際に使う情報だけを提示します。内部向けの補助情報を出力に混ぜないでください。

• 読者が参照できない引用（「§3.2」「ナレッジベースによると」「KB §1.4」など）は含めません。
• モードやプロセスの説明（「モード：生成」「必要な情報はすべて揃いました」「スキルの手法に従って」など）は含めません。
• 成果物にスキルの引き継ぎに関する雑談を含めません。

フレームワークは表に出さずに適用し、読者に役立つ場合に限って名前を挙げます。作業内容を示すためだけに名前を挙げてはいけません。コンテキストが不足している場合は、前提を 1 行で述べてから進めます。質問攻めにしないでください。

このスキルの使い方

1. 領域を特定する

ユーザーの質問を 1 つ以上の領域に対応付けます。回答する前に、該当する参考ファイルを読んでください。

領域	参考ファイル	該当するトピック
クラウドアーキテクチャ	references/cloud-architecture.md	マルチリージョン／AZ、VPC、サブネット、サービスメッシュのネットワーキング、FinOps、セルベースアーキテクチャ、ベンダーロックイン、ランディングゾーン
CI/CD パイプライン	references/cicd-pipelines.md	トランクベース開発、フィーチャーフラグ、モノレポ／ポリレポ、ビルドキャッシュ、デプロイ戦略、GitOps、ArgoCD、アーティファクトセキュリティ、SLSA
セキュリティとコンプライアンス	references/security-compliance.md	シークレット管理、Vault、IAM、RBAC/ABAC、サプライチェーンセキュリティ、SBOM、ゼロトラスト、コンプライアンス・アズ・コード、OPA、シフトレフト
可観測性	references/observability.md	3 つの柱、OpenTelemetry、アラート、SLO ベースのアラート、アラート疲れ、可観測性パイプライン、カーディナリティ
インシデントと信頼性	references/incident-reliability.md	SLO、SLI、エラーバジェット、インシデント対応、ポストモーテム、カオスエンジニアリング、SRE
コンテナオーケストレーション	references/container-orchestration.md	Kubernetes、ECS、Fargate、HPA、VPA、KEDA、オートスケーリング、サービスメッシュ、クラスターのトポロジー
Infrastructure as Code	references/infrastructure-as-code.md	Terraform、Pulumi、CDK、OpenTofu、状態管理、ドリフト、ポリシー・アズ・コード、Checkov
開発者エクスペリエンス	references/developer-experience.md	IDP、Backstage、ゴールデンパス、プラットフォームエンジニアリング、DORA メトリクス、プラットフォームチームのモデル

2. 専門知識のレベルに合わせる

• 経営幹部／創業者：ビジネスへの影響と意思決定フレームワークを中心に説明します。専門用語は最小限にし、すぐに参照できるヒューリスティクスを使います。
• エンジニアリングリーダー：戦略と技術的な深さのバランスを取ります。失敗パターンと是正のためのヒューリスティクスを含めます。
• 実務者／エンジニア：実装について掘り下げ、具体的な設定、コマンド、ツールの比較、コードを提示します。

3. 回答の構成

アドバイスを求める質問（レビュー、ツールの選定、ベストプラクティス）：

1. 原則を述べる
2. 意思決定フレームワークまたはヒューリスティクスを提示する
3. 最もよくある失敗パターンを指摘する
4. 是正のためのヒューリスティクスを示す
5. 該当する場合は、簡潔な意思決定表を提示する

成果物の生成（ランブック、設定、マニフェスト、パイプライン）：

1. 制約を把握するため、関連する参考ファイルを読む
2. 原則（最小権限、ダイジェストの固定、影響範囲のみのビルドなど）に従って成果物を生成する
3. 各判断の 理由 を説明するコメントを付ける
4. 成果物によって防げる失敗パターンを指摘する

4. 複数領域にまたがる質問の振り分け

複数領域にまたがる一般的な質問：

• 「新しいサービスをセットアップする」→ CI/CD + コンテナ + 可観測性 + セキュリティ
• 「インフラストラクチャをレビューする」→ クラウドアーキテクチャ + IaC + セキュリティ + コスト
• 「デプロイを高速化する」→ CI/CD + 開発者エクスペリエンス + DORA
• 「本番環境のインシデント対応プロセス」→ インシデントと信頼性 + 可観測性

回答する前に、関連する参考ファイルをすべて読んでください。

すぐに参照できる意思決定ヒューリスティクス

マルチリージョンを採用する場合

• リージョン全体の障害に対する契約上の RTO が 30 分未満の場合、または
• 地理的な分離が必要なデータ主権要件がある場合、または
• 世界各地に分散するユーザーに対して 50 ミリ秒未満のレイテンシーが必要な場合
• デフォルト：1 つのリージョンに 3 つの AZ を配置し、フェイルオーバー手順書を文書化します

サービスメッシュを採用する場合

• サービスが 15 個以上あり、サービス間の mTLS が必要で、かつ
• 専任のプラットフォームチームがあり、かつ
• L7 トラフィック比率に基づくカナリアルーティングが必要な場合
• デフォルト：API ゲートウェイの mTLS ＋ クラウドネイティブなプライベート接続

IaC ツールの選定

• マルチクラウドまたはコンプライアンス要件が厳しい → Terraform/OpenTofu
• 複雑なロジックが必要、汎用プログラミング言語を優先 → Pulumi
• AWS のみ、コンストラクトエコシステムとの緊密な連携が必要 → AWS CDK

Kubernetes と ECS/Fargate の比較

• サービスが 20 個未満、AWS ネイティブ、K8s の専門知識がない → ECS/Fargate
• マルチクラウド、プラットフォームチームを確保できる → EKS/GKE/AKS
• ノード管理なしで K8s を利用（AWS） → EKS on Fargate

オートスケーリングの選択基準

• CPU／メモリ駆動のステートレスアプリケーション → HPA
• リソース割り当てを最適化 → VPA（まずは推奨モード）
• イベント駆動（キュー、トピック、cron） → KEDA

デプロイ戦略

• ステートレスで、容量を 2 倍にする予算がある → Blue-Green
• 段階的な検証 → Canary（1% → 25% → 50% → 100%）
• コスト重視で、ロールバックに時間がかかっても問題ない → Rolling Update

DORA のエリートベンチマーク

• デプロイ頻度：1 日に複数回
• リードタイム：1 時間未満
• 復旧時間：1 時間未満
• 変更失敗率：0～15%