Durch COVID-19 sind die Schwachstellen hinsichtlich IT Service Continuity schonungslos aufgezeigt worden.

Das IT Service Continuity Management als Teil des IT Service Managements muss dafür sorgen, dass die nachhaltige Verfügbarkeit kritischer Services sichergestellt werden. Die Hauptfrage im Kontext von COVID-19 ist dabei: Was konnten wir aus der aktuellen Situation lernen und wie können wir uns auf die nächste Krise vorbereiten?

Abbildung 1: Beispielhafter Verlauf der Ausarbeitung eines Continuity Plans

 

 

1.      Business Impact Assessment (BIA) durchführen

Ziel des BIAs ist es, die Prozesse sowie die dauzehörigen IT-Services zu identifizieren, die für die Geschäftserfüllung kritisch sind, d.h. bei einem Ausfall entsteht ein erheblichen finanziellen Schaden für das Unternehmen.

Zunächst muss der Umfang identifiziert werden (welche Prozesse & IT-Services sollen angeschaut werden?).

Nun geht es darum, die Auswirkungen eines Ausfalls dieser Prozess zu analysieren, nach Möglichkeit mit quantitativen Kennzahlen.

Die folgenden Kriterien sollten hierbei berücksichtigt werden:

• Entgangener Umsatz bzw. Cash-Flow
• Zusätzlicher Aufwand für manuelles Umsetzen der Aktivitäten / Aufgaben
• Erhöhte Ausgaben durch Ersetzen von Ausstattung
• Höhe von potentiellen Strafzahlungen auf Grund von „non-compliance“ zu Gesetzen oder Regularien

Zusätzlich sollten aber auch noch qualitative Kriterien in die Bewertung einfliessen – z.B. Imageverlust.

Das Ergebnis des Business Impact Assessments ist eine priorisierte Liste der Geschäftsprozesse entsprechend ihrer Wichtigkeit bzw. des potentiellen Schadens bei Ausfall dieser Prozesse.

Projektbeispiel: Telefonzentrale

Der Ausfall der Telefonzentrale bedeutet, dass Kunden weder Bestellungen aufgeben noch deren Status telefonisch abfragen können. Der entgangene Umsatz konnte relativ gut quantifiziert werden. Zusätzlich wurde auch der Reputationsverlust berücksichtigt.

 

2.      Anforderungsanalyse

Die Anforderungen für jeden businesskritischen IT-Service werden identifiiert und analysiert. Es geht hier um die funktionalen und nicht-funktionalen Anforderungen:

• Die funktionalen Anforderungen beschreiben die direkten Funktionalitäten, die der IT-Service erfüllen muss. Diese sind für die IT Continuity i.d.R. weniger relevant.
• Die nicht-funktionalen Anforderungen beschreiben Konditionen, die erfüllt werden müssen. Darunter fallen unter anderem Performance, Wege des Zugriffs, Verfügbarkeit und Desaster Recovery

Bei der Identifikation der nicht-funktionalen Anforderungen sollten die folgenden Fragen geklärt werden:

• Wann müsste der IT-Service verfügbar sein (z.B. Bürozeiten oder rund um die Uhr auch am Wochenende?)?
• Wieviel Ausfallzeit im Jahr ist akzeptabel (in Stunden oder Tagen)?
• Wieviele Ausfälle pro Jahr sind akzeptabel?
• Wie gross darf die Antwortzeit (Performance) einer Webanwendung maximal sein?
• Wie schnell muss der IT-Service wiederhergestellt werden (in Stunden bei ganz kristischen IT-Services in Minuten)?
• Wieviel Datenverlust sind für das Business akzeptabel (in Minuten oder Stunden)?
• Wie geschäftskritisch sind die Daten, die im Rahmen des IT-Service transportiert, verarbeitet oder gespeichert werden und welcher Schutzbedarf ergibt sich daraus?

Projektbeispiel: Telefonzentrale

Für die Telefonzentrale ergaben sich dann unter anderem folgende nicht-funktionale Anforderungen:

• der Service musste nur unter der Woche von Montag bis Freitag (24/5) verfügbar sein.
• eine erhöhte Verfügbarkeit ist notwendig – man einigte sich auf eine max. Ausfallzeit von etwa 6 Stunden, was einer Verfügbarkeit von 99.9% entspricht.
• Die Wiederherstellung des Service bei einem Ausfall sollte nicht länger als 4 Stunden dauern
• Der Zugriff auf den Service musste von überall auf der Welt sichergestellt sein

 

3.      Design

Nun gilt es, diese Anforderungen in ein entsprechendes Design zu giessen. Hierbei ist folgendes zu berücksichtigen:

• Wichtige IT interne Stakeholder involvieren – z.B. IT Architekten, Netwerkexperten und natürlich auch externe Service Provider
• Es ist wichtig die „Service-Kette“ zu verstehen – d.h. welche anderen IT-Services werden vom Benutzer benötigt um auf den Servie zuzugreifen bzw. ihn zu benutzen (z.B. Endgerät, WiFi / LAN / WAN, Internetverbindung, etc.)
• Identifikation von Single-Point-of-Failures in der gesamten „Service-Kette“
• Bei Bedarf sollten externe Experten hinzugezogen werden

Es wird dann ein IT Service Design erstellt sowie auch erste Notfallpläne – dies ist im ersten Schritt vor allem „Papierarbeit“, was auf lange Sicht aber seinen Nutzen bringt.

Projektbeispiel: Telefonzentrale

Die grundsätzlichen Design Prinzipien für unsere im Überblick:

• Redundantes Hosting der Telefoniezentrale (Cloud Application) in zwei Rechenzentren
• On-site Komponenten (z.B. Media Server) wurden komplett redundant aufgebaut
• Netzwerkverfügbarkeit mit dem Service Provider musste erhöht werden
• Bereitstellung des Zugriffs via VPN von überall

Es wurden ebenfalls Notfallpläne für den Fall eines Ausfalls erstellt und mit dem Service Provider abgestimmt.

 

4.      Implementierung

Die Implementierung von Änderungen am bestehenden System sollte immer über den unternehmensweiten Change Management Prozess abgewickelt werden, um zu verhindern, dass Änderungen unvorhergesehene negative Folgen auf die Produktivumgebung hat.

Sollten größere Anpassungen notwendig sein, um die Anforderungen aus der Analyse zu erfüllen empfiehlt es sich, dies im Rahmen eines Projekts abzuwickeln.

 

 

5.      Überprüfung & Re-Design

Abschliessend ist wichtig, das neu implementierte Design zu prüfen. Das erfordert unter anderem auch, Tests durchzuführen, in denen ein solches Krisenszenario nachgestellt wird, um allfällige Schwachstellen zu identifizieren und gegebenenfalls erneut zu überarbeiten.

Projektbeispiel: Telefonzentrale

Im Rahmen des Projekts wurde das Katastrophenszenario getestet, indem die Agenten gebeten wurden, an verschiedenen Tagen von zu Hause aus zu arbeiten. Diese Tests waren erfolgreich und die Sicherstellung der Continuity konnte damit für diesen Service abgeschlossen werden.