IT DevOps neu gedacht

„Viele Unternehmen existieren aufgrund von Anwendungen. Und das bedeutet, dass die Anwendungsleistung neben dem Umsatz die wichtigste Messgröße ist“, sagt Chris Farrell, Vice President of Automation Value Services Software bei IBM. „Wenn Ihre Anwendung Ihr Geschäft ist, ist Geschwindigkeit sowohl eine Waffe als auch ein Indikator für die Qualität Ihrer Anwendung.“

In dieser Welt des Hyper-Deployments ist es laut Farrell entscheidend, dass die Unternehmen ihre Vorstellungen von kontinuierlicher Integration und kontinuierlicher Bereitstellung (CI/CD) überdenken. „Anstatt über die Anzahl der Tage zwischen den Bereitstellungen zu sprechen, sollten Sie über die Anzahl der Aktualisierungen pro Zeitraum sprechen“, sagt er. „Je kürzer der Zeitraum ist, desto mehr Fortschritte machen Sie.“

Die IBM-Reihe „Rethink & Automate“ lädt Führungskräfte dazu ein, gängige Geschäftsabläufe und IT-Prozesse anhand eines Greenfield-Ansatzes neu zu gestalten und die Automatisierung zu fördern. Der typische DevOps-Prozess ist ein zyklischer Ablauf mit acht Schritten: Planung, Codierung, Erstellung und Testen, gefolgt von Freigabe, Bereitstellung, Betrieb und Überwachung. Wenn sich einer der acht Schritte verlangsamt, verlangsamt sich die gesamte Pipeline.

„Außerhalb der digitalen Welt ist die Verbesserung der Geschwindigkeit für große, etablierte Unternehmen möglicherweise noch wichtiger“, schreibt Hans A.T. Dekkers von IBM in „The speed of smarter architecture“, einem vom IBM Institute for Business Value veröffentlichten Beitrag. „Die durchschnittliche Lebensdauer der Unternehmen im S&P 500 ist von 60 Jahren (in den 1960er Jahren) auf weniger als 20 Jahre (heute) gesunken, mit einem sich beschleunigenden Trend zu noch höherer Fluktuation. Das zeigt uns, welche Auswirkungen Geschwindigkeit bzw. deren Fehlen hat.“

Entdecken Sie in einem kostenlosen Innovationsworkshop zur Automatisierung neue Ansätze für die Verbesserung Ihrer Abläufe im Bereich IT-DevOps.

Um CI/CD zu erreichen, müssen Entwickler ein Produkt einmal erstellen, es überall bereitstellen und die Pipeline ständig verwalten. Im Folgenden beschreibt Farrell, wie er den typischen Zyklus mithilfe von Automatisierung umgestalten würde. Dabei stellt er fest, dass alle Verbesserungen „ein vollständiges Bekenntnis zu DevOps und den Wunsch, eine kontinuierliche Bereitstellung zu erreichen, erfordern“.

Übergang von der Überwachung zu Observability

„Es mag überraschen, aber wenn ich den DevOps-Prozess von Grund auf neu konzipieren müsste, würde ich mich zuerst auf den letzten Schritt konzentrieren: die Überwachung“, sagt Farrell. „Man sollte sich von Tools aus dem traditionellen Überwachungsbereich trennen und so schnell wie möglich zu Observability übergehen. Denken Sie daran: Je mehr Workloads Sie beobachten können, desto schneller und präziser kann jedes Ops-Mitglied von einem Problem zu seiner Ursache gelangen, und zwar ohne Einbeziehung von Entwicklern und anderen Fachleuten.“

In der IT bezieht sich Observability auf Software-Tools und Verfahren zur Aggregation, Korrelation und Analyse eines stetigen Stroms von Leistungsdaten einer verteilten Anwendung sowie der Hardware und des Netzwerks, auf denen sie läuft. Auf diese Weise können Sie Fehler in der Anwendung und im Netzwerk effektiver finden und beheben. Observability ist eine natürliche Weiterentwicklung des Application Performance Monitoring (APM), um der zunehmend schnellen, verteilten und dynamischen Natur von cloudnativen Anwendungsimplementierungen besser gerecht zu werden.

Abgesehen von der Überwachung gibt es für jeden Schritt des DevOps-Prozesses bereits zahlreiche Tools, die den Ablauf beschleunigen, integrieren und automatisieren. „Herkömmliche Überwachungstools haben mit beschleunigten Pipelines und modernen Tech-Stacks zu kämpfen, insbesondere weil die manuelle Einrichtung, Neukonfiguration und/oder Neuverteilung die Dinge verlangsamen“, sagt Farrell. Die Observability-Plattform liefert Verständnis (Sichtbarkeit mit Kontext) und passt sich an alle Änderungen in Echtzeit an, sodass sie immer auf dem neuesten Stand ist.

Die Observability verbindet auch Anwendungen und Infrastruktur. Und das ist notwendig, da die Grenzen zwischen Anwendungscode, codebasierter Infrastruktur und Hardware-Stacks zunehmend verschwimmen. „Wenn man an den Bedarf an Geschwindigkeit in der gesamten Pipeline denkt, müssen die Plattformen genauso flexibel und schnell sein wie der Anwendungscode selbst“, sagt Farrell.

Automatisierte Observability für mehr Geschwindigkeit und bessere Ergebnisse

„Die Notwendigkeit der Observability ist eindeutig, aber sie muss automatisiert sein“, sagt Farrell. Eine automatisierte Observability-Plattform mit einer Analyse-Engine ermöglicht es, dass die Plattform selbst Erkenntnisse, Empfehlungen und Abhilfemaßnahmen für Probleme liefert. So entfällt der Zeitaufwand für die Problemdiagnose; sie erfolgt automatisch.

Die Automatisierung des gesamten IT-DevOps-Prozesses bietet neben der Geschwindigkeit eine Reihe weiterer Vorteile. Kontinuierliches Feedback bedeutet, dass Entwickler schnell und entschlossen Maßnahmen zur kontinuierlichen Verbesserung ergreifen können. Eine verbesserte Fehlererkennung ermöglicht es zudem, Fehler zu beheben, bevor sie „katastrophale“ Auswirkungen haben, wie Farrell es nennt. Und schließlich verbessert die Systemintegration die Teamzusammenarbeit, sodass alle IT- und DevOps-Experten innerhalb eines Teams Code ändern, auf Feedback reagieren und Probleme beheben können, ohne ihre Kollegen zu behindern.

Laut dem Bericht „DORA 2018 Accelerate: State of DevOps“ (Link befindet sich außerhalb von ibm.com) zeichnen sich „Spitzenunternehmen“ durch eine 46-mal häufigere Bereitstellung von Code, eine 2.555-mal kürzere Vorlaufzeit vom Commit bis zur Bereitstellung, eine 7-mal niedrigere Fehlerquote bei Änderungen und eine 2.604-mal schnellere Behebung von Zwischenfällen aus. Der exponentielle Nutzen häufigerer Bereitstellungen führt zu einer schnelleren Veröffentlichung neuer Software – und zu einer tausendmal schnelleren Behebung von Problemen. „Eine meiner bevorzugten Zusammenhänge ist die Verringerung der Fehlerquote bei Änderungen, selbst bei schnellerer Bereitstellung“, sagt Farrell.

Wenn Unternehmen alle acht Schritte des Prozesses automatisieren, können sie eine höhere Qualität und bessere Kundenzufriedenheit erwarten. Farrell sagt jedoch, dass sein bevorzugter Vorteil die Geschwindigkeit sei. „Ein gutes Beispiel, das ich beobachtet habe, war bei einer Bank. Es dauerte etwa 10 bis 12 Monate, bis eine Produktidee vorlag und das Produkt in Betrieb genommen werden konnte. Nachdem die Bank die neuen DevOps-Prozesse eingeführt hatte, verringerte sich dieser Zeitrahmen auf zwei Wochen“, berichtet er. „Man sieht die absoluten, direkten Ergebnisse des Erfolgs auf dem Markt.“