Ten artykuł jest pierwszym w cyklu artykułów „Jak przejąć kontrolę nad infrastrukturą sieciową”. Spis treści wszystkich artykułów cyklu i linki można znaleźć .
Zgadzam się, że istnieje wystarczająca liczba firm, w których prostą sieć można zignorować przez godzinę lub nawet przez jeden dzień. Niestety, bądź na szczęście, nie miałem okazji pracować w takich miejscach. Niemniej jednak sieci są różne, wymagania różne, podejścia różne, i w każdym razie poniższa lista w wielu przypadkach będzie de facto „must-do”.
Zatem, warunki początkowe.
Jesteś w nowym miejscu pracy lub awansowałeś, albo postanowiłeś na nowo spojrzeć na swoje obowiązki. Sieć firmy to twoja strefa odpowiedzialności. Dla ciebie jest to w dużej mierze wyzwanie i coś nowego, co troszkę uzasadnia mentorską tonację tego artykułu :). Mam jednak nadzieję, że artykuł może być również przydatny dla każdego inżyniera sieci.
Twoim pierwszym strategicznym celem jest nauczenie się przeciwstawiania entropii i utrzymania poziomu świadczonej usługi.
Wiele z opisanych poniżej zadań można rozwiązać na różne sposoby. Celowo nie poruszam tematu realizacji technicznej, ponieważ często tak naprawdę nie ma znaczenia, jak rozwiązałeś dane zadanie, a bardziej to, jak tego używasz i czy w ogóle z tego korzystasz. Mało jest pożytku, na przykład, z profesjonalnie zbudowanego systemu monitorowania, jeśli go nie obserwujesz i nie reagujesz na alerty.
Sprzęt
Na początku musisz zrozumieć, gdzie tkwią największe ryzyka.
Znowu może być różnie. Przyjmuję, że gdzieś, na przykład, będą to pytania związane z bezpieczeństwem, a gdzie indziej zagadnienia związane z ciągłością usług, a może jeszcze coś innego. Dlaczego nie?
Załóżmy dla pewności, że chodzi o ciągłość usług (tak było we wszystkich firmach, w których pracowałem).
W takim razie należy zacząć od sprzętu. Oto lista tematów, na które należy zwrócić uwagę:
- klasyfikacja sprzętu według stopnia krytyczności
- rezerwacja krytycznego sprzętu
- wsparcie, licencje
Musisz przemyśleć możliwe scenariusze awarii, szczególnie w przypadku sprzętu znajdującego się na szczycie twojej klasyfikacji krytyczności. Zwykle zaniedbuje się prawdopodobieństwo podwójnych problemów, w przeciwnym razie twoje rozwiązanie i wsparcie mogą stać się nieuzasadnione drogie, ale w przypadku naprawdę krytycznych elementów sieci, których awaria może znacząco wpłynąć na biznes, musisz również o tym pomyśleć.
Przykład
Załóżmy, że mówimy o przełączniku głównym w centrum danych.
Ponieważ umówiliśmy się, że ciągłość usługi jest najważniejszym kryterium, rozsądnie jest zapewnić „gorące” rezerwowanie (redundancję) tego sprzętu. Ale to nie wszystko. Musisz również określić, ile czasu, w przypadku awarii pierwszego przełącznika, jesteś gotów funkcjonować tylko z jednym pozostałym przełącznikiem, ponieważ istnieje ryzyko, że i on ulegnie awarii.
Waża sprawa! Nie powinieneś samodzielnie podejmować tej decyzji. Musisz opisać ryzyka, możliwe rozwiązania i koszty swojemu kierownictwu lub kierownictwu firmy. Decyzje powinny podejmować oni.
Tak więc, jeśli postanowiono, że przy małym prawdopodobieństwie podwójnej awarii praca przez 4 godziny na jednym przełączniku jest w zasadzie akceptowalna, możesz po prostu wziąć odpowiednią pomoc (w ramach której sprzęt zostanie wymieniony w ciągu 4 godzin).
Ale jest ryzyko, że dostawa się nie powiedzie. Niestety, raz znaleźliśmy się w takiej sytuacji. Zamiast czterech godzin sprzęt podróżował przez tydzień!!!
Dlatego ten ryzyko również należy omówić i być może lepiej byłoby dla ciebie kupić jeszcze jeden przełącznik (trzeci) i trzymać go w ZIPrze („zimne” rezerwowanie) lub używać do celów laboratoryjnych.
Waża sprawa! Sporządź tabelę wszystkich wsparć, które posiadasz, z datami zakończenia i dodaj je do kalendarza, aby co najmniej miesiąc przed ich wygaśnięciem otrzymywać od Ciebie przypomnienie, że musisz zacząć przejmować się przedłużeniem wsparcia.
Nie wybaczą Ci, jeśli zapomnisz przedłużyć wsparcia, a następnego dnia po jego zakończeniu sprzęt się zepsuje.
Prace awaryjne
Cokolwiek się wydarzy w twojej sieci, w idealnym świecie powinieneś zachować dostęp do swojego sprzętu sieciowego.
Ważne! Musisz mieć dostęp do konsoli do całego sprzętu, a ten dostęp nie powinien zależeć od działającej sieci przesyłania danych użytkowników.
Musisz również wcześniej przewidzieć możliwe negatywne scenariusze i udokumentować niezbędne działania. Dostępność tego dokumentu jest także krytyczna, dlatego powinien być on nie tylko umieszczony w ogólnodostępnym zasobie działu, ale również zachowany lokalnie na komputerach inżynierów.
Obowiązkowo powinny się tam znaleźć
- informacje niezbędne do otwarcia zgłoszenia w wsparciu dostawcy lub integratora
- informacje, jak dostać się do każdego sprzętu (konsola, zarządzanie)
Oczywiście może tam być także zawarta każda inna przydatna informacja, na przykład opis procedury aktualizacji różnego sprzętu oraz pomocne komendy diagnostyczne.
Partnerzy
Teraz musisz ocenić ryzyko związane z partnerami. Zazwyczaj to
- dostawcy internetu oraz punkty wymiany ruchu (IX)
- dostawcy łączy komunikacyjnych
Jakie pytania należy sobie zadać? Podobnie jak w przypadku sprzętu, należy rozważyć różne możliwe scenariusze awaryjne. Na przykład, dla dostawców internetu, mogą to być takie pytania jak:
- co się stanie, jeśli dostawca internetu X przestanie z jakiegoś powodu świadczyć Ci usługę?
- czy wystarczy ci przepustowości pozostałych dostawców?
- jak dobra pozostanie łączność?
- jak niezależni są twoi dostawcy internetu i czy poważna awaria jednego z nich nie spowoduje problemów z innymi?
- ile optycznych wprowadzeń do twojego centrum danych?
- co się stanie, jeśli jedno z wprowadzeń zostanie całkowicie zniszczone?
Jeśli chodzi o wprowadzenia, w mojej praktyce w dwóch różnych firmach, w dwóch różnych centrach danych koparkach, które niszczyły studzienki, tylko cudem nasza optyka nie została uszkodzona. To wcale nie jest taki rzadki przypadek.
No i oczywiście, musisz nie tylko zadać te pytania, ale, ponownie, zyskując wsparcie zarządu, zapewnić w każdej sytuacji akceptowalne rozwiązanie.
Kopia zapasowa
Następnym priorytetem może być kopia zapasowa konfiguracji sprzętu. W każdym razie to bardzo ważny aspekt. Nie będę wymieniać przypadków, kiedy możesz stracić konfigurację, lepiej regularnie wykonywać kopię zapasową i nie myśleć o tym. Poza tym regularna kopia zapasowa może być bardzo przydatna w kontroli zmian.
Ważne! Wykonuj regularnie kopie zapasowe. To nie jest duża objętość danych, aby oszczędzać na tym. Rano dyżurny inżynier (lub ty) powinien otrzymywać raport od systemu, w którym jednoznacznie wskazane jest, czy kopia zapasowa powiodła się, czy nie, a w przypadku niepowodzenia problem powinien być rozwiązany lub utworzony bilet (zob. procesy działu sieciowego).
Wersje oprogramowania
Pytanie, czy należy przeprowadzić aktualizację oprogramowania, nie jest jednoznaczne. Z jednej strony, stare wersje to znane błędy i podatności, ale z drugiej strony, nowe oprogramowanie to po pierwsze, nie zawsze bezproblemowy proces aktualizacji, a po drugie nowe błędy i podatności.
Tutaj trzeba znaleźć optymalne rozwiązanie. Kilka oczywistych zaleceń
- instaluj tylko stabilne wersje
- jednak nie warto żyć na bardzo starych wersjach oprogramowania
- stwórz tabelę z informacjami, gdzie jakie oprogramowanie jest zainstalowane
- okresowo czytaj raporty o podatnościach i błędach w wersjach oprogramowania, a w przypadku krytycznych problemów warto pomyśleć o aktualizacji
Na tym etapie, mając dostęp konsolowy do sprzętu, informacje o wsparciu i opis procedury aktualizacji, jesteś w zasadzie gotowy do tego kroku. Idealnie byłoby mieć sprzęt laboratoryjny, na którym można przetestować całą procedurę, ale niestety, to rzadko się zdarza.
W przypadku krytycznego sprzętu można zwrócić się do wsparcia producenta z prośbą o pomoc przy przeprowadzeniu aktualizacji.
System biletowy
Teraz możesz rozejrzeć się wokół. Musisz nawiązać procesy współpracy z innymi działami oraz w obrębie działu.
Może to nie jest obowiązkowe (na przykład, jeśli twoja firma jest mała), ale zdecydowanie poleciłbym zorganizowanie pracy w taki sposób, aby wszystkie zewnętrzne i wewnętrzne zadania przechodziły przez system biletowy.
System biletowy to w zasadzie twój interfejs do komunikacji wewnętrznej i zewnętrznej, i powinieneś wystarczająco szczegółowo opisać ten interfejs.
Rozważmy na przykład ważne i często spotykane zadanie związane z otwieraniem dostępu. Opiszę algorytm, który doskonale sprawdził się w jednej z firm.
Przykład
Zacznijmy od tego, że często klienci formułują swoje życzenia w niezrozumiałym dla inżyniera sieciowego języku, a mianowicie, w języku aplikacji, na przykład „otwórz mi dostęp do 1C”.
Dlatego nigdy nie przyjmowaliśmy zapytań bezpośrednio od takich użytkowników.
I to było pierwsze wymaganie
- zapytania o dostęp muszą pochodzić z działów technicznych (w naszym przypadku byli to inżynierowie unix, windows i helpdesk)
Drugim wymaganiem jest to, że
- ten dostęp musi być protokołowany (przez dział techniczny, z którego otrzymaliśmy to zapytanie) i jako zapytanie dostajemy link do tego protokołowanego dostępu
Forma tego zapytania musi być dla nas zrozumiała, to znaczy
- zapytanie powinno zawierać informacje o tym, z jakiej i do jakiej podsieci ma być otwarty dostęp, a także o protokole i (w przypadku tcp/udp) portach
Powinno tam również być wskazane
- opis, dlaczego ten dostęp jest otwierany
- tymczasowy lub stały (jeśli tymczasowy, to do kiedy)
I bardzo ważny punkt to zatwierdzenia
- od kierownika działu, który zainicjował dostęp (na przykład działu księgowości)
- od kierownika działu technicznego, z którego to zapytanie wpłynęło do działu sieciowego (na przykład helpdesk)
Przy tym „właścicielem” tego dostępu jest kierownik działu, który zainicjował dostęp (dział księgowości w naszym przykładzie) i on jest odpowiedzialny za to, aby strona z protokółowanymi dostępami dla tego działu była aktualna.
Rejestrowanie
To jest coś, w czym można utknąć. Ale jeśli chcesz wdrożyć proaktywną strategię, musisz nauczyć się radzić sobie z tym strumieniem danych.
Oto kilka praktycznych wskazówek:
- logi należy przeglądać codziennie
- w przypadku planowego przeglądu (a nie sytuacji awaryjnej) można ograniczyć się do poziomów krytyczności (severity) 0, 1, 2 i dodać ulubione wzorce z innych poziomów, jeśli uważasz to za konieczne
- napisz skrypt, który parsuje logi i ignoruje te logi, wzorce których dodałeś do listy ignorowanych
To podejście pozwoli w miarę upływu czasu stworzyć listę ignorowanych logów, które cię nie interesują i pozostawić tylko te, które naprawdę uważasz za ważne.
U nas to świetnie działało.
Monitoring
Nie jest rzadkością, że w firmie brakuje systemu monitorowania. Możesz, na przykład, polegać na logach, ale sprzęt może po prostu "umarł", nie zdążywszy nic "powiedzieć", lub pakiet UDP protokołu syslog może się zgubić i nie dotrzeć. Ogólnie rzecz biorąc, aktywne monitorowanie jest ważne i potrzebne.
Dwa najbardziej poszukiwane w mojej praktyce przykłady:
- monitorowanie obciążenia łączy krytycznych, (na przykład, połączenie z dostawcami). Umożliwiają proaktywne dostrzeganie potencjalnych problemów z degradacją usług z powodu utraty ruchu i tym samym ich unikanie.
- wykresy oparte na NetFlow. Umożliwiają łatwe wykrywanie anomalii w ruchu i są bardzo pomocne w identyfikacji niektórych prostych, ale istotnych rodzajów ataków hakerskich.
Ważne! Skonfiguruj powiadomienia SMS dla najbardziej krytycznych zdarzeń. Dotyczy to zarówno monitorowania, jak i logowania. Jeśli nie masz dyżurującego zespołu, powiadomienia SMS powinny również przychodzić poza godzinami pracy.
Przemyśl proces w taki sposób, aby nie budzić wszystkich inżynierów. U nas w tym celu był dyżurujący inżynier.
Kontrola zmian
Moim zdaniem, nie jest konieczne kontrolowanie wszystkich zmian. Niemniej jednak, musisz mieć możliwość łatwego znalezienia, kto i dlaczego wprowadził określone zmiany w sieci, jeśli zajdzie taka potrzeba.
Kilka wskazówek:
- używaj systemu zgłoszeń do szczegółowego opisu tego, co zostało zrobione w ramach tego zgłoszenia, na przykład kopiując zastosowaną konfigurację do zgłoszenia
- wykorzystuj możliwości komentarzy na sprzęcie sieciowym (na przykład, commit comment na Juniper). Możesz zapisać numer zgłoszenia
- używaj diffów swoich kopii zapasowych konfiguracji
Możesz to wprowadzić jako proces, przeglądając codziennie wszystkie zgłoszenia pod kątem zmian.
Procesy
Musisz sformalizować i opisać procesy w swoim zespole. Jeśli dotarłeś do tego momentu, w Twoim zespole powinny już działać co najmniej następujące procesy:
Procesy codzienne:
- praca z zgłoszeniami
- praca z logami
- kontrola zmian
- codzienna lista kontrolna
Procesy roczne:
- odnowienie gwarancji, licencji
Procesy asynchroniczne:
- reakcja na różne sytuacje awaryjne
Zakończenie pierwszej części
Zauważyłeś, że to wszystko nie dotyczy konfiguracji sieci, designu, protokołów sieciowych, routingu ani bezpieczeństwa… To coś więcej. To może być nudne, ale oczywiście są to bardzo ważne elementy pracy działu sieciowego.
Na razie, jak widzisz, nie poprawiłeś nic w swojej sieci. Jeśli były luki w bezpieczeństwie, to one nadal istnieją, jeśli był zły design, to on się nie zmienił. Dopóki nie zastosujesz swoich umiejętności i wiedzy inżyniera sieci, na co prawdopodobnie poświęciłeś dużo czasu, wysiłku, a czasem także pieniędzy. Ale najpierw musisz stworzyć (lub wzmocnić) fundament, a potem zająć się budową.
O tym, jak szukać i naprawiać błędy, a następnie poprawiać swoją infrastrukturę – to będą kolejne części.
Oczywiście, nie wszystko musi być robione w kolejności. Czas może być krytyczny. Rób to równolegle, jeśli pozwalają na to zasoby.
I ważna uwaga. Komunikuj się, pytaj, konsultuj się ze swoją ekipą. W końcu to oni będą to wszystko utrzymywać i realizować.
Źródło: habr.com
