IT-Teams müssen eine Sprache sprechen DevOps-Monitoring – Blick in alle Werkzeugkoffer

Eine offene Kollaborationsstrategie im Sinne von DevOps birgt Herausforderungen. Neben der Harmonisierung der Tools und Prozesse müssen Entscheider vor allem Überzeugungsarbeit bei ihren Mitarbeitern leisten. Hier kann ein DevOps-übergreifendes Monitoring für zusätzliche Unterstützung sorgen.

Anbieter zum Thema

Vogel IT-Akademie

Insider Research

OutSystems

Entwickler und Administratoren rücken zusammen – ein Trend, der ein wenig Anlauf brauchte, laut Puppet State of DevOps Report inzwischen aber gut ein Viertel aller CIOs weltweit überzeugt hat. Die meisten Branchenkenner erwarten, dass die Popularität von DevOps in diesem Jahr einen neuen Höhepunkt erreichen wird.

Weitgehend Einigkeit besteht zudem darüber, dass die Tragweite von DevOps nicht ausschließlich technologischer, sondern ebenso unternehmenskultureller Natur ist. Viele erkennen in der strikten Trennung von Dev und Ops inzwischen einen unnötigen Bremsklotz, wenn es um schnelle Releases und ein effizientes Anwendungsmanagement geht.

Parallel dazu werden agile Methoden inzwischen zu einem ernstzunehmenden Erfolgsfaktor für Unternehmen – auch für DevOps ist es nun an der Zeit, den Kinderschuhen zu entwachsen. Denn um wirklich agil arbeiten zu können, müssen Organisationen die unsichtbare Mauer zwischen Entwicklungsteams, Systemadministratoren und dem IT-Support überwinden.

Code darf nicht länger von einer Blackbox in die nächste wandern. Es braucht Kollaboration zwischen Entwicklern und den Verantwortlichen für den operativen Betrieb einer Infrastruktur. Erst die enge Zusammenarbeit aller IT-Spezialisten schafft die nötige Voraussetzung für schnelle Iterationsschritte und Innovationszyklen, die ohne fortlaufendes Troubleshooting auskommen.

Herausforderung liegt im Umdenken

Oft werden Veränderungen im Unternehmen zuvorderst mit technischen Hürden assoziiert. Bei der Einführung von DevOps-Strategien besteht eine der größten Herausforderung allerdings im Umdenken der Mitarbeiterinnen und Mitarbeiter. Denn DevOps ist nicht einfach nur eine Technik, es ist eine Philosophie und bestimmt die Kultur innerhalb der IT-Teams.

In eingespielten Strukturen ist es deshalb nicht immer einfach, die kategorische Trennung von Entwicklung und Betrieb hin zu einem offenen, kollaborativen Denken zu verändern. Die Teams müssen den Willen mitbringen, enger zusammenzuarbeiten – und sie müssen gegenseitig ihre jeweiligen Ziele verstehen und bestenfalls gemeinsam definieren oder abstimmen.

Ein Beispiel für einen gemeinsamen Fokus kann zum Beispiel die allgemeine Systemverfügbarkeit sein. Mitarbeiter, die nicht nur ihre eigenen Zielsetzungen, sondern die übergeordneten Anforderungen im Blick haben, können die Tragweite ihrer eigenen Aufgaben besser einschätzen. Außerdem gilt auch für DevOps: Je konkreter und transparenter die Zieldefinitionen sind, umso besser können einzelne Aufgaben im Blick behalten und umgesetzt werden.

Transformation muss mit Bedacht erfolgen

Ein weiterer Umstand, der ein Zusammenrücken von Entwicklung und Betrieb erschweren kann, sind die komplett unterschiedlichen Tool Sets, mit denen Dev- und Ops-Mitarbeiter häufig arbeiten. Besonders schwer wiegt dieses Problem, wenn beide Teams nicht nur ganz andere Werkzeugkoffer benutzen, sondern aus diesen Instrumenten zudem noch unterschiedliche Kennzahlen und Messgrößen ableiten.

Das führt nicht selten dazu, dass in zentralen Performance- und Reliability-Fragen Äpfel mit Birnen verglichen werden. Die Folge: Dev und Ops reden aneinander vorbei, wenn es um die Systemgesundheit und mögliche Schwachstellen und Risiken geht. Es braucht also gemeinsame Lösungen und eine einheitliche Ausstattung für alle Teams, um bei der Analyse von systemrelevanten Messungen die gleichen Definitionen und Vokabeln zu verwenden.

Eben weil eine Harmonisierung von Tools, Prozessen und Architekturmodellen für einen nachhaltigen Wandel so wichtig ist, sollte sie mit Bedacht angegangen werden. Unternehmen sollten den Wandel hin zu integrierten DevOps-Prozessen nicht überstürzen – insbesondere nicht bei einer Legacy-lastigen Anwendungslandschaft.

Eine DevOps-Transformation muss als eigenständiges Projekt verstanden werden, das allen Beteiligten den Spielraum lässt, die nötigen Skills zu erwerben und sich in neue Prozessstrukturen einzuarbeiten – und um eine gemeinsame Sprache zu entwickeln. Die Implementierung eines übergreifenden Monitorings mit harmonisierten Kennzahlen, deren Relevanz für alle Arbeitsschwerpunkte ersichtlich ist, ist in diesem Zusammenhang ein erfolgskritischer Faktor.

Kennzahlen als Basis gemeinsamer Sprache

Um DevOps-Teams wirklich aussagekräftige Anhaltspunkte zu liefern, sollten drei verschiedene Kategorien von Daten erhoben 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 ausweist; 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 Rückschlüsse darüber, ob und wie erfolgreich das gesamte System die übergeordneten 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.

All diese Informationen sind grundlegend zur Diagnose und Problembehandlung von Störungen und Schwachstellen in der Infrastruktur. Die Erfassung spezifischer Ereignisse 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 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 lassen sich Auffälligkeiten oder Probleme identifizieren und beheben. Insbesondere beim Troubleshooting sorgen Alerts, die für alle Teams einheitlich in einer Plattform sichtbar sind, für eine nahtlosere und intuitivere Problemlösung.

KPIs sind für alle relevant

Work-, Performance- und Event-Daten sind 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).

Viele Unternehmen und Organisationen lassen sich von der Überzeugung leiten, dass ihr Monitoring-Budget nach wie vor am besten in die Produktion investiert werden sollte. Über kurz oder lang wird es sich allerdings als klug erweisen, allen Umgebungen – von der Entwicklung über die Integration und das Staging bis hin zur Produktion – das gleiche Augenmerk zu schenken.

So bekommen die Teams vom ersten Entwicklungstag an einen vollständigen und für alle beteiligten nachvollziehbaren Überblick über die gesamte System- und Anwendungsinfrastruktur. Ein entscheidender Faktor, wenn es um die Akzeptanz neuer, offener Kollaborationsstrukturen geht.

Stefan Marx

* Stefan Marx ist Director Product Management für die EMEA-Region beim Cloud-Monitoring-Anbieter Datadog. Marx ist seit über 20 Jahren in der IT-Entwicklung und -Beratung tätig. In den vergangenen Jahren arbeitete er mit verschiedenen Architekturen und Techniken wie Java Enterprise Systemen und spezialisierten Webanwendungen. Seine Tätigkeitsschwerpunkte liegen in der Planung, dem Aufbau und dem Betrieb der Anwendungen mit Blick auf die Anforderungen und Problemstellungen hinter den konkreten IT-Projekten.

(ID:45985219)