Das habe ich vor vielen Jahren selber in der IT-Abteilung eines größeren Verlags einer Tageszeitung erlebt: Ein neues Diskarray soll in Betrieb genommen werden und aus Sicherheitsgründen will man es gleich auf ein baugleiches Modell in einem anderen Brandabschnitt spiegeln. Die Daten sind bereits überspielt, Dienstleister und Techniker des Array-Herstellers sind vor Ort. Aber am Anfang hat man Treiberprobleme und sieht in Folge immer nur eines der beiden Arrays, nämlich das mit den Daten, die leere Spiegelhälfte fehlt. Man experimentiert mit diversen Softwareversionen der Treiber und plötzlich sind alle LUNs da, die zu erwarten waren. OK, dann kann man ja jetzt auf dem leeren Spiegel die Platten partitionieren und formatieren und mit Filesystemen versehen und dann die Spiegelung starten. Kurzer Blick in die Runde, beifälliges Nicken, los geht’s.
Das war der Schritt in die Katastrophe. Skeptisch werden die versammelten Techniker erst, als die vorgebliche Synchronisation der Daten viel zu schnell über die Bühne geht. Angst kommt auf. Die neu erschienene zweite LUN verwies nämlich nicht auf das leere zweite, sondern ebenfalls auf das bereits gefüllte erste Array. Die Aktion löschte sämtliche Daten und zwar so gründlich, dass auch ein in der Panik hinzugezogener Datenretter nichts mehr ausrichten konnte. Am Ende musste man wochenlang Studenten damit beschäftigen, die wichtigsten Daten von Hand wieder einzutippen.
Was auch immer die technische Ursache war, ein Grund war ganz sicher: Allen beteiligten Admins war die Komplexität über den Kopf gewachsen, keiner hatte verstanden, dass die Gefahr einer Täuschung bestand, die man sorgfältig hätte ausschließen müssen, bevor man den potenziell zerstörerischen Schritt startete. Und dabei ging es damals nur um zwei direkt angeschlossene SCSI-Diskarrays, die man heute als klein einstufen würde und bei denen kein Virtualisierungslayer eine Rolle spielte.
Szenenwechsel. Die Pausengespräche gehören ja nicht selten zum Besten, was eine Konferenz bieten kann. Bei einer solchen Gelegenheit erzählt mir neulich ein Teilnehmer, der zentrale Speicher der Cloud-Infrastruktur seines Unternehmens sei korrupt. Womöglich ein Problem mit der Zuordnung der LUNs. Genau wisse das keiner und auch der verantwortliche Hersteller, der angeblich mit Hochdruck das Problem analysiere, sei ratlos. Hier geht es allerdings um sehr viel mehr Speicher als bei dem einfachen Array und um ein sehr viel größeres Unternehmen als den Verlag.
Doch die Ursache ist mindestens teilweise diesselbe: Niemand überblickt mehr die Zusammenhänge und damit auch nicht die Konsequenzen einer Entscheidung. Die Handlungsgrundlage ist schieres Gottvertrauen: Es wird schon funktionieren. Und wenn nicht? Darüber denken wir besser nicht nach. Denn weder gibt es eine Strategie, wie man das Problem systematisch eingrenzen und lösen könnte, noch kann man irgendwie auf andere Hardware ausweichen, noch kommt man ohne sie aus. Der Anwender sitzt rettungslos in der Falle.
Würde man diesen worst case einkalkulieren, wieviel attraktiver oder billiger wäre die schöne neue Cloudwelt dann wohl noch?
