変更失敗率とは?
変更失敗率は DORA の安定性メトリクスで、本番へのデプロイのうち、ロールバック、ホットフィックス、インシデントなどの是正を必要とする障害をもたらす割合です。
変更失敗率は、品質の問いを投げかけることで速度のメトリクスとバランスを取ります。リリースするすべての変更のうち、どれくらいがうまくいかないか、です。それを追跡することで、チームが速くリリースしているのか、それとも単に無謀にリリースしているだけなのかについて正直でいられます。
何が失敗とみなされるか
変更の失敗とは、サービスを劣化させ対応を必要とするデプロイです。ロールバック、ホットフィックス、パッチ、またはインシデントです。正確な定義よりも一貫して適用することが重要で、そうすればメトリクスは解釈で揺れるのではなく、時間とともに意味あるトレンドを描きます。
どのように計算されるか
変更失敗率は、失敗したデプロイの数を全デプロイ数で割り、パーセンテージで表したものです。カウントではなく率であるため、頻繁にデプロイするチームは単により多くリリースしたことでペナルティを受けません。うまくいかない割合が高いことに対してのみです。
なぜ速度とペアになるのか
それ単独では、頻繁または速くデプロイすることは単により速く物事を壊すことを意味しかねません。変更失敗率はその釣り合いを取るものです。スループットの向上が品質を犠牲にして得られていないことを保証します。エリートチームは絶えずデプロイしながらもこの率を低く保ちます。
それを下げる
より低い変更失敗率は、より小さな変更、強力な自動化テスト、良いコードレビュー、そして影響範囲を制限するプログレッシブデリバリの手法から生まれます。信頼できる CI も重要です。テスト結果がノイジーやフレーキーだと、本物のリグレッションがすり抜け、悪い変更が本番に到達します。
数値を解釈する
非常に低い変更失敗率は健全なことがありますが、ほぼゼロの率は過度な慎重さと遅いデリバリを示すこともあります。デプロイ頻度とリードタイムと並べて読み、一方をもう一方で買うのではなく、安定性と速度を達成していることを確認しましょう。
重要なポイント
- 変更失敗率は、是正を必要とする障害を引き起こすデプロイの割合です。
- 率であるため、単により頻繁にデプロイすることでチームにペナルティを与えません。
- より小さな変更、堅実なテスト、プログレッシブデリバリがそれを押し下げます。