変更障害検出

ドキュメント > Delivery Performance > DORA Metrics > 変更障害検出

概要

Datadog の変更障害検出は、以前に失敗したデプロイを修復するデプロイを自動的に特定します。変更障害を修復デプロイに関連付けることで、デリバリーパフォーマンスの完全なビューを提供し、チームがリリースの速度と運用の安定性のバランスを取るのに役立ちます。

変更障害とは、本番環境で問題を引き起こし、復旧が必要となるデプロイのことです。変更障害は、次のメトリクスの計算に使用されます。

変更障害率 : 本番環境で問題を引き起こしたデプロイの割合で、次のように計算されます。

$$\text"変更障害率" = \text"変更障害数" / \text"総デプロイ数"$$

デプロイ失敗からの復旧時間 : デプロイ失敗からロールバックまたはロールフォワードデプロイによる修復までの時間の中央値です。

変更障害検出では、2 種類の修復デプロイを識別します。

ロールバック: 以前にデプロイされたバージョンが再デプロイされたときに自動的に検出されます。
ロールフォワード: メタデータのパターン (リバート PR やホットフィックスラベルなど) に一致するカスタムルールを通じて検出されます。

ロールバック

ロールバックは、失敗した変更や不具合のある変更の後にシステムを復旧させるため、以前にデプロイされたバージョンが再デプロイされたときに発生します。

ロールバックによる分類の仕組み

デプロイがロールバックとして分類されるのは、以前にデプロイされたバージョンと一致するものの、直前のデプロイとは異なるバージョンをデプロイした場合です。

Git メタデータが存在する場合、その照合はコミット SHA に基づきます。
Git メタデータが存在しない場合、その照合はバージョンタグに基づきます。

ロールバックが検出されると、ロールバックターゲット (元に戻したバージョン) の後の最初のデプロイが変更障害となります。

例: ロールバックの検出

V1 → V2 → V3 → V1 というシーケンスの場合、ロールバックターゲットは元の V1 であるため、V2 が変更障害としてマークされ、V1 がロールバックデプロイとしてマークされます。

注: 同じバージョンを連続して再デプロイすること (例: V1 → V1) は、ロールバックとはみなされません。

ロールフォワード

ロールフォワードは、失敗した変更や不具合のある変更を修正または上書きするために新しいデプロイが行われた場合に発生します。ロールバック (以前のバージョンの再デプロイ) とは異なり、ロールフォワードは問題を修復するために新しいコードをデプロイします。これには、新しいリリースを通じて以前の動作を復元するリバートプルリクエストが含まれる場合があります。

ロールフォワードは、デプロイメタデータのパターンに一致するカスタムルールを通じて検出されます。カスタムルールは、DORA 設定ページで構成されます。

カスタムルール

リポジトリやリリースのメタデータに基づいて、ロールフォワードデプロイを自動的に分類するカスタムルールを定義できます。ルールは次の 2 つの方法で機能します。

デプロイのリンク: 共有変数 (PR 番号やバージョンなど) の値を通じてデプロイを照合します。
静的パターン: 変数を使用せずにメタデータのパターン (ラベルやブランチ名など) を照合します。

失敗したデプロイにリンクされたルール

これらのルールを使用して、以前に失敗した特定のデプロイにリンクされるロールフォワードデプロイを特定します。これらのルールでは、共有参照を通じてデプロイを照合するために、変数を含む正規表現 (regex) パターンを使用します。

次の変数のいずれかを含む正規表現ルールを入力できます。

変数	説明
`$pr_title`	PR タイトルに一致
`$pr_number`	PR 番号に一致
`$version`	バージョンタグに一致

変数ベースの分類の仕組み

ルールがデプロイに一致すると、次のアクションが実行されます。

現在のデプロイから変数値が抽出されます。
同じ抽出値を持つ以前のデプロイが検索されます。
現在のデプロイが、その以前のデプロイにリンクされたロールフォワードとしてマークされます。
以前のデプロイが変更障害としてマークされます。

これらのルールは、失敗したデプロイが共有コミット SHA、バージョンタグ、または PR 参照によって識別できる場合に最も効果的です。

例: リバートプルリクエスト

リバートプルリクエストは、一般的な復旧パターンです。たとえば、Revert "Add feature X" というタイトルの PR は元の PR を参照しています。

Revert "$pr_title"

PR タイトルがこのパターンに一致すると、次のアクションが実行されます。

リバート PR から元の PR タイトル ($pr_title の値) が抽出されます。
元の PR タイトルを含む以前のデプロイが検索されます。
現在のデプロイ (リバートを含む) がロールフォワードとしてマークされます。
以前のデプロイが変更障害としてマークされます。

注: 元の PR が以前のいずれのデプロイにも見つからない場合、または元の PR とそのリバートの両方が同じデプロイにある場合、分類は適用されません。

静的ルール

静的ルールでは、変数を使用せずにメタデータのパターンに基づいてロールフォワードデプロイを分類します。これらのルールは、修復の広範な指標を照合します。

特定の種類のメタデータを照合する正規表現ルールを定義できます。次の表に、使用できるパターンの例をいくつか示します。プロセスに合わせて調整することも可能です。

メタデータタイプ	正規表現パターンの例	説明
PR タイトル	`.rollforward.`	`rollforward`
PR ラベル	`.hotfix.`	`hotfix`
PR ブランチ名	`recovery/.*`	`recovery/`
コミットメッセージ	`^Revert ".*"$`	`Revert` で始まり `"`
バージョンタグ	`.*_hotfix`	`_hotfix`

静的ルールによる分類の仕組み

静的ルールがデプロイに一致すると、次のアクションが実行されます。

現在のデプロイがロールフォワードとしてマークされます。
直前のデプロイが変更障害としてマークされます。

ホットフィックスラベル、ブランチプレフィックス、バージョンタグ規約など、広範な修復指標には静的ルールを使用してください。

デフォルトルール

Datadog は、自動的に有効になるデフォルトルールを提供しています。

リバート PR: リバートの命名規則 (例: 前の PR を参照する「Revert」) に従う PR タイトルがロールフォワードとして扱われます。元の変更を含む以前のデプロイは、前述の変数ベースのリンクルールを使用して、変更障害としてマークされます。
ホットフィックスインジケーター:「hotfix」を含む PR ラベル、タイトル、またはブランチ名がロールフォワードとして扱われ、その前のデプロイが変更障害としてマークされます。

これらのデフォルトルールは、DORA Metrics 設定ページで完全に構成可能です。これらは、一般的なシグナルをロールフォワードの可能性が高いアクティビティとして解釈する出発点として意図されています。独自のワークフローを反映させ、時間の経過とともに精度を向上させるために、必要に応じてパターン (命名規則、ラベル、バージョンタグなど) を調整してください。

デプロイステータスの更新

自動検出やカスタムルールでほとんどのケースに対応できますが、デプロイのステータスを手動で更新して変更障害としてマークしたり、変更障害を安定としてマークしたりすることも可能です。

デプロイステータスを更新する状況

次のようなシナリオでは、デプロイのステータスを手動で更新することを検討してください。

デプロイが本番環境で問題を引き起こしたが、変更障害として検出されなかった場合。
デプロイが誤って変更障害として分類された場合 (誤検知)。
レポート作成のために、正しいステータスを直ちに反映させる必要がある場合。

API によるステータスの更新

DORA Metrics API を使用して、プログラムからデプロイのステータスを更新します。次の例では、デプロイを変更障害としてマークし、ロールバックによる修復にリンクしています。

curl -X PATCH "https://api.datadoghq.com/api/v2/dora/deployment/{deployment_id}" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "DD-API-KEY: ${DD_API_KEY}" \
-d @- << EOF
{
  "data": {
    "attributes": {
      "change_failure": true,
      "remediation": {
        "id": "eG42zNIkVjM",
        "type": "rollback"
      }
    },
    "id": "z_RwVLi7v4Y",
    "type": "dora_deployment_patch_request"
  }
}
EOF