Aus Fehlern lernen

24.11.2020



Im Farnam Street Blog habe ich einen schönen Satz gefunden, der auch in der Netzwerktechnik seine Berechtigung hat: „Amateurs tend to focus on seeking brilliance. Professionals often know that it’s far more effective to avoid stupidity.„.


In diesem Artikel beschreibe ich anhand eines realen Falls aus meinem Arbeitsalltag, wie ich beim Lernen aus Fehlern vorgehe.

Der Fall

In einer Etage eines Gebäudes hatten Endgeräte plötzlich keine Netzwerkverbindung mehr . Diesen Umstand bemerkte ich erst nach einer Weile, als die ersten Störungsmeldungen aus dem betroffenen Bereich bei uns ankommen.


Analyse

Der erste Schritt beim Lernen aus Fehlern ist natürlich, dass man einen Fehler erkennt. Das heißt, eine Kausalkette einem beobachteten Sachverhalt bis zur Ursache zu bilden. Hier geht es also erst einmal um Troubleshooting.


Ich finde heraus, dass aufgrund einer Konfigurationsänderung auf den Interfaces eines Port-Channels der Port-Channel inaktiv wurde.

Nun stelle ich mir die Frage, wie ich diese Störung hätte verhindern bzw. deren Auswirkung minimieren können. Anders gesagt: wie hätten ich die Fehlkonfiguration der Interfaces verhindern können und wie hätte ich schneller bemerken können, dass mir ein Fehler unterlaufen ist?


Der Zusammenbruch des Port-Channels wurde durch die Konfiguration eines QoS-Befehls auf den Interfaces ausgelöst. Wie hätte ich dem vorbeugen können? Rückblickend ist das einfach: ich hätte diesen speziellen Befehl auf dieser speziellen Kombination von Hardware und Cisco-IOS-Version nicht anwenden dürfen (auf anderen Kombinationen trat das Problem so nicht auf). Hätte ich das vorher wissen können? Vielleicht, wenn ich vorher tiefere Kenntnisse zur QoS-Konfiguration erworben hätte. In der Praxis ist das jedoch nicht immer machbar. In solch einem Fall bleibt dann nur, diesen speziellen Fehler in Zukunft zu vermeiden.


Die zweite Frage ist, ob ich den Fehler nicht zeitnah bemerkt haben könnte. Ja, und das auf einfachem Wege. Ich hätte lediglich prüfen müssen, in welchem Zustand der betreffende Port-Channel nach meiner Konfigurationsänderung war (show etherchannel summary, show etherchannel port-channel). Hier kann ich sogar etwas verallgemeinern: die Prüfung des Port-Channel-Status ist nicht nur im konkreten Fall eine gute Idee, sondern generell, wenn man Konfigurationsänderungen vornimmt, die mit Port-Channels im Zusammenhang stehen (also den Port-Channels selbst, den zugehörigen Interfaces und dem gewählten Load-Balancing-Algorithmus).


Was fange ich nun mit diesen Erkenntnissen an? Ich mache mir zwei Lernkarten für meinen ANKI-Stapel Netzwerktechnik, um diese Erkenntnisse in meinem Gedächtnis zu verankern.


Die erste Lernkarte geht auf das spezifische Problem ein:

  • Frage: Was kann bei einer ungünstigen Kombination von Hardware und IOS-Version geschehen, wenn man den Befehl qos trust extend auf Interfaces konfiguriert, die Teil eines Port-Channels sind?

  • Antwort: Der Port-Channel kann zusammenbrechen.


Die zweite Lernkarte betrifft dann die Qualitätssicherung nach getaner Arbeit:

  • Frage: Was sollte man nach Konfigurationsänderungen an Port-Channels, den zugehörigen Interfaces oder dem Load-Balancing-Algorithmus tun?

  • Antwort: Prüfen, ob der Port-Channel aktiv ist (show etherchannel summary, show etherchannel port-channel)


Bei komplexeren Themen ist es auch sehr sinnvoll, mit Checklisten zu arbeiten, sowohl bei der Durchführung der Konfigurationsänderungen als auch bei der anschließenden Prüfung, ob alles in Ordnung ist.


Manchmal gibt es es nicht nur eine Ursache, sondern es wirken mehrere Ursachen zusammen, z. B. ist zusätzlich zur Fehlkonfiguration der Interfaces der ‚Zweitweg‘ aufgrund einer anderen Ursache nicht aktiv. Auch wenn dieses Problem vielleicht nicht gerade entstanden ist, sondern man nur gerade dessen Auswirkungen wahrnimmt, ist es sinnvoll, auch hier Ursachenforschung zu betreiben und daraus zu lernen.


Ich lerne auch gerne aus den Fehlern, die Andere machen (z. B. Kollegen oder Warnungen in der Fachliteratur vor beliebten Fehlern). Hier gehe ich dann möglichst genauso vor, wie oben beschrieben.