DevOps, APM und der Single Point of Failure

Inhaltsverzeichnis

DevOps ist derzeit eines der großen Buzzwords in der IT. Aber warum scheitern die DevOps-Bemühungen in vielen Unternehmen? Oder warum enden viele in einem Kompromiss, in DevOps light? Tools für das Application Performance Management können dabei helfen, eine erfolgreiche DevOps-Kollaboration zu etablieren.

Laut der Wikipedia vollzieht DevOps Maßnahmen, um häufige Bruchstellen zwischen Anwendungsentwicklung und IT-Betrieb zu überwinden. Das weist indirekt darauf hin, dass DevOps einen Kulturwandel in der IT bewirkt. Es ist die Rede vom "Überwinden von Bruchstellen". Und nicht von einem "das habe ich schon immer so gemacht, das muss deshalb gut sein!". Warum aber ist das Vorgehen von früher heute nicht mehr richtig, beziehungsweise warum erfüllt es nicht mehr die Anforderungen? Oder warum gibt es DevOps überhaupt, und wobei soll es helfen?

Single pane of glass oder Single glass of pain?

Unternehmen streben zunehmend nach dem "single pane of glass", also einer einzigen, verbindlichen Sicht auf ihre IT. Das zu erreichen ist recht einfach, wenn man eine IT-Umgebung als Monolith plant und an ihr die nächsten Jahre nichts ändert. Dann muss sich der Betrieb nur auf das Bereitstellen einer fest definierten Umgebung beschränken, und die Entwicklung hat ihr festes Korsett, in dem sie sich austoben kann.

Meist befinden sich Firmen jedoch in einem "single glass of pain", einer gewachsenen Infrastruktur mit einer Vielzahl von Applikationen. Es beginnt da, wo es neue, komplexe, nicht vorher planbare Anpassungen an die Umgebung oder an die Applikationsfunktionen geben muss, um den sich ändernden Geschäfts- oder Nutzeranforderungen gerecht zu werden.

Das Zauberwort heißt dann "Agilität", also agile Entwicklung und agiles Deployment. Die IT-Abteilung muss flexibel auf neue Anforderungen in der Entwicklung reagieren und diese zeitnah umsetzen. Ebenso sollen die neuen Anwendungsreleases umgehend im Produktivsystem ausgerollt werden, damit schnell der erhoffte Mehrwert für das Geschäft erzielt wird.

Warum scheitert DevOps?

In der Theorie klingt das logisch und einfach. Aber warum scheitern in vielen Unternehmen die DevOps-Bemühungen? Oder warum enden manche in Kompromissen – in DevOps light? Um das zu erkennen, hilft ein Blick auf die althergebrachten Rollen, Zuständigkeiten und dadurch verursachten Bruchstellen innerhalb der Unternehmens-IT: Der IT-Betrieb steht in der Verantwortung, eine Anwendung dem Nutzer jederzeit schnell zur Verfügung zu stellen.

Er ist aber auch der erste Anlaufpunkt, wenn es um Beschwerden geht, etwa weil eine Anwendung nicht verfügbar ist oder eine schlechte Performance aufweist. Um dieses Risiko und den Aufwand für die "Beschwerdestelle" zu minimieren, hat der IT-Betrieb – basierend auf Erfahrungen und Best Practices – Methoden und Sicherheits-Gates etabliert. Diese reduzieren die Wahrscheinlichkeit eines Ausfalls oder von schlechter Performance auf ein Minimum. Hierzu gehören funktionale und nichtfunktionale Tests sowie redundantes oder phasenweises Deployment.

Betriebssicherheit versus Agilität

Bei Betrachtung der Verantwortung, die der IT-Betrieb gegenüber dem Geschäftsbetrieb hat, sind diese Maßnahmen durchaus sinnvoll. Allerdings verbindet man umfängliche Tests und stufenweises Deployment selten mit dem Begriff der Agilität. Hier zeigt sich ein erstes Spannungsfeld, das Potenzial hat zur Bruchstelle zwischen Entwicklung und Betrieb zu werden. Denn die Erstere hat den Auftrag, schnell neue Funktionen umzusetzen – der Betrieb bringt sie aber nicht im gleichen Maße schnell in den Produktivbetrieb.

Zudem haben neue Funktionen oft zur Folge, dass die dafür notwendige Umgebung komplexer und umfänglicher wird. Deshalb benötigt man in der Regel einen neuen externen Service oder noch eine Schnittstelle. Außerdem sind die zusätzlich übertragenen Daten noch durch die Firewall zu schleusen. Das alles macht den Betrieb komplexer: Ist man zum einen abhängig von externen Services, sind zum anderen Wechselwirkungen zwischen den einzelnen Services verlässlich zu bewerten.

Entwicklung versus Betrieb

Ein Beispiel: Der Autor war einmal Teil einer Taskforce, die ins Leben gerufen wurde, weil es einen Ausfall in einer geschäftskritischen Applikation gab. Vor dem Ausfall der Anwendung hatte man im Unternehmen die Entscheidung getroffen, vorerst in die Entwicklung neuer Funktionen zu investieren. Die Modernisierung der Router-Netzanbindung wurde auf das nächste Quartal verschoben. Die Taskforce fand allerdings heraus, dass die Router durch die häufige Nutzung der neuen Funktionen der Datenmenge nicht mehr gewachsen waren und der Paketverlust die Applikation unter Performancegesichtspunkten "unbrauchbar" machte.

Ist das nun ein Problem der Entwicklung, weil sie die Bandbreiten beim Erstellen der neuen Funktion nicht berücksichtigt hat? Oder hätte stattdessen der Betrieb besser die Auswirkung der neuen Funktion überprüfen müssen? Die Wahrheit liegt wohl irgendwo dazwischen.