Techniki rozwiązywania problemów

Jakie są objawy problemu?

W przypadku opisywania problemu najistotniejszym pytaniem jest: Co stanowi problemem? To pytanie może wydawać się zbyt bezpośrednie; jednak można je podzielić na kilka bardziej konkretnych pytań, które utworzą bardziej opisowy obraz problemu. Mogą to być następujące pytania:

• Kto lub co zgłasza problem?
• Jakie są kody błędów i komunikaty?
• W jaki sposób objawia się nieprawidłowe działanie systemu? Na przykład czy jest to zapętlenie, zawieszenie, awaria, pogorszenie wydajności lub niepoprawne wyniki?

Gdzie problem występuje?

Określenie miejsca, w którym pojawił się problem, nie zawsze jest łatwe, ale stanowi jeden z najważniejszych kroków w procesie rozwiązywania problemu. Może istnieć wiele warstw technologii między komponentem zgłaszającym problem, a niepoprawnie działającym komponentem. Sieci, dyski i sterowniki to tylko niektóre z komponentów, które należy brać pod uwagę przy sprawdzaniu problemów.

Poniżej znajdują się pytania pomocne w znalezieniu miejsca wystąpienia problemu w celu wyizolowania warstwy problemu:

• Czy problem jest charakterystyczny dla jednego systemu operacyjnego, czy występuje w wielu systemach operacyjnych?
• Czy aktualne środowisko i bieżąca konfiguracja są obsługiwane?
• Czy problem dotyczy wszystkich użytkowników?
• (W przypadku instalacji w wielu ośrodkach). Czy problem dotyczy wszystkich ośrodków?

Jeśli jedna warstwa zgłasza problem, niekoniecznie musi ona być jego źródłem. Częścią procesu identyfikowania problemu jest zrozumienie środowiska, w którym on istnieje. Należy poświęcić trochę czasu na dokładny opis środowiska problemu, w tym systemów operacyjnych i ich wersji, odpowiedniego oprogramowania i jego wersji, oraz informacji na temat sprzętu. Należy sprawdzić, czy produkt działa w środowisku o obsługiwanej konfiguracji. Przyczyną wielu problemów jest niezgodność wersji oprogramowania, które nie są przeznaczone do wspólnej pracy lub nie zostały w pełni przetestowane ze sobą.

Kiedy problem występuje?

Należy przygotować szczegółową oś czasu zdarzeń prowadzących do awarii, z uwzględnieniem wystąpień jednorazowych. Najłatwiej to zrealizować, zaczynając od końca: rozpoczynając od momentu zgłoszenia błędu (z maksymalną możliwą dokładnością, nawet do milisekund), a następnie przechodząc wstecz poprzez dostępne dzienniki i informacje. Zwykle można użyć pierwszego podejrzanego zdarzenia, które można odnaleźć w dzienniku diagnostycznym.

Aby opracować szczegółową chronologię zdarzeń, należy odpowiedzieć na następujące pytania:

• Czy problem pojawia się tylko w określonej porze dnia lub nocy?
• Jak często problem występuje?
• Jaka sekwencja zdarzeń poprzedza moment zgłoszenia problemu?
• Czy problem pojawił się po wprowadzeniu zmiany w środowisku, takiej jak aktualizacja lub instalacja oprogramowania albo sprzętu?

Odpowiedzi na tego typu pytania pomagają opracować ramy czasowe dla analizy problemu.

W jakich warunkach problem występuje?

Istotną częścią procesu rozwiązywania problemu jest zgromadzenie wiedzy o systemach i aplikacjach, które działały w momencie wystąpienia problemu. Poniższe pytania dotyczące środowiska mogą pomóc w zidentyfikowaniu podstawowej przyczyny problemu:

• Czy problem występuje zawsze, gdy wykonywane jest dane zadanie?
• Czy do wystąpienia problemu niezbędne jest wystąpienie określonej sekwencji zdarzeń?
• Czy jednocześnie dochodzi do awarii innych aplikacji?

Udzielenie odpowiedzi na te pytania może ułatwić określenie środowiska, w jakim pojawia się problem, oraz skorelowanie wszelkich zależności. Należy jednak pamiętać, że w jednym czasie może występować wiele problemów, ale niekoniecznie muszą one być ze sobą powiązane.

Czy można odtworzyć problem?

Z punktu widzenia rozwiązywania problemów, idealny problem to taki, który można odtworzyć. Zwykle możliwość odtworzenia problemu udostępnia użytkownikom szerszą gamę narzędzi lub procedur ułatwiających badanie problemu. Problemy, które można odtworzyć, są często łatwiejsze do debugowania i rozwiązania.

Jednak problemy, które można odtworzyć, mają pewną wadę: jeśli problem ma duży wpływ na działalność przedsiębiorstwa, nie chcemy go powtórzyć. Jeśli jest to możliwe, należy odtworzyć problem w środowisku testowym lub programistycznym, które zwykle zapewnia większą elastyczność i daje lepszą kontrolę podczas badania.

• Czy problem można odtworzyć w systemie testowym?
• Czy ten sam typ problemu dotyka wielu użytkowników bądź aplikacji?
• Czy problem można odtworzyć, uruchamiając jedną komendę, zestaw komend lub konkretną aplikację?