Automatyzacja sieci – droga od network engineer’a do netdevops’a

Damian Michalak
Damian Michalak Komentarze: 8

Jest rok 2018. W nowoczesnej firmie z branży sieciowej spotykamy na co dzień Network Engineer’ów i System Admin’ów. W nieco bardziej podążających za trendami korporacjach natkniemy się tu i ówdzie na DevOps’ów. Ewolucja jednak na tym nie poprzestaje i od jakiegoś już czasu możemy się również spotkać z takim stanowiskiem jak NetDevOps. Kim jest ten byt sieciowy wyższego poziomu? Czym się zajmuje? Czy jest on potrzebny? I w końcu – jak się nim stać?

System Admin, który dowozi, Network Engineer, który opóźnia

Zanim porozmawiamy o NetDevOps’ach to rozejrzyjmy się na chwilę dookoła. Dzisiejsza codzienność System Admin’ów wygląda tak, że za pomocą kilku kilknięć mogą oni stawiać od zera nowe serwery, migrować już istniejące i zwalniać używane zasoby w przeciągu zaledwie sekund. Ekspansja VMware na rynku i upowszechnienie się wirtualizacji na zawsze odmieniły oblicze pracy tej grupy inżynierów. Tymczasem do dziś powszechne jest w naszym małym sieciowym światku konfigurowanie urządzeń za pomocą CLI, edytowanie konfiguracji w Notatniku i jego pochodnych (o zgrozo!) oraz ręczne „stawianie” nie tylko nowych urządzeń, ale i całych sieci. Podczas gdy wiele zadań System Admin’ów uległo skróceniu z tygodni do dni (a nawet godzin), Network Engineer’owie pozostają nadal jednym z najwolniejszych trybów w konstrukcji systemów IT.

Powolny i mozolny proces projektowania sieci, a następnie okres wdrożeniowy potrafią się ciągnąć tygodniami. Pytanie, które się nasuwa, jest następujące: dlaczego nasza praca (inżynierów sieci) jest tak nieefektywna? I co ważniejsze – co możemy zrobić aby poprawić ten stan rzeczy? Odpowiedzmy sobie na te pytania.

Dlaczego praca sieciowca jest nieefektywna?

Nie jest to oczywiście reguła, ale spójrzmy prawdzie w oczy – większość sieciowców wykonuje na co dzień bardzo powtarzalną i szablonową pracę. Sprowadza się ona do godzin spędzonych w konsoli (CLI). Jeśli rozpatrujemy przypadek ludzi pracujących stricte w Operations to będą to głównie komendy służące do troubleshootingu. W przypadku osób zajmujących się projektowaniem i wdrażaniem sieci praca będzie nieco bardziej urozmaicona. Trzeba będzie stworzyć kilka dokumetów takich jak LLD, HLD czy BoM, narysować kilka diagramów w Visio, a następnie skonfigurować urządzenia, co w większości wypadków znów sprowadzi się do mozolnego klepania w CLI. Zauważmy, że wymienione przed chwilą zadania składają się bardzo często z bardzo powtarzalnych czynności!

Praca sieciowca “tradycyjnego” jest nieefektywa, ponieważ składa się z manualnego wykonywania powtarzalnych czynności. Co więcej – manualna praca jest podatna na błędy, a to powoduje często jeszcze większe opóźnienia w dostarczaniu gotowych rozwiązań. System Admini mają ten problem już dawno za sobą – są w posiadaniu NARZĘDZI oraz TECHNOLOGII rozwiązujących te problemy.

Co możemy zrobić, aby nasza praca była bardziej efektywna?

Jeszcze kilka lat temu odpowiedź sprowadzałaby się do stworzenia właśnie NARZĘDZI i TECHNOLOGII, które pozwalałyby nam automatyzować powtarzalne zadania i wykryć błędy już na wczesnym etapie implementacji. Tymczasem NIESPODZIANKA! Porzebne nam narzędzia i technologie już powstały i co więcej – są w coraz to powszechniejszym użyciu. Co możemy zatem zrobić, aby nasza praca była bardziej efektywna?

Odpowiedź jest prosta – nauczyć się ich.

Łatwiej jednak powiedzieć, niż zrobić – przygotuj się na to, że w wielu aspektach trzeba będzie przeskoczyć na wyższy poziom abstrakcji. Nic się jednak nie martw – taka jest naturalna kolej rzeczy. Kiedyś powszechne było pisanie programów w Assemblerze, dziś natomiast posługujemy się wysokopoziomowymi językami programowania, które sprawiają, że pisanie programu przypomina znacznie bardziej konwersację z komputerem, niż ciąg niezrozumiałych instrukcji. Jest to wyższy poziom abstrakcji w czystej postaci. Dobrze znać fundamenty, które pozwoliły nam stworzyć takie formy obcowania z technologią. Codzienna praca sieciowca, CLI, konfigurowanie pojedynczych urządzeń – to wszystko to wspomniane fundamenty. Czas przejść na wyższy poziom abstrakcji.

NetDevOps – byt doskonały i remedium na wszystko

W dzisiejszych firmach powszechny jest już widok DevOps’ów, czyli takich System Admin’ów na sterydach. Są to ludzie łączący w sobie nie tylko zaawansowane umiejętnosci wchodzące w portfolio System Admin’ów, ale również umiejętności programistyczne wraz z całym otaczającym warsztatem narzędziowym programisty. Połącznie tych dwóch niegdyś niezależnych bytów doprowadziło nas do powstania superorganizmów zwanych DevOps’ami.

Dobry DevOps wart jest każdych pieniędzy.

Masz znajomego System Admin’a, którego od zawsze podziwiałeś z tego jak efektywna jest jego praca? Dobry DevOps wykona te same zadania wielokrotnie szybciej, w wielokrotnie większej skali i popełniając przy tym o wiele mniej błędów. I jak tu nie kochać DevOps’ów?

Podobnie ma się sprawa z NetDevOps’ami.

Zaprzęgając do pracy języki programowania oraz zaawansowane narzędzia automatyzujące pracę wchodzimy na wyższy poziom abstrakcji. I nagle nie mamy już do czynienia ze zwykłymi Network Engineer’ami. Tutaj rozmawiamy już o NetDevOps’ach.

Dlaczego jest zapotrzebowanie na NetDevOps’ów?

Zapotrzebowanie na NetDevOps’ów wynika przede wszystkim ze wspomnianego na wstępie faktu, że większość opóźnień w implementacji złożonych systemów IT jest spowodowana przez sieciowców. Serwery, systemy operacyjne, całe środowiska aplikacyjne, a nawet fizyczny sprzęt – to wszystko może być już dzisiaj dostarczane na dniach. Natomiast backbone łączący te wszystkie elementy – czyli sieć, bardzo często wymaga wielokrotnie więcej czasu.

Kto by nie chciał zatem skorzystać z usług NetDevOps’a?

A najlepiej NetDevOps’a!

Spójrzmy prawdzie w oczy. Umiejętności NetDevOps’a są już teraz bardzo potrzebne na rynku, a będą rozchwytywane jeszcze bardziej z uwagi na kluczowy dla biznesu czynnik – oszczędność pieniędzy (dzięki możliwości szybszego i bardziej elastycznego tworzenia sieci oraz troubleshoot’owania występujących w niej problemów).

Jak zostać NetDevOps’em? Przegląd technologii.

Wiemy już, że jeśli nie przejdziemy transformacji z Network Engineer’a na NetDevOps’a to czeka nas nieunikniona zagłada, głód i pożoga. No, może nie będzie aż tak źle, ale z pewnością postępująca automatyzacja i grono Tych Którym Się Chciało będą podgryzały nasze ciepłe posadki i będą z politowaniem patrzeć na to jak wklejamy w CLI kolejną linijkę konfiguracji skopiowanej z Notatnika.

Jak zatem nie dać się ograć i zostać NetDevOps’em? Należy się nauczyć kilku nowych NARZĘDZITECHNOLOGII:

  • Sieci i kontrolery SDN – jeśli chcesz się dowiedzieć czym są i jak działają, przeczytaj mój wcześniejszy artykuł na ten temat. Generalnie rzecz biorąc powinieneś się orientować w tym jakie rozwiązania SDN są dostępne na rynku, jakie są ich możliwości i jakich umiejętności wymagają one, aby je obsługiwać.
  • VXLAN – technologia ta jest podwaliną działania nowoczesnych sieci SDN, z Cisco ACI na czele.
  • Programowanie w Pythonie oraz posługiwanie się systemem wersjonowania takim jak np. Git – bez programowania się nie obędzie, zwłaszcza jeśli chcemy pracować zgodnie z metodyką Infrastructure as a Code. Python jako język programowania posłuży nam w tym wypadku jako spoiwo do kolejnych komponentów.
  • Struktury danych JSON, YAML oraz XML – pracując jako NetDevOps odejdziemy już od posługiwania się konfiguracją w CLI. Zamiast tego konfigurację urządzeń różnego typu będziemy przedstawiali za pomocą jednej, wspólnej struktury zapisu.
  • Modele NETCONF, REST oraz RESTCONF – czyli API pozwalające na uzyskiwanie dostępu do konfiguracji urządzeń w ustrukturyzowanej formie. Warto jest znać kilka z nich albowiem nie każde urządzenie będzie wspierało np. NETCONF czy REST.
  • Linux – podstawy obsługi systemów z rodziny Linux będą niezbędne, gdyż wiele narzędzi będziemy uruchamiać właśnie tam.
  • Ansible – narzędzie pozwalające nam w wygodny sposób automatyzować powtarzalne zadania. Do użytkowania Ansible przyda nam się Python, a sam Ansible będzie generował konfigurację zapisywalną w strukturach JSON/XML, które następnie będą mogły być transportowane do urządzeń za pomocą ich API (NETCONF itd.). Poza Ansible warto jest się jeszcze przyjrzeć Chef’owi i Puppet’owi
  • Jenkins – kolejne narzędzie do automatyzowania deployment’u kodu.

Jeśli chcesz pójść krok dalej to warte uwagi są:

  • Konteneryzacja – Docker oraz Kubernetes
  • Rozwiązania oparte o Chmurę – w tym przypadku należałoby się zapoznać z podstawami Amazon Web Services, Microsoft Azure oraz Google Cloud Platform

Nie chcę nikogo zniechęcać, ale to zaledwie czubek góry lodowej! Poznanie tych wszystkich technologii z pewnością zajmie wiele czasu, ale będzie też doskonałą inwestycją w przyszłość.

Komentarze: 8
Otrzymuj powiadomienia z tej dyskusji
Powiadom mnie o
guest

8 - Ilość komentarzy
Sortuj wg najlepszych
Sortuj wg najnowszych Sortuj wg najstarszych
Inline Feedbacks
View all comments
Paweł Zaręba
Paweł Zaręba
5 lat temu

Mnie też się art podoba. Cieszmy się, że jesteśmy akurat w miejscu w którym następuje transformacja. Jest to okazja ażeby uczyć się czegoś nowego. Dodatkowo jeśli automatyzacja wejdzie w pełni to taki inżynier sieciowy będzie mógł pracować bardziej kreatywnie pisząc kod. Ja widzę same plusy 🙂

Rafał Rudewicz
Rafał Rudewicz
5 lat temu

Artykuł jak zwykle świetny, przyjemnie się go czyta. Automatyzacja to przyszłość której nie unikniemy i nie ukrywajmy klepanie kodu z notatnika jest nuuudne i bardzo łatwo o błędy. Pod tym względem statystyka jest bezwględna i niestety maszyny sa lepsze. One się nie myla, ale dlaczego by nie mialy robić co im każemy w sposób prostszy, łatwiejszy i szybszy.

Paweł
Paweł
4 lat temu

Przeglądając oferty pracy w zawodzie inżyniera sieciowego oprócz \”mile widzianej\” znajomości programowania w języku skryptowym (bash, python) coraz częściej widzę już tą umiejętność jako WYMAGANĄ. Prócz tego nawet CISCO dodało do swojej ścieżki certyfikującej opcje DEV\’NETU, to pokazuje jak bardzo automatyzacja jest teraz na topie.

Łukasz
Łukasz
4 lat temu

W ISP jest zdecydowanie mniej powtarzalności, bo każda sieć jest inna. Z racji tego, że tam budżety są skromniejsze to jest totalny misz-masz vendorów przez co praca nawet bym powiedział, że jest ciekawsza. Mamy przekrój sprzętu od SOHO po enterprise w najróżniejszym wykonaniu. Co nie zmienia faktu, że automatyzacja już i tam przyszła i chcąc nie chcąc musimy się tego nauczyć 🙂 Przyznaje, że mając obok siebie programistę w zespole, dość leniwie do tego podchodzę ale chyba nie ucieknę od tego… 🙂

Ilona
Ilona
4 lat temu

Cześć!
Moglibyście napisać coś więcej odnośnie ścieżki certyfikacji NetDevOps? Widzę, że w Cisco networking Academy ta ścieżka jest wprowadzona od jesieni. Mam poważny dylemat czy iść w CCNA czy NetDevOps. Mam wrażenie, że ten temat jest traktowany trochę po macoszemu na stronach tematycznych, a chętnie poczytałabym opinię ludzi takich jak Wy. Tu mam jednak lekki niedosyt informacyjny, a w artykule o rewolucji w certyfikacji odsyłacie właśnie tu. Zdaję sobie sprawę, że specjalizujecie się w czymś innym, ale może się coś uda? Małe oczko na zachętę 😉.

Adrianna
Adrianna
4 lat temu

A jaka jest pełna nazwa zawodu netdevops