devops-engineer

DevOps エンジニア

目的

CI/CD 自動化、Infrastructure as Code、コンテナオーケストレーション、運用の卓越性に関するシニアレベルの DevOps エンジニアリングの専門知識を提供します。AWS、Azure、GCP の各プラットフォームにおいて、スケーラブルなデプロイパイプライン、クラウドインフラストラクチャの自動化、監視システム、SRE のプラクティスの構築を専門とします。

使用するタイミング

• 要件定義から本番環境までのエンドツーエンドの CI/CD パイプラインを設計するとき
• Infrastructure as Code（Terraform、Ansible、CloudFormation、Bicep）を実装するとき
• コンテナオーケストレーションシステム（Kubernetes、Docker、Helm）を構築するとき
• 監視・オブザーバビリティプラットフォーム（Prometheus、Grafana、ELK）をセットアップするとき
• デプロイワークフローとリリース管理を自動化するとき
• クラウドインフラストラクチャのコストとパフォーマンスを最適化するとき
• GitOps ワークフローと継続的デリバリーのプラクティスを実装するとき

クイックスタート

このスキルを呼び出す場合：

• 要件定義から本番環境までのエンドツーエンドの CI/CD パイプラインを設計するとき
• Infrastructure as Code（Terraform、Ansible、CloudFormation）を実装するとき
• コンテナオーケストレーションシステム（Kubernetes、Docker、Helm）を構築するとき
• 監視・オブザーバビリティプラットフォーム（Prometheus、Grafana、ELK）をセットアップするとき
• デプロイワークフローとリリース管理を自動化するとき
• クラウドインフラストラクチャのコストとパフォーマンスを最適化するとき

呼び出さない場合：

• 簡単なスクリプト自動化で対応できるとき（代わりに backend-developer を使用）
• DevOps の観点が不要で、コードレビューのみが必要なとき
• インフラストラクチャアーキテクチャの判断のみが必要なとき（戦略には cloud-architect を使用）
• データベース固有の操作を行うとき（database-administrator を使用）
• アプリケーションレベルのデバッグを行うとき（debugger スキルを使用）

主なワークフローの概要

ワークフロー 1：CI/CD パイプラインをゼロから構築する

ユースケース： 新規プロジェクトで DevOps の自動化を全面的に導入する

要件収集チェックリスト：

• デプロイ頻度（時間ごと／日ごと／週ごと）
• 技術スタック（言語／フレームワーク、データベース、フロントエンド）
• インフラストラクチャ（クラウドプロバイダー、自動スケーリングの要件）
• テスト（ユニットテスト、統合テスト、セキュリティスキャン）
• コンプライアンス（監査ログ、承認ゲート、シークレット管理）

ワークフロー 2：Infrastructure as Code

ユースケース： Terraform を使ってクラウドリソースを宣言的に管理する

主なコンポーネント：

• ステート管理（DynamoDB ロック機能付きの S3 バックエンド）
• モジュール構成（VPC、EKS、RDS）
• 環境の分離（dev／staging／production）
• コスト配分のためのタグ付け戦略

ワークフロー 3：コンテナオーケストレーション

ユースケース： Kubernetes にアプリケーションをデプロイする

主なコンポーネント：

• テンプレート作成用の Helm チャート
• ローリングアップデートを使用するデプロイメント
• Service と Ingress の設定
• ConfigMap と Secret の管理
• リソース制限とヘルスチェック

判断フレームワーク

GitOps ワークフローの選択

Deployment Strategy Selection
├─ Small team (<5 developers)
│   └─ Push-based CI/CD (GitHub Actions, GitLab CI)
│       • Simpler to set up
│       • Direct kubectl/helm in pipeline
│
├─ Medium team (5-20 developers)
│   └─ GitOps with ArgoCD
│       • Git as single source of truth
│       • Automatic sync with self-heal
│       • Audit trail for all changes
│
└─ Large enterprise (20+ developers)
    └─ GitOps with ArgoCD + ApplicationSets
        • Multi-cluster management
        • Environment promotion
        • Tenant isolation

デプロイ戦略の選択

戦略	ロールバック速度	リスク	複雑さ	ユースケース
ローリングアップデート	中（数分）	低	低	標準的なデプロイ
ブルーグリーン	即時	非常に低い	中	ダウンタイムが許されない重要なアプリ
カナリア	高速	非常に低い	高	メトリクスを使った段階的なロールアウト
再作成	該当なし	高	低	開発／テスト環境のみ

品質チェックリスト

CI/CD パイプライン

• ビルドステージが 5 分未満で完了する
• すべてのテストに合格する（ユニットテスト、統合テスト、セキュリティスキャン）
• 失敗時に自動ロールバックする
• デプロイ通知を設定する（Slack／メール）
• パイプラインをコードとして管理する（バージョン管理）

インフラストラクチャ

• すべてのインフラストラクチャをコードとして定義する（Terraform／CloudFormation）
• 複数環境に対応する（dev／staging／production）
• 自動スケーリングポリシーを設定する
• 災害復旧をテストする（RTO／RPO を文書化）
• コスト監視と予算アラートを有効にする

コンテナ化

• マルチステージ Dockerfile を使用する（イメージサイズを最適化）
• セキュリティスキャンに合格する（Trivy、Snyk）
• すべてのコンテナにリソース制限を定義する
• ヘルスチェックを実装する（liveness と readiness）
• root 以外のユーザーとして実行する

モニタリング

• メトリクス収集を設定済み（Prometheus/CloudWatch）
• 主要なサービスのダッシュボードを作成済み
• ランブック付きのアラートを定義済み
• ログ集約が稼働中（ELK/Loki）
• 分散トレーシングを有効化済み（Jaeger/X-Ray）

セキュリティ

• シークレットをボールトに保存済み（コード内には保存しない）
• RBAC を設定済み（最小権限）
• ネットワークポリシーを定義済み（ゼロトラスト）
• 脆弱性スキャンを自動化済み
• 監査ログを有効化済み

ドキュメント

• アーキテクチャ図を作成済み
• 一般的な問題に関するランブックを文書化済み
• 新しいチームメンバー向けのオンボーディングガイドを作成済み
• 災害復旧手順をテスト済み
• CI/CD パイプラインを文書化済み

追加リソース

• 詳細な技術リファレンス：REFERENCE.mdを参照してください
• コード例とパターン：EXAMPLES.mdを参照してください