Offene Kommunikation und harte Fakten: Mit klaren Kennzahlen rücken Dev und Ops näher zusammen
Die enge Verzahnung von Entwicklung und operativem IT-Management erweist sich zusehends als kluger Ansatz – und trotzdem scheint hierzulande das Eis beim Thema DevOps noch nicht gänzlich gebrochen zu sein. Die IT-Teams in den Unternehmen tun sich streckenweise schwer, von ihren eingespielten Abläufen abzulassen. Dahinter verbirgt sich nicht selten die Sorge, den Überblick oder sogar die Kontrolle über die eigenen Verantwortlichkeiten zu verlieren. Umso wichtiger ist es, dass alle Beteiligten – vom Programmierer bis zum Systemadmin – die gleiche Sprache sprechen, wenn es um Projekterfolge und Systemgesundheit geht. Die hierzu nötigen Kennzahlen liefert ein durchdachtes integriertes Monitoring-System.
Auf der DevOpsCon 2019 im Juni dieses Jahres wurden gleich mehrere Hot Issues am DevOps-Horizont ausgemacht, die den einen oder anderen Tech-fokussierten Besucher im ersten Moment vielleicht etwas überrascht haben mögen. Denn neben reinen Technologiethemen – unter anderem zu Microservice-Meshes, steigenden Security-Anforderungen und Best Practices für Infrastructure-as-Code-Projekte – kamen in den Keynotes vor allem weiche Aspekte wie Kommunikation, Empathie, Vertrauen und die Bereitschaft zum Lernen zur Sprache. Jeff Sussna, der als IT-Coach in Sachen DevOps und Agile inzwischen internationales Renommee genießt, brachte im Eröffnungsvortrag der Konferenz folgende Erkenntnis auf den Punkt: "Eine der wichtigsten Eigenschaften von DevOps ist kontinuierliches Lernen." Teamverantwortliche in agilen und DevOps-Umgebungen sind deshalb angehalten, neben einer offenen und vertrauensvollen Kommunikation, Prozesse zu etablieren, die den Rahmen für Erkenntnisgewinne schaffen. Diese können im Sinne einer fortlaufenden Weiterentwicklung dynamisch in Workflows eingebracht werden und so auch Stolpersteine bei den Abstimmungs- und Übergabeprozessen zwischen Development und Operations aus dem Weg räumen. Ganz aus dem Bauch heraus könne das allerdings nicht passieren, mahnt der Hamburger IT-Consultant und Business-Analyst Jacob Tiedemann. Wenn es darum geht, den Erfolg von DevOps-Projekten zu bewerten, "verlassen sich viele Teams auf ihr Bauchgefühl oder auf Schätzungen, die sie aus ihren Story Points ableiten." Dabei brauche es klare Kennzahlen für realistische Planungen und Vorhersagen. Tiedemann sprach sich auf der DevOpsCon deshalb für einen geschlossenen Build-Measure-Learn-Loop aus, der auf harten Fakten basiert.
Zwei Standpunkte, ein Widerspruch? Mitnichten. Denn ein lösungsorientierter, konstruktiver und lernwilliger Austausch zwischen Dev und Ops braucht neben Vertrauen und Empathie vor allem unmissverständliche Fakten. Genau hier greifen die Erkenntnisse aus einem übergreifenden Monitoring. Sie gewähren Einblicke, die für alle Teams – sowohl in der Entwicklung als auch im Betrieb – das für eine konstruktive Zusammenarbeit unverzichtbare Maß an Transparenz liefern. Ein Aspekt, der übrigens nicht nur für DevOps-Workflows, sondern in zweiter Instanz auch für die Abstimmung zwischen Entwicklung, Betrieb und den operativen Fachabteilungen im Unternehmen von großer Bedeutung ist.
Skills, Tools und Tempo müssen harmonieren
Unternehmen, die auf einem guten Weg hin zu tatsächlich agilen DevOps-Strukturen sind, haben die Mauern, über die ihre Entwickler vormals blind den fertigen Code geworfen haben, längst eingerissen. Da, wo vor wenigen Jahren noch eine unsichtbare Wand stand, sind heute im Idealfall runde Tische vorzufinden: Kollaborative Prozesse zwischen Entwicklungsteams und Anwendungsmanagern ermöglichen kürzere Iterationszyklen und schnelle Optimierungsmaßnahmen. Mit der rasant wachsenden Auswahl an Automatisierungstools, die derzeit nahezu täglich auf dem Markt erscheinen, und der enormen Geschwindigkeit, mit der mehr und mehr Infrastrukturelemente in die Cloud abwandern, wird diese Entwicklung weiter vorangetrieben. Schließlich überschneiden sich die Werkzeugkoffer, aus denen sich Software-Ingenieure und Systemadministratoren im Cloud-Universum bedienen, deutlich stärker als in On-Premise-Umgebungen.
Wenn die unterschiedlichen DevOps-Teams neben verwandten Tools und Fertigkeiten noch die gleichen Ziele in die Waagschale werfen, ist bereits viel gewonnen. Ein Beispiel: Die Systemverfügbarkeit ist eine wichtige Kenngröße, die für Entwickler und Anwendungsmanager gleichermaßen von Bedeutung sein sollte. Ein weiterer Aspekt, der mit Fingerspitzengefühl behandelt werden sollte, ist das Tempo, mit dem Unternehmen ihre IT-Prozesse neu strukturieren und in agilere, offenere Strukturen überführen. Gerade in Umgebungen mit einer großen Anzahl an Legacy-Anwendungen und in über die Jahre zusammengewachsenen Teams ist es nicht sinnvoll, DevOps mit der Brechstange einführen zu wollen. Hier braucht es vielmehr einen sorgfältig eingeleiteten Mindshift und die sukzessive Veränderung von Workflows, Team-Strukturen und technischen Rahmenbedingungen. Und eine gemeinsame Sprache, die über eine gemeinsame Plattform "gesprochen" werden kann. Auf Basis von interdisziplinär verständlichen Kennzahlen können auf einem zentralen Tool zum Beispiel Fehlermeldungen und Alerts von allen involvierten Team-Mitgliedern zu jeder Phase des Software-Lifecylces eingesehen werden. So gestaltet sich das Troubleshooting für das gesamte DevOps-Team transparent; Workflows können insgesamt nahtloser und intuitiver erfolgen.
Einheitliche Sicht ist entscheidend für zügige Entscheidungen
Damit DevOps-Teams nicht nur im Falle einer Alarmmeldung, sondern schon im Vorfeld zielführend agieren können, reicht es nicht aus, lediglich über Monitoring-Daten zu verfügen – diese müssen zugleich aussagekräftig und damit eindeutig interpretierbar sein. Neue Infrastrukturkonzepte wie Serverless und Infrastructure-as-Code bestehen aus einer Vielzahl unterschiedlichster Services und Elemente, die sowohl für Entwicklerinnen und Entwickler als auch für die Verantwortlichen im operativen IT-Betrieb schnell unübersichtlich werden können. Vor diesem Hintergrund ist es von großer Bedeutung, dass die Qualität der Reporting-Funktionen bei der Betrachtung kompletter DevOps-Zyklen nicht ins Hintertreffen geraten. Relevante Daten müssen eingängig aufbereitet sein, sonst verbringen die verantwortlichen Mitarbeiter wertvolle Zeit mit manuellen Datenbankensuchen, aufwändigen manuellen Analysen oder gar der nervenaufreibenden Formatierung von Excel-Sheets. Damit dies nicht geschieht, braucht es anpassungsfähige Visualisierungsfeatures. Denn ein gutes Monitoring entfaltet erst dann sein volles Potenzial, wenn Erkenntnisse ohne Umschweife und auf einen Blick gewonnen werden können. Die Visualisierung wird somit zur Schnittstelle zwischen den verfügbaren Daten und der Entscheidung bzw. dem Entscheider. Wird das Monitoring-Tool der Komplexität seines Wirkungsbereichs gerecht, können CIOs schnell und zielgerichtet sowohl operative als auch strategische Weichen stellen und Ihre Entscheidungen mit Hilfe der sichtbaren Daten begründen.
Einblick in operative Prozesse, Ressourcen und besondere Ereignisse
Um die effiziente Zusammenarbeit in einem DevOps-Team sicherzustellen, sollten drei verschiedene Kategorien von Daten dauerhaft erfasst werden: operative Kennzahlen, die "Work Metrics", Ressourcenkennzahlen, die sogenannten "Resource Metrics", sowie besondere Ereignisse, also systemrelevante "Events".
- Work Metrics geben Auskunft über nutzungsrelevante Aspekte eines Systems. Sie erfassen den Durchsatz (throughput), den ein System über eine festgelegte Zeitspanne hinweg vorweist; sie zeigen den prozentualen Anteil der erfolgreichen Operationen (success) an; sie ermitteln die Anzahl fehlerhafter Operationen (error); sie quantifizieren die Performance (performance) der einzelnen Komponenten, zum Beispiel durch die Ermittlung der Latenz- und Antwortzeiten. In Summe erlauben all diese Kennzahlen übergreifende Rückschlüsse darüber, ob und wie erfolgreich das System die gesetzten Ziele erreicht.
- Ergänzend zu diesen Erkenntnissen können DevOps-Teams anhand von Ressource Metrics die unterschiedlichen Bestandteile der Systeminfrastruktur detailliert betrachten und ihre Nutzung (utilization), Sättigung (saturation), Verfügbarkeit (availability) sowie Fehler (errors) auswerten. Diese Kennzahlen lassen unmittelbare Rückschlüsse auf den aktuellen Status eines Systems zu und zeigen zum Beispiel die Auslastung einer spezifischen CPU an. Die Analyse der Ressourcen-Kennzahlen ist unabdingbar, um Probleme und Engpässe, die anhand von Work Metrics indiziert wurden, exakt zu identifizieren.
- Die Erfassung spezifischer Ereignisse (Events) als dritte Kennzahlenkategorie vervollständigt die Informationsbasis und ist insbesondere bei der Ursachenanalyse hilfreich. Das DevOps-Team kann diese Events festlegen und zum Beispiel immer dann Daten erfassen, wenn ein neuer Code auf den Weg gebracht wird, ein Alarm ausgelöst oder dem System ein neues Modul hinzugefügt wurde.
Echtzeit-Daten sind in diesem Zusammenhang übrigens für alle Kategorien ideal; je schneller Informationen vorliegen, umso schneller kann eine Auffälligkeit oder ein Problem identifiziert und behoben werden. Insbesondere beim Troubleshooting sorgen Alerts, die für alle Teams einheitlich in einer Plattform sichtbar sind, für eine nahtlosere Problemlösung.
KPIs zeigen die Erreichung gemeinsamer Ziele an
Für alle drei Kategorien gilt übrigens: Je näher die Daten an Echtzeit sind, umso schneller können die Teams Probleme und Zwischenfälle erkennen, diagnostizieren und beheben. Und umso schneller ist ein vorübergehender Leistungsabfall im System wieder aus der Welt geschafft. Zudem sind Work-, Performance- und Event-Daten nicht nur hilfreich, wenn es um die Gesunderhaltung und den reibungslosen Betrieb von Systemen geht. Die aus diesen Messungen resultierenden Informationen liefern zugleich Aufschluss darüber, ob KPIs und damit die gemeinsam im DevOps-Team definierten Ziele erreicht wurden. Wichtige Indikatoren, um den Erfolg von DevOps-Prozessen bewerten zu können, sind unter anderem Frequenz und Fehlerraten beim Deployment (Event-basiert); die "mean time to detection" und "mean time to repair", also die durchschnittliche Dauer bis zur Identifikation und bis zur Behebung eines Problems (Work-Metrics-basiert); sowie die allgemeine Systemverfügbarkeit (Ressource-Metrics-basiert). Werden diese Kennzahlen über einen längeren Zeitraum erhoben und ausgewertet, können sie direkt in den DevOps-Erfahrungsschatz einfließen und zur Optimierung künftiger Entwicklungs- und Betriebsprozesse beitragen. An dieser Stelle fließen exakt die harten Fakten in den Lernzyklus der Anwendungsentwicklung und -bereitstellung ein, die Jacob Tiedemann mit seinem Build-Measure-Learn-Kreislauf auf der DevOpsCon in Berlin ins Gespräch gebracht hat.
Behebung von Sollbruchstellen schon vor dem Rollout
Viele Unternehmen mögen versucht sein, ausschließlich in das Monitoring und die Erfassung von Daten zu investieren, die im laufenden Betrieb anfallen. Davon sei allerdings abgeraten. Es ist deutlich zielführender für die Entwicklung, dem Staging und dem Betrieb die gleiche Aufmerksamkeit zu widmen. Auf diese Weise bekommen Teams einen Rundumblick auf ihre Infrastruktur und die Anwendungen, die darauf aufsetzen – und das von der ersten Programmzeile bis hin zum Go-Live. Zudem können mit Messwerten aus Staging- und Testumgebungen Probleme proaktiv identifiziert und angegangen werden. Beispiele für derartige Sollbruchstellen sind mangelnde Code-Performance oder Ressourcen-Engpässe.
Idealerweise kann eine Anwendung unter diesen Bedingungen schon optimiert werden, bevor sie ihre eigentliche Arbeit aufnimmt. Womit direkt ein zweiter, wichtiger Aspekt ins Rennen geht: Die Produktionsumgebung, in der Anwendungen die geplante Leistung erbringen müssen, sind die direkte Schnittstelle zur Außenwelt – und damit natürlich auch zum Kunden. Verfügbarkeit, Durchsatz und Performance wirken sich unmittelbar auf den Kunden, seine Zufriedenheit und damit auch auf die Ertragszahlen aus. DevOps-Teams, die schon während der Entwicklungsphase einen tiefgreifenden Blick auf ihre Infrastrukturen haben und durch ein gezieltes Monitoring potenzielle Probleme bereits im Keim ersticken, vermeiden damit zugleich auch die Gefahr auf Seiten der Anwender. Auf die Gewinnspanne kann sich das schon nach vergleichsweise kurzer Zeit positiv auswirken.
Trends verlangen nach granularem Monitoring
Wie die inhaltlichen Schwerpunkte der jüngst zurückliegenden DevOpsCon deutlich gemacht haben, könnten schon bald microservice-basierte und containerisierte Architekturen stärker in den Fokus der DevOps-Teams rücken. Diese Systeme werden vermutlich Cloud-agnostisch und so konzipiert sein, dass sie auch mit Kubernetes-Konzepten einwandfrei orchestriert werden können. Die Zahl der Unternehmen, die bereits so arbeitet oder zumindest mit der Migration auf derartige Konzepte begonnen hat, ist gar nicht gering. Manche CIOs zögern allerdings noch mit diesem Schritt, weil sie die perfekten Hebel für ihren spezifischen Bedarf noch nicht gefunden haben – die optimale Herangehensweise beim Einrichten von Microservices ist in der Tat eine Wissenschaft für sich und sehr fallspezifisch.
So oder so wird sich dieser Trend fortsetzen. Und mit der fortschreitenden Verbreitung von Microservices, Kubernetes & Co. wird zugleich der Bedarf an übergreifenden und zugleich granularen Monitoring-Optionen stetig ansteigen. IT-Ingenieure werden künftig verstärkt darauf achten, dass ihre Lösungen systemagnostisch arbeiten – proprietäre, anbietergebundene Monitoring-Tools werden langsam aber sicher vom Radar der DevOps-Teams verschwinden. Der lückenlose, transparente Blick auf die Systemgesundheit wird immer mehr zu einem Schlüsselfaktor für die erfolgreiche Zusammenarbeit zwischen Programmierern und Systemadministratoren werden. Darüber hinaus – und hier kommt erneut die Bedeutung für die fachliche Seite der Anwendungsbereitstellung zum Tragen – werden die Kennzahlen aus Dev und Ops stärker mit den Ergebnissen aus dem Business-Analytics-Segment integriert werden. Hieraus resultiert nicht nur die Substanz für datenbasierte Entscheidungen; die Betrachtung von Monitoring-Kennzahlen findet im übergeordneten Kontext von Geschäftszielen und Erfolgskennzahlen statt. Und davon profitiert letztlich nicht nur die IT, sondern das gesamte Unternehmen.
