mcpField
P
platform-engineer

platform-engineer

github.com/404kidwizクラウド・DevOps106 回インストール
リポジトリ

platform-engineer について

プラットフォームエンジニア向けに、内部開発者プラットフォーム、開発者体験、セルフサービス型インフラの設計を支援するスキルです。Backstageのサービスカタログ、Golden Pathテンプレート、Crossplaneによるリソース抽象化、GitOpsを扱います。

主な機能

  1. 01内部開発者プラットフォームの設計
  2. 02Backstageのカタログとポータル構築
  3. 03Golden Pathテンプレートの作成
  4. 04Crossplaneによるクラウドリソースの抽象化
  5. 05GitOpsと一時環境の導入
  6. 06DORAとDevEx指標の測定

活用シーン

  1. 01内部開発者プラットフォームの新規計画
  2. 02マイクロサービス用の標準テンプレート作成
  3. 03Crossplaneによるクラウドリソースのセルフサービス化
  4. 04開発者のオンボーディングと体験の改善

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/404kidwiz/claude-supercode-skills --skill platform-engineer

インストール後、Claude Code で/platform-engineerを入力して読み込まれたか確認します。

詳細

プラットフォームエンジニア

目的

開発者エクスペリエンスの最適化、セルフサービス型インフラストラクチャ、Golden Path テンプレートを専門とする、Internal Developer Platform(IDP)の知識を提供します。Backstage、Crossplane、GitOps を活用し、開発者の認知負荷を軽減するプラットフォームを構築します。

使用する場面

  • Internal Developer Platform(IDP)をゼロから構築するとき
  • Service Catalog または Developer Portal(Backstage)を導入するとき
  • マイクロサービス(Spring Boot、Node.js、Go)向けの「Golden Path」テンプレートを作成するとき
  • クラウドリソース(RDS、S3)をカスタムプラットフォーム API(Crossplane)として抽象化するとき
  • セルフサービス型の一時環境を設計するとき
  • DORA メトリクスと Developer Experience(DevEx)KPI を測定するとき

例

例 1:Backstage による Developer Portal の構築

シナリオ: 中規模のテクノロジー企業が、開発者のオンボーディング期間を 2 週間から 2 日に短縮したいと考えています。

実装:

  1. 標準的な統合機能を備えた Backstage をデプロイ
  2. 一般的なサービス種別(Go、Node.js、Python)向けのソフトウェアテンプレートを作成
  3. 自動プロビジョニングのために CI/CD(GitHub Actions)と統合
  4. 所有者情報とドキュメントを含むサービスカタログを構築
  5. ドキュメントを一元管理するために TechDocs を導入

結果:

  • 新しいサービスの作成期間を 2 週間から 4 時間に短縮
  • 開発者の満足度が 45% 向上
  • ドキュメントのカバー率が 60% から 95% に改善
  • デプロイ頻度が 3 倍に増加
例 2:マイクロサービス向け Golden Path テンプレート

シナリオ: マイクロサービスプラットフォームで、新しいサービスの本番環境へのデプロイまでの時間を短縮する必要があります。

実装:

  1. ベストプラクティスを組み込んだ標準サービステンプレートを作成
  2. テンプレートに自動セキュリティスキャンを導入
  3. オブザーバビリティ(メトリクス、ログ、トレース)をデフォルトで追加
  4. セキュリティゲートを備えた CI/CD パイプラインを構成
  5. わかりやすいドキュメントと例を提供

結果:

  • 新しいサービスの 80% が Golden Path を使用
  • 最初の本番デプロイまでの時間を 2 週間から 2 日に短縮
  • セキュリティコンプライアンスを自動化(手動レビューが不要)
  • 開発者の生産性スコアが 35% 向上
例 3:Crossplane プラットフォーム API

シナリオ: 開発者が直接アクセスすることなく、クラウドリソースをプロビジョニングできるようにする必要があります。

実装:

  1. 一般的なインフラストラクチャパターン向けに Crossplane XRD を定義
  2. データベース、キュー、バケット向けの複合リソースを作成
  3. クォータと承認を含む RBAC を導入
  4. Backstage プラグインを使ってセルフサービスポータルを構築
  5. 既存のワークフローやツールと統合

結果:

  • 開発者は数日ではなく数分でリソースをプロビジョニング可能
  • クラウド支出の可視性が向上(開発者がコストへの影響を確認可能)
  • セキュリティ態勢が向上(クラウドコンソールへの直接アクセスなし)
  • インフラストラクチャ関連のチケットが 60% 減少

ベストプラクティス

プラットフォーム設計
  • 置き換えるのではなく、集約する:ネイティブツールを再構築せず、リンクします
  • Golden Cage ではなく Golden Path:価値を提供し、使用を義務付けません
  • 開発者エクスペリエンスを最優先:開発者を顧客として扱います
  • 反復的な改善:小さく始め、フィードバックに基づいて改善します
セルフサービス
  • 迅速なプロビジョニング:リソースのプロビジョニングを数分で完了します
  • わかりやすいドキュメント:自己文書化されたテンプレートとワークフローを用意します
  • 柔軟な例外対応:必要に応じて手動での上書きを可能にします
  • フィードバックループ:開発者からのフィードバックを収集し、それに基づいて対応します
ガバナンス
  • デフォルトでのセキュリティ:セキュリティを後付けではなく、テンプレートに組み込みます
  • コンプライアンスの自動化:コンプライアンスチェックを自動化します
  • コストの可視化:開発者にコストへの影響を提示します
  • 監査証跡:説明責任を果たせるよう、すべてのアクションを記録します
運用
  • 高可用性:プラットフォームには本番環境と同等の信頼性が必要です
  • モニタリング:プラットフォームの健全性と利用状況のメトリクスを監視します
  • インシデント対応:プラットフォームの問題に備えてランブックを用意します
  • 継続的な改善:プラットフォームの健全性を定期的にレビューします


主な機能

内部開発者プラットフォーム
  • セルフサービス型のインフラストラクチャプラットフォームを構築する
  • Backstage でサービスカタログを実装する
  • 開発者ポータルとドキュメントハブを作成する
  • プラットフォームのガバナンスとポリシーを管理する
ゴールデンパステンプレート
  • 標準化されたアプリケーションテンプレートを開発する
  • Infrastructure as Code モジュールを作成する
  • セキュリティとコンプライアンスの制御を実装する
  • サービスのオンボーディングを自動化する
GitOps とインフラストラクチャ
  • ArgoCD/Flux で GitOps ワークフローを実装する
  • Kubernetes クラスターとオペレーターを管理する
  • クラウドリソースの抽象化に向けて Crossplane を設定する
  • 一時的な環境を設定する
開発者エクスペリエンス
  • DORA メトリクスと DevEx KPI を測定する
  • 開発者の認知負荷を軽減する
  • 内部ツールと自動化を実装する
  • 開発者のオンボーディングとトレーニングを管理する


ワークフロー 2:インフラストラクチャの構成(Crossplane)

目標: 開発者が AWS の詳細を知らなくても、Kubernetes マニフェスト(YAML)を使って PostgreSQL DB をリクエストできるようにします。

手順:

  1. Composite Resource Definition(XRD)を定義する

    # postgres-xrd.yaml
    apiVersion: apiextensions.crossplane.io/v1
    kind: CompositeResourceDefinition
    metadata:
      name: xpostgresqlinstances.database.example.org
    spec:
      group: database.example.org
      names:
        kind: XPostgreSQLInstance
        plural: xpostgresqlinstances
      claimNames:
        kind: PostgreSQLInstance
        plural: postgresqlinstances
      versions:
        - name: v1alpha1
          served: true
          referenceable: true
          schema:
            openAPIV3Schema:
              type: object
              properties:
                spec:
                  properties:
                    storageGB:
                      type: integer
    
  2. Composition(AWS 実装)を定義する

    # aws-composition.yaml
    apiVersion: apiextensions.crossplane.io/v1
    kind: Composition
    metadata:
      name: xpostgresqlinstances.aws.database.example.org
    spec:
      compositeTypeRef:
        apiVersion: database.example.org/v1alpha1
        kind: XPostgreSQLInstance
      resources:
        - base:
            apiVersion: rds.aws.crossplane.io/v1alpha1
            kind: DBInstance
            spec:
              forProvider:
                region: us-east-1
                dbInstanceClass: db.t3.micro
                masterUsername: masteruser
                allocatedStorage: 20
          patches:
            - fromFieldPath: "spec.storageGB"
              toFieldPath: "spec.forProvider.allocatedStorage"
    
  3. 開発者エクスペリエンス

    • 開発者が適用します:
      apiVersion: database.example.org/v1alpha1
      kind: PostgreSQLInstance
      metadata:
        name: my-db
        namespace: my-app
      spec:
        storageGB: 50
      
    • Crossplane が RDS インスタンスを自動的にプロビジョニングします。


4. パターンとテンプレート

パターン 1:「ゴールデンパス」リポジトリ

ユースケース: テンプレートを一元管理します。

/templates
  /spring-boot-microservice
    /src
    /Dockerfile
    /chart
    /catalog-info.yaml
    /mkdocs.yml
  /react-frontend
    /src
    /Dockerfile
    /nginx.conf
  /python-data-worker
    /src
    /requirements.txt
パターン 2:スコアカード(ゲーミフィケーション)

ユースケース: Backstage を通じてベストプラクティスの実践を促します。

  • ブロンズレベル:
    • catalog-info.yaml がある
    • README.md がある
    • CI ビルドが成功している
  • シルバーレベル:
    • コードカバレッジが 80% を超えている
    • Prometheus でアラートが定義されている
    • ランブックへのリンクがある
  • ゴールドレベル:
    • DORA メトリクスが追跡されている
    • セキュリティスキャンが成功している(重大度が高または緊急の問題が 0 件)
    • SLO が定義されている
パターン 3:TechDocs(ドキュメントをコードとして管理)

ユースケース: ドキュメントをコードの近くに保ちます。

# mkdocs.yml
site_name: My Service Docs
nav:
  - Home: index.md
  - API: api.md
  - Architecture: architecture.md
  - Runbook: runbook.md
plugins:
  - techdocs-core


6. 統合パターン

kubernetes-specialist:
  • 引き継ぎ:プラットフォームエンジニアが抽象的な PostgreSQL クレームを定義し、Kubernetes スペシャリストがオペレーター/ドライバーのロジックを実装します。
  • 協力:IDP の基盤となるクラスターのトポロジーを設計します。
  • ツール:Crossplane、ArgoCD。
security-engineer:
  • 引き継ぎ:プラットフォームエンジニアがテンプレートを作成し、セキュリティエンジニアがCIのスケルトンにSAST/SCAのステップを追加します。
  • 連携:Golden Pathsに「デフォルトでセキュア」な設定を用意します。
  • ツール:OPA Gatekeeper、Snyk。
sre-engineer:
  • 引き継ぎ:プラットフォームエンジニアが「アラートを作成」する機能を公開し、SREがデフォルトのアラートルールを定義します。
  • 連携:サービス向けのSLI/SLOテンプレートを定義します。
  • ツール:Prometheus、PagerDuty。
backend-developer:
  • 引き継ぎ:プラットフォームエンジニアが「サービスを作成」ボタンを提供し、バックエンド開発者がそれを使ってコードをリリースします。
  • 連携:テンプレートに関するフィードバックを収集します(「機能を詰め込みすぎていませんか?」)。
  • ツール:Backstage。

コメント