W chwili pisania tego tekstu wyszukiwanie frazy „Inżynier sieci” na popularnej stronie z ofertami pracy dało około trzystu wolnych miejsc pracy w całej Rosji. Dla porównania, wyszukanie frazy „administrator systemu” zwraca prawie 2.5 tys. wolnych miejsc pracy, a „inżynier DevOps” – prawie 800.
Czy to oznacza, że w czasach zwycięskich chmur, dockera, kubernetisa i wszechobecnego publicznego Wi-Fi, networkerzy nie są już potrzebni?
rozwiążmy to (s)
Poznajmy się. Nazywam się Alexey i jestem networkerem.
Sieciami zajmuję się od ponad 10 lat, a od ponad 15 lat pracuję z różnymi systemami * nix (miałem okazję wybrać zarówno Linuksa, jak i FreeBSD). Pracowałem w operatorach telekomunikacyjnych, dużych firmach, które są uważane za „przedsiębiorstwa”, a ostatnio pracuję w „młodych i odważnych” fintechach, gdzie chmury, devops, kubernetes i inne przerażające słowa, które na pewno sprawią, że ja i moi koledzy niepotrzebny. Pewnego dnia. Może.
zastrzeżenie: „W naszym życiu nie wszystko, zawsze i wszędzie, ale coś, czasem w miejscach” (c) Maxim Dorofeev.
Wszystko, co napisano poniżej, może i powinno być traktowane jako osobista opinia autora, nie pretendująca do miana ostatecznej prawdy, a nawet pełnoprawne opracowanie. Wszystkie postacie są fikcyjne, wszystkie zbiegi okoliczności są przypadkowe.
Witam w moim świecie.
Gdzie można znaleźć networkerów?
1. Operatorzy telekomunikacyjni, firmy usługowe i inni integratorzy. Wszystko jest proste: sieć to dla nich biznes. Albo bezpośrednio sprzedają łączność (operatorzy), albo świadczą usługi uruchamiania/utrzymania sieci swoich klientów.
Tutaj jest duże doświadczenie, ale mało pieniędzy (chyba, że jesteś dyrektorem lub odnoszącym sukcesy kierownikiem sprzedaży). A jednak, jeśli lubisz sieci i jesteś dopiero na początku swojej drogi, kariera wspierająca jakiegoś niezbyt dużego operatora będzie już teraz idealnym punktem wyjścia (wszystko jest bardzo oskryptowane w federalnych, a tam jest mało miejsca na kreatywność). Cóż, opowieści o tym, że z dyżurującego inżyniera w kilka lat można wyrosnąć na kierownika C-level, też są całkiem realne, choć z oczywistych względów rzadkie. Zawsze jest zapotrzebowanie na personel, ponieważ wciąż jest rotacja. Jest to jednocześnie dobre i złe – zawsze są wolne miejsca, z drugiej strony – często ci najbardziej aktywni/mądrzy dość szybko albo awansują, albo wyjeżdżają do innych, „cieplejszych” miejsc.
2. Warunkowe „przedsiębiorstwo”. Nie ma znaczenia, czy jego główna działalność jest związana z IT, czy nie. Najważniejsze, że ma własny dział IT, który zajmuje się zapewnieniem działania wewnętrznych systemów firmy, w tym sieci w biurach, kanałów komunikacji z oddziałami itp. Funkcje inżyniera sieciowego w takich firmach mogą być wykonywane „na pół etatu” przez administratora systemu (jeśli infrastruktura sieciowa jest niewielka lub zaangażowany jest w nią zewnętrzny wykonawca), a kierownik sieci, jeśli jeszcze istnieje, może dbać jednocześnie o telefonię i SAN (nie nuacho). Płacą na różne sposoby - to mocno zależy od marży firmy, wielkości firmy i struktury. Pracowałem zarówno z firmami, w których cisco były regularnie „ładowane do beczek”, jak i z firmami, w których sieć była budowana z fekaliów, patyków i niebieskiej taśmy elektrycznej, a serwery nie były aktualizowane mniej więcej nigdy (trzeba powiedzieć, że nie było też rezerw). Tutaj jest znacznie mniej doświadczenia i prawie na pewno będzie to w obszarze hard vendor-lock, czyli „jak zrobić coś z niczego”. Osobiście wydawało mi się to szalenie nudne, chociaż wielu ludziom się to podoba - wszystko jest dość wyważone i przewidywalne (jeśli mówimy o dużych firmach), „dorah-bajato” itp. Przynajmniej raz w roku jakiś duży producent mówi, że wymyślił kolejny mega-super-duper system, który teraz wszystko automatyzuje, a wszyscy administratorzy systemu i osoby pracujące w sieci mogą zostać przetaktowani, pozostawiając parę przycisków w pięknym interfejsie. Rzeczywistość jest taka, że nawet jeśli zignorujemy koszt rozwiązania, networkerzy nigdzie się nie ruszą. Tak, niewykluczone, że zamiast konsoli znów pojawi się webowy interfejs (ale nie konkretny kawałek żelaza, a duży system zarządzający dziesiątkami i setkami takich kawałków żelaza), ale wiedza „jak wszystko działa w środku ” będą nadal potrzebne.
3. Firmy produktowe, których zysk pochodzi z rozwoju (i często eksploatacji) jakiegoś oprogramowania lub platformy - tego właśnie produktu. Zwykle są małe i zwinne, daleko im jeszcze do skali przedsiębiorstw i ich biurokratyzacji. To tutaj te same devops, cubers, dockers i inne okropne słowa znajdują się w dużych ilościach, co z pewnością sprawi, że sieć i inżynierowie sieci będą niepotrzebnym szczątkiem.
Czym różni się menedżer sieci od administratora systemu?
W rozumieniu ludzi nie z IT - nic. Oboje patrzą na czarny ekran i piszą jakieś zaklęcia, czasem cicho przeklinając.
W rozumieniu programistów - być może dziedzina. Sysadmini administrują serwerami, administratorzy sieci administrują przełącznikami i routerami. Czasami administrator jest zły i wszystko spada na wszystkich. Cóż, w przypadku jakichkolwiek dziwnych, winni są również networkerzy. Tylko dlatego, że cię pierdolę, właśnie dlatego.
Tak naprawdę główna różnica polega na podejściu do pracy. Być może to właśnie wśród networkerów są przede wszystkim zwolennicy podejścia „To działa – nie ruszaj tego!”. Zwykle można coś zrobić (w ramach jednego sprzedawcy) tylko w jeden sposób, całą konfigurację pudełka - tutaj jest w zasięgu ręki. Koszt błędu jest wysoki, a czasem bardzo wysoki (przykładowo trzeba przejechać kilkaset kilometrów, żeby zrestartować router, a w tym czasie kilka tysięcy osób będzie bez łączności - sytuacja dość częsta u operatora telekomunikacyjnego ).
Moim zdaniem dlatego inżynierowie sieciowi z jednej strony są niezwykle silnie zmotywowani do stabilności sieci (a głównym wrogiem stabilności są zmiany), a po drugie ich wiedza sięga głębiej niż wszerz (nie trzeba aby móc skonfigurować dziesiątki różnych demonów, trzeba znać technologie i ich implementację od konkretnego producenta sprzętu). Dlatego administrator systemu, który wygooglował, jak zarejestrować vlan na tsisce, nie jest jeszcze menedżerem sieci. I jest mało prawdopodobne, że będzie w stanie skutecznie wspierać (a także rozwiązywać problemy) mniej lub bardziej złożoną sieć.
Ale dlaczego potrzebujesz menedżera sieci, jeśli masz hostera?
Za dodatkową opłatą (a jeśli jesteś bardzo dużym i ukochanym klientem, może nawet za darmo, „jako przyjaciel”) inżynierowie centrum danych skonfigurują Twoje przełączniki zgodnie z Twoimi potrzebami, a być może nawet pomogą podnieść interfejs BGP z dostawcami (jeśli masz własną podsieć adresów IP do ogłoszenia).
Główny problem polega na tym, że centrum danych to nie Twój dział IT, to osobna firma, której celem jest generowanie zysku. W tym kosztem Ciebie jako klienta. Centrum danych udostępnia szafy, zapewnia im prąd i chłód, a także zapewnia pewną „domyślną” łączność z Internetem. Bazując na tej infrastrukturze, centrum danych może kolokować Twój sprzęt (kolokacja), wynajmować Ci serwer (serwer dedykowany) lub świadczyć usługi zarządzane (np. OpenStack lub K8s). Ale biznesem centrum danych (zwykle) nie jest administrowanie infrastrukturą klienta, ponieważ ten proces jest raczej pracochłonny, słabo zautomatyzowany (a w normalnym centrum danych wszystko jest zautomatyzowane), jeszcze gorzej ujednolicony (każdy klient jest indywidualny) i generalnie obarczone roszczeniami („mówisz mi, że serwer był ustawiony, a teraz się zawiesił, to wszystko twoja wina!!!111”). Dlatego jeśli hoster ci w czymś pomoże, to postara się, aby było to jak najprostsze i „mieszkaniowe”. Bo to trudne do zrobienia - nieopłacalne, przynajmniej z punktu widzenia kosztów pracy inżynierów tego właśnie hostera (ale sytuacje są różne, patrz zastrzeżenie). Nie oznacza to, że gospodarz koniecznie zrobi wszystko źle. Ale wcale nie jest faktem, że zrobi dokładnie to, czego naprawdę potrzebujesz.
Wydawałoby się, że sprawa jest dość oczywista, ale kilka razy w swojej praktyce spotkałem się z tym, że firmy zaczęły polegać na swoim dostawcy usług hostingowych trochę bardziej niż powinny, a to nie prowadziło do niczego dobrego. Długo trzeba było szczegółowo wyjaśniać, że żaden SLA nie pokryje strat przestoju (są wyjątki, ale zazwyczaj jest to BARDZO BARDZO kosztowne dla klienta) oraz że hoster w ogóle nie jest świadomy tego, co dzieje się w infrastrukturze klienta (poza bardzo ogólnymi wskaźnikami). Hoster też nie tworzy dla ciebie kopii zapasowych. Sytuacja jest jeszcze gorsza, jeśli masz więcej niż jednego hostera. W przypadku jakichkolwiek problemów między nimi, na pewno nie dowiedzą się za Ciebie, co poszło nie tak.
Właściwie motywy są tutaj dokładnie takie same jak przy wyborze „własny zespół adminów vs outsourcing”. Jeśli ryzyko jest skalkulowane, jakość odpowiada, a biznesowi to nie przeszkadza – dlaczego nie spróbować. Z drugiej strony sieć jest jedną z najbardziej podstawowych warstw infrastruktury i nie warto oddawać jej osobom z zewnątrz, jeśli sam obsługujesz już wszystko inne.
Kiedy potrzebujesz networkera?
W dalszej kolejności skupimy się na spółkach nowoczesnych produktów. Z operatorami i przedsiębiorstwami wszystko jest na plus lub minus jasne - niewiele się tam zmieniło w ostatnich latach, a networkerzy byli tam potrzebni wcześniej, są potrzebni teraz. Ale z tymi bardzo „młodymi i odważnymi” sprawa nie jest taka prosta. Często umieszczają całą swoją infrastrukturę w chmurach, więc nie potrzebują nawet administratorów, z wyjątkiem oczywiście administratorów tych samych chmur. Infrastruktura z jednej strony jest dość prosta w swojej konstrukcji, z drugiej strony jest dobrze zautomatyzowana (ansible/puppet, terraform, ci/cd… no wiesz). Ale nawet tutaj zdarzają się sytuacje, w których nie można obejść się bez inżyniera sieci.
Przykład 1, klasyczny
Załóżmy, że firma zaczyna od jednego serwera z publicznym adresem IP, który znajduje się w centrum danych. Następnie są dwa serwery. Potem więcej... Prędzej czy później pojawi się potrzeba stworzenia prywatnej sieci pomiędzy serwerami. Ponieważ ruch „zewnętrzny” jest ograniczony zarówno przepustowością (na przykład nie więcej niż 100 Mb / s), jak i ilością pobrań / przesłanych miesięcznie (różni dostawcy usług hostingowych mają różne taryfy, ale przepustowość do świata zewnętrznego jest z reguły znacznie droższa niż sieć prywatna).
Hoster dodaje do serwerów dodatkowe karty sieciowe i umieszcza je w swoich przełącznikach w osobnym vlanie. Pomiędzy serwerami pojawia się „płaska” sieć LAN. Wygodny!
Rośnie liczba serwerów, rośnie też ruch w sieci prywatnej – kopie zapasowe, replikacje itp. Hoster oferuje przeniesienie cię do oddzielnych przełączników, abyś nie przeszkadzał innym klientom, a oni nie przeszkadzali tobie. Hoster stawia jakieś przełączniki i jakoś je konfiguruje - najprawdopodobniej pozostawiając jedną płaską sieć między wszystkimi twoimi serwerami. Wszystko działa dobrze, ale w pewnym momencie zaczynają się problemy: okresowo rosną opóźnienia między hostami, logi zaklinają się na zbyt wiele pakietów arp na sekundę, a pentester podczas audytu zgwałcił całą Twoją okolicę, psując tylko jeden serwer.
Co robić
Podziel sieć na segmenty - vlany. Skonfiguruj własną adresację w każdym vlanie, wybierz bramę, która będzie przekazywać ruch między sieciami. Na bramie skonfiguruj acl, aby ograniczyć dostęp między segmentami, a nawet umieść obok niej oddzielną zaporę ogniową.
Przykład 1, ciąg dalszy
Serwery są połączone z obszarem lokalnym za pomocą jednego przewodu. Przełączniki w stojakach są w jakiś sposób połączone, ale w razie wypadku w jednym stojaku odpadają trzy kolejne sąsiednie. Schematy istnieją, ale istnieją wątpliwości co do ich przydatności. Każdy serwer ma swój własny adres publiczny, który jest nadawany przez hosta i powiązany z szafą. Te. podczas przenoszenia serwera należy zmienić adres.
Co robić
Podłącz serwery za pomocą LAG (Link Aggregation Group) za pomocą dwóch przewodów do przełączników w szafie (muszą też być redundantne). Zarezerwuj połączenia między stojakami, przerób je z „gwiazdą” (lub modnym teraz CLOSem), aby utrata jednego stojaka nie wpłynęła na pozostałe. Wybierz „centralne” szafy, w których będzie zlokalizowany rdzeń sieci i gdzie zostaną uwzględnione inne szafy. Jednocześnie uporządkuj adresowanie publiczne, weź od hostera (lub z RIR, jeśli to możliwe) podsieć, którą sam (lub za pośrednictwem hostera) ogłaszasz światu.
Czy „zwykły” administrator systemu, który nie ma głębokiej wiedzy o sieciach, może to wszystko zrobić? Niepewny. Czy gospodarz to zrobi? Może tak, ale będziesz potrzebował dość szczegółowego TORa, który również będzie musiał zostać przez kogoś skompilowany. a następnie sprawdź, czy wszystko zostało wykonane poprawnie.
Przykład 2: Zachmurzenie
Załóżmy, że masz VPC w jakiejś chmurze publicznej. Aby uzyskać dostęp z biura lub części infrastruktury on-prem do sieci lokalnej wewnątrz VPC, należy zestawić połączenie przez IPSec lub dedykowany kanał. Z jednej strony IPSec jest tańszy. nie musisz kupować dodatkowego sprzętu, możesz skonfigurować tunel między swoim serwerem z adresem publicznym a chmurą. Ale - opóźnienia, ograniczona wydajność (ponieważ kanał musi być szyfrowany) oraz niegwarantowana łączność (ponieważ dostęp odbywa się przez zwykły Internet).
Co robić
Podnieś połączenie przez dedykowany kanał (na przykład AWS nazywa to Direct Connect). W tym celu znajdź partnera operatora, który Cię połączy, zdecyduj o najbliższym punkcie połączenia (zarówno ty do operatora, jak i operator do chmury), a na koniec wszystko skonfiguruj. Czy to wszystko można zrobić bez inżyniera sieci? Na pewno tak. Ale jak rozwiązywać problemy bez niego w przypadku problemów, nie jest już tak jasne.
Mogą również wystąpić problemy z dostępnością między chmurami (jeśli masz multicloud) lub problemy z opóźnieniami między różnymi regionami itp. Oczywiście teraz istnieje wiele narzędzi, które zwiększają przejrzystość tego, co dzieje się w chmurze (ten sam Tysiąc Oczu), ale wszystkie są narzędziami inżyniera sieci, a nie zamiennikiem.
Mógłbym naszkicować jeszcze z tuzin takich przykładów z mojej praktyki, ale myślę, że jasne jest, że w zespole, zaczynając od pewnego poziomu rozwoju infrastruktury, powinna być osoba (a raczej więcej niż jedna), która wie, jak sieć działa, potrafi konfigurować sprzęt sieciowy i rozwiązywać problemy, jeśli się pojawią. Uwierz mi, będzie miał co robić
Co powinien wiedzieć networker?
Nie jest wcale konieczne (a czasem nawet szkodliwe), aby inżynier sieci zajmował się tylko siecią i niczym więcej. Nawet jeśli nie weźmiemy pod uwagę opcji z infrastrukturą, która prawie w całości żyje w chmurze publicznej (i cokolwiek można powiedzieć, staje się ona coraz bardziej popularna) i weźmiemy na przykład chmurę lokalną lub prywatną, gdzie tylko „Wiedza na poziomie CCNP „Nie odejdziesz.
Oprócz sieci - chociaż istnieje po prostu nieskończone pole do badań, nawet jeśli koncentrujesz się tylko na jednym kierunku (sieci dostawców, przedsiębiorstwa, centra danych, Wi-Fi ...)
Oczywiście wielu z Was pamięta teraz Pythona i inną „automatyzację sieciową”, ale jest to tylko warunek konieczny, ale niewystarczający. Aby inżynier sieciowy „z powodzeniem dołączył do zespołu”, musi być w stanie mówić tym samym językiem zarówno z programistami, jak i innymi administratorami / devopami. Co to znaczy?
- umieć nie tylko pracować w Linuksie jako użytkownik, ale także administrować nim, przynajmniej na poziomie sysadmin-junior: zainstalować niezbędne oprogramowanie, zrestartować upadłą usługę, napisać prosty systemd-unit.
- Zrozumieć (przynajmniej ogólnie) jak działa stos sieciowy w Linuksie, jak działa sieć w hiperwizorach i kontenerach (lxc/docker/kubernetes).
- Oczywiście być w stanie pracować z ansible/chef/puppet lub innym systemem SCM.
- Osobny wiersz należy napisać o SDN i sieciach dla chmur prywatnych (na przykład TungstenFabric czy OpenvSwitch). To kolejna ogromna porcja wiedzy.
W skrócie opisałem typowego specjalistę od T-shape (jak to się teraz modnie mówi). Wydaje się, że to nic nowego, jednak zgodnie z doświadczeniami z wywiadów, nie wszyscy inżynierowie sieciowi mogą pochwalić się znajomością co najmniej dwóch tematów z powyższej listy. W praktyce brak wiedzy „w pokrewnych dziedzinach” bardzo utrudnia nie tylko komunikację ze współpracownikami, ale także zrozumienie wymagań, jakie biznes stawia sieci jako infrastrukturze najniższego poziomu projektu. A bez tego zrozumienia trudniej jest rozsądnie bronić swojego punktu widzenia i „sprzedać” go biznesowi.
Z drugiej strony sam nawyk „rozumienia, jak działa system” daje networkerom bardzo dobrą przewagę nad różnymi „generalistami”, którzy znają technologie z artykułów na czacie Habré/medium i telegramów, ale nie mają zupełnie pojęcia, na jakich zasadach to lub to oprogramowanie działa. A znajomość pewnych prawidłowości, jak wiadomo, z powodzeniem zastępuje znajomość wielu faktów.
Wnioski, czyli po prostu TL;DR
- Administrator sieci (tak jak DBA czy inżynier VoIP) to specjalista o dość wąskim profilu (w przeciwieństwie do sysadmins/devops/SRE), którego potrzeba nie pojawia się od razu (i w rzeczywistości może nie powstać przez długi czas) . Ale jeśli się pojawi, jest mało prawdopodobne, aby została zastąpiona przez zewnętrzną ekspertyzę (outsourcing lub zwykli administratorzy generalni, „którzy również opiekują się siecią”). Nieco smutniejsze jest to, że zapotrzebowanie na takich specjalistów jest niewielkie, a warunkowo w firmie z 800 programistami i 30 devopsami/administratorami może być tylko dwóch networkerów, którzy doskonale wykonują swoją pracę. Te. rynek był i jest bardzo, bardzo mały, a jeszcze mniej z dobrą pensją.
- Z drugiej strony dobry networker we współczesnym świecie powinien znać się nie tylko na samych sieciach (i jak zautomatyzować ich konfigurację), ale także na tym, jak współdziałają z nimi systemy operacyjne i oprogramowanie, które działają w tych sieciach. Bez tego niezwykle trudno będzie zrozumieć, o co proszą cię współpracownicy, i przekazać im (rozsądnie) swoje życzenia / wymagania.
- Nie ma chmury, to tylko czyjś komputer. Musisz zrozumieć, że korzystanie z chmur publicznych/prywatnych czy usług dostawców hostingu „którzy zrobią za Ciebie wszystko” nie przekreśla faktu, że Twoja aplikacja nadal korzysta z sieci, a problemy z nią wpłyną na działanie Twojej aplikacji . Twój wybór to miejsce, w którym zlokalizowane zostanie centrum kompetencyjne, które będzie odpowiedzialne za sieć Twojego projektu.
Źródło: www.habr.com