IT-Notfallvorsorge agil bearbeiten

Das Absichern von Geschäftsprozessen gegen Ausfälle ist eine wichtige Vorbereitung. Früher haben wir dazu die Prozesse erhoben. Dann haben wir die Auswirkungen untersucht und uns eine Reihe von absichernden und vorbereitenden Maßnahmen überlegt. Das hat eine ganze Weile gedauert. Geht das nicht auch agil? Und wenn ja, wie macht man das genau?

Was ist Notfallvorsorge? 

Bei der Vorsorge stellen wir uns - hoffentlich bevor der erste Notfall passiert - Fragen: Was tun wir, wenn bestimmte IT-Systeme nicht zur Verfügung stehen? Wie sind wir möglichst schnell wieder arbeitsfähig? Im Rahmen solcher Projekte werden Notfallhandbücher erstellt, Ersatzsysteme und Ersatzzugänge eingerichtet. Wir schauen uns die Datensicherung an und schulen Mitarbeiter für den Fall der Fälle. (Der Fachbegriff dafür lautet übrigens business continuity management. Beim BSI gibt es einen Online-Kurs Notfallmanagement.)

Foto von Mick Haupt auf Unsplash

Woran scheitern solche Projekte?

Solche Projekte fühlen sich oft zäh an. Natürlich weiß jeder, dass Vorsorge besser ist als das Nachsehen zu haben. Bisher ist es ja auch immer gut gegangen usw.. Aber in der Praxis haben Mitarbeiter selten dafür Zeit. Als Projektleiter muss man den Kollegen hinterherlaufen. Der o. g. Notfallmanagementkurs beschreibt ein Projekt eher klassisch. Es wird viel analysiert und konzipiert. Natürlich müssen wir Dinge analysieren und konzipieren. Aber auf solch einem Weg verlieren wir die wichtige Unterstützung der Anwender und wir bekommen spät Feedback. Wir wissen also gar nicht, ob unser Konzept überhaupt funktioniert.

Je schneller wir solche Projekte bearbeiten, desto eher gibt es überhaupt ein Ergebnis. Hier kann uns eine agile Arbeitsweise helfen.

Produktziel und Product Backlog

Warum machen wir das Projekt? Wir möchten alle Geschäftsprozesse gegen unvorhergesehene Ausfälle absichern. Wir könnten uns zum Beispiel vornehmen, dass wir nach einem Ausfall innerhalb einer festen Zeit wieder arbeitsfähig sind. 

Die Wiederherstellzeit kann je Geschäftsprozess variieren. Dazu könnten wir Klassen definieren:

• Klasse 1: Es gibt keine Ausfälle, egal, was passiert. (Das ist aufwendig. Aufwand und Nutzen müssen zueinanderpassen.)
• Klasse 2: Der Geschäftsprozess ist am selben Tag wieder hergestellt.
• Klasse 3: Der Geschäftsprozess ist innerhalb weniger Tage wieder verfügbar.
• Klasse 4: Die Wiederherstellzeit für den Geschäftsprozess ist länger.

Solch eine Liste könnte zur Vorlage für das Produktziel werden.

Im Product Backlog stehen die Geschäftsprozesse der verschiedenen Abteilungen:

• Registrierte Kunden können Bestellungen aufgeben. Bestellungen werden automatisch verarbeitet.
• Bürger können einen Antrag für Leistung X stellen. Der Antrag wird innerhalb von X Stunden bearbeitet.
  
• Registrierte Anwender können auf 50 % der angebotenen Serien und Filme zugreifen und abspielen.
  

Zu jedem Prozess können Akzeptanzkriterien definiert werden. Z. B. können wichtige betroffene Systeme oder einzuhaltende Standards ergänzt werden.

Das Backlog ist nach Wichtigkeit der Prozesse sortiert.

Die Geschäftsprozesse sind gut geeignet, weil sie zu wiederholbaren Umsetzungsbausteinen werden.

Vorbereitung und Refinement

Vor dem ersten Sprint hilft eine grobe Übersicht:

• Welche Abteilungen gibt es? Wer sind die Ansprechpartner? Wer aus den Abteilungen kann operativ im Projekt mithelfen?
  
• Was sind ihre wichtigen Geschäftsprozesse? Welche Systeme sind beteiligt?
• Welche typischen Ausfälle hatten wir schon einmal? Mit welchen Ausfällen ist zu rechnen? Gibt es Informationen zu Ausfällen von vergleichbaren Organisationen?

Bevor das Scrum Team einen bestimmen Geschäftsprozess bearbeiten kann, brauchen wir ein paar Informationen:

• Was macht der Prozess? Wer ist verantwortlich?
  
• Welche Systeme sind betroffen?
• Wie lange kann dieser Prozess offline oder gestört sein, bevor es richtig unangenehm wird? Hier reichen schon ungefähre Informationen.

Der Product Owner sorgt dafür, dass diese Informationen jeweils vor der Planung des Sprints vorliegen, in dem die Prozesse bearbeitet werden sollen.

Scrum Team

Der Product Owner ist für ein gutes Notfallmanagement verantwortlich. Dafür sollte eine Person ausgewählt werden, die operativ mitarbeiten kann und einen guten Draht zu allen Abteilungen in der Organisation hat. Der Product Owner bekommt einen klaren Auftrag von der Unternehmensleitung. Budget und Entscheidungsbefugnisse sind geklärt.

Bei den Umsetzern brauchen wir alle Kompetenzen, um einen Geschäftsprozess inhaltlich und technisch sicherzumachen. Dafür brauchen wir Prozessexperten aus den Fachbereichen, denn die müssen dafür sorgen, dass Abläufe im eigenen Bereich etwas angepasst werden. Wir brauchen auch IT-Experten, die die Systeme absichern können.

Die Rolle Scrum Master sollten wir mit einer Person besetzen, die den Umsetzern kritische Fragen stellen kann, ohne dass die Umsetzer eingeschnappt sind. Der Scrum Master soll den Umsetzern dabei helfen, ihre Lieferprozesse zu verbessern.

Inkrement und Definition of Done

Häufig werden solche Projekte sehr dokumentenlastig bearbeitet. Es besteht die Gefahr, dass die Dokumentation veraltet. Die Frage ist: Was kann das Scrum Team von Sprint zu Sprint zeigen, um Feedback zur Absicherung zu bekommen? Vielleicht ist es ein Notfallhandbuch mit Anlagen. Vielleicht sind es konkrete Pläne und Tools. Vielleicht sind es Rückmeldungen aus den Fachbereichen.

Zum Inkrement bei Scrum gehört eine Definition of Done. Diese Checkliste soll uns helfen, unabhängig vom bearbeiteten Prozess eine gute Qualität abzugeben. Die DoD ist von der Art des Inkrements abhängig. Wir könnten mit folgenden Punkten starten:

• Der Geschäftsprozess ist gemäß unserer Vorgaben dokumentiert und freigegeben.
• Der Prozess ist einer Schadensklasse zugeordnet. Es gibt eine Vorgabe für die Wiederherstellzeit.
• Es gibt eine Liste von absichernden Maßnahmen mit Terminen, die diesen Prozess gegen Ausfälle absichern sollen.
• Es gibt eine Liste von Aktivitäten, die im Falle eines Falles ausgelöst werden. Es gibt Termine mit Anwendern, an denen diese Maßnahmen besprochen und ggf. geübt werden.
• Die Notfalldokumentation ist aktuell.
• Die nötigen Freigaben liegen vor.

Grundsätzlich gilt: auch wenn noch nicht alle Prozesse in die Notfallvorsorge aufgenommen wurden, ist das Notfallpaket immer aktuell. Für die IT-Dokumentation finde ich noch immer das Buch von Manuela und Georg Reiss gut.

• Reiss, Manuela ; Reiss, Georg: Praxisbuch IT-Dokumentation : Vom Betriebshandbuch bis zum Dokumentationsmanagement – die Dokumentation im Griff. M: Carl Hanser Verlag GmbH  Co KG, 2019. https://www.hanser-fachbuch.de/fachbuch/artikel/9783446455924

(Die DevOps-Community empfiehlt an dieser Stelle sicherlich, ganz viele Dinge auch für die Dokumentation zu automatisieren, z. B. Infrastructure as code. Alles, was sich selbst dokumentieren und aus einer potenziellen Schadenszone beamen kann, reduziert den Aufwand. Vielleicht wissen einige Leser, dass Netflix extra Skripte programmiert hat, die absichtlich etwas kaputt machen (Chaos Engineering). Damit wollen die Betreiber wissen, ob ihre Infrastruktur ausfallsicher ist.)

Rhythmus und Releaseplanung

Je kürzer der Rhythmus ist, desto eher wird das Projekt überhaupt zum Ergebnis kommen. Es hängt jetzt ein wenig davon ab, wie fokussiert das Scrum Team arbeiten kann.

• Idealerweise arbeiten alle Vollzeit nur an diesem Projekt. Sprintlänge ist eine Woche oder noch kürzer.
• Wenn das nicht möglich ist, sollte das Scrum Team feste Blöcke verhandeln, z. B. einen festen Tag pro Woche oder feste Arbeitsblöcke mit mehreren Tagen pro Monat.

Je schneller das Projekt beendet ist, desto eher haben die Beteiligten wieder Zeit für andere Projekte. Das gleichzeitige Bearbeiten von mehreren Projekten verzögert das Liefern von Ergebnissen für alle um ein Vielfaches. Es frustriert die Beteiligten und führt oft dazu, dass Projekt verhungern. Wer als Führungskraft schnelle Ergebnisse will, sollte dem Scrum Team helfen, fokussiert arbeiten zu können. Bitte lasst das Scrum Team fokussiert arbeiten.

Wir erinnern uns noch einmal, warum Scrum für solche Projekt gut geeignet ist:

• Wir können uns nicht sicher sein, ob wir den Prozess im Hinblick auf Vorsorge gut verstanden haben.
• Wir kennen nicht alle Einzelheiten zur Technologie, zu den Tools, zu den Standards oder sonstigen Dingen, mit denen wir Prozesse absichern wollen.
• Wenn wir mit unterschiedlichen Abteilungen intern und mit unterschiedlichen Lieferanten extern arbeiten, wissen wir nicht, ob wir uns wirklich richtig verstanden haben.

Aus diesen Gründen können wir nicht vorab alles planen. Es ist besser, nach vernünftiger Vorbereitung mit den ersten Prozessen anzufangen. Wir machen regelmäßig Reviews mit Stakeholdern (spätestens alle 1-2 Monate). Dort holen wir uns Feedback, ob die Prozesse nun sicher und zumindest sicherer geworden sind. Mit jedem Review lernen wir dazu.

Zu Beginn der Arbeit würde ich mit ein paar Prozessen starten, an denen das Scrum Team lernen kann. Das sollten nicht die kritischsten Prozesse, aber auch nicht die unwichtigsten sein. Mit diesen Prozessen bauen wir die erste Version des Notfallpaketes auf. Wenn wir gutes Feedback bekommen haben, nehmen wir uns die kritischen Prozesse vor und dann folgen wir den Schadens- oder Wiederherstellklassen.

Irgendwann müssen wir sicherlich größere Reviews einplanen, weil wir zum Beispiel die Freigabe von Wirtschaftsprüfern brauchen. Wir sollten auch Übungen einplanen. Bei manchen Prozessen müssen wir vielleicht sogar mehrfach üben. Das kann man dann über Sprint- oder Releaseziele steuern.

Sie wollen mehr über Digitalisierung lernen? Dazu gibt es eine Überblicksseite, die wichtige Artikel aus diesem Blog in eine Reihenfolge bringt. 

Ihr wollt mehr über Scrum wissen? Wir haben eine Übersichtsseite zu Scrum, über die man sich in die wichtigsten Artikel in diesem Blog einlesen kann.