DevOps-Einblicke Dashboard: Arbeitsbereich

Dashboard „Zusammenfassung“

Die DevOps-Einblicke Das Zusammenfassungs-Dashboard ermöglicht einen Überblick über wichtige Metriken in verschiedenen Kategorien von Beschleunigungs- bis Qualitätsmetriken sowie einen schnellen Überblick über die aktivsten Anwendungen.

Zusammenfassungsberichte

DevOps-Einblicke Dashboard „Zusammenfassung“.


Bericht	Beschreibung	Quelle
Durchschnittliche WIP-Zykluszeit	Durchschnittliche Zeit in Tagen, die sich ein Arbeitselement vor Abschluss im Status „WIP“ befindet.	Berechnung: Zeit bis zum Abschluss von WIP-Elementen geteilt durch die Anzahl der abgeschlossenen Arbeitselemente
Durchschnittliche Vorlaufzeit	Tägliche durchschnittliche Vorlaufzeit für Ausführungen der Pipeline zur Prod-Bereitstellung.	Berechnung: Summe der Vorlaufzeiten der erfolgreichen Prod-Bereitstellung geteilt durch die Anzahl der erfolgreichen Produktions-Pipeline-Ausführungen.
Durchschnittliche Bereitstellungshäufigkeit	Durchschnittliche Anzahl erfolgreicher Produktionsbereitstellungen. Gilt für Pipeline-Schritte vom Typ Prod-Bereitstellung Die sich im Status „Abgeschlossen“ befinden.	Schrittausführung
Durchschnittliche Rate bestandener Tests in %	Täglicher durchschnittlicher Prozentsatz der bestandenen Tests für Pipeline-Ausführungen.	Datenbankansicht, die durch Testzusammenfassung, Testzusammenfassungsbeziehungen, Schrittausführung, Change-Anforderungs-Repository-Details, Schritt, Pipeline, App und Anwendungsproduktdetails verbunden ist.
Abgeschlossene Arbeitselemente	Arbeitselemente, gruppiert nach Arbeitselementtyp, die in den letzten 30 Tagen auf den Status „Abgeschlossen“ gesetzt wurden.	Datenbankansicht, die durch Arbeitselement, Metrikinstanz, Commit-Arbeitselement, Commit, Commit-Ausführung verbunden ist, Schrittausführung, Schritt, Pipeline, App und Anwendungsproduktdetails.
Aktivität: Letzte 30 Tage	Für jede Anwendung die Zusammenfassung der Aktivität in den letzten 30 Tagen.	Datenbankansicht durch Commit, Commit-Arbeitselement, Repository, Commit-Ausführung, App, Testzusammenfassungsbeziehungen, Schrittausführung, Testzusammenfassung.

Dashboard für Flow-Metriken

Die DevOps-Einblicke Flow-Metrikberichte helfen Ihnen, zu visualisieren, wie die Arbeit Ihren Entwicklungsprozess durchläuft. Decken Sie Engpässe auf, indem Sie bestimmen, welche Arten von Arbeiten (z. B. Stories oder Bugs) am längsten dauern.

Flow-Metrikberichte

DevOps-Einblicke Dashboard für Flow-Metriken

Tabelle : 1. Flow-Metrikberichte
Bericht	Beschreibung	Quelle
Durchschnittliche Flow-Zeit	Durchschnittliche Zeit in Tagen, die ein Arbeitselement vom Status „erstellt“ bis zur Endzeit der Schrittausführung einer erfolgreichen Prod-Pipeline-Bereitstellung verbracht hat.	Datenbankansicht, die durch Arbeitselement, Metrikinstanz, Commit-Arbeitselement, Commit, Commit-Ausführung verbunden ist, Schrittausführung, Schritt, Pipeline, App und Anwendungsproduktdetails.
Durchschnittliche WIP-Zykluszeit	Durchschnittliche Zeit in Tagen, die sich ein Arbeitselement in einem bestimmten Status befindet.	Datenbankansicht, die durch Arbeitselement, Metrikinstanz, Commit, Schrittausführung, Commit-Ausführung, und Commit-Arbeitselementlisten.
Durchschnittliche WIP-Anzahl	Durchschnittliche Anzahl der Arbeitselemente, die in den letzten 30 Tagen in Arbeit waren.	Durchschnittliche Anzahl von Arbeitselementen, deren Status auf „in Bearbeitung“ festgelegt ist.
Abgeschlossene Arbeitselemente	Anzahl der Arbeitselemente im Status „Abgeschlossen“, die Commits durch eine erfolgreiche Bereitstellung der Produktions-Pipeline in den letzten 30 Tagen zugeordnet sind. Hinweis: Filter gelten für dieses Diagramm nicht.	Durchschnittliche Anzahl der Arbeitselemente, die dem Schrittausführungstyp zugeordnet sind, der auf Prod-Bereitstellung festgelegt ist. Dies erfordert die Zuordnung von Commit zu Arbeitselementen, da sich nur Arbeitselemente, die über eine Pipeline bereitgestellt werden, in der Produktion befinden.
Durchschnittliche Arbeitselement-Zykluszeit	Durchschnittliche Zeit in Tagen, die sich ein Arbeitselement in einem bestimmten Status befindet.	Datenbankansicht, die durch Arbeitselement, Metrikinstanz, Commit, Schrittausführung, Commit-Ausführung, und Commit-Arbeitselementlisten.
Durchsatz und Verteilung	Anzahl der Arbeitselemente nach Typ, die Commits durch eine erfolgreiche Bereitstellung der Produktions-Pipeline zugeordnet sind.	Datenbankansicht, die durch Arbeitselement, Metrikinstanz, Commit, Schrittausführung, Commit-Ausführung, und Commit-Arbeitselementlisten.
Durchschnittlich geplant für Bereitstellungs-Flow-Zeit	Durchschnittliche Dauer von der Erstellung eines Arbeitselements, das einem Commit zugeordnet ist, bis zur erfolgreichen Bereitstellung des Elements in der Produktion über Pipelines.	Datenbankansicht, die durch Arbeitselement, Metrikinstanz, Commit, Schrittausführung, Commit-Ausführung, und Commit-Arbeitselementlisten.
In Arbeit	Anzahl der Arbeitselemente, die sich derzeit im Status „in Arbeit“ befinden.	Datenbankansicht, die durch Arbeitselement, Metrikinstanz, Commit, Schrittausführung, Commit-Ausführung, und Commit-Arbeitselementlisten.

Change-Beschleunigungs-Dashboard

Die DevOps-Einblicke Auf der Registerkarte „Change-Beschleunigung“ werden Change-Beschleunigungsmetriken angezeigt, die sich auf Ihren Weg zur Automatisierung konzentrieren. Dabei werden automatisierte Changes mit manuellen Changes, Change-Richtlinienentscheidungen und ROI verglichen. Sie können diese Informationen verwenden, um sicherzustellen, dass automatisierte Change-Anforderungen schneller gelöst werden als manuell genehmigte Change-Anforderungen.

Change-Beschleunigungsberichte

DevOps-Einblicke Change-Beschleunigungs-Dashboard

Change-Anforderungen, die Teil von Schrittausführungen sind, qualifizieren sich als DevOps Change-Anforderungen.

Tabelle : 2. Change-Beschleunigungsberichte
Bericht	Beschreibung	Quelle
DevOps Ändern Sie das Volume	Anzahl von DevOps Change-Anforderungen erstellt.	Datenbankansicht, die durch Schrittausführung, Change-Anforderung und Change-Anforderungs-Repository verbunden ist.
Zeit zum Schließen von Änderungen	Durchschnittliche Zeit in Stunden zum Schließen DevOps Changes nach Anwendung. Für jeden Monat ist dies der Durchschnitt für (Zeit, zu der die Change-Anforderung geschlossen wurde) minus (Zeit, zu der die Change-Anforderung geöffnet wurde).	Datenbankansicht, die durch Schrittausführung, Change-Anforderung und Change-Anforderungs-Repository verbunden ist.
Automatisierte vs. manuelle Changes	Vergleich zwischen den Nummern von DevOps Change-Anforderungen mithilfe von Change-Genehmigungsrichtlinien und DevOps Change-Anforderungen, die eine manuelle Genehmigung erfordern. Eine Change-Anforderung gilt als automatisiert, wenn eine Change-Richtlinie die Aktion „Genehmigen/Ablehnen“ ausführt. Ein manueller Change ist eine Change-Anforderung, die einem Anwender oder einer Gruppe für die Aktion „Genehmigen/Ablehnen“ zugewiesen ist und nicht von einer Change-Richtlinie bearbeitet wird.	Datenbankansicht, die durch Schrittausführung, Change-Anforderung und Change-Anforderungs-Repository verbunden ist.
Changes, die auf Genehmigung warten	Anzahl von DevOps Changes, deren Genehmigung aussteht, nach Datumsbereich. Standardmäßig werden Change-Anforderungen im Status „Neu“ oder „Bewerten“ als Warten auf Genehmigung betrachtet. Aktualisieren Sie, um die status anzugeben, die als ausstehend auf Genehmigung gelten Change Request Awaiting StatesEigenschaftseinstellung. Details finden Sie unter DevOps-Einblicke -Eigenschaften.	Datenbankansicht, die durch Detaillisten „Schrittausführung“, „Change-Anforderung“, „Systemeigenschaften“ und „Change-Anforderungs-Repository“ verbunden ist.
Change-Richtlinienentscheidung: automatisch akzeptieren	Die Anzahl der Change-Richtlinienentscheidungen nach Entscheidungstyp, die Change-Anforderungen automatisch akzeptieren. Zeigen Sie auf einen Wert im Diagramm, um die Liste der Richtlinienentscheidungen anzuzeigen, die für die automatische Genehmigung verwendet wurden, und die Häufigkeit, mit der eine Entscheidung für die automatische Genehmigung verwendet wurde.	Datenbankansicht, die durch Detaillisten „Schrittausführung“, „Change-Anforderung“, „Systemeigenschaften“ und „Change-Anforderungs-Repository“ verbunden ist.
Change-Richtlinienentscheidung: automatisch ablehnen	Die Anzahl der Change-Richtlinienentscheidungen nach Entscheidungstyp, die Change-Anforderungen automatisch ablehnen. Zeigen Sie auf einen Wert im Diagramm, um die Liste der Richtlinienentscheidungen anzuzeigen, die für die automatische Ablehnung verwendet wurden, und die Häufigkeit, mit der eine Entscheidung für die automatische Ablehnung verwendet wurde.	Datenbankansicht, die durch Schrittausführung, Change-Anforderung, angewendete Richtlinie, Aktion für automatische Genehmigung, Definition der Change-Genehmigung und Detaillisten des Change-Anforderungs-Repositorys verbunden ist.
Einsparungen durch Change-Beschleunigung	Nettobetrag, der pro Monat durch Automatisierung eingespart wird DevOps Changes. Wenn ein Change automatisiert wird, muss ein Entwickler die Change-Anforderung nicht manuell ausfüllen und jedes Arbeitselement, jede Code-Commits, Testergebnisse und andere Nachweise und Artefakte dem Change zuordnen. Nachdem diese Aktivität automatisiert wurde, werden jetzt Stunden gespeichert, die für das Ausfüllen des Change, die Suche, das Nachverfolgen und das Anhängen von Elementen aus anderen Tools an einen Change aufgewendet wurden. Weitere Arbeitselemente erfordern eine relativ steigende Anzahl von Stunden, um sie manuell zuzuordnen. Daher sollte eine höhere Anzahl von Arbeitselementen zu mehr Stunden führen, nachdem der Change automatisiert wurde. Die Einsparungen bei der Change-Beschleunigung werden berechnet, indem die eingesparten Stunden mit den durchschnittlichen stündlichen Entwicklerkosten multipliziert werden. Um den Standardwert der durchschnittlichen stündlichen Entwicklerkosten zu ändern, aktualisieren Sie Average Hourly developer CostEigenschaftseinstellung. Details finden Sie unter DevOps-Einblicke -Eigenschaften.	Berechnung: Durchschnittliche stündliche Entwicklerkosten multipliziert mit eingesparten Entwicklerstunden.
Eingesparte Entwicklerstunden	Anzahl der durch Automatisierung pro Monat eingesparten Entwicklerstunden DevOps Changes. Um den Standardwert von 1 (eine) Stunde pro Entwickler zu ändern, aktualisieren Sie X hours per Developer timeEigenschaftseinstellung. Details finden Sie unter DevOps-Einblicke -Eigenschaften.	Berechnung: Anzahl der Arbeitselemente in einer Change-Anforderung multipliziert mit 1 Stunde pro Entwickler.

Metriken-Dashboard beschleunigen

Die DevOps-Einblicke Beschleunigungsmetriken sind vier Schlüssel DevOps Metriken, die die Leistung der Softwarebereitstellung messen. Bereitstellungshäufigkeit und Vorlaufzeitmessung DevOps Geschwindigkeit, während Change-Fehlerrate und durchschnittliche Zeit bis zur Wiederherstellung verwendet werden, um die Stabilität zu messen.

Beschleunigen Sie Metrikberichte

DevOps-Einblicke Metriken-Dashboard beschleunigen

Tabelle : 3. Beschleunigen Sie Metrikberichte
Bericht	Beschreibung	Quelle
Durchschnittliche Vorlaufzeit	Durchschnitt von: ([Zeit, zu der der Code erfolgreich in die Produktion übertragen wurde] minus [Früheste Commit-Zeit]) Gilt für Pipeline-Schritte vom Typ Prod-Bereitstellung Die sich im Status „Abgeschlossen“ befinden. Hinweis: Dieses Widget verwendet eine durchschnittliche Zusammenfassung und unterstützt keine Auswahl mehrerer Elemente.	Pipeline-Ausführung
Durchschnittliche Bereitstellungshäufigkeit	Durchschnittliche Anzahl erfolgreicher Produktionsbereitstellungen. Gilt für Pipeline-Schritte vom Typ Prod-Bereitstellung Die sich im Status „Abgeschlossen“ befinden.	Schrittausführung
Durchschnittliche MTTR	Durchschnittliche Lösungszeit für einen Incident, der durch verursacht wurde DevOpsÄndern. Hinweis: Dieses Widget verwendet eine durchschnittliche Zusammenfassung und unterstützt keine Auswahl mehrerer Elemente.	Datenbankansicht durch Incident, Change-Anforderung, Schrittausführung, Schritt, Pipeline, und App-Listen.
Durchschnitt DevOps Change-Fehlerrate	Tägliches durchschnittliches Verhältnis von DevOps Change-Anforderungen, die einem Incident zugeordnet sind, geteilt durch alle DevOps Change-Anforderungen. Hinweis: Dieses Widget verwendet eine Formel und unterstützt keine Auswahl mehrerer Elemente.	Change-Anforderung
Vorlaufzeit von Commit bis Bereitstellung	Dauer vom frühesten Commit-Zeitpunkt bis zur Produktionsbereitstellung für eine erfolgreiche Pipeline-Ausführung. Der Wert enthält nur Schritte vom Typ Prod-Bereitstellung Die sich im Status „Abgeschlossen“ befinden. Sie können hohe Vorlaufzeiten untersuchen, indem Sie die langsamsten Pipeline-Schritte identifizieren. Beispielsweise könnte ein manueller Change-Genehmigungsprozess die Vorlaufzeit erhöhen.	Berechnung: Summe der erfolgreichen Vorlaufzeiten der Prod-Bereitstellung geteilt durch die Anzahl der erfolgreichen Produktions-Pipeline-Ausführungen. Erfordert die Zuordnung von „Commits zu Aufgabenausführung“. Sowohl Repository als auch Pipeline müssen nachverfolgt und derselben App zugeordnet werden. Erfordert den Schritttyp „Prod-Bereitstellung“. Das Ergebnis der Aufgabenausführung muss erfolgreich sein.
Durchschnittliche Zeit bis zur Wiederherstellung nach Incidents, die durch verursacht wurden DevOps Changes	Tägliche durchschnittliche Zeit bis zur Lösung eines Incident, der durch verursacht wurde DevOpsÄndern.	Datenbankansicht, die durch Schrittausführung, Change-Anforderung, Change-Anforderungs-Repository-Details und Incident-Listen verbunden ist. Nur für berechnet DevOps Incidents durch Berücksichtigung der Öffnungs- und Schließungszeit des Incidents.
Häufigkeit der Bereitstellung in der Produktion	Anzahl der erfolgreichen Produktionsbereitstellungen. Der Wert enthält nur Pipeline-Schritte vom Typ Prod-Bereitstellung Die sich im Status „Abgeschlossen“ befinden. Um den Standardwert von 30 Tagen zu ändern, aktualisieren Sie Datumsbereich Einstellung.	Datenbankansicht durch Change-Anforderung, Schrittausführung, Change-Anforderungs-Repository-Detail. Der Status der Schrittausführung muss „Abgeschlossen“ sein. Erfordert den Schritttyp „Prod-Bereitstellung“.
DevOps Change-Fehlerrate aus Incidents	Prozentsatz von DevOps Changes, die Incidents verursacht haben, geteilt durch alle DevOps In der Produktion bereitgestellte Changes. Wenn eine Change-Anforderung mehrere Incidents verursacht hat, wird nur der Change berücksichtigt, der den Incident verursacht oder ausgelöst hat. Die Anzahl der Incidents, die der Change verursacht hat, wird nicht berücksichtigt.	Benötigt DevOps Change-Anforderung (Change, der einer Schrittausführung zugeordnet ist). Der Status der Schrittausführung muss „Abgeschlossen“ sein. Erfordert den Schritttyp „Prod-Bereitstellung“. Benötigt einen von verursachten Incident, der sein muss DevOps Change-Anforderung.
Bereitstellungserfolgsquote	Erfolgsquote von Bereitstellungen über Letzte 30 Tage. Bereitstellungserfolgsrate = (Anzahl der erfolgreichen Bereitstellungen in den letzten 30 Tagen / Gesamtzahl der Bereitstellungen in den letzten 30 Tagen) * 100 Gilt für Schritte vom Typ Prod-Bereitstellung Im Status „Abgeschlossen“. Hinweis: Dieses Widget verwendet eine Formel und unterstützt keine Auswahl mehrerer Elemente.	Schrittausführung
Bereitstellungshäufigkeit	Anzahl der erfolgreichen Produktionsbereitstellungen in den letzten 30 Tagen. Gilt für Schritte vom Typ Prod-Bereitstellung Die sich im Status „Abgeschlossen“ befinden.	Schrittausführung
Fehlgeschlagene Bereitstellungen	Anzahl der fehlgeschlagenen Produktionsbereitstellungen in den letzten 30 Tagen. Gilt für Schritte vom Typ Prod-Bereitstellung Die sich im Status „fehlgeschlagen“ oder „vom Anwender abgebrochen“ befinden.	Schrittausführung

Dashboard für Qualitätsmetriken

Die DevOps-Einblicke Das Dashboard für Qualitätsmetriken ermöglicht einen schnellen Blick auf Daten aus Tools wie SonarQube Für die Codeabdeckung den Prozentsatz der bestandenen Tests Ihrer Orchestration-Tools, Schwachstellen von Sicherheitstools und sogar die Gesamtanzahl der Fehler.

Berichte zu Qualitätsmetriken

DevOps-Einblicke Dashboard für Qualitätsmetriken

Tabelle : 4. Berichte zu Qualitätsmetriken
Bericht	Beschreibung	Quelle
Codeabdeckung in %	Prozentsatz des Codes, der durch Tests abgedeckt wird.	Erfordert Softwarequalitäts-Scan-Detail mit Kategorie = Abdeckung (%) Benötigt Zusammenfassungsbeziehungen des Softwarequalitätscans im Zusammenhang mit der Aufgabenausführung
Bestandene Tests in %	Prozentsatz der bestandenen Tests.	Benötigt Testzusammenfassung im Zusammenhang mit der Aufgabenausführung
Sicherheitsschwachstellen	Anzahl der Sicherheitsschwachstellen im Zeitverlauf.	Erfordert Softwarequalitäts-Scan-Detail mit Kategorie = Schwachstellen Benötigt Zusammenfassungsbeziehungen des Softwarequalitätscans im Zusammenhang mit der Aufgabenausführung.
Fehlerzählungen	Anzahl der Arbeitselemente vom Typ „Fehler“.	Benötigt Commits to Work Itemszuordnung. Sowohl Repository als auch Plan müssen nachverfolgt und derselben App zugeordnet werden. Benötigt Commits to Task Executionzuordnung. Sowohl Repository als auch Pipeline müssen nachverfolgt und derselben App zugeordnet werden Erfordert, dass das Arbeitselement vom Typ „Fehler“ ist.

DevOps-Einblicke Entwicklungs-Dashboard

Entwicklungsmetriken konzentrieren sich auf Commit-Daten, die Einblicke in die Aktivität und Agilität Ihrer Teams bieten. Mit diesen Informationen können Sie die vollständige Nachverfolgbarkeit der Arbeit erreichen, indem Sie sicherstellen, dass Commits mit den entsprechenden Arbeitselementen gekennzeichnet werden.

Entwicklungsberichte

DevOps-Einblicke Entwicklungs-Dashboard

Tabelle : 5. Entwicklungsberichte
Bericht	Beschreibung
Commit-Häufigkeit	Anzahl der Commits, die Pipeline-Ausführungen zugeordnet sind. Kleinere, häufigere Commits werden gegenüber größeren, weniger häufigen Commits bevorzugt.
Aktive Committer	Anzahl der Committer, die Commits übermittelt haben. Da dieser Bericht Metrikzusammenfassung verwendet, wird die Auswahl mehrerer Elemente nicht unterstützt.
Top-Committer (laufende Summe über 30 Tage)	Committer mit der höchsten Anzahl von Commits.
Top-Rückgängigmacher (laufende Summe über 30 Tage)	Committer mit der höchsten Anzahl von Wiederherstellungen.
Durchschnittliche Commits pro Committer	Durchschnitt berechnet als: `(Gesamtanzahl der Commits)/(aktive Committer)` . Ein höherer Wert ist günstiger. Da dieser Bericht Metrikzusammenfassung verwendet, wird die Auswahl mehrerer Elemente nicht unterstützt.
Durchschnittliche Commits pro Pipelineausführung	Durchschnittliche Commits pro Pipeline, berechnet als (Gesamtanzahl der Commits)/(Anzahl der Pipeline-Ausführungen). Eine niedrige Zahl ist vorzuziehen, was auf einen konzentrierten Aufwand hinweist, anstatt von Aufgabe zu Aufgabe ohne Abschluss zu wechseln. Da dieser Bericht Metrikzusammenfassung verwendet, wird die Auswahl mehrerer Elemente nicht unterstützt.
Commits ohne Arbeitselemente	Commits, die keinem Arbeitselement zugeordnet sind, gruppiert nach Committer. Dieser Bericht ist nützlich, um zu untersuchen und zu lösen, warum ein Commit nicht an ein Arbeitselement gebunden ist, da alle Commits an ein Arbeitselement gebunden sein sollten.
Prozentsatz positive Ergebnisse für Pipeline	Verhältnis der erfolgreichen Pipeline-Ausführungen geteilt durch die Gesamtzahl der Pipeline-Ausführungen.

DevOps-Einblicke Dashboard „Betriebsstabilität“

Operative Metriken spiegeln die Stabilität Ihrer Anwendungen wider, damit Sie sicherstellen können, dass Ihre Teams schnell arbeiten, ohne die Releasequalität zu beeinträchtigen.

Berichte zur Betriebsstabilität

DevOps-Einblicke Dashboard „Betriebsstabilität“

Tabelle : 6. Berichte zur Betriebsstabilität
Bericht	Beschreibung	Quelle
Incidents	Anzahl der Incidents für Pipeline-Schritte vom Typ „Prod-Bereitstellung“, die mit einem Service in verknüpft sind CMDB.	Erfordert den Schritttyp „Prod-Bereitstellung“. Benötigt einen Incident, der einem Service zugeordnet ist, der dem im Schritt „Prod-Bereitstellung“ entspricht.
Ausfälle	Anzahl der Ausfälle für Pipeline-Schritte vom Typ „Prod-Bereitstellung“, die mit einem Service in verknüpft sind CMDB.	Erfordert den Schritttyp „Prod-Bereitstellung“. Benötigt Ausfall (cmdb_ci_Outage), der einem Service zugeordnet ist, der dem im Schritt „Prod-Bereitstellung“ entspricht.
Serviceverfügbarkeit	Durchschnittliche Serviceverfügbarkeit für Pipeline-Schritte vom Typ „Prod-Bereitstellung“, die mit einem Service in verknüpft sind CMDB.	Erfordert den Schritttyp „Prod-Bereitstellung“. Benötigt ein übergeordnetes Serviceangebot, das einem Service zugeordnet ist, der dem im Prod-Bereitstellungsschritt entspricht.
Verbleibendes Fehlerbudget	Prozentsatz des verbleibenden Fehlerbudgets in einem Monat für Pipeline-Schritte vom Typ „Prod-Bereitstellung“, die mit einem Service in der CMDB verknüpft sind. Diese Daten stammen aus der Anwendung Site Reliability Operations. Ein Fehlerbudget ist die Menge des Servicelevel-Ziels (Service Level Objective, SLO), die Sie über einen bestimmten Zeitraum ausgeben können. Es kann verwendet werden, um die Release-Geschwindigkeit zu verwalten. Dies basiert normalerweise auf Verfügbarkeit, Latenz usw.	Erfordert den Schritttyp „Prod-Bereitstellung“. Benötigt ein übergeordnetes Serviceangebot, das einem Service zugeordnet ist, der dem im Prod-Bereitstellungsschritt entspricht. Benötigt SRO-Anwendung.