(Disclaimer: Es geht nicht um den Film - versprochen!)

Die Firma, für die ich arbeite, verdient einen Großteil ihres Geldes damit, eine Reihe von Internet-Anwendungen zu betreiben. Diese Anwendungen werden In-House entwickelt und laufen auf von der Firma selbst betriebener Infrastruktur. Dadurch sind wir natürlich in vielen Dingen sehr flexibel: Wenn das Operations-Team ein Loadbalancing-Verfahren implementiert, um festzustellen, ob ein bestimmter Applikationsserver noch so funktioniert, wie er soll, dann kann das Team sich einfach an die Entwickler wenden und diese bitten, so einen Check zu implementieren. Verabschiedet sich ein Tomcat dann aus der Welt der funktionierenden Servlet-Container, dann wird er automatisch aus dem Loadbalancing entfernt. Und es ist sehr gut, daß wir diese Flexibilität unser eigen nennen können, denn natürlich ist für uns alle wichtig, daß unsere Haupteinnahmequellen stets verfügbar sind.

Bei der Firma handelt es sich um ein Anfang der 2000er gegründetes Internet-Startup, das es geschafft hat, der größte Spieler in seinem Bereich zu werden. Entsprechend interessant klingen Geschichte, die mir Mitarbeiter, die schon länger dabei sind, aus der Anfangszeit erzählen: Da gab es einen Server, auf dem die Datenbank lief, und einen Server, auf dem die beiden wichtigsten Anwendungen beheimatet waren. Musste man eine der Anwendungen durchstarten, war die Internet-Seite nicht verfügbar. Seit damals ist viel Zeit vergangen, und die Infrastruktur hat sich, zusammen mit einer Vielzahl an internen Abläufen gewaltig verändert. Trotzdem bitte ich Euch, liebe Leser, mit mir zusammen eine kleine Zeitreise in diese Anfangszeit zu unternehmen und aus der Sicht eine Operation Engineers die damalige Struktur zu betrachten. Was erwartet man, wenn man von so einem Setup hört? Ganz ohne IT-Erfahrung:

  • Der Datenbankserver kann kaputt gehen.
  • Der Applikationsserver kann kaputt gehen.
  • Der Switch, an dem die Geräte hängen, kann kaputt gehen.
  • Die sonstigen Netzwerkgeräte, die die Verbindung in’s Internet herstellen, können kaputt gehen.

Wie man sieht erwartet jeder IT’ler bei diesem Setup vier unerwartete Vorfälle (ich werde die Kunstausdrücke “erwartete unerwartete Vorfälle” und “unerwartete unerwartete Vorfälle” in diesem Artikel noch öfter verwenden. Meine Intention ist hier weniger der Einsatz als Stilmittel, z.B. Oxymoron oder Hendiadyoin, sondern einfach der Mangel an besseren Ausrücken, um den Alltag in einer Operations-Abteilung zu beschreiben). Als sich unternehmerischer Erfolg einstellte und mehr Mittel zur Verfügung standen, waren es denn auch diese vier Punkte, an denen gearbeitet wurde. Aus einem Datenbankserver wurde ein Oracle RAC-Cluster pro Kunde. Aus den internen Festplatten, auf denen die Datenbank gespeichert war, wurde zunächst eine externe Storage, später dann zwei Storages, die von Oracle ASM verwaltet wurden. Aus der direkten Steckverbindung zwischen externer Storage und Server wurden ein, zwei und schließlich vier SAN-Switche. Aus einem einzigen Applikationsserver wurde zunächst ein Server pro Kunde, später ein Cluster pro Kunde. Aus einem Switch pro Server wurden zwei, gefolgt von redundanten Core-Switches. Aus einer Firewall wurden zwei und später vier und aus einem Internet-Uplink wurden mehrere (und derzeit wird wohl überlegt, das ganze als ASN aufzuziehen).

Mit steigender Redundanz passierten drei Dinge, die jede Operations-Abteilung in der selben Weise erleben würde:

  • Der Komfort für die IT stieg. Wenn man alles redundant auslegt, ist es, von wenigen Ausnahmen abgesehen, kein Problem mehr, Wartungsarbeiten am hellichten Tag durchzuführen. Das bedeutet weniger Nachtschichte, ausgeruhte und glückliche IT-Mitarbeiter und trägt auf seine Weise zu der stoischen Ruhe bei, die meiner Meinung nach das Kennzeichen einer gut funktionierenden Betriebsabteilung ist.
  • Das Vertrauen der Mitarbeiter in die Systeme erhöhte sich: Das Wissen, daß ein einzelner Ausfall keine verheerenden Folgen mehr haben kann, erworben während Wartungsarbeiten, ist ein Wissen, daß jeden Operations-Mitarbeiter ruhiger schlafen lässt. Zu den Folgen siehe Punkt 1 ;-)
  • Die Komplexität des Systems erhöhte sich. Wenn man statt vier Geräten innerhalb kurzer Zeit plötzlich mehr als 300 Geräte zu verwalten hat, dann werden Dinge eben etwas komplizierter.

Dem dritten Punkt begegnete das Unternehmen nun so, wie man es von Profis erwarten würde: Zentrales Konfigurationsmanagement, Standardisierung, einheitliche Deployments, mehr Automatisierung, Aufbau von Personal. Fragt man Mitarbeiter, die den Wandelt miterlebt haben, wie sie diese Zeit beschreiben würden, so antworten diese meist nach einigem Hin und Her mit: “Professionalisierung”. Und dabei merkt man den stolz, der mitschwingt. Stolz darauf, so einen Wandel geschafft zu haben. Stolz darauf, daß alle sechs Monate die gesamte IT eine Nachtschicht damit zubringt, zu überprüfen, ob das System auf alle erwarteten unerwarteten Vorfälle so reagiert, wie man das geplant hat (ja, wir testen das wirklich zweimal im Jahr. Mit “Strom aus” und so!).

Treten wir einen Schritt zurück und betrachten das ganze von der menschlichen Ebene: IT-Operations hat sich das ursprüngliche System mit seinen zwei Servern angesehen und sich jahrelang den Kopf zerbrochen, was da schiefgehen kann. Man hat sich also Gedanken über alle unerwarteten Vorfälle gemacht, die auftreten können, und sich eine technische oder prozedurale Gegenmaßnahme einfallen lassen. Damit jedoch wurden aus “unerwarteten Vorfällen” etwas anderers, nämlich “erwartete unerwartete Vorfälle”. Ein DNS-Server fällt aus? Kein Problem, der Loadbalancer übernimmt. Ein Datenbankserver fällt aus? Die Anwendung erhält von der Oracle Clusterware die Information, was passiert ist, und schwenkt ihre Verbindungen auf überlebende Knoten um. Ein Applikationsserver fällt aus? Nach drei fehlgeschlagenen Überprüfungen wird er im Loadbalancer ausgetragen und alles geht weiter wie zuvor. Eingerahmt ist das ganze von einem extrem detaillierten Monitoring und Alerting, das das Gefühl des “Wir sind auf alles vorbereitet!” weiter erhöht (erinnert mich bitte mal dran, einen Beitrag über Monitoring zu schreiben - genauer darüber, wie ein immer detaillierteres Monitoring die Abläufe in einem Operations-Team beeinflussen kann, weil man plötzlich Fehler sieht, von denen man früher noch nie gehört hatte).

Und so könnte das IT-Team eigentlich von sich behaupten, knapp zehn Jahre nach der Gründung des Unternehmens auf einer grünen Wiese angekommen zu sein. Die einzigen Aufgaben so scheint es, sind die Weiterentwicklung des Systems und das Beobachten der Uptime, wie sie steigt. Wirklich?

Vorhang auf für Akt zwei (oder von mir aus auch Akt zwanzig) - die Bühne betritt jetzt nämlich ein schwarzer Schwan. Oder auch gerne mal ein ganzer Schwarm schwarzer Schwäne. Was meint man damit? Den Term hat Nassim Taleb in The Black Swan: The Impact of the Highly Improbable geprägt. Dort definiert er ihn folgendermaßen:

A black swan is an outlier, an event that lies beyond the realm of normal expectations.

Als typische und für jedermann verständliche Inkarnationen von schwarzen Schwänen nennt der Autor Katrina oder 9/11. Für uns aber ist wichtig, daß wir uns offensichtlich mit einer weiteren Klasse von Vorfällen beschäftigen müssen: Den unerwarteten unerwarteten Vorfällen, also den “echten Überraschungen”. Ich stelle hiermit die These auf, daß es diese Klasse von Geschehnissen ist, die bei den meisten IT-Firmen für die weitaus meisten Downtimes verantwortlich ist und behaupte ferner, daß man sich nicht vor ihnen Schützen, sondern nur ihre Auswirkungen mitigieren kann - wenn überhaupt.

Das Knifflige an schwarzen Schwänen ist ihre, auf das Auftreten bezogene, mangelnde statistische Signifikanz. Aus dieser folgt direkt daß wir Menschen eigentlich nie vorher “auf dem Radar” haben. Wenn ich an meine Zeit bei meiner Firma zurückdenke so sind eigentlich alle ungeplanten Downtimes von Ereignissen verursacht worden, die so noch nie vorher aufgetreten waren - und die somit wirklich “unerwartet” im eigentlichen Sinne des Wortes darstellten. Ausfallende Festplatten? Kennen wir, haben wir im Griff. Die Überflutung einer ganzen Stadt? Unwahrscheinlich. Zwei EMP-Bomben, eine pro Rechenzentrum, kombiniert mit einem Luftangriff auf die Bank, in der Backup-Bänder liegen? Ha, ha! In letzter Instanz sind es halt immer wir Menschen, die Design-Entscheidungen treffen, und es liegt in der Natur eines “black swan”, daß wir auch bei der ausgefeiltesten FMEA nur die Dinge in Betracht ziehen, die unserem Vorstellungsvermögen, angereichert durch Jahre der Erfahrung, in den Sinn kommen. Auch lassen uns bei der Vorbereitung auf solche Ereignisse die althergebrachten Methoden vollkommen im Stich, denn für viele Vorfälle macht es nicht einmal Sinn, sie auch nur statistisch zu betrachten. Was ist die mittlere Zeit zwischen zwei Terror-Anschlägen auf unser Rechenzentrum? Keine Ahnung. Es ist ein bißchen wie in der Fliegerei: Die nationalen Aufsichtsgremien in Europa und Nordamerika haben in jahrzehntelanger Kleinarbeit so gut wie jeden denkbaren erwarteten unerwarteten Vorfall erlebt, untersucht und ihre Schlüsse daraus gezogen. Wenn man heutzutage also den Bericht zu einem Flugzeugabsturz liest, dann steht da selten “Triebwerk zwei ist ausgefallen”, nein, fast immer liest sich der Bericht wie eine vollkommen verrückte, unglaublich weit hergeholte Aneinanderreihung absolut unerwarteter Ereignisse (“Weil die Staurohre zur Geschwindigkeitsermittlung zugefroren waren hat der Steuercomputer des Airbus zugelassen, daß der Pilot das Flugzeug in einen Flugmodus gebracht hat, der ultimativ zum Strömungsabriss geführt hat. Die akustische und visuelle Warnmeldung, daß genau das passiert ist, hat der Pilot ignoriert, weil die Vorstellung, der Bordcomputer könne diesen Flugmodus zulassen, außerhalb seines persönlichen Erfahrungsschatzes lag.”)

Was können wir also tun? Nun - eigentlich gar nichts. Man bringt den Fehler in Ordnung, entschuldigt sich bei Kunden und Geschäftspartnern, zahlt Entschädigungen und macht weiter. Als Operations-Abteilung hat man jedoch eine weitere Aufgabe: Sicherzustellen, daß das nächste mal, wenn dieser Schwan sein hässliches Haupt erhebt, die Auswirkungen geringer sein werden. Eine Möglichkeit, dies zu tun, die für uns gut funktioniert - wenn wir sie auch nie so genannt oder formalisiert haben - stammt vom Gründer der Autofirma Toyota, Sakichi Toyoda. Es handelt sich dabei um die 5 Whys, eine Methode, die dabei helfen soll, die eigentliche Ursache eines Ereignisses, engl. root cause, heraus zu finden.

Betrachten wir ein reales Beispiel: Der Umzug eines Oracle RAC-Clusters auf modernere Hardware. Vier Server, vier SAN-Switches, zwei Storage-Systeme. Die neue Hardware wurde aufgebaut, in Betrieb genommen, konfiguriert, man hat mit der Datenbank Last- und Failovertests gefahren und sie im vorletzten Schritt als sog. physical standby-Datenbank für den bestehenden RAC-Cluster konfiguriert. Mit einem Software names Data Guard wurde dann die Umschaltung vorgenommen - alles kein Problem. In den Tagen nach der Umstellung vielen in den Performance-Auswertungen immer wieder grobe I/O-Wartezeiten auf, die so auf der alten Hardware nicht vorhanden waren. Das ganze gipfelte Dann irgendwann an einem Feiertag in einer wahren Benachrichtigungsflut des Monitoring-Systems, welches den Kollegen, der Bereitschaft hatte, darüber informiert hat, daß die Datenbank sich soeben beendet hatte und gerade dabei war, neu zu starten. Sowas liest natürlich kein DBA gern, und so hat der Kollege unverzüglich mit der Fehlersuche begonnen. Der erste Hinweis fand sich in den Logfiles der ASM-Instanz: Beim Versuch, einen I/O-Vorgang auf beiden Storages (Oracle-Speech: “in beiden Failure Groups”) vorzunehmen, hat das System über 15 Sekunden lang keine Rückmeldung von der Storage erhalten und deswegen beide Disks - eine pro Failure Group - offline gesetzt. Da die Disks für den Betrieb der Datenbank unerlässlich sind, hat sie sich dann beendet. Die nächste Station in der Fehlersuche waren dann natürlich die Storage-Systeme, hier fanden sich aber keine Hinweise auf Fehler. Also hat sich der Kollege die SAN-Infrastruktur vorgenommen, und siehe da, hier wurde er fündig: Zu den Zeitpunkten, an denen die Datenbank I/O-Probleme hat, haben sich die Switches darüber beschwert, daß auf den Verbindungen, mit denen die Switches untereinander kommunizieren, massive Latenzen aufgetreten sind. Nach einem langen Service Request beim Hersteller konnte schließlich eine Lösung gefunden werden: Durch das Hinzufügen von weiteren Verbindungen zwischen den SAN-Switchen konnte das Problem behoben werden. Interessanterweise hatte die alte SAN-Installation kein Stück mehr ISL-Kapazitäten und war trotzdem nie von dem Problem betroffen. Die genau Klärung steht noch aus, aber am wahrscheinlichsten ist, daß die neue Hardware allgemein leistungsfähiger war: Die Daten wurden auf deutlich mehr Spindeln verteilt und die Server hatten deutlich mehr Durchsatz und einen deutlich performanteren Cluster-Interconnect. Das alles führte wohl dazu, daß von den SAN-Switchen deutlich mehr verlangt wurde. Wenn man jetzt den Fakt bedenkt, daß das Problem während der Testläufe nicht entdeckt wurde, dann hat man eine gutes Beispiel für 5 Whys:

Die Datenbank zeigt ungewöhnliche I/O-Waitstates bzw. setzt Disks offline.
Warum? Die ASM-Instanz läuft nach 15 Sekunden in einen Timeout.
Warum? Die SAN-Switches zeigen extreme Latenzzeiten auf den ISL-Port.
Warum? Die ISL-Kapazität auf den SAN-Switchen ist zu gering. Dieses Problem wurde beim Testen jedoch nicht erkannt.
Warum? Während der Testläufe war das normale Monitoring der Logs nicht aktiviert. Ferner waren die SAN-Switches nicht für eine automatische Benachrichtigung über Probleme konfiguriert.
Warum? Für Testläufe erschien eine Betrachtung der DB-Logs mit “Augapfel Mark I” ausreichend. Ferner hatten wir auf der alten Datenbank - und allgemein bei keinem SAN-Fabric - jemals Probleme dieser Art gehabt, so daß es keine Vorschriften gab, wie die SAN-Switches abseits der essentiellen Dinge zu konfigurieren sind.

Somit ist klar, wie wir verhindern werden, daß dieser schwarze Schwan jemals wieder seinen Schnabel drohend über unseren Häuptern kreisen lässt: Klare Richtlinien, was an SAN-Switchen eingestellt wird und aktivieren des normalen Monitorings auch bei Testsystemen. Aber hätten wir das vorher wissen oder ahnen können? Dieser eine Vorfall hat uns wahrscheinlich in einer Woche mehr Uptime gekostet als wir das ganze vorhergehende Jahr verbuchen mussten. Und hier zeigt sich wieder, wie wenig uns die Statistik helfen kann: Die Anzahl der Minuten, die wir im Vorjahr offline waren, sagt leider gar nichts über das laufende Jahr aus. Und die Frage “Wie oft kommt es pro Monat vor, daß ein SAN-Fabric zu wenig Interconnect-Kapazität hat?” macht in diesem Kontext exakt gar keinen Sinn.

Es gibt sie wirklich, diese grüne Wiese, die man erreichen kann, wenn man sicher ist, jeden planbaren Ausfall beim Design der eigenen Systeme in Betracht gezogen zu haben. Es ist nur, bildlich gesprochen, kein guter Ort, ein Haus zu bauen. Es ist vielmehr der Umgang mit den schwarzen Schwänen, der zeigt, ob wir professionell handeln oder nicht. Dazu gehört, wie wir gegenüber unseren Kollegen und Kunden im Angesichts eines Ausfalls auftreten aber auch, welche Maßnahmen wir treffen, um sicherzustellen, daß so etwas nie wieder passiert. Wie so oft in der IT wird man auch hier “im Angesicht des Untergangs” (gut, das ist zu dramatisch, sagen wir, “im Angesicht des brennenden Schiffs”) gemessen, gewogen, und wenn man gut ist, für schwer genug befunden.

In diesem Sinne noch einen schönen Rest-Sonntag. Ich werde mich jetzt Beethoven zuwenden, genauer der “Apassionata”.