DevOps stał się w ostatnich latach bardzo popularnym tematem. Wiele osób marzy o dołączeniu do niej, ale jak pokazuje praktyka, często tylko ze względu na poziom wynagrodzeń.
Niektóre osoby w swoim CV wymieniają DevOps, chociaż nie zawsze znają i rozumieją istotę tego terminu. Niektórzy uważają, że po przestudiowaniu Ansible, GitLab, Jenkins, Terraform i tym podobnych (listę można kontynuować według własnego gustu) od razu zostaniesz „devopsistą”. To oczywiście nieprawda.
Od kilku lat zajmuję się głównie wdrażaniem DevOps w różnych firmach. Wcześniej przez ponad 20 lat pracował na stanowiskach od administratora systemu po dyrektora IT. Obecnie główny inżynier DevOps w Playgendary.
Kim jest DevOps
Pomysł napisania artykułu zrodził się po kolejnym pytaniu: „kim jest DevOps?” Nadal nie ma ustalonego określenia, czym lub kim jest. Część odpowiedzi już jest w tym temacie . Najpierw podkreślę najważniejsze punkty z niego, a następnie podzielę się swoimi spostrzeżeniami i przemyśleniami.
DevOps to nie specjalista, którego można zatrudnić, nie zbiór narzędzi, a nie dział programistów z inżynierami.
DevOps to filozofia i metodologia.
Innymi słowy, jest to zestaw praktyk, które pomagają programistom aktywnie współdziałać z administratorami systemu. Oznacza to łączenie i integrowanie procesów pracy ze sobą.
Wraz z pojawieniem się DevOps struktura i role specjalistów pozostały takie same (są programiści, są inżynierowie), ale zmieniły się zasady interakcji. Granice pomiędzy działami zatarły się.
Cele DevOps można opisać w trzech punktach:
- Oprogramowanie musi być regularnie aktualizowane.
- Oprogramowanie musi zostać wykonane szybko.
- Oprogramowanie powinno zostać wdrożone wygodnie i w krótkim czasie.
Nie ma jednego narzędzia dla DevOps. Konfigurowanie, dostarczanie i studiowanie kilku produktów nie oznacza, że w firmie pojawił się DevOps. Narzędzi jest wiele i wszystkie są wykorzystywane na różnych etapach, ale służą jednemu wspólnemu celowi.
A to tylko część narzędzi DevOps
Od ponad 2 lat prowadzę rozmowy kwalifikacyjne na stanowisko inżyniera DevOps i zdałem sobie sprawę, jak ważne jest jasne zrozumienie istoty tego terminu. Zebrałem konkretne doświadczenia, obserwacje i przemyślenia, którymi chcę się podzielić.
Z wywiadu widzę następujący obraz: Specjaliści, dla których DevOps jest tytułem zawodowym, zwykle mają nieporozumienia ze współpracownikami.
Był uderzający przykład. Młody człowiek przyszedł na rozmowę z wieloma mądrymi słowami w swoim CV. Na trzech ostatnich stanowiskach miał 5-6 miesięcy doświadczenia. Opuściłem dwa startupy, bo „nie wystartowały”. Ale o trzeciej firmie powiedział, że nikt go tam nie rozumie: programiści piszą kod w systemie Windows, a reżyser wymusza „opakowanie” tego kodu w zwykły Docker i wbudowanie w potok CI/CD. Facet powiedział wiele negatywnych rzeczy na temat swojego obecnego miejsca pracy i swoich kolegów - chciałem tylko odpowiedzieć: „Więc słonia nie sprzedasz”.
Następnie zadałem mu pytanie, które jest wysoko na mojej liście dla każdego kandydata.
— Co DevOps oznacza dla Ciebie osobiście?
- W ogóle, czy jak to postrzegam?
Interesowała mnie jego osobista opinia. Znał teorię i pochodzenie tego terminu, ale zdecydowanie się z nimi nie zgadzał. Uważał, że DevOps to tytuł zawodowy. Tu właśnie leży źródło jego problemów. Jak i inni specjaliści o tym samym zdaniu.
Pracodawcy, słysząc wiele o „magii DevOps”, chcą znaleźć osobę, która przyjdzie i stworzy tę „magię”. A kandydaci z kategorii „DevOps to praca” nie rozumieją, że takim podejściem nie będą w stanie sprostać oczekiwaniom. I w ogóle w CV napisali DevOps, bo taki jest trend i sporo za to płacą.
Metodologia i filozofia DevOps
Metodologia może być teoretyczna i praktyczna. W naszym przypadku to drugie. Jak wspomniałem powyżej, DevOps to zbiór praktyk i strategii wykorzystywanych do osiągnięcia wyznaczonych celów. I w każdym przypadku, w zależności od procesów biznesowych firmy, może się to znacznie różnić. Co nie oznacza, że jest lepiej lub gorzej.
Metodologia DevOps jest jedynie środkiem do osiągnięcia celów.
Teraz o tym, czym jest filozofia DevOps. I to jest chyba najtrudniejsze pytanie.
Sformułowanie krótkiej i zwięzłej odpowiedzi jest dość trudne, ponieważ nie została ona jeszcze sformalizowana. A ponieważ zwolennicy filozofii DevOps są bardziej zaangażowani w praktykę, po prostu nie ma czasu na filozofowanie. Jest to jednak bardzo ważny proces. Co więcej, ma to bezpośredni związek z działalnością inżynierską. Istnieje nawet wyspecjalizowany obszar wiedzy - .
Na mojej uczelni nie było takiego kierunku, wszystkiego musiałem uczyć się sam, korzystając z materiałów, które udało mi się znaleźć w latach 90-tych. Temat jest fakultatywny dla kształcenia inżynierskiego, stąd brak sformalizowania odpowiedzi. Ale osoby poważnie zanurzone w DevOps zaczynają odczuwać pewnego „ducha” lub „nieświadomą kompleksowość” wszystkich procesów firmy.
Korzystając z własnego doświadczenia, próbowałem sformalizować niektóre „postulaty” tej filozofii. Wynik jest następujący:
- DevOps nie jest czymś samodzielnym, co da się wydzielić w odrębny obszar wiedzy czy działania.
- Wszyscy pracownicy firmy powinni podczas planowania swoich działań kierować się metodologią DevOps.
- DevOps wpływa na wszystkie procesy w firmie.
- DevOps istnieje po to, aby redukować koszty czasowe wszelkich procesów w firmie, aby zapewnić rozwój swoich usług i maksymalny komfort klienta.
- DevOps, we współczesnym języku, to proaktywna postawa każdego pracownika firmy, mająca na celu redukcję kosztów czasu i poprawę jakości otaczających nas produktów IT.
Myślę, że moje „postulaty” to odrębny temat do dyskusji. Ale teraz jest na czym budować.
Co robi DevOps
Kluczowym słowem jest tutaj komunikacja. Komunikacji jest mnóstwo, których inicjatorem powinien być dokładnie ten sam inżynier DevOps. Dlaczego? Bo to jest filozofia i metodologia, a dopiero potem wiedza inżynierska.
Nie mogę wypowiadać się ze 100% pewnością na temat zachodniego rynku pracy. Ale wiem całkiem sporo o rynku DevOps w Rosji. Oprócz setek rozmów kwalifikacyjnych, przez ostatnie półtora roku brałem udział w setkach przedsprzedaży technicznych usługi „Wdrożenie DevOps” dla dużych rosyjskich firm i banków.
W Rosji DevOps to wciąż bardzo młody, ale już modny temat. O ile wiem, w samej Moskwie niedobór takich specjalistów w 2019 roku wyniósł ponad 1000 osób. A słowo Kubernetes dla pracodawców jest prawie jak czerwona płachta na byka. Zwolennicy tego narzędzia są gotowi z niego skorzystać nawet tam, gdzie nie jest to konieczne i ekonomicznie opłacalne. Pracodawca nie zawsze rozumie, w jakich przypadkach lepiej zastosować i przy odpowiednim wdrożeniu utrzymanie klastra Kubernetes kosztuje 2-3 razy więcej niż wdrożenie aplikacji przy użyciu konwencjonalnego schematu klastrowego. Używaj go tam, gdzie naprawdę go potrzebujesz.
Wdrożenie DevOps jest kosztowne pod względem finansowym. I ma to uzasadnienie tylko wtedy, gdy przynosi korzyści gospodarcze w innych obszarach, a nie samo w sobie.
Inżynierowie DevOps są tak naprawdę pionierami – to oni powinni jako pierwsi wdrożyć tę metodologię w firmie i zbudować procesy. Aby to się udało, specjalista musi stale współdziałać z pracownikami i współpracownikami na wszystkich poziomach. Jak zwykle powtarzam, w proces wdrożenia DevOps powinni być zaangażowani wszyscy pracownicy firmy: od sprzątaczki po Prezesa. I to jest warunek wstępny. Jeśli najmłodszy członek zespołu nie wie i nie rozumie, czym jest DevOps i po co wykonywane są określone działania organizacyjne, to pomyślne wdrożenie nie będzie skuteczne.
Ponadto inżynier DevOps musi od czasu do czasu skorzystać z zasobu administracyjnego. Na przykład, aby pokonać „opór środowiska” – gdy zespół nie jest gotowy na zaakceptowanie narzędzi i metodologii DevOps.
Programista powinien pisać tylko kod i testy. Aby to zrobić, nie potrzebuje supermocnego laptopa, na którym będzie wdrażał i lokalnie wspierał całą infrastrukturę projektu. Przykładowo front-end developer trzyma na swoim laptopie wszystkie elementy aplikacji łącznie z bazą danych, emulatorem S3 (minio) itp. Oznacza to, że spędza dużo czasu na utrzymaniu tej lokalnej infrastruktury i samodzielnie zmaga się ze wszystkimi problemami związanymi z takim rozwiązaniem. Zamiast opracowywać kod dla frontu. Tacy ludzie potrafią być bardzo oporni na wszelkie zmiany.
Są jednak zespoły, które wręcz przeciwnie, chętnie wprowadzają nowe narzędzia i metody oraz aktywnie uczestniczą w tym procesie. Chociaż nawet w tym przypadku komunikacja pomiędzy inżynierem DevOps a zespołem nie została anulowana.
Kiedy DevOps nie jest potrzebny
Są sytuacje, w których DevOps nie jest potrzebny. To fakt – trzeba to zrozumieć i zaakceptować.
Przede wszystkim dotyczy to wszelkich firm (zwłaszcza małych przedsiębiorstw), których zysk nie zależy bezpośrednio od obecności lub braku produktów informatycznych zapewniających klientom usługi informacyjne. I nie mówimy tutaj o stronie internetowej firmy, czy to statycznej „wizytówki”, czy z dynamicznymi blokami wiadomości itp.
DevOps jest wymagany, gdy satysfakcja Twojego klienta i jego chęć ponownego powrotu do Ciebie zależą od dostępności tych usług informacyjnych do interakcji z klientem, ich jakości i ukierunkowania.
Uderzającym przykładem jest jeden znany bank. Firma nie posiada tradycyjnych biur klientów, obieg dokumentów odbywa się za pośrednictwem poczty lub kurierów, a wielu pracowników pracuje z domu. Firma przestała być tylko bankiem, a moim zdaniem stała się firmą informatyczną z rozwiniętymi technologiami DevOps.
Wiele innych przykładów i wykładów można znaleźć w nagraniach spotkań i konferencji tematycznych. Część z nich odwiedziłam osobiście – jest to bardzo przydatne doświadczenie dla osób chcących rozwijać się w tym kierunku. Poniżej linki do kanałów YouTube z dobrymi wykładami i materiałami na temat DevOps:
Teraz spójrz na swoją firmę i pomyśl o tym: w jakim stopniu Twoja firma i jej zyski zależą od produktów IT umożliwiających interakcję z klientami?
Jeśli Twoja firma sprzedaje ryby w małym sklepie, a jedynym produktem IT są dwie konfiguracje 1C: Enterprise (Księgowość i UNF), to nie ma sensu rozmawiać o DevOps.
Jeśli pracujesz w dużym przedsiębiorstwie handlowo-produkcyjnym (na przykład produkujesz karabiny myśliwskie), powinieneś o tym pomyśleć. Możesz przejąć inicjatywę i przekazać swojemu kierownictwu perspektywy wdrożenia DevOps. Cóż, jednocześnie prowadź ten proces. Proaktywna postawa to jedno z ważnych założeń filozofii DevOps.
Wielkość i wielkość rocznych obrotów finansowych nie jest głównym kryterium decydującym o tym, czy Twoja firma potrzebuje DevOps.
Wyobraźmy sobie duże przedsiębiorstwo przemysłowe, które nie ma bezpośredniego kontaktu z klientami. Na przykład niektórzy producenci samochodów i firmy produkujące samochody. Nie jestem teraz pewien, ale z moich wcześniejszych doświadczeń wynika, że przez wiele lat cała interakcja z klientami odbywała się za pośrednictwem poczty elektronicznej i telefonu.
Ich klientami jest ograniczona lista dealerów samochodowych. I do każdego przypisany jest specjalista od producenta. Cały wewnętrzny obieg dokumentów odbywa się poprzez SAP ERP. Pracownicy wewnętrzni są zasadniczo klientami systemu informatycznego. Ale ten IS jest kontrolowany za pomocą klasycznych sposobów zarządzania systemami klastrowymi. Co wyklucza możliwość stosowania praktyk DevOps.
Stąd wniosek: dla takich przedsiębiorstw wdrożenie DevOps nie jest czymś krytycznie ważnym, jeśli przypomnimy sobie cele metodologii z początku artykułu. Ale nie wykluczam, że dzisiaj korzystają z niektórych narzędzi DevOps.
Z drugiej strony istnieje wiele małych firm, które tworzą oprogramowanie wykorzystując metodologię, filozofię, praktyki i narzędzia DevOps. A wierzą, że koszt wdrożenia DevOps to koszt, który pozwala im skutecznie konkurować na rynku oprogramowania. Przykłady takich firm można zobaczyć .
Główne kryterium zrozumienia, czy DevOps jest potrzebny: jaką wartość mają Twoje produkty IT dla firmy i klientów.
Jeśli głównym produktem firmy generującym zysk jest oprogramowanie, potrzebujesz DevOps. I nie jest to takie ważne, jeśli zarabiasz prawdziwe pieniądze, korzystając z innych produktów. Dotyczy to również sklepów internetowych czy aplikacji mobilnych z grami.
Wszelkie gry istnieją dzięki finansowaniu: bezpośredniemu lub pośredniemu od graczy. W Playgendary tworzymy darmowe gry mobilne, w ich tworzenie bezpośrednio zaangażowane jest ponad 200 osób. Jak wykorzystujemy DevOps?
Tak, dokładnie tak samo jak opisano powyżej. Stale komunikuję się z programistami i testerami oraz prowadzę wewnętrzne szkolenia dla pracowników z metodologii i narzędzi DevOps.
Obecnie aktywnie używamy Jenkinsa jako narzędzia potoków CI/CD do wykonywania wszystkich potoków montażu za pomocą Unity i późniejszego wdrażania w App Store i Play Market. Więcej z klasycznego zestawu narzędzi:
- Asana - do zarządzania projektami. Skonfigurowano integrację z Jenkinsem.
- Google Meet – do spotkań wideo.
- Slack - do komunikacji i różnych alertów, w tym powiadomień od Jenkinsa.
- Atlassian Confluence - do dokumentacji i pracy grupowej.
Nasze najbliższe plany obejmują wprowadzenie statycznej analizy kodu z wykorzystaniem SonarQube oraz przeprowadzenie automatycznych testów UI z wykorzystaniem Selenium na etapie Continuous Integration.
Zamiast zawierania
Chciałbym zakończyć następującą myślą: aby zostać wysoko wykwalifikowanym inżynierem DevOps, trzeba nauczyć się komunikować na żywo z ludźmi.
Inżynier DevOps to gracz zespołowy. I nic więcej. Inicjatywa w komunikowaniu się z kolegami powinna pochodzić od niego, a nie pod wpływem pewnych okoliczności. Specjalista DevOps musi zobaczyć i zaproponować najlepsze rozwiązanie dla zespołu.
I tak, wdrożenie dowolnego rozwiązania będzie wymagało wielu dyskusji, a na koniec może całkowicie się zmienić. Samodzielnie rozwijając się, proponując i wdrażając swoje pomysły, taka osoba stanowi coraz większą wartość zarówno dla zespołu, jak i pracodawcy. Co ostatecznie przekłada się na wysokość jego miesięcznego wynagrodzenia lub w formie dodatkowych premii.
Źródło: www.habr.com