Jak zostałem DevOpsem

Jeśli miałeś podobnie jak ja, to wiesz, że było to trudne, ale duże postępy i wyjście ze strefy komfortu zawsze są trudne. Aby zrozumieć, dlaczego było mi ciężko, powinieneś poznać moje początki.


Pomijam 15 lat pracy w IT jako administrator systemów w miejscach takich, jak Lockheed Martin i Rząd Federalny. Posiadam kilkanaście certyfikatów, skończone studia i mnóstwo różnorodnych doświadczeń. Miej na uwadze, że było to administrowanie ręczne i trochę pisania skryptów. Byłem dobry w mojej pracy. Nie jakoś nadzwyczajnie, ale z pewnością byłem silnym opsowym facetem i uważałem siebie za tradycjonalistę.

Zapamiętaj ten wstęp…

Przeniosłem się do pracy, gdzie administrowałem ponad 500 wirtualnymi maszynami. Niesamowite. Zgłosiłem się na ochotnika do wzięcia udziału w zrobieniu ogromnej instalacji AWS w chmurze. Mogłem zapomnieć o farmie VMWare i EMC SAN i wszystkich innych nonsensach centrum danych. Wszystko tam dotyczyło chmury. Tak mało o tym wiedziałem, ale szybko zrozumiałem, że wszystkie zasady zaangażowania były zupełnie inne.

Jak przystało na doświadczonego admina, zacząłem budować w chmurze, w taki sam sposób, jak budowałem centra danych, ale to był zły sposób. Moje daremne wysiłki nie trwały długo, ponieważ kilka miesięcy po zakończeniu projektu nasz Project Manager powiedział:

„Wprowadzamy DevOps”. - Czym do **** jest DevOps?

Całkowicie to wyśmiałem. To tylko modne słowo i po prostu musiałem się z tym pogodzić i dokończyć ten projekt. W naszym zespole pracowało „tak jakby” kilku konsultantów. Jednym facetem, którego wynajęli, był szef - Craig. W większości wypadków nie miałem pojęcia, co robił. Popełniłem błąd, pytając go pewnego dnia, a on wyjaśnił, że buduje Gem Server, Berkshelf, Jenkins, Gitlab i serwer Chef… wszystko na Linuksie. Byłem tradycyjnie administratorem systemu Windows, więc po tym, jak mój mózg się roztopił, po prostu cofnąłem się, dosłownie.

Następnego tygodnia Craig próbował mi pokazać, jak dodać użytkownika do Cookbooka Chefa. Byłem tak sfrustrowany, widząc tyle Ruby i próbując zrozumieć, dlaczego zamierzaliśmy zbudować test, zanim napisaliśmy kod, aby stworzyć użytkownika. WTF, test? Przez cały czas myślałem o tym, że mogłem zrobić tego użytkownika w 10 sekund w GUI lub zmontować skrypt, który to zrobi. Kiedy Craig tłumaczył, jak możemy sprawdzić kod w repozytorium, mój umysł po prostu się wyłączył.

Przez całą sesję myślałem o następujących rzeczach (bez szczególnej kolejności):

To nie ma nic wspólnego z Windows.
Nie jestem programistą.
To dla mnie za trudne.
To nie ma znaczenia dla mojej pracy.

To był strach, prawdziwy strach. Powiedziałem sobie te rzeczy, ponieważ nie chciałem przyznać, że nie rozumiem wartości tego procesu i zlekceważyłem te umiejętności po prostu jako takie, które są poza moimi możliwościami i karierą. W tamtym momencie miałem całkowitą rację.

Miesiąc później pojawił się Justin. Był nowym jednorożcem DevOps rockstar (IT jest po prostu pełne takiego slangu). Justin znał AWS, Chefa, wszystko. Siedział tuż obok mnie. Otworzył swojego MacBooka (oczywiście, że nie peceta) i po godzinie wciągał tickety ze sprintu, pisał testy i pracował nad Cookbookami Chef. Byłem zszokowany. Zerknąłem na to, nad czym pracował kilka razy tego dnia. Skakał między ekranami terminala, commitował kod, symulował kompilacje na środowisku testowym. To wszystko w pierwszy dzień pracy.

Tego dnia mieliśmy demo. Craig miał nam pokazać, nad czym pracuje w Chef. Jego zadaniem było zautomatyzowanie od początku do końca jednej z naszych aplikacji do przetwarzania pożyczek (myślałem, że to będzie jak skrypt).

Na moich oczach działa się magia. Nacisnął przycisk na zadaniu Jenkinsa, kod automatyzacji był w gicie, uruchomiono instancję AWS EC2 i przetestowano kuchnię przez RSpec i Serverspec. Teraz, dla tych, którzy nie nadążają za tym, co to wszystko oznacza, zobaczyłem odpalenie zupełnie czystego serwera w chmurze, przeprowadzono dziesiątki testów w celu sprawdzenia kodu automatyzacji, a następnie przeprowadzono testy akceptacyjne, aby faktycznie skonfigurować skrzynkę i potwierdzić, że jest skonfigurowana poprawnie. Na tym nie koniec, przepis z Chefa wprowadził Elastic Load Balancer, stworzył certyfikat i użył go, a serwer umieścił za balanserem. Receptura stworzona w Chefie zrobiła wszystko.

Patrzyłem na to wszystko ze zdumieniem. Po zakończeniu walidacji serwer został zniszczony, a kod był „gotowy” do promocji w Chef. Teraz gdy uruchomiono nowy serwer przetwarzania pożyczek, będzie on automatycznie konfigurowany i gotowy do pracy - nie wymaga żadnych skryptów ani ręcznej interwencji.

W tamtym momencie zrozumiałem, że to koniec moich dni. Bolało.

Następnego dnia wszedł Justin i usiadł obok mnie. Nawalał w swój niesamowity kod, a ja zwróciłem się do niego i powiedziałem: Cześć stary, muszę spytać. Czy chodziłeś do jakiejś szkoły, która uczyła programowania? Jak nauczyłeś się tego wszystkiego? Naprawdę chciałem wiedzieć, skąd pochodzą te jednorożce. Jego odpowiedź zabolała mnie jeszcze bardziej.

"Nie. Byłem administratorem tak jak Ty. Po prostu zdecydowałem, że nie chcę już robić dłużej tego głupiego gówna.”

W tamtym momencie odmieniła się cała moja kariera

Siedziałem na krześle przez dobrą godzinę, wpatrując się w ekran. Naprawdę zastanawiałem się, czy całe moje doświadczenie już nie ma znaczenia. Moje ego sprawiło, że uwierzyłem, że ludzie tacy jak ja zawsze będą potrzebni, w końcu jest tak wiele serwerów Windows, które muszą być zarządzane (ręcznie)!

Ale okłamywałem sam siebie. Uświadomiłem sobie, że wpatruję się w przestarzałe odbicie mojego laptopa. I doprowadziło mnie to do gorzkiego postanowienia.

Po nocy ciężkiego picia przyszedłem następnego dnia z nastawieniem, że to nie może być tak trudne. Przecież to nie były prawdziwe jednorożce, byli ludźmi z IT takimi jak ja. Na początku zastanawiałem się, jakiego rodzaju szkolenia mogę podjąć. Może po prostu musiałem zdobyć kilka certyfikatów i dogonić ich. To myślenie doprowadziło mnie daleko, ale nie wystarczająco daleko, wystarczająco szybko. Postanowiłem po prostu sięgnąć do podstaw i pobrudzić sobie trochę ręce.

Kilka miesięcy później do naszego zespołu dołączyło jeszcze dwóch chłopaków DevOps, Lars i Roman. W tym czasie dowiedziałem się o Agile i miałem podstawową wiedzę na temat przepływów pracy git, budowaniu jobów Jenkinsa, pisania podstawowych testów RSpec, ale w większości byłem wciąż zielony i szybko gubiłem się w tych wszystkich metodologiach. Często czułem się tak, jakbym uczył się jeździć w odwrotnym kierunku, w Anglii, z odpaloną głośną muzyką. Byłem przytłoczony i naprawdę musiałem się opierać oszukiwaniu poprzez korzystanie z GUI lub uciekaniu się do skryptów PowerShell. Byłem jak uzależniony, który zbyt długo używał wizardów i myszy. Ale byłem zdeterminowany, a moi koledzy z zespołu byli świetni.

Minął rok. Nadal nie jestem zbyt dobry, ale piszę wszystkie cookbooki systemu Windows (ponieważ nikt w moim zespole nie chciał dotykać Windowsa). Mogę wziąć udział w sprincie, pisać testy (większość), zbudować swój własny worklfow na Jenkinsie. Nagle całkiem „w porządku” rozumiałem DevOps.

Wyobraź sobie, że aż do tej ścieżki DevOpsa, nigdy nie ubiegałem się o pracę, nie znałem co najmniej 65% tego, czego się ode mnie oczekuje. Była to idealna mieszanka posiadania wystarczających umiejętności i miejsca do rozwoju. Cóż, to już nie było ważne.

Pierwsza praca

Nadszedł czas, aby wyjść na łowy. Złożyłem podanie o pracę, na którą nie miałem prawa aplikować. Używali Ansible, Pythona, Perforce i było to w 100% na Linuksie (z którym w ogóle nie czułem się dobrze). Na rozmowie, powiedziałem menedżerowi ds. Zatrudnienia: „Nie znam całego stosu, ale wciąż mogę wykonać tę pracę”. W końcu jedna rzecz, jakiej się nauczyłem w tym roku, to fakt, że mogę zrobić wszystko, co trzeba i się tego nauczyć - to jest mentalność DevOps. Wyzwania związane z nauką nowego światowego porządku IT nie były już tak niemożliwe .

Mam pracę. W niecały miesiąc poczułem się w Linuksie bardziej komfortowo, pisząc playbooki Ansible i tworząc skrypty w Pythonie. Był moment, w którym nawet ja nie mogłem uwierzyć, że udał mi się blef. Potem nagle stałem się jednorożcem w moim zespole. Byłem w dziwnym miejscu, gdzie dokładnie połowa zespołu była opsami (administratorzy), a druga połowa była programistami. A ja byłem gdzieś pośrodku.

Znalazłem się w sytuacji, w której pytałem ludzi, dlaczego nie zautomatyzują długiej konfiguracji lub pytałem deweloperów, dlaczego nie próbują znaleźć poprawek i sztuczek zarządzania starych systemów przed rozpoczęciem projektowania nowych. Na jednym ze standupów zadałem pytanie:

„Dlaczego nie piszemy żadnych testów?” To nie było pytanie tylko dla ludzi z ops.

Otrzymałem nonszalancką odpowiedź, że Ansible robi przecież wszystko za Ciebie. Chociaż jest to prawdą i świetnie współgra z orkiestracją, skąd mamy wiedzieć, kiedy pchamy playbook, czy serwery zostały skonfigurowane tak, jak zamierzaliśmy? Skąd wiemy, że kod jest poprawny od początku do końca, kiedy wprowadzamy zmiany… bez ręcznego testowania? W tym momencie zdałem sobie sprawę, że zaczynam myśleć jak inżynier DevOps. To wciąż było dla mnie nowe, ale mimo to, zdałem sobie z tego sprawę.

Kolejny krok

Moja następna praca wcale nie była „DevOpsowa”. O dziwo, było to zwieńczenie mojego doświadczenia aż do tego momentu (i będzie kontynuacją moich ostatnich notatek w tym artykule). Zadaniem było przeniesienie starych centrów danych klienta do AWS. Posiadali każdy możliwy kawałek technologii pod słońcem. Cokolwiek powstało w ciągu ostatnich 30 lat, mieli to i chcieli, żeby wszystko zostało przeniesione do chmury.

Migracja tych centrów danych była dziwnie wygodna - pracowałem nad tak wieloma starymi systemami, do których byłem przyzwyczajony przed rozpoczęciem podróży z DevOps. Z drugiej strony nie chciałem tego robić. Nie było nic nowatorskiego w „podnoszeniu i przenoszeniu” starych obciążeń do chmury. Stale przyglądałem się sposobom, w jakie te systemy były zarządzane, jak okrutni byli, jak bardzo wszystko było ręczne - tak naprawdę patrzyłem na to, w jaki sposób sam kiedyś działałem. Ta migracja była wielkim wyczynem i historią na inny czas.

Nadchodzi WIELKI test

Miałem rozmowę o pracę w startupie, który był tak blisko mojego domu, że mogłem do niego chodzić spacerem. Piwo w lodówce, stojaki na rowery, tarcze do rzutek, to było niesamowite. Moi potencjalni koledzy z zespołu byli bardzo bystrzy. Robili wszystkie fajne rzeczy, w 100% w AWS, CI / CD, niemutowalne niebieskie/zielone wdrożenia, tylko na Linuksie, używając Puppet, ELK, kontenery, MongoDB. Lista jest długa. To był prawdziwy warsztat DevOps. Znowu, nie znałem około 85% narzędzi, ale użyłem tej samej kwestii:

„Nie znam całego stosu, ale mogę wykonywać tę pracę”.

Cóż, dostałem pracę i byłem niesamowicie podekscytowany. W końcu znalazłem się w tej stajni jednorożców i zamierzałem robić wszystkie fajne rzeczy na fajne sposoby. Miałem zamiar nauczyć się tego nowego zestawu technologii od naprawdę inteligentnych ludzi, tyle że teraz byłem w stanie zrozumieć wszystkie praktyki DevOps.

Pierwszego dnia, po wejściu do pracy okazało się, że jeden z dwóch inżynierów DevOps jest dziś ostatni dzień. Drugi złożył rezygnację tego samego dnia. Następnie CTO opuścił firmę kilka dni później. Zarządzał kilkoma technologiami i tylko on je znał. Potem moja szefowa również zrezygnowała. Nie otrzymywała wsparcia, którego potrzebowała od firmy.

Teraz to ja musiałem wszystkim zarządzać. Nie było żadnego prawdziwej rotacji, dokumentacji, żadnych wskazówek, tylko kod. Nie wchodząc w żadne konkrety apropos tej g*wnoburzy, zostałem sam z rozczarowanymi pracownikami platformy deweloperskiej, bałaganem technologii, której nie znałem i mniej więcej całym rokiem deadlinów przed sobą.

Mogłem uciec. Niecałe dwa lata wcześniej zdecydowanie uciekłbym z powrotem do mojej starej firmy i błagał o powrót do pracy. Jednak to był mój stary zestaw umiejętności, stare obawy, a przecież rzuciłem tę starą karierę.

Po krótkich poszukiwaniach duszy, jak najszybciej sięgnąłem po całą technologię. Niektóre rozwiązania były świetne, niektóre były ogromnymi pułapkami, niektóre były jak niesamowicie trudne do oswojenia smoki. Zdobywszy pewność siebie i umiejętności z ostatnich kilku posad, byłem w stanie przekopać się przez kod, śledzić procesy wdrażania, poprawić pokrycie testów: zrobić wszystko, co było potrzebne.

6 miesięcy później, po strasznych doświadczeniach, kilku momentach, gdzie było blisko kryzysu, dobrej pracy zespołowej i odrobinie szczęścia, cały stos był pod moją kontrolą.

Opowiadam to wszystko, aby przejść do tematu tranzycji. Nie chodzi o kodowanie ani używanie fajnych narzędzi. To, co czyni kogoś inżynierem DevOps, to te rzeczy.

Wszystkie pociągi przejeżdżają przeze mnie

To nie znaczy, że jestem wąskim gardłem ani że moje ego jest takie napompowane. Oznacza to, że mam udział w każdej części biznesu, infrastruktury, SDLC. Jeśli mam zautomatyzować proces end-to-end, muszę być częścią wszystkich konwersacji.

Nie ma ściany

W branży IT często przerzuca się problemy przez ścianę. „To zadanie programisty.” Lub niesławny „To działało na moim laptopie, pewnie coś nie tak z opsami”. Najważniejsze jest to, że to mój problem, wszystko jest moim problemem.

Testy są świetne, wyniki są lepsze

Łatwo jest się pochłonąć perfekcjonizmem DevOps, zapewnić 100%-owe pokrycie testów, w tym wszystkich skrajnych przypadków (tak, jasne). Zrobić kod, który jest w pełni DRY i przenieść zasoby na następną fajną rzecz, taką jak kontenery lub Kubernetes. Mogę kontynuować, ale najważniejsze jest to, że staram się nie tylko ulepszyć proces od początku do końca, ale także upewnić się, że wszystko działa w bardzo stabilny i utrzymywalny sposób. Jako były facet z opsów, myślę, że ważniejsze jest, aby wszystko działało dobrze, niż żeby wszystko było wykonane w najfajniejszy sposób, poprzez trzymanie się zasad ze złotego podręcznika DevOps.

Dowiedz się, co musisz wiedzieć na DZIŚ

Nie martw się o resztę. Stary ja martwiłby się o wszystkie rzeczy, których nie znał i próbował wszystkiego się nauczyć. Tak wiele wciąż nie wiem, że często czuję się jak Sokrates:

„Starożytna Wyrocznia powiedziała, że ​​jestem najmądrzejszym ze wszystkich Greków. To dlatego, że jestem jedynym Grekiem, który wie, że nic nie wie”.

Martwienie się i próba naprawienia wszystkiego jest ogromną stratą czasu i energii. Rozwiąż dzisiejsze problemy i ruszaj dalej.

Bądź rozwiązaniem dla Twojej firmy

Nie chodzi już o tworzenie serwera lub bazy danych, która działa w cieniu centrum danych. Nie chodzi o prośbę o ticket we właściwym formacie, abyś mógł wykonać swoją pracę. Bądź rozwiązaniem problemu dla wyzwania. Badaj, testuj nowe technologie i nie bój się zawieść.

Postaw na prostotę

To powinno być zrozumiałe, ale widziałem zbyt wielu „sprytnych” ludzi DevOps, którzy robią zadanie tak, że następny koleś/koleżanka ma znacznie trudniej poprzez ich automatyzację. Dokumentuj swój ****** kod.

Jeżeli coś sprawia problem lub musi być wykonane dwa razy, zautomatyzuj to

Jeśli nie lubisz sadomasochizmu, to łap się za naprawianie swojego budzika, za każdym razem jak obudzi Cię o drugiej w nocy. Zautomatyzuj problem, abyś mógł wychodzić z pracy o piątej i nie martwić się o telefony w nocy.

Może jesteś nowy w IT. Może jesteś administratorem od 15 lat, jak ja kiedyś i chciałbyś dokonać jakiejś zmiany. Możesz być programistą, który chce lepiej zrozumieć infrastrukturę jako kod. Bez względu na powody, wiedz, że możesz absolutnie wykonać ten skok. Jeśli jesteś oldschoolowcem, tak jak ja, to po prostu potrzeba tony zaangażowania, ale to jest tego warte.