Ten artykuł jest pierwszym z serii artykułów „Jak przejąć kontrolę nad infrastrukturą sieciową”. Można znaleźć treść wszystkich artykułów z serii oraz linki .
W pełni przyznaję, że jest wystarczająca liczba firm, w których godzinny lub nawet jeden dzień przestoju sieci nie jest krytyczny. Niestety lub stety nie miałam okazji pracować w takich miejscach. Ale oczywiście sieci są różne, wymagania są różne, podejścia są różne, a jednak w takiej czy innej formie poniższa lista w wielu przypadkach będzie w rzeczywistości „obowiązkowa”.
A więc warunki początkowe.
Jesteś w nowej pracy, dostałeś awans lub postanowiłeś na nowo spojrzeć na swoje obowiązki. Sieć firmowa to Twój obszar odpowiedzialności. Dla Ciebie jest to pod wieloma względami wyzwanie i nowe, co poniekąd uzasadnia mentorski ton tego artykułu :). Mam jednak nadzieję, że artykuł będzie przydatny także dla każdego inżyniera sieciowego.
Twoim pierwszym celem strategicznym jest nauczenie się przeciwstawiania się entropii i utrzymywanie poziomu świadczonych usług.
Wiele z opisanych poniżej problemów można rozwiązać na różne sposoby. Celowo nie poruszam tematu realizacji technicznej, bo... w zasadzie często nie jest tak ważne, jak rozwiązałeś ten czy inny problem, ale ważne jest, jak z niego korzystasz i czy w ogóle go używasz. Na przykład Twój profesjonalnie zbudowany system monitorowania na niewiele się zda, jeśli nie będziesz na niego patrzeć i nie reagować na alerty.
Sprzęt
Najpierw musisz zrozumieć, gdzie występuje największe ryzyko.
Powtórzę: może być inaczej. Przyznam, że gdzieś będą to na przykład kwestie bezpieczeństwa, a gdzieś kwestie związane z ciągłością usługi, a gdzieś może coś innego. Dlaczego nie?
Załóżmy dla jasności, że jest to nadal ciągłość świadczenia usług (tak było we wszystkich firmach, w których pracowałem).
Następnie musisz zacząć od sprzętu. Oto lista tematów, na które warto zwrócić uwagę:
- klasyfikacja sprzętu według stopnia krytyczności
- tworzenie kopii zapasowych krytycznego sprzętu
- wsparcie, licencje
Należy przemyśleć możliwe scenariusze awarii, szczególnie w przypadku sprzętu znajdującego się na szczycie klasyfikacji krytyczności. Zwykle pomija się możliwość wystąpienia podwójnych problemów, w przeciwnym razie rozwiązanie i wsparcie mogą stać się nieracjonalnie drogie, ale w przypadku naprawdę krytycznych elementów sieci, których awaria może znacząco wpłynąć na biznes, należy się nad tym zastanowić.
Przykład
Załóżmy, że mówimy o przełączniku głównym w centrum danych.
Ponieważ zgodziliśmy się, że najważniejszym kryterium jest ciągłość usług, zasadne jest zapewnienie „gorącego” zasilania rezerwowego (redundancji) tego sprzętu. Ale to nie wszystko. Musisz także zdecydować, jak długo, w przypadku zepsucia się pierwszego wyłącznika, akceptowalne jest życie z tylko jednym pozostałym wyłącznikiem, ponieważ istnieje ryzyko, że i on się zepsuje.
Ważny! Nie musisz sam decydować o tej kwestii. Należy opisać ryzyko, możliwe rozwiązania i koszty kierownictwu lub kierownictwu firmy. Muszą podejmować decyzje.
Jeśli więc uznano, że przy małym prawdopodobieństwie podwójnej awarii, praca przez 4 godziny na jednym wyłączniku jest w zasadzie akceptowalna, to można po prostu sięgnąć po odpowiednie wsparcie (wg którego sprzęt zostanie wymieniony w ciągu 4 godziny).
Istnieje jednak ryzyko, że nie zostaną dostarczone. Niestety, kiedyś znaleźliśmy się w takiej sytuacji. Zamiast czterech godzin sprzęt jechał tydzień!!!
Dlatego to ryzyko również należy omówić i być może bardziej słuszne będzie zakup innego przełącznika (trzeciego) i przechowywanie go w pakiecie części zamiennych („zimna” kopia zapasowa) lub wykorzystanie go do celów laboratoryjnych.
Ważny! Zrób arkusz kalkulacyjny zawierający wszystkie posiadane wsparcie wraz z datami wygaśnięcia i dodaj go do swojego kalendarza, aby z co najmniej miesięcznym wyprzedzeniem otrzymać wiadomość e-mail z informacją, że powinieneś zacząć się martwić o odnowienie wsparcia.
Nie zostanie Ci wybaczone, jeśli zapomnisz odnowić wsparcie, a następnego dnia po jego zakończeniu nastąpi awaria sprzętu.
Praca awaryjna
Cokolwiek dzieje się w Twojej sieci, najlepiej jest zachować dostęp do sprzętu sieciowego.
Ważny! Musisz mieć dostęp konsolowy do całego sprzętu, a dostęp ten nie powinien zależeć od stanu sieci danych użytkownika.
Należy także z wyprzedzeniem przewidzieć możliwe negatywne scenariusze i udokumentować niezbędne działania. Dostępność tego dokumentu jest również krytyczna, dlatego należy go nie tylko opublikować w zasobach współdzielonych dla działu, ale także zapisać lokalnie na komputerach inżynierów.
Musi być
- informacje wymagane do otwarcia zgłoszenia przy wsparciu dostawcy lub integratora
- informacje jak dostać się do dowolnego sprzętu (konsola, zarządzanie)
Oczywiście może zawierać również inne przydatne informacje, na przykład opis procedury aktualizacji dla różnych urządzeń i przydatne polecenia diagnostyczne.
Partnerzy
Teraz musisz ocenić ryzyko związane z partnerami. Zwykle to
- Dostawcy Internetu i punkty wymiany ruchu (IX)
- dostawców kanałów komunikacyjnych
Jakie pytania warto sobie zadać? Podobnie jak w przypadku sprzętu, należy wziąć pod uwagę różne scenariusze awaryjne. Na przykład w przypadku dostawców Internetu może to wyglądać następująco:
- co się stanie, jeśli dostawca Internetu X z jakiegoś powodu przestanie świadczyć Ci usługi?
- Czy inni dostawcy będą mieli dla Ciebie wystarczającą przepustowość?
- Jak dobra pozostanie łączność?
- Jak niezależni są Twoi dostawcy Internetu i czy poważna awaria jednego z nich spowoduje problemy u pozostałych?
- ile wejść optycznych znajduje się w Twoim centrum danych?
- co się stanie, jeśli jedno z wejść zostanie całkowicie zniszczone?
Jeśli chodzi o dane wejściowe, w mojej praktyce w dwóch różnych firmach, w dwóch różnych centrach danych, koparka zniszczyła studnie i tylko cudem nie miało to wpływu na naszą optykę. To nie jest taki rzadki przypadek.
I oczywiście musisz nie tylko zadać te pytania, ale ponownie, przy wsparciu kierownictwa, zapewnić akceptowalne rozwiązanie w każdej sytuacji.
utworzyć kopię zapasową
Kolejnym priorytetem może być kopia zapasowa konfiguracji sprzętu. W każdym razie jest to bardzo ważny punkt. Nie będę wymieniał przypadków, w których można stracić konfigurację, lepiej regularnie robić kopie zapasowe i nie myśleć o tym. Ponadto regularne kopie zapasowe mogą być bardzo przydatne w monitorowaniu zmian.
Ważny! Codziennie twórz kopie zapasowe. Nie jest to aż tak duża ilość danych, aby na tym zaoszczędzić. Rano dyżurny inżynier (lub Ty) powinien otrzymać raport z systemu, który jasno wskazuje, czy tworzenie kopii zapasowej się powiodło, czy nie, a jeśli tworzenie kopii zapasowej się nie powiodło, należy rozwiązać problem lub wystawić zgłoszenie ( zobacz procesy działu sieci).
Wersje oprogramowania
Kwestia, czy warto aktualizować oprogramowanie sprzętu, nie jest już tak jednoznaczna. Z jednej strony stare wersje to znane błędy i luki, ale z drugiej strony nowe oprogramowanie to po pierwsze nie zawsze bezbolesna procedura aktualizacji, a po drugie, nowe błędy i luki.
Tutaj musisz znaleźć najlepszą opcję. Kilka oczywistych zaleceń
- instaluj tylko wersje stabilne
- Mimo to nie powinieneś żyć na bardzo starych wersjach oprogramowania
- zrób znak z informacją o tym, gdzie znajduje się jakieś oprogramowanie
- okresowo czytaj raporty o podatnościach i błędach w wersjach oprogramowania, a w przypadku krytycznych problemów powinieneś pomyśleć o aktualizacji
Na tym etapie mając konsolowy dostęp do sprzętu, informacje o wsparciu oraz opis procedury aktualizacji, jesteś w zasadzie gotowy na ten krok. Idealną opcją jest posiadanie sprzętu laboratoryjnego, w którym można sprawdzić całą procedurę, jednak niestety nie zdarza się to często.
W przypadku sprzętu krytycznego możesz skontaktować się z pomocą techniczną dostawcy z prośbą o pomoc w modernizacji.
System biletowy
Teraz możesz się rozejrzeć. Należy ustanowić procesy interakcji z innymi działami i wewnątrz działu.
Być może nie będzie to konieczne (jeśli np. Twoja firma jest mała), jednak gorąco polecam zorganizowanie pracy w taki sposób, aby wszystkie zadania zewnętrzne i wewnętrzne przechodziły przez system zgłoszeń.
System zgłoszeń jest zasadniczo interfejsem do komunikacji wewnętrznej i zewnętrznej i należy go opisać wystarczająco szczegółowo.
Weźmy przykład ważnego i powszechnego zadania otwierania dostępu. Opiszę algorytm, który sprawdził się doskonale w jednej z firm.
Przykład
Zacznijmy od tego, że często dostępni klienci formułują swoje pragnienia w języku niezrozumiałym dla inżyniera sieci, a mianowicie w języku aplikacji, na przykład „daj mi dostęp do 1C”.
Dlatego nigdy nie przyjmowaliśmy próśb bezpośrednio od takich użytkowników.
I to był pierwszy wymóg
- prośby o dostęp powinny pochodzić z działów technicznych (w naszym przypadku byli to inżynierowie ds. systemów UNIX, Windows, Helpdesk)
Drugi wymóg jest taki
- dostęp ten musi zostać zarejestrowany (przez dział techniczny, od którego otrzymaliśmy to żądanie) i jako żądanie otrzymujemy link do tego zalogowanego dostępu
Forma tego żądania musi być dla nas zrozumiała, tj.
- żądanie musi zawierać informację o tym, która podsieć i do jakiej podsieci ma być otwarty dostęp, a także protokół i (w przypadku tcp/udp) porty
Tam też należy to zaznaczyć
- opis powodu otwarcia tego dostępu
- tymczasowe lub stałe (jeśli tymczasowe, do jakiej daty)
Bardzo ważnym punktem są zatwierdzenia
- od kierownika działu, który zainicjował dostęp (np. księgowość)
- od kierownika działu technicznego, skąd to żądanie trafiło do działu sieci (np. helpdesk)
W tym przypadku za „właściciela” tego dostępu uważa się kierownika działu, który zainicjował dostęp (w naszym przykładzie księgowość) i to on odpowiada za to, aby strona z zalogowanym dostępem dla tego działu była aktualna .
Logowanie
To jest coś, w czym można się utopić. Jeśli jednak chcesz wdrożyć podejście proaktywne, musisz nauczyć się radzić sobie z zalewem danych.
Oto kilka praktycznych zaleceń:
- musisz codziennie przeglądać logi
- w przypadku przeglądu planowanego (a nie sytuacji awaryjnej) możesz ograniczyć się do poziomów ważności 0, 1, 2 i dodać wybrane wzorce z pozostałych poziomów, jeśli uznasz to za konieczne
- napisz skrypt, który analizuje logi i ignoruje te logi, których wzorce dodałeś do listy ignorowanych
Takie podejście pozwoli Ci z czasem utworzyć listę ignorowanych dzienników, które Cię nie interesują i pozostawić tylko te, które naprawdę uważasz za ważne.
U nas zadziałało świetnie.
Monitorowanie
Nierzadko zdarza się, że w firmie brakuje systemu monitorowania. Można na przykład polegać na logach, ale sprzęt może po prostu „umrzeć” i nie mieć czasu na „powiedzenie” czegokolwiek lub pakiet protokołu udp syslog może zostać utracony i nie dotrzeć. Ogólnie rzecz biorąc, aktywne monitorowanie jest oczywiście ważne i konieczne.
Dwa najpopularniejsze przykłady w mojej praktyce:
- monitorowanie obciążenia kanałów komunikacji, łączy krytycznych (na przykład łączenie się z dostawcami). Pozwalają proaktywnie dostrzec potencjalny problem degradacji usług na skutek utraty ruchu i odpowiednio go uniknąć.
- wykresy oparte na NetFlow. Ułatwiają znalezienie anomalii w ruchu i są bardzo przydatne do wykrywania prostych, ale znaczących rodzajów ataków hakerskich.
Ważny! Skonfiguruj powiadomienia SMS o najważniejszych zdarzeniach. Dotyczy to zarówno monitorowania, jak i rejestrowania. Jeśli nie masz dyżuru, sms powinien dotrzeć także poza godzinami pracy.
Przemyśl proces tak, aby nie obudzić wszystkich inżynierów. Mieliśmy do tego inżyniera.
Zmień kontrolę
Moim zdaniem nie trzeba kontrolować wszystkich zmian. Ale w każdym razie powinieneś być w stanie, jeśli to konieczne, łatwo dowiedzieć się, kto dokonał określonych zmian w sieci i dlaczego.
Kilka porad:
- użyj systemu zgłoszeń, aby szczegółowo opisać, co zostało zrobione na tym zgłoszeniu, na przykład kopiując zastosowaną konfigurację do zgłoszenia
- użyj możliwości komentowania sprzętu sieciowego (na przykład zatwierdź komentarz w Juniper). Możesz zapisać numer biletu
- użyj diff kopii zapasowych konfiguracji
Możesz wdrożyć to jako proces, codziennie przeglądając wszystkie zgłoszenia pod kątem zmian.
Procesy
Musisz sformalizować i opisać procesy zachodzące w Twoim zespole. Jeśli dotarłeś do tego punktu, Twój zespół powinien już mieć uruchomione co najmniej następujące procesy:
Codzienne procesy:
- praca z biletami
- praca z logami
- zmienić kontrolę
- dzienny arkusz kontrolny
Procesy roczne:
- przedłużenie gwarancji, licencji
Procesy asynchroniczne:
- reagowania na różne sytuacje awaryjne
Zakończenie pierwszej części
Czy zauważyłeś, że to wszystko nie dotyczy jeszcze konfiguracji sieci, nie projektowania, nie protokołów sieciowych, nie routingu, nie bezpieczeństwa... To coś około. Ale te, choć być może nudne, są oczywiście bardzo ważnymi elementami pracy działu sieciowego.
Jak dotąd, jak widać, nie poprawiłeś niczego w swojej sieci. Jeśli istniały luki w zabezpieczeniach, pozostały; jeśli był zły projekt, pozostały. Dopóki nie zastosujesz swoich umiejętności i wiedzy jako inżynier sieci, na co najprawdopodobniej poświęciłeś dużo czasu, wysiłku, a czasem i pieniędzy. Ale najpierw musisz stworzyć (lub wzmocnić) fundament, a następnie rozpocząć budowę.
W poniższych częściach dowiesz się, jak znaleźć i wyeliminować błędy, a następnie ulepszyć swoją infrastrukturę.
Oczywiście nie musisz robić wszystkiego po kolei. Czas może być krytyczny. Zrób to równolegle, jeśli pozwalają na to zasoby.
I ważny dodatek. Komunikuj się, pytaj, konsultuj się ze swoim zespołem. W końcu to oni to wszystko wspierają i robią.
Źródło: www.habr.com