Foto: Imagentle - shutterstock.com
Bei DevOps handelt es sich längst nicht mehr um einen Hype oder kurzfristigen Trend. Die Einführung und Realisierung sind geschäftskritisch. Weltweit führen Unternehmen DevOps Best Practice ein, um die Entwicklung und Markteinführung neuer Produkte zu beschleunigen, die betriebliche Effizienz zu steigern und die Kosten zu senken. So zeigt eine Studie, die Puppet und DORA auf dem DevOps Enterprise Summit 2017 in London veröffentlicht haben, dass der Anteil der in DevOps investierenden Unternehmen in den vergangenen drei Jahren von 16 auf 27 Prozent gestiegen ist.
Gartner zufolge befindet sich DevOps inzwischen unter den drei wichtigsten CIO-Initiativen und wird zur Kernfrage für CIOs. Die Analysten prognostizieren, dass bis 2020 die Hälfte der CIOs von Führungspositionen enthoben werden, weil sie die Fähigkeiten ihres Teams nicht dafür angepasst haben.
Die wichtigsten Gründe für DevOps
Doch warum ist DevOps für die künftige Strategie von CIOs so wichtig? Dafür gibt es vor allem folgende Gründe:
Schnellere Markteinführung neuer Produkte und Angebote
Höhere Betriebseffizienz
Geringere Kosten
Bessere Qualität der entwickelten Lösungen
Mitarbeiter-Bindung durch moderne Arbeitsprozesse
Schritt halten mit dem technologischen Wandel
Die meisten dieser Gründe sind selbsterklärend, doch häufig wird die verbesserte Bindung von Mitarbeitern übersehen. So empfehlen diese doppelt so häufig ihren Arbeitgeber weiter, wenn er aktuelle Technologien und Prozesse einsetzt, so der 2017 State of DevOps Report von Puppet und DORA. Dies ist vor allem angesichts des Fachkräftemangels ein entscheidender Punkt, um auch in Zukunft erfolgreich zu sein.
Die größten Herausforderungen
Die Einführung von DevOps ist keine leichte Aufgabe, denn sie erfordert nicht nur neue Technologien und Lösungen, sondern auch veränderte Prozesse und Organisationsstrukturen. Daher schrecken einige CIOs davor zurück. Aus diversen Kundengesprächen und Befragungen von Meeting-Teilnehmern haben sich folgende Punkte als größte Hürden herausgestellt:
Technische Komplexität: DevOps befürwortet, die beste technische Lösung für jedes Problem anzuwenden. Dieses Prinzip kann aber sehr schnell in einem Wildwuchs an Technologien und Tools enden, in dem man schnell den Überblick verlieren kann.
Schlechte Qualität: Häufig wird die Einführung von DevOps durch die Fachabteilungen vorangetrieben, weil diese von den schnelleren Entwicklungszeiten direkt profitieren wollen. Doch es muss dabei darauf geachtet werden, dass die Geschwindigkeit nicht die Qualität beeinträchtigt.
Zu viele Warnmeldungen: Je mehr Tools eingesetzt werden, desto zahlreichere Warnmeldungen erzeugen sie. Allerdings erfordern nicht alle Benachrichtigungen eine Aktion, daher sind wichtige von unwichtigen Meldungen zu unterscheiden.
Ablösung bewährter Prozesse: Dort bildet nicht nur das Change Management eine Herausforderung, sondern auch eine mögliche Überforderung durch die vielen zu ändernden Prozesse und Strukturen bis hin zu "IT-losen IT-Teams", wie bei einem hochautomatisierten IT-Betrieb ohne traditionelle Administratoren.
Technische Komplexität
Eine übliche DevOps-Praxis lautet: "Wählen Sie die Technologie, die Ihr Problem löst - aber lassen Sie sich nicht von Ihrer Technologie vorschreiben, welche Probleme es gibt oder wie sie zu lösen sind!"
Wenn jedoch zehn verschiedene Entwicklerteams zehn unterschiedliche Technologien auswählen, entsteht eine enorme Komplexität, die vom Betriebsteam verwaltet werden muss. Und gerade in der Produktionsumgebung sollten alle Teilsysteme einer Lösung reibungslos zusammenarbeiten.
Daher ist die Kompatibilität zwischen den Einzelkomponenten der Gesamtarchitektur schon in der Testphase zu prüfen. Dies ist derzeit meist nicht der Fall. So werden Code-Änderungen oft nur innerhalb der einzelnen Entwicklungspipelines in separaten, nachgebildeten oder verkleinerten Umgebungen getestet. Erfolgt der erstmalige gemeinsame Einsatz erst in der Produktion, sind Probleme vorprogrammiert.
Schlechte Qualität
Der 2017 State of DevOps Report belegt, dass DevOps-Prozesse tatsächlich zu einer schnelleren Markteinführung von Produkten und Lösungen führen - aber auch zu höheren Fehlerraten.
Dies bedeutet, dass sowohl das Geschäft beeinträchtigt wird als auch die Nutzer aufgrund schlechter Implementierungen und Ausfallzeiten der Dienste frustriert sind. Zudem benötigen die DevOps-Teams mehr Zeit zur Behebung dieser Fehler, wodurch weniger Zeit zur Entwicklung anderer Lösungen bleibt.
Daher muss das eigentliche Ziel lauten: "Schnellere Markteinführung hochqualitativer Lösungen". Die Qualität ist dabei durch integrierte Tests während der Entwicklungsphase zu gewährleisten.
Zu viele Warnmeldungen
Mitarbeiter im IT-Betrieb erhalten von diversen Monitoring-Lösungen oft tausende Alarm-E-Mails pro Tag. Diese landen häufig in einem speziellen E-Mail-Ordner, der kaum noch durchgesehen wird, da die Zeit fehlt und die meisten Meldungen unwichtig sind. Dadurch verpassen sie aber manchmal auch kritische Warnungen und werden erst von Fachabteilungen auf Probleme aufmerksam gemacht.
Aber selbst, wenn die Meldungen durchforstet werden, gehen in der riesigen Menge an unkritischen Nachrichten die wenigen wichtigen Warnungen zu Problemen unter, die sich auf den Benutzer auswirken.
So sollten einheitliche Monitoring-Lösungen genutzt werden, die einerseits ähnliche Probleme zusammenfassen, um die Anzahl der Meldungen zu reduzieren, und andererseits wichtige von unwichtigen Fehlern unterscheiden. Im Idealfall liefern sie gleich noch eine Ursachenanalyse sowie mögliche Lösungsvorschläge zur Behebung des Problems mit. Angesichts der Vielzahl der Daten, Anwendungen und Abhängigkeiten unterstützt künstliche Intelligenz bei diesen hochkomplexen Aufgaben. Selbstlernende Systeme überwachen und bündeln Alerts und schaffen eine zuverlässige Korrelation der Probleme mit den Ursachen.
Ablösung bewährter Prozesse
Blickt man aus Entwicklersicht auf zahlreiche DevOps-Praktiken, dann hat man den Eindruck, dass nun agile Prinzipien übergreifend ausgerollt werden. Die Kernprinzipien wie kleinere Iterationen, Automatisierung und Feedback-Schleifen sind für Entwickler nicht neu. Sie wurden schon immer an Veränderungsrate wie Stories-per-sprint oder Funktionalitäten pro Release gemessen, die stetig zunehmen. Ganz anders der IT-Betrieb, dessen Ziel hohe Verfügbarkeit (normalerweise 99.999%) ist, das nun durch das höhere Entwicklungstempo und die Technologievielfalt der DevOps-Prozesse gefährdet werden könnte.
Viele etablierte IT-Mitarbeiter fühlen sich dadurch überfordert und haben das Gefühl, mit dem entstehenden Chaos und dessen Bewältigung allein gelassen zu werden. Genau hier müssen Unternehmen und ihre Führungskräfte sowie Hersteller versuchen, frühzeitig Ängste abzubauen.
Dazu sollten:
Neue Architekturen auf skalierbaren Plattformen erstellt werden, die standardmäßig ausfallsicher sind.
Der IT-Betrieb frühzeitig in den Bereitstellungsprozess eingebunden werden, um Best Practices zu integrieren.
Gemeinsam Wege für schnellere und sichere Innovationen gesucht werden, ohne die Fehlerrate zu erhöhen.
Monitoring-Technologien für DevOps-Prozesse können dazu einen wichtigen Beitrag leisten. Unabhängig von den gewählten Lösungen müssen die Funktionalitäten Shift-Left, Shift-Right und Self-Healing in die kontinuierlichen Entwicklungsprozesse integriert werden. Denn somit lassen sich unerwünschte Veränderungen und direkte Auswirkungen auf die Anwender durch mangelhaften Code verhindern.
Shift-Left: Automatisierte Qualitätsschranken für frühzeitige Entscheidungen, ob eine Code-Änderung weiter promoted wird oder ob die Delivery Pipeline gestoppt werden soll. Dabei geht es darum, mehr Daten früher im Softwarelebenszyklus zu nutzen und die erzielbaren Änderungen zu bewerten. Für spezifische Einheiten wie Prozesse, Services, Anwendungen oder Tests werden dazu die Daten über eine Automation API erfasst und in die Entscheidungslösungen eingespeist.
Shift-Right: Das bedeutet, die Kontext-Informationen über Inbetriebnahmen oder Veränderungen an die IT-Umgebung aktiv weiterzugeben, beispielsweise die zugehörigen Revisionsnummern oder Changes. Ein Schritt dafür ist es, Metadata als Bestandteil des automatisierten Deployment-Prozesses mit zu verbreiten. Beispiele dafür sind Tags aus AWS EC2-Instanzen, Docker, CloudFoundry, OpenShift oder Kubernetes. Je mehr Kontext vorliegt, desto besser wird die Ursachenanalyse.
Self-Healing: Darunter versteht man die Fähigkeit zur smarten Auto-Mängelbeseitigung von Root Cause-Problemen - wie das Ausbessern eines schlechten GC Settings - und nicht die Abschaffung der Symptome, etwa eine Erweiterung um zusätzliche Server wegen zu hoher CPU-Auslastung. Auch dafür sind ausreichende Kontextdaten erforderlich.
Ausblick
Die Einführung von DevOps-Prozessen ist, insbesondere auch mit Blick auf Cloud Computing, Pflicht - aber nicht einfach. Mit einer frühzeitigen Einbindung der Mitarbeiter, einer robusten und ausfallsicheren DevOps-Pipeline, integrierten Tests für hohe Qualität und Kompatibilität der Einzelkomponenten der Gesamtarchitektur sowie einer einheitlichen Monitoring-Lösung mit priorisierten Warnmeldungen gelingt sie jedoch effizient und nachhaltig. Der Einsatz passender Lösungen sorgt für eine höhere Mitarbeiterzufriedenheit und verbessert die gesamte IT-Performance. Der DevOps-Prozess lebt von Veränderungen und Anpassungen, Mitarbeiter und Führungskräfte müssen dabei immer wieder hinzulernen und Vorgehensweisen überdenken.