Uwe Baumann artiso solutions GmbH

Wer gute Software entwickeln will, braucht Erkenntnisse über das tatsächliche Verhalten der Anwendung und der Anwender im tatsächlichen Produktionsbetrieb.

Thomas Schissler artiso solutions GmbH

Eine Anwendung zu instrumentieren, ist nicht trivial – schließlich soll das Erheben von Telemetriedaten möglichst den Umgang der Nutzer mit unserer Anwendung nicht beeinträchtigen.

In den bisherigen Folgen unserer DevOps-Serie haben wir beschrieben, wie kurze Zyklen, agile Planung, ein ganzheitlicher Ansatz für Qualitätssicherung und geeignete Tools zu besserer Software für unsere Kunden führen können. Doch was heißt bessere Software? Anders formuliert: Woher wissen wir, wie gut unsere Software ist, was die Kunden davon halten und wo wir uns verbessern können?

Wir können uns auf unsere Intuition verlassen, unsere Kunden direkt befragen oder unsere Verkaufs- bzw. Abonnentenzahlen konsultieren. Aber reicht das, um zu wissen, wie gut unsere Software wirklich läuft? Tatsache ist: Die Anwendung befindet sich in Produktion und tagtäglich arbeiten Kunden damit, nutzen Features oder ignorieren sie, ärgern oder freuen sich über die Performance, entdecken Fehler und nutzen Workarounds. Das ist die ungeschönte Wirklichkeit und sie sagt uns, wie gut unsere Software wirklich ist. Die Erkenntnisse über das Verhalten unserer Applikation in der freien Wildbahn können dann wieder in unsere Entwicklungszyklen einfließen.

In Zeiten von App-Shops und Bewertungsportalen entscheiden die Informationen aus dem Realbetrieb unserer Applikation – und was wir daraus machen – über wirtschaftlichen Erfolg oder Untergang. Am deutlichsten wird das in der mobilen Welt: Eine „abgewertete“ App hat keine Chance mehr bei den Usern, die oft mehrere Alternativen für die gleiche Anforderung zur Verfügung haben.

Datenschätze aus der Blackbox heben

Die Zauberworte zum Heben dieses lebenswichtigen Erkenntnisschatzes heißen „Monitoring“ und „Telemetrie“. Mit geeigneten Mitteln wollen wir in verschiedenen Bereichen Daten gewinnen, die uns weiterhelfen. Zu oft ist der Produktivbetrieb eine „Blackbox“.

Viele Teams sind dabei zunächst einmal daran interessiert, über Fehler im Produktivbetrieb informiert zu werden, um Bugs und Performanceprobleme aufzuspüren und schnell zu beheben. Ein klassisches Debugging ist in vielen Fällen auf dem Produktivserver nicht uneingeschränkt möglich. Mehr noch: Wenn Fehler auftauchen, ist das Kind bereits in den Brunnen gefallen. Wir wollen aber vielmehr schon gewarnt werden, wenn das Kind die Mauer hinaufklettert. Idealerweise erfahren wir deshalb mittels geeigneter Vorwarnindikatoren, ob sich unsere Anwendung einem instabilen Zustand nähert. Wir wollen sozusagen eine „Ölwarnlampe“ für unsere Applikation – das könnte zum Beispiel eine Mail-Queue sein, die gerade vollläuft und auf ein Problem an anderer Stelle der Applikation hinweist.

Konzepte wie das im letzten Artikel erwähnte „Test in Production“ funktionieren ebenfalls nur, wenn wir Fehler- oder Vorwarndaten zur Verfügung haben. Zur Erinnerung: Bei Test in Production deployen wir mehrere Versionen der Software gleichzeitig. Neue Features werden zunächst für wenige User freigeschaltet und später einer immer größeren Nutzerbasis zur Verfügung gestellt – idealerweise automatisch und auch nur dann, wenn mit den neuen Funktionalitäten keine Probleme auftreten. Und dafür muss die Software (und das Operations-Team) auch in der Lage sein, konkrete oder potenzielle Probleme im Produktivbetrieb zu erkennen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 5.17 - "Cross-Plattform mit JavaScript"

Alle Infos zum Heft
579794452Die Bedeutung besserer Software laut DevOps
X
- Gib Deinen Standort ein -
- or -