3. Nachbereitung
Manchen Leuten scheint es gegeben, häufiger als andere richtige Voraussagen zu machen und damit Probleme schneller zu lösen. Beobachtet man diese Leute genauer, stellt man fest, das sie keine Voraussagen über die Zukunft machen, sondern aus der Vergangenheit. Der Volksmund nennt dieses Phänomen auch Erfahrung.
Nach dem letzten Fehler wird es einen nächsten geben. Darum ist die Nachbereitung immer auch eine Vorbereitung auf kommende Fehlersuchen.
Manchmal folgt der nächste Fehler so schnell, dass kaum Zeit für die Rückschau bleibt. Tritt dieser Umstand häufiger auf, ist das ein Zeichen dafür, dass eine Rückschau umso nötiger ist. Dann kann ich mir wenigstens eine Liste oder Tabelle anlegen, in der ich die aufgetretenen Fehler zusammen mit ihrem Schweregrad festhalte. So habe ich später eine Entscheidungsgrundlage, wenn Zeit da ist, sich einem Thema intensiver zu widmen.
Kontrolle der Erledigung
Auf jeden Fall kontrolliere ich nach der Fehlersuche, ob der Fehler wirklich behoben und nicht nur verdeckt ist. Darum habe ich mir zur Angewohnheit gemacht, ein Ticket erst zu schließen, wenn ich eine Bestätigung von dem bekommen habe, der mir das Problem gemeldet hat.
Das kann, gerade bei Problemen mit der Performance, schwierig sein wenn der Meldende eine andere Vorstellung von erledigt hat, als ich. In diesem Fall helfen SLAs, die man natürlich vorher vereinbart haben sollte.
Der kurioseste Fall, der mir bisher begegnete, war ein Kunde, der bei der Rückfrage ob ein Performanceproblem behoben ist, anstelle eine Verbesserung zu bestätigen oder verneinen, die Gegenfrage stellte, ob ihn das etwas kostet. Auch dieser Situation kann man mit klaren Vereinbarungen beikommen.
In dem Artikel [Bartsch2013] geht der Autor auf einige rechtliche Aspekte der Gestaltung von Service Level Agreements (SLA) als Bestandteil von IT-Verträgen in einer Form ein, die auch für Nichtjuristen verständlich ist.
Vertiefen der Erkenntnisse
Um zu einem tieferen Verständnis des Systems zu kommen, kann ich die 5-W-Methode anwenden, bei der ich fünfmal warum frage. Beim ersten Mal frage ich nach den unmittelbaren Ursachen des konkreten, soeben gelösten Problems. Dabei berücksichtige ich, dass ein Problem meist nur einen Auslöser aber oft mehrere Ursachen hat. Das zweite warum fragt nach den Ursachen der Ursachen, dann nach deren Ursachen und so weiter. Am Ende kenne ich die wesentlichen Aspekte des Systems, die zu diesem Fehler geführt haben.
Ein einfaches Beispiel, dass ich Wikipedia entnommen habe, soll das Vorgehen verdeutlichen.
- Warum startet das Fahrzeug nicht?
Die Starterbatterie ist leer.
- Warum ist die Starterbatterie leer?
Die Lichtmaschine funktioniert nicht.
- Warum funktioniert die Lichtmaschine nicht?
Der Treibriemen ist gerissen.
- Warum ist der Treibriemen gerissen?
Der Treibriemen wurde nie ausgewechselt.
- Warum wurde der Treibriemen nie ausgewechselt?
Das Fahrzeug wurde bisher nie gewartet.
Die Anzahl der Nachfragen muss nicht stur auf fünf beschränkt bleiben. Manchmal ist bereits mit weniger Fragen die auslösende Ursache ermittelt, manchmal braucht es mehr.
Am Ende kann ich meine Gedankenkette überprüfen, indem ich den Kausalzusammenhang umkehre. Das sieht für obiges Beispiel dann ungefähr so aus:
- Wenn das Fahrzeug nicht gewartet wird, wechselt niemand den Treibriemen.
- Wenn der Treibriemen nicht gewechselt wird, reißt er irgendwann.
- Wenn der Treibriemen reißt, funktioniert die Lichtmaschine nicht.
- Wenn die Lichtmaschine nicht funktioniert, wird die Starterbatterie nicht geladen und ist irgendwann leer.
- Wenn die Starterbatterie leer ist, startet das Fahrzeug nicht.
Es kann passieren, dass ich nicht wie in obigem Beispiel auf linearem Wege von einer Ursache zur anderen komme, sondern herausfinde, dass erst das Zusammentreffen verschiedener Ursachen zu diesem Problem führte. In diesem Fall habe ich in der nächsten Runde statt einer einzigen Frage, mehrere.
Lautet zum Beispiel in obigem Beispiel die Antwort auf Frage 4 wie folgt:
- Warum ist der Treibriemen gerissen?
Der eingebaute Treibriemen der Sorte A hält nur 12.000 km, Sorte B hält 20.000 km, das Wartungsintervall beträgt 15.000 km.
Dann könnten die folgenden Fragen lauten
5.1. Warum wurde ein Treibriemen der Sorte A eingebaut?
5.2. Warum wurde das Wartungsintervall nicht reduziert?
Natürlich reicht es nicht, nur nach den Ursachen zu fragen. Vielmehr muss ich in jeder Stufe überlegen, welche Möglichkeiten es gibt, die entsprechende Ursache zu beseitigen. Falls das nicht möglich ist, finde ich vielleicht ein paar Parameter, im Fachjargon KPI (Key Performance Indicator) genannt, die ich im Monitoring-System beobachten kann und die mir bei der nächsten Fehlersuche behilflich sind.
Allerdings muss ich sowohl beim Beseitigen der Ursachen als auch beim Monitoring darauf achten, dass mir die Pferde nicht durchgehen.
Recht einfach ist das beim Monitoring zu erkennen. Geht mehr als 50% der Systemaktivität nur für das Monitoring drauf, dann wird mir fast jeder zustimmen, dass ich über das Ziel hinausgeschossen bin. Wo genau die Grenze ist, liegt im Ermessen des Einzelnen und natürlich bei den Anforderungen an das System. Auf jeden Fall ist relativ einfach zu erkennen, ob ein System nur noch damit beschäftigt ist, sich selbst zu überwachen, oder ob es noch produktiv ist.
Schwerer ist beim Beseitigen erkannter Fehlerursachen einzuschätzen, wo ich die Grenze ziehen muss. Ich neige dazu, einem System dass “scheinbar” fehlerfrei läuft, weniger Aufmerksamkeit zu widmen. So lange alles gut eingestellt ist und nichts passiert, ist das in Ordnung. Wenn sich aber unbemerkt über einen längeren Zeitraum kaum wahrnehmbare Probleme addieren, deren Auswirkungen bis zu einem gewissen Grad automatisch kompensiert werden, wird es mich unvermittelt und besonders heftig treffen, wenn die automatische Korrektur nicht mehr ausreicht. Das passiert meist im ungünstigsten Augenblick. In [Taleb2012] ist das Problem sehr gut beschrieben.
Ich muss die Balance finden zwischen notwendigem und übermäßigem Monitoring sowie zwischen anfälligen, pflegeintensiven Systemen, die ich aus dem Effeff beherrsche und stabilen, wartungsarmen Systemen, die ich im Fehlerfalle erst kennenlernen muss.
Wo ich den Schwerpunkt setze, hängt unter anderem vom Einsatzzweck, den Kosten und der geforderten Ausfallsicherheit des Gesamtsystems ab.
Verallgemeinerung der Erkenntnisse
Spätestens jetzt ist es an der Zeit, das Laborbuch mit den während der Fehlersuche gewonnenen Erkenntnissen zu ergänzen. Vielleicht schreibe ich auch einen Artikel zum Thema. Das hilft mir gleich in mehrfacher Hinsicht. Zum einen verankert das Ausformulieren die Erkenntnisse besser im Gehirn. Dann kann ich den Artikel zur Schulung der Kollegen heranziehen. Und schließlich kann ich ihn vielleicht später bei ähnlich gelagerten Problemen zu Rate ziehen.
Habe ich genug Zeit für die Rückschau, dann überlege ich, ob ich dieses Problem auch auf andere Art hätte eingrenzen können. Gibt es vielleicht einen schnelleren Weg, der mich auch zur Lösung geführt hätte. Oder einen, der weniger aufwendig gewesen wäre.
Im Gegenzug kann ich fragen, ob mein diesmal verwendeter Lösungsweg auch für andere Probleme einsetzbar ist. Wenn ja, für welche?
In der Verallgemeinerung führen mich diese Fragen und ihre Antworten zu einem an meine konkrete Umgebung und Situation angepassten Entscheidungsbaum, der zukünftige Fehlersuchen beschleunigen kann.
 |
Nimm die Aufzeichnungen zu einer der letzten Fehlersuchen zur Hand und fasse die Erkenntnisse zusammen in einem Artikel. Wenn Du willst kannst Du den Artikel veröffentlichen. |
Probleme verhindern?
Habe ich mich mit dem System und diesem speziellen Fehler vertraut gemacht, kann ich überlegen, wie ich das Auftreten dieses Fehlers hätte vorhersehen und verhindern können.
Wir kommen hier in den Bereich Systemarchitektur und Qualitätssicherung, der weit über das Thema dieses Buches hinausgeht. Ich will mich daher auf einige Anregungen beschränken.
Anhand der mit der 5-W-Methode erhaltenen Erkenntnisse überlege ich, ob ich durch technische oder organisatorische Maßnahmen entlang der Fragenkette das Auftreten dieses Fehlers verhindern will oder durch Monitoring der ermittelten KPI eine Art Frühwarnsystem einrichte, um rechtzeitig vor Auftreten des Fehlers Gegenmaßnahmen einleiten zu können.
Wie bereits im Abschnitt über das Vertiefen der Erkenntnis erwähnt, muss ich hier eine Balance finden. Wo diese Balance liegt, hängt von der Auswirkung des Fehlers ab und von den Mitteln, die mir zur Verfügung stehen.
An einem Ende der Skala habe ich relativ chaotische Systeme mit mehr oder weniger regelmäßig auftretenden kleinen Problemen, die ich üblicherweise im Griff habe und auf die ich im Laufe der Zeit vorbereitet bin. Zuverlässigkeit erreiche ich durch Redundanz auf höherer Ebene, im Extremfall dadurch, dass die Benutzer wissen, wie sie im Fehlerfall weiter arbeiten können.
Am anderen Ende sind Systeme, die bis ins kleinste durchdacht sind und Störungen automatisch kompensieren oder gar korrigieren. Diese Systeme sind wartungsarm und fallen erst - aber genau dann - aus, wenn ein Problem auftritt an das der Architekt nicht gedacht hat.
Ich persönlich starte lieber mit einem chaotischen System vom Typ 1 und entwickle dieses auf Grund der Erkenntnisse, die ich bei Fehlersuchen gewinne, in Richtung geordnetes System vom Typ 2, dass am Ende genau auf die jeweilige Situation zugeschnitten ist. Im Laufe der vielen Fehlersuchen lerne ich, welche Vitalfunktionen ich überwachen muss, um einen stabilen Betrieb zu gewährleisten.
Ein von Anfang an fertiges System hat demgegenüber den Vorteil der geringeren Wartung. Da habe ich weniger zu tun und kann meine Zeit für andere Sachen nutzen. Diesen Vorteil bezahle ich mit einer höheren Abhängigkeit von demjenigen, der sich mit dem System auskennt. In der Regel ist das der Hersteller. Zwar besteht die Möglichkeit, das System kennenzulernen, zum Beispiel über gezielte Schulungen oder Workshops. Meist ist die Motivation zum Lernen aber gering, wenn ich das Gelernte anschließend nicht anwenden kann. Damit wiege ich mich bei diesem System in einer trügerischen Sicherheit, bis zu dem Tage, an dem es an seine Grenzen gelangt und ich auf Grund mangelnder Kenntnis nicht angemessen reagieren kann. Ich empfehle an dieser Stelle noch einmal ausdrücklich [Taleb2012], der dieses Problem umfassend erörtert und zudem noch kurzweilig zu lesen ist.
Monitoring
Ich hatte bereits angesprochen, dass ich eine Balance finden muss, zwischen zu geringem Monitoring, bei dem mich fast jedes Problem unvorbereitet trifft und übermäßigem Monitoring, bei dem kaum noch Ressourcen übrig sind für die eigentliche Aufgabe des Systems.
Gehe ich bei der Auswertung der Fehler gründlich und sorgfältig vor und betrachte nicht jeden Fehler einzeln, sondern setze ihn in Beziehung zu vorhergehenden Fehlern, dann stoße ich auf die Vitalfunktionen, die ich beobachten muss, um mit einem Blick entscheiden zu können, ob ein Eingriff notwendig ist.
Wenn ich den Weg vom chaotischen in Richtung stabiles System gehe, bekomme ich diese Vitalfunktionen und vor allem ihre Parameter durch eigene Erfahrung heraus. Nutze ich ein fertiges, geschlossenes System, bin ich darauf angewiesen, dass mir der Hersteller die zu überwachenden Funktionen und deren Parameter nennt oder mich zumindest soweit schult, dass ich sie selbst bestimmen kann.
Die allgemeinen Vitalfunktionen sind diejenigen, nach denen ich bei Problemen mit der Performance des Systems schaue. Auf einem Server sind das Auslastung des Prozessors, Speichernutzung und Eingabe-Ausgabe-Aktivität. Im Netzwerk sind es Datendurchsatz an neuralgischen Punkten, die Latenz und die Verfügbarkeit und Antwortzeit essentieller Dienste.
Um Probleme so früh wie möglich zu erkennen, reicht es nicht, den aktuellen Wert dieser Variablen zu betrachten. Damit erkenne ich ein Problem erst, wenn es aufgetreten ist. Will ich vorher reagieren, muss ich die Trends beobachten.
Schulungen
Um meine Kollegen zu schulen, mache ich mir Gedanken, wie ich diesen eben gelösten Fehler in einem Testsystem gezielt hervorrufen kann. Damit kann ich eine möglichst realistische Trainingssituation schaffen, in der das Problem und die Auswirkungen in aller Ruhe studiert werden können.
Das setzt voraus, das mir ein geeignetes Testsystem zur Verfügung steht. Und das den Kollegen der Wert des Trainings für ihre tägliche Arbeit bewusst ist.
Damit kommen wir in den Bereich der Vorbereitung auf den nächsten Fehler, indem ich meine Herangehensweise auf den Prüfstand stelle und nötigenfalls anpasse.
Dabei mache ich auch mir Gedanken über meine Gewohnheiten. Da mein Handeln sehr stark von Gewohnheiten dominiert wird, stelle ich diese hin und wieder auf den Prüfstein. Welche Gewohnheiten haben mir bei der letzten Fehlersuche geholfen und welche waren eher hinderlich. Dementsprechend kann ich mich daran machen, nutzlose oder gar schädliche Gewohnheiten allmählich durch bessere zu ersetzen.
Details und Gesamtbild
Vor meinem Studium habe ich einen Beruf erlernt, in dem ich unter anderem Telefonvermittlungsanlagen, die damals noch mit Relais funktionierten, reparieren musste. Damals hatten wir zwei Arten dieser Anlagen. Die alten, mit Hebdrehwählern hatten nur wenige Relais. Wenn man in der Vermittlungsstelle beobachtete, was beim Abheben des Telefonhörers passierte, dann konnte man das nächste betätigte Relais ansagen.
Die anderen, moderneren Anlagen, funktionierten mit Koordinatenschaltern. Das waren große elektromagnetische Schalter, die in einer Matrix die richtige Verbindung durchschalteten. Diese konnten eine Verbindung schneller durchschalten, als Hebdrehwähler. Dafür benötigten sie erheblich mehr Relais zur Funktion und Fehler konnten dort nicht wie in den alten Anlagen analysiert werden, da fast immer mehrere Relais gleichzeitig betätigt wurden. Dafür lernten wir eine andere Herangehensweise. Zunächst setzten wir uns so, dass wir die ganze Anlage im Blick hatten. Dann beobachteten wir wiederholt das Gesamtbild der Anlage, wenn bestimmte Aktionen ausgeführt wurden. Anschließend verglichen wir die Relais, die sich bewegt hatten mit dem Schaltplan der Anlage. Auf diese Art erarbeiteten wir uns analytisch Stück für Stück den Zusammenhang zwischen dem, was wir gesehen hatten und dem, was laut Schaltplan hätte passieren müssen. Am Anfang wiederholten wir das mit einer funktionsfähigen Anlage. Nach einiger Zeit isolierte unser Lehrmeister einige Relaiskontakte mit farblosem Kleber. Unsere Aufgabe war es nun, herauszufinden, welche Kontakte schlecht waren. Später durften die Fortgeschrittenen sich selbst Fehler auszudenken, die die anderen finden sollten. Natürlich setzte jeder seinen Ehrgeiz darein, Fehler einzubauen, die durch ihr Verhalten die anderen zunächst auf die falsche Spur schickten. Und natürlich kannten wir diese Anlagen am Ende in- und auswendig. Was wir dabei - spielerisch - übten, war ein Umschalten zwischen dem visuellen, wahrnehmenden Modus und dem sprachlich, analytischen Modus unseres Gehirns. Und, ja, heute könnte ich keine solcher Anlagen mehr reparieren, müsste alles erst wieder lernen. Was ich aber immer noch kann, ist relativ schnell zwischen dem Gesamtbild eines Problems und den Details zu wechseln.
Dieser Exkurs in eine längst vergangene Zeit war nötig, um einen Aspekt hervorzuheben, der damals so wichtig war, wie er heute ist: dass die unzähligen Details, die ich bei der Fehlersuche wissen muss, für sich genommen nichts wert sind, wenn es mir nicht gelingt, diese in ein Gesamtbild einzufügen und richtig zu bewerten. Wenn ich in der Lage bin, das Gesamtbild zu sehen, kann ich für jedes Detail einschätzen, ob es korrekt, falsch oder irrelevant ist und mich dann dem nächsten zuwenden.
Da nicht jeder heute Zugang zu alten Telefonvermittlungsanlagen und deren Schaltplänen hat, sind vielleicht andere Methoden gefragt, die beiden Modi des Gehirns und vor allem das Umschalten zwischen diesen zu trainieren. Eine Möglichkeit bietet das Zeichnen. Nicht so, wie es in den meisten allgemeinbildenden Schulen gehandhabt wird, sondern eher so, wie es in [Edwards2012] beschrieben ist. Für die Fehlersuche ist es nicht von Belang, wie gut man zeichnen kann. Der souveräne Umgang mit den beiden Modi ist aber enorm hilfreich bei komplexen Problemen, die man nicht auf einmal erfassen kann. Diesen Umgang und das Umschalten zwischen beiden Modi zu trainieren ist mit dem genannten Buch sehr gut möglich.
Aktiv zwischen beiden Modi umschalten zu können, ist wichtig, weil ich nur im R-Modus in der Lage bin, Beobachtungen so wahrzunehmen, wie sie sind. Der L-Modus mit seinem Hang zum Bewerten und Kategorisieren verfälscht oft genug meine Wahrnehmungen, weil sie nicht in das selbstgemachte Bild passen. Das funktioniert genau dann nicht, wenn ich es mit einem Problem zu tun habe, das mir nie zuvor begegnet ist. Dann muss ich unvoreingenommen beobachten können und jegliche Bewertung auf später verschieben.