Warum gute IT auch ohne CIO läuft

Wer als IT-Chef im Urlaub jeden Morgen die Alarme checkt, beweist nicht automatisch besonderen Einsatz. Es kann vielmehr ein Hinweis darauf sein, dass wichtige Abläufe zu stark von einer einzelnen Person abhängen. Das ist ein Risiko für das ganze Unternehmen.

Denn die ständige Erreichbarkeit hat zwei Nebenwirkungen. Erstens fehlt der Führungskraft echte Erholung und im Arbeitsalltag bleibt weniger Raum für strategische Aufgaben. Zweitens kann sich ein Team daran gewöhnen, bei wichtigen Entscheidungen auf Freigaben von oben zu warten. Muss bei jedem größeren Ausfall erst der CIO zustimmen, können unnötige Abstimmungsschleifen die Wiederherstellung verzögern.

Die gute Nachricht: Das lässt sich ändern. Eine IT, die zwei Wochen ohne ihren Chef stabil läuft, ist kein Zufall, sondern Ergebnis guter Vorbereitung. Wie das geht, zeigen die folgenden Abschnitte.

Reife statt Heldentum

Ein hilfreiches Raster ist das Capability Maturity Model Integration, kurz CMMI. Es beschreibt fünf Reifegrade: Initial, Managed, Defined, Quantitatively Managed und Optimizing.

Auf niedrigen Reifegraden können Abläufe stärker von einzelnen Personen, projektspezifischen Prozessen und manueller Koordination abhängen. Mit zunehmender Prozessreife werden Verantwortlichkeiten, Abläufe und Standards klarer definiert.

Ein wichtiger Schritt ist Stufe 3 (Defined). Hier sind Prozesse organisationsweit definiert und dokumentiert. Das kann dazu beitragen, Abhängigkeiten von einzelnen Personen zu reduzieren. Das Team weiß, welche Abläufe gelten und wie es in typischen Situationen handeln soll.

Für eine IT, die auch bei Abwesenheit ihrer Führungskräfte funktioniert, kann dieser Grad an Standardisierung bereits eine solide Grundlage schaffen. Stufe 4 und 5 gehen noch weiter und ergänzen unter anderem quantitative Steuerung und kontinuierliche Optimierung.

Error-Budgets: Die Zahl entscheidet, nicht der Chef

Aus dem Site Reliability Engineering (SRE) stammt ein Werkzeug, das viele Diskussionen über Verfügbarkeit und Änderungen objektiver machen kann: das Error-Budget. Es beschreibt, wie viel Nichterfüllung eines definierten Serviceziels innerhalb eines bestimmten Zeitraums akzeptiert wird.

Bei einem auf Verfügbarkeit bezogenen Service Level Objective (SLO) lässt sich die zulässige Ausfallzeit vereinfacht so berechnen: Erlaubte Ausfallzeit = Zeitraum × (1 − SLO)

Bei einem Ziel von 99,9 Prozent Verfügbarkeit sind das in 30 Tagen rund 43 Minuten.

Wichtig ist die Unterscheidung zwischen Service Level Objective (SLO) und Service Level Agreement (SLA). Das SLO beschreibt ein definiertes Ziel für die Servicequalität. Ein SLA ist dagegen eine Vereinbarung mit Kunden und kann Konsequenzen vorsehen, wenn bestimmte zugesicherte Werte nicht eingehalten werden.

In der Praxis kann ein internes SLO bewusst anspruchsvoller als die vertragliche SLA-Grenze gewählt werden. Dadurch kann das Unternehmen bereits reagieren, bevor eine vertragliche Verpflichtung verletzt wird.

Der Clou ist die Spielregel dahinter. Solange ausreichend Error-Budget vorhanden ist, können Teams nach vorher festgelegten Regeln Deployments und Änderungen durchführen. Ist das Budget aufgebraucht, greift eine definierte Error-Budget-Policy. Beispielsweise können neue Features oder nicht zwingend notwendige Änderungen pausieren, während die Stabilität Vorrang bekommt.

Der CIO muss dann nicht mehr jeden Einzelfall persönlich zwischen Geschwindigkeit und Zuverlässigkeit abwägen.

Ersetzen statt reparieren

Ein weiterer Baustein kann Immutable Infrastructure sein. Dabei werden laufende Systeme möglichst nicht nachträglich manuell verändert. Infrastruktur wird typischerweise als Code definiert und automatisiert bereitgestellt.

Statt einen fehlerhaften Server mühsam von Hand zu reparieren, wird er, sofern die Architektur dafür ausgelegt ist, durch eine neu erzeugte und definierte Instanz ersetzt. Manuelle Änderungen an Produktivsystemen werden dadurch auf Ausnahmefälle reduziert.

Je nach Umgebung kann ein solcher Austausch sehr schnell erfolgen. Gleichzeitig werden Systeme reproduzierbarer. Neue Instanzen entstehen aus derselben definierten Konfiguration, statt über Jahre durch individuelle manuelle Änderungen auseinanderzudriften.

Ein Allheilmittel ist das aber nicht. Gegen Fehler im Anwendungscode, beschädigte Daten, fehlerhafte Konfigurationen oder den Ausfall eines externen Dienstleisters hilft eine neue Serverinstanz allein nicht.

Dafür braucht es weiterhin gute Backups, Monitoring, getestete Wiederherstellungsverfahren, Runbooks und Menschen, die sie anwenden können.

Wann der Anruf wirklich nötig ist

Loslassen heißt nicht, im Ernstfall grundsätzlich unerreichbar zu sein. Es bedeutet vielmehr, vorher klar festzulegen, wann eine Eskalation an die IT-Leitung tatsächlich notwendig ist. In manchen Organisationen führen Vorfälle der höchsten internen Prioritätsstufe automatisch zu einer Eskalation an die IT-Leitung, selbst wenn technische Redundanzen bereits gegriffen haben.

Besser ist es, Eskalationswege nicht nur an der technischen Priorität, sondern auch an den möglichen geschäftlichen Auswirkungen auszurichten.

Fällt beispielsweise ein Core-Switch aus und eine redundante Infrastruktur übernimmt wie vorgesehen, kann das zunächst Sache des zuständigen Incident-Teams bleiben.

Eine Eskalation an die Führungsebene kann dagegen sinnvoll oder notwendig werden, wenn beispielsweise eines davon eintritt:

• Datenverlust über dem akzeptierten Niveau: Das Recovery Point Objective (RPO) eines kritischen Systems wird überschritten.
• Erheblicher Sicherheitsvorfall: Für besonders wichtige und wichtige Einrichtungen nach dem BSIG können bei einem erheblichen Sicherheitsvorfall gesetzliche Meldepflichten greifen. Eine frühe Erstmeldung muss grundsätzlich unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung erfolgen. Innerhalb von 72 Stunden folgt eine weitere Meldung mit einer ersten Bewertung des Vorfalls.
• Verletzung des Schutzes personenbezogener Daten: Sind personenbezogene Daten von einer Datenschutzverletzung betroffen, kann zusätzlich die Meldepflicht nach Art. 33 DSGVO greifen. Die zuständige Aufsichtsbehörde ist grundsätzlich unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden zu informieren, sofern die Verletzung voraussichtlich ein Risiko für die Rechte und Freiheiten natürlicher Personen darstellt.
• Verlust eines Standorts: Brand, Hochwasser oder ein vergleichbares Ereignis legt einen Standort lahm und der Business-Continuity-Plan muss aktiviert werden.

So kommt der Anruf vor allem dann, wenn tatsächlich rechtliche, finanzielle oder strategische Entscheidungen notwendig werden. Technische Probleme innerhalb vorher definierter Grenzen kann dagegen das zuständige Team eigenständig bearbeiten.

Vorher und nachher

Wie groß der Unterschied zwischen einer personenabhängigen und einer gut organisierten IT sein kann, zeigt sich besonders im Alltag.

Wer entscheidet bei einem Incident?
In einer stark personenabhängigen IT werden wichtige Entscheidungen häufig nach oben eskaliert. In einer prozessorientierten IT kann das Team innerhalb klar definierter Befugnisse selbst entscheiden und sich dabei an Runbooks und festgelegten Abläufen orientieren.

Wie sieht die Dokumentation aus?
Im ersten Fall steckt viel Wissen in den Köpfen einzelner Mitarbeiter oder Führungskräfte. Im zweiten Fall sind wichtige Prozesse, Zuständigkeiten, Infrastruktur und Wiederherstellungsverfahren nachvollziehbar dokumentiert.

Wann wird die IT Leitung gerufen?
In einer personenabhängigen Organisation kann bereits eine größere technische Störung zur Eskalation führen. In einer gut vorbereiteten IT wird die Führung vor allem dann einbezogen, wenn definierte geschäftliche, rechtliche oder sicherheitsrelevante Grenzen überschritten werden.

Was passiert, wenn der Chef im Urlaub ist?
Fehlen klare Zuständigkeiten, können Unsicherheit und zusätzliche Abstimmungsschleifen entstehen. Sind Verantwortlichkeiten und Befugnisse dagegen vorher geregelt, läuft der normale Betrieb auch während einer längeren Abwesenheit weiter.

Wie schnell werden Probleme gelöst?
Wenn Entscheidungen erst von einzelnen Führungskräften freigegeben werden müssen, kann sich die Wiederherstellung verzögern. Automatisierung, Runbooks und klare Zuständigkeiten können dagegen helfen, schneller auf Störungen zu reagieren.

Womit beschäftigt sich die IT Führung?
In einer stark personenabhängigen Organisation wird die Führung regelmäßig in operative Probleme hineingezogen. Eine selbstständig arbeitende IT schafft dagegen mehr Freiraum für Strategie, Architektur und die langfristige Weiterentwicklung der IT.

Fünf Schritte vor dem Urlaub

Das alles entsteht nicht erst in der Woche vor dem Abflug. Sinnvoll ist es, entsprechende Strukturen dauerhaft aufzubauen und vor längeren Abwesenheiten noch einmal zu überprüfen.

1. Stellvertretung mit echten Befugnissen. Benennen Sie eine Vertretung und geben Sie ihr die notwendigen Entscheidungs- und Freigaberechte. Eine Vertretung ohne ausreichende Befugnisse kann im Ernstfall genauso zum Flaschenhals werden wie ein abwesender Chef.
2. Runbooks prüfen und schärfen. Identifizieren Sie die wichtigsten Risikoszenarien und dokumentieren Sie die notwendigen Schritte. Ein qualifiziertes Teammitglied sollte eine Wiederherstellung durchführen können, ohne auf Wissen angewiesen zu sein, das ausschließlich im Kopf des CIO steckt.
3. Adminrechte nur auf Zeit. Über Privileged Access Management (PAM) können hohe Berechtigungen bedarfsgerecht und zeitlich begrenzt vergeben werden. Zugriffe lassen sich protokollieren und anschließend wieder entziehen.
4. Den Ernstfall proben. Simulieren Sie vor einer längeren Abwesenheit, dass die IT-Leitung für einen festgelegten Zeitraum nicht erreichbar ist. Probleme bei Zuständigkeiten, Freigaben oder Dokumentation werden dadurch sichtbar, bevor ein echter Incident auftritt.
5. Status asynchron verfügbar machen. Dashboards, Ticketsysteme und schriftliche Statusinformationen reduzieren die Abhängigkeit von spontanen Meetings oder direkten Rückfragen an die Führungskraft.

Fazit

Eine gute IT sollte nicht davon abhängen, dass ihr Chef rund um die Uhr erreichbar ist. Sie braucht robuste Systeme, dokumentierte Abläufe, klare Eskalationsregeln und ein Team, das innerhalb definierter Grenzen selbst entscheiden darf.

Automatisierung, Runbooks, Error-Budgets, geregelte Zugriffsrechte und eine handlungsfähige Stellvertretung reduzieren dabei nicht nur die Abhängigkeit von einzelnen Personen. Sie machen die gesamte Organisation widerstandsfähiger.

Wenn die IT-Leitung zwei Wochen Urlaub machen kann, ohne morgens am Pool die Alarme kontrollieren zu müssen, ist das deshalb nicht mangelnder Einsatz. Es ist ein Zeichen dafür, dass die Organisation gelernt hat, auch ohne einzelne Schlüsselpersonen zu funktionieren.