DORA comprises four metrics:

Data for these metrics is retained for 180 days. Users can choose to view data for any time within the last 180 in the following graduations:

Using the

Select duration

feature located on the right directly above the graphic displays, the user can select the data history range from a dropdown menu containing these selections.

The graph represents the total and average number of deployments for the selected history period. It is essential to map the application across all technical services to ensure the accuracy of data flow in the graphs.

For a more in-depth analysis, click on the launch icon. This action will open a detailed view of a graph and a corresponding table. Similar to the summary graph, you can adjust the time frame for the data in this detailed view.

The details table includes technical service, application name, status, duration, deployment date, release, and environment.

The graph represents the total and average number of deployments for the selected history period.

For a more in-depth analysis, click on the launch icon. This action will open a detailed view of a graph and a corresponding table. Similar to the summary graph, you can adjust the time frame for the data in this detailed view.

The details table contains the application name, first commit, deployment date, change lead time, and epic details with a redirecting link.

The Change failure rate is a significant metric in DevOps that signifies the percentage of deployed changes that fail in the production environment necessitating an immediate fix. These failures could be service degradation, system outages, functionality issues, or any other significant problems that negatively impact the end-user experience or system stability.

CFR is mathematically defined as

Deployments Failed

/

Total Number of Deployments

Using this calculation, the interactive graph displays the total and average failure rate of deployments over a selected period.

For a more in-depth analysis, click on the launch icon. This action will open a detailed view of a graph and a corresponding table. Similar to the summary graph, you can adjust the time frame for the data in this detailed view.

The detail table provides information such as application name, change failure rate, and incident details. The table includes selectable links that redirect you to relevant sections or additional information for easy navigation.

Creation Time

is the time at which an incident was created and

Resolved Time

is the time at which the incident was promoted to the Resolved state. MTTR is mathematically defined as

Resolved Time

—

Creation Time

The graph represents the total and average number of deployments for the selected history period. This graph allows you to filter data by priorities (P1 through P4), by default,

All priorities

is selected. MTTR trends help in evaluating the resilience of the system. A decreasing MTTR indicates that the team is improving its ability to recover from failures quickly, enhancing overall system reliability. As more applications are added to DevOps Intelligence, users can track and compare the performance of different applications. Performance can also be measured against industry standards, categorized as ‘High’, ‘Medium’, or ‘Low’ according to Google’s standards.

For a more in-depth analysis, click on the launch icon. This action will open a detailed view of a graph and a corresponding table. Similar to the summary graph, you can adjust the time frame for the data in this detailed view.

The details table includes the Technical service, Application, Number of Incidents, Mean Time To Recovery, and Incident details. For easy navigation, redirecting links are incorporated within the table.

Open-source projects like Four Keys can facilitate this by automatically setting up a data ingestion pipeline and compiling the data into a comprehensible dashboard. This setup helps to monitor your metrics and view trends over time, providing valuable insights into your team's operational efficiency and effectiveness.

Deployment data can be obtained in one of two ways:

When adding a connection, the incident Host URL fields should be populated with your ServiceNow instance host url. 

To post the record from the BYO deployment, refer to the configure page, here: Bring your own deploy. Ensure the following:

This section describes how to configure data collection for Deployment frequency:

You can connect existing tools, where release information is available, and add the service config from the tool's configuration page. For instance: If you are using ArgoCD, the service config should be created with the details available at the documentation page for configuring that service, in this case, ArgoCD. Instructions for configuring all supported services are available in the DevOps Intelligence documentation (Kyndryl Docs) by clicking the

Supported tools and integration

tile

Alternatively, you can post the record from the BYODeployment using supported APIs.  Ensure that the fields

environment

and

release

match those provided in the change request. Also, make sure that

itsm_host

and 'endpoint hostname' match your ServiceNow instance URL. If you post the data via BYODeployment, set

isProduction

to true.

This section presents configuring Change lead time from BitBucket and GitHub, GitLab, and Azure DevOps.

For more information on BitBucket configuration, please see: Atlassian Bitbucket, Bitbucket Cloud and Bitbucket Server.

For more information on GitHub and GitLab configuration, please refer to the following links: GitHub and GitHub enterprise configuration and GitLab.

For more information on Azure DevOps  configuration, please see: Azure Boards and Azure Repo configuration.

Once the release cut is done and the release branch is created, it automatically links all releases with User Stories. The Epic Change lead time calculation is determined from the first User Story's first PR merge date to the Last User Story's last merge and release deployment time.

To use Jira as an issue-tracking tool and another source control tool, you must provide the SCM Host URL when configuring the Jira Connection. Note that if you specify a separate source tool in the SCM Host URL, a separate IAM connection for that specific source tool should also be established.

For consistent data collection, ensure you format the 'short description' field in the change request as follows:

The following image depicts the example of a short description field in a change request. Data will be visualized when incidents are in a closed state.

The Incident should also be mapped to the initiating ChangeRequest by giving the change request ID in the Related Records section

Change Request

" and

Cause By Change

field.

MTTR calculations are performed for Incidents that are either in a

closed

or

resolved

state. All the incidents that are moved to a resolved or closed state within 180 days are synched. While creating Incidents, the

Configuration Item

field should be populated, which will be mapped to TechnicalServiceName in DevOps Intelligence. If the Configuration Item field is not populated, then by default,

No CI

will be marked for such incidents and reflected in the

Technical Service

column of the MTTR details page.

To correlate incidents with their respective Change Requests, provide the Change Request ID in the 'Related Records' section under the 'Change Request' and 'Cause By Change' fields when creating an incident. The following image presents sample information of ServiceNow.

Mean time to recovery calculations are performed for incidents in a

closed

or

resolved

state. When creating incidents, ensure that the

Configuration Item

field is populated. This field maps to the

TechnicalServiceName

in DI. In cases where the Configuration Item field is not populated,

No CI

will be labeled by default for such incidents, which will then be reflected in the

Technical Service

column of the MTTR details page.