指標は定義ではなく計算で分かれる

一言でいうと

DORAの4つのメトリクスは、名前を知っているだけでは終わりません。同じデータでも、ウィンドウ(window)・分母・代表値をどう取るかによって、数字が何倍も変わるため、メトリクスは、定義とともに計算方法を、ドキュメントではなくコードで固定する必要があります。

なぜ必要なのか

2つのチームが同じデプロイ記録を見て、それぞれ「リードタイム40分」と「リードタイム4時間」を報告したことがあります。データは同じでした。一方は中央値を、もう一方は平均を使い、一方は成功したデプロイだけを数え、もう一方はすべてを数えました。こうなると、数字で対話できません。メトリクスが増えるほど会議が長くなる組織は、たいていここで行き詰まっています。

そのため、プラットフォームチームがメトリクスを導入するときに最初に決めるべきことは、どのメトリクスを見るかではなく、そのメトリクスをどう計算するかです。

どう動くのか

元帳から始めます

メトリクスは、ダッシュボードではなく元帳(ledger)から生まれます。デプロイ1件ごとに、サービス名、コミットがいつ作られ、いつデプロイされたか、成功か失敗か、失敗した場合は復旧までどれくらいかかったかを、1行として残します。この1枚があれば4つのメトリクスをすべて計算でき、なければ、どんなツールを買っても推定しかできません。

4つのメトリクスの計算で、実際に分かれるところ

メトリクス	よく間違えるポイント
デプロイ頻度	組織全体の合計だけを見ると、1つのサービスが頻繁にデプロイして、残りを隠してしまいます。サービスごとにも見ます
変更のリードタイム	平均は、時間のかかった1件に引きずられます。中央値を使います
変更失敗率	分母はデプロイ件数です。サービス数や障害件数ではありません
平均復旧時間	分母は失敗したデプロイ件数です。全デプロイで割ると、値が何分の1にも小さくなります

中央値には、もう1つ落とし穴があります。サービスごとの中央値の平均は、全体の中央値ではありません。デプロイ件数がサービスごとに違うため、2つの値はたいてい異なり、両方を混ぜて使うと、同じ元帳から互いに異なるレポートが出てきます。

レベルは、しきい値を先に書いてから判定します

DORAは、4つのメトリクスをElite・High・Medium・Lowに分けます。ここで重要なのは、しきい値そのものよりも、私たちの組織が使うしきい値を事前に書いておき、そのとおりに適用することです。判定するたびに基準を少しずつ調整すると、レベルには何の意味もなくなります。

そして、4つのメトリクスは一緒に読みます。速度のメトリクスは良いのに安定性のメトリクスが悪ければ、その組織は速いのではなく、検証を省略しているのです。逆に、安定性だけが良くてデプロイがまばらなら、リスクを避けるために改善が止まった状態かもしれません。

採用率は、分母と「アクティブ」の定義がすべてです

プラットフォームの採用率で争点になるのは、いつも2つです。分母を全サービスとするか、オンボーディングしたサービスとするか、そして何を「使っている」とみなすかです。オンボーディング完了を採用として数えると、数字はきれいですが、実際には誰も使っていない状態を隠します。直近の一定期間内に実際にデプロイしたサービスを数えるほうが正直で、その期間も一緒に書いておけば、あとで比較できます。

エラーバジェットは算数です

SLOが99.5%で、ウィンドウが28日なら、バジェットは次のように出ます。28日は40320分で、その0.5%である201.6分が、今回のウィンドウで許容される悪い時間です。ここから実際に消化した時間を引くと、残りのバジェットが出ます。この数字があって初めて、「今、新機能をさらに出すのか、安定化に使うのか」を、感情ではなく残量で話せます。

現場での姿

メトリクスをチーム間のランキング表として使い始めると、元帳が汚染されます。失敗を失敗として書かなくなり、デプロイの単位を細かく分割して件数を増やすようになります。数字は良くなるのに実際の状況は悪くなり、そのときからメトリクスは、現実を隠す装置になります。

そこで、プラットフォームチームはメトリクスを自分自身に向けます。準拠率の低いルールがあれば、そのチームを呼びつける代わりに、そのルールを守りやすくし、リードタイムが特に長いサービスがあれば、そのサービスのパイプラインで何が待っているのかを見ます。メトリクスの使い道は、ランキングではなく、次に何を直すかを決めることにあります。

メトリクスが人の行動を変える仕組み

プラットフォームのメトリクスを測り始めると、すぐにわかることがあります。測った瞬間に、その数字が目標になり、人々はその数字を良くする方向に動きます。そのため、何を測るかが、そのまま何が起きるかになります。

デプロイ頻度だけを測ると、意味のないデプロイが増えます。変更のない再デプロイや、細かく分割したコミットが数字を押し上げます。そのため、4つのメトリクスは一緒に見ます。デプロイ頻度が上がりながら変更失敗率が変わらなければ、実際に良くなったということで、1つだけ良くなったのなら、たいてい別の側を犠牲にしています。

変更失敗率の分母を決めないと、どんな値でも出てきます。「失敗」がロールバックなのか、障害なのか、インシデント等級以上なのかによって、値が何倍も変わります。定義を書いておき、変更するときは過去の値も一緒に再計算します。そうしないと、定義が変わった月のグラフが改善のように見えてしまいます。

復旧時間は、中央値と最悪値を一緒に見ます。ほとんどが10分で終わるのに、四半期に1回 8時間かかるなら、平均は何も教えてくれません。人々が覚えているのはその8時間です。

チーム間の比較には使いません。サービスの性格が違えば、数字も違います。決済システムと社内ツールを同じ表に置くと、決済チームはリスクを取らない方向に動きます。メトリクスは、同じチームの時間的な変化を見るために使います。

採用率は、「使っている」ではなく「これで仕事をしている」と定義します。アカウントを作った人数は何も語りません。過去30日以内に実際にデプロイを行ったチーム数のように、 行動を数える定義でなければ、プラットフォームが役に立っているかはわかりません。

エラーバジェットは交渉の道具です。バジェットが残っていれば、リスクの高い変更をしてもよく、使い切れば安定化に集中するという合意が事前にあって初めて、価値が生まれます。その合意なしに数字だけを測ると、 障害のあとにその数字を巡って争うための材料にしかなりません。

次のラボですること

28日分のデプロイ元帳を使って、4つのメトリクスを自分で計算します。中央値と平均の違い、失敗率と復旧時間の分母を手で確認し、事前に決めたしきい値でレベルを判定します。続いて、サービス名簿から採用率を、アクティブ利用の定義どおりに計算し、最後に、エラーバジェットの総量と消化率を求めます。