ITIL - Availability & Continuity-Management · PDF fileSeminararbeit Healthcare-Seminar ITIL - Availability & Continuity-Management Bereich: praktische Informatik Lehrstuhl: I4 - LuFG

Seminararbeit

Healthcare-Seminar

ITIL - Availability & Continuity-Management

Bereich: praktische InformatikLehrstuhl: I4 - LuFG - Verläßliche Verteilte SystemeProfessor: Dr. Felix FreilingBetreuer: Dipl.-Inform. A. Blum

Semester: WS 2004/2005

Autor: Marko Ritter (229629)Heinrichsallee 3052062 Aachen

Seite 1 von 25 Marko Ritter

Inhaltsverzeichnis1. Einführung.............................................................................................................................32. Einfügung in ITIL.................................................................................................................43. Notwendigkeit von Availability-Management....................................................................54. Availability-Management..................................................................................................... 7

a. Aufgaben des Availability-Managements...........................................................................7b. Kenngrößen und Begriffe................................................................................................... 9c. Der Availability-Management-Prozess.............................................................................11d. Availability-Management in einem Unternehmen........................................................... 12

5. Unterscheidung Availability- / Continuity-Management................................................156. Notwendigkeit von Continuity-Management................................................................... 167. Business-Continuity-Management.................................................................................... 17

a. Aufgaben des IT-Service-Continuity-Managements........................................................ 18b. ITIL Optionen bei der Planung.........................................................................................18c. Der Continuity-Management-Prozess...............................................................................19d. Beispiel eines Continuity-Plans........................................................................................21

8. Zusammenfassung...............................................................................................................249. Literaturverzeichnis............................................................................................................25


1. Einführung

1. EinführungDiese Arbeit hat das Ziel eine Einführung in das Availability-Management (Verfügbarkeits-Management) und das Continuity-Management (Sicherstellung eines fortlaufenden Betriebs), zwei Bereiche des ITIL (IT Infrastructure Library®), zu bieten. In Kapitel 2 wird erläutert wie sich die beiden Bereiche in die gesamte ITIL Welt eingliedern. Anschließend wird in Kapitel 3 die Notwendigkeit von Availability-Management erläutert. Darauf folgt in Kapitel 4 die Beschreibung des Availability-Management. In Kapitel 5 wird eine Abgrenzung der Themengebiete vorgenommen. Analog zu Kapitel 3 und 4 folgt die Notwendigkeit von Continuity-Management in Kapitel 6 und die Beschreibung von Continuity-Management in Kapitel 7.

Anmerkung zur Schreibweise"In ITIL werden zahlreiche zusammengesetzte englische und eingedeutschte Begriffe eingeführt und definiert. Leider gibt es in der Literatur keine einheitliche Schreibweise." [vgl. Sommer, 2004, S.11]

Hier wird durchgängig die Schreibweise mit Bindestrichen verwendet.


2. Einfügung in ITIL

2. Einfügung in ITILDiese Arbeit setzt einen Grundeinblick in ITIL sowie den ITIL-Servicedesk voraus. Hier erneut detailiert auf diese Bereiche einzugehen würde den Rahmen der Arbeit sprengen.Man kann die ITIL grob in zwei Bereiche gliedern: den Service-Support und den Service-Delivery. In den Bereich des Service-Support fallen die Aufgaben des tagtäglichen Geschäfts, die Aufgaben im Service-Delivery-Bereich sind von eher längerfristigem, planendem Charakter.

Das Availability- sowie das Continuity-Management fallen in den Bereich des Service-Delivery. Zusammen mit dem Service-Level-Management, Finance-Management und Capacity-Management übernehmen sie die strategische Planung und Steuerung der IT-Organisation.Es existieren vom und zum Availability- und Continuity-Management diverse Kontaktstellen zu Bereichen des Service-Deliverys und des Service-Supports. Wie diese im Einzelnen aussehen wird in den folgenden Kapiteln ersichtlich.


3. Notwendigkeit von Availability-Management

3. Notwendigkeit von Availability-ManagementEine Statistik [aus Sommer, 2004, S.119] zeigt die Hauptgründe für Computerausfälle. Computersysteme hängen von drei wichtigen Faktoren ab, vom Betriebssystem, von der Hardware und von den Softwaretools. Fällt eine dieser Komponenten aus, so auch das gesamte System. Daher ist bei der Planung gleichermaßen auf alle drei einzugehen. Wenn man sich nur auf einen dieser drei Punkte konzentriert und dessen Verfügbarkeit optimiert, bieten die anderen beiden Punkte immer noch Ausfallgefahren für das gesamte System. Deshalb darf z.B. nicht davon ausgegangen werden, dass ein hochverfügbares System geschaffen wurde, wenn mit Windows2000 ein Stripe Set mit Spare Disks konfiguriert wurde (kleines Software RAID), da die Hardware und die Softwaretools noch in keiner Form redundant abgesichert wurden.Bei naiver Herangehensweise an das Thema Computerabstürze könnte der Gedanke entstehen, dass der Hauptgrund für einen Absturz bei Hardwareproblemen liegt (z.B. Headcrash der Festplatte, etc.).

Abbildung 1 vgl. Sommer, 2004, S.119

Wie Abbildung 1 zeigt sind Hardwareprobleme zwar der Hauptgrund, der Anteil an den Ausfällen insgesamt beträgt aber nur 39%. Die restlichen 61% werden häufig vernachlässigt. Mit einem Anteil von 31% ist die nächst häufigste Ursache ein Softwarefehler, wobei 62% davon durch das Betriebssystem verursacht werden. Bei den Hardwarefehlern sind die häufigsten Ausfallgründe Plattenspeicher (ca. 51%) und RAM-Fehler (ca. 23%). Es wird anhand dieser Darstellung deutlich, dass durch redundante Systeme für Platten (z.B. SCSI-RAID Systeme) oder für den Speicher (ECC-RAM) die Auswirkung dieser Fehler drastisch eingeschränkt werden kann.


Hardware-Fehler 39,00%

Sof tware-Fehler 31,00%

Externe Quellen 12,00%

Bedienerf ehler 18,00%

Computerabstürze

3. Notwendigkeit von Availability-Management

Gegen externe Fehlerquellen, z.B. Stromausfälle oder Wasserschäden, kann auf Grund der Größe des Ausmaßes, den solche Katastrophen in der Regel haben, nur mit Redundanz auf größerer Ebene vorgegangen werden. Es bieten sich hierfür zum Beispiel Notstromaggregate oder Standby-Locations (z.B. in anderen Rechenzentren) an. Für die restlichen 18%, die aus menschlichen Bedienungsfehler resultieren, gibt es noch kein Allheilmittel, allerdings können viele kritische Schritte automatisiert und dadurch auch diese Gefahr deutlich eingeschränkt werden. [Zu diesem Beispiel vgl. Sommer, 2004, S.119.]


4. Availability-Management

4. Availability-ManagementIm Rahmen von ITIL sind Services, oder auch Dienste genannt, bestimmte Leistungen oder Leistungspakete, die von einem Unternehmen, dem Service-Anbieter, für den jeweiligen Kunden bereitgestellt werden. Das Availability-Management hat die Aufgabe, die Verfügbarkeit von Services sicherzustellen bzw. zu verbessern. Die verfügbaren Services sollen optimal genutzt und mögliche Ausfälle, z.B. auf Grund von Wartungsarbeiten, sollen vorhergesehen und sinnvoll geplant werden.Service-Level-Agreements (SLAs) sind Vereinbarungen zwischen verschiedenen Parteien, die auf Managementebene getroffen werden und von Zeit zu Zeit neu verhandelt werden. So kann es unternehmensinterne SLAs wie auch SLAs zwischen zwei Unternehmen geben. Die bestehenden Service-Level-Agreements haben direkten Einfluss auf das Availability-Management, da diese die aktuellen Anforderungen an die Services formulieren. Andersherum sind die Manager bei Neuverhandlungen der Service-Level-Agreements auf die Vorgaben des Availability-Managements angewiesen, da es z.B. die Aufgabe hat die Verfügbarkeitslevel zu standardisieren. Verfügbarkeitslevel sind frei definierbar und sollen die Einstufung der Services in verschiedene Prioritäten ermöglichen. Diese vom Availability-Management standardisierten Verfügbarkeitslevel können dann bei Verhandlungen dem Kunden im Servicekatalog angeboten werden.

Es ist demnach die Hauptaufgabe des Availability-Managements dafür zu sorgen, dass ein festgelegter Verfügbarkeitslevel zu möglichst geringen Kosten erreicht wird.

a. Aufgaben des Availability-Managements

Availability (Verfügbarkeit)Die Verfügbarkeit von Services muss sichergestellt werden, damit die Kunden im Rahmen ihrer Service-Level-Agreements Zugriff auf ihre bestellten Services haben. Bevor eine realisierbare Verfügbarkeit dem Kunden angeboten werden kann muss sie zuerst geplant werden. Es werden Verfügbarkeit-Standards gesetzt, die dann dem Kunden bei Verhandlungen angeboten werden können.Das Availability-Managements macht einen Wechsel der Betrachtungsweise weg von der komponentenbasierten Verfügbarkeit hin zu einer servicebasierten Verfügbarkeit. Das Denken soll sich von Raid-Arrays und USVs hin zu z.B. verfügbarem Webspace und Datenbanken entwickeln. Hat ein Kunde oder das eigene Unternehmen besondere Anforderungen an die Verfügbarkeit für bestimmte Services, so ist es auch hier wieder die Aufgabe des Availability-Managements dafür zu sorgen, dass diese implementiert und eingehalten werden.

Messung der VerfügbarkeitFür die Bewertung des Erfolges des Availability-Managements spielt die Messung der Verfügbarkeit der einzelnen Services eine wichtige Rolle. Sonst könnte keine sinnvolle Bewertung der Verfügbarkeits-Zustände stattfinden.

Reliability (Zuverlässigkeit)Noch wichtiger als die bloße Bewertung und Messung der Verfügbarkeit ist die Steuerung der Reliability. Dazu gehört sowohl die Vermeidung von Service-Ausfällen, als auch das



Management der Wartung von IT-Komponenten (vgl. Maintainability).Es ist die Aufgabe des Availability-Managements dafür zu sorgen, dass die Services störungsfrei zur Verfügung stehen. Es müssen alle möglichen Ausfallzeiten kalkuliert werden und redundante Technologien implementiert werden.

Serviceability (Servicefähigkeit)Bei Vertragsverhandlungen mit externen Dienstleistern muss das Availability-Management die Pflichten der Dienstleister genau kalkulieren und definieren.Zur späteren Erhaltung der Servicefähigkeit muss auch die Dienstleistung von Lieferanten und Support-Partnern bemessen und beurteilt werden. Dies ist ein Bereich, der durch das ständige Outsourcing immer größer und wichtiger werden dürfte.

Maintainability (Wartungsfähigkeit)Bei der Neuimplementierung von Services muss darauf geachtet werden, dass sich die jeweiligen Bestandteile leicht und zuverlässig warten lassen, und möglichst keine großen Ausfallzeiten und Kosten dadurch entstehen.Die Maintainability beschreibt die Fähigkeit einer Komponente, nach einem Ausfall wieder in Stand gesetzt zu werden. Die hierfür benötigte Zeit ist ebenfalls ein zu berücksichtigender Faktor (Recoverability [vgl. http://www.itil-itsm-world.com/itil-9.htm]).

Das Availability-Management übernimmt auch die Aufgabe einer ständigen Service-Verbesserung. Einsatz-Szenarien für neue Technologien müssen hierzu auch berücksichtigt und eingebracht werden.Das Availability-Management muss nicht nur auf bestehende Fehler reagieren, sondern proaktiv bzw. präventiv optimale Bedingungen schaffen.

Außerdem hat das Availability-Management die Aufgabe, die Wartung aller IT-Komponenten zu planen um anfallende Wartungsausfälle möglichst kurz und zeitlich optimal platziert stattfinden zu lassen. Es ist z.B. nicht sinnvoll die Wartungsarbeiten in die Hauptgeschäftszeiten zu legen.

Security (Sicherheit)Ein sehr wichtiger Faktor für den Erfolg des Availability-Managements ist die Integration von IT-Security Prozessen. Gemeint sind Systemverbesserungen die die Sicherheit vor Angriffen auf ein System erhöhen sollen. Beispielhaft wären hier Firewalls, Passwortvalidierungen und Systemupdates zu nennen. Heute mehr denn je ist effektiver Schutz vor Crackern und allen Arten von Viren notwendig. Ohne diesen würde das beste, hochverfügbare High-End System nicht mehr seinen eigentlichen Zweck erfüllen.

Anders ausgedrückt ist es also auch Aufgabe des Availability-Managements die Vertraulichkeit, die Integrität und (erneut) die Verfügbarkeit aller betroffenen Daten zu wahren. Vgl. zu diesem Kapitel [http://www.hisolutions.com/19874/level2/Availability_&_Capacity.htm]



b. Kenngrößen und BegriffeEs folgt eine kurze Einführung zu Kenngrößen und Begriffen, die für das Availability-Management von Bedeutung sind.

VerfügbarkeitDie Verfügbarkeit eines Services ist in der Regel als Anteil eines Servicezeitraums in Prozent angegeben. Die Definition lautet wie folgt:

Verfügbarkeit=Gesamtbetriebszeit−DowntimeGesamtbetriebszeit

⋅100%

Als Downtime wird die Zeit bezeichnet, die ein Service, sei es beabsichtigt oder unbeabsichtigt, während seiner Betriebsbereitschaft nicht zur Verfügung steht. Die Betriebsbereitschaft, die für einen Service gilt, wird im Allgemeinen durch die Zeitformel Stunden*Tage*Wochen angegeben. Sie bezieht sich üblicherweise auf den Zeitraum von einem Jahr. Demzufolge soll ein Service mit der Zeitformel 24*7*52 rund um die Uhr zur Verfügung stehen.Ist eine minimale zugesagte Verfügbarkeit und die Zeitformel gegeben, lässt sich die maximale Zeit, die ein Service dann nicht zur Verfügung stehen muss (maximale Downtime), leicht errechnen.

Hier einige Beispiele:Die Beispiele zeigen welchen Minimale Uptime bzw. Maximale Downtime ein Service pro Jahr und je nach Verfügbarkeitslevel (in Prozent) haben muss bzw. darf. Je nach Art des Service (24*7*52, ...) gestalten sich die Ergebnisse sehr unterschiedlich.

Verfügbarkeit in % Minimale Uptime (h:m) Maximale Downtime (h:m)99 8648:38 87:2299,9 8727:15 8:4599,99 8735:08 0:5299,999 8735:55 0:05

Tabelle 1: Betriebsbereitschaft eine 24*7*52-Service [vgl. Sommer, 2004, S.117]

Verfügbarkeit in % Minimale Uptime (h) Maximale Downtime (h) Rest (h)99 3706:34 37:26 499299,99 3743:38 0:22 4992

Tabelle 2: Betriebsbereitschaft eine 12*6*52-Service [vgl. Sommer, 2004, S.117]

Mean (Operating) Time Between FailuresDie Mean (Operation) Time Between Failures (MTBF) ist ein Maß für die durchschnittliche Zeit zwischen 2 Fehlern einer Komponente. Sie berechnet sich aus der gesamten Betriebszeit und der Menge aller Fehler in dieser.



MTBF=Gesamtbetriebszeit

Gesamtzahl der Fehler=

1 mit λ: Fehlerrate

Ein Service, der aus mehreren Komponenten zusammengesetzt ist, hat fast immer eine niedrigere MTBF als die einzelnen Komponenten, da die Fehler in den Subsystemen häufig auch zu einem Fehler im Hauptsystem führen.

Beispiel: [vgl. Sommer, 2004, S.118]

Eine Festplatte hat eine MTBF von 250.000 Stunden. Ein Array mit 50 Festplatte des gleichen Typs hat nur noch eine MTBF von 5.000 Stunden (250.000 geteilt durch 50). Außerdem kommen noch die MTBF der Stromversorgungen und Festplattencontroller hinzu.Man kann mit der MTBF also nur eine zuverlässige Aussage über ein System treffen, wenn alle Komponenten berücksichtigt wurden.

Die MTBF ist ein Maß für die Zuverlässigkeit eines Systems. Fällt zum Beispiel ein Netzwerk alle 2 Stunden für eine Millisekunde aus, so ist es nicht sehr zuverlässig, kann aber wegen der kurzen Downtime trotzdem eine hohe Verfügbarkeit haben.

Mean Time to Repair (MTTR)Die MTTR ist das Maß für die durchschnittliche Ausfallzeit, die durch einen Fehler verursacht wird (inklusive der Zeit bis der Fehler erkannt wird). Sie berechnet sich wie folgt:

MTTR= Summe der ReparaturzeitSumme der ErkennungszeitGesamtzahl der Fehler

Average Downtime (ADT)Die ADT ist die Zeit, die ein Service nach einem Fehler durchschnittlich nicht betriebsbereit ist. Sie ähnelt stark der MTTR und berechnet sich daher sehr ähnlich:

ADT= Summe derinoperablen ZeitGesamtanzahl der Fehler

Annulized Failure Rate (AFR)Die Annulized Failure Rate gibt an, wieviele Ausfälle man pro Jahr von einer Komponente erwarten kann.

AFR= 1MTBFMTTR

⋅8760⋅100 %

Single Point of Failure (SPOF)Der SPOF steht für eine Service-Komponente die bei einem Ausfall einen kompletten Systemausfall nach sich zieht. Es sollte demnach (z.B. durch Redundanz) dafür gesorgt werden, dass kein SPOF existiert. Viele Systeme haben in der Realität mindestens einen SPOF. So haben z.B. Online Markplätze das Problem das die meisten KundenPCs ein SPOF sind. Redundanz auf allen Systemebenen ist sehr schwer zu erschaffen und meist sehr kostspielig. Bei Festplatten Arrays werden z.B. aus Kostengründen meist nur die Festplatten redundant ausgelegt und nicht der RAID-Kontroller. Dieser bildet dann den SPOF.



c. Der Availability-Management-ProzessDas Availability-Management hat direkten Kontakt mit dem Service-Level-Management. Die Vorgaben des Service-Level-Managements, die in den SLAs verankert sind, sind die Grundlage für das Availability-Management Sie beschreiben, in welcher Form und auf welchem Level die Planung, Sicherstellung und Optimierung der Verfügbarkeit von statten gehen soll.

Das Availability-Management muß die Verfügbarkeitswerte intern (dem Service-Level-Management) und extern (dem Kunden) bereitstellen. Die interne Bereitstellung benötigt das Service-Level-Management um zu überprüfen ob die Vorgaben auch eingehalten werden. Die aktuellen Verfügbarkeitswerte werden dafür durch Monitortools überwacht und dokumentiert. Daraus können dann erweiterte Berichte erstellt werden (Reporting). Die SLAs sollten eine genaue Beschreibung der Form der Überwachung und des Reporting enthalten, da man bei willkürlichem Vorgehen keine aussagekräftigen und vergleichbaren Ergebnisse bekommt.In der Regel muß die Ende-zu-Ende Verfügbarkeit eines Service überwacht werden und nicht die reine Serververfügbarkeit. So sollte z.B. bei einem Online Marktplatz nicht nur gemessen werden wie gut der relationale SQL Server verfügbar war, sondern ob die Kunden immer in der Lage waren Waren zu bestellen und so Umsätze für den Betreiber zu schaffen.

Das Availability-Management und das Service-Level-Management unterstützen sich gegenseitig einerseits durch die Vorgabe der Verfügbarkeitswerte und der Form des Reporting durch das Service-Level-Management, andererseits durch die Bereitstellung von Messwerten und Reviews aus dem Reporting durch das Availability-Management.Die Überwachung der Services ist nicht die einzige Aufgabe im Availability-Management-Prozess. Es müssen andauernd Verfügbarkeitsanforderungen für neue oder verbesserte IT Services festgelegt und Designkriterien bezüglich der Verfügbarkeit und Wiederherstellung der IT-Infrastruktur formuliert werden.

Außerdem sind alle Geschäftsprozesse und Funktionen von Unterdienstleistern bezüglich ihrer Wichtigkeit zu bewerten und es ist abzuschätzen, welche Folgen Fehler und Ausfälle der einzelnen Services bedeuten würden. Anhand dieser Abschätzungen sind die entsprechenden Designanforderungen an die Verfügbarkeit zu optimieren, um so die Auswirkungen der möglichen Ausfälle möglichst gut zu kompensieren.Des Weiteren müssen Ziele für die Verfügbarkeit, Wartbarkeit und Verlässlichkeit von IT Infrastruktur Komponenten definiert werden, damit darauf aufbauend die Services dokumentiert und in den SLAs Operational Level Agreements und Verträge vereinbart werden können.

Die Hauptaufgabe bleibt die Verwaltung der Verfügbarkeit. Dazu müssen nicht nur die Messverfahren und das Berichtswesen eingerichtet werden. Diese müssen auch überwacht und eine geeignete Trendanalyse gemacht werden. Beim Review dieser Berichte müssen außerdem nicht akzeptable Werte, also Werte die nicht den SLAs entsprechen, identifiziert und dann die Ursachen herausgefunden werden.Diese Ergebnisse fließen dann unmittelbar in die Planung und Priorisierung von Verbesserungen für die IT Verfügbarkeit mit ein. Am Ende des Prozesses steht die Erstellung bzw. Wartung eines Availability Plans.



Die Festlegung von Sicherheitsbestimmungen für den Geschäftsbetrieb gehört außerdem zum Availability-Management. Hierzu ist festzulegen welche Maßnahmen gegen Attacken von außen sowie Mißbrauch von innen getroffen werden müssen.

d. Availability-Management in einem UnternehmenZur Demonstration des Availability-Managements wird als Beispiel die Firma eBay herangezogen [vgl. http://www.sohar.com/software/meadep/MeadepArticle/Web.pdf]. Die folgende Abbildung stelle eine vereinfachte Übersicht über die Servicestruktur bei eBay dar:

Abbildung 2 [vgl. http://www.sohar.com/software/meadep/MeadepArticle/Web.pdf]

Die Abbildung zeigt die Ebene der beiden Internet-Service-Provider (ISP), die jeweils an einen anderen Backbone angeschlossen sind, die Ebene der gespiegelten Cisco Switches/Router, die Ebene der Web-Frontend-Server und die Ebene der Sun Starfire Database Management Systems (DBMS).Man kann erkennen das alle Komponenten redundant ausgelegt sind, dass heißt es existiert kein Single-Point-of-Failure auf der Seite von eBay. Der einzige SPOF ist der Endkunden-PC.

Die Berechnung der Verfügbarkeit dieses komplexen Systems läßt sich durchführen, indem



man das System in hierarchisch verbundene Teilsysteme unterteilt und die Teilsystem-Verfügbarkeiten berechnet.

Dies geschieht mit Tools wie z.B. dem MEADEP (MEAsurement-based DEPendability tool). Die Teilsysteme werden dabei durch Markov-Modelle oder Blockdiagramme modelliert und lassen sich dann berechnen.

Als Beispiel für ein Markov-Modell dienen hier die gespiegelten Cisco-Switches aus Abbildung 4:

Der Start-Zustand ist hierbei S0 und der Fehlerzustand ist Sf. Es werden die jeweiligen Übergangs-raten bzw. -wahrscheinlichkeiten der einzelnen Zustände für die Berechnung benötigt. Da es zu aufwendig ist solche Modelle von Hand zu berechnen, werden solche Tools wie das MEADEP eingesetzt.Durch Vereinfachung des Beispiels lassen sich die Cisco-Switches als einfaches Duplex-System darstellen (Abbildung 5). Dieses kann von Hand leicht berechnet werden. Hierbei wird zur Idealisierung angenommen, dass die Cisco-Switches im Fehlerfall zu 100% den Fehler erkennen und auf das Fallback-Gerät umschalten.

Das sich dann daraus ergebenes Blockdiagramm ist folgendes:


Abbildung 3 [vgl. http://www.sohar.com/software/meadep/MeadepArticle/Web.pdf]

Abbildung 4 vgl. http://www.sohar.com/software/meadep/MeadepArticle/Web.pdf


Die zur Berechnung der Availability benötigten Werte sind folgende:

MTTR (einer Cisco Switch) = 3h

Fehlerrate einer Cisco Switch: =0.005 1h

MTTF eines Duplexsystems =2=400 h

Daraus lässt sich mit der passenden Formel die Availability berechnen:

A= MTTFMTTFMTTR

=400 h

400 h3 h=0,9926

Im Anschluss kann verifiziert werden ob die Availability in dem in den SLAs zugesichertem Rahmen liegt oder ob Verbesserungen benötigt werden.


Abbildung 5 Vereinfachung: Duplex System

5. Unterscheidung Availability- / Continuity-Management

5. Unterscheidung Availability- / Continuity-ManagementDie Tatsache, dass es im Availability-Management sowie beim Continuity-Management um Ausfälle sowie das Wiederherstellen und Reparieren von Configuration-Items (CIs), also Bestandteilen der IT-Infrastruktur, geht, könnte zur Annahme führen, dass das Continuity-Management im Availability-Management bereits enthalten wäre. Die zwei Bereiche lassen sich aber einfach abgrenzen. Das Availability-Management kümmert sich nur um die Wiederherstellung bzw. den Schutz von Configuration-Items bei denen ein Ausfall von vornherein eingeplant ist. Es werden also z.B. Ersatzplatten für Festplattenraids bereit gehalten, da man weiß das diese ausfallgefährdet sind. Außerdem untersucht es Unterbrechungen von Services durch Messung von bestimmten Kenngrößen und quantifiziert diese in Prozentzahlen.

Das Continuity-Management kümmert sich hingegen um alle Schadensfälle, die nicht geplant waren und somit nicht vom Availability-Management abgedeckt sind. Es bereitet das Unternehmen also auch auf grundsätzlich unvorhersehbare Unterbrechungen vor, welche nicht messbar und höchstens statistisch einzuschätzen sind. Da Katastrophen größeren Ausmaßes nicht planbar sind, gehören diese auch in den Verantwortungsbereich des Continuity-Managements.In der Praxis ist diese Abgrenzung leider nicht so leicht nachzuvollziehen wie in der Theorie. Der Übergang zwischen geplanten Ausfällen und nicht geplanten Ausfällen ist oftmals fließend und je nach Unternehmen und Vorsorgeverhalten unterschiedlich. Plant ein Unternehmen beispielsweise Plattenausfälle standardmäßig ein und legt sich für jeden PC Ersatzteile auf Lager, so gehört ein Ausfall dieser Kategorie bei diesem Unternehmen zum Availability-Management. Das kann beim nächsten Unternehmen schon wieder ganz anders sein. Je nach Vorsorgeverhalten des Unternehmens ist die Grenze zwischen Availability-Management und Continuity-Management auf einem anderen Level.


6. Notwendigkeit von Continuity-Management

6. Notwendigkeit von Continuity-ManagementDas Continuity-Management ist verantwortlich für die Behandlung unplanbarer Störungen. Neben kleineren Ausfällen, die nicht vom Availability-Management abgedeckt werden, gehören auch größere Katastrophen dazu. Laut Statistiken [vgl. Sommer, 2004, S.124] nimmt im Laufe der Zeit der volkswirtschaftliche Schaden, der durch Katastrophen angerichtet wird, zu. Nicht nur die Anzahl der Katastrophen steigt, sondern auch die räumliche Konzentration der Bevölkerung und von Sachwerten. Dadurch bekommt eine Katastrophe eine stärkere Auswirkung. Als bildhaften Vergleich kann man sich ein Erdbeben auf einer verlassenen Insel oder auf Manhattan vorstellen.

Dekade Anzahl Volkswirtschaftliche Schäden in Mrd. US$ (von 2002)

versicherte Schäden in Mrd. US$ (von 2002)

1950-1959 20 42,1 -1960-1969 27 75,5 6,11970-1979 47 138,4 12,91980-1989 63 213,9 271990-1999 91 659,9 1241993-2002 70 550,9 84,5

Tabelle 3: [vgl. Sommer, 2004, S.124]

Viele Katastrophen können einen Totalausfall der IT-Infrastruktur in dem Krisengebiet zur Folge haben. Da solch ein Ausfall für viele Unternehmen massive finanzielle Verluste verursacht, kann es vorkommen, dass sie nach ein paar Tagen nicht mehr überlebensfähig sind. Der Begriff Katastrophe bezieht sich keinesfalls nur auf Naturkatastrophen oder terroristische Anschläge. Die Gefahren von Brand-, Explosions-, Staub-, Schimmel- oder Wasserschäden werden gerne unterschätzt und können doch katastrophale Auswirkungen haben.

Das Continuity-Management hat zur Aufgabe, solche bestehenden Risiken realistisch abzuschätzen, und gegebenenfalls geeignete Maßnahmen zur Vorbereitung zu treffen. Die dafür notwendigen Gelder dürfen das Budget des Unternehmens nicht sprengen und müssen daher mit für die Finanzierung zuständigen Abteilungen abgesprochen werden.Da aber im Katastrophenfall bei erfolgter Vorsorge eine erhebliche Kostenersparnis eintritt, kann das Continuity-Management keineswegs als reiner Kostenfaktor gesehen werden.


7. Business-Continuity-Management

7. Business-Continuity-ManagementWenn Katastrophen den Geschäftsbetrieb stören, erfordert es guter Planung und Vorbereitung, um schnell wieder in einen betriebsbereiten Zustand zu kommen. Dabei können die Katastrophen je nach Typ des Unternehmens von komplett anderer Gestalt sein. Welcher Umstand für ein Unternehmen als Katastrophe zählt hängt davon ab welche Services für das Unternehmen lebenswichtig sind. So können z.B. die meisten Unternehmen den Ausfall der Internetanbindung für ein paar Stunden verschmerzen. Wenn aber ein Unternehmen wie z.B. Amazon für mehrere Stunden, auf Grund fehlender Internetanbindung den Online-Shop nicht den Endkunden zur Verfügung stellen kann, entstehen dadurch womöglich hohe Umsatzeinbußen, die das Geschäft nachhaltig schädigen.Die Maßnahmen, die für solche Fälle geplant werden müssen, können vom einfachen Austausch einzelner Configuration Items bis hin zum komplett eingerichteten Hot Standby Alternativstandort reichen. Dies ist die Hauptaufgabe des Business-Continuity-Managements.

Das Business-Continuity-Management (BCM) ist allerdings nicht allein für die Kontinuität von IT-Services zuständig. Hierfür existiert im BCM ein spezieller Teilbereich: das IT-Service-Continuity-Management (ITSCM). Das BCM hat auch Vorsorge für den Rest des Unternehmens zu treffen. Hierbei kann es sich je nach Art des Unternehmens z.B. um Finanzmarkt-Recovery-Center, Call-Center-Recovery-Center, die Bereitstellung von mobilen Recovery-Centern in Form von Containern mit der nötigen Infrastruktur oder Rechenzentrum-Recovery-Center handeln. Auch die Gebäude-Wiederherstellung (Facility-Restauration) z.B. nach einem Brand gehört zum Planungsrepertoire des Business-Continuity-Management.In vielen Fällen können die Kosten für solche Notfall-Lösungen gesenkt werden, indem auf professionelle Dienstleister zurückgegriffen wird. Diese stellen teilweise komplette Recovery-Center innerhalb vereinbarten Zeiträume zur Verfügung und garantierten für die Bereitstellung.

Ein gutes Business-Continuity-Management bringt seinem Unternehmen also diverse Vorteile. Zum einen sorgt es für kürzere Unterbrechungszeiten im Katastrophenfall und die kontrollierte Wiederherstellung der Services, woraus eine höhere Kontinuität der Geschäftsabläufe und Reduzierung der Ausfallzeiten insgesamt resultiert. Andererseits entstehen niedrigere Gesamtkosten im Katastrophenfall und ein höheres Ansehen bei den Kunden, da auch ihre Services trotz einer offensichtlichen Beeinträchtigung weiterhin betriebsbereit sind.Das Hauptproblem, das im Business-Continuity-Management besteht, ist, dass alle vorbereitenden Recovery Maßnahmen viel Geld kosten. Wie im Availability-Management besteht daher ein enger Kontakt zum Financial-Management. Hätte man keine Budgetlimits, könnte man jeden noch so unwichtigen Service mit den besten Recovery Maßnahmen schützen. Da aber Geld in keinem Unternehmen verschwendet werden soll, muß hier entschieden werden welcher Service es wert ist geschützt zu werden.

Im Folgenden wird näher auf den Teilbereich des BCM, das IT-Service-Continuity-Management eingegangen. Dieser beschäftigt sich mit Ausfällen von IT-Services und bietet hierfür zugeschnittene Planungsoptionen.



a. Aufgaben des IT-Service-Continuity-ManagementsDas IT-Service-Continuity-Management hat die Aufgabe das Unternehmen auf ungeplante Unterbrechungen und Ausfälle vorzubereiten. Da nicht von vornherein klar ist was ausfällt, können auch nicht für alle CIs detailierte Recovery-Pläne, die genau auf den Schadensfall zugeschnitten sind, erstellt werden. Für diese Fälle werden sogenannte Metapläne erstellt, die grundsätzliche Vorgehensweisen für verschiedene Situationen beinhalten.

Je nach Priorität des Service werden andere Vorkehrungen getroffen. Die ITIL beschreibt eine Reihe von Recoveryoptionen, die von "Nichts tun" bis "Hot Standby" reichen und im folgenden Kapitel beschrieben werden.Die grundsätzlichen Aufgaben des IT-Service-Continuity-Managements sind also folgende:

Risikoanalysen bezüglich möglicher Katastrophen müssen durchgeführt werden. Hierzu müssen die Auswirkungen und geschäftlichen Schäden im Störungsfall abgeschätzt und bewertet werden. Weiterhin muß ermittelt werden welche Recoveryoptionen für die betroffenen IT-Services zur Verfügung stehen. Generelle Maßnahmen um Katastrophen von vornherein zu verhindern müssen durchgeführt werden.Es muß ein IT-Service-Continuity-Plan erstellt und dieser dann getestet werden.

Anschließend müssen die Mitarbeiter geschult und die Continuity-Pläne getestet werden.

b. ITIL Optionen bei der Planung[vgl. Sommer, 2004, S.128]

Es folgt eine Aufzählung von Optionen, die ITIL für die verschiedenen Arten der Absicherung eines Service vorsieht. Die jeweilige Option wird dann im Einzelfall je nach Priorität des Service gewählt.

Nichts tun:Der Service hat keine Priorität im Unternehmen und muss daher nicht vom Continuity-Management gesichert werden. In der Regel sind dies Services, die keinen direkten Zusammenhang mit dem Umsatz des Unternehmens haben, z.B. ein Mitarbeiter-Bulletin-Board.

Manuelle Wiederherstellung:Der Service hat eine geringe Priorität bzw. es sind nur kleinere Teile ausgefallen. Die Wiederherstellung erfolgt durch Vorort vorhandenen Mitarbeiter. Die Durchführbarkeit der Wiederherstellung hängt also von der Personalverfügbarkeit ab. Daher eignet sich diese Option nur um z.B. kleine Datenmengen wiederherzustellen.

Wechselseitige Wiederherstellung:Durch die Nutzung von gleichen Systemen, also Systemen mit identischen Konfigurationen und gleichem Change-Management, hat man die Möglichkeit bei einem Ausfall an einem anderen Ort mit einem identischen System weiterzuarbeiten.

Allmähliche Wiederherstellung (Cold Standby)Bei der allmählichen Wiederherstellung wird auf eigene Recovery-Center zurückgegriffen.



Diese stellen entweder mobile oder feste Räumlichkeiten und Infrastruktur bereit, welche innerhalb eines definierten Zeitraums in Betrieb genommen werden können.

Zügige Wiederherstellung (Warm Standby)Ähnlich dem Cold Standby werden hier Recovery-Center bereitgestellt. Beim Warm Standby verfügen diese aber schon über eine identische Infrastruktur. Die Wiederherstellung der Services ist damit innerhalb 24-72h möglich.

Sofortige Wiederherstellung (Hot Standby)Diese Option wird nur für Services höchster Priorität angewandt, da sie auch mit den höchsten Kosten verbunden ist. Für die sofortige Wiederherstellung wird eine gespiegelte Produktivumgebung mit den aktuellen Daten benötigt. Nur so kann ohne größere Unterbrechungen der Betrieb wieder aufgenommen werden.

c. Der Continuity-Management-Prozess[vgl. Sommer, 2004, S.126ff]


Abbildung 6 vgl. Sommer, 2004, S.127


Abbildung 6 zeigt eine Übersicht über die Vorgänge des Continuity-Management-Prozesses. Die einzelnen Teile werden im folgenden erläutert. Der Continuity-Management-Prozess bzw. die Einführung von Continuity-Management in einem Unternehmen ist ein Ressourcen beanspruchender Vorgang. Es bedarf dabei nicht nur vieler finanzieller Mittel sondern auch dafür ausgebildeter Mitarbeiter. In der Regel werden für diese Aufgabe auch externe Experten hinzugezogen.

Die erste Aufgabe des Continuity-Management-Prozesses ist es daher, das Management von der Notwendigkeit eines Continuity-Managements zu überzeugen, da dieses auch die Mittel dafür genehmigen muss. Da die meisten Manager Projekte gerne anhand von Kennzahlen wie RoI (Return of Invest) und TCO (Total Cost of Ownership) bewerten, lassen sich "Projekte" wie das Continuity-Management nur schwer positiv darstellen. Dieses bringt ja in erste Linie gar kein Geld ein und nur im Katastrophen- oder Notfall entstehen dem Unternehmen dadurch Vorteile.Da das Continuity-Management die Produktivumgebung schützen soll, entstehen durch Recoverytests und Verbesserungsumbauten an eben dieser zusätzliche Umsatzausfallrisiken. Auch diese müssen gerechtfertigt sein.

Nach dem Start des Prozesses muss zunächst der Bereich und der Umfang des ITSCM definiert werden. Hierbei werden alle grundsätzlichen Entscheidungen getroffen und die Schwerpunkte ermittelt, auf die sich das ITSCM konzentrieren wird. Es werden die notwendigen personellen und finanziellen Ressourcen ermittelt und außerdem eine geeignete Projektmanagementmethode gewählt.Um die Auswirkungen möglicher Katastrophen einzuschätzen, werden mittels einer Business-Impact-Analyse die missionskritischen IT-Services ermittelt und bestehende Abhängigkeiten dokumentiert. Es folgt eine Risikoanalyse, die die potenziellen Bedrohungen bewertet. Hierzu wird in der Regel die CCTA (Central Computer and Telecommunications Agency) Risk Analysis and Management Methode (CRAMM) empfohlen. [Näheres zur CRAMM in Sommer, 2004, Kapitel MOF]

Im Anschluss wird eine IT-Service-Continuity-Strategie erstellt, wobei mögliche vorbeugende Maßnahmen mit berücksichtigt werden. Diese enthält die Schritte, die beim Eintritt einer Katastrophe ausgeführt werden sollen.Nach der Erstellung der ITSC-Strategie folgt deren Umsetzung im Schritt der Organisationsplanung und Implementation des ITSCM-Prozesses. In diesem Schritt wird auch der Kontinuitätsplan erarbeitet. Dieser besteht aus den folgenden sieben Bereichen.

Der Teil Administration beschreibt, welche Mitarbeiter mit welchen Maßnahmen den Plan starten. Der Bereich IT-Infrastruktur enthält alle Einzelheiten und bestehenden Vereinbarungen zu allen IT-Infrastruktur Komponenten. Im Bereich Management und Betrieb der Infrastruktur werden detaillierte Anleitungen zur schnellen Wiederherstellung des Betriebs gesammelt. Dazu gehören die notwendige Dokumentation der Verfahren sowie die Handbücher und SLAs. Der Teil Mitarbeiter ist eine einfache Auflistung der Personen und Rollen, die bei der Wiederaufnahme des Betriebs benötigt werden. Außerdem enthält er eine genaue Beschreibung der Erreichbarkeit und Transportmöglichkeiten zu den Recovery-Centern. Der Bereich Sicherheit beschreibt alle Sicherheitsmaßnahmen, die bei einer Katastrophe zu ergreifen sind. Im Teil Alternativstandort finden sich alle Informationen zu



den Alternativstandorten: Beschreibungen der Einrichtungen, Notfallrufnummern, Kontaktlisten und die Logistikbeschreibungen. Der letzte Teil ist Wiederherstellung des normalen Betriebs. Er beschreibt wie die Wiederherstellung erfolgt und enthält auch die zugehörigen Zeitpläne.Zusätzlich zu den sieben Standardteilen des Kontinuitätsplans können noch weitere Unterpläne enthalten sein, wie z.B. Katastrophenplan, Schadensbeurteilungsplan, Wiederherstellungsplan, Datensatz-Plan, Krisenmanagementplan und Public Relations Plan.

Der nächste Schritt nach der Erstellung des Plans ist die Implementierung der verfügbaren Einrichtungen und Maßnahmen zur Risikominimierung, so wie es im Kontinuitätsplan festgelegt wurde. Der Kontinuitätsplan ist zu diesem Zeitpunkt aber noch nicht komplett. Es werden nun Entwicklungspläne und Wiederherstellungsverfahren entwickelt, dokumentiert, genehmigt und dann dem Plan angehängt.Jetzt folgen die ersten Tests, welche sicher stellen sollen, dass die erarbeiteten Pläne und Verfahren überhaupt durchführbar und wirksam sind. Sobald funktionierende Pläne vorliegen, müssen die Mitarbeiter geschult werden, da sonst auch die besten Pläne nicht schnell umgesetzt werden können. Hierzu müssen Schulungen ausgearbeitet und durchgeführt werden. Dies sollte zumindest sicher stellen, dass die für den Kontinuitätsplan wichtigen Mitarbeiter mit den notwendigen Maßnahmen vertraut sind und sich im Notfall richtig verhalten.

Nach dem Training der Mitarbeiter ist die Erstellung des Kontinuitätsplan abgeschlossen. Da sich die Umstände und Konfigurationen in Unternehmen aber ständig ändern, müssen regelmäßige Überprüfungen und Audit des Plans gemacht werden. Diese sollten zumindest nach größeren Änderungen von IT-Systemen, CIs oder der Infrastruktur durchgeführt werden. Andernfalls kann keine dauerhafte Konsistenz und Wirksamkeit der Planung gewährleistet werden. Da Änderungen an der IT-Umgebung oft durch das Change-Management angestoßen werden, spielt es hierbei eine entscheidende Rolle. Außerdem sollten in regelmäßigen Abständen Wiederherstellungstests durchgeführt werden um sicherzustellen, dass die Pläne im Notfall auch reibungslos funktionieren.

d. Beispiel eines Continuity-Plans[http://www.hope.ac.uk/itservices/Guides/pdfs/DisasterRecovery.pdf]

Die Vorgänge des Continuity Prozess sind in Kapitel 7.c. beschrieben. Als Beispiel aus der Realität soll ein Auszug aus einem Continuity Plan dienen. Einen Continuity Plan als Ganzes anzuführen, würde den Rahmen der Arbeit sprengen, da diese in der Regel sehr umfassend sind. Der folgende Auszug stammt aus dem Continuity Plan des Liverpool Hope College und wurde aus dem Englischen übersetzt.[...]

Bedrohungen für die Informationsdienste am College können in drei Kategorien unterteilt werden:

Universitätsweite Katastrophe (Hope Park und Everton Campus)Große Bedrohungen die beide Campus Teile betreffen werden vom "Major Incident Plan" und anderen Recovery Plänen wie dem IS Contingency Plan" behandelt.



Lokale Katastrophe (Hope Park und Everton Campus)

Diese Bedrohungen können auch den Major Incident Plan in Kraft treten lassen. Der IS Contingency Plan spielt eine Hauptrolle im Recovery Prozess wenn die Katastrophe IT Equipment, Einrichtungen oder Services beeinflusst hat.

Hauptservice VerlustAlle Ereignisse, die die technische Infrastruktur signifikant beeinflussen oder eine Sicherheitsbedrohung darstellen, stellen einen Grund dar, den IS Contingency Plan in Kraft treten zu lassen. Die identifizierten Risiken haben mögliche Auswirkungen auf die technische oder physische Sicherheit der Informationen oder Telekommunikationsressourcen. Die Bedrohungen könnten physische Zerstörung von Equipment und Informationen, Unerreichbarkeit von Services, Datenverlust oder Datenkorruption zur Folge haben.[...]

Informations-Services Eventualitäten Management Team (IS Contingency Management Team)Das IS-Contingency-Management Team wird vom Direktor der IT Services geleitet.

...Bei einer Katastrophe treffen sich die IS-Contingency-Management Team Mitglieder um einen Aktionsplan zu diskutieren und zu formulieren. Dieser soll die Schlüsselbereiche für die Koordination und Verantwortung identifizieren. Die Folge Liste soll eine allgemeine Anleitung bieten:

• gesamte IT Mannschaft alarmieren und auf Bereitschaft halten• Drittanbieter darauf vorbereiten, dass sie kurzfristig Unterstützung leisten können

• Mitarbeiter für die Backup-Unterstützung organisieren• Mobiltelefone für alle Mitarbeiter des Recovery-Prozesses organisieren

• Benachrichtigung aller anderen Notfall-Teams, die für die spezifische Situation benötigt werden.

• Treffen der notwendigen Vorkehrungen um Zugang zu verschiedenen Gebäuden auf und außerhalb des Campus zu bekommen.

• Treffen der notwendigen Vorkehrungen für Transportmöglichkeiten zwischen den Gebäuden

• Einrichtung einer Katastrophen Stufe

• Priorisierung der Service-Wiederherstellung• Errichtung eines Aktionen-Planes und Verteilung klarer Rollen und Verantwortungen

• Einrichtung eines Zentralen Help Desk Kontaktes zur Informationsverteilung• Die Mitglieder des IS-Contingency-Management Teams müssen ihren Mitarbeiterstab

versammeln um die beschlossenen Aktionen auszuführen.

• Einrichtung von Report-Protokollen (Zeit und Ort)



• Einrichtung von Kommunikations-Protokollen• Die Mitarbeiter daran erinnern, dass Statements zu den Medien nur vom College

Marketing Büro abgegeben werden dürfen.

Zusätzlich zu den oben genannten Verantwortlichkeiten, und je nach Art der Katastrophe, wird der IT Service Stab den anderen Campus Abteilungen je nach Priorität Hilfe anbieten, wenn sie mit kritischen Geschäftsprozessen arbeiten.[...]


8. Zusammenfassung

8. ZusammenfassungEs gibt viele Gründe sich in einem Unternehmen mit den Bereichen Availability-Management und Continuity-Management zu beschäftigen. Die mögliche Erhöhung und Kontrolle der Verfügbarkeit durch das Availability-Management ist in manchen Bereichen unerlässlich, da in der heutigen Zeit immer mehr, fürs Unternehmen lebenswichtige, Prozesse über Computer ablaufen. Die Tatsache, dass auch andere Bereiche des ITIL, wie z.B. das Service-Level-Management, auf das Availability-Management angewiesen sind, macht es noch wichtiger.Damit ein Unternehmen nicht nur auf geplante sondern auch auf ungeplante Zwischenfälle richtig reagieren kann, sollte es auf ein Continuity-Management nicht verzichten. Wie weit sich ein Unternehmen auf Ausfälle vorbereiten möchte bleibt ihm selbst vorbehalten. Alle eingeplanten Ausfälle fallen in die Verantwortung des Availability-Management. Alles was darüber hinaus geht wird vom Continuity-Management abgedeckt. Der Übergang ist genau definiert, kann sich aber von Unternehmen zu Unternehmen unterscheiden.

Continuity-Pläne helfen auch unerfahreneren Mitarbeitern in Notsituationen richtig zu reagieren. Die zugehörigen Tests sind unerlässliche Vorbereitungen der Mitarbeiter auf reale Probleme. So lohnt sich die Investition ins Continuity-Management auch wenn keine direkten Einnahmen dadurch entstehen.


9. Literaturverzeichnis

9. LiteraturverzeichnisBücher:[1] Sommer, Jochen: IT-Servicemanagement mit ITIL und MOF; 1. Auflage 2004; mitp/Bonn[2] Dreyer, Carsten: Citrix Metaframe und Windows Terminal Services; 1. Auflage 2002;

mitp/Bonn[3] Frank Victor, Holger Günther: Optimiertes IT-Management mit ITIL; 2. Auflage 2005;

Vieweg

Web Referenzen:[1] http://www.hisolutions.com/19874/level2/Availability_&_Capacity.htm[2] http://www.hisolutions.com/19872/level2/Business_Continuity.htm[3] http://www.itil-itsm-world.com/itil-9.htm[4] http://www.itil-itsm-world.com/itil-8.htm[5] http://www.sohar.com/software/meadep/MeadepArticle/Web.pdf[6] http://www.weibull.com/systemrelwebcontents.htm#Overview%20of%20System%20Reli

ability[7] http://www.hope.ac.uk/itservices/Guides/pdfs/DisasterRecovery.pdf


Documents

ITIL - Availability & Continuity-Management · PDF fileSeminararbeit Healthcare-Seminar ITIL - Availability & Continuity-Management Bereich: praktische Informatik Lehrstuhl: I4 - LuFG