Ustrukturyzowane kroki rozwiązywania problemów

Losowe naprawy marnują czas, a czasami jeszcze pogarszają sytuację. Ustrukturyzowana metodyka rozwiązywania problemów zapewnia powtarzalną i logiczną drogę od objawu do rozwiązania. CompTIA sprawdza znajomość konkretnego siedmioetapowego procesu, ponieważ pomaga on technikom zachować porządek, nie pomijać wskazówek oraz uzyskiwać wyniki, które można udokumentować i powtórzyć. Postępowanie zgodnie z tymi krokami jest szybsze niż zgadywanie, nawet gdy odpowiedź wydaje się oczywista.

Model CompTIA obejmuje siedem kroków:

• 1. Zidentyfikować problem.
• 2. Ustalić teorię prawdopodobnej przyczyny.
• 3. Przetestować teorię.
• 4. Ustalić plan działania.
• 5. Wdrożyć rozwiązanie.
• 6. Zweryfikować pełną funkcjonalność.
• 7. Udokumentować ustalenia, wykonane działania i wyniki.

Proszę zapamiętać tę kolejność — egzamin pyta o nią bezpośrednio.

Zidentyfikować problem, zbierając informacje od użytkowników, z logów oraz z własnych testów. Proszę ustalić, co się zmieniło, kiedy problem się rozpoczął i kogo dotyczy. Należy podważać oczywiste założenia i, jeśli to możliwe, odtworzyć problem. Jasny i konkretny opis problemu, na przykład „brak internetu z sieci bezprzewodowej na drugim piętrze”, ukierunkowuje wszystkie kolejne działania. Ogólny opis prowadzi do ogólnego rozwiązania.

Ustalić teorię prawdopodobnej przyczyny. Na podstawie objawów należy sformułować uzasadnione przypuszczenie dotyczące źródła problemu. Proszę najpierw brać pod uwagę najbardziej prawdopodobne i najprostsze przyczyny, czyli tak zwane „łatwe punkty”, a dopiero potem bardziej nietypowe. Jeśli pojedynczy komputer nie ma dostępu do sieci, uszkodzony kabel jest bardziej prawdopodobny niż błąd protokołu routingu. Można mieć kilka teorii będących kandydatami.

Przetestować teorię, aby ustalić przyczynę. Należy wykonać test, który potwierdzi lub wykluczy dane przypuszczenie. Jeśli teoria się potwierdzi, można przejść dalej. Jeśli nie, należy sformułować nową teorię i ponownie ją przetestować albo eskalować problem do osoby dysponującej większą wiedzą lub dostępem. Nie wolno rozpoczynać naprawy przed faktycznym potwierdzeniem przyczyny, ponieważ można w ten sposób uszkodzić działające elementy.

Ustalić plan działania i określić potencjalne skutki. Należy dokładnie zdecydować, co zostanie zrobione, w jakiej kolejności i co może pójść nie tak. Proszę uwzględnić przestój, użytkowników, których może on dotknąć, oraz możliwość wycofania zmian, jeśli rozwiązanie nie zadziała. Planowanie zapobiega sytuacji, w której szybka naprawa jednego urządzenia przypadkowo zakłóca działanie całej lokalizacji. Większe zmiany wymagają większych i staranniej przygotowanych planów.

Wdrożyć rozwiązanie zgodnie z planem lub eskalować problem, jeśli wykracza on poza zakres Pana/Pani uprawnień lub umiejętności. Jeśli to możliwe, proszę wprowadzać jedną zmianę naraz, aby można było ustalić, co rzeczywiście rozwiązało problem. Podczas wdrażania należy przestrzegać zasad kontroli zmian i okien serwisowych, aby w jak najmniejszym stopniu zakłócić ruch produkcyjny.

Zweryfikować pełną funkcjonalność systemu i, jeśli to właściwe, wdrożyć środki zapobiegawcze. Należy potwierdzić nie tylko zniknięcie pierwotnego objawu, lecz także to, że nic innego nie przestało działać. Proszę poprosić użytkownika o wykonanie testu i ponownie sprawdzić powiązane usługi. Jeśli awarię spowodował uszkodzony kabel, można również oznaczyć jego przebieg albo wymienić zużyty kabel znajdujący się obok, aby zapobiec powtórzeniu problemu.

Udokumentować ustalenia, wykonane działania i wyniki. Należy zapisać objaw, przyczynę, podjęte działania oraz rezultat. Dobra dokumentacja przyspiesza obsługę kolejnego podobnego incydentu, wspiera dzielenie się wiedzą i tworzy ścieżkę audytu. Ten końcowy krok łatwo pominąć pod presją, ale to właśnie on zmienia jednorazową naprawę w trwałą wiedzę organizacji.

W ramach tej metody technicy często wybierają kierunek działania na podstawie modelu OSI. Podejście od dołu rozpoczyna się od warstwy fizycznej (kabli i łączy) i prowadzi w górę; jest przydatne, gdy podejrzewana jest całkowita awaria. Podejście od góry rozpoczyna się od aplikacji i prowadzi w dół; sprawdza się, gdy aplikacja działa nieprawidłowo, ale łączność wydaje się poprawna. Podejście dziel i zwyciężaj rozpoczyna się w środku, aby podzielić obszar problemu.

Należy uważać na nawyki, które łamią zasady tej metody: jednoczesne zmienianie kilku rzeczy, przez co nie można ustalić, co zadziałało, pomijanie weryfikacji lub zapominanie o dokumentacji. Proszę również unikać błędu potwierdzenia — skłonności do trzymania się teorii mimo dowodów, które jej zaprzeczają. To właśnie konsekwentne przestrzeganie każdego kroku, w odpowiedniej kolejności, sprawia, że metodyka jest niezawodna pod presją.

Sprawdź swoją wiedzę o tym procesie.

Dowiedział się Pan / Dowiedziała się Pani, na czym polega ustrukturyzowana metoda. Najważniejsze informacje:

• Siedem kroków: identyfikacja, tworzenie teorii, testowanie, planowanie, wdrażanie, weryfikacja i dokumentacja.
• Najpierw należy sprawdzać najprostsze i najbardziej prawdopodobne przyczyny.
• Przed naprawą trzeba potwierdzić przyczynę, a w razie potrzeby eskalować problem.
• Podejścia: od dołu, od góry oraz dziel i zwyciężaj.
• Zawsze należy przeprowadzać weryfikację i sporządzać dokumentację, nawet pod presją.