Twoje zasady rozwiązywania problemów, podejście do rozwiązywania problemów? [Zamknięte]

Czy masz jakieś ogólne zasady, na których opierasz się podczas rozwiązywania trudnego problemu z siecią / sprzętem / oprogramowaniem?

Np .: „Izoluję źródło problemu, testując urządzenie peryferyjne za pomocą drugiego komputera” lub „Usuwam tyle sprzętu, ile jest możliwe, aby włączyć urządzenie, a następnie dodam komponenty jeden po drugim, aż będę mógł odtworzyć problem” itd.

Po prostu lista punktów, które zapisałem sobie po walce z jakimś problemem:

1. Jaki jest twój główny cel ? Należy wyraźnie i zwięźle stwierdzić. Cel powinien być bardzo konkretny. To nie powinno być ogólne. Najlepiej jedno zdanie .
   
2. Jaki masz problem ?
   
3. Czy jest tylko jeden problem czy wiele ? Jeśli jest ich wiele, rozwiąż je pojedynczo.
   
4. Spróbuj odtworzyć problem w różnych warunkach . Czy można go powielać we wszystkich możliwych warunkach, czy nie? Czy mówi coś o naturze problemu?
   
5. Jeśli jest to pilny problem, czy istnieje obejście ? Spróbuj znaleźć jak najwięcej obejść.
   
6. Postaraj się jak najwięcej zgadnąć, co jest przyczyną twojego problemu.
   
7. Spróbuj udowodnić swoje domysły, eksperymentuj z systemem.
   
8. Bądź konsekwentny w tym, co próbujesz zrobić. Rób jedną rzecz na raz.
   
9. Śledź to, co robisz, co już próbowałeś.
   
10. Nie odbiegaj od swojego głównego celu. Ciągle sprawdzaj, czy nadal rozwiązujesz główny problem, a nie inny.
    
11. Nie naprawiaj też.

Była też świetna lista reguł debugowania, w formacie PDF z przykładami i objaśnieniami do każdej z reguł. Nie mogłem szybko znaleźć pliku PDF, ale myślę, że to plakat z listy:

• Jeśli problem dotyczy Internetu, prawdopodobnie jest to DNS.

• Jeśli problem jest trudny do zdiagnozowania, prawdopodobnie jest to pamięć RAM.

• Jeśli problem dotyczy stacji roboczej z systemem Windows, prawdopodobnie najprościej jest go odtworzyć.

• Jeśli problem występuje w piątek, prawdopodobnie jest to coś poważnego.

Lubię wracać do metody naukowej .

From ( http://en.wikipedia.org/wiki/Scientific_method )

1. Zdefiniuj pytanie
2. Zbierz informacje i zasoby (obserwuj)
3. Forma hipotezy
4. Wykonaj eksperyment i zbierz dane
5. Analizować dane
6. Interpretuj dane i wyciągaj wnioski, które stanowią punkt wyjścia do nowej hipotezy
7. Wyniki dokumentu

Zasadniczo zawsze lubię próbować dokładnie sprawdzać moje podstawowe założenia. Czy ma zasilanie, czy jest podłączony, czy okablowanie jest dobre. Bardzo denerwujące jest spędzanie godzin na próbach rozwiązania problemu z oprogramowaniem, gdy masz luźny kabel.

Uważam, że bardzo ważne jest, aby w fazie tworzenia hipotezy wymyślić jak najwięcej możliwych przyczyn problemu. Następnie próbuję najpierw wybrać pomysły do ​​przetestowania na podstawie tego, jak łatwo jest przetestować i jak prawdopodobny jest pomysł.

Ważne jest również, aby uzyskać pomoc. Skonsultuj się ze współpracownikami, sprzedawcą lub kimkolwiek, kto ma najlepszą wiedzę na temat danych systemów, jeśli możesz. Nie marnuj dużo czasu na przekręcanie kół na problem, jeśli jest ktoś, kto może pomóc Ci rozwiązać problem.

O'Reilly ma dobrą książkę Narzędzia do rozwiązywania problemów z siecią, która zawiera dobry zestaw kroków do naśladowania, bardzo podobny do metody naukowej. Uważam tę książkę za bardzo przydatną i zdecydowanie ją polecam. Książka zawiera dużo więcej szczegółów i sugeruje wiele przydatnych narzędzi.

Z narzędzi do rozwiązywania problemów sieciowych

1. Podaj swój cel
2. Zdefiniuj system
3. Zidentyfikuj możliwe wyniki
4. Zidentyfikuj i wybierz, co będziesz mierzyć
5. W razie potrzeby określ parametry testowe i czynniki
6. Wybierz narzędzia
7. Ustal ograniczenia pomiarowe
8. Przejrzyj projekt eksperymentalny
9. Zbieraj dane
10. Analizować dane

Zobacz też:

• 3COM ma przewodnik rozwiązywania problemów
• Prawo Murphy'ego - robi wszystko, co może pójść nie tak.
• Occam's_razor - Wszystkie inne rzeczy są równe, najprostsze rozwiązanie jest najlepsze.

(Te najważniejsze informacje zostały sparafrazowane z rozdziału „Debugowanie” w „Praktyce administracji systemem i siecią” )

Dwie rzeczy, które należy wiedzieć:

1. Dowiedz się, jak wygląda wersja „stała”. Najlepiej polecenie, które można uruchomić, które daje określone wyjście, gdy coś działa. Na przykład: próbuję dowiedzieć się, dlaczego SSH prosi o hasło, gdy poprawnie skonfigurowałem klucze (a przynajmniej tak mi się wydawało). Więc mój test brzmi: „ssh servername uptime” i powinien działać bez pytania o hasło.

2. Opisz problem na odpowiednim poziomie. Użytkownik narzekający, że nie może pingować serwera, nie powinien odsyłać Cię do uruchomienia i naprawy serwera. Zadaniem tej osoby nie jest siedzenie i pingowanie komputera przez cały dzień. Chcą wykonać jakieś zadanie, takie jak używanie maszyny jako serwera DNS. Przykład: gdy użytkownik skarżył się, że nie może pingować komputera w połowie świata. Spędzam dzień, szukając sysadminów w tej części firmy, aby dowiedzieć się, co było nie tak z tą maszyną. Został wycofany ze służby i wpadli w panikę, ponieważ myśleli, że może wyłączyli niewłaściwą maszynę. Skontaktowałem się z użytkownikiem i powiedziałem „poza tym, że musisz pingować ten komputer, co chciałbyś z tym zrobić?”. Okazało się, że chciał uruchomić na nim określoną pracę i gdyby postępował zgodnie z właściwą procedurą, jego zadania zostałyby automatycznie przekierowane na maszynę zastępczą. Zmarnowałem cały dzień i czas lokalnych administratorów. Innym powodem, dla którego „nie mogę pingować”, jest niewłaściwe do testowania: często zapory ogniowe są skonfigurowane do odrzucania pakietów ping, ale umożliwiają przepuszczanie innych pakietów. Sprawdź, przez co chcesz przejść.

Dwie strategie:

1. Dodatek: dodawaj składniki do momentu pojawienia się problemu. Ostatnią rzeczą, którą dodałeś, jest problem. Przykład: przeglądarki internetowe nie mogą komunikować się z serwerem. Pomiędzy serwerem a użytkownikiem znajduje się moduł równoważenia obciążenia, zapora ogniowa, pamięć podręczna i lokalny internetowy serwer proxy użytkownika. Najpierw spróbuj wysłać zapytania bezpośrednio do serwera, następnie przez LB do serwera, a następnie przez zaporę ogniową do LB do serwera itp. Za każdym razem dodając jeden komponent.

2. Subtraktywne: Kontynuuj usuwanie komponentów, aż problem zniknie. Ostatnią rzeczą, którą usunąłeś, był problem: Przykład: Maszyna z dziesiątkami kart nie uruchamia się. Wyjmuj karty, dopóki urządzenie się nie uruchomi.

Dwa kawałki głupiego szczęścia:

1. Zapomnij o wszystkim, co powiedziałem. Problem jest spowodowany ostatnią zmianą dokonaną w systemie. (działa to w 99% przypadków ... problem polega na tym, że w 99% nie wiesz, jaka była ostatnia zmiana)

2. Kiedy wszystko inne zawiedzie, poszukaj głupich rzeczy. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Przykład: Szalonego problemu nie można było wyjaśnić. Następnie sprawdziliśmy plik konfiguracyjny: użytkownik edytował go, kopiując go do okna systemu Windows, edytując go, a następnie kopiując z powrotem. Teraz miał ^ M na końcu każdej linii. Nigdy tego nie zauważyliśmy, ponieważ nasz edytor tekstu po cichu ukrył ten fakt. Niestety, oprogramowanie odczytujące plik konfiguracyjny zamieniło te ^ M w przestrzeń non-break, która zepsuła mnóstwo innych procedur.

Ogólne praktyki, które pamiętam podczas całego procesu:

1. Napisz wszystko, co robię w dół.
2. Wprowadź tylko jedną zmianę na raz.
3. Jeśli to możliwe, cofnij zmianę przed wypróbowaniem innej, chyba że poczyniono zdecydowane postępy.

Podczas rozwiązywania problemów tutaj określa moją podstawową metodologię:

• Kiedy system działa prawidłowo, zanim pojawi się problem, staram się nauczyć, co robi. Joe Richards wyjaśnia, dlaczego o wiele lepiej niż ja w tej krótkiej przestrzeni .
• Zaczynam od najprostszego rozwiązania. Na przykład brak łączności sieciowej? Sprawdź warstwę fizyczną. Nie mogę powiedzieć, ile razy sporadyczne problemy z połączeniem nie były problemem z serwerem, ale kablem sieciowym, który był w połowie lub zepsuty.
• Próbuję uchwycić wszystkie symptomy, które widzę ze wszystkich prawdopodobnych źródeł, zanim zacznę wprowadzać zmiany.
• Przeprowadzam wstępne testy diagnostyczne. Na przykład, kiedy dostaję komunikat, że serwer jest wyłączony, pierwszą rzeczą, którą robię, jest sprawdzenie ping za pomocą ping i nbtstat (Windows). Problemem może być odległy koniec (pożyczyć stare powiedzenie kontroli technicznej Sił Powietrznych).
• Nie boję się robić badań. Google, support.microsoft.com, eventid.net i podobne strony to twój przyjaciel.
• Nie boję się prosić społeczności o pomoc. Nie tylko strony takie jak serverfault.com, ale mam duży wybór osób, którym ufam i szanuję na Twitterze, z którymi utrzymuję kontakt.
• Oceniam odpowiedzi, które znajduję, na podstawie tego, co widzę. Nie zakładam, że którekolwiek rozwiązanie jest właściwe, dopóki nie będę w stanie wystarczająco przeanalizować dowodów, które widzę na podstawie tego, co zostało zgłoszone w rozwiązaniu.

Postawy, które staram się utrzymać:

• Absolutna pewność, że przyczyna i skutek działają i nic nie jest magią. Nie dzieje się nic dziwnego, tylko rzeczy, których nie rozumiem.
• Absolutna pewność, że jeśli będę ją dalej naciskać, to ją rozwiążę (może to obejmować przekazanie jej komuś bardziej kompetentnemu, uczenie się, proszenie o pomoc, ciężką pracę itp.).
• Narzekanie na to, że konfiguracja, program lub scenariusz jest źle zaprojektowany lub naprawdę głupi, po prostu nie pomaga, więc nie rób tego. (Uważam to za trudne, narzekanie jest zabawne).

Są to postawy, które pomagają mi utrzymać - powstrzymują mnie od wyrzucania rąk w powietrze, ogłaszania czegoś „dziwnego”, a następnie poddawania się lub odczuwania nieszczęścia, ponieważ wydaje się to „nierozwiązywalne”.

Sposoby myślenia o rozwiązywaniu problemów:

• Systemy składają się z wielu części, jeśli są ze sobą połączone lub skonfigurowane losowo, nie będą działać zgodnie z oczekiwaniami. Istnieje jedna lub dwie bardzo specyficzne konfiguracje, które będą działać - spośród wszystkich milionów sposobów układania cegieł i metalu, tylko kilka jest mostami, a tylko jedna lub dwie są wystarczająco dobrymi mostami. Przyczyną może być znak w pliku tekstowym lub uszkodzony serwer, ale każda część musi być odpowiednia, aby wszystko działało poprawnie. W razie potrzeby muszę być dokładny i skrupulatny. Systemy nie mogą zrobić „show musi trwać”.
• Zaczynasz z całym systemem, takim jak mapa, wyobrażasz sobie chmurę prawdopodobieństwa unoszącą się nad mapą, reprezentującą „gdzie jest problem”, a Twoim zadaniem jest wykorzystanie doświadczenia i znalezienie testów, aby odepchnąć prawdopodobieństwo od niektórych obszarów w kierunku innych i aby skondensować go do punktów, w których występują problemy z dużym prawdopodobieństwem, a następnie zaatakować je. Wraca to do przyczyny i skutku - problem tkwi w systemie, to nie jest magia. Jest to problem, który istnieje, więc musi gdzieś istnieć.
• Wszystko można skonfigurować w dowolny sposób. Jedynym sposobem, w jaki możemy zdefiniować jedno zachowanie jako „OK”, a drugie jako „problem”, jest to, że ktoś dostaje to, czego nie chce. Musisz zrozumieć, czego chcą, co otrzymują w sposób jasny i konkretny.

Proces rozwiązywania problemów:

• Jaki jest problem. Upewnij się, że to się dzieje i możesz to samodzielnie odtworzyć, aby nie doszło do nieporozumień. Tak często problemy napotykały wiele osób w naszym centrum pomocy, zanim do mnie dotarły, ale nikt nie jest w stanie wyjaśnić mi, na czym tak naprawdę polega problem.
• To jest rekurencyjna bisekcja od nowa - dziel i zwyciężaj, wyszukiwanie binarne - wymyślisz test, który udowodni, czy problemem jest ta strona testu, czy ta strona, i sprawisz, aby test wyeliminował w jak największym stopniu. Powtarzaj aż do rozwiązania.
• Nie ucz się, czy możesz tego uniknąć - lepiej zablokować konto bazy danych i udowodnić, że problem nadal występuje, gdy baza danych nie jest zaangażowana, niż spędzać godziny na nauce korzystania z bazy danych.
• Zbyt łatwo jest mi myśleć „nie wiem, co robić dalej”. Zauważ, kiedy to nastąpi, i wróć do wymyślania testów, które zlokalizują problem.

Internet nie działa? Sprawdź problem, znajdź witrynę, do której nie mogą się dostać. Szybkie testy obejmują ich połączenie internetowe (działa), czy to dla mnie ładuje (nie). Szybkie testy wskazują, że jest to witryna. Widząc, że problem mi się zdarza, szybko odsunąłem prawdopodobieństwo od komputera, przeglądarki, DNS, zapory biurowej konta użytkownika itp.

Więc strona się nie ładuje, co teraz? Tego jeszcze nie da się naprawić, więc poszukaj miejsc, w których możesz wyrzeźbić problem na mniejszy. Czy serwer jest włączony? Czy to ping? działa DNS? Tak. Czy usługa odpowiada na porcie 80? Nie. Czy usługa jest uruchomiona? Nie. Czy to się zaczyna? Nie. Czy wyświetla błędy w dzienniku zdarzeń / plikach dziennika? Tak! Co oni mówią?

Jest to wydajne i szybkie rozwiązywanie problemów, ponieważ nieustannie koncentruje się na zawężeniu zakresu problemu. Gdybym zaakceptował ich raport, że Internet nie działa, zostałbym wprowadzony w błąd, sądząc, że to błąd połączenia. Gdybym zaakceptował moje pierwsze stwierdzenie, że nie ładuje się dla nich, traciłbym czas na komputerze, sądząc, że to wina.

Wytnij fragmenty „rzeczy, których nie może być”, tak duże, jak to możliwe.

Zrozum system. Im bardziej ogólna wiedza na temat systemu, tym łatwiej. Tam, gdzie mam słabe zrozumienie, problemy są bardziej zastraszające, trudniejsze, wolniejsze i bardziej prawdopodobne jest, że skończą się obejście niż poprawka lub z dużym głupim powolnym naprawieniem (ponowna instalacja) niż mała, precyzyjna poprawka chirurgiczna.

Ogólnie pytam: „Co się zmieniło, co mogło spowodować ten problem”? Większość problemów jest spowodowana zmianami w znanych dobrych konfiguracjach. Jeśli potrafisz ustalić, kto dokonał zmiany, zazwyczaj otrzymasz odpowiedź.

Myślę, że to umiejętność, a nie nauka. Są chwile, kiedy idziesz niewłaściwą ścieżką, ale w większości:

• Dobra znajomość wszystkich powiązanych technologii - sieci, sprzętu, systemu operacyjnego, oprogramowania, rozwoju itp. - pomoże Ci wyeliminować niektóre z tych „złych ścieżek”
• myśl podstawowy - nie przeskakuj do najbardziej skomplikowanego scenariusza, ponieważ jest on w twojej głowie, wykonaj podstawowe rozwiązywanie problemów i pozwól, aby Cię poprowadził.

Kiedyś mój szef zadzwonił do mnie z „starszym” inżynierem przez telefon - mówił mi, że ma jeden serwer, który nie może się połączyć i próbował zmienić kabel, ale nadal nie miał radości. W tle słyszałem dźwięk przypominający UPS na akumulatorach. Zapytałem go, czy widzi aktywność na przełączniku, powiedział „nie”. Zapytałem go, czy sygnał dźwiękowy pochodzi z UPS, odpowiedział, że tak, zapytałem, czy w ogóle może zobaczyć jakieś światła na stojaku, który powiedział nie ... Spójrz poza nos - to pomaga!

Zaczynam od sprawdzenia rzeczy oczywistych. Czy pojawia się komunikat o błędzie wyjaśniający, na czym polega problem? Czy wszystko jest prawidłowo podłączone? Nie lubię marnować kilku godzin na rozwiązywanie problemów, które mogłyby zostać rozwiązane w ciągu kilku minut. Myślę, że można być zbyt metodycznym. Widziałem, jak ludzie marnują cały dzień na odtwarzanie problemu, mimo że powiedziałem im dokładnie, na czym polega problem. Nie za to im płacę.

Jeśli odpowiedź nie jest oczywista, ustaw w szeregu podejrzanych i przetestuj ich w pierwszej kolejności. Dopiero po przetestowaniu prawdopodobnych podejrzanych powinieneś przetestować podejrzanych podejrzanych. Możesz być tak naukowy, jak chcesz.