W momencie pisania tego artykułu, wyszukiwanie na popularnej stronie z ofertami pracy pod hasłem „Inżynier sieci” zwracało około trzystu ofert pracy w całej Rosji. Dla porównania, wyszukiwanie frazy „administrator systemów” zwraca prawie 2,5 tysiąca ofert, a „inżynier DevOps” — prawie 800.
Czy oznacza to, że inżynierowie sieciowi nie są już potrzebni w czasach dominujących chmur, Dockera, Kubernetes i wszechobecnego publicznego Wi-Fi?
Zastanówmy się nad tym (c)
Pozwólcie, że się przedstawię. Nazywam się Aleksiej i jestem inżynierem sieciowym.
Od ponad 10 lat zajmuję się sieciami i od ponad 15 lat pracuję z różnymi systemami *nix (zdarzyło mi się grzebać zarówno w Linuksie, jak i FreeBSD). Pracowałem u operatorów telekomunikacyjnych, w dużych firmach uznawanych za „enterprise”, a ostatnio pracuję w młodej i odważnej branży fintech, gdzie chmury, DevOps, Kubernetes i inne straszne słowa, które na pewno uczynią mnie i moich kolegów zbędnymi. Kiedyś. Może.
zrzeczenie się odpowiedzialności: „W naszym życiu nie wszystko, zawsze i wszędzie, a niektóre rzeczy, czasami i miejscami” (c) Maksym Dorofiejew.
Wszystko, co napisane poniżej, można i trzeba traktować jako osobiste zdanie autora, które nie rości sobie prawa do bycia ostateczną prawdą, ani nawet pełnoprawnym badaniem. Wszystkie postacie są fikcyjne, wszelkie zbieżności przypadkowe.
Witaj w moim świecie.
Gdzie można spotkać inżynierów sieciowych?
1. Operatorzy telekomunikacyjni, firmy serwisowe i inni integratorzy. Tu wszystko jest proste: sieć to dla nich biznes. Bezpośrednio sprzedają łączność (operatorzy) lub świadczą usługi uruchamiania/utrzymania sieci swoich klientów.
Tutaj jest dużo doświadczenia, ale niewiele pieniędzy (chyba że jesteś dyrektorem lub skutecznym menedżerem sprzedaży). Niemniej jednak, jeśli interesują Cię sieci i dopiero zaczynasz swoją drogę, kariera w wsparciu jakiegoś mniejszego operatora będzie, nawet teraz, idealnym punktem wyjścia (w dużych firmach wszystko jest bardzo schematyczne i jest mało miejsca na kreatywność). Historie o tym, że można z technika dyżurnego awansować w ciągu kilku lat do menedżera na poziomie C, również są całkiem realne, chociaż rzadkie, z oczywistych powodów. Potrzeba pracowników zawsze istnieje, ponieważ rotacja jest zjawiskiem rzeczywistym. To ma swoje dobre i złe strony — zawsze są wolne miejsca, z drugiej strony — często najbardziej aktywni/inteligentni szybko odchodzą, albo awansując, albo do innych, bardziej „komfortowych” miejsc.
2. Warunkowy "enterprise". Niezależnie od tego, czy jego główna działalność związana jest z IT, czy nie. Najważniejsze jest to, że posiada własny dział IT, który zajmuje się zapewnieniem pracy wewnętrznych systemów firmy, w tym sieci w biurach, kanałów komunikacyjnych do oddziałów itp. Funkcje inżyniera sieci w takich firmach mogą „na zasadzie współpracy” pełnić administratorzy systemów (jeśli infrastruktura sieciowa jest niewielka, lub zajmuje się nią zewnętrzny wykonawca), a sieciowiec, jeśli w ogóle jest, może również nadzorować telefonię i SAN (w końcu). Wynagrodzenia są różne - mocno zależy od rentowności biznesu, wielkości firmy i struktury. Pracowałem z firmami, gdzie cisco regularnie „ładowały beczki”, i z firmami, gdzie sieć budowano z odpadów, kijków i niebieskiej taśmy, a serwery nigdy nie były aktualizowane (czy trzeba mówić, że żadne rezerwy również nie były przewidziane). Doświadczenia jest znacznie mniej, i prawie na pewno będzie w obszarze sztywnego vendor-locka albo „jak z niczego zrobić coś”. Osobiście wydawało mi się tam strasznie nudno, chociaż wielu to lubi - wszystko jest wystarczająco spokojne i przewidywalne (jeśli mówimy o dużych firmach), „dorahabachato” itp. Nie rzadziej niż raz w roku jakiś duży dostawca mówi, że wymyślił kolejną mega-super-system, która automatyzuje wszystko, więc wszystkich administratorów systemów i inżynierów sieciowych można by zwolnić, zostawiając kilku do kliknięcia przycisków w ładnym interfejsie. Rzeczywistość jest jednak taka, że nawet abstrahując od kosztów rozwiązania, inżynierowie sieciowi z tego miejsca się nie wycofają. Tak, być może zamiast konsoli znowu będzie interfejs webowy (ale nie już konkretnego sprzętu, a dużego systemu, który zarządza dziesiątkami i setkami takich urządzeń), ale wiedza o tym, „jak wszystko działa w środku” nadal będzie potrzebna.
3. Firmy produktowe, której zyski pochodzą z tworzenia (i często, eksploatacji) jakiegoś oprogramowania lub platformy - tego właśnie produktu. Zwykle są to małe i zwinne firmy, które jeszcze daleko mają do rozmiarów przedsiębiorstw i ich biurokracji. To tutaj masowo znajdują się ci wszyscy devopsi, kubery, dockery i inne straszne słowa, które koniecznie uczynią sieć i inżynierów sieciowych niepotrzebnym reliktem.
Czym różni się inżynier sieciowy od administratora systemu?
W oczach osób spoza branży IT — nic. I jedni, i drudzy patrzą w czarny ekran i wpisują jakieś zaklęcia, czasem przeklinając cicho.
W oczach programistów — może tylko jako dziedzina specjalizacji. Administratorzy systemów zarządzają serwerami, sieciowcy zarządzają przełącznikami i routerami. Czasem administrowanie nie idzie dobrze i wszystko zawodzi. W przypadku różnych problemów również to sieciowcy są winni. Po prostu dlatego, że tak.
Tak naprawdę, główna różnica polega na podejściu do pracy. Być może to właśnie wśród sieciowców najczęściej można spotkać zwolenników podejścia „Działa — nie ruszaj!”. Zrealizowanie pewnej rzeczy (w ramach jednego dostawcy) zazwyczaj można zrobić tylko jednym sposobem, a cała konfiguracja sprzętu — jest na wyciągnięcie ręki. Koszt błędu jest wysoki, a czasem bardzo wysoki (na przykład trzeba będzie jechać setki kilometrów, aby zrestartować router, a w tym czasie kilka tysięcy osób będzie bez łączności — całkiem zwyczajna sytuacja dla operatora).
Moim zdaniem, właśnie dlatego inżynierowie sieciowi, z jednej strony, są niezwykle zmotywowani do zapewnienia stabilności sieci (a zmiany są głównym wrogiem stabilności), a z drugiej strony, ich wiedza jest bardziej wnikliwa niż szeroka (nie potrzeba umieć konfigurować dziesiątek różnych demonów, trzeba znać technologie i ich realizację u konkretnego producenta sprzętu). Dlatego administrator systemów, który znalazł w Google, jak na urządzeniu Cisco ustawić VLAN — to jeszcze nie sieciowiec. I wątpię, aby mógł skutecznie wspierać (a także rozwiązywać problemy) bardziej skomplikowaną sieć.
Ale po co ci sieciowiec, jeśli masz powinien umieć to zrobić)?
Za dodatkową opłatą (a jeśli jesteś bardzo dużym i ulubionym klientem — być może nawet za darmo, "po znajomości") inżynierowie centrum danych skonfigurują twoje przełączniki według twoich potrzeb, a być może nawet pomogą uruchomić połączenie BGP z dostawcami (jeśli masz swoją podsieć adresów IP do ogłoszenia).
Głównym problemem jest to, że centrum danych to nie wasz dział IT, ale oddzielna firma, której celem jest generowanie zysków. W tym również na was, jako klientów. Centrum danych zapewnia szafy, dostarcza im energię elektryczną i chłodzenie, a także zapewnia pewną „domyślną” łączność z Internetem. Na bazie tej infrastruktury centrum danych może umieścić wasz sprzęt (colocation), wynająć wam serwer (serwer dedykowany) lub dostarczać usługę zarządzaną (na przykład OpenStack lub K8s). Ale prowadzenie administracji infrastruktury klientów (zwykle) nie jest działalnością centrum danych, ponieważ ten proces jest dość pracochłonny, słabo się automatyzuje (a w normalnym centrum danych zautomatyzowane jest wszystko, co tylko możliwe), jeszcze trudniej jest to ujednolicić (każdy klient jest indywidualny) i w ogóle wiąże się z roszczeniami („ustawiłeś mi serwer, a teraz się zawiesił, to wy jesteście za wszystko odpowiedzialni!!!111”). Dlatego jeśli hoster będzie wam w czymś pomagał, to postara się to zrobić w maksymalnie prosty i „sztywny” sposób. Bo robić coś skomplikowanego — jest nieopłacalne, przynajmniej z punktu widzenia nakładów pracy inżynierów tego samego hostera (ale sytuacje są różne, patrz zastrzeżenie). To nie oznacza, że hoster koniecznie wszystko zrobi źle. Ale wcale nie ma pewności, że zrobi dokładnie to, czego naprawdę potrzebowaliście.
Wydawałoby się, że to dosyć oczywiste, ale w swojej praktyce kilka razy spotkałem się z sytuacjami, gdzie firmy zaczynały polegać na swoim dostawcy hostingu nieco bardziej, niż powinny, co nie prowadziło do niczego dobrego. Musiałem długo i szczegółowo wyjaśniać, że żaden SLA nie pokryje strat wynikających z przestoju (są wyjątki, ale zazwyczaj jest to bardzo, BARDZO drogie dla klienta), a hoster w ogóle nie jest świadomy tego, co dzieje się w infrastrukturze zamawiającego (oprócz bardzo ogólnych wskaźników). I hoster również nie robi za was kopii zapasowych. Jeszcze gorzej wygląda sprawa, jeśli macie więcej niż jednego hostera. W przypadku jakichkolwiek problemów między nimi, na pewno nie będą wyjaśniać za was, co tak naprawdę poszło nie tak.
Motywy są tu dokładnie takie same, jak przy wyborze "własny zespół administratorów vs outsourcing". Jeśli ryzyka zostały oszacowane, jakość jest zadowalająca, a biznes nie ma nic przeciwko — czemu by nie spróbować. Z drugiej strony, sieć to jeden z najbardziej podstawowych poziomów infrastruktury, więc raczej nie warto oddawać jej w ręce zewnętrznych specjalistów, jeśli wszystko inne już sami obsługujecie.
Kiedy potrzebny jest inżynier sieci?
Teraz będziemy mówić o nowoczesnych firmach produktowych. Z operatorami i przedsiębiorstwami wszystko jest mniej więcej jasne — niewiele się zmieniło w ciągu ostatnich lat, a inżynierowie sieci byli potrzebni wcześniej, są potrzebni i teraz. Inaczej jednak sprawa ma się z tymi "młodymi i śmiałymi" — często całkowicie umieszczają swoją infrastrukturę w chmurach, więc nawet administratorzy nie są im specjalnie potrzebni — poza administratorami tych chmur, oczywiście. Infrastruktura z jednej strony jest dość prosta w budowie, a z drugiej — dobrze zautomatyzowana (ansible/puppet, terraform, ci/cd… wiecie, o co chodzi). Ale nawet tutaj zdarzają się sytuacje, w których inżynier sieci jest niezbędny.
Przykład 1, klasyczny
Załóżmy, że firma zaczyna od jednego serwera z publicznym adresem IP, który znajduje się w centrum danych. Potem serwerów przybywa, aż w końcu pojawia się potrzeba stworzenia prywatnej sieci między serwerami. Ponieważ "zewnętrzny" ruch jest ograniczony zarówno pod względem przepustowości (na przykład nie więcej niż 100 Mbit/s), jak i objętości danych pobranych/wysłanych w miesiącu (różni hosterzy mają różne stawki, ale przepustowość do świata zewnętrznego jest zazwyczaj znacznie droższa niż prywatnej sieci).
Host dodaje do serwerów dodatkowe karty sieciowe i łączy je z własnymi przełącznikami w osobnym VLANie. Powstaje "płaska" lokalna sieć. Wygodne!
Liczba serwerów rośnie, podobnie jak ruch w prywatnej sieci — kopie zapasowe, replikacje itp. Hostingodawca oferuje przeniesienie do oddzielnych przełączników, aby nie przeszkadzać innym klientom, a oni nie przeszkadzali wam. Hostingodawca ustawia jakiekolwiek przełączniki i w jakiś sposób je konfiguruje — najprawdopodobniej zostawiając pomiędzy wszystkimi waszymi serwerami jedną płaską sieć. Wszystko działa dobrze, ale w pewnym momencie zaczynają się problemy: okresowo wzrastają opóźnienia między hostami, w logach pojawiają się błędy zbyt dużej liczby pakietów ARP na sekundę, a pentester podczas audytu uzyskał dostęp do całej waszej lokalnej sieci, łamiąc tylko jeden serwer.
Co należy zrobić?
Podzielić sieć na segmenty — VLAN-y. Skonfigurować w każdym VLAN-ie własną adresację, przydzielić bramę, która będzie przełączać ruch między sieciami. Na bramie skonfigurować ACL, aby ograniczyć dostęp między segmentami, lub w ogóle postawić obok oddzielny firewall.
Przykład 1, kontynuacja
Serwery są podłączone do lokalnej sieci jednym przewodem. Przełączniki w szafach jakoś są ze sobą połączone, ale w przypadku awarii w jednej szafie odpadają jeszcze trzy sąsiednie. Schematy istnieją, ale co do ich aktualności są wątpliwości. Każdy serwer ma swój publiczny adres, który jest przydzielany przez hostingodawcę i powiązany z szafą. To znaczy, że podczas przenoszenia serwera trzeba zmieniać adres.
Co należy zrobić?
Podłączyć serwery za pomocą LAG (Link Aggregation Group) dwoma przewodami do przełączników w szafie (też trzeba je zarezerwować). Połączenia między szafami zarezerwować, przekształcić w "gwiazdę" (lub modne obecnie CLOS), aby awaria jednej szafy nie wpływała na inne. Wyznaczyć "centralne" szafy, w których będzie zlokalizowane jądro sieciowe, i do których będą podłączane inne szafy. Przy okazji uporządkować adresację publiczną, wziąć od hostingodawcy (lub od RIR, jeśli jest taka możliwość) podsieć, którą samodzielnie (lub przez hostingodawcę) ogłosić światu.
Czy to wszystko może zrobić "zwykły" administrator systemu, nie mający głębokiej wiedzy o sieciach? Nie jestem pewien. Czy to zrobi hostingodawca? Może i zrobi, ale będzie wymagana dość szczegółowa specyfikacja, którą też trzeba będzie komuś przygotować, a potem kontrolować, czy wszystko zostało zrobione poprawnie.
Przykład 2. Chmura
Załóżmy, że masz VPC w jakiejś publicznej chmurze. Aby uzyskać dostęp z biura lub on-premise części infrastruktury do sieci lokalnej wewnątrz VPC, musisz skonfigurować połączenie przez IPSec lub dedykowany kanał. Z jednej strony – IPSec jest tańszy, ponieważ nie trzeba kupować dodatkowego sprzętu, można skonfigurować tunel między swoim serwerem z publicznym adresem a chmurą. Ale – opóźnienia, ograniczona wydajność (ponieważ kanał wymaga szyfrowania), plus brak gwarancji łączności (ponieważ dostęp odbywa się przez zwykły internet).
Co należy zrobić?
Zorganizuj połączenie przez dedykowany kanał (na przykład w AWS nazywa się to Direct Connect). W tym celu znajdź partnera operatora, który cię podłączy, określ najbliższy punkt włączenia (zarówno do operatora, jak i do chmury), a na końcu wszystko skonfiguruj. Czy można to zrobić bez inżyniera sieci? Na pewno, tak. Ale jak to zdiagnozować w przypadku problemów bez niego – to już nie jest takie oczywiste.
Możliwe są również problemy z dostępnością między chmurami (jeśli masz wiele chmur) lub problemy z opóźnieniami między różnymi regionami itd. Niewątpliwie pojawiło się wiele narzędzi, które zwiększają przejrzystość tego, co się dzieje w chmurze (to samo Thousand Eyes), ale są to narzędzia inżyniera sieciowego, a nie jego zamiana.
Mógłbym podać jeszcze dziesiątki takich przykładów z mojej praktyki, ale myślę, że rozumiesz, że w zespole, zaczynając od pewnego poziomu rozwoju infrastruktury, powinien być ktoś (a lepiej więcej niż jedna osoba), kto wie, jak działa sieć, może skonfigurować sprzęt sieciowy i zrozumieć problemy, jeśli się pojawią. Wierz mi, będzie miał co robić.
Czego powinien wiedzieć inżynier sieciowy?
Nie jest wcale konieczne (a nawet czasami szkodliwe), aby inżynier sieciowy zajmował się tylko siecią i niczym więcej. Nawet jeśli nie brać pod uwagę opcji z infrastrukturą, która prawie w całości znajduje się w publicznej chmurze (a staje się ona coraz bardziej popularna), i wziąć na przykład środowiska on-premise lub prywatne chmury, gdzie tylko "wiedza na poziomie CCNP" może nie wystarczyć.
Oprócz samych sieci – chociaż tu jest nieskończone pole do nauki, nawet jeśli skoncentrujesz się tylko na jednym kierunku (sieci dostawców, enterprise, centra danych, wifi…)
Oczywiście, wielu z was przypomni sobie o Pythonie i innej «automatyzacji sieci», ale to tylko warunek konieczny, a nie wystarczający. Aby inżynier sieciowy „pomyślnie włączył się do zespołu”, musi być w stanie rozmawiać w tym samym języku zarówno z programistami, jak i z kolegami administratorami/devopsami. Co to oznacza?
- Umieć nie tylko pracować w Linuxie jako użytkownik, ale także go administrując, przynajmniej na poziomie juniora sysadmina: zainstalować potrzebne oprogramowanie, zrestartować usuniętą usługę, napisać prosty systemd-unit.
- Rozumieć (chociażby w ogólnym zarysie), jak działa stos sieciowy w Linuxie, jak zorganizowana jest sieć w hipernadzorcach i kontenerach (lxc / docker / kubernetes).
- Oczywiście, umieć pracować z ansible/chef/puppet lub innym systemem SCM.
- Osobny akapit należy poświęcić SDN i sieciom dla prywatnych chmur (na przykład TungstenFabric lub OpenvSwitch). To kolejny ogromny obszar wiedzy.
Krótko mówiąc, opisałem typowego specjalistę T-shape (jak to teraz modne się mówi). Wydaje się, że nie ma nic nowego, jednak z doświadczenia rozmów kwalifikacyjnych nie wszyscy inżynierowie sieciowi mogą się pochwalić wiedzą przynajmniej w dwóch tematach z powyższej listy. W praktyce brak wiedzy „w pokrewnych dziedzinach” bardzo utrudnia nie tylko komunikację z kolegami, ale także zrozumienie wymagań, jakie biznes stawia przed siecią jako najniższym poziomem infrastruktury projektu. A bez tego zrozumienia staje się trudniej argumentować swoje zdanie i „sprzedawać” je biznesowi.
Z drugiej strony, ta sama tendencja „do zrozumienia, jak działa system” daje inżynierom sieciowym bardzo dużą przewagę nad różnymi „specjalistami szerokiego profilu”, którzy wiedzą o technologiach z artykułów na Habrze/Medium i czatach w Telegramie, ale wcale nie mają pojęcia, na jakich zasadach działa dane oprogramowanie. A znajomość kilku regularności, jak wiadomo, skutecznie zastępuje znajomość wielu faktów.
Wnioski, czyli po prostu TL;DR
- Administrator sieciowy (podobnie jak DBA czy inżynier VoIP) to specjalista o wąskim profilu (w przeciwieństwie do administratorów systemów/devopsów/SRE), którego zapotrzebowanie nie pojawia się od razu (i w zasadzie może się nie pojawić przez długi czas). Jednak gdy już się pojawi, to z pewnością nie da się go zastąpić wiedzą zewnętrzną (outsourcing czy zwykli administratorzy o szerokim profilu, „którzy także zajmują się siecią”). Co jest dość smutne — zapotrzebowanie na takich specjalistów jest małe, a w firmie zatrudniającej 800 programistów i 30 devopsów/administratorów mogą być tylko dwaj administratorzy sieci, którzy świetnie wywiązują się ze swoich obowiązków. Tzn. rynek był i jest bardzo, bardzo mały, a jeśli chodzi o wysokie wynagrodzenia — jeszcze mniejszy.
- Z drugiej strony, dobry administrator sieci w dzisiejszym świecie musi znać nie tylko same sieci (i jak zautomatyzować ich konfigurację), ale także, jak współdziałają z nimi systemy operacyjne i oprogramowanie, które działają na tych sieciach. Bez tego będzie niezwykle trudno zrozumieć, czego oczekują od ciebie koledzy i w sposób uzasadniony przedstawić im swoje życzenia/wymagania.
- Nie ma chmury, to tylko komputer kogoś innego. Należy zrozumieć, że korzystanie z publicznych/prywatnych chmur lub usług dostawców hostingu „którzy załatwiają wszystko za Ciebie” nie zmienia faktu, że twoja aplikacja nadal korzysta z sieci, a problemy z nią będą miały wpływ na działanie twojej aplikacji. Twój wybór — gdzie będzie znajdować się centrum kompetencji odpowiedzialne za sieć twojego projektu.
Źródło: habr.com
