Diese Informationen gehören in ein gutes Runbook

Die Grundlagen

Ein Unternehmen muss bereit sein, eine umfassende Dokumentation zu erstellen und zu pflegen und das nicht nur einmalig, sondern laufend. IT-Systeme sind fließend; sie ändern sich ständig. Um mit der Realität Schritt zu halten, müssen anwendbare Runbooks ebenso fließend sein, und sie binden dabei durchgehend Ressourcen.

Diese können auch aus Bereichen außerhalb des Administratorenteams stammen. Fragen Sie sich beispielsweise, ob es sich lohnt, einen Entwickler mehrere Stunden für die Mitarbeit an einem Runbook aufzuwenden zu lassen, das dem Admin in Zukunft einige Stunden sparen wird, ist die Antwort unklar, da diese beiden IT-Rollen ein unterschiedliches Gehalt beziehen. Nach diesen Gesichtspunkten ist es gar nicht sinnvoll, wirklich alle Teile des Betriebs mit Runbooks abzudecken. Sie müssen einen Mittelweg finden.

Statt wahllos alles zu dokumentieren, beginnen Sie mit den Prozessen, die sich selten ändern und grundlegend sind. Ein Eckpfeiler in jedem Runbook sollte das Layout der Anwendung oder der IT-Umgebung sein. Mitarbeiter können zum Beispiel ein Problem mit dem Report-Server nicht beheben, wenn sie dessen IP-Adresse nicht kennen. Nun gibt es zwei Probleme: erstens das Identifizieren des Problems und zweitens das Beheben des Problems.

Dokumentieren Sie den Standort jeder Komponente der IT-Umgebung und wer dafür verantwortlich ist – zusammen mit den Kontaktinformationen dieser Person, zum Beispiel einer Mobiltelefonnummer. Eine Anwendung kann sich über mehrere virtuelle Umgebungen erstrecken und ganz oder teilweise in der Public Cloud gehostet sein. Wissen Mitarbeiter darüber genau Bescheid, beginnen sie sofort mit der Problemsuche, ohne lange die Grundlagen zu recherchieren. Infrastrukturkomponenten wie Servernamen, Funktionen und IP-Adressen ändern sich nicht, was sie zu einer soliden Ausgangspunkt zum Verfassen eines Runbooks macht.

Neustart

Wenn Sie den Teil des Runbooks mit der Umgebungsbeschreibung erstellt haben, dokumentieren Sie als nächstes die Start- und Shutdown-Reihenfolge für IT-Systeme und ihre Auswirkungen. Jedes System muss irgendwann neu gestartet werden.

Um dabei Fehler zu vermeiden, benötigen die IT-Administratoren Anweisungen dazu, in welcher Reihenfolge sie Geräte neustarten sollten, und welche Auswirkungen es bei jedem einzelnen Server im Anwendungsstapel haben wird, wenn sie ihn herunterfahren. Berücksichtigen Sie alle möglichen Probleme oder Ereignisse, die dem Mitarbeiter beim Neustartprozess unterkommen könnten, und geben Sie an, wie er mit diesen umgehen soll.

Fehlerbehebung

Ein weiterer wichtiger Teil eines Runbooks ist die Fehlerbehebung für Prozesse und die Handhabung von Vorfällen. Versuchen Sie nicht, jedes Ereignis oder jeden Tickettyp in das Runbook aufzunehmen: Nicht nur wird Ihr Runbook durch die schiere Masse sehr unhandlich, sondern es wird auch gleich mit dem nächsten Software-Update veraltet sein. Treffen Sie eine sinnvolle Auswahl und konzentrieren Sie sich auf allgemeine Probleme – solche, die regelmäßig auftreten.

Selbst, wenn es sich um eine Aufgabe handelt, die jeder Admin in Ihrem Unternehmen im Schlaf erledigen kann, gehört der Lösungsweg ins Runbook: das erleichtert das Onboarding neuer Mitarbeiter erheblich. Besonders aufwendige Prozesse zur Problemlösung mit vielen Schritten und besonderen Tricks sollten Sie unbedingt in Ihr Runbook aufnehmen, solange es sich um eine Aufgabe handelt, die Ihre Mitarbeiter wahrscheinlich mehrmals durchführen werden. Es ist hingegen nicht sinnvoll, Anleitungen für einmalige Vorfälle aufzunehmen.

Der Abschnitt zur Fehlerbehebung erfordert mehr Nachdenken und Planung als die anderen beiden oben beschriebenen Teile des Runbooks. Fügen Sie ein Inhaltsverzeichnis und einen ausführlichen Index hinzu, damit Ihre Mitarbeiter die benötigten Informationen auch schnell finden.

Bereiten Sie sich auf verschiedene Arten von Vorfällen vor

IT-Vorfälle lassen sich nach Bereich, Ursache oder Schweregrad kategorisieren.

Jeder Typ hat seinen eigenen Platz und insbesondere sein eigenes Runbook. Sicherheitsvorfälle beispielsweise sind zeitkritische Ereignisse, die eine schnelle Untersuchung und Behebung erfordern. Sie ziehen in der Regel auch Folgemaßnahmen nach sich, die Sie je nach gesetzlichen oder betrieblichen Vorgaben wiederum dokumentieren müssen.

Ausfälle sollten Sie schnell eskalieren und beheben. Implementieren Sie einen Weg, zuständige Mitarbeiter rund um die Uhr zu erreichen und das Management sowie die Kunden zeitnah zu informieren. Im Vergleich zum Sicherheitsvorfall ist das eine Eskalationsstufe höher – es ist deshalb wichtig, dass die Mitarbeiter auch gleich erfahren, womit sie es zu tun haben.

Ausfälle oder Fehler einzelner Funktionen haben in der Regel eine niedrige Priorität, je nach Wichtigkeit der einzelnen Funktion, und können mitunter warten, bis die Mitarbeiter Zeit dafür haben.

Unternehmen kennzeichnen Vorfälle oder Warnungen häufig als kritisch, schwerwiegend, moderat oder informativ – und dieses Klassifizierungssystem ist ein Problem. Es schafft ein Ampelsystem und berücksichtigt nicht die einzigartigen Aspekte jedes Vorfalls, was zu weiteren Problemen führen kann. Kategorisieren Sie stattdessen alle Vorfälle richtig und delegieren Sie sie dann anhand des Schweregrads, um sicherzustellen, dass die Teams dem richtigen Runbook folgen.

Bereiten Sie sich auf die Cloud vor

Runbooks erstrecken sich über alle Umgebungen; eine der wichtigsten Funktionen eines Runbooks besteht darin, zu dokumentieren, wie verschiedene Systeme miteinander verbunden sind und wie sich darin spezifisch Fehler beheben lassen. Die Cloud verkompliziert das erheblich.

IT-Administratoren On-Premises können natürlich keine Probleme unter der Haube eines Cloud-Anbieters beheben. Wenn jedoch eine Anwendung mehrere Zonen und Teams unterstützt, ändern IT-Mitarbeiter bei Problemen Dienste oder Verfügbarkeitszonen– und sind somit teilweise wieder selbst für Vorfälle zuständig.

Die Möglichkeit, Cloud-Zonen zu wechseln, oder Dienste von On-Premises in die Cloud zu schieben – und umgekehrt – sind wichtige Strategien, die in ein aktualisiertes Runbook aufgenommen werden müssen. Sie können Ausfallzeiten verkürzen und eine einfachere Wiederherstellung ermöglichen. So einfach, wie hier dargestellt ist der Prozess nämlich nicht: Aktionen wie diese haben meistens weitere Auswirkungen, die Sie in das Runbook aufnehmen müssen.

Bei einer verteilten Anwendung sind die Frage, wer Eigentümer ist und die Einhaltung fester Troubleshooting-Reihenfolgen von entscheidender Bedeutung, da sich einige Teile in Clouds oder Remote-Standorten befinden können. Cloud-Dienste bringen auch eine neue Facette ein, da Sie den Umfang des vertraglich vereinbarten Supports, weitere Vertragsbedingungen, Garantien und Support-Prozesse in Ihren Runbooks dokumentieren sollten.

Wenn beispielsweise 90 Prozent der Dienste vor Ort gehostet sind, aber die letzten 10 Prozent in einer Public Cloud ausfallen, dann werden die 90 Prozent im Zweifelsfall auch nutzlos. Aus diesem Grund ist es wichtig, die Kontaktinformationen des Anbieters, die Art des bezahlten Supports, die Beteiligten und die wichtigsten technischen Informationen zu hinterlegen. Sie können sie auch an bestimmten Punkten im Incident Response Runbook beilegen, um sicherzustellen, dass Ihre Mitarbeiter den Support kontaktieren, bevor sie kritische Schritte zur Fehlerbehebung durchführen.

Es geht nicht darum, das perfekte Runbook zu erstellen, das alle möglichen Probleme abdeckt, sondern darum, ein Framework zu schaffen, das für Sie funktioniert und das Anleitungen für das Hinzuziehen internen oder externen Supports bietet, wenn ein Problem auf die höchste Ebenen eskaliert wird. Die Anforderungen an ein Runbook zur Reaktion auf Vorfälle sind gestiegen, weshalb einige Unternehmen lieber auf sogenannte Flows setzen.

Runbooks versus Flows

Viele Admins sind das Führen und Befolgen von Runbooks gewohnt – doch die Cloud kann ihnen eine Neuorientierung abverlangen. Wenn Sie beispielsweise einen Datenbankdienst in die Cloud verschieben, kann dies zu Datenverlusten oder Beschädigungen führen. Oder, Sie haben Schwierigkeiten, aus der Cloud wieder On-Premises zu wechseln, weil die Versionsverwaltung der Anwendung sich aufgrund der in der Cloud vorgenommenen Updates querstellt.

Diese Art von Szenario lässt sich besser in einem Entscheidungsbaum abbilden, als in einer linearen Anweisungen – und hier kommen Flows ins Spiel. Das Runbook ist ein Satz von Anweisungen, um auf Ereignisse oder Bedingungen eines Ereignisses zu reagieren. Ein Flow umfasst mehr Aspekte von der geschäftlichen Seite, als im traditionellen Runbook zu finden sind.

Da das moderne Rechenzentrum und der Anwendungs-Stack über die reine IT hinauswachsen, müssen Teams zusätzlich zu den Schritten in einem Runbook den Ablauf dieser Schlüsselprozesse berücksichtigen. Das Runbook teilt IT-Betriebsteams mit, wann ein Failover für einen Dienst erforderlich ist, aber es kann sein, dass Ingenieure oder das Management diesem zustimmen müssen. Das Runbook muss dies zeigen – und ob eine zusätzliche Freigabe aus Kosten-, rechtlichen oder anderen Gründen erforderlich ist.

Das Failover von Systemen in Public Clouds oder gemeinsame Colocations kann schwerwiegende finanzielle Folgen haben, die über die Ebene des traditionellen IT-Betriebs hinausgehen. Das Playbook – das das Runbook unterstützt und nicht ersetzt – muss dies erfassen.

Stellen Sie sich den Flow als den Stamm und die Zweige eines Baumes vor und das Runbook als die Blätter. Der Zweig führt zu einem bestimmten Pfad, aber die Blätter enthalten die detaillierten Anleitungen. IT-Ereignisse werden immer komplexer und das wirkt sich auf die Dokumentation aus, die zu ihrer Bewältigung erforderlich ist.

Fügen Sie einen Plan für Sicherheitsverstöße hinzu

Sicherheitsverstöße sind ein weiteres großes Thema für Flows und Runbooks. Überlegen Sie beispielsweise, welche Schritte und Maßnahmen bei einem Vorfall zu ergreifen sind und welche Auswirkungen dies vor oder nach der Entwicklungspipeline haben könnte.

Es handelt sich um ein komplexes Thema, das sich aber über die bereits genannte Baumstruktur in Flows abbilden lässt. Beginnen Sie mit allgemeinen Vorfällen. Konzentrieren Sie sich auf einen Zweig des Flows und fügen Sie bei Bedarf Runbooks hinzu. Bauen Sie dieses Wissensnetzwerk aus und verwenden Sie es als Modell, um das nächste Set zu erstellen. Dies wird einige Zeit in Anspruch nehmen, aber das Aufteilen der Aufgabe in kleinere Abschnitte vermeidet eine Überlastung des Personals. Sie schaffen damit ein System, auf das neue Mitarbeiter später aufbauen können.