プラットフォームの測定: メトリクスが重要な理由
社内開発者プラットフォームを必要としない メトリクス ダッシュボードのない車と同じです: 運転することはできますが、どのくらいの速度で走っているのか、燃料はどのくらいあるのか、エンジンがかかっているのかはわかりません。 過熱。プラットフォームが価値を生み出しているかどうかを理解するには指標が不可欠です。 ボトルネックを特定し、投資決定を導きます。
この記事では、パフォーマンスを測定するための 2 つの最も信頼できるフレームワークについて説明します。 ソフトウェアの配信と開発者のエクスペリエンス: DORA メトリクス e スペースフレームワーク。 具体的なダッシュボードを実装する方法と、継続的な改善のためにデータを使用する方法を見ていきます。
何を学ぶか
- DORA の 4 つの指標: 導入頻度、リードタイム、MTTR、変更失敗率
- SPACE フレームワーク: 満足度、パフォーマンス、アクティビティ、コミュニケーション、効率
- GitHub、GitLab、Kubernetes、CI/CD からデータを収集する方法
- ベンチマーク: エリート、高、中、低パフォーマーとの比較
- DORA メトリクス用の Grafana ダッシュボードの実用的な実装
- 避けるべき落とし穴: 虚栄心の指標、ゲーム、相関関係と因果関係
4 つの DORA メトリクス
Le DORA メトリクス (DevOps の調査と評価) は長年にわたる研究の結果です。 Nicole Forsgren、Jez Humble、Gene Kim によって行われた研究は、書籍「Accelerate」に記録されています。 次の 4 つの指標は、ソフトウェア配信パフォーマンスの最良の指標として認識されています。
- 導入頻度 (DF): 組織が運用環境にデプロイする頻度。エリート パフォーマーが 1 日に複数回、オンデマンドでデプロイします
- 変更のリードタイム (LT): 最初のコードのコミットから運用環境へのデプロイメントまでの時間。エリートパフォーマーのリードタイムは 1 時間未満
- 平均回復時間 (MTTR): インシデント後にサービスを復元するまでの平均時間。エリートパフォーマーは 1 時間以内に回復します
- 故障率 (CFR) の変更: 運用環境で障害を引き起こすデプロイメントの割合。エリートパフォーマーの CFR は 0 ～ 15% です
# DORA Metrics: benchmarking table
dora-benchmarks:
deployment-frequency:
elite: "On-demand (multiple deploys/day)"
high: "Between once per day and once per week"
medium: "Between once per week and once per month"
low: "Between once per month and once every 6 months"
lead-time-for-changes:
elite: "Less than one hour"
high: "Between one day and one week"
medium: "Between one week and one month"
low: "Between one month and six months"
mean-time-to-recovery:
elite: "Less than one hour"
high: "Less than one day"
medium: "Between one day and one week"
low: "More than six months"
change-failure-rate:
elite: "0-15%"
high: "16-30%"
medium: "16-30%"
low: "16-30%"
# Target per la nostra piattaforma
platform-targets:
current-state:
deployment-frequency: "weekly"
lead-time: "3 days"
mttr: "4 hours"
change-failure-rate: "22%"
6-month-target:
deployment-frequency: "daily"
lead-time: "4 hours"
mttr: "1 hour"
change-failure-rate: "10%"
スペースフレームワーク
DORA メトリクスは配信パフォーマンスに焦点を当てていますが、フレームワークは 空間 開発者エクスペリエンスのより広い視野を提供します。投稿者 Nicole Forsgren、マーガレット アン ストーリー と他の研究者によると、SPACE は次の 5 つの次元を測定します。
- 満足と幸福: 開発者が自分の仕事と利用可能なツールにどの程度満足しているか
- パフォーマンス: 開発者の作業の成果と影響 (コードの品質、サービスの信頼性)
- 活動内容: エンゲージメントの指標としてのアクティビティ (コミット、PR、レビュー、デプロイ) の量
- コミュニケーションとコラボレーション: チーム内およびチーム間のコミュニケーションとコラボレーションの質
- 効率と流れ: 開発者が中断やフリーズをせずに作業できる能力
SPACE の重要な側面は次のとおりです。 単一の指標はありません 完全なストーリーを語ります。 正確に理解するには、5 つの次元のうち少なくとも 3 つの指標を組み合わせる必要があります。 開発者のエクスペリエンス。
バニティメトリクスには注意してください
書かれたコードの行数、コミット数または作業時間を測定します。 バニティメトリクス それは実際の生産性については何も語っていません。さらに悪いことに、 悪い行為を奨励する可能性があります (冗長なコード、人為的なアトミックコミット、 プレゼンスと生産性の比較)。アウトプットではなく、アウトカムを測定する指標に焦点を当てます。
データの収集と計測
DORA および SPACE メトリクスを収集するには、複数のデータ ソースとの統合が必要です。
- Git (GitHub/GitLab API): コミットのタイムスタンプ、PR の作成/マージ時間、ブランチのライフサイクル
- CI/CD (GitHub アクション、GitLab CI): パイプラインの期間、成功/失敗率、デプロイメントのタイムスタンプ
- Kubernetes API: デプロイメントのロールアウトステータス、ポッドの再起動、リソース使用率
- インシデント管理 (PagerDuty、OpsGenie): インシデントの作成、確認、解決時間
- 調査ツール：開発者満足度調査（四半期ごとのNPS、パルス調査）
# Prometheus: regole per calcolo DORA metrics
groups:
- name: dora-metrics
interval: 5m
rules:
# Deployment Frequency: deployment al giorno per servizio
- record: dora:deployment_frequency:daily
expr: |
sum by (service) (
increase(
deployment_total{environment="production"}[24h]
)
)
# Lead Time: tempo medio dal commit al deploy (in ore)
- record: dora:lead_time_hours:avg
expr: |
avg by (service) (
deployment_lead_time_seconds{environment="production"}
) / 3600
# Change Failure Rate: % deployment falliti
- record: dora:change_failure_rate:ratio
expr: |
sum by (service) (
increase(
deployment_total{environment="production",status="failed"}[30d]
)
)
/
sum by (service) (
increase(
deployment_total{environment="production"}[30d]
)
)
# MTTR: tempo medio di recovery (in minuti)
- record: dora:mttr_minutes:avg
expr: |
avg by (service) (
incident_resolution_time_seconds{severity=~"critical|high"}
) / 60
# Alert se MTTR supera il target
- alert: HighMTTR
expr: dora:mttr_minutes:avg > 60
for: 5m
labels:
severity: warning
annotations:
summary: "MTTR per {{ $labels.service }} supera 60 minuti"
DORA 用 Grafana ダッシュボード
Una グラファナダッシュボード DORA メトリクス専用でリアルタイムの可視性を提供 ソフトウェア配信のパフォーマンスについて。主な見解は次のとおりです。
- 導入頻度: トレンドライン付きの日次/週次棒グラフ
- リードタイム: パーセンタイル (p50、p90、p99) と目標を示す折れ線グラフ
- MTTR: 目標を基準とした現在値を示すゲージ、履歴付き
- 故障率の変更: パーセンテージと月ごとの傾向を示す円グラフ
- DORA 総合スコア: パフォーマンスレベルを示す信号機 (エリート、高、中、低)
ダッシュボードは、プラットフォーム チームだけでなく、すべてのチームがアクセスできる必要があります。透明性 指標に関しては、改善を奨励し、データ主導の文化を生み出します。
フィードバック ループ: 指標から改善まで
指標は、それが結果を導く場合にのみ価値があります。 具体的な行動。フィードバックループ プラットフォームの継続的な改善には以下が含まれます。
- 集める: 定量的指標と定性的フィードバックの自動収集
- 分析する: 傾向、異常、相関関係の特定
- 優先順位を付ける: 影響と労力に基づいて改善をランク付けします
- 埋め込む：優先的に改善を実行する
- 測定: 改善によって望ましい効果が得られることを確認します
# Feedback loop: processo trimestrale di review
quarterly-platform-review:
week-1-collect:
- pull DORA metrics from Prometheus/Grafana
- run developer satisfaction survey (NPS + open questions)
- collect support ticket analytics
- review incident postmortems
week-2-analyze:
- compare metrics with previous quarter
- identify top 5 developer pain points from survey
- correlate support tickets with platform areas
- benchmark against industry standards
week-3-prioritize:
- impact-effort matrix for improvement initiatives
- align with business priorities
- estimate ROI for top initiatives
- present to engineering leadership
week-4-plan:
- create platform roadmap for next quarter
- define OKRs for platform team
- communicate plan to all engineering teams
- set metric targets for next quarter
避けるべき罠
メトリクスは強力なツールですが、誤って使用すると有害になる可能性もあります。
- ゲーム: 個人のパフォーマンスを評価するために指標が使用される場合、人々は指標を操作します。 DORA メトリクスは人ではなくシステムを測定する必要があります
- 相関関係と因果関係: 2 つの指標が一緒に動くからといって、一方がもう一方を引き起こすとは限りません
- 過剰測定: あまりにも多くのメトリクスを追跡すると、ノイズと混乱が生じます。 50 の無視された指標よりも、よく理解されている 5 つの指標の方が優れています
- メトリックの固定: 他のすべてを犠牲にして単一の指標を最適化する (例: 品質を気にせずにデプロイメント頻度を増やす)
基本原則
メトリクスは次のことを行う必要があります 啓発する、判断しないでください。プラットフォームがどこにあるかを理解するために使用してください 個々の開発者の生産性を評価するものではありません。文化に基づいた 信頼性と透明性、そしてメトリクスから価値を導き出すための前提条件について。