Mehr Qualität und Geschwindigkeit bei DevOps

Know-how  –  2 Kommentare

Ob sie es nun DevOps oder anders nennen: Viele Unternehmen folgen penibel bestimmten Anleitungen, um Entwicklung, Test und Deployment von Software aktuellen Anforderungen anzupassen. Doch das führt nur bedingt zu höherer Qualität und Geschwindigkeit, da individuelle Optimierungen fehlen. Zeit für eine neue Ausbaustufe von DevOps.

Branchengrößen wie Facebook, Flickr, Twitter oder Amazon gelten als Wegweiser für DevOps. Doch deren Vorgehen dürfen andere Unternehmen nicht einfach nachahmen, denn sie besitzen eine andere Organisation, Firmenkultur oder Softwareausstattung. Stattdessen sollten sie bei der Planung von DevOps-Prozessen mit dem wichtigsten Ziel beginnen, der schnelleren Auslieferung von Software, ohne dabei die Qualität zu gefährden. Das müssen die Entwicklungs-, Test- und Betriebsteams gemeinsam verinnerlichen. Tools können sie dabei unterstützen, die Aufgaben entlang der Prozesskette effizienter zu automatisieren.

Initial war DevOps ein gutes Mittel, um die Beteiligten auf die Notwendigkeit für Veränderungen hinzuweisen, die aus der schlanken Produktionsweise seit den 1980er-Jahren resultierte. Doch nun erfordern neue Trends wie "Your App is Your Brand", Internet der Dinge und Industrie 4.0 die nächste Evolutionsstufe von DevOps, da sich durch DevOps 1.0 zwar im Durchschnitt die Lieferzeit von Software verkürzt hat – es aber nun vermehrt zu Qualitätsproblemen kommt, die Nutzer direkt spüren – etwa dass Dienste wie Facebook down sind – oder in den Nachrichten lesen – etwa United streicht Tausende Flüge nach Softwareupdate.

DevOps 2.0 verlangt von jedem Techniker, sein Wissen und Können auf verantwortliche Weise für das Endprodukt einzusetzen. Sogenannte War Rooms, in die sich das Team und verschiedene Experten einige Tage zurückziehen, um Lösungsszenarien auszuarbeiten, müssen dabei eine Ausnahme bleiben. Das lässt sich durch einen Fokus auf Qualität über den gesamten Softwarelebenszyklus erreichen: angefangen bei den Anforderungen, dann in der Entwicklung und beim Testen sowie schließlich in der Live-Stellung und im Betrieb – und das möglichst automatisiert.

Und tschüss, War Room!

Das Ausbessern von Fehlern in der Produktivphase ist eine teure Angelegenheit. In einem typischen War Room sitzen viele Führungskräfte und Experten tagelang in einem Zimmer und analysieren Log-Files. Diese Zeit geht für das Entwickeln neuer Funktionen verloren. Stattdessen investieren die Involvierten alleine in den USA etwa 60 Milliarden Dollar jährlich für das Beheben der Probleme von gestern (Quelle: NIST).

Entsprechend sollten Unternehmen ihre bislang womöglich monolithischen Architekturen durch Continuous-Delivery-Prozesse ersetzen. Eine Weiterentwicklung des Qualitätsansatzes durch DevOps-Metriken ist nötig, um Probleme so früh wie möglich in der Entwicklungsphase zu identifizieren. Das wird im Englischen häufig als "Shift Left" bezeichnet, also die Erweiterung des Qualitätsansatzes nach links in der Zeitleiste.

Eine Welt ganz ohne War Rooms wird es zwar nicht geben, aber sie lassen sich in vielen Fällen vermeiden. Basierend auf praktischen Erfahrungswerten aus der Problemursachenforschung von hunderten Kunden lässt sich sagen, dass 80 Prozent der Fehler im Produktionsbetrieb von lediglich 20 Prozent der Fehlermuster verursacht werden. Dazu zählen zum Beispiel ein falsch gewähltes Framework, ineffizienter Datenbankzugang, zu großzügige Speicherzuweisungen, CPU-Spitzen verursachende Algorithmen, ungeeignete Synchronisierung gemeinsam genutzter Ressourcen oder ewiges Loggen.

Um diese Probleme frühzeitig zu identifizieren, sind passende Architekturmetriken zu ermitteln. Das beginnt beim Starten der Entwicklermaschine, noch bevor der Code eingegeben wird, und seiner Automatisierung in Continuous Integration durch Unit- und Integration-Tests. Eine Architekturmetrik für die Webentwicklung bildet zum Beispiel die Anzahl der Ressourcen auf einer Seite, wie Bilder, JavaScript oder CSS. Ein Entwickler sollte in den Browser integrierte Diagnose-Tools nutzen, um zu gewährleisten, dass die Seite nicht durch zu viele Elemente überladen wird. Die gleiche Metrik lässt sich mit einem Selenium-Test bei der Continuous Integration verifizieren.