DevOps

Die Erhebung „State of DevOps“ des Forschungsprogramms DORA ordnet Teams nach Veröffentlichungshäufigkeit: Spitzenteams liefern auf Abruf mehrmals am Tag aus, die starke Gruppe täglich bis wöchentlich, die schwächste im Abstand von Wochen bis Monaten. Diese Häufigkeit ist ein Ergebnis, kein Ziel – sie steigt, sobald ein kleines Paket ohne Handarbeit live gehen kann. Wer nur häufiger veröffentlicht, ohne den Weg dahin zu automatisieren, verschiebt dieselbe Arbeit auf mehr Termine.

DevSecOps zieht die Sicherheitsprüfung in denselben automatisierten Lauf, der ohnehin testet und ausliefert: Abhängigkeiten gegen gemeldete Schwachstellen prüfen, Zugangsdaten im Quellcode suchen, Rechte der Zielumgebung kontrollieren. DevOps trifft darüber keine Aussage. Ein solcher Lauf kann monatelang ohne Abbruch durchgehen und dabei eine Bibliothek mit bekannter Schwachstelle mitschleppen, weil niemand diesen Schritt eingebaut hat. Das zweite Kürzel benennt deshalb keine andere Arbeitsweise, sondern die fehlende Prüfung.

Aussagekräftig ist die Fehlerquote der Auslieferungen – der Anteil, der eine Nachbesserung oder einen Rückbau erzwingt. Sekundärdarstellungen des DORA-Programms nennen für Spitzenteams übereinstimmend rund fünf Prozent; für die schwächeren Gruppen gehen sie weit auseinander, von 40 bis 64 Prozent, und im Primärbericht sind diese Werte nicht öffentlich nachlesbar. Gerechnet wird ohne Werkzeug: zwei misslungene von zwanzig Auslieferungen sind zehn Prozent. Wächst dieser Wert mit der Zahl der Auslieferungen, sind die Pakete zu groß oder die Tests zu dünn – nicht das Tempo zu hoch.

Drei sind die praktische Untergrenze, und diese Zahl folgt aus dem Arbeitszeitgesetz statt aus dem Werkzeug. § 5 Absatz 1 ArbZG verlangt eine ununterbrochene Ruhezeit von mindestens elf Stunden; die Ausnahme, nach der ein Rufbereitschaftseinsatz sie nur kürzt, gilt nach Absatz 3 ausdrücklich für Krankenhäuser und Pflegeeinrichtungen, nicht für Softwareteams. Weil die Ruhezeit ununterbrochen sein muss, verschiebt ein Einsatz um drei Uhr den Arbeitsbeginn auf 14 Uhr.

DevOps lohnt sich nicht, wenn eine Website nach dem Livegang faktisch unverändert bleibt. Die Arbeitsweise ordnet den Fluss von Änderungen; wo im Jahr zwei Textkorrekturen anfallen, gibt es keinen Fluss zu ordnen, und die Automatisierung wird selbst zum Wartungsposten: Laufzeitumgebung, Abhängigkeiten und Zugangsschlüssel veralten, ob etwas läuft oder nicht. Nötig bleiben dann die Aktualisierungen des Unterbaus – dafür genügt ein fester Termin im Kalender.

Drei Angaben entscheiden, und alle drei stehen in der Oberfläche der Auslieferungskette: Wann lief die Auslieferung zuletzt durch, wann wurde eine Wiederherstellung zuletzt geprobt, und wer besitzt die Zugangsschlüssel. Ein grüner Haken belegt nur, dass der Lauf ohne Abbruch endete – nicht, dass ein Test etwas geprüft hat. Wir finden bei Übernahmen regelmäßig Sicherungen, die seit Monaten leer liefen, und abgeschaltete Testschritte, mit denen eine Veröffentlichung durchgedrückt wurde.