Close

Der Weg zu einem besseren Vorfallmanagement beginnt hier

Disaster-Recovery-Pläne für IT-Ops- und DevOps-Fachleute

Da sich die IT-Services von einer bloßen Kostenstelle zu einem entscheidenden zentralen Wert für das Unternehmen entwickeln, sind effektive Disaster-Recovery-Verfahren für die IT wichtiger denn je.

Ob es sich um Anwendungsausfallzeiten, Datenverluste oder sogar um einen lokalen Brand handelt – die Reaktion während einer Katastrophe ist selten einfach.

Für kleine Unternehmen kann die Wiederherstellung verheerend sein. Laut FEMA eröffnen etwa 40 bis 60 Prozent der kleinen Unternehmen nach einer Katastrophe nicht wieder.

Was ist ein Disaster-Recovery-Plan?

Ein Disaster-Recovery-Plan besteht aus dokumentierten Verfahren und Methoden, die zum Schutz eines Unternehmens und seiner IT-Assets im Katastrophenfall festgelegt wurden. In der Regel umfasst der Plan Szenarien, Runbooks, Backups und Anweisungen, um das Unternehmen und die IT-Services wieder betriebsbereit zu machen. Er ist insbesondere relevant bei Ereignissen wie Systemstörungen, Ausfällen, Sicherheitsverletzungen oder Datenverlusten.

Dazu meint IBM:

"Vor den 1970er Jahren mussten sich die meisten Unternehmen nur darum kümmern, Kopien ihrer papierbasierten Aufzeichnungen zu erstellen. Die Disaster-Recovery-Planung gewann in den 1970er Jahren an Bedeutung, als die Unternehmen begannen, sich stärker auf computerbasierte Abläufe zu verlassen. Zu dieser Zeit waren die meisten Systeme stapelverarbeitungsorientierte Mainframes. Nach der Wiederherstellung des primären Standorts konnte ein weiterer Mainframe abseits des Standorts aus Sicherungsbändern geladen werden."

Disaster-Recovery-Planung und Business-Continuity-Planung im Vergleich

Die Disaster-Recovery-Planung ist ein Bestandteil der Business-Continuity-Planung. Während sich die Disaster-Recovery-Planung darauf konzentriert, die betroffenen Services so schnell wie möglich wieder zum Laufen zu bringen, geht es bei der Business-Continuity-Planung darum, sicherzustellen, dass das Unternehmen im Katastrophenfall ununterbrochen arbeiten kann.

Die IT spielt bei beiden Praktiken eine zentrale Rolle.

Disaster Recovery und Business Continuity werden gerne miteinander verwechselt oder als austauschbar behandelt. Die Disaster-Recovery-Planung zielt darauf ab, einen Service nach einem Vorfall wiederherzustellen. Die Disaster Recovery selbst ist ein kleinerer Bestandteil des übergeordneten Business-Continuity-Plans. Ein Business-Continuity-Plan soll das Unternehmen vor, während und nach einem Vorfall funktionsfähig halten. Bei der Disaster Recovery geht es also darum, wie ein Vorfall am besten behoben werden kann, während die Business Continuity sich darum kümmert, wie das Unternehmen auch während eines Vorfalls weiter operieren kann.

Disaster-Recovery-Planung im Vergleich zum Vorfallmanagement

DevOps und IT-Operations-Teams nutzen das Vorfallmanagement als Prozess, um auf ein ungeplantes Ereignis oder eine Serviceunterbrechung zu reagieren und den Servicebetrieb wiederherzustellen.

Vorfallmanagement und Disaster Recovery werden je nach Team und Unternehmen häufig synonym verwendet. Das Vorfallmanagement konzentriert sich außerdem darauf, Vorfälle in Echtzeit anzugehen und Services während eines Vorfalls wieder in Betrieb zu nehmen.

Wir bei Atlassian definieren einen Vorfall als ein Ereignis, das eine Störung oder eine Verringerung der Servicequalität und somit eine Notfallreaktion erfordert.

Folgende Aussage findet sich im Buch über Site Reliability Engineering von Google:

"Ein effektives Vorfallmanagement ist ein wichtiges Mittel, um die durch einen Vorfall verursachte Unterbrechung zu begrenzen und den normalen Geschäftsbetrieb so schnell wie möglich wiederherzustellen. Wenn du deine Reaktion auf potenzielle Vorfälle nicht im Voraus gründlich geübt hast, kann ein von Prinzipien geleitetes Vorfallmanagement in realen Situationen unter Umständen schiefgehen."

Google empfiehlt außerdem, das Vorfallmanagement zum Teil des Disaster-Recovery-Testprozesses eines Unternehmens zu machen.

Was bedeutet Recovery Time Objective (RTO)?

Als Recovery Time Objective wird die zulässige Wiederherstellungszeit für die Wiederaufnahme eines normalen Service nach einem Ausfall bezeichnet. Sie steht in engem Zusammenhang mit der mittleren Wiederherstellungszeit (MTTR), die in den DevOps-Metriken erklärt wird.

Disaster-Recovery-Planung in einer DevOps-Umgebung

Wie bleiben Disaster-Recovery-Pläne jeden Tag in Umgebungen relevant, in denen es um Continuous Delivery, automatisierte Tests und mehrfache Bereitstellungen geht?

Mit anderen Worten, welche Rolle spielen Disaster-Recovery-Pläne in Unternehmen, die DevOps praktizieren?

Zum Glück können beide Praktiken nebeneinander bestehen und voneinander profitieren. Die gleichen Tools und Prozesse, die du zum Pushen von Code von der Entwicklung zur Testphase und dann bis zur Produktion verwendest, lassen sich auch bei der Disaster Recovery einsetzen. Beispielsweise können Backups von Produktionsumgebungen, die zum Testen von Deployments verwendet werden, auch zum Ausführen von Katastrophensimulationen verwendet werden. Und die nachverfolgten Code-Commits aus deiner CI/CD-Pipeline können ein nützliches Werkzeug sein, um die jüngsten Änderungen in einem Disaster-Recovery-Szenario sichtbar zu machen.

Es ist kein Geheimnis, dass DevOps zunehmend das Tempo für alle IT-Entscheidungen im Unternehmen vorgibt. Dies muss jedoch nicht bedeuten, dass die harte Arbeit, die in den Wiederherstellungsplan und die Ressourcen geflossen ist, verschwendet wurde oder dein Disaster-Recovery-Plan ins Regal gestellt wird und dort Staub ansammelt.