Allgemein, DevOps, Logfiles, Tools

“Es funktioniert nicht!”

Wie oft habt ihr das schon gehört oder in einem Ticket gelesen? Und wie oft hat euch diese Information in der Form geholfen? In meiner Erfahrung ist oftmals das größte Problem bei der Fehlerbehebung die genaue Definition des Fehlers. Gerade ist in meinem Feed Reader ein interessanter Blog Post aufgetaucht, der mich dazu bewegt hat meine Sicht auf das Thema nieder zu schreiben.

Wenn man ein Problem hat und Hilfe sucht, sollte man dem Helfenden zumindest folgendes klar benennen können. (Analog zu den 5 W-Fragen beim Notruf)

  • Was habe ich getan?
  • Wann habe ich es getan?
  • Was habe ich erwartet?
  • Was ist passiert?
  • Was habe ich schon probiert, um das Problem einzugrenzen?

Leider passiert es immer noch häufig, dass in unseren Ticketsystemen  oder direkt am Telefon Anfragen mit dem Inhalt “Funktioniert nicht”, “geht nicht”, “es ist kaputt” ohne weitere Informationen landen. Ich fange dann typischerweise an, die obige Liste durch zu gehen. Überraschend häufig löst sich das Problem schon auf, wenn der Fragende auf diese 5 W-Fragen antwortet. Warum ist das so? Um diese Fragen zu beantworten, muss man selbst reflektieren, was man getan hat und was eigentlich die Erwartungshaltung war. Dabei macht man sich Gedanken über sein Problem. Das reicht manchmal schon um selbst auf die Lösung zu kommen (wenn es sich um einen Bedienungsfehler handelt), oder den Fehler im System zu finden (Falls es sich um einen Bug oder eine defekte Komponente handelt).

Fall an diesem Punkt noch keine Antwort offensichtlich ist, hilft ein Blick ins, gut gepflegte, Monitoring. Gibt es hier Fehlermeldungen? Weichen bestimmte Metriken vom Normalwert ab? Was ich gelegentlich erlebe ist, dass Monitorings erst zum Zeitpunkt einer Störung eingerichtet werden. Diese sind leider häufig verwirrend und damit nutzlos (oder zumindest nur mit Vorsicht nutzbar) da ein Vergleich zum Normalzustand nicht möglich ist. Erst wenn ich weiß, dass 50 Datenbankverbindungen normal sind, kann ich ableiten, dass bei 10 oder 100 irgendwas faul ist. Ohne diesen Vergleich weiß ich nichts!

Wenn das bestehende Monitoring nicht ausreicht und weitere Nachforschungen nötig sind, um das Problem zu finden, sind vor allem Fehlermeldungen und Logfiles hilfreich.  Hier ist es wichtig zu wissen, welche Meldungen “normal” sind, also (leider) auch im ordnungsgemäßen Betrieb auftreten und diese heraus zu filtern. Mit den übrigen Meldungen kann man sich schon mal ein gutes Bild der Lage machen und auch sein Glück mit Google versuchen. Dabei ist es besonders wichtig, dass standardisierte Fehlermeldungen auf Englisch ausgegeben werden. Ich habe auch schon mehr als genug Zeit damit verbracht lokalisierte deutsche Fehlermeldungen in ihr englisches Äquivalent zu übersetzen nur um dann sofort die Lösung bei Google zu finden. Also bitte lokalisiert eure Fehlermeldungen nicht! Die einzige Ausnahme sind hier vielleicht Meldungen im Frontend, die dem Nutzer präsentiert werden.

In letzter Zeit debugge ich auch häufiger Netzwerkprobleme. Besonders hier gilt der Grundsatz “zurück in den Kindergarten und Buntstifte raus!”, ernsthaft! Ein Bild sagt mehr als tausend Worte. Um Abhängigkeiten und Netzwerkpfade zu verstehen, muss man immer die Architektur vor Augen haben. Ein System Architekt oder ein Engineer mit viel Erfahrung zeichnet das zwar nicht immer, aber vertraut mir, wir waren alle an dem Punkt an dem ein A3 Blatt und viele bunte Stifte uns den Hintern gerettet haben. Für Netzwerke gilt, zeichne alle Komponenten ein und male möglichst bunt alle Verbindungen in dein Diagramm. Hin- und Rückweg müssen immer gleich sein, wenn das irgendwo nicht eindeutig ist, hast du wahrscheinlich dein Problem gefunden.

Aber genug zu den einzelnen Analysemethoden, für diese werden sich später noch detailliertere Blogbeiträge finden. 😉

Abschließend noch ein Wort zu dem letzten Absatz des Beitrages, der mich zu diesem Text inspiriert hat.

Before you can solve a problem, you must first clearly define it.  And frequently, you’ll find that in defining a problem clearly enough that others can help you, mostly you’ll just end up resolving the problem on your own.

Diesen Satz darf man ruhig häufiger lesen. Wenn man sein Problem klar definieren kann, ist die passende Lösung auch oft in greifbarer Nähe.

2 comments

  1. Manu

    A3 Blatt und Buntstifte … Find ich gut oder wie es ein Kollege immer sagte: “Von der Lösung keine Spur … male eine Hilfsfigur”.

    Ich freu mich schon auf die Deep Dives zu verschiedenen Analysemethoden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.