Observability Best Practices in den Software Development Lifecycle zu integrieren, ist heute von entscheidender Bedeutung, da immer mehr Anwendungen geschäftskritische Kunden- und Mitarbeitererfahrungen liefern. Deshalb sollte Devops-Teams nicht nur daran gelegen sein, die mittlere Zeit bis zur Behebung größerer Probleme zu verkürzen. Sie wollen auch sicherstellen, dass Anwendungen und Services beobachtbar sind, um die Robustheit, Zuverlässigkeit und Benutzerfreundlichkeit einer Experience kontinuierlich zu verbessern.

Heutige Cloud-Native-Applikationen sind komplexer als die zwei- und dreistufigen Rechenzentrums-Anwendungsarchitekturen der letzten Generation. Eine einzelne Transaktion kann mehrere Microservices umfassen und Datenbanken abfragen, mit SaaS-Angeboten von Drittanbietern interagieren und in multiplen Clouds laufen. Wenn Anwendungsfehler, schlechte Performance und Datenprobleme das Benutzererlebnis beeinträchtigen, sind zentralisierte und aussagekräftige Informationen der Schlüssel dazu, die Ursachen zu erkennen und schneller zur Problemlösung zu finden.

Starke Praktiken in Sachen Observability können sich in vielfältiger Weise positiv auf den IT-Betrieb auswirken. Etwa, indem sie:

• Microservices und APIs identifizieren, die Leistungsengpässe verursachen;

• Benutzereingaben überprüfen, die Anwendungsfehler verursachen;

• die Customer Journey tracken, um festzustellen, an welchen Stellen die User Schwierigkeiten haben;

• Sicherheitsverletzungen erkennen und forensische Daten sammeln; oder

• die Quelle von Datenproblemen lokalisieren, um sie mit optimierter Datenvalidierung zu beheben.

Im Folgenden haben wir vier Observability Best Practices für Devops-Teams zusammengetragen, die Applikationen, Microservices und Datenbanken entwickeln und unterstützen.

Do you want to play a Game ?? #observability #data #o11y #devops pic.twitter.com/8Xhn70QB24

— Mina Yacoub (@MinaYacoub7) January 23, 2023

1. Mit Business Collaboration die Data Collection treiben

Jeden JSON-Payload zwischen allen Apps und Services zu loggen, mag auf den ersten Blick als gute Idee erscheinen. Allerdings können zu viele Daten:

• die Problembehebung behindern,

• die Ursachenforschung verkomplizieren, oder

• ausgedehnte Data-Science-Bemühungen nach sich ziehen.

Die Frage ist also, wie Devops-Teams entscheiden sollen, welche Daten sie sammeln und wie lange sie diese vorhalten. Anant Adya, Executive Vice President bei Infosys Cobalt, empfiehlt an dieser Stelle: "Um sicherzustellen, dass die Zielausrichtung stimmt, sollten agile Entwicklungsteams eng mit Entwickler- und Stakeholder-Gruppen zusammenarbeiten, wenn es darum geht, Devops Observability Tools zu managen. So lässt sich vermeiden, Unmengen von Daten zu sammeln und auszuwerten, die keinem bestimmten Zweck beziehungsweise Ziel dienen."

Ein Gespräch mit den Business-Stakeholdern kann dabei helfen, eine Strategie zu entwickeln und zu ermitteln, welche Benutzeraktivitäten höhere Service-Level-Ziele erfordern. Entwickler sollten sich außerdem darüber im Klaren sein, welche Daten sensibel sind - und diese entweder weglassen oder maskieren, bevor sie in Protokollen, Datenbanken oder Observability-Tools erfasst werden.

"Bei Observability geht es auch darum, was eigentlich protokolliert werden soll, nicht nur darum, wo und wann", konstatiert Anand Krishnan, Global Head of Presales and Solutions bei Persistent Systems. Er ergänzt: "Es ist wichtig, die verschiedenen Spuren der Customer Journey über verschiedene Systeme und Anwendungen hinweg zusammenzufügen und sie in einem zentralen Repository zu sammeln."

Für größere Devops-Organisationen kann eine solche Zentralisierung von Observability-Daten eine Erleichterung sein: Sie können dazu Application-Performance-Management-Tools und AIOps-Plattformen verwenden, die auch Alarmmeldungen korrelieren oder die Performance überwachen.

Wenn es darum geht, wie Business Stakeholder und technische Führungskräfte wertvollen Input über Observability-Tools und -Daten liefern können, kennt sich Prashanth Samudrala, Vice President of Customer Success bei AutoRabit, aus: "Zu den Best Practices in diesem Bereich gehört es, Metriken und Ziele, die sich auf Qualität und Gesamtproduktivität fokussieren, klar zu definieren, technische Schulden zuverlässig zu erfassen sowie die Problemlösungsfähigkeiten der Teams zu nutzen, um kontinuierlich zu lernen und sich zu verbessern."

2. Mehr als nur Produktionsvorfälle lösen

Site Reliability Engineers (SREs), Network Operation Center (NOCs) und Devops-Teams nutzen Anwendungsprotokolle, Infrastruktur-Alerts und andere Telemetriedaten für das Incident Management. Zudem können APM-Tools, IT-Service-Management-Plattformen (ITSM), Automatisierungsfunktionen und AIops-Lösungen zum Einsatz kommen, um Vorfälle zu beheben und Ursachenanalysen zu fahren.

Dabei sollten SREs und Devops-Teams allerdings proaktiv vorgehen und Observability-Daten und -Tools nutzen, um Apps bereits während der Entwicklungs- und Testing-Prozesse zu verbessern. Tomas Kratky, Gründer und CEO von Manta, erklärt: "Observability ist Teil der Qualitätssicherung - die letzte Meile, die benötigt wird, um die Erkennung von Vorfällen zu optimieren und deren Auflösung zu vereinfachen."

Die Nutzer und Kunden für Observability-Daten und -Tools zu identifizieren, ist dabei empfehlenswert. Selbstorganisierte Teams sollten festlegen, welche Entwickler, QA-Ingenieure, SREs und Incident Manager als Experten für die Tools auftreten und für die Qualitätsverbesserung verantwortlich sind. Die Observability zu verbessern, sollte eine Schlüsselaktivität im Rahmen einer Continuous-Testing-Strategie darstellen.

Chris Cooney, Entwicklerbeauftragter bei Coralogix, hat eine weitere Best Practice auf Lager: "Full-Stack-Observability ist ein Ansatz, der bei High-Performance-Teams allgegenwärtig ist. Er ermöglicht es, Datensilos zu vermeiden. Anstatt sich mit disparaten Observability-Daten zu begnügen, wo die Logs auf einem System, die Metriken auf einem anderen und die Traces auf einem dritten liegen, rendern diese Teams alles zusammen."

3. Kontinuierliche Verbesserung vorantreiben

Auch wenn eine ausgewählte Gruppe von Engineers die Verantwortung für die Softwarequalität tragen, muss das gesamte Entwicklungsteam an Bord sein, um kontinuierliche Verbesserungen voranzutreiben. David Ben Shabat, Vice President R&D bei Quali, empfiehlt: "Unternehmen sollten sich um 'Visbility as a Standard' bemühen. Das ermöglicht Ihrem Team, eine Kultur der End-to-End-Verantwortung zu etablieren und sich auf kontinuierliche Verbesserungen Ihres Produkts zu konzentrieren."

Eine Möglichkeit, Verantwortung zu übernehmen, besteht darin, eine standardisierte Taxonomie und ein standardisiertes Nachrichtenformat für Protokolle und andere Observability-Daten zu erstellen und zu befolgen. Agile Entwicklungsteams sollten in jedem Sprint ein Teammitglied damit beauftragen, die Logs zu überprüfen und Alerts für neue Fehlerbedingungen hinzuzufügen. Und, wie Ben Shabat ergänzt: "Außerdem sollten Sie so viele Prozesse wie möglich automatisieren und dabei Protokolle und Metriken als Maßstab für erfolgreiche Performance verwenden."

Auch Ashwin Rajeev, Mitbegründer und CTO von Acceldata, sieht Automatisierung als Schlüssel dazu, 'observable' Applikationen und Services zu entwickeln: "Moderne Devops-Observability-Lösungen integrieren sich in CI/CD-Tools, analysieren alle relevanten Datenquellen, geben Empfehlungen in Echtzeit und nutzen Automatisierung, um verwertbare Erkenntnisse zu gewinnen."

4. Monitoring und Observability koordinieren

Monitoring-Tools sind historisch betrachtet eher etwas für NOCs, ITSM- oder IT-Operations-Teams. Observability hingegen eher ein "Entwicklerding". Heutzutage führen Devops-Teams diese Fähigkeiten zusammen und entwickeln einen ganzheitlichen Ansatz, um Customer Journeys und Employee Experiences zu beobachten und zu überwachen. "Früher konnte man einen Ingenieur über ein Systemproblem informieren, indem man eine E-Mail schickte oder einen Core Dump durchführte. Heute geht es um die Integration in das Entwickler-Ökosystem und die Produktions-Supportsysteme", meint Krishnan.

Devops-Teams wollen häufig neue Versionen veröffentlichen und Produktionsprobleme schnell beheben. In Observability zu investieren, hilft dabei, Probleme zu finden, bevor sie die Produktion erreichen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.