So funktioniert’s

So funktioniert’s

Drei Schritte von den ersten Daten zur Steuerung Ihrer Services. Kein halbjähriges Implementierungsprojekt.

  1. 01

    Quellen anbinden

    Das Monitoring liefert Events, Discovery oder ein Import die Konfigurationselemente. Weitere Integrationen brauchen Sie nicht.

  2. 02

    CentOps erstellt die Service-Landkarte

    Elemente, Beziehungen und Verantwortliche bilden eine Abhängigkeitskarte. Events werden Elementen zugeordnet und zu Situationen zusammengefasst.

  3. 03

    Services durchgängig steuern

    Incidents, Problems, Changes, Patching und die Architektur-Roadmap arbeiten auf derselben Landkarte und derselben Auswirkungsberechnung.

Was CentOps unterscheidet

Ein Abhängigkeitsgraph

Incident, Change, Patch-Plan und Monitoring-Situation berechnen die Auswirkung gleich – einschließlich Clustern, Replikation und gespiegeltem Speicher.

Integration nur an der Quelle

Sie binden Monitoring (Zabbix, Prometheus oder kommerzielle Tools) und Discovery an. Keine Dutzenden Konnektoren zu weiteren Systemen, die gepflegt werden müssen.

Vom Alert bis zur Roadmap

Betrieb, Changes und Architektur in einer Anwendung. Was heute ausfällt, fließt in den Plan für das nächste Quartal ein.

FÄHIGKEITENSTRATEGIECapabilityBUSINESS-SERVICESBUSINESSBusiness ServiceANWENDUNGENANWENDUNGApplication ComponentDATENBANKENTECHNOLOGIESystem SoftwareSERVER UND CONTAINERNode ·System SoftwareVIRTUALISIERUNG UND CLOUDNode ·Technology ServiceVIRTUELLES NETZWERK UND DATENSPEICHERCommunication Network ·Technology ServiceSPEICHER UND SANDevice ·Communication NetworkNETZWERK UND SEGMENTEDevice ·Communication NetworkRECHENZENTRUMTECHNOLOGIE – PHYSISCHFacility · EquipmentROADMAPIMPLEMENTIERUNG & MIGRATIONWork Package · PlateaukommerziellOpen SourceAlarm-Integration1.284 Alarme → 3 SituationenApplication Interface · FlowFähigkeitBusiness-ServiceAnwendungIntegrationDatenbankServerContainerVirtualisierungCloudVirtuelles NetzVirtuelle DiskSpeicher ASpeicher BSwitchFirewallRechenzentrumAusweich-RZArbeitspaketZielbildIncidentRedundanz · Service läuftFÄHIGKEITENSTRATEGIECapabilityBUSINESS-SERVICESBUSINESSBusiness ServiceANWENDUNGENANWENDUNGApplication ComponentDATENBANKENTECHNOLOGIESystem SoftwareSERVER UND CONTAINERNode · System SoftwareVIRTUALISIERUNG UND CLOUDNode · Technology ServiceVIRTUELLES NETZWERK UND DATENSPEICHERCommunication Network · Technology ServiceSPEICHER UND SANDevice · Communication NetworkNETZWERK UND SEGMENTEDevice · Communication NetworkRECHENZENTRUMTECHNOLOGIE – PHYSISCHFacility · EquipmentROADMAPIMPLEMENTIERUNG & MIGRATIONWork Package · PlateaukommerziellOpen SourceAlarm-Integration1.284 Alarme → 3 SituationenFähigkeitBusiness-ServiceAnwendungIntegrationDatenbankServerContainerVirtualisierungCloudVirtuelles NetzVirtuelle DiskSpeicher ASpeicher BSwitchFirewallRechenzentrumAusweich-RZArbeitspaketZielbildIncidentRedundanz · Service läuft
Eine Karte von Monitoring-Alarmen bis zu Fähigkeiten und Roadmap. Mit ArchiMate sehen Sie dieselbe Umgebung als Modell der Unternehmensarchitektur.
Herausforderungen

Herausforderungen, die wir lösen

IT-Operationen scheitern selten an der Technologie. Sie scheitern, weil niemand das vollständige Bild hat: Wer der Service Owner ist, was von was abhängt, wann die Produktion berührt werden kann und was es kostet.

01

Eine CMDB, der niemand traut

Daten veralten, Leute führen eigene Tabellen und fragen Kollegen während Incidents.

LösungVersionen und Historie für jeden Change, Datenqualitätschecks, Discovery, Import und Synchronisierung mit einer primären CMDB.
Artikel lesen →
02

Auswirkungen werden erst nach dem Ausfall entdeckt

Wer einen Change plant, weiß oft nicht, welche Business-Services davon betroffen sein werden.

LösungEine mehrschichtige Abhängigkeitskarte, Ausfall-Simulation und berechneten Auswirkungen, bevor ein Change eingereicht wird.
Artikel lesen →
03

Genehmigungen gehen in E-Mails verloren

Ausfälle, Requests und Preise werden in verschiedenen Kanälen genehmigt und niemand weiß, was wo pending ist.

LösungEine Freigabe-Queue, eine Eigentumsregel, jede Ablehnung mit einem Grund.
Artikel lesen →
04

Patching als monatliche Verhandlung

Jedes Fenster wird erneut verhandelt und kritische Schwachstellen warten.

LösungEin Patch-Vereinbarung mit dem Service Owner, ein vorab genehmigtes Fenster, Wellenpläne und ein beschleunigter Modus.
Artikel lesen →
05

Tausende von Alarmen, keine Situation

Das Monitoring meldet Symptome, nicht Ursachen. Die Leute hören auf zu lesen.

LösungDeduplikation, Unterdrückung während Changes und Gruppierung in Situationen mithilfe der CMDB-Topologie.
Artikel lesen →
06

Kosten nicht mit Services verknüpft

Rechnungen für Cloud und Rechenzentrum können nicht Services oder Kunden zugeordnet werden.

LösungFOCUS-Kostenimport, Kosten nach Service und Kunde, eine Preisliste mit einem Besitzer.
Artikel lesen →
Anwendungsfälle

Use Cases

Alltägliche Betriebssituationen und wie eine gemeinsame Abhängigkeitskarte hilft.

01

Geplante Unterbrechung eines Datenbankclusters

Der Change-Manager erstellt einen Change. CentOps berechnet die betroffenen Services, bietet einen Zeitrahmen innerhalb des Wartungsfensters und außerhalb eines Change-Freeze an und sendet die Unterbrechung an die Service Owner zur Genehmigung. Alerts von betroffenen Servern werden während des Changes unterdrückt.

02

Ein Speicherfehler in der Nacht

Monitoring sendet Hunderte von Ereignissen. CentOps gruppiert sie in eine Situation mit einer wahrscheinlichen Ursache im Speicher, öffnet ein großes Incident mit den betroffenen Services und eskaliert an den Lieferanten gemäß dem Service-Vertrag.

03

Eine kritische Schwachstelle am Freitag

Der Scanner-Import markiert eine aktiv ausgenutzte Schwachstelle. CentOps zeigt die betroffenen Server und Services, setzt eine Frist nach Schweregrad und erstellt einen Change in einem Schritt aus dem beschleunigten Modus des Patch-Abkommens.

04

Monatliche Abrechnungsdaten

Kosten von Clouds, OpenShift und dem Rechenzentrum werden im FOCUS-Format geladen, zum Kurs der Tschechischen Nationalbank umgerechnet und nach Kunde, Projekt und Service aufgeschlüsselt. Die Finanzabteilung erhält die Daten ohne Tabellenkalkulationsarbeit.

05

Geteilte Services für viele Kunden

Ein Anbieter betreibt eine Plattform für Dutzende von Organisationen. Die Benutzer eines Kunden sehen nur ihre eigenen Daten, einschließlich Kosten; Resolver arbeiten über Kunden hinweg und der Service Owner genehmigt die Preisliste.

06

Neben einer primären CMDB

Das Unternehmen hält seine CMDB in einem anderen Tool. CentOps synchronisiert mit ihm über externe IDs und fügt die operative Schicht hinzu: Auswirkungskarten, Changes in Fenstern, Patching und Kosten.

Nächster Schritt

Testen Sie CentOps mit Ihren eigenen Services.

Binden Sie Monitoring und Discovery an und sehen Sie Ihre Service-Landkarte schon in der ersten Woche. Die Beta ist 6 Monate kostenlos.

An der Beta teilnehmen →