DevOps-Einblicke Dashboard: Arbeitsbereich
Die DevOps-Einblicke Das Dashboard bietet eine flexible grafische Ansicht von Betriebs- und Geschäftsberichten. Verwenden Sie das Dashboard, um die Ergebnisse Ihrer Gesamtergebnisse zu bewerten DevOps Prozess.
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
| 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
| 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
Change-Anforderungen, die Teil von Schrittausführungen sind, qualifizieren sich als DevOps Change-Anforderungen.
| 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.
|
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
| 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
| 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
| 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: 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
| 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. |