Startseite > Netzwerke & IT-Infrastruktur > Business-Continuity-Management umsetzen

Wenn die IT-Infrastruktur wankt

Business-Continuity-Management umsetzen

14. November 2022, 7:00 Uhr | Jürgen Kolb und Christoph Aichinger/am

Fortsetzung des Artikels von Teil 1

Shutdown-Konzept statt Schadenersatz

Sowohl im echten Notfall als auch beim geplanten IT-Shutdown müssen sich Server und virtuelle Umgebungen automatisiert oder auf Knopfdruck nach vordefinierter Logik herunter- und bei Bedarf wieder hochfahren lassen. Auslöser für den Ernstfall können beispielsweise Stromausfälle oder Blackouts sein. Kurzfristige Stromausfälle lassen sich mit Hilfe von USVs überbrücken. Für längerfristige Ausfälle hingegen bedarf es eines umfassenden Shutdown- und Wiederanlauf-Konzepts, um Datenverlust und etwaige daraus resultierende Schadenersatzzahlungen zu vermeiden.

System-Administratoren neigen zudem häufig dazu, mögliche Gefahren auszublenden oder für den Schutz der Systeme selbst zu skripten. Der Alltag zeigt jedoch, dass diese Skripte nicht auditierbar, unzureichend und fast immer veraltet sind. Somit stellen sie im Endeffekt ein größeres Risiko als eine Rettung in der Not dar. Auch das Vertrauen in die unterbrechungsfreie Stormversorgung ist meist grenzenlos, selbst wenn man sie kaum testet und ebenfalls zu selten wartet.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Oft passieren Unglücke, bei denen die Kommunikation nicht gegeben ist, abbricht oder keiner klaren Linie folgt. Was mit einer ausgefallenen Klimaanlage beginnt, endet schnell als Katastrophe, wenn die Server der Hitze zum Opfer fallen, weil keiner wusste, dass sich der Server-Raum aufheizt. Eine warnende E-Mail aus einem Software-Tool hinaus, das im schlimmsten Falle auf einem der überhitzten Server läuft, oder eine Nachricht aus dem keineswegs vertrauenswürdigen Internet sind keine sicheren Optionen. Im Krisenfall ist die Kommunikation über einen eigenen Kanal, zum Beispiel via GSM-Modem samt Software-Tool, die redundante und bessere Lösung.

Ein automatisiertes Notification-Tool fährt folglich über einen gesicherten Weg und alarmiert die vordefinierten Empfänger via SMS, Voice oder Mail, so wie es auch eine gängige Alarmanlage macht. Wenn zu wenig Personal für Bereitschaftsdienste, zu wenig Know-how, zu große Entfernungen oder andere Gründe in der operativen Welt gegen eine derartige Lösung sprechen, muss man Schäden abwehren, indem man die Vorgangsweise neu evaluiert und andere Lösungen wie zum Beispiel Managed-Security-Services findet, um ein wirkungsvolles Alarm-Management aufzubauen. An der Einrichtung einer gesicherten Alarmierung aus diversen Quellen (Software, Hardware, Sensoren) inklusive Eskalation und Abbildung organisatorischer Prozesse (Bereitschaftsdienste, Zuständigkeiten und Rollenkonzepte) führt jedoch kein Weg vorbei. Es gibt einige erfolgsentscheidende Kriterien für ein funktionierendes BCM-Konzept: Neben bewährter Software, der Einbindung sinnvoller Prozesse und der theoretischen Basis (Notfallhandbuch) gilt es vor allem, durch Tests und Simulationen in der realen Infrastruktur Erkenntnisse zu sammeln und sich zu verbessern. Krisen und Notfälle haben es an sich, dass sich nicht alles planen lässt, aber solide Werkzeuge und wertvolle Erfahrungen bieten die besten Voraussetzungen.

Wer so gerüstet ist, dass sich die Hardware sicher herunterfahren lässt, Daten vor Verlust geschützt sind und eine Alarmierung verlässlich funktioniert, hat schon sehr viel gewonnen. Und so wichtig die Verfügbarkeit der Daten auch scheint, noch wichtiger ist bei einem Ausfall doch die schnelle Wiederverfügbarkeit.

Inhalte eines Shutdown-Konzepts
Restlaufzeit der USV: Wie viele Minuten lassen sich die Systeme bei einem Stromausfall am Laufen halten? Shutdown-Dauer: Wie viel Zeit nimmt der Shutdown der gesamten IT-Infrastruktur in Anspruch (Schätzung)? Timing: Wie viel Zeit lässt sich bei kürzeren Stromausfällen überbrücken und ab wann muss man den Shutdown einleiten? Systeme: Welche Systeme müssen in den Shutdown integriert sein (virtuelle Maschinen, physische Server, Telefonanlage, Bandroboter, Storage etc.)? Shutdown-Reihenfolge: Definition der Shutdown-Reihenfolge nach Prioritäten („unwichtigere“ Systeme zuerst, „wichtigere“ wie Domain Controller und Storage zuletzt) und unter Berücksichtigung von Abhängigkeiten (zuerst Web-, dann Applikations- und danach Datenbank-Server).

Inhalte eines Shutdown-Konzepts

Restlaufzeit der USV: Wie viele Minuten lassen sich die Systeme bei einem Stromausfall am Laufen halten?
Shutdown-Dauer: Wie viel Zeit nimmt der Shutdown der gesamten IT-Infrastruktur in Anspruch (Schätzung)?
Timing: Wie viel Zeit lässt sich bei kürzeren Stromausfällen überbrücken und ab wann muss man den Shutdown einleiten?
Systeme: Welche Systeme müssen in den Shutdown integriert sein (virtuelle Maschinen, physische Server, Telefonanlage, Bandroboter, Storage etc.)?
Shutdown-Reihenfolge: Definition der Shutdown-Reihenfolge nach Prioritäten („unwichtigere“ Systeme zuerst, „wichtigere“ wie Domain Controller und Storage zuletzt) und unter Berücksichtigung von Abhängigkeiten (zuerst Web-, dann Applikations- und danach Datenbank-Server).

Jürgen Kolb ist Geschäftsführer und Christoph Aichinger ist Leiter Entwicklung, beide bei iQSol.