"Wir konnten die Ursache dadurch identifizieren, dass wir den Service-Anbieter kontaktierten und von ihm mitgeteilt bekamen, was genau geschehen war", sagt Rowe. "Um sich künftig vor derartigen Incidents zu schützen, wird künftig jedes Mal wenn ein analoger Netzfehler auftritt, eine Aktion ausgelöst, die den Anmeldevorgang umleitet und alle Partnerunternehmen informiert, dass der Service offline ist." Wenn man der ganzen Geschichte etwas Positives abgewinnen möchte, dann die Tatsache, dass den Entwicklern nun eigens Zeit und Geld zur Verfügung gestellt wurde, um auch die übrigen Systeme auf Schwachstellen zu überprüfen.

Menschen einfach vergessen

Als Brian Dawson, heute DevOps-Evangelist beiCloudBees, vor einigen Jahren im Auftrag einer US-Regierungsbehörde als Prozessberater für einen Hersteller tätig war, machte er erste Erfahrungen mit DevOps. Und zwar keine guten. Die Behörde startete ein wichtiges Web-Anwendungsprojekt. "Als Hersteller, der für das Lifecycle Management der Anwendung zuständig war, kümmerten wir uns um die Werkzeuge und Arbeitsabläufe für alle Projektschritte - Planung, Code-Entwicklung und Release - in einer kollaborativen und Open-Source-ähnlichen Weise", so Dawson.

Konfiguration und Einsatz der unterstützenden DevOps-Tools waren erfolgreich - "leider lassen sich DevOps nicht ausschließlich mit Tools umsetzen", warnt er. "Es braucht auch ein Augenmerk auf die beteiligten Menschen, Kulturen und Arbeitsabläufe."

Mehrere Teams hatten den Projektzeitplan strikt einzuhalten, der aber sehr eng gestrickt war - was die Projektleitung dazu veranlasste, sich auf die Tools-Plattform zu konzentrieren. Dawson: "Wir waren in der Lage, eine Plattform mit robusten agilen Planungswerkzeugenagilen Planungswerkzeugen, einem modernen Software Configuration Management und dem webbasierten Software-System Jenkins für die Integration der entwickelten Tools zu bauen." Alles zu Agile auf CIO.de

Bei all den schönen Tools ignorierte man jedoch die Menschen, die die Plattform später dann nutzen sollten. "Obowohl wir also eine DevOps-Plattform hatten, wurde sie lediglich als Unterstützung der alten eingefahrenen Arbeitsmethoden verwendet - die Entwickler scherten sich nicht um agile Methoden, die automatisierte Qualitätsprüfung wurde nie vollständig integriert, kaputte Versionen regten niemanden auf und Produktions-Workloads in produktionsähnlichen Umgebungen wurden nie ausgetestet."

Das führte dazu, dass es sofort zu sehr kritischen Fehlern kam, als die Web-Anwendung auf den Clients ausgespielt wurde - sie war schließlich niemals von "echten" Nutzern ausgetestet worden. Die Regierungsbehörde benötigte viele zusätzliche Wochen Entwicklungszeit, um die Website zum Laufen zu bekommen - erschwerend hinzu kamen in dieser Zeit die langsamen Antwortzeiten des Services.

Die technischen Schwierigkeiten waren so nach ein paar Monaten behoben - das Grundproblem konnte nach Dawsons Auskunft aber erst sehr viel später gelöst werden: Es mussten zuerst klare Project Owner benannt werden, um alle DevOps-Facetten auch im menschlichen und kulturellen Bereich abdecken zu können. Erst danach war die Behörde "vollständig bereit für DevOps."

Dieser Beitrag erschien im englischen Original bei unserer US-Schwesterpublikation InfoWorld.