© Excellent backgrounds/Shutterstock.com
Wenn das System erzählt, was ihm weh tut

Design for Diagnosability


Auch das beste System kann Laufzeitanomalien enthalten, die es kurz- oder langfristig in einen instabilen und fehlerhaften Zustand versetzen. Je komplexer ein System ist, desto höher ist die Wahrscheinlichkeit für Laufzeitanomalien wie Speicherüberläufe oder langsame Antwortzeiten. Eine Garantie für Fehlerfreiheit gibt es nicht. Daher ist es sinnvoll, bereits beim Systementwurf Diagnosemöglichkeiten vorzusehen, ähnlich wie man Autos seit Jahren mit Diagnosesteckern ausrüstet. Dieser Artikel beschreibt den Weg eines Systems in die Diagnosefähigkeit, um die Ursache von Laufzeitanomalien schneller eingrenzen und reparieren zu können: Für eine lange MTTF (Mean Time to Failure) sorgt eine gute Softwarearchitektur, für eine kurze MTTR (Mean Time to Repair) sorgt die Diagnosefähigkeit eines Systems.

Wir sprechen von einer Laufzeitanomalie, wenn eine Anwendung Ressourcen (CPU, RAM etc.) nicht effizient genug nutzt, um ihre normalen nicht funktionalen Eigenschaften (Antwortzeiten, Verfügbarkeit etc.) gewährleisten zu können. Den Zustand eines Systems, in dem wir eine Laufzeitanomalie beobachten können, bezeichnen wir als kranken Zustand. Konkrete Beispiele für Laufzeitanomalien sind Leaks, Locks, stark schwankender Durchsatz, langsame Antwortzeiten und auch der Extremfall: ein Systemausfall.

Die Ursachenforschung bei Laufzeitanomalien beginnt meist mit der Bestandsaufnahme und dem Einsammeln von Laufzeitinformationen. Die Quellen dabei sind vielfältig: Nutzer, die von einem unerwarteten Verhalten berichten, Mitarbeiter des Betriebs, die nach einem Alert des Monitoring-Systems auf den Fehler hinweisen, oder Logdateien des Systems. Die Qualität und Aussagekraft dieser Informationen variieren dabei stark, diese sind aber oft der erste und einzige Ansatzpunkt bei der Fehlerdiagnose. Betrachten wir diese Informationen, können wir aus Erfahrung Folgendes sagen:

  • Nutzer: Detaillierte Informationen der Nutzer helfen dabei, die Fehlerwirkung zu reproduzieren. Meistens sind sie ein erster Ansatzpunkt, um den fachlichen Anwendungsfall zu verstehen, bei dem der Fehler aufgetreten ist. Was die genauen Auslöser der Fehlersituation sind, bleibt dabei aber oft im Dunkeln.

  • Monitoring: Die Messdaten aus dem Monitoring liefern eine technische Sicht auf das System durch Informationen wie Speicherverbrauch, CPU-Auslastung oder Anzahl der Prozesse auf dem System. Meist sind diese Daten jedoch zu wenig detailliert, um den Fehler eingrenzen zu können – geschweige denn, die Fehlerursach...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang