Szkolenie Cisco TSHOOT – teoria i praktyka rozwiązywania
advertisement
Szkolenie Cisco TSHOOT – teoria i praktyka rozwiązywania problemów w sieciach W minionym roku w ofercie autoryzowanych szkoleń Cisco, realizowanych przez SOLIDEX pojawiło się szkolenie TSHOOT poświęcone zagadnieniom diagnozowania i rozwiązywania problemów w sieciach komputerowych. Po przeszło półrocznej obecności tego szkolenia w naszej ofercie postanowiłem podzielić się z czytelnikami Integratora moimi wrażeniami instruktora prowadzącego zajęcia z tego tematu. Czy troubleshooting to działania inżynierskie? Zawsze byłem gorącym zwolennikiem klasyfikowania pracy informatyków jako działalności inżynierskiej. Wiąże się z tym posiadanie odpowiedniej wiedzy, zastosowanie właściwych metod i narzędzi jak również w miarę możliwości ograniczanie nieskrępowanej „inwencji twórczej”. Możemy posłużyć się przykładem z architektury: urzeczywistnienie wizji architekta wymaga przemyślanych i rzetelnych działań inżynierskich. Zasad tych staram się również przestrzegać i stosować przy projektach i wdrożeniach sieci komputerowych. Czy jednak rozwiązywanie problemów w systemach komputerowych, w tym również w sieciach, można ująć w ramy działalności inżynierskiej? Na pierwszy rzut oka wydaje się to trudne. Przecież występowania problemów nie można „zaplanować” a ich rozwiązania „zaprojektować”. Przy rozwiązywaniu problemów liczy się przede wszystkim skuteczność i czas. W wielu przypadkach podejmujemy decyzje i działamy pod presją czasu. Przełożeni i użytkownicy oczekują szybkiego i skutecznego rozwiązania problemu. Mamy wrażenie, że przy rozwiązywaniu problemów liczy się przede wszystkim intuicja, łut szczęścia, a czasami również przypadek. Czy takie warunki diagnozowania problemów dają się pogodzić z zasadami uporządkowanej pracy inżynierskiej? A może istnieją metody pozwalające zmienić sposób pracy przy rozwiązywaniu problemów? Jeśli za wyznacznik klasyfikujący działania jako „inżynierskie” przyjmiemy ich uporządkowany, strukturalny charakter, to pomimo wielu cech towarzyszących rozwiązywaniu problemów, które utrudniają inżynierskie podejście do zagadnienia, nadal jest ono możliwe a nawet niezbędne. Troubleshooting a zarządzanie siecią Infrastruktura sieciowa jest żywym organizmem: realizowane funkcje dostosowywane są do potrzeb użytkowników oraz wymagań biznesowych, zmieniająca się dobowa aktywność wpływa na zmiany obciążenia łączy i urządzeń, zakres uprawnień użytkowników i ich działania wymagają nadzoru i monitoringu, występujące awarie i usterki wpływają na jakość i dostępność usług. W związku z tym dla zapewnienia sprawnego działania infrastruktury sieciowej niezbędne jest sprawowanie nad nią opieki. Prace z tym związane mogą mieć charakter doraźny i być sterowane zdarzeniami: jeśli coś nie działa jak należy, wówczas zastanawiamy się, co i jak należy zmienić. O ile dla niewielkich i prostych instalacji taki tryb prowadzenia zarządzania może dawać dobre rezultaty, to w przypadku bardziej złożonych struktur nieuchronnie prowadzić będzie do katastrofy: wszystkie wykonywane przez nas operacje będą miały charakter wyjątków, nie będziemy w stanie wyodrębnić i planować prac rutynowych. Wprowadzamy więc uporządkowane działania posiłkując się nierzadko metodologiami systematyzującymi zagadnienia zarządzania: czerpiemy wzory z modelu ITIL (IT Infrastructure Library), ISO FCAPS (Fault, Configuration, Accounting, Performance, Security), ITU-T TMN (Telecommunications Management Network), czy też z zaleceń producentów sprzętu jak również własnych doświadczeń. Dążymy do opracowania sprawnych procedur postępowania i jak najlepszego wykorzystania narzędzi pozwalających usprawnić naszą pracę. Efektem tych działań powinien być spójny i sprawnie działający schemat procesów, procedur i stosowanych narzędzi pokrywający wszystkie aspekty zarządzania siecią. Jaki ma to wpływ na rozwiązywanie problemów w sieci? Przede wszystkim dobrze zarządzana sieć posiada kompletną i aktualną dokumentację, do której możemy odwołać się w czasie rozwiązywania problemów. W szeroko pojmowanej dokumentacji powinniśmy znaleźć nie tylko informacje o strukturze sieci, schemacie adresacji czy zasadach działania routingu, ale również: -scenariusze i procedury testów potwierdzających prawidłowe działanie, -wskazówki dotyczące interpretacji typowych informacji diagnostycznych z urządzeń, -opis poprawnego i typowego zachowania się sieci (np. typowe obciążenie procesorów urządzeń czy wykorzystanie łączy), -informacje o aktualnych konfiguracjach urządzeń, zmianach i wprowadzanych modyfikacjach konfiguracji oraz przyczynach wprowadzenia tych zmian. Wszystkie te informacje pozwalają dużo sprawniej prowadzić diagnostykę problemów i wyciągać prawidłowe wnioski z dokonywanych obserwacji. Można zatem zaryzykować twierdzenie, że podstawą sprawnego rozwiązywania problemów jest prawidłowo prowadzone zarządzanie siecią. Systematyczne podejście do rozwiązywania problemów Czy zatem prawidłowe zarządzanie siecią oraz posiadanie aktualnej i szczegółowej dokumentacji jest gwarantem sprawnego rozwiązywania problemów? Wdrożenie procedur zarządzania siecią niestety nie daje automatycznie gwarancji usystematyzowanego podejścia do zagadnień troubleshootingu. Rozwiązywanie problemów wymaga zdefiniowania specyficznego schematu postępowania, odmiennego od procedur zarządzania siecią. Cisco w swoich materiałach szkoleniowych proponuje schemat oparty na przechodzeniu pomiędzy poszczególnymi fazami rozwiązywania problemu. W całym procesie wyróżnione zostały następujące fazy: Definicja problemu. Pozyskanie informacji. Analiza. Eliminacja. Stawianie hipotez. Weryfikacja hipotez. Rozwiązanie problemu. Na rysunku 1 przedstawiono graficznie relacje pomiędzy poszczególnymi fazami procesu diagnostyki i rozwiązywania problemu. Rys. 1. Fazy procesu diagnostyki i rozwiązywania problemu. Rozpoczęcie procesu diagnozowania wymaga prawidłowego zdefiniowania problemu. Ten krok jest szczególnie istotny w przypadku, gdy problem został zgłoszony przez użytkowników opisujących jego symptomy. Zdarza się, że przy zgłaszaniu problemu, użytkownicy stawiają nieuzasadnione hipotezy dotyczące przyczyn oraz błędnie interpretując obserwowane zjawiska mogą pomijać w opisie istotne fakty. Wszystko to wskazuje na konieczność zrewidowania przyjmowanego zgłoszenia w celu poprawnego zdefiniowania problemu. Z potrzebą redefiniowania problemu możemy spotkać się również w przypadku, gdy prowadzone prace diagnostyczne ujawnią nowe fakty i pozwolą doprecyzować czy wręcz zmienić pierwotną postać definicji problemu. Kolejnym krokiem w procesie diagnostycznym jest pozyskanie informacji pozwalających zrozumieć istotę problemu i prowadzić dalsze prace. Na tym etapie bardzo istotne jest opracowanie wstępnego planu działania, według którego będziemy pozyskiwać informacje. Plan działania musi uwzględniać zarówno charakter rozwiązywanego problemu, jego zakres, potencjalne przyczyny wystąpienia jak również możliwości pozyskania informacji. Należy wziąć pod uwagę dostępne narzędzia, możliwości ich wykorzystania, koszt i czasochłonność pozyskania informacji, jak też istotność i użyteczność informacji, które zamierzamy pozyskać. Na etapie analizy weryfikujemy pozyskane informacje wykorzystując do tego różnorakie środki: zestawiamy pozyskane dane z dokumentacją sieci, porównujemy z poprawnymi wzorcowymi danymi (tutaj widać istotną rolę posiadania wzorcowych przykładów danych z poprawnie pracującej sieci), wykorzystujemy naszą wiedzę i doświadczenie w celu oceny, które informacje są prawidłowe, a które wskazują na potencjalną przyczynę problemu. Etap eliminacji jest kluczowym etapem dla efektywnego procesu diagnostycznego. Na tym właśnie etapie podejmujemy decyzję o wykluczeniu potencjalnych przyczyn diagnozowanego problemu. Poprawne decyzje podejmowane na tym etapie pozwalają eliminować całe obszary potencjalnych przyczyn problemu wydatnie skracając czas niezbędny na diagnostykę i znalezienie rozwiązania. Należy zwrócić szczególną uwagę na skutki jakie mogą pociągać za sobą błędne decyzje: odrzucenie obszaru zagadnień, w którym faktycznie znajduje się przyczyna rozwiązywanego problemu, prowadzić może do wydłużenia prac diagnostycznych i weryfikowania wielu nietrafnych hipotez. Formułowanie hipotez to pierwszy z etapów opracowywania rozwiązania problemu. Na podstawie zebranych danych, ich analizy, jak również eliminacji potencjalnych przyczyn, typujemy najbardziej prawdopodobne przyczyny problemu. W bardziej złożonych przypadkach, zwłaszcza w warunkach ograniczonych możliwości wykonania rekonfiguracji środowiska produkcyjnego (np. wysokie koszty lub ograniczenia w dostępnym czasie serwisowym), możemy na tym etapie zdefiniować cząstkowe hipotezy, których weryfikacja pozwoli upewnić się co do słuszności podejrzeń o przyczynach danego problemu. Formułując cząstkowe hipotezy powinniśmy mieć na uwadze możliwości ich przetestowania oraz ocenę istotności dla formułowania ostatecznego rozwiązania problemu. Faza weryfikacji hipotez pozwala upewnić się o słuszności naszych podejrzeń co do przyczyn rozwiązywanego problemu. Zwykle testowanie hipotez wymaga wprowadzenia zmian w konfiguracji – należy pamiętać, że wprowadzane zmiany mogą mieć wpływ na pracę sieci. Wdrożenie zmian wymaga zatem odpowiedniego przygotowania: należy dobrze opisać proponowane zmiany, rozważyć ich wpływ na inne elementy konfiguracji, zaplanować testy weryfikujące poprawność działania sieci po wprowadzeniu zmian jak również opracować plan powrotu do pierwotnej konfiguracji w przypadku wystąpienia nieoczekiwanych i niemożliwych do szybkiego rozwiązania problemów po wprowadzeniu zmian. Ostatnim etapem troubleshootingu jest wdrożenie znalezionego rozwiązania problemu. Ponieważ w bardzo wielu przypadkach rozwiązanie polega na wdrożeniu zmian w konfiguracji sieci, nie można zapomnieć o odpowiednim udokumentowaniu wdrożonych zmian. Jeśli przyczyną problemu okazały się błędy lub niejednoznaczności w projekcie sieci, odpowiednich uzupełnień wymagać będzie również dokumentacja projektowa. Aspekty organizacyjne procesu troubleshootingu W wielu organizacjach zagadnienia administrowania siecią są realizowane w oddzielnych zespołach względem administrowania serwerami czy zarządzania aplikacjami. Nierzadko nawet w ramach zarządzania infrastrukturą sieciową występuje podział np. na zespoły odpowiedzialne za sieć WAN, sieci lokalne, systemy bezpieczeństwa, czy też węzły styku z Internetem. Praktyka troubleshootingu pokazuje, że w wielu przypadkach rozwiązanie problemu wymaga zaangażowania wielu osób, niekiedy wielu zespołów, odpowiedzialnych za różne elementy działania sieci i świadczonych w niej usług. Przykładem może być konieczność zaangażowania administratorów serwerów czy też osób odpowiedzialnych za systemy aplikacyjne do rozwiązywania problemów z wydajnością, czy też stabilnością pracy aplikacji. Przedstawiony strukturalny schemat rozwiązywania problemów znajduje swoje zastosowanie również w takim przypadku. Należy jedynie uwzględniać możliwość eskalacji problemu i angażowania dodatkowych zespołów oraz osób. Istotną rolę odgrywa w tym przypadku komunikacja pomiędzy zespołami i osobami pracującymi nad rozwiązaniem problemu. Zdarzają się problemy, których diagnozowanie i poszukiwanie przyczyn przeciąga się w czasie. Ze względu np. na ograniczenia możliwości testowania hipotez prace są zawieszane w pewnych okresach czasu. Powoduje to „oderwanie się” od rozwiązywanego problemu, a czasami występuje wręcz konieczność przekazania prowadzonych prac innym członkom zespołu. Nie zawsze proces rozwiązywania problemu przebiega optymalną ścieżką. Błędna interpretacja zebranych informacji, błędne hipotezy, czy też błędy na etapie eliminacji powodują konieczność powrotu do wcześniejszych etapów: zebrania dodatkowych informacji, ponownego przeanalizowania faktów, czy też zweryfikowania decyzji eliminacyjnych. Ponownej weryfikacji mogą wymagać również przeprowadzone testy hipotez, zwłaszcza jeśli na pewnym etapie rozwiązywania problemu dochodzimy do sprzecznych wniosków. Przy rozwiązywaniu problemów można skorzystać z doświadczeń i rezultatów prac związanych z diagnozowaniem wcześniejszych przypadków. W niektórych sytuacjach pozwala to w istotny sposób skrócić czas rozwiązywania problemu, gdy obserwowane symptomy są identyczne jak dla wcześniejszych przypadków: po zebraniu niezbędnych informacji można wówczas wprost wskazać hipotetyczną przyczynę nieprawidłowości omijając czasochłonne etapy analizy oraz eliminacji. We wszystkich wyżej przytoczonych sytuacjach bardzo istotną rolę odgrywa dokumentowanie prowadzonych prac diagnostycznych. Dokumentacja ułatwia przekazywanie sprawy kolejnym osobom jak również angażowanie nowych osób czy zespołów. Pozwala również na powtórne przeanalizowanie zebranych informacji i zweryfikowanie podjętych wcześniej na etapie eliminacji decyzji. Stanowi doskonałą bazę wiedzy uzupełniającą typową dokumentacje sieci. Tworzenie dokumentacji-historii prac diagnostycznych dla niektórych osób wydaje się na pierwszy rzut oka marnowaniem czasu, lecz w dłuższej perspektywie prowadzi do usprawnienia działania zespołu administratorów oraz udoskonalenia procesu diagnostycznego. Warunki ćwiczeń laboratoryjnych na szkoleniu TSHOOT W ramach szkolenia TSHOOT uczestnicy rozwiązują problemy sieciowe w zakresie technologii oraz elementów konfiguracji routerów i switchy Cisco omawianych na szkoleniach SWITCH oraz ROUTE. Znajomość technologii oraz umiejętność konfigurowania urządzeń Cisco w tym zakresie jest wymagana, gdyż czas i zakres szkolenia TSHOOT nie zakłada prowadzenia wykładów dotyczących tych zagadnień. Pewne elementy konfiguracji wykorzystywanych na szkoleniu TSHOOT wykraczają poza zakres szkoleń SWITCH i ROUTE – dotyczy to głównie zagadnień security. Uczestnicy szkolenia mają do dyspozycji środowisko laboratoryjne składające się z kilkunastu urządzeń. Strukturę sieci laboratoryjnej wykorzystywanej przez 3-4 osobową grupę przedstawia rysunek 2. Rys. 2. Struktura sieci laboratoryjnej szkolenia TSHOOT. Wykonywane ćwiczenia można podzielić na trzy grupy tematyczne obejmujące: problemy związane z sieciami LAN, problemy dotyczące routingu (EIGRP, OSPF, BGP), problemy bezpieczeństwa w sieci. W ramach każdej grupy tematycznej realizowane są dwa lub trzy ćwiczenia, z których każde zawiera od 3 do 5 zadań w postaci „zgłoszeń problemów” (trouble tickets). Diagnozowane problemy związane są z błędami konfiguracji – od uczestników oczekiwane jest nie tyle proste znalezienie błędu konfiguracyjnego, co przede wszystkim przeprowadzenie diagnostyki sieci pozwalającej na podstawie zbieranych informacji zidentyfikować i usunąć przyczyny problemów. Na zakończenie szkolenia przeprowadzane jest ćwiczenie podsumowujące, w którym rozwiązywane problemy dotyczą wszystkich omawianych wcześniej technologii. Współdziałanie w grupie Interesującym aspektem szkolenia jest praca w zespołach rozwiązujących problemy. Szkolenie przeprowadzane jest w grupie 6-12 osób dzielonych na dwa do czterech zespołów. Każdy z zespołów liczy 3-4 osoby i ma za zadanie zdiagnozować i rozwiązać problemy przedstawiane w poszczególnych ćwiczeniach. Ćwiczenia realizowane w poszczególnych zespołach są identyczne co daje możliwość porównania sposobu i efektów pracy poszczególnych zespołów. Na zakończenie ćwiczenia uczestnicy szkolenia z różnych grup mogą podzielić się doświadczeniami zebranymi w trakcie pracy. Organizacja pracy w zespole oddaje rzeczywiste warunki rozwiązywania problemów, gdzie zaangażowany jest cały zespół. W zależności od sposobu organizacji pracy zespołowej zaangażowanie kliku osób może pomagać lub utrudniać rozwiązanie problemów. Stosowane metody rozwiązywania problemów Uczestnicy szkolenia mają do dyspozycji dostęp terminalowy do portów konsoli poszczególnych urządzeń oraz mogą korzystać z testowych komputerów w środowisku laboratoryjnym. Pomiędzy urządzeniami możliwe jest również nawiązywanie zdalnych sesji terminalowych (telnet, ssh). W razie potrzeby istnieje możliwość użycia oprogramowania Wireshark do analizy pakietów przesyłanych w sieci laboratoryjnej. Ponadto dostęp do Internetu daje możliwość skorzystania z dokumentacji jak również innych zasobów informacji pozwalających znaleźć wyjaśnienie obserwowanych zjawisk. Najprostszą, aczkolwiek najmniej kształcącą metodą rozwiązywania problemów diagnozowanych w ramach szkolenia jest czytanie konfiguracji urządzeń i wychwycenie błędów w nich zawartych. Dużo ciekawszą metodą jest próba zebrania informacji oraz obserwowanie zachowania urządzeń i na tej podstawie przeprowadzenie wnioskowania odnośnie przyczyny problemów. Ponieważ diagnozowana sieć jest siecią laboratoryjną, uczestnicy szkolenia mają niemal nieograniczone możliwości testowania stawianych hipotez (nie ma możliwości dokonywania zmian topologii sieci). Na zakończenie każdego z ćwiczeń prezentowane jest podsumowanie, które zawiera nie tylko wskazanie, gdzie krył się błąd, ale podaje również metody diagnostyczne, których użycie pozwala zidentyfikować przyczyny problemów. Uczestnicy szkolenia mają możliwość w ramach takiego podsumowania podzielić się również własnymi spostrzeżeniami oraz uwagami odnośnie przeprowadzanego procesu diagnostycznego. Inżynier SOLIDEX H.M.
