Die Bedeutung von Fehlerbehandlung, Qualitätskontrolle und Dokumentation aus der Perspektive eines IT-Betriebsteams

Die langfristige Verantwortung für den Betrieb von IT-Systemen bringt Erfahrungen mit sich, die für viele in diesem Bereich allzu vertraut sind. Ein gutes Beispiel hierfür ist der Markteinführungsprozess eines neuen Produkts. Dabei lassen wir die anfänglichen Phasen eines Projekts außer Acht und konzentrieren uns unmittelbar auf die Umsetzung:

Nach sorgfältiger fachlicher und technischer Prüfungen durch das Qualitätssicherungsteam und der Behebung identifizierter Fehler durch die Entwickler, sowie dem Aufbau der Produktionsumgebung durch das zuständige IT-Betriebsteams, folgt der große Tag das Produkt geht an den Start.

Anfänglich scheint der Start erfolgreich, doch unerwartet verschlechtert sich die Performance bis zum völligen Stillstand. Die darauffolgenden Fragen nach dem Warum und den Lösungen sind vertraut. Auch wenn dieses Beispiel einen Extremfall darstellt, treten solche und ähnliche Situationen über die Jahre hinweg immer wieder auf.

In diesem Artikel beleuchten wir aus der Sicht eines IT-Betriebsteams die potenziellen Ursachen für solche Vorfälle und mögliche Lösungsansätze.

Herausforderungen bei der Fehlerdiagnose

Häufig richtet sich der erste Blick bei der Fehlersuche auf die Logdateien der Anwendung und des Systems, um potenzielle Ursachen zu identifizieren. Doch genau hier beginnen oft die Schwierigkeiten.

Im ungünstigsten Fall wurden Fehler gar nicht erst protokolliert. Existieren Fehlermeldungen, sind diese häufig zu allgemein gehalten, um das Problem präzise zu lokalisieren. Zudem kann ohne tiefgehendes Verständnis des Codes oft nicht nachvollzogen werden, was die Probleme verursacht hat. Letzteres tritt, zumindest aus unserer Erfahrung, vornehmlich bei Java-Anwendungen auf.

Ein praxisnahes Beispiel veranschaulicht das Problem: Eine Anwendung generiert einen über hundert Zeilen langen Stack Trace, dessen eigentliche Ursache eine „FileNotFoundException“ ist. Der Stack Trace lässt jedoch offen, welche Datei fehlt. Erst die Konsultation des zuständigen Entwicklers führte zur Problemlösung.

Solche und ähnliche Herausforderungen dürften vielen bekannt sein. Doch wie können sie vermieden werden? Nach zahlreichen Diskussionen mit Fachleuten aus der Softwareentwicklung kristallisieren sich verschiedene Gründe heraus, von denen wir einige beleuchten möchten.

Erfahrungsmangel im täglichen Betrieb von Systemen und Anwendungen

Ein Stack Trace kann die problematische Codezeile aufzeigen. Mit Codezugriff und entsprechender Entwicklungserfahrung ist dies eine hilfreiche Information.

Für Betriebsteams gestaltet sich die Lage jedoch oft anders. Codezugriff ist nicht immer gegeben und selbst wenn, fehlt es möglicherweise an Programmierkenntnissen. Hinzu kommt der Druck, die Funktionalität möglichst schnell wiederherzustellen, oftmals auch nachts, wenn das Monitoring die Bereitschaft alarmiert.

Es ist ebenfalls wichtig zu berücksichtigen, dass das Format der Lognachrichten nicht nur die Effizienz der Auswertungsprozesse beeinflusst, sondern auch eine signifikante Auswirkung auf die Belastung der zentralen Systeme hat und die Analyse der Daten maßgeblich vereinfachen oder erschweren kann.

Tunnelblick

Ein häufiges Phänomen ist der „Tunnelblick“. Man ist so vertraut mit der Materie, dass man die Ursache eines Problems leicht identifizieren kann, vergisst dabei jedoch, dass Außenstehende die Zusammenhänge nicht ohne Weiteres verstehen.

Zeit und Budget

Oft sind Zeit und Budget nur so bemessen, dass die Anwendung die Grundanforderungen erfüllt und alle notwendigen Basisfunktionen bereitstellt. Eine strukturierte Fehlerbehandlung kann zeit- und ressourcenintensiv sein und erhält daher leider oft eine geringere Priorität.

Die Rolle von Staging und Lasttests

In diesem Abschnitt möchten wir die Bedeutung und den Nutzen von verschiedenen Umgebungen im Rahmen eines Projekts, dessen Betrieb sowie bei der Fehlerbehebung und Weiterentwicklung eines Produktes näher beleuchten. Das Bereitstellen dedizierter Umgebungen für die unterschiedlichen Teams kann sich als äußerst sinnvoll erweisen. Die Ausgestaltung dieser Umgebungen kann dabei je nach Budget, Produktanforderungen, Teamgröße und verfügbarer Zeit variieren.

Staging

Wir skizzieren einen Ansatz für Staging, der im Zusammenhang eines eher traditionelleren Setups mit Servern und virtuellen Maschinen Anwendung findet, aber auch als Grundlage für moderne Cloud- und Container-Umgebungen dienen kann:

Entwicklungsumgebung

Hier haben Entwickler volle Kontrolle und können ihre Applikationen testen und auch verschiedene Ansätze und Lösungen ausprobieren . Von Vorteil ist, wenn diese Umgebung der Produktionsumgebung zumindest vom Layout so ähnlich wie möglich ist, um frühzeitig potenzielle Fehlerquellen zu identifizieren. Manche Fehler werden unter Umständen erst ersichtlich wenn die einzelnen Komponenten getrennt voneinander laufen.

QS Umgebung

Hier führt das QS-Team manuelle und automatisierte Tests durch, um Codefehler und Funktionsstörungen aufzuspüren. Auch Lasttests werden oft in dieser Umgebung durchgeführt, wobei auch hier das Layout der Produktionsumgebung simuliert werden sollte.

PreLive Umgebung

Diese optional eingerichtete Umgebung simuliert die Live-Umgebung kann für das durchführen von Lasttests, dazu später mehr, seitens des QS Teams und/oder des Betriebsteam verwendet werden.

Zudem bietet es dem Betriebsteam einige Vorteile. Sie ermöglicht es, das automatische Setup der Systeme mit Werkzeugen wie Puppet oder Ansible vorzubereiten und auf Fehlerfreiheit zu prüfen. Des weiteren bietet sie eine Plattform, um Monitoring-Checks zu evaluieren und angemessene Schwellenwerte festzulegen. Darüber hinaus kann das Deployment von Anwendungen auf potenzielle Probleme hin überprüft werden, beispielsweise auf Kompatibilitätsprobleme mit bestimmten Bibliotheksversionen oder unvollständig definierte Abhängigkeiten.

Live-Umgebung

Dies ist die abschließende Umgebung, in der das Produkt für Endkunden betrieben wird. Idealerweise führt die sorgfältige Vorbereitung und Erprobung in den vorherigen Umgebungen zu einem reibungslosen Betrieb in der Live-Umgebung.

Ein kleines Beispiel, bei dem ein Problem trotz sorgfältiger Vorbereitung erst später erkennbar wurde:

Ein Produkt verfügte über ein spezielles Webinterface für verschiedene administrative Tätigkeiten. Während der initialen Tests funktionierte alles einwandfrei. Jedoch wurde später zufällig entdeckt, dass bei gleichzeitiger Nutzung des Webinterfaces durch mehrere Personen und der Ausführung von Aufgaben es zu gegenseitigen Blockaden der Prozesse kam. Diese führten dazu, dass Aktionen nur in einigen Fällen überhaupt erfolgreich abgeschlossen wurden. Somit war dieses Webinterface nur „Single User fähig“.

Lasttests

Die Bedeutung von realitätsnahen Lasttests lässt sich an einem Beispiel verdeutlichen:

Eine, von einem externen Dienstleister entwickelte, Webanwendung, die Inhalte basierend auf der IP-Adresse (Geolokation) anzeigt, fiel kurz nach der Inbetriebnahme aufgrund von Überlastung aus.

Der Dienstleister führte vorab auch Lasttests durch. Wie konnte das also trotz Lasttests passieren? Es stellte sich heraus die durchgeführten Lasttests spiegelten nicht die „normale“ Nutzung wieder. Einige können sich vielleicht schon denken was passiert ist.

Bei den vom Dienstleister durchgeführten Lasttest kamen alle Anfragen von der gleichen IP Adresse mit dem immer gleichen Inhalt. Das führte dann dazu das für jeden Anfrage die gleiche Abfrage bei der dahinterliegenden Datenbank ausgeführt wurde. Jetzt wurde das Ergebnis dieser Datenbankabfrage natürlich im Cache der Datenbank abgelegt. Jede weitere Anfrage an das System konnte somit ohne wirkliche Last, im Millisekunden Bereich beantwortet werden.

Warum betonen wir, dass die für Lasttests genutzte Umgebung der Live-Umgebung so ähnlich wie möglich sein sollte? Verschiedene Faktoren tragen dazu bei, darunter:

• Unterschiede in der Netzwerktopologie und bei den Latenzzeiten können das Verhalten der Anwendung erheblich beeinflussen.
• Die Hardwarekonfiguration, wie beispielsweise der Einsatz verschiedener CPU-Typen oder der Wechsel von herkömmlichen Festplatten zu SSDs, was an anderen Stellen zu Leistungsengpässen führen kann.
• Das Verhalten von virtuellen Maschinen oder Containern unterscheidet sich oft signifikant von dem physischer Server.

Diese Faktoren können die Testergebnisse verzerren, wenn die Testumgebung nicht die Realbedingungen der Produktionsumgebung widerspiegelt.

Zusammenfassung

Ein durchdachtes Staging-Konzept ist nicht nur während der initialen Projektphase, sondern auch für die spätere Fehlerbehebung und Produktweiterentwicklung von Vorteil. Es maximiert den Nutzen der investierten Ressourcen über den gesamten Lebenszyklus des Produkts.

Abschließend sei betont, dass dieses Modell keinen universellen Lösungsansatz darstellt oder vor sämtlichen unvorhergesehenen Problemen schützt, jedoch hat sich dieser Ansatz in unserer Erfahrung als äußerst effektiv erwiesen und uns viele schlaflose Nächte erspart.

Bedeutung der Dokumentation

Obwohl es für viele von uns in der IT-Branche, unabhängig von der Spezialisierung, oft als lästige Pflicht empfunden wird, spielt die Dokumentation für Software, Prozesse und Betriebsabläufe eine entscheidende Rolle. Allzu oft wird das Verfassen der Dokumentation jedoch als nachrangige Aufgabe angesehen, die dann durch neue Projekte oder scheinbar dringendere Tätigkeiten in den Hintergrund gedrängt wird. Es ist keine Seltenheit, dass wir es selbst erleben, für Systeme, für die wir verantwortlich sind, keine oder nur unvollständige beziehungsweise veraltete Dokumentation vorzufinden. Dies trifft ebenso auf viele kommerzielle und Open-Source-Produkte zu.

Die meisten von uns sind sicherlich auf die folgenden Herausforderungen gestoßen:

• Installationsanleitungen enthalten Kommandozeilenbefehle, die nicht funktionieren oder nur in älteren Versionen funktioniert haben.
• Trotz akribischer Befolgung der Schritt-für-Schritt-Anleitung gelingt es nach mehreren Versuchen nicht, das gewünschte Ergebnis zu erzielen.
• Bereitgestellte Beispielkonfigurationen ermöglichen nicht den Start der Applikation, führen zu abweichenden Funktionen oder setzen Benutzerrechte nicht korrekt. Oft fehlt auch eine Erklärung der verwendeten Optionen sowohl in den Beispielkonfigurationen als auch in anderen Teilen der Dokumentation.
• Dokumentationen, die lediglich auf Quellcode verweisen, sind ohne entsprechendes Fachwissen unverständlich.
• Eigene Dokumentationen enthalten eingefügte Witze, unkommentierte und unsortierte Befehle, oder es wird darauf verwiesen, dass die Dokumentation zu einem späteren Zeitpunkt erstellt wird.

Angesichts der stetig wachsenden Komplexität in der IT-Landschaft (Zu diesem Thema habe ich auch etwas in meinem letzten Blogbeitrag Innovation vs. Stabilität geschrieben.) sind qualitativ hochwertige Dokumentationen wichtiger denn je. Das ist nicht nur für Auszubildende oder Berufseinsteiger relevant, die die Grundlagen erst verstehen müssen, sondern auch für erfahrene Fachkräfte mit jahrzehntelanger Erfahrung in ihrem Bereich.

Daher richten wir einen Appell an uns alle: Gute Dokumentation kann uns allen viel Frust ersparen, sei es durch einen zusätzlichen Kommentar im Quellcode oder durch das Verfassen einer Anleitung, die auch für Personen verständlich ist, die zuvor keine Berührung mit dem Thema hatten, oder für jemanden, der nachts um drei Uhr ein komplexes Problem im Halbschlaf beheben muss.

Andere Blickwinkel

Abschließend möchten wir den Vorschlag unterbreiten, dass Interessierte – sei es als Softwareentwickler, Mitarbeiter in der Qualitätssicherung, Projektmanager, Produktverantwortliche oder in einer anderen Rolle – ihre persönlichen Perspektiven zum Thema als Gastbeitrag in unserem Blog teilen können.