Kiedy aplikacja nie działa, najmniej chce się usłyszeć od kolegów zdanie „problem po waszej stronie”. W końcu to użytkownicy cierpią – a im wszystko jedno, która część zespołu ponosi odpowiedzialność za awarię. Kultura DevOps powstała właśnie po to, aby zjednoczyć rozwój i wsparcie oraz połączyć je wokół wspólnej odpowiedzialności za końcowy produkt.
Jakie praktyki mieszczą się w pojęciu DevOps i po co są potrzebne? Czym zajmują się inżynierowie DevOps i co powinni umieć? Na te i inne pytania odpowiadają eksperci z EPAM: Kirill Sergeev, inżynier systemowy i ewangelista DevOps, oraz Igor Bojko, główny inżynier systemowy i koordynator jednego z zespołów DevOps w firmie.
Po co potrzebny jest DevOps?
Dawniej między programistami a wsparciem (tzw. operations) istniała bariera. Paradoksalnie, mieli różne cele i KPI, mimo że robili wspólną pracę. Celem rozwoju było jak najszybsze wprowadzenie wymagań biznesowych i dodanie ich do działającego produktu. Wsparcie odpowiadało za to, aby aplikacja działała stabilnie – a jakiekolwiek zmiany zagrażały stabilności. Istniał widoczny konflikt interesów – DevOps powstał, aby go rozwiązać.
Czym jest DevOps?
To dobre pytanie – i kontrowersyjne: na świecie jeszcze się co do tego nie zgodzono. W EPAM uważa się, że DevOps łączy w sobie technologie, procesy i kulturę współpracy w zespole. To połączenie ma na celu ciągłe dostarczanie wartości końcowym użytkownikom.
Kirill Sergeev: „Programiści piszą kod, testerzy go sprawdzają, a administratorzy instalują finalny produkt w środowisku produkcyjnym. Przez długi czas te części zespołu były nieco rozdzielone, a potem pojawiła się idea, aby połączyć je wspólnym procesem. Tak powstały praktyki DevOps.”
Nadszedł ten dzień, kiedy programiści i inżynierowie systemowi zaczęli interesować się pracą siebie nawzajem. Bariera między produkcją a wsparciem zaczęła się zacierać. Tak pojawił się DevOps, który obejmuje praktyki, kulturę i porządek współpracy w zespole.
Na czym polega esencja kultury DevOps?
Odpowiedzialność za końcowy rezultat spoczywa na każdym członku zespołu. Najciekawszą i najtrudniejszą częścią filozofii DevOps jest zrozumienie, że konkretna osoba nie tylko odpowiada za swój etap pracy, ale także za to, jak będzie działał cały produkt. Problem nie leży po stronie nikogo – jest wspólny, a każdy członek zespołu pomaga go rozwiązać.
Najważniejsze w kulturze DevOps jest rozwiązywanie problemów, a nie tylko stosowanie praktyk DevOps. Co więcej, te praktyki nie są wdrażane „po czyjejś stronie”, lecz w całym produkcie. Projekt nie potrzebuje tylko inżyniera DevOps – potrzebuje rozwiązania problemu, a rola inżyniera DevOps może być rozłożona na kilku członków zespołu o różnych specjalizacjach.
Jakie są praktyki DevOps?
Praktyki DevOps obejmują wszystkie etapy cyklu życia oprogramowania.
Igor Bojko: „Idealnym przypadkiem jest, gdy zaczynamy stosować praktyki DevOps od samego początku projektu. Razem z architektami planujemy, jaki będzie architektoniczny krajobraz aplikacji, gdzie będzie umiejscowiona i jak będzie się skalować, wybieramy platformę. Obecnie w modzie jest architektura mikrousług – dla niej wybieramy system orkiestracji: trzeba umieć zarządzać każdym elementem aplikacji osobno i aktualizować go niezależnie od innych. Kolejną praktyką jest „infrastruktura jako kod”. Tak nazywamy podejście, w którym infrastruktura projektu jest tworzona i zarządzana za pomocą kodu, a nie przez bezpośrednią interakcję z serwerami.
Następnie przechodzimy do etapu rozwoju. Tutaj jedną z największych praktyk jest budowanie CI/CD: musimy pomóc programistom szybko integrować zmiany w produkcie w małych porcjach, często i bez bólu. CI/CD obejmuje zarówno testowanie kodu, jak i włączenie zmian do bazy kodu oraz wdrażanie aplikacji na środowiskach testowych i produkcyjnych.
Na etapach CI/CD kod przechodzi przez quality gates. Za ich pomocą sprawdzają, czy kod, który wyszedł z stacji roboczej programisty, spełnia określone kryteria jakości. Dodawane jest tutaj testowanie jednostkowe i UI. Aby szybko, bezboleśnie i ukierunkowanie wdrożyć produkt, można wybrać odpowiedni typ wdrożenia.
Praktyki DevOps znajdują zastosowanie również na etapie wsparcia gotowego produktu. Służą do monitorowania, zbierania informacji zwrotnej, zapewnienia bezpieczeństwa oraz wprowadzania zmian. Na wszystkie te zadania praktyki DevOps patrzą z perspektywy ciągłych usprawnień. Minimalizujemy powtarzalne operacje, automatyzując je. To obejmuje również migracje, rozszerzanie aplikacji i wsparcie dla jej działania.
Jakie korzyści przynoszą praktyki DevOps?
Jeśli pisalibyśmy podręcznik na temat nowoczesnych praktyk DevOps, na jego pierwszej stronie znalazłyby się trzy punkty: automatyzacja, przyspieszenie wydania i szybka informacja zwrotna od użytkowników.
Kirill Sergeev: „Pierwszym punktem jest automatyzacja. Całą współpracę w zespole możemy zautomatyzować: napisaliśmy kod – wdrożyliśmy go – przetestowaliśmy – zainstalowaliśmy – zebraliśmy informacje zwrotne – wracamy na początek. Wszystko to – automatycznie.
Drugim punktem jest przyspieszenie wydania i uproszczenie procesu tworzenia. Dla klienta zawsze ważne jest, aby produkt trafił na rynek jak najszybciej i zaczął przynosić korzyści szybciej niż konkurencja. Proces dostarczania produktu można bez końca udoskonalać: skracać czas, dodawać dodatkowe punkty kontrolne, doskonalić monitorowanie.
Trzecim punktem jest przyspieszenie informacji zwrotnej od użytkownika. Jeśli ma on uwagi, możemy natychmiast wprowadzić poprawki i od razu zaktualizować aplikację.
Jak odnosi się pojęcie „inżynier systemowy”, „inżynier budowy” i „inżynier DevOps”?
Przecinają się one, ale dotyczą nieco różnych obszarów.
Inżynier systemowy w EPAM to stanowisko. Mogą być różnych poziomów: od juniora do specjalisty głównego.
Inżynier budowy to raczej rola, którą można pełnić w projekcie. Obecnie tak nazywane są osoby odpowiedzialne za CI/CD.
Inżynier DevOps to specjalista, który wdraża praktyki DevOps w projekcie.
Podsumowując, można powiedzieć, że osoba pracująca na stanowisku inżyniera systemowego pełni w projekcie rolę inżyniera budowy i zajmuje się wdrażaniem praktyk DevOps.
Czym konkretnie zajmuje się inżynier DevOps?
Inżynierowie DevOps łączą wszystkie elementy składające się na projekt. Znają specyfikę pracy programistów, testerów, administratorów systemów i pomagają uprościć ich pracę. Rozumieją potrzeby i wymagania biznesu, jego rolę w procesie rozwoju – i budują proces z uwzględnieniem interesów zleceniodawcy.
Dużo rozmawialiśmy o automatyzacji – to nią zajmują się inżynierowie DevOps w pierwszej kolejności. To bardzo ważny punkt, który obejmuje przygotowanie środowiska.
Kirill Sergeev: „Zanim wdrożymy aktualizacje do produktu, muszą być one przetestowane w zewnętrznym środowisku. Przygotowują je inżynierowie DevOps. To oni również wprowadzają kulturę DevOps w projekcie: stosują praktyki DevOps na wszystkich poziomach swoich projektów. Te trzy zasady: automatyzacja, uproszczenie, przyspieszenie – wprowadzają wszędzie, gdzie mogą sięgnąć”.
Co powinien wiedzieć inżynier DevOps?
Generalnie powinien mieć wiedzę z różnych dziedzin: programowania, pracy z systemami operacyjnymi, bazami danych, systemami budowy i konfiguracji. Do tego dochodzi umiejętność pracy z infrastrukturą chmurową, systemami orkiestracji i monitorowania.
1. Języki programowania
Inżynierowie DevOps znają kilka podstawowych języków do automatyzacji i mogą na przykład powiedzieć programiście: „Możesz zainstalować kod nie ręcznie, ale z pomocą naszego skryptu, który wszystko automatyzuje? Przygotujemy do niego plik konfiguracyjny, który będzie wygodny do odczytu zarówno dla Ciebie, jak i dla nas – i w każdej chwili będziemy mogli go zmienić. A ponadto będziemy widzieć, kto, kiedy i w jakim celu wprowadza zmiany”.
Inżynier DevOps może nauczyć się jednego lub kilku z tych języków: Python, Groovy, Bash, Powershell, Ruby, Go. Nie jest wymagane ich dogłębne poznanie – wystarczy znać podstawy składni, zasady OOP oraz umieć pisać proste skrypty do automatyzacji.
2. Systemy operacyjne
Inżynier DevOps powinien rozumieć, na jakim serwerze będzie zainstalowany produkt, w jakim środowisku będzie uruchamiany, z jakimi usługami będzie współpracował. Można skoncentrować się na specjalizacji związanej z Windows lub rodziną Linux.
3. Systemy kontroli wersji
Bez znajomości systemu kontroli wersji inżynier DevOps nic nie zdziała. Git to jeden z najpopularniejszych systemów w tej chwili.
4. Dostawcy chmurowi
AWS, Google, Azure – zwłaszcza jeśli mówimy o kierunku Windows.
Kirill Sergeev: „Dostawcy chmur oferują nam serwery wirtualne, które doskonale nadają się do CI/CD.
Instalacja dziesięciu serwerów fizycznych wymaga około stu ręcznych operacji. Każdy serwer trzeba ręcznie uruchomić, zainstalować i skonfigurować odpowiedni system operacyjny, zainstalować nasze aplikacje na tych dziesięciu serwerach, a później dziesięć razy wszystko sprawdzić. Usługi chmurowe zastępują tę procedurę dziesięcioma linijkami kodu, a dobry inżynier DevOps powinien umieć nimi operować. Dzięki temu oszczędza czas, wysiłek i pieniądze – zarówno dla klienta, jak i dla firmy.
5. Systemy orkiestracji: Docker i Kubernetes
Kirill Sergeev: „Serwery wirtualne są podzielone na kontenery, w które możemy zainstalować nasze aplikacje. Kiedy kontenerów jest wiele, trzeba nimi zarządzać: jeden włączyć, inny wyłączyć, gdzieś wykonać kopie zapasowe. To staje się dość skomplikowane, dlatego potrzebny jest system orkiestracji.
Dawniej każdą aplikacją zajmował się oddzielny serwer – wszelkie zmiany w jego działaniu mogły wpłynąć na funkcjonalność aplikacji. Dzięki kontenerom aplikacje stają się odizolowane i uruchamiane osobno – każda na swojej wirtualnej maszynie. Jeśli wystąpi awaria, nie trzeba tracić czasu na szukanie przyczyny. Prościej jest zniszczyć stary kontener i dodać nowy.
6. Systemy konfiguracji: Chef, Ansible, Puppet
Kiedy trzeba zarządzać całym parkiem serwerów, trzeba wykonać wiele jednorodnych operacji. To jest długie i skomplikowane, a także ręczna praca zwiększa szansę na błąd. W takiej sytuacji z pomocą przychodzą systemy konfiguracji. Dzięki nim można stworzyć skrypt, który jest czytelny zarówno dla programistów, inżynierów DevOps, jak i administratorów systemów. Ten skrypt pomaga wykonywać te same operacje na serwerach automatycznie. Dzięki temu liczba operacji ręcznych (a więc także błędów) maleje.
Jaką karierę może zbudować inżynier DevOps?
Można się rozwijać zarówno w poziomie, jak i w pionie.
Igor Bojko: „Z perspektywy poziomego rozwoju, inżynierowie DevOps mają obecnie najszersze możliwości. Wszystko ciągle się zmienia, a umiejętności można rozwijać w różnych kierunkach: od systemów kontroli wersji po monitoring, od zarządzania konfiguracjami po bazy danych.
Można zostać architektem systemów, jeśli pracownik jest zainteresowany zrozumieniem, jak działa aplikacja na wszystkich etapach jej cyklu życia – od rozwoju po wsparcie.
Jak zostać inżynierem DevOps?
- Przeczytaj książki „Projekt Phoenix” i DevOps Handbook. To prawdziwe filary filozofii DevOps, przy czym pierwsza to powieść.
- Ucz się technologii z powyższej listy: samodzielnie lub na kursach online.
- Dołącz jako inżynier DevOps do projektu open-source.
- Praktykuj i wdrażaj praktyki DevOps w swoich osobistych i zawodowych projektach.
Źródło: habr.com
