SP8: Gewährleisten von Kontinuität
Prozessname: Vorbereiten auf Katastrophen-Ereignisse - Teil von: Unterstützende Prozesse
Vorhergehender Prozess: Gewährleisten der Sicherheit
Nächster Prozess: Sicherstellen von Compliance
Prozess-Beschreibung
Der Katastrophenvorsorge-Prozess in YaSM dient zur Sicherstellung der Service-Kontinuität ('Service Continuity') im Fall von Ereignissen, die als Katastrophen eingestuft werden, wie z.B. Überschwemmungen, Feuer, Stromausfall usw.
Die Vorbereitung auf Katastrophen-Ereignisse beginnt mit der Erstellung eines Registers der gemanagten Katastrophen-Ereignisse. In diesem Register sind die Arten von Katastrophen aufgelistet, für die der Service-Provider beschlossen hat, Vorbereitungsmaßnahmen zu treffen. Das Register spezifiziert außerdem, was zur Vorbereitung auf diese Ereignisse im Einzelnen unternommen werden muss; insbesondere verweist es auf die entsprechenden Service-Kontinuitäts-Pläne.
Der Kontinuitäts-Manager verfügt über eine Reihe von Möglichkeiten, Service-Kontinuität sicherzustellen. Die wichtigste hierbei ist, dass diese Rolle bereits in die Service-Design- und Service-Erstellungs-Prozesse einbezogen ist, um zu gewährleisten, dass Kontinuitätsaspekte bei der Erstellung oder Aktualisierung von Services berücksichtigt werden. Sobald im Verlauf der Design-Phase eines Service feststeht, welche Kontinuitätsvorkehrungen und -mechanismen für einen neuen Service erforderlich sind, können diese eingerichtet werden, und zwar
- über den Prozess "Erstellen von Services" durch Hinzufügen geeigneter Kontinuitätsmerkmale zur Service-Infrastruktur, die errichtet werden soll
- sowie über den Prozess "Vorbereiten auf Katastrophen-Ereignisse" durch Aktualisierung der Kontinuitätsvorkehrungen und -mechanismen, die in der Verantwortung des Service-Kontinuitäts-Managers betrieben werden.
Sofern Service-Kontinuitätsaspekte eine Rolle spielen, ist der Service-Kontinuitäts-Manager auch in die Service- oder Prozess-Verbesserungsinitiativen mit einbezogen.
Sollen neue Arten von Katastrophen berücksichtigt werden oder sind die Kontinuitätsvorkehrungen aus anderen Gründen zu verbessern, kann der Prozess "Vorbereiten auf Katastrophen-Ereignisse" selbstständig Kontinuitätsverbesserungs-Initiativen anstoßen. Solche Initiativen werden über den Kontinuitätsverbesserungs-Plan verwaltet.
Sub-Prozesse
YaSM's Katastrophenvorsorge-Prozess beinhaltet die folgenden Sub-Prozesse:
- SP8.1: Bewerten von Risiken aus Katastrophen-Ereignissen
- Prozessziel: Bestimmen der Katastrophen-Ereignisse, die vom Service-Provider gemanagt werden müssen, und Definieren geeigneter Kontinuitäts-Vorkehrungen und -Mechanismen.
- SP8.2: Definieren von Kontinuitäts-Verbesserungen
- Prozessziel: Definieren der Ziele von Initiativen zur Verbesserung der Service-Kontinuität und des Vorgehens zu deren Implementierung. Dies beinhaltet auch die Erstellung von Kosten-/ Nutzen-Analysen für die Initiativen.
- SP8.3: Starten von Kontinuitäts-Verbesserungs-Initiativen
- Prozessziel: Starten von Initiativen zur Sicherstellung bzw. Verbesserung der Service-Kontinuität. Dies beinhaltet auch das Einholen der Genehmigung durch Beantragung eines Budgets und Einreichen eines Requests for Change.
- SP8.4: Implementieren von Kontinuitäts-Vorkehrungen
- Prozessziel: Implementieren, Testen und Ausrollen von neuen oder verbesserten Kontinuitäts-Vorkehrungen und -Mechanismen.
- SP8.5: Betreiben der Kontinuitäts-Vorkehrungen
- Prozessziel: Durchführen geeigneter Schulungen zur Vorbereitung der Mitarbeiter und Kunden des Service-Providers auf Katastrophenfälle. Sicherstellen, dass die Kontinuitäts-Vorkehrungen und -Mechanismen regelmäßig gewartet und getestet werden.
- SP8.6: Überprüfen der Kontinuitäts-Vorkehrungen
- Prozessziel: Die Kontinuitäts-Vorkehrungen und -Mechanismen regelmäßigen Reviews zu unterwerfen, um Verbesserungspotentiale zu identifizieren, die mit Kontinuitäts-Verbesserungs-Initiativen adressiert werden sollen.
Prozess-Outputs
Die folgenden Dokumente und Records werden vom Prozess zur Katastrophen-Vorsorge ('Service-Continuity-Management') erzeugt. YaSM-Datenobjekte [*] sind mit einem Sternsymbol markiert, und andere Objekte werden in grau dargestellt.
- Anforderung zur Bewertung der Compliance-Auswirkungen
- Ist-Daten zu Projekt-Fortschritt und Ressourcen-Verbrauch, die von unterschiedlichen Service-Management-Prozessen an den Projektmanager übermittelt werden. Diese Daten sind ein Input für das Projekt-Controlling.
- Aktualisierungs-Daten für den Projektplan
- Ist-Daten zu Projekt-Fortschritt und Ressourcen-Verbrauch, die von unterschiedlichen Service-Management-Prozessen an den Projektmanager übermittelt werden. Diese Daten sind ein Input für das Projekt-Controlling.
- Anforderung zur Bewertung von Sicherheits-Risiken
- Eine Anforderung zur Bewertung von Sicherheits-Risiken; diese wird typischerweise während des Service-Designs erteilt, falls evtl. neue oder geänderte Sicherheits-Regelungen und -Mechanismen für einen neuen oder verbesserten Service benötigt werden.
- Bericht zum Kontinuitäts-Review
- Ein Bericht zum Kontinuitäts-Review zeichnet die Details und Ergebnisse eines Kontinuitäts-Reviews auf. Dieser Bericht ist eine wichtige Grundlage für die Definition von Initiativen zur Verbesserung der Service-Kontinuität. [*]
- Beschaffungs-Anforderung
- Eine Anforderung zur Beschaffung von Gütern von einem externen Lieferanten. Beschaffungs-Anforderungen werden typischerweise an den Supplier-Manager gerichtet, wenn z.B. Anwendungen, Systeme oder andere Infrastruktur-Komponenten für die Erstellung eines neuen Service notwendig sind, oder wenn Standard-Infrastruktur-Komponenten oder Verbrauchsgüter für den Service-Betrieb benötigt werden.
- Budget-Anforderung
- Eine Budget-Anforderung wird typischerweise erstellt, um finanzielle Mittel für das Erstellen, Verbessern oder Betreiben eines Service oder Prozesses zu erhalten. Eine genehmigte Budget-Anforderung bedeutet, dass die finanziellen Ressourcen vom Finanz-Manager zugeteilt wurden. [*]
- Change Record
- In einem Change Record sind alle Einzelheiten eines Changes enthalten; er dokumentiert somit den Lebenszyklus eines einzelnen Changes. Zu Beginn beschreibt ein Change Record einen Change-Antrag (Request for Change, RFC), der vor der Implementierung des Changes zu bewerten und freizugeben ist. Weitere Informationen werden im Verlauf des Changes hinzugefügt. [*]
- CI Record
- Konfigurations-Information wird für alle Konfigurations-Elemente (Configuration Items, CIs) in CI Records gepflegt, die unter der Kontrolle des Konfigurations-Managers stehen. In diesem Zusammenhang gibt es unterschiedliche Typen von CIs: Anwendungen, Systeme und andere Infrastruktur-Komponenten werden als CIs behandelt, aber oft auch Services, Richtlinien, Projektdokumente, Mitarbeiter, Lieferanten usw. Konfigurations-Informationen sind im Konfigurations-Management-System (Configuration Management System, CMS) verzeichnet. [*]
- Index der Informationen für Katastrophenfälle
- Ein Katalog mit allen Informationen, die im Zusammenhang mit der Bekämpfung von Katastrophenfällen relevant sind. Der Index der Informationen für Katastrophenfälle wird vom Service-Kontinuitäts-Manager gepflegt und an alle Mitarbeiter verteilt, die für das Bekämpfen von Katastrophen verantwortlich sind. [*]
- Informationen zum Change-Status
- Aktuelle Status-Informationen zur Implementierung eines Changes. Diese Informationen werden dem Change-Manager von den verschiedenen Prozessen zur Verfügung gestellt, die freigegebene Changes implementieren. Der Change-Manager wird so in die Lage versetzt, die Change Records und die Change-Planung aktuell zu halten.
- Kontinuitäts-Betriebshandbuch
- Das Kontinuitäts-Betriebshandbuch spezifiziert die in der Verantwortung des Service-Kontinuitäts-Managers liegenden Aktivitäten, die für den Betrieb der Kontinuitäts-Vorkehrungen und -Mechanismen erforderlich sind. Einige Anweisungen für den Betrieb bestimmter Sicherheits-Systeme können in separaten technischen Handbüchern oder Standardarbeitsanweisungen ('Standard Operating Procedures, SOP') dokumentiert werden. [*]
- Kontinuitäts-Verbesserungs-Plan
- Einträge im Kontinuitäts-Verbesserungs-Plan (Continuity Improvement Plan) dienen dem Service-Kontinuitäts-Manager zur Erfassung und dem Management von Kontinuitäts-Verbesserungs-Initiativen über ihren gesamten Lebenszyklus. Initiativen im Kontinuitäts-Verbesserungs-Plan können die Ausfallsicherheit von Services erhöhen oder Mechanismen einrichten, mit denen die Services im Katastrophenfall wieder hergestellt werden können. [*]
- Leitfaden für Katastrophenfälle
- Der Leitfaden für Katastrophenfälle enthält detaillierte Anweisungen, wann und wie das Verfahren zur Bekämpfung von Katastrophenereignissen eingeleitet wird. Insbesondere legt die Richtlinie die ersten Schritte fest, die der 1st Level Support nach Bekanntwerden eines (vermuteten) Katastrophen-Ereignisses zu ergreifen hat. [*]
- Register gemanagter Katastrophen-Ereignisse
- Das Register der gemanagten Katastrophen-Ereignisse ist ein vom Service-Kontinuitäts-Manager genutztes Tool, das eine Übersicht über die Katastrophen-Ereignissen bietet, gegen die der Service-Provider sich auf irgendeine Weise zu schützen beschlossen hat, ausgehend von der Betrachtung potentieller Schäden und Eintrittswahrscheinlichkeiten. Das Register der gemanagten Katastrophen-Ereignisse spezifiziert auch, wie die identifizierten Ereignisse behandelt werden; insbesondere nennt es die relevanten Service-Kontinuitäts-Pläne. [*]
- Service-Kontinuitäts-Plan
- Ein Service-Kontinuitäts-Plan beschreibt, wie Service-Kontinuität bei einer bestimmten Art von Katastrophenfall erreicht wird. Der Plan spezifiziert die erforderlichen vorbereitenden Maßnahmen und beschreibt, wie im Katastrophenfall effektiv reagiert werden kann. Service-Kontinuitäts-Pläne enthalten gewöhnlich Verweise auf spezielle Wiederherstellungs-Pläne (Recovery-Pläne) mit genauen Anleitungen zur Wiederherstellung von Anwendungen, Systemen und anderen Infrastruktur-Komponenten. [*]
- Testprotokoll
- Ein Testprotokoll stellt einen detaillierten Bericht zu Testaktivitäten bereit. Ein solches Protokoll wird z.B. während der Tests neuer oder geänderter Service-Komponenten erstellt, oder während der Tests von Sicherheits- oder Service-Kontinuitäts-Mechanismen. [*]
- Testskript
- Ein Testskript bzw. Testdrehbuch spezifiziert einen Satz von Testfällen einschließlich der erwarteten Ergebnisse. Die Art der Testfälle hängt davon ab, was zu testen ist. [*]
- Vorschlag zur Kontinuitäts-Verbesserung
- Ein Vorschlag zur Verbesserung der Service-Kontinuität. Solche Vorschläge können an jeder Stelle innerhalb der Organisation entstehen.
- Vorschlag zur Prozess-Änderung
- Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.
- Vorschlag zur Service-Änderung
- Ein Vorschlag zur Änderung eines Service, z.B. zur Verbesserung der Qualität oder Wirtschaftlichkeit des Services. Solche Vorschläge können an jeder Stelle innerhalb oder außerhalb der Service-Provider-Organisation entstehen.
- Wiederherstellungs-Plan
- Wiederherstellungspläne (Recovery-Pläne) enthalten genaue Anweisungen zu den Maßnahmen, mit denen bestimmte Services und/ oder Systeme nach einem Ausfall wieder hergestellt werden können, was in vielen Fällen auch die Wiederherstellung von Daten zu einem definierten, konsistenten Stand mit einschließt. [*]
Anmerkungen:
[*] "YaSM-Datenobjekte" sind Dokumente und Records, für die YaSM detaillierte Empfehlungen bereithält: Für jedes YaSM-Objekt gibt es eine Checkliste (siehe Beispiel), die die typischen Inhalte beschreibt, und ein Lifecycle-Diagramm, das darstellt, wie sich der Zustand des Objekts ändert, während es von verschiedenen YaSM-Prozessen erstellt, geändert, gelesen und archiviert wird (siehe Beispiel).
"Andere Objekte" sind eher informelle Daten oder Informationen. Es gibt aus diesem Grund keine zugehörigen Lifecycle-Diagramme oder Checklisten.
Prozess-Kennzahlen
Prozesskennzahlen werden benötigt, wenn gemessen werden soll, ob die Service-Management-Prozesse "zufriedenstellend" laufen.
Vorschläge zu geeigneten Prozess-Kennzahlen entnehmen Sie der Liste von Kennzahlen zum Prozess zur Katastrophenvorsorge.
Rollen und Verantwortlichkeiten
Prozess-Owner: Service-Kontinuitäts-Manager
- Der Service-Kontinuitäts-Manager ist verantwortlich für das Managen solcher Risiken, die gravierende Auswirkungen auf die vom Service-Provider erbrachten Services haben können. Insbesondere stellt diese Rolle sicher, dass der Service-Provider in Katastrophenfällen die vereinbarten Minimalanforderungen bereitstellen kann.
| YaSM-Rolle / Sub-Prozess | Compli.-Mgr. | Oper. | Proz.-Owner | Secur. mgr. | Serv.-Kontin.-Mgr. | Serv.-Owner | Techn.- Fachexp. | |
|---|---|---|---|---|---|---|---|---|
| SP8.1 | Bewerten von Risiken aus Katastrophen-Ereignissen | - | - | R | - | AR | R | - |
| SP8.2 | Definieren von Kontinuitäts-Verbesserungen | R | - | - | R | AR | - | - |
| SP8.3 | Starten von Kontinuitäts-Verbesserungs-Initiativen | - | - | - | - | AR | - | - |
| SP8.4 | Implementieren von Kontinuitäts-Vorkehrungen | - | R | - | - | AR | - | R |
| SP8.5 | Betreiben der Kontinuitäts-Vorkehrungen | - | R | - | - | AR | - | - |
| SP8.6 | Überprüfen der Kontinuitäts-Vorkehrungen | - | - | - | - | AR | - | - |
Anmerkungen
Basiert auf: Der Prozess zur Katastrophenvorsorge aus der YaSM-Prozesslandkarte.
Von: Stefan Kempter 
und Andrea Kempter , IT Process Maps.
Prozess-Beschreibung › Sub-Prozesse › Prozess-Outputs › Kennzahlen › Rollen
