Wsparcie IT zrobione prawidłowo: praktyczny przewodnik terenowy

Większość pracy w IT support ocenia się na podstawie szybkości, ale szybkość bez metody to tylko przesunięcie tego samego problemu dalej. Zgłoszenie zamknięte w pięć minut, które otwiera się ponownie za trzy dni, kosztuje więcej niż jedno, które zajmie dwadzieścia minut i rzeczywiście zostanie naprawione. Ten przewodnik obejmuje nawyki, które odróżniają kogoś, kto zamyka zgłoszenia, od kogoś, kto rozwiązuje problemy.

Zacznij od rzeczywistego pobrania danych, a nie domysłów

Zanim dotkniesz maszyny, poproś użytkownika, aby opisał problem własnymi słowami, a następnie zadaj trzy pytania uzupełniające: kiedy się zaczęło, co się ostatnio zmieniło i czy zdarza się to za każdym razem, czy sporadycznie. "Mój internet jest wolny" może oznaczać rozdzielczość DNS, nasycony kanał Wi-Fi, uszkodzony interfejs sieciowy lub przeglądarkę z czterdziestu otwartymi kartami. Zapisz dokładny tekst błędu, jeśli taki jest. Zrzuty ekranu zawsze biją opisy — poproś o jeden zanim poprosisz użytkownika, aby cokolwiek spróbował.

Odłóż na bok chęć przeskoczenia od razu do "czy próbowałeś restartować". To działa wystarczająco często, że ludzie stosują to domyślnie, ale jeśli pominiesz pobranie danych, przegapisz wzorce. Jeśli trzy osoby na tym samym switchu zgłoszą tę samą wolność w tej samej godzinie, to inne zgłoszenie niż jeden laptop ze złym sterownikiem.

Odtwórz zanim naprawisz

Jeśli nie potrafisz odtworzyć problemu, nie możesz potwierdzić, że go naprawiłeś. Poproś użytkownika, aby przeprowadził dokładne kroki na ekranie współdzielonym, lub zrób to sam na jego maszynie, jeśli narzędzia zdalne na to pozwalają. Sprawdź ipconfig /all na Windows lub ip a na Linux, aby sprawdzić podstawową sanację sieci, spojrz na Event Viewer (eventvwr.msc) pod kątem błędów aplikacji i systemu około zgłoszonego czasu i sprawdź journalctl -xe --since "1 hour ago" na maszynach Linux dla tego samego okna czasowego.

W przypadku awarii aplikacji uzyskaj dokładny numer kompilacji i wersję systemu operacyjnego. "Zawiesiła się" mówi ci nic; "Outlook 16.0.17726 zawiesza się przy otwieraniu zaproszenia kalendarza z załącznikiem .ics" pokazuje ci gdzie szukać. Skojarzyć ze znanymi problemami w notatkach wydania sprzedawcy przed założeniem, że to problem lokalny.

Priorytetyzuj na podstawie wpływu, a nie na podstawie tego, kto krzyczy najgłośniej

Jeden użytkownik zablokowany z dostępu do poczty e-mail to niedogodność. Współdzielony serwer plików niedostępny dla czterdziestu osób to awaria. Zbuduj prostą skalę ważności — coś w rodzaju P1 dla awarii dotykających wielu użytkowników lub systemy krytyczne, P2 dla blokerów jednego użytkownika, P3 dla zdegradowanych ale działających, P4 dla żądań kosmetycznych lub wygody — i stosuj ją konsekwentnie, nawet pod presją kierownika, który chce swoją rzecz pierwszy.

Zdokumentuj decyzję ważności w samym zgłoszeniu. To cię chroni później, gdy ktoś pyta, dlaczego jego P3 siedział przez dwa dni, podczas gdy ty obsługiwałeś trzy P1.

Napraw pierwotną przyczynę, a nie objaw

Zrestartowanie usługi, która ciągle się zawiesza, daje zyskanie czasu, a nie rozwiązanie. Jeśli drukarka kolejkuje się zawale codziennie, sprawdź Get-WinEvent -LogName Application -MaxEvents 50 pod kątem rzeczywistego błędu przed zrestartowaniem jej ponownie. Jeśli hasło użytkownika ciągle nieoczekiwanie wygasa, sprawdź zasadę grupy zastosowaną do ich OU zamiast po prostu zresetować je i przejść dalej.

Prowadziłem osobisty dziennik powtarzających się napraw. Jeśli okaże się, że wpisujesz tę samą komendę PowerShell lub tę samą poprawkę rejestru trzy razy, to znak, że należy do skryptu lub udokumentowanego runbooka, a nie w twojej głowie.

Dokumentuj tak, jakby ktoś inny to przeczytał

Każde rozwiązanie zgłoszenia powinno odpowiadać: jaka była rzeczywista przyczyna, jaka była naprawa i co byś sprawdzył pierwszy, gdyby to się powtórzyło. "Naprawione" jako notatka w rozwiązaniu jest bezwartościowe dla następnego technika, w tym ciebie za sześć miesięcy bez pamięci o tym zgłoszeniu.

Dobra notatka rozwiązania wygląda tak: "Przyczyna pierwotna: zakres DHCP na VLAN 20 wyczerpany, nowe urządzenia otrzymały adresy APIPA. Naprawa: rozszerzony zakres z /24 do /23, rezerwacja dla drukarki dodana. Weryfikacja: sprawdzaj miesięcznie liczbę dzierżaw DHCP, próg alertu ustawiony na 90%." To trzecie zdanie to to, które większość techników pomija, i to ten, który zapobiega powtórzonemu zgłoszeniu.

Eskaluj z kontekstem, a nie tylko forwarduj

Kiedy zgłoszenie trafia do tier 2 lub sprzedawcy, dołącz to, co już wyeliminowałeś. "Sprawdzałem kablowanie, wymieniałem port, potwierdzałem konfigurację VLAN, nadal brak lampki łącza" oszczędza następnej osobie powtarzania twoich pierwszych dwudziestu minut. Niejasne eskalacje takie jak "użytkownik mówi, że jest zepsuty, proszę o poradę" po prostu przenoszą opóźnienie zamiast go usuwać.

Zamknij pętlę z użytkownikiem

Powiedz użytkownikowi, co było nie tak w zwykłym języku, a nie tylko "naprawione". Ludzie bardziej ufają wsparciem, gdy rozumieją, co się stało, i zmniejsza to ilość przypadków, gdy ta sama osoba zgłasza ten sam problem w następnym miesiącu, ponieważ nie zdaje sobie sprawy, że jest powiązany.

Jeśli chcesz pogłębić się w stronę techniczną dowolnego z tego — podstawy sieci, dzienniki zdarzeń Windows lub tworzenie własnych narzędzi diagnostycznych — Korra Studio ma segmenty dotyczące sieci, systemów i skryptów warte przejrzenia dalej.