BA-Mega-Crash: "Es gibt vor allem ein spekulatives(!), aber plausibles, Szenario"

Was steckt hinter dem globalen IT-Crash bei British Airways? André Oppermann, akkreditierter Tier Designer beim renommierten Uptime Institute im Interview über mögliche technische Ursachen und Manager-Fehler.
 
Ein nicht spezifizierter Stromausfahl, so der BA-CEO – ein "power supply issue" – soll die IT der Fluglinie zwischen Samstag und heute mittag global in die Knie gezwungen haben. Gerüchte schiessen ins Kraut. Ist die Begründung plausibel?
 
Als erstes stellt Senior Datacenter Engineer und Accredited Tier Designer #573 beim Uptime Institute, André Oppermann, eines klar: "Ich verfüge selber über keine vertieften Hintergrundkenntnisse zur IT von British Airways. Jedoch kann ich aufgrund meiner Erfahrung im Bereich Datacenter (seit 1998) und meiner Qualifikation Aussagen zur Plausibilität machen."
 
So beantwortete der Geschäftsführer von Internet Business Solutions einige Fragen.
 
inside-it.ch: Ist es plausibel, dass ein Stromzufuhrproblem zu einem derartigen Crash führen kann?
André Oppermann: Grundsätzlich ist das als Ursprung möglich, jedoch werden bei jedem Datacenter umfassende Massnahmen vorgesehen und getroffen damit dies nicht passiert, bzw. die Auswirkungen abgefangen werden. Daher die redundanten Stromversorgungen mit unterbrechungsfreier Stromversorgung (USV) und Notstromgeneratoren, falls ein Netzausfall eintritt. Es muss immer auch eine weitere Verkettung von unglücklichen Umständen involviert sein. Gleich wie bei einem Absturz eines westlichen Linienflugzeugs.
 
Gemäss den Informationen hat British Airways zwei RZ in der Region London-Heathrow. Die sollten sich normalerweise auf der Hardware-Ebene eine gegenseitige Redundanz bieten und die Wahrscheinlichkeit eines gleichzeitigen Ausfalls sollte extrem gering sein. Der Ausfall eines RZ dürfte bei einer entsprechenden Server- und Software-Redundanz (Active/Active oder Active/Hotspare) über die beiden RZ Standorte keine signifikanten Auswirkungen haben. Im schlimmsten Fall dauert es ein paar Stunden bis die Applikation am Zweitstandort mit den gespiegelten Daten manuell hochgefahren werden.
 
In der Region London-Heathrow gab es allerdings am 27. Mai 2017 sehr intensive Gewitter mit einer sehr hohen Blitzintensität (beim Link als Datum 27.5.2017 mit 24h-Loop einstellen, Anm. d. Redaktion).
 
Ein solch heftiges Gewitter ist natürlich ein heftiger Test für die Dichtigkeit des Gebäudes, die Infrastruktur und die Blitzschutzmassnahmen eines RZ. Wenn die Anbindung an das öffentliche Stromnetz keinen ausreichend funktionierenden Blitzschutz haben sollte, so ist es durchaus denkbar, dass es zur Zerstörung der USV-Anlagen kommen könnte.

Nicht zu vergessen sind auch die üblichen, aussen aufgestellten Kältemaschinen auf den Dächern mit ihren Steuerungen und metallischen Rohrleitungen. Bei ungenügenden Blitzschutzmassnahmen und einem direkten Blitzeinschlag kann praktisch die ganze Elektronik der gesamten Kälteversorgung zerstört werden. Zudem kann der elektromagnetische Impuls über die Kühlwasserleitungen bis in das RZ eindringen und auch dort weitere Schäden durch Überspannung anrichten.
 
Ohne Kühlung lässt sich kein Server mehr betreiben. In einem dem Stand der Technik entsprechenden RZ sind zum Blitzschutz umfassende Massnahmen vorgesehen, so dass keine Schäden eintreten.
 
In der Region um Heathrow gibt es diverse kommerzielle Mega-Datacenter, welche keine Ausfälle vermelden. Dass beide RZ von British-Airways durch das gleiche Gewitter gleichzeitig ausfallen ist sehr unwahrscheinlich, aufgrund der geringen Distanz von wenigen Kilometern aber auch nicht ganz auszuschliessen.

Aus meiner Sicht und Erfahrung gibt es vor allem ein spekulatives(!), aber plausibles, Szenario: Es gab beim primären RZ einen Schaden, beispielsweise durch Blitzschlag. Dieser führte zu einem plötzlichen Ausfall der dortigen Server. Der Applikations-Failover in das Backup-RZ hat nicht funktioniert, da entweder die Datenspiegelung nicht aktuell war, oder beispielsweise das Backup-System nicht auf dem gleichen System- und Konfigurationsstand ist und die vorhandenen Daten nicht einlesen kann. Oder es gibt versteckte Abhängigkeiten zwischen den Applikationen und dem Netzwerk, welche ein Hochfahren verhindern, da sie dazu fälschlicherweise wieder das ausgefallene primäre RZ benötigen.

Probleme dieser Art treten häufig auf, da in der Industrie nicht sehr oft umfassende Failover-Tests gemacht werden (Kosten und Risiko) und die Komplexität der Abhängigkeiten mittlerweile kaum noch überblickt werden kann. Kombiniert mit einem kürzlichen Outsourcing der Programmierung und des Unterhalts der Applikationen an einen externen Dienstleister (welche weiterhin bei British-Airways im RZ laufen), ist eine Verkettung der Umstände durchaus plausibel. Dies weil mit dem Outsourcing immer Know-How Verluste verbunden sind und es leider häufig schlecht dokumentierte System-Abhängigkeiten gibt. Da es ein extralanges Wochenende in UK war, dürften auch nur wenig Experten vor Ort verfügbar sein.

Eine so lange Recovery-Zeit für ein solch wichtiges System ist unüblich. Da muss etwas ganz Gravierendes aufgetreten sein. Z.B. ein Ausfall der Infrastruktur gekoppelt mit einem kleinen Datenverlust z.B. eines Near-Line Mirrors, der ein rasches Hochfahren des Ersatzsystems verhindert. Oder wenn das normale Personal aufgrund des extra-langen Wochenendes abwesend ist und tendenziell eher unerfahrene Kollegen die Stellung halten sind gut gemeinte "schnelle Rettungsaktionen" möglich, die aber die Sache nur noch komplexer machen. Der "Human Factor" spielt also auch mit und seltene, hochkomplexe Extremsituationen bedeuten enormen Stress mit der zugehörigen Wahrscheinlichkeit von Über- und Fehlreaktionen.
 
Ein bekanntes Beispiel wäre auch das Sunrise-Email vor einigen Jahren, als im RAID zu viele Harddisk gleichzeitig entfernt wurden, oder der grosse Ausfall bei Swisscom vor einem Jahr.
 
Flugzeugpiloten trainieren solche extremen Ausnahmesituationen regelmässig und umfassend im Simulator, da unmittelbar Menschenleben auf dem Spiel stehen. In der IT sind solche umfassenden Simulationen und Trainings eher selten. Vor allem auch wegen der Komplexität und dem Risiko eines unerwünschten Einflusses auf die produktive Umgebung.
 
Die grossen Anbieter Google, Youtube, Facebook, Netflix, Amazon usw. erreichen ihre hohe Verfügbarkeit nur, weil deren Applikationen, IT und Datacenter konsequent auf "fail anything at any time" inklusive von ganzen RZ ausgelegt sind. Dies wird mit einem sehr hohen personellen und finanziellen Aufwand, sowie hochqualifizierten Mitarbeitern erreicht.
 
Netflix hat ein internes Tool namens "Chaos-Monkey" als Open Source veröffentlicht. Dieses "terminiert" während der Arbeitszeit immer wieder zufällig ausgewählte redundante Systeme und Applikationen. Wenn die Redundanzen überall korrekt implementiert sind, dann merkt der Nutzer von diesem "Chaos" nichts. Für ein normales Unternehmen, welches IT als zu optimierende "Kosten" betrachtet, ist es natürlich schwierig, eine solch extrem hohe Verfügbarkeit langfristig aufrechtzuhalten. Die Frage ist dann, wie weit die IT zum Kerngeschäft eines Luftfahrtunternehmens gehört, beziehungsweise wie viel Vorsprung eine gut funktionierende IT und Logistik gegenüber der Konkurrenz bringt.
 
Ist es primär eine Geldfrage, redundante Systeme mit unabhängigen Stromzufuhr-Systemen zu unterhalten?
André Oppermann: Bei Wartung und Unterhalt kann kurzfristig immer gespart werden. Dafür sind ein paar Quartale später die Konsequenzen und Folgekosten umso grösser. Alle technischen Versorgungseinrichtungen (Strom, Kälte) müssen mindestens einmal im Quartal auf ihre Funktionstüchtigkeit und Leistung geprüft werden. Insbesondere Batterien von USV-Anlagen und die Starterbatterien von Notstromgeneratoren sind empfindliche Komponenten die kurzfristig ihre Leistungsfähigkeit verlieren können. Bei rotierenden USV-Anlagen sind die Lager und Kupplungen die Schwachstellen. Die drei häufigsten RZ Ausfallursachen sind a) Fehlhandlungen durch Personal; b) Anlagenausfälle durch fehlende oder mangelhafte Wartung; c) zu hohe Komplexität der Anlagen (siehe wieder (a)). Unvorhergesehene äussere Einwirkungen (höhere Gewalt) kommen nur äusserst selten vor.
 
Wir haben den Eindruck, solche Probleme treten vermehrt auf. Ist dies korrekt?
André Oppermann: Es macht den Anschein. Wobei Ausfälle aus den genannten und sonstigen Gründen schon immer vorgekommen sind. Die Auswirkungen sind in der heutigen "24x7-Online-Zeit" allerdings viel gravierender und viel stärker von aussen sichtbar. Mein Eindruck ist, dass einerseits aufgrund der Profit-Center-Strukturen in vielen Unternehmen bei den Kosten, sprich Test, Wartung, Erneuerung und Dokumentation, gespart wird. Dies rächt sich entsprechend nach einiger Zeit.
 
Selten wird eine umfassende Risiko- und Auswirkungsanalyse inklusive entgangenem Gewinn und Reputationsverlust durchgeführt, oder nicht mehr aufgrund neuer Gegebenheiten aktualisiert. Im diesem Fall bei British Airways dürfte der materielle und immaterielle Schaden durch diesen Ausfall vermutlich im zwei- bis dreistelligen Millionenbereich liegen.
 
Da stellt sich dann immer die Frage, ob man am richtigen Ort gespart hat. Diese lässt sich natürlich nur im Nachhinein mit etwas Glück oder Pech genauer beantworten. Umgekehrt kann man in der IT leider auch unbegrenzt viel Geld mit magerem Ergebnis ausgeben.
 
Ein weiterer häufiger Grund für aufgeschobene Wartung oder Investitionen sind Outsourcing-Pläne in ein kommerzielles Datacenter oder in die "Cloud". Der Unterhalt und Erneuerungen werden minimiert, sobald das Thema in der Geschäftsleitung aufkommt und noch gar nicht spruchreif ist. Bis eine tatsächliche Strategie vorliegt und die Migrationen dann auch wirklich stattfinden, vergehen üblicherweise mehrere Jahre.
 
Zusammen mit dem üblichen Trigger bei diesem Thema, hohen anstehenden Ersatzinvestitionen (d.h. die Infrastruktur muss für einen weiterhin zuverlässigen Betrieb bald erneuert werden), steigt das Risiko für einen Ausfall jedes weitere Quartal entsprechend stark an. (Interview: Marcel Gamma)