Blog

Auswirkungen des Vorfallmanagements auf den Entwickler

von Zachary Flower 10. März 2016 | 4 Minuten Lesezeit

Obwohl ich mich schon fast mein ganzes Leben lang für Computer interessiere, bekam ich meinen ersten Job im Computerbereich erst im ersten Studienjahr. Systemadministrator Für das Zentrum für Integrierte Plasmaforschung. Wie alle Jobs an der Universität bot auch dieser eine hervorragende Lernmöglichkeit bei unterdurchschnittlicher Bezahlung und viel Freiraum für selbstständiges Arbeiten. Meine Aufgaben reichten damals von der Systemadministration bis hin zu grundlegenden Helpdesk-Diensten für die Mitarbeiter. Die nächsten vier Jahre arbeitete ich als Systemadministrator für verschiedene Abteilungen der Universität und anschließend noch ein Jahr als Rundfunktechniker (eine andere Geschichte). Ich denke, es war die Arbeit in diesen Jahren, die mir den Respekt vor der Komplexität eines professionellen Incident-Managements vermittelt hat.

Kommt Ihnen das bekannt vor? Ein Benutzer meldet einen geschäftskritischen Fehler im System. Sie erkennen sofort, dass es sich um ein Problem handelt, das vom Entwicklerteam behoben werden muss, leiten es an die zuständige Person weiter und arbeiten an Ihrem nächsten Arbeitstag. Möglicherweise erhalten Sie eine Rückmeldung vom Entwicklerteam, möglicherweise aber auch nicht. Je nach Komplexität des Problems kann die Antwort, falls Sie überhaupt eine erhalten, eher kühl ausfallen – von einem frustrierten Entwickler, dem gerade ein weiterer schwerer Schlag in den Arbeitsalltag verwickelt wurde.

Eines möchte ich klarstellen: Es ist nicht allein deine Schuld.

Als Entwickler neigen wir dazu, frustriert zu sein, wenn uns ein Problem begegnet. Nicht das Problem selbst ist das Problem – Problemlösung macht Spaß! Problematisch ist vielmehr die Liste der unbeantworteten Fragen, die damit einhergehen. Wann ist es passiert? Welche Benutzer sind betroffen? Wo sind die Protokolle? Gibt es überhaupt Protokolle? Wie kann ich das Problem reproduzieren? Ist es schon einmal aufgetreten? Wer ist für diese Funktion verantwortlich? Ist diese Person heute im Büro? Wie soll ich das mit meiner aktuellen Arbeitsbelastung vereinbaren?

Die Fragen häufen sich immer weiter an, und ehrlich gesagt, ist das beängstigend.

Es geht aber nicht nur um uns. Wir verstehen, dass wir Tickets oft mit den Informationen erhalten, die uns zum Zeitpunkt der Bearbeitung vorliegen. Wenn ein Vorfall die Hierarchie hinaufgeht, ist es für den nächsten Kollegen am wichtigsten, alles zu dokumentieren: durchgeführte Schritte, Notizen, Protokolle. Je mehr Informationen, desto besser. Niemand muss alles wissen, aber wenn Sie etwas untersuchen können (sei es durch Nachfragen oder das Einsehen von Protokollen), sollten Sie unbedingt alle Informationen dokumentieren, um das Problem effektiv zu lösen.

Kehren wir zum vorherigen Szenario zurück. Ein Benutzer meldet einen geschäftskritischen Fehler im System. Obwohl dies offensichtlich ein Problem ist, das vom Entwicklungsteam behoben werden muss, können Sie, bevor Sie es an die nächsthöhere Ebene weiterleiten, dem Benutzer klärende Fragen stellen und versuchen, den Fehler zu reproduzieren. Reproduzierbare Fehler sind behebbare Fehler. Wenn Sie den Fehler reproduzieren können, dokumentieren Sie alle Schritte, Screenshots, Fehlermeldungen und den genauen Ablauf. Nachdem Sie all diese Informationen zusammengetragen haben, können Sie sie an das zuständige Mitglied des Entwicklungsteams weiterleiten, das die Bearbeitung dort fortsetzt, wo Sie aufgehört haben.

Ein guter Fehlerbericht kann darüber entscheiden, ob ein Entwickler abends mit seiner Familie zu Abend essen kann oder eine Nacht durcharbeitet. Doch damit nicht genug. Sobald ein Fehler das Entwicklerteam betrifft, sollte der Zyklus aus Untersuchung und Dokumentation während des gesamten Prozesses beibehalten werden. Dies ist nicht nur ein wichtiger Schritt zum Verständnis des Problems. Was Es ist zwar passiert, aber es ist auch entscheidend zu verstehen, wie sich die Wahrscheinlichkeit eines ähnlichen Vorfalls in Zukunft verringern lässt. Effektives Incident-Management ist Teamarbeit. Von den Mitarbeitern an vorderster Front bis hin zu den Fachexperten trägt jeder eine wichtige Rolle bei der schnellen und effizienten Problemlösung.