senior-devops

シニア DevOps エンジニア

概要

本番環境のインフラストラクチャとデプロイパイプラインを設計、構築、保守します。このスキルでは、Docker によるコンテナ化、Kubernetes によるオーケストレーション、GitHub Actions による CI/CD、Terraform/Pulumi によるインフラストラクチャ・アズ・コード、Prometheus/Grafana による監視、アラート戦略、ダウンタイムゼロのデプロイ、ロールバック手順を扱います。

フェーズ 1：インフラストラクチャ設計

1. デプロイトポロジーを定義します（単一サーバー、クラスター、マルチリージョン）
2. コンテナ化戦略を選択します（Docker、Buildpacks）
3. オーケストレーションプラットフォームを選択します（Kubernetes、ECS、Cloud Run）
4. ネットワークを計画します（ロードバランサー、DNS、TLS）
5. シークレット管理の方法を設計します

停止 — 実装前に、インフラストラクチャ設計をユーザーに提示して承認を得てください。

インフラストラクチャの選択表

規模	トポロジー	オーケストレーション	推奨
趣味／MVP	単一サーバー	Docker Compose	Railway、Fly.io
スタートアップ（ユーザー数 < 100k）	小規模クラスター	ECS、Cloud Run	AWS ECS、GCP Cloud Run
成長期（ユーザー数 100k ～ 1M）	マルチ AZ クラスター	Kubernetes	EKS、GKE
エンタープライズ（ユーザー数 1M 以上）	マルチリージョン	Kubernetes + サービスメッシュ	EKS/GKE + Istio
コンプライアンス要件が厳しい環境	専用／プライベートクラウド	Kubernetes	セルフマネージド K8s

フェーズ 2：パイプラインの実装

1. CI パイプラインを構築します（lint、テスト、ビルド、セキュリティスキャン）
2. CD パイプラインを構築します（ステージング環境、本番環境へのデプロイ）
3. 環境ごとの設定を構成します
4. アーティファクトレジストリをセットアップします（コンテナーイメージ、パッケージ）
5. デプロイ戦略を実装します（ブルーグリーン、カナリア、ローリング）

停止 — パイプライン設定の構文を検証し、レビュー用に提示してください。

フェーズ 3：可観測性

1. 監視スタックをデプロイします（Prometheus、Grafana）
2. アラートルールとエスカレーションを構成します
3. ログ集約をセットアップします
4. 分散トレーシングを実装します
5. よくあるインシデントのランブックを作成します

停止 — 完了と宣言する前に、すべての重要なサービスが監視対象に含まれていることを確認してください。

Dockerfile のベストプラクティス

# 1. Use specific version tags (not :latest)
FROM node:20-alpine AS base

# 2. Set working directory
WORKDIR /app

# 3. Install dependencies in separate layer (cache optimization)
FROM base AS deps
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile --prod

FROM base AS build-deps
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile

# 4. Build in separate stage
FROM build-deps AS builder
COPY . .
RUN pnpm build

# 5. Production image — minimal size
FROM base AS runner
ENV NODE_ENV=production

# 6. Don't run as root
RUN addgroup --system --gid 1001 app && \
    adduser --system --uid 1001 app
USER app

# 7. Copy only what's needed
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist

# 8. Health check
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s \
  CMD wget -qO- http://localhost:3000/health || exit 1

# 9. Expose port and set entrypoint
EXPOSE 3000
CMD ["node", "dist/server.js"]

Dockerfile の主なルール

ルール	理由
マルチステージビルド	イメージサイズを最小限に抑える
.dockerignore ファイル	node_modules、.git、テストを除外する
非 root ユーザー	セキュリティを強化する
ベースイメージのバージョンを明示する	再現可能なビルドを実現する
レイヤーの順序（ソースより依存関係を先に配置）	キャッシュ効率を高める
HEALTHCHECK 命令	コンテナーの健全性を監視する
ビルド引数／レイヤーにシークレットを含めない	認証情報の漏えいを防ぐ

Docker Compose のパターン

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      target: runner
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgresql://postgres:postgres@db:5432/app
      - REDIS_URL=redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
      interval: 10s
      timeout: 5s
      retries: 3

  db:
    image: postgres:16-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5

  cache:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

GitHub Actions ワークフロー

name: CI/CD
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm typecheck
      - run: pnpm test -- --coverage

  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx audit-ci --moderate
      - uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          severity: HIGH,CRITICAL

  build-and-push:
    needs: [lint-and-test, security-scan]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Deploy to production
        run: echo "Deploying ${{ github.sha }}"

Terraform／Pulumi のパターン

Terraform の構成

modules/
  vpc/
    main.tf, variables.tf, outputs.tf
  ecs/
    main.tf, variables.tf, outputs.tf
environments/
  staging/
    main.tf, terraform.tfvars
  production/
    main.tf, terraform.tfvars

IaC の主なルール

ルール	理由
リモートステートバックエンド（S3 + DynamoDB）	状態を共有し、ロックする
ステートのロック	同時変更を防ぐ
環境ごとの変数ファイル	責務を分離する
モジュールのバージョン管理	共有インフラの再現性を確保する
CI で terraform plan を実行する	apply 前に問題を検出する
スケジュールに基づくドリフト検出	手動変更を検出する
すべてのリソースにタグを付ける	所有者の特定、コスト配分に役立つ

監視（Prometheus + Grafana）

USE メソッド（リソース）

リソース	使用率	飽和度	エラー
CPU	cpu_usage_percent	cpu_throttled	—
メモリ	memory_usage_bytes	oom_kills	—
ディスク	disk_usage_percent	io_wait	disk_errors
ネットワーク	bytes_total	queue_length	errors_total

RED メソッド（サービス）

• レート：1 秒あたりのリクエスト数
• エラー：1 秒あたりのエラー率
• 所要時間：レイテンシーの分布（p50、p95、p99）

アラートルール

groups:
  - name: app-alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
      - alert: HighLatency
        expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1
        for: 5m
        labels:
          severity: warning

アラートのベストプラクティス

プラクティス	理由
原因ではなく症状に対してアラートを出す	ノイズを減らし、影響に焦点を当てる
すべてのアラートにランブックへのリンクを付ける	迅速な対応を可能にする
重要度を段階分けする	critical=ページ通知、warning=チケット、info=ログ
アラートを出す前に集約する	頻繁な状態変動を避ける
四半期ごとに見直して整理する	アラート疲れを防ぐ

ゼロダウンタイムデプロイ戦略

戦略	仕組み	リスク	ロールバック速度
ローリング	インスタンスを一度に1つずつ置き換えます	低	中
ブルーグリーン	2つの環境間でトラフィックを切り替えます	低	即時
カナリア	少量のトラフィックを新バージョンにルーティングし、段階的に増やします	非常に低	即時
フィーチャーフラグ	コードを無効な状態でデプロイし、フラグで有効にします	非常に低	即時

ロールバック手順

1. 自動：ヘルスチェックに失敗すると、自動でロールバックします
2. 手動：kubectl rollout undo deployment/app
3. データベース：後方互換性を備えた、一方向のマイグレーション
4. 設定：シークレットマネージャーのバージョンを使って元に戻します

データベースマイグレーションの安全性

ルール	理由
マイグレーションは後方互換性を備えている必要があります	古いコードと新しいスキーマが共に動作する必要があります
同じデプロイで列の名前変更や削除をしないでください	2段階の変更が必要です
2段階で実施します：列を追加 -> デプロイ -> 古い列を削除	ゼロダウンタイムでスキーマを進化させます
各マイグレーションのロールバックを必ずテストしてください	元に戻せることを確認します

アンチパターン／よくある間違い

アンチパターン	問題点	代わりに行うこと
本番環境への手動デプロイ	監査証跡がなく、エラーが発生しやすい	CI/CD で自動化します
シークレットの共有やハードコード	セキュリティ侵害のリスクがあります	シークレットマネージャーを使用します
デプロイ前にロールバック計画を立てない	デプロイに失敗すると行き詰まります	デプロイの前に必ずロールバック手順を文書化します
本番イメージに latest タグを使用する	再現性がありません	特定のバージョンタグを固定します
コンテナを root として実行する	セキュリティ上の脆弱性があります	Dockerfile で root 以外のユーザーを使用します
対応可能なアクションがないアラートによるアラート疲れ	実際の問題を見逃してしまいます	症状をアラートし、しきい値を調整します
ステージング環境を省略する	本番環境でバグが見つかります	必ず最初にステージングへデプロイします
手動設定のスノーフレークサーバー	再現も拡張もできません	Infrastructure as Code を使用します
アラートなしのモニタリング	誰も問題に気づきません	アラートをモニタリングに接続します

主な原則

• Infrastructure as Code — 本番環境に手動で変更を加えません
• イミュータブルインフラストラクチャ — パッチを適用せず、置き換えます
• ペットではなく家畜 — サーバーは使い捨て可能です
• セキュリティのシフトレフト — パイプラインの早い段階でスキャンします
• 最小権限 — あらゆる場所で権限を最小限にします
• 2回を超えて実行するものはすべて自動化します
• 災害復旧計画を定期的にテストします

ドキュメントの検索（Context7）

最新のドキュメントを参照するには、mcp__context7__resolve-library-id の後に mcp__context7__query-docs を使用します。返されたドキュメントは、記憶している知識より優先されます。

• docker — Dockerfile の構文、compose の設定、またはマルチステージビルドについて
• kubernetes — リソースマニフェスト、kubectl コマンド、または Helm チャートについて
• terraform — プロバイダーの設定、リソースブロック、または状態管理について

---

統合ポイント

スキル	統合
deployment	より高水準のデプロイパイプラインオーケストレーションを提供します
security-review	CI パイプラインのセキュリティスキャン段階
planning	インフラストラクチャの変更を機能と同様に計画します
verification-before-completion	デプロイ後の検証ゲート
finishing-a-development-branch	マージによってデプロイパイプラインが起動します
mcp-builder	MCP サーバーにはコンテナ化とデプロイが必要です

スキルの種類

FLEXIBLE — プロジェクトのクラウドプロバイダー、チームの規模、運用の成熟度に合わせて、ツールとパターンを適応させます。原則（IaC、不変性、可観測性）は変わりませんが、具体的なツールは置き換え可能です。