Temat DevOps stał się bardzo popularny w ciągu ostatnich kilku lat. Wiele osób marzy o związaniu się z tą dziedziną, ale, jak pokazuje praktyka, często tylko ze względu na poziom wynagrodzeń.
Niektórzy wskazują w swoim CV DevOps, chociaż nie zawsze znają i rozumieją istotę tego terminu. Ktoś uważa, że po nauczeniu się Ansible, GitLab, Jenkins, Terraform i podobnych narzędzi (lista może być kontynuowana według uznania) od razu stanie się 'devopsem'. To, oczywiście, nieprawda.
Od kilku ostatnich lat zajmuję się głównie wdrażaniem DevOps w różnych firmach. Wcześniej przez ponad 20 lat pracowałem na stanowiskach od administratora systemu do dyrektora IT. Teraz jestem DevOps Lead Engineer w Playgendary.
Kim jest DevOps
Pomysł na napisanie artykułu powstał po kolejnym pytaniu: 'kim jest DevOps?'. Do tej pory nie ma ustalonego terminu, co lub kto to jest. Część odpowiedzi już znajduje się w tym . Na początek wyróżnię główne tezy z niego, a następnie podzielę się swoimi obserwacjami i przemyśleniami.
DevOps to nie specjalista, którego można zatrudnić, ani zestaw narzędzi, ani dział programistów z inżynierami.
DevOps to filozofia i metodologia.
Innymi słowy, to zestaw praktyk, który pomaga aktywnie współpracować programistom z administratorami systemów. To znaczy łączyć i integrować procesy robocze ze sobą.
Z pojawieniem się DevOps struktura i role specjalistów pozostały takie same (są deweloperzy, są inżynierowie), ale zmieniły się zasady współpracy. Granice między działami stały się mniej wyraźne.
Cele DevOps można opisać trzema punktami:
- Oprogramowanie powinno być regularnie aktualizowane.
- Oprogramowanie powinno być tworzone szybko.
- Oprogramowanie powinno być wdrażane wygodnie i w krótkim czasie.
DevOps nie ma jednego narzędzia. Skonfigurowanie, zainstalowanie i nauczenie się kilku produktów nie oznacza, że w firmie pojawił się DevOps. Narzędzi jest bardzo wiele i wszystkie są używane na różnych etapach, ale służą jednej wspólnej celu.
I to tylko część narzędzi DevOps
Od ponad 2 lat przeprowadzam rozmowy kwalifikacyjne z osobami na stanowisko inżyniera DevOps i dotarło do mnie, jak ważne jest jasno rozumieć istotę tego terminu. Zgromadziłem specyficzne doświadczenie, obserwacje i myśli, którymi chcę się podzielić.
Z doświadczenia rozmów kwalifikacyjnych widzę taki obraz: specjaliści, którzy uważają DevOps za stanowisko, zazwyczaj mają nieporozumienia z kolegami.
Był wyraźny przykład. Na rozmowę kwalifikacyjną przyszedł młody mężczyzna z masą mądrych słów w CV. W ostatnich trzech miejscach pracy miał doświadczenie wynoszące 5-6 miesięcy. Z dwóch startupów odszedł, ponieważ „nie wzbiły się”. A w odniesieniu do trzeciej firmy powiedział, że nikt go tam nie rozumie: programiści piszą kod na Windows, a dyrektor zmusza do „opakowywania” tego kodu w zwykły Docker i wbudowywania w CI/CD-pipeline. Chłopak wiele negatywnych rzeczy opowiedział o swoim obecnym miejscu pracy i kolegach — aż chciało się odpowiedzieć: „No to gwałt ci nie sprzedadzą”.
Potem zadałem mu pytanie, które w mojej liście jest jednym z pierwszych dla każdego kandydata.
— Co dla ciebie osobiście oznacza DevOps?
— Ogólnie czy jak to postrzegam?
Interesowało mnie jego osobiste zdanie. Znał teorię i pochodzenie terminu, ale był z nimi kategorycznie niezgodny. Sądził, że DevOps to stanowisko. W tym tkwi źródło jego problemów. Podobnie jak innych specjalistów o tym samym zdaniu.
Pracodawcy, nasłuchawszy się o „magii DevOps”, chcą znaleźć osobę, która przyjdzie i tę „magie” stworzy. A kandydaci z kategorii „DevOps to stanowisko” nie rozumieją, że przy takim podejściu nie będą w stanie spełnić oczekiwań. I w ogóle, napisali w swoim CV DevOps, ponieważ to trend i za to dużo płacą.
Metodologia i filozofia DevOps
Metodologia może być teoretyczna i praktyczna. W naszym przypadku — drugie. Jak wspomniałem powyżej, DevOps to zestaw praktyk i strategii stosowanych w celu osiągnięcia wyznaczonych celów. I w każdym przypadku, w zależności od procesów biznesowych firmy, może się znacznie różnić. Co nie sprawia, że jest lepsza lub gorsza.
Metodologia DevOps to jedynie środek do osiągnięcia wyznaczonych celów.
Teraz o tym, czym jest filozofia DevOps. I to pewnie najtrudniejsze pytanie.
Sformułowanie krótkiej i zwięzłej odpowiedzi jest dość trudne, ponieważ nie została jeszcze sformalizowana. A ponieważ zwolennicy filozofii DevOps bardziej zajmują się praktyką — na filozofowanie po prostu nie ma czasu. Niemniej jednak, to bardzo ważny proces. I ma bezpośredni związek z działalnością inżynieryjną. Istnieje nawet wyspecjalizowany obszar wiedzy — .
Na moim uniwersytecie nie było takiego przedmiotu, musiałem studiować wszystko samodzielnie, korzystając z materiałów, które udało mi się znaleźć w latach 90. Temat nie jest obowiązkowy w edukacji inżynierskiej, stąd brak sformalizowanej odpowiedzi. Ale ci, którzy poważnie zanurzyli się w DevOps, zaczynają odczuwać pewien „duch” lub „nieuświadomioną wszechobecność” wszystkich procesów w firmie.
Na swoim doświadczeniu starałem się sformalizować niektóre „postulaty” tej filozofii. Oto, co wyszło:
- DevOps nie jest czymś samodzielnym, co można wydzielić jako odrębny kierunek wiedzy lub działalności.
- Z metodologią DevOps powinien się kierować każdy pracownik firmy planując swoją działalność.
- DevOps dotyczy wszystkich procesów wewnątrz firmy.
- DevOps istnieje, aby zmniejszać czas poświęcony na jakiekolwiek procesy w firmie w celu zapewnienia rozwoju jej usług i maksymalnego komfortu klienta.
- DevOps, współczesnym językiem, to proaktywna postawa każdego pracownika firmy, skierowana na obniżanie kosztów czasowych i poprawę jakości otaczających nas produktów IT.
Myślę, że moje „postulaty” to osobny temat do dyskusji. Ale teraz jest od czego zacząć.
Co robi DevOps
Kluczowym słowem tutaj są komunikacje. Jest ich bardzo wiele, a inicjatorem powinien być właśnie ten sam inżynier DevOps. Dlaczego tak? Ponieważ to filozofia i metodologia, a dopiero potem wiedza inżynieryjna.
Nie mogę mówić o zachodnim rynku pracy z 100% pewnością. Ale o rynku DevOps w Rosji wiem całkiem sporo. Oprócz setek rozmów kwalifikacyjnych, w ciągu ostatnich półtora roku brałem udział w setce technicznych preselekcji dotyczących usługi „Wdrożenie DevOps” dla dużych rosyjskich firm i banków.
W Polsce DevOps jest jeszcze młodym, ale już trendowym tematem. Z tego, co wiem, tylko w Warszawie w 2019 roku deficyt takich specjalistów przekroczył 1000 osób. A słowo Kubernetes dla pracodawców jest prawie jak czerwona flaga dla byka. Zwolennicy tego narzędzia są gotowi stosować je nawet tam, gdzie nie jest to konieczne i ekonomicznie opłacalne. Pracodawca nie zawsze rozumie, w jakich przypadkach lepiej co użyć, a przy odpowiednim wdrożeniu koszt klastrów Kubernetes jest 2-3 razy droższy niż wdrażanie aplikacji w tradycyjnym schemacie klastrowym. Używaj go tam, gdzie jest naprawdę potrzebny.
Wdrożenie DevOps z perspektywy finansowej jest kosztowne. Jest uzasadnione tylko tam, gdzie przynosi korzyści ekonomiczne w innych obszarach, a nie samo w sobie.
Inżynierowie DevOps to w zasadzie pionierzy – to oni jako pierwsi muszą wdrożyć tę metodologię w firmie i organizować procesy. Aby to się udało, specjalista musi stale współpracować z pracownikami i kolegami na wszystkich szczeblach. Jak zwykle mówię, w proces wdrożenia DevOps powinni być zaangażowani wszyscy pracownicy firmy: od sprzątaczki po CEO. To jest warunek konieczny. Jeśli najniżej postawiony członek zespołu nie będzie wiedział i rozumiał, czym jest DevOps i po co wykonuje się te czy inne działania organizacyjne, nie będzie można mówić o skutecznym wdrożeniu.
Inżynier DevOps musi także od czasu do czasu korzystać z zasobów administracyjnych. Na przykład, aby pokonać 'opór środowiska' – gdy zespół nie jest gotowy zaakceptować narzędzi i metodologii DevOps.
Programista powinien pisać tylko kod i testy. Nie potrzebuje w tym celu superwydajnego laptopa, na którym będzie wdrażał i utrzymywał lokalnie całą infrastrukturę projektu. Na przykład frontendowiec ma na swoim laptopie wszystkie elementy aplikacji, w tym bazę danych, emulator S3 (minio) i inne. Spędza więc dużo czasu na utrzymaniu tej lokalnej infrastruktury i samotnie zmaga się ze wszystkimi problemami takiego rozwiązania. Zamiast rozwijać kod dla frontu. Tacy ludzie mogą mocno opierać się jakimkolwiek zmianom.
Są jednak zespoły, które z kolei cieszą się z wprowadzania nowych narzędzi i metod, i aktywnie uczestniczą w tym procesie. Choć nawet w takim przypadku komunikacja między inżynierem DevOps a zespołem nadal jest niezbędna.
Kiedy DevOps jest niepotrzebny
Zdarzają się sytuacje, w których DevOps jest zbędny. To fakt — należy go zrozumieć i zaakceptować.
Przede wszystkim dotyczy to wszelkich firm (szczególnie małych przedsiębiorstw), dla których zyski nie zależą bezpośrednio od posiadania lub braku produktów IT, które świadczą usługi informacyjne dla klientów. I nie chodzi tutaj o stronę internetową firmy, czy to będąca statyczną „wizytówką”, czy z dynamicznymi sekcjami z wiadomościami itd.
DevOps jest potrzebny, gdy jakość i celowość tych usług informacyjnych wpływa na zadowolenie klientów oraz ich chęć ponownego skorzystania z twoich usług.
Jasnym przykładem jest jeden znany bank. Firma nie ma tradycyjnych oddziałów obsługi klienta, a obieg dokumentów odbywa się za pośrednictwem poczty lub kurierów, a wielu pracowników pracuje zdalnie. Firma przestała być tylko bankiem i, w mojej opinii, przekształciła się w firmę IT z rozwiniętymi technologiami DevOps.
Można znaleźć wiele innych przykładów i wykładów w nagraniach tematycznych meet-upów i konferencji. Część z nich osobiście odwiedziłem — to bardzo cenne doświadczenie dla tych, którzy chcą rozwijać się w tym kierunku. Oto linki do kanałów YouTube z dobrymi wykładami i materiałami poświęconymi DevOps:
Teraz spójrz na swoją firmę i pomyśl o tym: jak bardzo twoja firma i jej zyski zależą od produktów IT, które zapewniają interakcje z klientem?
Jeśli twoja firma sprzedaje ryby w małym sklepie, a jedynym produktem IT są dwa systemy 1C: Przedsiębiorstwo (Księgowość i UNF), to raczej nie ma sensu mówić o DevOps.
Jeśli jednak pracujesz w dużym przedsiębiorstwie handlowym i produkcyjnym (na przykład produkujesz strzelby myśliwskie), warto się zastanowić. Możesz wykazać się inicjatywą i przedstawić kierownictwu perspektywy wprowadzenia DevOps. No i przy okazji, przewodniczyć temu procesowi. Proaktywna postawa jest jednym z ważnych postulatów filozofii DevOps.
Wielkość i liczba rocznego obrotu finansowego nie są podstawowym kryterium do określenia, czy Twoja firma potrzebuje DevOps.
Wyobraźmy sobie dużą firmę przemysłową, która nie współpracuje bezpośrednio z klientami. Na przykład niektóre koncerny motoryzacyjne i firmy zajmujące się produkcją samochodów. Teraz nie jestem pewny, ale z mojego wcześniejszego doświadczenia, przez wiele lat cała komunikacja z klientami odbywała się drogą mailową i telefonicznie.
Ich klienci to ograniczona lista dealerów samochodowych. Do każdego z nich przypisany jest specjalista od producenta. Cała wewnętrzna dokumentacja prowadzona jest przez ERP SAP. Wewnętrzni pracownicy są w zasadzie klientami systemu informacyjnego. Ale zarządzanie tym systemem odbywa się za pomocą klasycznych narzędzi do zarządzania systemami klastrowymi. Co wyklucza możliwość zastosowania praktyk DevOps.
Stąd wniosek: dla takich przedsiębiorstw wdrożenie DevOps nie jest czymś krytycznie ważnym, gdy przypomnimy sobie cele metodologii z początku artykułu. Ale nie wykluczam, że mogą oni dzisiaj korzystać z niektórych narzędzi DevOps.
Z drugiej strony istnieje wiele małych firm, które rozwijają oprogramowanie, stosując metodologię, filozofię, praktyki i narzędzia DevOps. Uważają, że wydatki na wdrożenie DevOps są kosztami, które pozwalają im efektywnie konkurować na rynku oprogramowania. Przykłady takich firm można zobaczyć. .
Głównym kryterium do zrozumienia, czy potrzebujesz DevOps, jest to, jakie znaczenie mają Twoje produkty IT dla firmy i klientów.
Jeśli głównym produktem firmy, przynoszącym zyski, jest oprogramowanie – potrzebujesz DevOps. I nie jest tak ważne, czy prawdziwe pieniądze zarabiasz dzięki innym towarom. Można tu również zaliczyć sklepy internetowe czy aplikacje mobilne z grami.
Jakiekolwiek gry istnieją dzięki finansowaniu: bezpośredniemu lub pośredniemu ze strony graczy. W Playgendary rozwijamy darmowe gry mobilne, w bezpośrednim tworzeniu których uczestniczy ponad 200 osób. Jak wykorzystujemy DevOps?
Dokładnie tak, jak opisano powyżej. Nieustannie komunikuję się z deweloperami i testerami, przeprowadzam wewnętrzne szkolenia dla pracowników dotyczące metodologii i narzędzi DevOps.
Obecnie aktywnie korzystamy z Jenkins jako narzędzia CI/CD pipelines do wykonywania wszystkich zestawów budowlanych z Unity i późniejszego wdrażania w App Store i Play Market. Dodatkowo, w klasycznym zestawie narzędzi:
- Asana – do zarządzania projektami. Zintegrowano z Jenkins.
- Google Meet – do przeprowadzania spotkań wideo.
- Slack – do komunikacji i różnych powiadomień, w tym powiadomień z Jenkins.
- Atlassian Confluence – do dokumentacji i pracy zespołowej.
W najbliższych planach wdrożenie analizy statycznej kodu za pomocą SonarQube i przeprowadzenie zautomatyzowanego testowania UI za pomocą Selenium na etapie Continuous Integration.
Zamiast zakończenia
Chcę zakończyć następującą myślą: aby stać się wysoko wykwalifikowanym inżynierem DevOps, koniecznie należy nauczyć się bezpośredniej komunikacji z ludźmi.
Inżynier DevOps to gracz zespołowy. I tak właśnie powinno być. Inicjatywa w komunikacji z kolegami powinna pochodzić od niego samego, a nie być efektem jakichkolwiek okoliczności. Specjalista DevOps powinien dostrzegać i proponować najlepsze rozwiązania dla zespołu.
Tak, wdrożenie jakiegokolwiek rozwiązania wymaga wielu dyskusji, a na koniec może się całkowicie zmienić. Rozwijając się samodzielnie, proponując i realizując swoje pomysły – taka osoba staje się coraz cenniejsza zarówno dla zespołu, jak i dla pracodawcy. Co, ostatecznie, znajduje odzwierciedlenie w wysokości jego miesięcznego wynagrodzenia lub w postaci dodatkowych premii.
Źródło: habr.com
