Die Sprache des Vorfallmanagements

Vorfallbestätigung

In den meisten Bereitschaftswarntools kann eine generierte Vorfallwarnung von einem Benutzer bestätigt werden. Dieser Benutzer übernimmt damit die Verantwortung für das Problem und gibt an, dass er an einer Lösung arbeitet.

Umsetzbare Warnmeldung

Eine umsetzbare Warnmeldung ist eine Warnmeldung, die ein Problem und dessen Auswirkungen klar beschreibt und zur richtigen Zeit an die richtigen Personen weitergeleitet wird, damit das Team sofort Maßnahmen ergreifen kann.

Aktive Überwachung

Systeme, die mit aktiver Überwachung ausgestattet sind, werden mit Software regelmäßig überprüft oder automatisch auf Leistungsänderungen überwacht, die zu Vorfällen führen könnten.

Nachträglicher Review (After-action Review, AAR)

Ein nachträglicher Review ist ein strukturierter Überprüfungsprozess, der nach einem Ereignis stattfindet. Dabei beschreiben Mitarbeiter üblicherweise, was genau passiert ist, versuchen die Gründe dafür herauszufinden und suchen nach Bereichen mit Verbesserungspotenzial, um die gleichen oder ähnliche Ereignisse in Zukunft zu verhindern. Nachträgliche Reviews werden auch als Post-Mortem-Analysen oder Reviews vergangener Vorfälle bezeichnet.

Vereinbarte Servicezeit (Agreed Service Time, AST)

Die vereinbarte Servicezeit ist die Zeitspanne (normalerweise in Stunden pro Jahr gemessen), während der ein Service erwartungsgemäß verfügbar ist. Diese Vereinbarung wird in der Regel in einem Service Level Agreement (SLA) zwischen Anbieter und Kunde festgehalten. Hochverfügbare Services versprechen in der Regel eine Verfügbarkeit von 99,99 %, sodass pro Jahr Ausfallzeiten von weniger als einer Stunde zulässig sind.

Warnmeldung

Ein Alarm oder eine Warnung, die generiert wird, wenn Überwachungstools Änderungen, risikobehaftete Aktionen oder Ausfälle in der IT-Umgebung erkennen.

Störende Warnmeldungen

Warnmeldungen können auch störend sein: Wenn in kurzer Zeit eine große Anzahl von Warnungen erzeugt wird, können Mitarbeiter nur schwer erkennen, welche Services betroffen sind und wie sie ihre Aufgaben priorisieren sollen. Störende Warnmeldungen können zu Alarm-Fatigue beitragen.

Alarm-Fatigue

Alarm-Fatigue tritt auf, wenn Mitarbeiter durch die Menge oder Häufigkeit von Warnmeldungen überwältigt werden. Alarm-Fatigue führt häufig dazu, dass Reaktionen langsam erfolgen oder auch völlig ausbleiben, da die ständigen Warnungen von Mitarbeitern nicht mehr ernst genommen werden.

Ständig verfügbare Services

Ein Service, von dem erwartet wird, dass er kontinuierlich verfügbar ist.

Asset/Asset-Management

Komponenten eines Systems oder Netzwerks, das einen geschäftlichen Nutzen hat. Asset-Management bedeutet, dass ein Mitarbeiter oder Team eine Bestandsaufnahme dieser Komponenten durchführt, um die Auswirkungen eines Updates oder des Entfernens eines Systems zu verstehen.

Prüfung

Eine formale Prüfung der Verfügbarkeit und Nutzung eines Systems oder Prozesses sowie der Einhaltung von Richtlinien, Leitlinien und Best Practices.

Verfügbarkeit

Wenn ein Produkt oder System verfügbar ist und wie erwartet funktioniert. Wird auch als Systemverfügbarkeit bezeichnet.

Backout

Das Zurücksetzen eines Service auf einen früheren zuverlässigen Zustand oder eine Baseline. Dies ist in der Regel eine Schnellkorrektur, die angewendet wird, wenn durch ein Update oder einen Release ein Systemfehler auftritt.

Backup

Eine gespeicherte Kopie der Daten oder ein redundantes System für den Fall, dass das Original kompromittiert wird oder verloren geht.

Baseline

Ein Bezugspunkt für erwartetes Verhalten. Baselines helfen Teams bei der Messung von Änderungen und Verbesserungen.

Benchmark

Ein Bezugspunkt, der wie eine Baseline funktioniert, um den Fortschritt zu messen oder Ergebnisse zu vergleichen. Wenn in unserer Branche beispielsweise eine Verfügbarkeit von 99,99 % Standard ist, können wir uns damit mit der Konkurrenz vergleichen und erkennen, ob wir Kundenerwartungen erfüllen.

Bug

Ein unbeabsichtigtes Problem bei Software, Code, Programmen usw., das zu anormalem Verhalten oder einem Ausfall führen kann.

Business-Impact-Analyse (BIA)

Eine Business-Impact-Analyse (BIA) ist eine systematische Evaluierung der potenziellen Auswirkungen von Serviceunterbrechungen und Ausfällen aufgrund eines größeren Vorfalls. Mit der BIA soll ermittelt werden, welche Auswirkungen die einzelnen Services auf das Unternehmen haben und welche Anforderungen für die Wiederherstellung nach einem Vorfall gelten.

Kapazität

Die maximale Menge an Informationen, die zwischen Netzwerken übertragen oder über einen Service bereitgestellt werden kann. Die Überschreitung der Kapazität ist ein gängiger Indikator für Vorfälle.

Änderung

Jegliche Änderungen an einem IT-Service, einer Konfiguration, einem Netzwerk oder einem Prozess. Wird häufig im Rahmen des sogenannten Änderungsmanagements verfolgt.

Änderungsverlauf

Eine umfassende Aufzeichnung der Änderungen, die an einem IT-Service, einer Konfiguration, einem Netzwerk oder einem Prozess von Beginn des Lebenszyklus an bis zum aktuellen Zustand vorgenommen wurden.

Änderungsmanagement

Eine IT-Praktik, deren Schwerpunkt auf der Minimierung von Unterbrechungen während Änderungen/Aktualisierungen kritischer Systeme und Services liegt. Für manche Teams umfasst diese Praktik alle Aspekte von Änderungen – technische, personenbezogene und prozessorientierte. Für andere Teams liegt der Schwerpunkt des Änderungsmanagements – basierend auf den ITIL 4-Richtlinien – auf dem Management menschlicher oder kultureller Aspekte von Änderungen. Der Fokus einer weiteren Praktik namens Change Control liegt auf Risikobewertung, Zeitplänen und Änderungsgenehmigungen.

ChatOps

Die Verwendung von Chat- und Zusammenarbeitstools für das Vorfallmanagement. Von Sean Regan von Atlassian stammt folgende Erklärung:

"ChatOps ist ein Modell für die Zusammenarbeit, das Menschen, Tools, Prozesse und Automatisierung zu einem transparenten Workflow verbindet. Dieser bringt die benötigten, die laufenden und die erledigten Aufgaben in einer beständigen Umgebung zusammen, die mit Mitarbeitern, Bots und verwandten Tools ausgestattet ist."

Status "Geschlossen"

Ein Vorfall weist den Status "Geschlossen" auf, wenn alle erforderlichen Maßnahmen ergriffen wurden und ein Vorgang geschlossen wurde.

Cold Standby (schrittweise Wiederherstellung)

Ein Cold Standby wird verwendet, wenn ein System als Backup für ein anderes System fungiert. Wenn das Primärsystem ausfällt, ersetzt der Cold Standby das Primärsystem, während dieses repariert wird. Dies ist eine besonders nützliche Strategie, wenn der Ausfall des Primärsystems eine schrittweise Wiederherstellung erfordert (die mehrere Wochen dauern kann), weil Computerhardware ersetzt und eingerichtet werden muss.

Kaltstart

Ein Kaltstart liegt vor, wenn das Starten einer Anwendung, die gerade nicht ausgeführt wird, länger dauert als bei einer Anwendung, die "warm" ist, also bereits läuft.

Kommunikationsleiter

Das Teammitglied, das während eines Vorfalls für die Kommunikation zuständig ist.

Compliance

Abstimmung auf Vorschriften. Häufig werden Überwachungssysteme so programmiert, dass sie auf Compliance-Probleme überwachen und Warnungen auslösen, wenn ein System nicht mehr konform ist.

Analyse der Auswirkungen von Komponentenausfällen (Component failure impact analysis, CFIA)

Der Prozess zur Bestimmung der Auswirkungen auf einen Service, wenn eine Komponente oder Konfiguration nicht mehr wie erwartet funktioniert.

Parallelität

Das Maß dafür, wie viele gleiche Aktionen gleichzeitig in einem System ausgeführt werden. Zum Beispiel: Wie viele Benutzer greifen auf denselben Vorgang zu oder führen dieselbe Transaktion aus?

Kontrolle

Verfahren und Richtlinien, mit denen Risiken verwaltet, die erwartungsgemäße Funktionsweise eines Produkts oder Service sichergestellt und die Compliance gewahrt werden.

Kernservice

Ein Service, der eine zentrale Funktion für Benutzer/Kunden hat.

Gegenmaßnahme

Eine spezifische reaktive Aktion zum Schutz eines Systems oder zur Wiederherstellung des Betriebs.

Kundenorientierter Service

Services, die Kunden nutzen und mit denen sie interagieren.

Cynefin-Framework

Ein Konzept der Entscheidungsfindung, das an Vorfallmanagementprozesse angepasst wurde, um Managern dabei zu helfen, die effektivste Reaktion zu organisieren. Basierend auf der Komplexität eines Vorfalls unterteilt das Framework Situationen in fünf Kategorien. Jede Kategorie umfasst eigene (unterschiedliche) nächste Schritte.

Dashboard

Eine visuelle Darstellung von Systemen, Warnmeldungen und Vorfällen auf einem einzigen Bildschirm, mit der Informationen aus einer Vielzahl von Tools mit kontextbezogenen Informationen übersichtlich und präzise präsentiert werden sollen.

Abhängigkeit

Die Beziehung zwischen zwei Services, Prozessen oder Konfigurationen, die sich gegenseitig benötigen, um ordnungsgemäß zu funktionieren.

Kennzeichnung als veraltet

Liegt vor, wenn eine Funktion oder ein Tool außer Betrieb genommen, nicht mehr verwendet oder nicht mehr aktualisiert wird.

Diagnose

Der Prozess und das Ergebnis der Untersuchung eines Vorfalls und seiner Ursache.

Diagnostik

Die Symptome oder Anzeichen, die zu einer Vorfalldiagnose führen.

Ausfallzeit/Ausfall

Eine Zeit, in der ein Service nicht wie erwartet funktioniert oder verfügbar ist.

Notfalländerung

Ein Update oder Patch, das bzw. der – normalerweise im Rahmen der Behebung eines Vorfalls – schnell bereitgestellt wird. Bei Notfalländerungen werden Änderungsgenehmigungsprozesse häufig übersprungen, da das mit dem Warten auf Genehmigungen verbundene Risiko größer ist als das Risiko der Bereitstellung der Änderung.

Unterstützender Service

Ein Service, der für das Funktionieren eines Kernservice erforderlich ist, Kunden jedoch nicht direkt angeboten wird.

Testumgebung*

Die Infrastruktur, in der ein Service, eine Funktion, ein Prozess, ein Konfigurationselement usw. auf die erwartete Funktionalität getestet wird. Diese Umgebung wird streng kontrolliert, um die Produktion widerzuspiegeln.

Produktionsumgebung

Die Infrastruktur, in der ein Service für einen Kunden bereitgestellt wird. Da die Ergebnisse in dieser Umgebung live sind, wird sie manchmal auch als Live-Umgebung bezeichnet.

Fehler

Ein Fehler, der den Ausfall eines Konfigurationselements oder Service verursacht. Dabei kann es sich um einen Design- oder Verarbeitungsfehler oder um menschliches Versagen handeln.

Eskalation

Der Prozess der Verlagerung einer Vorfallmanagement-Zuweisung an ein Team oder eine Person mit relevanteren Fähigkeiten oder Erfahrungen. Von einer funktionellen Eskalation wird gesprochen, wenn eine Warnung oder ein Vorfall an eine Person oder ein Team mit mehr Fachwissen übertragen wird. Bei einer hierarchischen Eskalation wird die entsprechende Warnung oder der Vorfall von einer hierarchisch niedriger gestellten Person an eine höhergestellte Person übertragen.

Event

Eine relevante System- oder Servicesituation. Ereignisse werden normalerweise entweder durch Benutzeraktionen oder einen Vorfall verursacht.

Ausnahmebericht

Ein Bericht, der erstellt wird, wenn Key Performance Indicators (KPIs) die festgelegten Schwellenwerte überschreiten oder die Erwartungen nicht erfüllen.

Fehlertoleranz

Fehlertoleranz beschreibt die Fähigkeit eines Service, den Betrieb fortzusetzen, selbst wenn ein Konfigurationselement oder einzelnes Teil ausfällt.

Fehlerbaumanalyse

Eine Technik, mit der ermittelt wird, welche Ereignisse zu einem Vorfall geführt haben. Außerdem wird prognostiziert, welche Ereignisse zu künftigen Vorfällen führen könnten. Sie wird häufig eingesetzt, um die Ursache eines schwerwiegenden Vorfalls zu finden.

First-Line-Support

Die Person, von der erwartet wird, dass sie zuerst auf einen Vorfall reagiert. Dies ist normalerweise der Mitarbeiter im Bereitschaftsdienst.

Beheben

Eine Aktion oder Methode zur Fehlerkorrektur.

Sachanlage

Eine Sachanlage ist ein physischer, wertbehafteter, langfristiger Bestandteil des Unternehmens, z. B. ein Büro, ein Computer oder eine Lizenz.

Follow-the-Sun-Zeitplan

Eine Methode des Kundensupports oder des Vorfallmanagements, bei der Bereitschaftsdienste über Zeitzonen hinweg rotiert werden. Dadurch wird eine Abdeckung rund um die Uhr gewährleistet, ohne dass Teams nachts Bereitschaftsdienst leisten müssen.

Forensische Untersuchung

Eine wissenschaftliche, evidenzbasierte Untersuchung eines Computersystems zur Ermittlung der Ursache eines Vorfalls.

Funktional

Ein Service wird als "funktional" bezeichnet, wenn er erwartungsgemäß funktionieren kann.

Schrittweise Wiederherstellung

Eine schrittweise Wiederherstellung ist ein Wiederherstellungsprozess, der länger als gewöhnlich dauert (Wochen, nicht Stunden). In diesem Fall wird als Ersatz für das betroffene System normalerweise ein Cold Standby (Backup-System) online gestellt.

Hot Standby

Ein Hot Standby ist eine Wiederherstellungsoption, bei der redundante Assets gleichzeitig ausgeführt werden, um einen IT-Service bei einem Ausfall zu unterstützen. Wenn das aktive System ausfällt, läuft der Hot Standby bereits und kann den Betrieb übernehmen, ohne dass das Team aktiv werden muss und Ausfallzeiten auftreten. Dies wird auch als sofortige Wiederherstellung bezeichnet.

Hotfix

Ein Update, das auf Software angewendet wird, um ein Problem zu lösen oder einen Bug zu beheben. Es wird häufig verwendet, um ein vom Kunden gemeldetes Problem zu beheben.

Auswirkungen

Die Messung der Kosten, die durch eine Serviceunterbrechung, einen Vorfall oder eine Änderung verursacht werden und die Form von finanziellen und zeitlichen Verlusten sowie Rufschädigung annehmen können. Wird auch als Ausfallkosten bezeichnet.

Nicht umsetzbare Warnmeldung

Eine Warnmeldung, die es einer reagierenden Person nicht ermöglicht, Maßnahmen zu ergreifen. Dies liegt oft daran, dass die Warnmeldung keine Kontextinformationen enthält, an die falsche Person weitergeleitet wurde oder der Umfang unklar ist. Nicht umsetzbare Warnungen können zu Alarm-Fatigue beitragen.

Vorfall

Ein Ereignis, das zu einer Unterbrechung im Service oder zu einer Abnahme der Servicequalität führt und eine Notfallreaktion erfordert. Teams, die ITIL- oder ITSM-Verfahren nutzen, sprechen in diesem Fall möglicherweise von einem schwerwiegenden Vorfall.

Incident Response

Die Reaktion eines Teams auf einen Vorfall. Normalerweise ist die Incident Response ein vorab festgelegter Prozess mit Regeln, Rollen und Best Practices, die vor dem Auftreten eines Vorfalls definiert werden.

Vorfallmanagement

Der Prozess, den DevOps- und IT-Operations-Teams zur Reaktion auf ein ungeplantes Ereignis oder eine Serviceunterbrechung und zur Wiederherstellung des normalen Servicebetriebs befolgen.

Einsatzleiter

Der Einsatzleiter ist Mitglied der IT- oder DevOps-Teams, die für das Management der Incident Response verantwortlich sind. Diese Rolle leitet das Vorfallmanagementteam und hat die oberste Kontrolle und das letzte Wort bei allen Entscheidungen rund um Vorfälle. Die Rolle wird auch oft als Vorfallmanager bezeichnet.

Lebenszyklus eines Vorfalls

Die Dauer eines Vorfalls von der Erstellung und Erkennung bis zur Lösung.

E/A-Metriken

Eine Sammlung von Metriken zur Messung von Eingabe und Ausgabe. Zu den gängigen Metriken in dieser Kategorie zählen die E/A-Wartezeit (die Zeit, in der eine CPU auf eine E/A-Anfrage wartet) und IOPS (die Anzahl der E/A-Anfragen pro Sekunde).

Incident-Response-Orchestrierung

Eine Funktion von Opsgenie, mit der Teams Probleme schnell und effektiv identifizieren, die richtigen Personen benachrichtigen, die Kommunikation zwischen Geschäftseinheiten erleichtern und teamübergreifend für das Vorfallmanagement zusammenarbeiten können.

Vorfalldatensatz

Eine Aufzeichnung der Details und Prozesse, die während eines bestimmten Vorfalls verwendet wurden.

Vorfallverantwortlicher

Personen und/oder Teams, die für die Untersuchung und Lösung eines Vorfalls verantwortlich sind.

Stakeholder/Beobachter von Vorfällen

Personen, die bei einem Vorfall auf dem Laufenden gehalten werden müssen, da dieser Auswirkungen auf ihre Arbeit bzw. auf die Möglichkeit hat, ihre Arbeit zu erledigen. Diese Personen können Einfluss auf die Lösung von Vorfällen nehmen oder auch nicht, sind jedoch keine aktiv Reagierenden.

Zügige Wiederherstellung

Diese Art der Wiederherstellung, die auch als "Warm Standby" bezeichnet wird, dauert in der Regel 24 bis 72 Stunden. Normalerweise sind Datenwiederherstellungen und/oder Hardware- und Softwarekonfigurationen der Grund für die relativ lange Zeit bis zur Wiederherstellung.

Information Technology Infrastructure Library (ITIL)

Eine dokumentierte Reihe von allgemein akzeptierten Best Practices für IT-Services.

Information Technology Service Management (ITSM)

Alle Aspekte der Prozesse und Verfahren, die zur Bereitstellung eines IT-Service für Kunden erforderlich sind. Dies umfasst alle Aspekte des Servicelebenszyklus – vom Design über die Bereitstellung bis hin zum Vorfallmanagement.

Kepner-Tregoe-Methode (KT-Methode)

Eine Methode der Ursachenanalyse und Entscheidungsfindung, bei der Probleme getrennt von der endgültigen Entscheidung über ein Problem bewertet werden.

KPIs (Key Performance Indicators)

Erfolgsmessgrößen für Systeme oder Produkte. KPIs werden im Voraus festgelegt, regelmäßig verfolgt und generieren häufig Warnmeldungen, wenn sie von ihren erwarteten Schwellenwerten abweichen. Wenn zum Beispiel die Mean Time Between Failures (MTBF) (durchschnittliche Zeit zwischen Ausfällen) immer kürzer wird, kann eine Warnmeldung generiert werden, damit dein Team das Problem identifizieren und untersuchen kann.

Bekannter Fehler

Ein Problem, das schon früher vorhanden war und für das es schon einen Workaround gibt.

Latenz

Eine Verzögerung bei der Übertragung von Daten.

Protokolle

Die Aufzeichnungen aller Ereignisse im Zusammenhang mit einem Service oder einer Anwendung. Diese umfassen übertragene Daten, Zeit- und Datumsangaben, Vorfälle, Änderungen, Fehler usw.

Wartbarkeit

Das Maß dafür, wie einfach Änderungen auf einen Service oder eine Funktion angewendet werden können.

Manueller Workaround

Eine manuell implementierte Lösung (im Gegensatz zu einer automatisch implementierten Lösung).

Mean Time Between Failures (MTBF, mittlere Zeit zwischen Ausfällen)

Die durchschnittliche Zeit zwischen reparierbaren Ausfällen eines Technologieprodukts. Diese wird auch als Mean Time Between Service Incidents (MTBSI) bezeichnet.

Mean Time to Acknowledge (MTTA, mittlere Zeit bis zur Bestätigung)

Die durchschnittliche Zeitspanne zwischen dem Triggern einer Warnmeldung und dem Beginn der Arbeit an dem Vorgang.

Mean Time to Failure (MTTF, mittlere Zeit bis zum Ausfall)

Die durchschnittliche Zeit zwischen nicht reparierbaren Ausfällen eines Technologieprodukts.

Mean Time to Repair (MTTR, mittlere Reparaturzeit)

Die durchschnittliche Zeit für die Reparatur eines Systems (normalerweise technisch oder mechanisch). Dies beinhaltet sowohl die Reparaturzeit als auch die Testzeit.

Durchschnittliche Wiederherstellungszeit (MTTR)

Die durchschnittliche Dauer der Wiederherstellung nach einem Produkt- oder Systemausfall. Dies beinhaltet die gesamte Dauer des Ausfalls – vom Zeitpunkt des Ausfalls des Systems oder Produkts bis zu dem Zeitpunkt, an dem es wieder voll funktionsfähig ist.

Mean Time to Resolve (MTTR, mittlere Problemlösungszeit)

Die durchschnittliche Zeit, die benötigt wird, um einen Fehler vollständig zu beheben. Dazu zählt auch die Zeit, die aufgewendet wird, damit der Fehler nicht erneut auftritt.

Mean Time to Respond (MTTR, mittlere Reaktionszeit)

Die durchschnittliche Zeit, die zur vollständigen Behebung eines Produkt- oder Systemausfalls ab dem Zeitpunkt benötigt wird, an dem du erstmals auf diesen Fehler aufmerksam gemacht wirst. Verzögerungen bei deinem Warnsystem werden hierbei nicht berücksichtigt.

Modell/Modellierung

Eine Darstellung eines tatsächlichen Systems, eines Service, einer Anwendung usw.

Überwachung

Der wiederholte Prozess der Überprüfung eines Service oder Prozesses, um sicherzustellen, dass er wie erwartet funktioniert.

Normale Änderung

Eine Änderung, die keine Notfalländerung ist und für die es keinen definierten, vorab genehmigten Prozess gibt.

Bereitschaftsplan

Ein Zeitplan, der sicherstellt, dass Tag und Nacht immer die richtige Person verfügbar ist, um schnell auf Vorfälle und Ausfälle reagieren zu können. Bereitschaftspläne sind sowohl im Medizinbereich als auch in der Technologiebranche üblich.

Operations-Brücke

Der physische Ort, an dem die Überwachung der IT-Services erfolgt.

Operations Lead

Die Person, die für die Überwachung des täglichen Betriebs verantwortlich ist. In einigen Fällen kann diese Person auch der Vorfallmanager (oder der Einsatzleiter) sein, der für die Leitung der Vorfallbehebung verantwortlich ist.

Ergebnis

Das Ergebnis eines IT-bezogenen Ereignisses, Prozesses oder einer Änderung. Teams sprechen häufig sowohl von "erwarteten" und "tatsächlichen" Ergebnissen.

Schadenswertanalyse

Eine Analyse zur Ermittlung der geschäftlichen Auswirkungen eines Vorfalls. Dabei werden normalerweise die Kosten von Ausfällen, die Dauer eines Vorfalls, die Auswirkungen auf Benutzer und die Anzahl der betroffenen Benutzer berücksichtigt.

Passive Überwachung

Automatische (statt aktive oder manuelle) Überwachung der Servicefunktionalität.

Friedenszeit

Die Zeit, in der Services und Betriebsabläufe ohne Unterbrechung wie erwartet funktionieren.

Leistungsverschlechterungen

Ein Maß dafür, wie stark die Leistung eines Systems aufgrund eines Ereignisses oder Vorfalls abgenommen hat.

Geplante Ausfallzeiten

Der Zeitraum, in dem ein IT-Service für Wartungsarbeiten oder Updates absichtlich nicht verfügbar ist.

Playbook

Eine Sammlung von "Spielen"/Übungen oder spezifischen Aktionen, die ein Team durchführen kann, um ein bestimmtes Problem, einen Vorfall oder ein bestimmtes Ziel anzugehen.

Post-Mortem-Analyse/Analyse bzw. Rückblick nach dem Vorfall

Der Prozess des Nachvollziehens eines Vorfalls, nachdem er erledigt wurde. Das Ziel einer Post-Mortem-Analyse besteht darin, die Reaktionsprozesse zu verbessern, zukünftige Vorfälle zu verhindern und die Ursache des letzten Vorfalls zu verstehen.

Priority

Die Reihenfolge, in der Vorfälle bearbeitet werden sollten. Elemente mit hoher Priorität sind dringender als Aufgaben mit niedrigerer Priorität. Die Priorität wird durch Dringlichkeit, Schweregrad und potenzielle Auswirkungen auf das Unternehmen bestimmt.

Problem Record

Ein Problem Record ist ein Dokument, in dem jeder Aspekt eines Problems von der Erkennung bis zur Lösung erfasst wird.

Prognostizierter Serviceausfall

Ein Dokument, in dem beschrieben wird, wie sich zukünftige Wartungen oder Tests auf die normalen Service-Level auswirken.

Qualitätssicherung

Der Testprozess, mit dem sichergestellt wird, dass bei allem, was mit der IT zusammenhängt – von neuen Funktionen bis hin zu Anleitungen –, die geltenden Standards eingehalten werden.

Qualitätsmanagementsystem

Das vorhandene Framework oder die Systeme zur Qualitätssicherung.

Reaktive Überwachung

Überwachung, die als Reaktion auf ein Ereignis oder einen Vorfall durchgeführt wird.

Wiederherstellung

Der Prozess, bei dem ein Service auf seine Baseline-Funktionalität und seinen Normalzustand zurückgesetzt wird.

Recovery Point Objective

Der maximal zulässige Datenverlust während der Wiederherstellung.

Recovery Time Objective

Die maximale Zeitdauer, die für eine Betriebsunterbrechung toleriert wird.

Veröffentlichen

Eine Änderung, die für Benutzer bereitgestellt wird.

Release-Management

Die Planung, das Design, das Testen, die Zeitplanung, die Fehlerbehebung und das Deployment von Änderungen.

Stabilität

Die Fähigkeit eines Systems, bei einem Fehler nicht vollständig auszufallen und im Falle eines Vorfalls schnell wiederhergestellt zu werden.

Reaktionszeit

Die Zeit, die ab der Generierung einer Warnung verstreicht, bis das Team eine erste Aktion durchführt.

Risikobewertung

Die Ermittlung des mit einem Asset verbundenen Risikos durch Bewertung des Werts, der potenziellen Bedrohungen und der potenziellen Auswirkungen dieser Bedrohungen.

Risikomanagement

Der Prozess des Umgangs mit Bedrohungen, bei dem diese identifiziert und kontrolliert werden.

Grundlegende Ursache

Die grundlegende Ursache ist normalerweise der singuläre Grund für den Ausfall eines Service oder einer Anwendung. Häufig sind es jedoch viele miteinander verbundene Faktoren, die zu Ausfällen führen. Daher beginnen Teams darüber zu diskutieren, ob dieser Begriff im Vorfallmanagement hilfreich ist. Viele verwenden mittlerweile die Pluralform: grundlegende Ursachen.

Runbooks

Runbooks beinhalten detaillierte Verfahren für das Vorfallmanagement. Diese werden üblicherweise von einem Systemadministrator oder NOC-Team (Network Operations Control) verwaltet. Runbooks gibt es in digitaler oder gedruckter Form.

Umfang

Das Ausmaß eines Problems, einer Lösung, eines Projekts, einer Fähigkeit usw.

Second-Line-Support

Menschen mit zusätzlichen Fähigkeiten wie Zeit, Erfahrung, Wissen oder Ressourcen, um Probleme zu lösen, die möglicherweise über die Fähigkeiten der Erstbearbeiter hinausgehen.

Serviceänderung

Updates, Korrekturen, die Kennzeichnung als veraltet oder andere Änderungen an einem Service.

Servicedesk

Ein Team, das Kundensupportanfragen annimmt und als Kontaktstelle zwischen Kunden und IT fungiert.

Analyse von Serviceausfällen

Die Analyse von Serviceausfällen ist der Prozess der Überprüfung einer Serviceunterbrechung, um deren Ursache zu ermitteln.

Service Level Agreement (SLA)

Eine Vereinbarung zwischen Anbieter und Kunde über messbare Metriken wie Verfügbarkeit, Reaktionsfähigkeit und Zuständigkeiten.

Diagramm zur Überwachung des Service Level Agreements (SLAM)

Ein Dokument, in dem Fortschritte und Daten zu Service-Level-Zielen aufzeichnet werden.

Service Level Objective (SLO)

Eine Vereinbarung innerhalb eines Service Level Agreement (SLA) über eine bestimmte Metrik wie die Verfügbarkeit.

Schweregrade (SEV)

Zeigt, wie stark ein Service von einem Vorfall betroffen ist. Normalerweise verwenden Teams eine SEV-Struktur mit drei bis fünf Stufen, wobei 1 der höchste Schweregrad ist und Probleme mit Schweregrad 3 bis 5 weniger dringlich sind.

Single Point of Failure

Eine Variable, von der das Funktionieren eines Systems abhängt, beispielsweise ein wesentliches Konfigurationselement.

Spezifikation

Eine offizielle Aufzeichnung der Anforderungen an eine IT-bezogene Konfiguration.

Site Reliability Engineer (SRE)

Ein Softwareentwickler, der für den Betrieb zuständig ist. SREs sind in der Regel für die Automatisierung manueller Aufgaben, die Verwaltung von SLOs und das Vorfallmanagement verantwortlich.

Standardänderungen (Standard-Changes)

Mit geringem Risiko behaftete, häufig wiederholte, vorab genehmigte Änderungen, beispielsweise das Hinzufügen von Arbeitsspeicher oder Speicher.

Standby

Inaktive Ressourcen, die zur Unterstützung des Vorfallmanagements verfügbar sind.

Status

Der aktuelle Zustand eines Service.

Statusseite

Eine dedizierte Anlaufstelle für Mitteilungen zum aktuellen Zustand eines Service mit regelmäßigen Status-Updates zu Vorfällen.

Fachexperte (Subject Matter Expert, SME)

Eine Person mit spezifischen Kenntnissen zu einem bestimmten Vorgang, einem Service usw.

Technologieportfolio

Die Programmiersprachen, Software und Komponenten, aus denen eine Anwendung besteht. Es gibt zwei Seiten eines Technologie-Stacks: Front-End (Kundenseite) und Back-End (Entwicklerseite).

Spannungsmetriken

Daten, die sich bei einer Änderung eines Datensatzes oder Datenpunkts negativ auf andere Datenpunkte auswirken.

Schwellenwert

Eine vordefinierte Stufe oder Zahl, bei deren Überschreitung eine Warnmeldung generiert wird. Der Schwellenwert für das Laden der Anmeldeseite kann beispielsweise drei Sekunden betragen. Wenn das Laden der Seite länger dauert, wird eine Warnmeldung generiert.

Zeitlicher Ablauf

Eine umfassende, mit Zeitangaben versehene Liste von Ereignissen, Änderungen, Korrekturen und Ergebnissen im Zusammenhang mit einem Vorfall.

Trendanalyse

Eine Untersuchung von zeitbezogenen Mustern. Bei der Trendanalyse wird davon ausgegangen, dass anhand vergangener Muster zukünftige Muster in den Daten vorhergesagt werden können. Sie spielt daher eine wichtige Rolle bei der Vermeidung künftiger Vorfälle.

Umgehungslösung

Eine erfolgreiche Methode zur Implementierung einer Schnellkorrektur, die die Systemfunktionalität wiederherstellt, selbst wenn der zugrunde liegende Vorfall noch nicht erledigt ist.

Workload

Die (menschlichen und technischen) Ressourcen, die zur Bereitstellung eines IT-Service benötigt werden .