Digital souverän dank Datensicherung und Backup

Im Klartext bedeutet dies, dass zentrale Werkzeuge von hoher strategischer Relevanz eher nicht in die Hände Dritter gehören, jedenfalls nicht so uneingeschränkt, wie es im hier beschriebenen Fall geschah. Wenn Sie es einem Aussenstehenden überliessen, ob Ihre Fahrzeuge fahren oder nicht oder ob Ihre Verwaltungssoftware bereit steht, dann sind Sie in Ihrem betrieblichen Handeln nicht „souverän“.

Natürlich gibt es keine absoluten, 100 prozentigen Lösungsansätze, die alle Kriterien abdecken. Dennoch haben Sie es in der Hand, für welchen Lösungsansatz oder Anbieter Sie sich entscheiden. Wenn wesentliche Kriterien nicht Ihren Ansprüchen genügen, dann sollten Sie eine Alternative suchen. Und die gibt es, auch in der Digitalisierung von Geschäftsprozessen.

„Ab in die Cloud“ als riskante Zwangsmaßnahme

Im Fall von Atlassian war es übrigens so, dass der Anbieter für die genannten Softwarelösungen bis vor kurzem noch zwei Varianten zur betroffenen Cloudlösung anbot. Einmal die sogenannte On-Prem-Lösung (also zum selber betreiben auf dem eigenen Server) und die DataCenter-Lösung. Diese beiden Betriebsmodelle wurden aufgegeben bzw. durch eine preislich extreme Kostenerhöhung für den Kunden unrentabel gemacht. Der Anbieter drängte also seine Kunden in die Cloud bzw. in ein typisches „Software as a Service (SaaS)“ Modell. Damit lässt sich zwar viel Geld einsparen (und noch mehr verdienen). Jedoch ist die Betriebssicherheit der verwendeten Systeme sehr oft nicht vergleichbar mit einer professionellen Hosting-Lösung. Denn es handelt sich meistens um ein integriertes Gesamtsystem, dessen Ressourcen sich viele oder alle Kunden teilen.

So ist „die Cloud“ entgegen der allgemeinen Wahrnehmung überhaupt nicht so extrem sicher und stabil im Betrieb, wie der initiale Ausfall und die mehr über viele Tage gehende Auszeit zeigen. Aber warum ist das so bzw. was ist hier geschehen?

Daran hat’s gelegen

Die eigentliche Ursache war laut Anbieter ein Fehler in einem Service-Script für die Systembereinigung. Dadurch löschte man nicht etwa wie geplant ausschließlich nicht mehr benötigte Daten. Man verschob sowohl diese in den „Kernspeicher“ –  wir vermuten, dass damit eine „Papierkorb-Funktion“ gemeint ist – als auch andere wichtige Daten. Zum Beispiel Zugangsdaten, Profile und mehr. Das führte letztlich zum Ausfall. Wie bereits beschrieben war das Resultat, dass alle betroffenen Kunden, das sind ziemliche viele und auch große, tagelang ohne Ticketsystem und Wikis für ihr Prozessmanagement dastanden.

Fehler können passieren

Solche Programmierfehler sind schon jedem untergekommen, der programmiert hat.Was aber zum Handwerk eines jeden Programmierers gehören sollte, fängt mit ausgiebigen Testen an, geht mit Zwischentest weiter und hört mit abschließenden Tests auf. Das ist ganz offensichtlich hier nicht passiert. Ob es nun vergessen wurde oder ob es keine Testumgebung gab, ist nicht bekannt und auch gänzlich irrelevant. Denn dieses Serviceskript hätte so niemals eingesetzt werden dürfen. Erschwerend kam hinzu, dass das Team, welches den Prozess plante, nicht mit dem Team kommunizierte, welches die geplanten Service-Arbeiten durchführen sollte.