Gdzie iść z tą wiedzą, co robić w projekcie i ile zarobić, o co powiedzieć i zapytać na rozmowie kwalifikacyjnej – mówi Aleksander Titow, partner zarządzający Express 42 i autor .
Cześć! Choć termin DevOps istnieje od 2009 roku, w społeczności rosyjskiej nadal nie ma konsensusu. Zapewne zauważyłeś, że niektórzy uważają DevOps za specjalizację, inni za filozofię, jeszcze jeszcze inni za zbiór technologii. Występowałem już wiele razy z o rozwoju tego kierunku, dlatego nie będę się wdawać w szczegóły w tym artykule. Powiem tylko, że w Expressie 42 uwzględniamy w nim m.in.:
DevOps to specyficzna metodyka, kultura tworzenia produktu cyfrowego, gdy w produkcji uczestniczą wszyscy specjaliści w zespole.
W klasycznym rozwoju korporacyjnym wszystko przebiega sekwencyjnie: programowanie, testowanie i dopiero potem działanie, a szybkość tego procesu od pomysłu do produkcji wynosi 3 miesiące. Jest to problem globalny dla produktów cyfrowych, ponieważ nie da się szybko uzyskać informacji zwrotnej od klientów.
W DevOps narzędzia i podejścia są zaprojektowane tak, aby zapewnić równoczesne działanie procesów programowania, testowania i operacji.
Co wynika z takiego podejścia?
- Nie można zatrudnić jakiegoś „inżyniera”, który przyjdzie i rozwiąże wszystkie problemy związane z produkcją. Cały zespół musi zastosować tę technikę.
- DevOps NIE jest następną formą sysadmin, do której można dokonać aktualizacji. „Inżynier DevOps” brzmi mniej więcej tak samo, jak „programista Agile”.
- Jeśli zespół korzysta z Kubernetesa, Ansible, Prometheusa, Mesosfery i Dockera, nie oznacza to, że zostały w nim wdrożone praktyki DevOps.
Życie po DevOps nigdy nie będzie takie samo
Podejście DevOps to przede wszystkim inny sposób myślenia, postrzeganie rozwoju jako całości i swojego miejsca w procesie. Nasz kurs online podzieliliśmy na 2 bloki:
1. Samostanowienie
Najpierw szczegółowo badamy istotę podejścia DevOps, a uczniowie odkrywają nowe role w zespole, sprawdzają, która z nich bardziej reaguje i sami ustalają, w którym kierunku się rozwijać.
2. Narzędzia i praktyki
Studenci opanowują konkretne technologie z punktu widzenia metody DevOps.
Narzędzia DevOps można wykorzystać zarówno w podejściu DevOps, jak i w klasycznym rozwoju. Najbardziej oczywistym przykładem byłoby użycie narzędzia do zarządzania konfiguracją Ansible. Został stworzony i pomyślany w celu realizacji praktyki DevOps „Infrastruktura jako kod”, co oznacza, że opisywane są różne stany systemu, od ustawień systemu operacyjnego po oprogramowanie aplikacyjne. Opis podzielony jest na warstwy i pozwala zarządzać złożoną, ciągle zmieniającą się konfiguracją. Jednak inżynierowie często używają Ansible jako sposobu na uruchamianie skryptów bash na wielu komputerach. Nie jest to ani złe, ani dobre, ale trzeba zrozumieć, że obecność Ansible nie gwarantuje obecności DevOps w firmie.
Jesteśmy w trakcie Zagłębisz się w proces tworzenia aplikacji na wzór słynnego Reddita, zaczynając od jej wersji monolitycznej, przechodząc krok po kroku do mikroserwisów. Krok po kroku opanujemy nowe narzędzia: Git, Ansible, Gitlab, a skończymy na Kubernetesie i Prometheusie.
W zakresie praktyk będziemy kierować się taktyką trzech ścieżek opisanych w Podręczniku DevOps – praktyki ciągłego dostarczania, praktyki przekazywania informacji zwrotnej, a istotą całego kursu jest praktyka ciągłego uczenia się wraz ze swoim systemem.
Co ta wiedza daje każdemu ze specjalistów?
Dla administratorów systemu
Praktyki pozwolą Ci odejść od administracji w stronę stworzenia rurociągu ciągłego dostarczania i platformy infrastrukturalnej do dostarczania oprogramowania. Chodzi o to, że tworzy produkt – platformę infrastrukturalną dla programistów, która pomaga im szybko wypchnąć zmiany do produkcji.
Wcześniej administratorzy systemu byli ostatnim bastionem, po którym wszystko trafiało do produkcji. A w zasadzie zajmowali się ciągłą gaszeniem pożarów – w świetle czego dość trudno jest zagłębić się w potrzeby biznesu, pomyśleć o produkcie i korzyściach dla użytkownika.
Dzięki metodzie DevOps myślenie się zmienia. Administrator systemu rozumie, jak przełożyć konfigurację na kod, jakie istnieją w tym zakresie praktyki.
To o tyle istotne, że firmy coraz częściej zdają sobie sprawę, że nie wystarczy im wszystko automatyzować, czyli np. w tym, do czego w zasadzie byli przyzwyczajeni administratorzy systemów starej szkoły, którzy w dodatku niewiele się komunikowali i nie informowali zespołu o wszystkich wprowadzonych zmianach. Teraz zespoły szukają tych, którzy staną się producentem produktu infrastruktury wewnętrznej i pomogą połączyć rozdzielone procesy w jeden.
Deweloperzy
Deweloper przestaje myśleć wyłącznie algorytmami. Nabywa umiejętność pracy z infrastrukturą, umiejętność architektonicznej świadomości krajobrazu. Taki programista rozumie, jak aplikacja działa, jak przechodzi przez rurociąg ciągłego dostarczania, jak ją monitorować, jak ją rejestrować, aby przynosiła korzyść klientowi. W rezultacie cała ta wiedza pozwala na napisanie odpowiedniego kodu.
Dla testerów
Testowanie już dawno przechodzi w tryb automatyczny, wszyscy mówimy, że wielu testów nie należy wykonywać, tylko pisać :) Testowanie staje się częścią całego procesu dostarczania Twojego produktu. Tester musi nie tylko nauczyć się pisać kod, ale także wiedzieć, jak zintegrować go z systemami ciągłego dostarczania, jak otrzymywać informację zwrotną z kodu na wszystkich etapach dostarczania oraz jak stale ulepszać testowanie, aby wykrywać błędy możliwie wcześnie.
I tak się okazuje wszystkie trzy etapy zachodzą jednocześnie. Na przykład może to wyglądać tak:
Deweloper pisze kod, od razu pisze dla niego testy i opisuje kontener dokera dla kodu, który należy uruchomić. Od razu opisuje także monitoring, który będzie monitorował działanie tej usługi na produkcji i to wszystko zobowiązuje.
Kiedy rozpoczyna się ciągła integracja, procesy przebiegają jednocześnie. Usługa zostanie uruchomiona i skonfigurowana. W tym samym czasie uruchamiany jest kontener dokujący i sprawdzane jest, czy działa. Jednocześnie wszystkie informacje trafiają do systemu logowania. I tak na każdym etapie rozwoju – okazuje się, że to prawdziwa praca zespołowa administratorów systemu, programistów i testerów.
Studiowałem DevOps, co dalej?
Jak wiadomo, człowiek w polu nie jest wojownikiem. Jeśli Twoja firma nie zastosuje tej metody, nabyte umiejętności pozostaną bezużyteczne. A po zapoznaniu się z podejściami DevOps najprawdopodobniej nie będziesz chciał być trybikiem w rozwoju korporacji. Może być jeden wyjątek: jesteś administratorem systemu w zespole i możesz odbudować wszystkie procesy w nowy sposób. Warto w tym miejscu dodać, że firm, które korzystają z tego podejścia, nie odczuwają lockdownu i poszukują specjalistów. Ponieważ DevOps polega na tworzeniu produktów online.
A teraz coś dobrego: znajomość praktyk i narzędzi DevOps to około +30% Twojej wartości na rynku pracy. Wynagrodzenia zaczynają się od 140 tysięcy rubli, ale oczywiście zależą od Twojej głównej specjalizacji i funkcjonalności.
Możesz przeglądać oferty pracy oznaczone jako „zorientowane na infrastrukturę”, gdzie występuje automatyzacja testów, tworzenie aplikacji mikroserwisowych z wykorzystaniem technologii chmurowych, oferty pracy dla inżynierów infrastruktury i wszelkiego rodzaju odniesienia do DevOps. Pamiętaj tylko, że każda firma pod tą definicją ma na myśli co innego - przeczytaj uważnie opis.
Podczas startu naszego kursu przyszła mi do głowy spostrzeżenie – wiele osób po kursie wpada w pułapkę inżyniera DevOps. Znajdują wakat o powyższym tytule, otrzymują dobrą ofertę, a potem przychodzą do pracy i zdają sobie sprawę, że będą musieli utrzymywać trzystronicowy skrypt bashowy w Jenkinsie. Gdzie są Kubernetes, ChatOps, wydania kanarek i tak dalej? Ale nic z tego, bo firma nie potrzebuje DevOps jako metodologii, ale wykorzystuje indywidualne innowacje.
To powód, aby intensywnie dowiedzieć się od firmy, jak wygląda proces dostarczania oprogramowania, stos technologii i jakie obowiązki będziesz pełnił.
Jeśli pracodawca odpowiada na Twoje pytania abstrakcyjnie, jak z książki, bez szczegółów, to najprawdopodobniej w firmie nie ma jeszcze procesu DevOps, ale nie jest to powód, aby odmówić, przestudiować firmę i jej produkty, czy istnieją w Internecie usługi, które firma sama rozwija, aplikacje mobilne, pomysły na produkty.
Jeśli tak, to wyjaśnij, czy będziesz musiał pracować bezpośrednio z tymi systemami, czy też istnieje możliwość poziomego przemieszczania się do zespołów tych usług, jednocześnie wykazując dobre wyniki w praktykach DevOps. Jeśli tak, to warto pojechać i być aktywnym i użytecznym, a jeśli ukończysz nasz kurs, to drugie masz gwarancję.
Należy zauważyć, że praktycy Devops zyskują prawdziwą wartość tylko dzięki doświadczeniu w programowaniu/administrowaniu/testowaniu. Tylko wtedy wiedza nie będzie abstrakcyjna, ale wzbogaci specjalistę (pod każdym względem). Dlatego idea „nauki DevOps od podstaw” jest mniej więcej taka sama, jak nauka „korzystania z obiektywów od podstaw”, jeśli nigdy nie trzymałeś aparatu w rękach ani nie reżyserowałeś sesji. Aby pomóc Ci zdecydować, czy kurs jest dla Ciebie odpowiedni, przygotowaliśmy test wstępny, który sprawdzi Twój wystarczający poziom wiedzy.
Myślę, że to jedna ze sztuczek — aby w trakcie kształcenia każdy student sam ustalał, w jakim kierunku chce się rozwijać. Często widzimy przejścia, gdy programista zostaje inżynierem infrastruktury, a administrator uświadamia sobie, że interesuje go pisanie kodu – wtedy dalej studiuje język i uzupełnia go o nabyte umiejętności DevOps. Dlatego szczególnie zapraszamy tych, którzy czują, że ich kariera utknęła na rozdrożu. Kurs rozpoczyna się 28 maja, ale można dołączyć już po 2 tygodniach od rozpoczęcia zajęć. Możesz obejrzeć program i przystąpić do testu . Do zobaczenia w OTUS!
Źródło: www.habr.com