Kiedy aplikacja nie działa, ostatnią rzeczą, którą chcesz usłyszeć od współpracowników, jest zdanie „problem jest po twojej stronie”. W rezultacie cierpią użytkownicy – i jest im obojętne, która część zespołu jest odpowiedzialna za awarię. Kultura DevOps pojawiła się właśnie po to, aby połączyć rozwój i wsparcie wokół wspólnej odpowiedzialności za produkt końcowy.
Jakie praktyki mieszczą się w koncepcji DevOps i dlaczego 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, wiodący inżynier systemowy i koordynator jednego z firmowych zespołów DevOps.
Dlaczego DevOps jest potrzebny?
Wcześniej istniała bariera pomiędzy programistami a wsparciem (tzw. operacje). Brzmi to paradoksalnie, ale mieli różne cele i KPI, choć robili to samo. Celem rozwoju było jak najszybsze wdrożenie wymagań biznesowych i dodanie ich do działającego produktu. Support odpowiadał za to, aby aplikacja działała stabilnie - a wszelkie zmiany zagrażały stabilności. Występuje konflikt interesów – wydaje się, że DevOps go rozwiązuje.
Co to jest DevOps?
To dobre pytanie – i kontrowersyjne: świat jeszcze się co do tego ostatecznie nie zgodził. EPAM wierzy, że DevOps łączy technologie, procesy i kulturę interakcji w zespole. Celem tego stowarzyszenia jest ciągłe dostarczanie wartości użytkownikom końcowym.
Cyryl Siergiejew: „Programiści piszą kod, testerzy go przeglądają, a administratorzy wdrażają produkt końcowy do środowiska produkcyjnego. Przez długi czas te części zespołu były nieco rozproszone, a potem zrodził się pomysł, aby je zjednoczyć poprzez wspólny proces. Tak pojawiły się praktyki DevOps.”
Nadszedł dzień, w którym programiści i inżynierowie systemowi zainteresowali się wzajemną pracą. Bariera pomiędzy produkcją a wsparciem zaczęła zanikać. W ten sposób powstał DevOps, który obejmuje praktyki, kulturę i interakcję w zespole.
Jaka jest istota kultury DevOps?
Faktem jest, że odpowiedzialność za końcowy wynik spoczywa na każdym członku zespołu. Najciekawszą i najtrudniejszą rzeczą w filozofii DevOps jest zrozumienie, że konkretna osoba nie jest odpowiedzialna tylko za własny etap pracy, ale jest odpowiedzialna za to, jak będzie działał cały produkt. Problem nie leży po niczyjej stronie – jest wspólny i każdy członek zespołu pomaga go rozwiązać.
Najważniejszą rzeczą w kulturze DevOps jest rozwiązanie problemu, a nie tylko zastosowanie praktyk DevOps. Co więcej, praktyki te nie są wdrażane „po czyjejś stronie”, ale w całym produkcie. Projekt nie potrzebuje inżyniera DevOps per se - potrzebuje rozwiązania problemu, a rolę inżyniera DevOps można rozdzielić na kilku członków zespołu o różnych specjalizacjach.
Jakie są rodzaje praktyk DevOps?
Praktyki DevOps obejmują wszystkie etapy cyklu życia oprogramowania.
Igor Bojko: „Idealnym przypadkiem jest sytuacja, gdy zaczynamy stosować praktyki DevOps już na początku projektu. Wspólnie z architektami planujemy, jaki rodzaj krajobrazu architektonicznego będzie miała aplikacja, gdzie będzie zlokalizowana, jak skalować i wybierać platformę. Obecnie w modzie jest architektura mikroserwisowa - dla niej wybieramy system orkiestracji: trzeba umieć zarządzać każdym elementem aplikacji z osobna i aktualizować go niezależnie od pozostałych. Inną praktyką jest „infrastruktura jako kod”. Tak nazywa się podejście, w którym infrastruktura projektu jest tworzona i zarządzana przy użyciu kodu, a nie poprzez bezpośrednią interakcję z serwerami.
Następnie przechodzimy do etapu rozwoju. Jedną z największych praktyk jest tutaj budowanie CI/CD: musisz pomóc programistom zintegrować zmiany z produktem szybko, w małych porcjach, częściej i bezboleśnie. CI/CD obejmuje przegląd kodu, przesłanie kodu głównego do bazy kodu oraz wdrożenie aplikacji w środowiskach testowych i produkcyjnych.
Na etapach CI/CD kod przechodzi przez bramki jakości. Za ich pomocą sprawdzają, czy kod wychodzący ze stacji roboczej programisty spełnia określone kryteria jakościowe. Dodano tutaj testy jednostkowe i interfejsu użytkownika. Aby zapewnić szybkie, bezbolesne i ukierunkowane wdrożenie produktu, możesz wybrać odpowiedni typ wdrożenia.
Praktycy DevOps mają swoje miejsce także na etapie wspierania gotowego produktu. Służą do monitorowania, przekazywania informacji zwrotnych, bezpieczeństwa i wprowadzania zmian. DevOps patrzy na wszystkie te zadania z perspektywy ciągłego doskonalenia. Minimalizujemy powtarzalne operacje i automatyzujemy je. Obejmuje to również migracje, rozszerzanie aplikacji i wsparcie wydajności.”
Jakie są zalety praktyk DevOps?
Gdybyśmy pisali podręcznik o nowoczesnych praktykach DevOps, na pierwszej stronie znalazłyby się trzy punkty: automatyzacja, przyspieszanie wydań i szybki feedback od użytkowników.
Cyryl Siergiejew: „Pierwszą rzeczą jest automatyzacja. Wszystkie interakcje w zespole możemy zautomatyzować: napisali kod - wdrożyli - sprawdzili - zainstalowali - zebrali opinie - wrócili na początek. Wszystko to dzieje się automatycznie.
Drugim jest przyspieszenie wydania, a nawet uproszczenie rozwoju. Dla Klienta zawsze ważne jest, aby produkt jak najszybciej trafił na rynek i zaczął przynosić korzyści wcześniej niż analogi konkurencji. Proces dostarczania produktu można udoskonalać w nieskończoność: skracać czas, dodawać dodatkowe znaki kontrolne, usprawniać monitorowanie.
Trzecim jest przyspieszenie otrzymywania opinii użytkowników. Jeśli ma uwagi, możemy od razu wprowadzić poprawki i natychmiast zaktualizować aplikację.”
Jak powiązane są pojęcia „inżynier systemowy”, „inżynier budujący” i „inżynier DevOps”?
Nakładają się na siebie, ale należą do nieco innych obszarów.
Inżynier systemowy w EPAM to stanowisko. Są na różnych poziomach: od młodszego do głównego specjalisty.
Inżynier budowy to raczej rola, którą można wykonać w projekcie. Tak nazywa się osoby odpowiedzialne za CI/CD.
Inżynier DevOps to specjalista, który wdraża praktyki DevOps w projekcie.
Jeśli to wszystko podsumujemy, otrzymamy coś takiego: osoba na stanowisku inżyniera systemowego pełni na projekcie rolę inżyniera kompilacji i bierze tam udział we wdrażaniu praktyk DevOps.
Czym dokładnie 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 uwzględniając interesy klienta.
Dużo rozmawialiśmy o automatyzacji - tym zajmują się przede wszystkim inżynierowie DevOps. To bardzo duży punkt, który obejmuje między innymi przygotowanie środowiska.
Cyryl Siergiejew: „Przed wdrożeniem aktualizacji do produktu należy je przetestować w środowisku strony trzeciej. Przygotowują go inżynierowie DevOps. Zaszczepiają kulturę DevOps w całym projekcie: wprowadzają praktyki DevOps na wszystkich warstwach swoich projektów. Te trzy zasady: automatyzacja, uproszczenie, przyspieszenie – wprowadzają wszędzie tam, gdzie się da.”
Co powinien wiedzieć inżynier DevOps?
W zasadzie musi posiadać wiedzę z różnych dziedzin: programowania, pracy z systemami operacyjnymi, bazami danych, systemami montażu i konfiguracji. Ich uzupełnieniem jest możliwość pracy z infrastrukturą chmurową, systemami orkiestracji i monitorowania.
1. Języki programowania
Inżynierowie DevOps znają kilka podstawowych języków automatyzacji i potrafią np. powiedzieć programiście: „A może zainstalujesz kod nie ręcznie, a za pomocą naszego skryptu, który wszystko automatyzuje? Przygotujemy dla niego plik konfiguracyjny, który będzie wygodny do odczytania zarówno dla Ciebie, jak i dla nas, a także będziemy mogli go w każdej chwili zmienić. Zobaczymy także, kto, kiedy i dlaczego wprowadza w nim zmiany.”
Inżynier DevOps może nauczyć się jednego lub więcej z tych języków: Python, Groovy, Bash, Powershell, Ruby, Go. Nie jest konieczna ich dogłębna znajomość – wystarczą podstawy składni, zasady OOP i umiejętność pisania prostych skryptów do automatyzacji.
2. Systemy operacyjne
Inżynier DevOps musi wiedzieć, na jakim serwerze produkt zostanie zainstalowany, w jakim środowisku będzie działał i z jakimi usługami będzie współpracował. Możesz wybrać specjalizację w rodzinie Windows lub Linux.
3. Systemy kontroli wersji
Bez wiedzy o systemie kontroli wersji inżynier DevOps nie ma szans. Git to obecnie jeden z najpopularniejszych systemów.
4. Dostawcy chmury
AWS, Google, Azure – szczególnie jeśli mówimy o kierunku Windows.
Cyryl Siergiejew: „Dostawcy rozwiązań chmurowych dostarczają nam serwery wirtualne, które idealnie pasują do CI/CD.
Instalacja dziesięciu serwerów fizycznych wymaga około stu operacji ręcznych. Każdy serwer musi zostać ręcznie uruchomiony, zainstalowany i skonfigurowany wymagany system operacyjny, zainstalowany na tych dziesięciu serwerach naszą aplikację, a następnie dziesięć razy wszystko dokładnie sprawdzone. Usługi chmurowe zastępują tę procedurę dziesięcioma linijkami kodu, a dobry inżynier DevOps powinien być w stanie z nimi pracować. Oszczędza to czas, wysiłek i pieniądze – zarówno dla klienta, jak i firmy.
5. Systemy orkiestracji: Docker i Kubernetes
Cyryl Siergiejew: „Serwery wirtualne podzielone są na kontenery, w każdym z nich możemy zainstalować naszą aplikację. Gdy kontenerów jest dużo, trzeba nimi zarządzać: włączyć jeden, wyłączyć drugi, zrobić gdzieś kopię zapasową. Staje się to dość złożone i wymaga systemu orkiestracji.
Wcześniej każda aplikacja obsługiwana była przez osobny serwer – wszelkie zmiany w jego działaniu mogły mieć wpływ na użyteczność aplikacji. Dzięki kontenerom aplikacje zostają izolowane i działają osobno – każda na własnej maszynie wirtualnej. Jeśli wystąpi awaria, nie ma potrzeby tracić czasu na szukanie przyczyny. Łatwiej jest zniszczyć stary pojemnik i dodać nowy.”
6. Systemy konfiguracyjne: Chef, Ansible, Puppet
Jeśli chcesz utrzymać całą flotę serwerów, musisz wykonać wiele tego samego rodzaju operacji. Jest to długie i trudne, a praca ręczna również zwiększa ryzyko błędu. Tutaj z pomocą przychodzą systemy konfiguracyjne. Z ich pomocą tworzą skrypt łatwy do odczytania dla programistów, inżynierów DevOps i administratorów systemów. Skrypt ten pomaga automatycznie wykonywać te same operacje na serwerach. Zmniejsza to liczbę operacji ręcznych (a co za tym idzie, liczbę błędów).
Jaką karierę może zbudować inżynier DevOps?
Możesz rozwijać się zarówno w poziomie, jak i w pionie.
Igor Bojko: „Z punktu widzenia rozwoju poziomego inżynierowie DevOps mają teraz najszersze perspektywy. Wszystko ciągle się zmienia, a umiejętności można rozwijać w różnych obszarach: od systemów kontroli wersji po monitorowanie, od zarządzania konfiguracją po bazy danych.
Możesz zostać architektem systemu, 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 projekt Phoenix i podręcznik DevOps. To są prawdziwe filary filozofii DevOps, przy czym pierwszy jest dziełem fikcyjnym.
- Poznaj technologie z powyższej listy: samodzielnie lub poprzez kursy online.
- Dołącz jako inżynier DevOps do projektu open source.
- Ćwicz i oferuj praktyki DevOps w swoich projektach osobistych i zawodowych.
Źródło: www.habr.com