docs: polish fdrt docs (#734)
Co-authored-by: Startrekzky <kaiyun.zhang@merico.dev>
diff --git a/docs/Configuration/images/fdrt.png b/docs/Configuration/images/fdrt.png
new file mode 100644
index 0000000..89c9080
--- /dev/null
+++ b/docs/Configuration/images/fdrt.png
Binary files differ
diff --git a/docs/DORA.md b/docs/DORA.md
index 114a52f..7ddebfc 100644
--- a/docs/DORA.md
+++ b/docs/DORA.md
@@ -20,11 +20,12 @@
- [Deployment Frequency](./Metrics/DeploymentFrequency.md): Number of successful deployments to production, how rapidly is your team releasing to users?
- [Lead Time for Changes](./Metrics/LeadTimeForChanges.md): How long does it take from commit to the code running in production? This is important, as it reflects how quickly your team can respond to user requirements.
-Stability is composed of some core metrics:
+Stability is composed of two core metrics:
- [Change Failure Rate](./Metrics/CFR.md): How often are your deployments causing a failure?
-- [Median Time to Restore Service (2021 dora report)](./Metrics/MTTR.md): How long does it take the team to properly recover from a failure once it is identified?
-- [Failed Deployment Recovery Time (2023 dora report)](./Metrics/FailedDeploymentRecoveryTime.md): How long does it take from the time of deployment to the resolution of the incident associated with the deployment?
+- [Median Time to Restore Service (MTTR)](./Metrics/MTTR.md): How long does it take the team to properly recover from a failure once it is identified?
+
+However, MTTR is replaced by [Failed Deployment Recovery Time](./Metrics/FailedDeploymentRecoveryTime.md) from the 2023 DORA report. This metric measures the finish time of a deployment to the resolution of the incident caused by the deployment.
diff --git a/docs/Metrics/FailedDeploymentRecoveryTime.md b/docs/Metrics/FailedDeploymentRecoveryTime.md
index e7343d4..46e573b 100644
--- a/docs/Metrics/FailedDeploymentRecoveryTime.md
+++ b/docs/Metrics/FailedDeploymentRecoveryTime.md
@@ -7,7 +7,7 @@
## What is this metric?
-The Time of changes that were made to a code that then resulted in incidents, rollbacks, or any type of production failure.
+The time of changes that were made to a code that then resulted in incidents, rollbacks, or any type of production failure.
## Why is it important?
@@ -19,7 +19,9 @@
## How is it calculated?
-The time from deployment to the incident corresponding to deployment is resolved. For example, if a deployment at 10:00 AM and incident caused by deployment is resolved at 11:00 AM, the failed deployment recovery time is one hour.
+The time from deployment to the incident corresponding to deployment is resolved. For example, if a deployment finishes at 10:00 AM and causes an incident at 10:20. Then, the incident gets resolved at 11:00 AM. The failed deployment recovery time is one hour.
+
+
Below are the 2023 DORA benchmarks for different development teams from Google's report. However, it's difficult to tell which group a team falls into when the team's failed deployment recovery time is `between one week and six months`. Therefore, DevLake provides its own benchmarks to address this problem:
@@ -30,15 +32,16 @@
| Medium performers | Between one day and one week | Between one day and one week |
| Low performers | More than six months | More than one week |
+<p><i>Source: 2023 Accelerate State of DevOps, Google</i></p>
<b>Data Sources Required</b>
-- `Deployments` from Jenkins, GitLab CI, GitHub Action, BitBucket Pipelines, or Webhook, etc.
-- `Incidents` from Jira issues, GitHub issues, TAPD issues, PagerDuty Incidents, etc.
+- `Deployments` from Jenkins, GitLab CI, GitHub Action, BitBucket Pipelines, Webhook, etc.
+- `Incidents` from Jira issues, GitHub issues, TAPD issues, PagerDuty Incidents, Webhook, etc.
<b>Transformation Rules Required</b>
-Define `deployment` and `incident` in [data transformations](https://devlake.apache.org/docs/Configuration/Tutorial#step-3---add-transformations-optional) while configuring the blueprint of a project to let DevLake know what CI/issue records can be regarded as deployments or incidents.
+Define `deployment` and `incident` in [data transformations](../Configuration/Tutorial#step-3---add-transformations-optional) while configuring the blueprint of a project to let DevLake know what CI/issue records can be regarded as deployments or incidents.
<b>SQL Queries</b>
@@ -198,4 +201,5 @@
- Add unit tests for all new feature
- "Shift left", start QA early and introduce more automated tests
-- Enforce code review if it's not strictly executed
+- Enforce code review if it is not strictly executed
+- Improve your user support workflow to cope with incidents more efficiently
\ No newline at end of file
