Dlaczego powinniśmy automatyzować sieć?

To, że świat IT wkroczył w erę „programowalności” wszystkiego jest faktem i nie trzeba się już na ten temat za bardzo rozwodzić. Wiemy też, że programowanie zaczęło już przenikać do sieci. Proces ten jest niestety dość powolny, szczególnie w naszych polskich realiach. Wiele zespołów sieciowych wciąż się przed tym wzbrania. Wynika to przeważnie z dwóch faktów. Po pierwsze, administratorzy wciąż obawiają się o swoje stanowiska. Tak, tak, po wielu latach wciąż słyszę, że automatyzacja doprowadzi do redukcji personelu. Po drugie, wciąż boimy się automatyzować sieć, bo jest ona bazą dla wszystkich usług. Jak coś zepsujemy to wszystko przestaje działać. A ta obawa jest efektem błędnego przekonania, że musimy od razu zacząć automatyzować wszystko, wliczając sieć szkieletową.

Przed automatyzacją nie uciekniemy – wiem, jest to już nudny slogan :-). Pozwól zatem, że podsumuję Ci w pięciu krótkich punktach, dlaczego (moim subiektywnym zdaniem) powinniśmy zacząć w końcu programować i automatyzować sieci.

Kontrola nad konfiguracją

Konfiguracja urządzeń sieciowych bazowała do tej pory na ręcznym definiowaniu wpisów przez interfejs CLI. W najlepszym przypadku, definiowaliśmy sobie wcześniej konfigurację w pliku tekstowym lub Excelu i wklejaliśmy ją w całości na urządzenia. Proces ten jednak rzadko był poprzedzony jakąś analizą i weryfikacją. Czasami zdarzało się, że konfiguracja była generowana jakimś automatem. Najczęściej jednak było to kopiowanie innych, podobnych kawałków konfiguracji, po czym modyfikowane były ich wybrane składowe. Najgorsze jednak były konfiguracje ad-hoc, jak trzeba było coś na szybko dodać, zmienić czy usunąć awarię. Problem w tym, że zazwyczaj wytyczne dla wszystkich tych konfiguracji pochodziły z losowych źródeł (często z głowy administratora).

Zmieniając nasze podejście do konfiguracji sieci poprzez jej programowanie, mamy możliwość nie tylko usprawnienia procesu konfiguracji, ale też jej ujednolicenia. Możemy to osiągnąć dzięki wspólnym narzędziom devops’owym, z których od lat korzystają programiści. Bardzo przydatny jest tu model zapisu danych YAML. Niezależnie od tego, czy konfigurujemy naszą sieć za pomocą skryptów w Pythonie czy narzędzi takich jak Absible, możemy opisać nasze usługi w jednym miejscu, w sposób spójny i ustrukturyzowany, a jednocześnie czytelny. Dzięki temu, nasza konfiguracja będzie zawsze bazowała na tych samych parametrach (Single Source of Truth). Oczywiście, najlepszym rozwiązaniem jest posiadanie centralnej, relacyjnej bazy danych (CMDB), ale w wielu przypadkach jej stworzenie jest procesem mozolnym i dość skomplikowanym. Zacznijmy od rzeczy prostych i łatwo dostępnych :-). Najpierw odzyskajmy pełną kontrolę (i wiedzę) nad tym jak nasza sieć funkcjonuje, a później ten proces usprawniajmy.

Czas implementacji

Powtarzałem to wielokrotnie i będę powtarzał do znudzenia, administratorzy będą zwalniani za niedostarczanie usług na czas, a nie za programowanie sieci. Oczywiście, czas implementacji usług jest bardzo ważny z punktu widzenia Biznesu, ale spójrzmy też na to od strony administratora sieci. Jeżeli mamy niewielką sieć, złożoną z kilku urządzeń, to może nie będzie to tak istotne, ale w dużych korporacjach czy u operatorów telekomunikacyjnych ilość urządzeń jest przytłaczająca. Zmiany, jakie wprowadzamy, mogą być związane z nową usługą, ale też często są to zmiany typowo operacyjne. Naprawdę chcemy przez kilka kolejnych godzin wklepywać mozolnie jedno i to samo polecenie? Jak jest to samo to pół biedy, gorzej, jak na każdym urządzeniu musimy podać unikalny parametr.

Czas jest czymś czego nie wydłużymy, nie zatrzymamy ani nie kupimy. Programowanie i automatyzacja jest jedynym kierunkiem, dzięki któremu możemy ten czas wykorzystać bardziej efektywnie. Nie, nie możemy zaoszczędzić czasu, bo czas się nie buforuje, ale możemy wykonać zadania w krótszym czasie, dając sobie przestrzeń do rozwijania swoich kompetencji i optymalizacji innych zadań.

Oczekiwania Biznesu

Oczekiwania Biznesu są jasne. Wprowadzanie usługi (lub jej zmian) na rynek ma być jak najszybsze (czytaj natychmiastowe). Czasy, w których Biznes cierpliwie czekał kilka godzin lub nawet dni na nowy VLAN minęły bezpowrotnie. Możemy się zapierać rękami i nogami przed idącymi zmianami, możemy nie lubić programowania, automatyzacji czy narzędzi, które są popularyzowane, ale Biznesu to za bardzo nie interesuje. Biznes do nas przyjdzie i powie wprost „ja to chcę, bo inni też to mają” (tak, wiem, że czasami takie decyzje są bezpodstawne, ale nie zawsze możemy z nimi dyskutować). Pamiętajmy, że automatyzujemy Biznes, a sieć jest tylko jednym ze składowych tej automatyzacji.

Permanentny rozwój

Automatyzacja sieci nie dzieje się z dnia na dzień. Jest to proces, nad którym trzeba się pochylić i trochę napracować. Ale jest to praca niesamowicie kreatywna i wspierająca innowacyjność. Świat IT zmienia się od zawsze. Kiedyś mieliśmy centralki analogowe, teraz mamy telefonię IP. Kiedyś mieliśmy Frame-Relay i ATM, teraz mamy MPLS. Zawsze będzie coś nowego do nauki. Co za różnica czy uczymy się nowej technologii czy programowania? Wiem, wielu administratorów czuje wstręt do pisania kodu, ale może to wynikać głównie z faktu, że programowanie postrzegamy jako nudne pisanie jakieś aplikacji księgowej czy nowego CRMa. Programowanie sieci wygląda zupełnie inaczej i nie, nie jest nudne :-). Skoro uczymy się jak działa protokół BGP, jaki jest algorytm nawiązywania sąsiedztw, wymiany tras i w jakiej kolejności mamy wpisywać poszczególne polecenia to jaki jest problem nauczyć się pętli, struktur danych i algorytmów w Pythonie? Jeżeli nie będziemy się rozwijali to wypadniemy z obiegu.

Certyfikacja

Certyfikacja w IT zawsze była tematem dość kontrowersyjnym. Dla wielu jest ona niepotrzebnym dodatkiem i mało miarodajnym wskaźnikiem wiedzy. Z jednej strony jest w tym trochę racji. Pewnie dlatego, że na rynku jest masa różnego rodzaju „dumpów”, dzięki którym niektórzy wybierają drogę na skróty (jedno pytanie na rozmowie rekrutacyjnej weryfikuje to bardzo szybko). A to znowu napędzane jest przez błędne przekonanie, że jak się ma tylko certyfikaty, to się zarabia więcej 🙂 Kiedyś może i tak było, ale te czasy minęły. Teraz liczy się solidna wiedza i doświadczenie, ale przede wszystkim chęć rozwoju, otwartość na nowe technologie i innowacyjność.

Czy to oznacza, że certyfikacja jest nieistotna? Nic bardziej mylnego. Oczywiście, jako papier, największą wartość daje różnego rodzaju partnerom. Ale, jako stawiany sobie cel, stanowi niesamowicie skuteczny oręż w pozyskiwaniu wiedzy i budowaniu swojej marki. Filozoficznie, cel nadaje sens naszym poczynaniom. Technicznie, jeżeli czegoś nie mierzymy to tym nie zarządzamy. Egzamin/certyfikat jest pewną formą pomiaru (abstrahując od podejścia dumpowców). Rozwojowo, certyfikat może być elementem grywalizacji, przez co osiąganie celów jest dużo łatwiejsze.

Co certyfikacja ma wspólnego z automatyzacją sieci? Jak w każdym innym przypadku, pozwala nam w sposób ustrukturyzowany zdobyć pewien zakres wymaganej wiedzy (wiem, to nauka daje nam wiedzę, a nie certyfikat, ale certyfikat pozwala nam łatwiej tą wiedzą zarządzać – temat na dłuższy artykuł, może kiedyś popełnię :-)). To, jak bardzo automatyzacja sieci staje się powszechna i istotna, pokazało ostatnio Cisco, wprowadzając na rynek nową ścieżkę certyfikacyjną DevNet. Pojawiło się też przy okazji dużo bardzo istotnych zmian w istniejących certyfikatach, które bardzo fajnie opisał Damian na swoim blogu.

Podsumowanie

Wciąż zastanawiasz się czy zacząć przygodę z automatyzacją sieci? Na zastanawianie się nie ma już czasu 🙂 Decyzja powinna być oczywista. Teraz jest już czas na działanie. Jak zacząć? Jakich narzędzi używać? Jak współpracować z innymi działami? Będziemy o tym wszystkim pisali. Zapraszam do śledzenia bloga.

Podziel się z innymi:
Email this to someone
email
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin

Dodaj komentarz

fifteen − 5 =