Od Admina do DevOpsa: wskazówki i rady

16 września
Heber Benitez
Od Admina do DevOpsa: wskazówki i rady
Według definicji DevOps to zestaw praktyk, procesów i narzędzi do tworzenia software’u, które łączą tworzenie oprogramowania (Dev) i eksploatację usług IT (Ops). Ale osobiście uważam, że jest to ruch kulturowy, który ma na celu tchnięcie nowego życia w rozwój, testowanie i wdrażanie oprogramowania. W artykule opisuję doświadczenia, które przytrafiły mi się podczas zmiany kwalifikacji. Pierwszą część tekstu, w której zawarta jest garść wskazówek dotyczących umiejętności, które warto rozwijać, znajdziecie na blogu NoFluffJobs.

Moje zawodowe początki

Swój pierwszy komputer dostałem, gdy miałem 14 lat. To był Commodore 64 i pierwszą rzeczą, którą pamiętam, było wrzeszczenie „LOAD”, ponieważ chciałem zagrać w grę z kasety. Kto by pomyślał, że ta chwila na zawsze zmieni bieg mojego życia? Po kilku miesiącach i licznych dyskusjach, moi rodzice zapisali mnie na kurs komputerowy. Po latach zacząłem studiować inżynierię systemów na uniwersytecie. Po jakimś czasie poznałem Windows 95, z SuSE Linux - kiedy był darmowy - i wreszcie Internet!

Kiedy skończyłem 19 lat, zacząłem pracować w sektorze zupełnie niezwiązanym z programowaniem - zajmowałem się obróbką metali Skończyło się na projektowaniu konstrukcji dla instalacji wodno-kanalizacyjnych, później przeniosłem się do kontroli produkcji.

Sprzęt, systemy operacyjne, sieć i pamięć masowa.

Bez pracy nie ma kołaczy. W końcu trafiłem do branży IT jako administrator systemów. Właśnie tam zacząłem mówić o gniazdach, TCP IP - IPX… Tak, poznałem Novell Netware i dobrze znany katalog SYS - oraz skomputeryzowane przetwarzanie wsadowe, w ogromnym pudełku z napisem: „IBM AS 400”. Poproszono mnie o zapoznanie się z NT i certyfikację w zakresie czegoś, co nazywa się „Windows 2000”. Stworzyłem też skrypt (moje magiczne słowo!) dla użytkowników w LDAPv3. Dowiedziałem się, że mogę uzyskać dostęp do dowolnego komputera bez pozwolenia i co ważniejsze: każdy może uzyskać dostęp do mojego., w związku z czym podejmowanie środków bezpieczeństwa jest bardzo ważne.

Dowiedziałem się też, że mam znacznie więcej do zaoferowania i postanowiłem zmienić pracę (SPOILER ALERT: dokonałem wielu zmian w swoim życiu zawodowym, nawet teraz jestem w trakcie kolejnej rewolucji). I tak zaczęła się moja wielka zawodowa przygoda - mogłem zobaczyć hiperwizory i systemy rozproszone, serwery kasetowe, aktualizować sprzęt, użyć kabli UTP Cat 4 i 5, ustawić i skonfigurować SAN i NAS, ustawić poziomy RAID, klastry, balancery, serwery proxy i system inspekcji pakietów.  W końcu dowiedziałem się również, że w rozwoju oprogramowania wszystko musi być zaplanowane i skoordynowane i mam na myśli nie tylko usługi IT, ale także procesy i procedury, musi również  istnieć polityka określająca granice.

Zespół operacyjny vs. „ci faceci”

Jednym z moich pierwszych zadań jako SysAdmina, było zgłaszanie szefowi spraw dotyczących produkcji. Ponieważ mieliśmy system operacyjny Windows, użyłem VBS i strony internetowej o nazwie „Hey, Scripting Guy” i stworzyłem elegancki kod. Ale różniło się to od kodowania aplikacji i zacząłem się zastanawiać: jaka jest dokładnie różnica między zadaniami DevOps a skryptami, które tworzę? Do tego czasu jedyne, co wiedziałem to, że to programiści byli odpowiedzialni za wprowadzenie części problemu do środowiska operacyjnego. Innymi słowy: osoba, której powiesz „nie”, prawie domyślnie. Wszystko działa płynnie, dopóki programista nie pojawi się z nową aktualizacją aplikacji, która rozrywa na strzępy SLA, KPI i wszelkie inne wskaźniki. A co gorsza zawsze twierdzili, że jest to problem z infrastrukturą, więc spędziłbyś cały weekend ciężko pracując, i ostatecznie okazałoby się, że problem nie był twój - prawdziwy polegał na tym, że taka aktualizacja zajmowała zbyt dużo pamięci RAM.

Oczywiście administratorzy nie zostali pozostawieni w tyle - czasami zapominamy o skonfigurowaniu niektórych portów, a użytkownicy są zszokowani, gdy otrzymują komunikaty OLEDB.

Od ServerFault do StackOverflow

Moim kolejnym zadaniem było bezpośrednie wsparcie grupy programistów pracujących nad systemem ERP dla sieci aptek. To doświadczenie spowodowało, że diametralnie zmieniłem swój punkt widzenia. To byli „fajni” ludzie, z zupełnie innym podejściem do życia. Nie mówię, że było lepiej czy gorzej, po prostu inaczej, i to sprawiło, że zmieniłem sposób myślenia.

Nauczyłem się od nich wielu rzeczy. Na przykład, że programowanie to znacznie więcej niż tylko pisanie kodu. Oznacza zrozumienie wymagań biznesowych, kierowanie każdym wydaniem, zbieranie błędów - w razie potrzeby - a następnie testowanie, zajmowanie się maszynami wirtualnymi, wprowadzanie zmian w ostatniej chwili, ponieważ użytkownik zapomniał coś dodać, dotrzymywanie terminów nawet, kiedy w ostatniej chwili znajdziesz buga do naprawienia, radzenie sobie z SysAdminami, aby „pozwolili” ci dodać coś w swoim środowisku - oznacza to, że mówią „boimy się” przed wprowadzeniem aktualizacji do produkcji i krytykują twój kod (czyli twoje dziecko!) - i dużo pracy zespołowej.

Z technicznego punktu widzenia to doświadczenie wprowadziło mnie w GitLab i przyzwyczaiłem się do takich pojęć jak: zatwierdzanie, popychanie, meagering itp. Nauczyłem się używać MySQL, dowiedziałem się, że RFC dla protokołu HTTP jest tak złożona jak architektura katedry gotyckiej, a ponadto każda przeglądarka ma wiele do powiedzenia. Dowiedziałem się, że Amazon nie tylko sprzedaje książki i, że z metodologicznego punktu widzenia Agile jest tutaj, aby nas wszystkich uratować. A Docker to magia!

Gdzie są moje serwery?

Po osiągnięciu pewnego stopnia dojrzałości zacząłem pracować jako kierownik zespołu infrastruktury. To było wspaniałe doświadczenie. Zrealizowałem wiele celów i zwykle wszystko szło zgodnie z planem. Jednak, jak zawsze w życiu, wiele się zmienia.

Technologia rozwijała się ramię w ramię z globalizacją gospodarczą, a życie w sieci stawało się coraz ważniejsze. Aplikacje mobilne były najgorętszym trendem, pojawił się nowy problem - C10k, Internet cierpiał na wiele DDOS, a wszyscy mówili o CDN - a przynajmniej ja. Początkowo myślałem, że ten „świat zewnętrzny” - handel elektroniczny, prędkość, HTTP, www, równoważenie obciążenia L7, interfejsy API, telefony komórkowe itp. - bardzo różni się od mojego „świata wewnętrznego” - DHCP, sieci obwodowej, serwer SQL, klaster, użytkownicy, komputery stacjonarne i intranety.

Teraz wiem, że musiałem iść dalej i opuścić swoją strefę komfortu, chociaż naprawdę podobało mi się życie w moim czysto technicznym świecie. W mgnieniu oka zacząłem pracować jako DevOps. Bardzo dobrze znałem wszystkie filary infrastruktury IT, umiałem kodować, miałem doświadczenie w pracy w środowisku programistycznym, znałem zasady procesów, zabezpieczenia informacji i danych, wiedziałem, jak dostarczać solidne rozwiązania i wiele więcej. Jak można sobie wyobrazić, okazało się, że jest zupełnie inaczej. Pierwsza rzecz, jaka przyszła mi do głowy, brzmiała: „Gdzie są moje serwery? Gdzie jest inwentarz? I kopie? A potem było jeszcze gorzej: Smoke Testing? Endpoint? Architektura?

Było już za późno, kiedy zdałem sobie sprawę, że popełniłem ogromny błąd: w zależności od podejścia firmy, normalnym podejściem DevOps było CI, które było zupełnie innym światem! I mówię “normalne” zamiast „standardowe”, ponieważ czasami może to być podejście oparte na infrastrukturze chmury, na przykład: zezwolenie na port TCP/UDP, rekonfiguracja automatycznego skalowania lub naprawa błędów w konfiguracji. Innymi słowy, po prostu nie chcesz pracować z programistami. Z drugiej strony - miałem doświadczenie w pracy z mikrousługami, jednak nigdy nie pracowałem z metodologią Continuous Deployment. Dowiedziałem się, że regularne tworzenie mniejszych wersji oprogramowania jest lepsze niż mniej większych wdrożeń. Aby to osiągnąć, cały zespół powinien być dobrze wyszkolony; w końcu musimy się upewnić, że to wydarzenie nie wpłynie na produkcję, prawda?

Niektóre najważniejsze myśli z tamtego okresu:

  • Tagi wszędzie: mogę przypisać tagi do grup obiektów, a następnie łatwo się do nich odwoływać z innego systemu. Doskonale!
  • Przetwarzanie bezserwerowe i batchowe. Cudowne!
  • Infrastruktura jako kod. Nigdy nie lubiłem otwierać sprzętu i brudzić sobie rąk, dodając więcej pamięci. Piękne!

Pamiętam, jakby to było wczoraj, podczas mojej pierwszej rozmowy klient powiedział mi: „Po prostu zapisz artefakty w Artifactory”. Nie miałem pojęcia, o czym on mówi! Z pełną uwagą, a hiszpański był moim pierwszym językiem, starałem się zrozumieć znaczenie angielskiego słowa „artefakt”. Pokonawszy tę pierwszą podstawową barierę, próbowałem dowiedzieć się, gdzie są te artefakty i jakie procesy zostały utworzone. Kiedy znalazłem go w określonym katalogu w kontenerze Dockera - w GitLabie nazywa się „Runner” - otrzymałem URL. Nie wiedząc nawet, że adres URL różni się od Endpoint (znowu tylko pod względem programowania: REST vs NON-REST), skopiowałem go do paska adresu mojej ulubionej przeglądarki, czekając na żądanie logowania. Ale otrzymałem dane w formacie JSON z napisem: „Odmowa dostępu”. Błąd nowicjusza. Zajęło mi trochę czasu, zanim zrozumiałem, że taki dostęp był zapewniany tylko przez pipeline GitLab.

Inne zadania, które naprawdę mnie zszokowały, to:

  • Skrypty w YAML i HCL
  • Zrozumienie GO, IOS, a nawet Javy!
  • Tworzenie pipeline'u, nie wiedząc, jak każdy język współdziała z procesem testowania.
  • Zrozumienie całej infrastruktury opartej na Terraform nierozerwalnie połączonej z setkami oddziałów, przy niewielkiej wiedzy na temat GUI AWS
  • Tworzenie obwodu niezależnych zadań między Lambda, SNS, Slack i Datadog bez wiedzy, czym one są.

Muszę przyznać, że nieraz przychodziła mi do głowy stara dobra myśl: „To jest sprawa deweloperów, po prostu stwórz ticket”. Ale teraz to były moje zadania. Nagle znowu byłem na poziomie juniora.

Trochę kontrowersji

Otwieram ten wątek: droga do DevOps wydaje się łagodniejsza, kiedy startujesz z programowania. Dlaczego to mówię? Przede wszystkim dlatego, że programista prawdopodobnie już wie, co oznacza praca z pipeline. Na przykład: jak stworzyć skrypt. Pewnego dnia można się dowiedzieć, jak działa load balancer; następnego dnia o jego protokołach i RFC; trzeciego dnia - wprowadzić to w życie. Ale nie możesz tak szybko nauczyć się kodować.

Faza ciągłej integracji ma wiele wspólnych elementów z testowaniem oprogramowania i zapewnieniem jakości, które nie są częścią świata operacyjnego. W świecie, w którym większość usług jest związanych z Internetem, nie jest zaskoczeniem, że programista ma doświadczenie w usługach wysokiej dostępności lub usługach internetowych. Mogło to doprowadzić go do badań nad L4 i L7, automatycznym skalowaniem, monitorowaniem i stworzenia VPC i zanurzenia się w podsieciach.

Jeśli chodzi o systemy, nie jest zaskoczeniem, że programista współdziała z uprawnieniami systemu plików, użytkownikami, regułami zapory, a nawet poprzez Sysctl do jądra systemu operacyjnego.

Jeśli mówimy o chmurze, coraz więcej firm i startupów korzysta z tych usług. Na jego niższym poziomie możemy znaleźć IaaS, który pozwala zarządzać pamięcią masową, systemami komputerowymi, siecią itp., okablowaniem i stelażem serwera, wiedząc, że RAID i system chłodzenia nie są już ważne, liczba IOPS systemu pamięci masowej, którą muszę kupić nie jest już potrzebne i powinienem przestać martwić się ruchem BGP i szyfrowaniem danych w spoczynku. Wszystko czego potrzebujesz to wiersz kodu!

Jeśli chodzi o automatyzację, możemy powiedzieć, że 15-20 lat temu nie mogliśmy znaleźć szerokiej gamy narzędzi, jakie mamy dzisiaj: między innymi Chef, Puppet, Ansible. Możemy również znaleźć „serverless”. Na przykład: LAMP Serverless umożliwia wdrażanie kodu do produkcji bez martwienia się o wydajność, zarządzanie i planowanie konfiguracji, które nie są istotne dla firmy. Dlatego programista koncentruje się głównie na wynikach. Myślę, że w przyszłości to podejście będzie się nasilać, ale powinienem napisać o tym osobny artykuł.

Najbardziej kontrowersyjną kwestią są wszystkie umiejętności, których DevOps potrzebuje: programowanie/język poleceń; Go, Python, Java, PHP, C #, HTML, CSS, JavaScript; Kubernetes i Swarm; kontenery i usługi przetwarzania w chmurze, takie jak AWS, GCP, Azure; systemy zarządzania kodem, takie jak Github i CI, takie jak Gitlab; wdrożenia przy użyciu Ansible, Puppet lub Chef; Administracja Linux i Windows; równoważniki i klastry; buforowanie bazy danych; TCP, UPD, DNS, HTTP; Kryptografia SSL/TLS; bazy danych takie jak MySQL, MSSQL, MongoDB, Redis, Casandra, Aurora; Infrastruktura jako kod: Terraform lub Cloud Formation; narzędzia monitorujące, takie jak New Relic, Datadog, Nagios, Zabbix. Ponadto DevOps musi nauczyć się stale radzić sobie z ogromną ilością informacji. Wygląda na to, że jedna osoba jest odpowiedzialna za zadania całego działu czuwającego nad systemem!

Wnioski

Nie istnieje jedyna słuszna droga zawodowa - jest tyle możliwych ścieżek, ilu specjalistów. Każda osoba jest wyjątkowa, ma indywidualne cechy i dlatego uważam, że w grupie Ciągła Integracja, Ciągłe Dostarczanie i Ciągłe Wdrażanie brakuje czwartej koncepcji, która brzmiałaby: „Ciągłe Uczenie się”.

Wiem tylko, że proces uczenia się powinien być jak najbardziej agnostyczny, jednak czasami konieczne jest szczegółowe przestudiowanie konkretnego produktu i mentoring nowych współpracowników i myślę, że prowadzenie ich ścieżką oznacza dodawanie wartości do biznesu; niezbędna jest znajomość schematu przebiegu procesu, sieci i usług.

DevOps to metodologia, a nie praca. A przejście nie jest proste: czasami może być zbyt długa, kręta i pod górę. Kusi mnie, żeby opowiedzieć o miejscu, do którego trafia się po przejściu takiej drogi, wyobrażając sobie, że musi być piękne. Ale prawda jest taka, że nie wierzę, że istnieje coś takiego jak linia mety: zamiast tego naucz się cieszyć jazdą, która, podobnie jak nasza koncepcja wszechświata, jest nieskończona.