IT-Support richtig machen: Ein praktischer Feldleitfaden

Die meiste IT-Support-Arbeit wird nach Geschwindigkeit bewertet, aber Geschwindigkeit ohne Methode verschiebt das gleiche Problem nur in den nächsten Flur. Ein Ticket, das in fünf Minuten geschlossen wird und nach drei Tagen erneut aufmacht, kostet mehr als eines, das zwanzig Minuten dauert und tatsächlich behoben wird. Dieser Leitfaden behandelt die Gewohnheiten, die jemanden, der Tickets schließt, von jemandem unterscheiden, der Probleme löst.

Beginne mit einer echten Aufnahme, nicht mit einer Vermutung

Bevor du eine Maschine anfasst, lass den Benutzer das Problem in seinen eigenen Worten beschreiben, dann stelle drei Nachfragen: wann hat es angefangen, was hat sich kürzlich geändert, und passiert es jedes Mal oder nur manchmal. "Mein Internet ist langsam" könnte DNS-Auflösung, einen gesättigten Wi-Fi-Kanal, eine fehlerhafte NIC oder einen Browser mit vierzig offenen Tabs bedeuten. Schreib den genauen Fehlertext auf, falls vorhanden. Screenshots schlagen Beschreibungen immer — frag danach, bevor du den Benutzer etwas versuchen lässt.

Widerstand der Versuchung, direkt zu "hast du schon neu gestartet" zu springen. Es funktioniert oft genug, dass die Leute es zur Standardlösung machen, aber wenn du die Aufnahme überspringst, verpasst du Muster. Wenn drei Personen am gleichen Switch die gleiche Langsamkeit in der gleichen Stunde berichten, ist das ein anderes Ticket als ein Laptop mit einem fehlerhaften Treiber.

Reproduziere vor du reparierst

Wenn du ein Problem nicht reproduzieren kannst, kannst du nicht bestätigen, dass du es behoben hast. Lass den Benutzer die genauen Schritte in einem Screen Share durchgehen, oder mach es selbst auf seiner Maschine, wenn Remote-Tools das zulassen. Überprüfe ipconfig /all unter Windows oder ip a unter Linux auf grundlegende Netzwerk-Integrität, schau in Event Viewer (eventvwr.msc) nach Anwendungs- und Systemfehlern um die gemeldete Zeit, und überprüfe journalctl -xe --since "1 hour ago" auf Linux-Boxen für das gleiche Zeitfenster.

Bei Anwendungsabstürzen hole die genaue Build-Nummer und OS-Version. "Es ist abgestürzt" sagt dir nichts; "Outlook 16.0.17726 stürzt ab beim Öffnen einer Kalendereinladung mit einem .ics-Anhang" sagt dir, wo du nachschauen musst. Vergleiche gegen bekannte Probleme in Vendor-Versionshinweisen, bevor du davon ausgehst, dass es lokal ist.

Triage nach Auswirkung, nicht danach, wer am lautesten ruft

Ein einzelner Benutzer ohne E-Mail-Zugang ist unbequem. Ein gemeinsamer Dateiserver, der für vierzig Personen unerreichbar ist, ist ein Ausfall. Erstelle eine einfache Schweregrad-Skala — etwa P1 für Ausfälle, die mehrere Benutzer oder kritische Systeme betreffen, P2 für Single-User-Blockierer, P3 für gedrosselt-aber-funktionierend, P4 für kosmetische oder Komfort-Anfragen — und wende sie konsistent an, auch unter Druck eines Managers, der sein Ding zuerst haben will.

Dokumentiere die Schweregrad-Entscheidung im Ticket selbst. Das schützt dich später, wenn jemand fragt, warum sein P3 zwei Tage herumgesessen hat, während du drei P1s bearbeitet hast.

Behebe die Grundursache, nicht das Symptom

Einen Service neu zu starten, der ständig abstürzt, kauft Zeit, keine Lösung. Wenn ein Print Spooler täglich stirbt, überprüfe Get-WinEvent -LogName Application -MaxEvents 50 auf den eigentlichen Fehler, bevor du ihn wieder neu startest. Wenn das Passwort eines Benutzers unerwartet immer wieder abläuft, überprüfe die Gruppenrichtlinie, die auf seine OU angewendet wird, anstatt es einfach zurückzusetzen und weiterzumachen.

Führe ein persönliches Protokoll wiederkehrender Fixes. Wenn du dich selbst dabei ertappst, den gleichen PowerShell-Befehl oder die gleiche Registry-Änderung drei Mal zu tippen, ist das ein Zeichen, dass es in ein Skript oder ein dokumentiertes Runbook gehört, nicht in deinen Kopf.

Dokumentiere so, als würde jemand anderes es lesen

Jede Ticket-Lösung sollte beantworten: was war die eigentliche Ursache, was war die Lösung, und was würdest du zuerst überprüfen, wenn das wieder passiert. "Behoben" als Lösungsnote ist für den nächsten Techniker wertlos, einschließlich dir selbst sechs Monate später ohne Erinnerung an dieses Ticket.

Eine gute Lösungsnote sieht so aus: "Grundursache: DHCP-Bereich auf VLAN 20 erschöpft, neue Geräte erhielten APIPA-Adressen. Lösung: Bereich von /24 auf /23 erweitert, Reservierung für Drucker hinzugefügt. Überprüfung: DHCP-Lease-Anzahl monatlich überprüfen, Warnungsschwelle auf 90% gesetzt." Der dritte Satz ist der, den die meisten Techniker überspringen, und er ist derjenige, der das wiederholte Ticket verhindert.

Eskaliere mit Kontext, nicht nur einer Weiterleitung

Wenn ein Ticket an Tier 2 oder einen Vendor geht, beziehe ein, was du bereits ausgeschlossen hast. "Verkabelung überprüft, Port gewechselt, VLAN-Konfiguration bestätigt, immer noch kein Link Light" spart dem nächsten die erste zwanzig Minuten Wiederholung. Vage Eskalationen wie "Benutzer sagt, es ist kaputt, bitte Bescheid geben" verschieben nur die Verzögerung, anstatt sie zu beheben.

Schließe die Schleife mit dem Benutzer

Erzähl dem Benutzer in einfacher Sprache, was nicht stimmte, nicht nur "behoben." Menschen vertrauen Support mehr, wenn sie verstehen, was passiert ist, und es reduziert, dass die gleiche Person das gleiche Ticket nächsten Monat einreicht, weil sie nicht realisiert, dass es zusammenhängt.

Wenn du auf der technischen Seite von all dem tiefer einsteigen möchtest — Netzwerk-Grundlagen, Windows-Event-Logs oder das Scripting deiner eigenen Diagnose-Tools — hat Korra Studio Segmente über Networking, Systems und Scripting, die es wert sind, als nächstes durchzuarbeiten.