DevOps – pojęcie niezrozumiane

Na LinkedIn / Facebooku i innych forach z ogłoszeniami o pracę wręcz roi się od ogłoszeń zatytuowanych „DevOps enginner” albo lepiej, jako „DevOps Hero”. Zatem czym się zajmuje DevOps engineer? Najczęściej automatyzacją stawiania środowisk za pomocą Ansible, rozwiązań chmurowych (Azure/AWS/Google Cloud), JIRA i tak dalej. Generalnie, człowiek, który zna się na wszystkim. Żartobliwie mówi się, że osoba taka to administrator dla programistów. Jak mówi sam autor tego terminu, używanie tego słowa stało się po prostu modne. Jednakże wg metodyki DevOps, nie ma kogoś takiego jak inżynier DevOps. Intrygujące? Zapraszam na wycieczkę po tym świecie.

Historia DevOps

DevOps powstał z połączenia dwóch słów: Development i Operations, a za ojca tego ruchu uważa się Patricka Debois. Patrick pracował wtedy jako IT Consultant i był niesamowicie sfrustrowany brakiem komunikacji i rozłącznością zespołów deweloperskich, a operacyjnych (zjawisko to jest określanie jako Wall of Confusion). Pracując nad migracją całego data center dla rządu w Belgii, zorientował się, że tak naprawdę stoi okrakiem pomiędzy dwoma zespołami. Był więc członkiem zespołu podążającego zgodnie z metodologią Agile, a także zupełnie nie przewidywalnego zespołu operacyjnego.

Podczas konferencji Agile w Toronto w roku 2008, Andrew Shafer zaproponował, by tematem dyskusji stała się sesja zatytułowana „Agile Infrastructure”. Jednakże, sesja ta musiałą zostać anulowana bo… nikt nią nie był zainteresowany za wyjątkiem Patricka. Oboje podjęli długą rozmowę o ich własnych, frustrujących doświadczeniach. Była ona nadzwyczaj owocna – w rezultacie powstała grupa Agile System Administration w ramach grup Google (wciąz obecna, ale mało aktywna – możecie ją odwiedzić pod tym linkiem). W końcu powstało wydarzenie DevOpsDays, konferencja została przeprowadzona w dniach 30-31 października 2009 roku w Belgii. Wydarzenie wywołało ogromne zainteresowanie wśród administratorów, programistów i menadżerów na całym świecie. Od tego czasu, DevOpsDays zawitały do innych krajów popularyzując ruch.

Chociaż dostawcy oprogramowania i analitycy początkowo zupełnie zignorowali to poruszenie, to wywołało ono nie małe poruszenie wśród osób poszukujących nowych rozwiązań. W rezultacie, „do młynu zaczęła płynąć woda” i zaczęły z tego wynikać fantastyczne projekty – powstały między inymi Vagrant, Puppet, Chef i FPM – narzędzią, bez których wielu nie wyobraża sobie automatyzacji infrastruktury.

Czym jest DevOps?

Jak już po części wspomniałem na początku wpisu, DevOps ma ułatwić kooperację pomiędzy różnymi zespołami. Ma na celu usprawnić dostarczanie oprogramowania z mniejszą ilością błędów i lepiej dostosowanym do klienta. DevOps czerpie garściami z innych dobrze znanych metodyk: Lean, Agile, Kaizen znają tu swoje miejsce. DevOps to odpowiedź na bardzo szybki rozwój technologii, zmienność wymagań w czasie.

Korzyściami wprowadzania DevOps w firmie są:

  • Redukcja czasu dostarczania oprogramowania – w tradycyjnym podejściu, klient z dostawcą spotykali się na uzgodnieniu wymagań, czasem kilka razy z pytaniem „Jak tam idzie?” i ostatecznie w momencie wdrożenia. W idealnym świecie, nie byłoby w tym podejściu nic złego, pieniądze za rozwiązanie i wszyscy są zadowoleni. Jak to zwykle bywa, w praktyce jest zupełnie inaczej. Dostarczenie oprogramowania trwało często kilka lat, wiele rzeczy przedawniło się w międzyczasie a system zawierał i tak mnóstwo błędów. DevOps zakłada, że oprogramowanie trzeba dostarczać w mniejszych porcjach, ale szybciej. Klient powinien zostać zapraszany na tzw. demo, podczas którego zbierana jest informacja zwrotna. Idąc tą drogą, jedna ze stron widzi postęp i może od razu stwierdzić, co nie spełnia wymagań albo co należy dodać, druga strona może się dowiedzieć, czy idzie w dobrą stronę.
  • Odporność na zmiany – DevOps w zasadzie używa bardzo ładnego słowa „antifragile”, ale rozwijając korzyść – organizacja, która wdrożyła metodę dobrze po prostu polubi zmiany, stają się silniejsi w obliczu stresu i kryzysu. No kto by tak nie chciał? 🙂 Świat IT zmienia się bardzo szybko, spójrzcie tylko wstecz czym świat żył jeszcze nie dawno. Biznes wymaga, aby organizacje adaptowały się do zmian, kryzysu w sposób autonomiczny podejmowały decyzje co i jak dostarczać na rynek.
  • Autonomiczne zespoły – to moja ulubiona korzyść 🙂 zespół ma jeden cel – dostarczyć funkcjonalność i ją utrzymywać. Sposób w jaki oni to zrobią to sprawa drugorzędna. Zespół sam się organizuje, wybiera technologię, sposób działania, testowania i tak dalej. W takim zespole unika się tzw. micro zarządzania, kiedy menadżer jest zbyt szczegółowy i za bardzo angażuje się w sposób pracy zespołu.
  • Zburzenie muru odpowiedzialności – Wall of Confusion to dość częsty problem w IT. Mieliście do czynienia z obwinianiem się wzajemnie pomiędzy ludźmi, że to nie mój problem, zapytajcie innych? I tak w kółko? Zauważyliście przy tym jak długo sprawa leży, zanim zostanie wykonana? Czas nie liczy się wtedy nie rzadko w dniach. Myślę, że obrazek poniżej choć śmieszny, doskonale oddaje realia tej sytuacji. DevOps zakłada, że zespół jest odpowiedzialny od początku do końca za dostarczony produkt. W myśl tego, nie tracimy czasu na obwinianie się, kto zawiódł, tylko staramy się rozwiązać problem.
  • Lepsze bezpieczeństwo – to wydaje się dość oczywisty benefit, częste testy, częste wydawanie małych porcji oprogramowania pozwala na wykrycie wielu błędów, być może nawet istotnych, których koszt naprawienia w dalszej fazie byłby wielokrotnie większy. Świetnie obrazuje to poniższy wykres:
Źródło: Applied Software Measurement, Capers Jones, 1996
  • Transparentność – całe szczęście dociera to do organizacji również nie idących zgodnie z przytaczaną tu metodą. Transparentność oznacza, że każda osoba w firmie z każdego zespołu jest świadoma i rozumie, co się dzieje w samej firmie, co się dzieje w systemie, w którym pracują i o co chodzi w serwisie, dla którego pracują. Będąc przejrzystym, nie mamy nic do ukrycia, co za tym idzie, pozbywamy się wielu nieprzyjemnych uczuć i zaczynamy sobie ufać nawzajem. Ja nie wyobrażam sobie, aby mój przełożony nie miał zaufania do mnie. Spotkałem się z taką sytuacją raz w życiu, była to jedna z motywacji do opuszczenia firmy.

Jakie zasady należy wdrożyć, aby móc nazywać się organizacją DevOps?

Należy podążać za tzw. pryncypiami DevOps, a jest ich 6:

  • Działania zorientowane na klienta – wszystkie akcje związane z budowaniem produktów i usług IT powinny się obracać wokół klientów – posiadanie bardzo krótkich pętli zwrotnych z prawdziwymi klientami i użytkownikami końcowymi jest obecnie konieczne, by sprawnie i w mądry sposób rozwijać swój produkt,
  • Twórz z wizją końca – w myśl tej zasady skupiamy się na prawdziwych potrzebach klientów i pracy nad serwisami i produktami rozwiązującymi te problemy. Innymi słowy – należy mieć pełne spojrzenie na tworzenie i użytkowanie wytwarzanych serwisów,
  • Odpowiedzialność od początku do końca – zespoły są zorganizowane „wertykalnie”, dlatego są odpowiedzialne w pełni za dostarczany produkt. Zespół Wertykalne tzn. zespół współzależnych ludzi pracujących nad wspólnym celem, za który wszyscy są wzajemnie odpowiedzialni. Brzmi zawile? Dla rozjaśnienia, posłużę się poniższym obrazkiem. Podpunkt a) oznacza tradycyjne podejście (horyzontalnie), podpunkt b) zespół wertykalny.
Źródło: Microservices Architecture Enables DevOps: an Experience Report on Migration to a Cloud-Native Architecture,Armin Balalaie, Abbas Heydarnoori, Pooyan Jamshidi (2016)
  • Autonomiczne, wielozadaniowe zespoły (Cross-Functional Autonomous Teams)- skoro zespół jest w pełni odpowiedzialny za produkt, musi być w pełni autonomiczny przez cały czas życia produktu. W jego skład będą więc wchodzić osoby z różnymi specjalnościami. Autonomiczne zespoły są wykluczone z tzw. micro-managementu. Raczej nie chcesz, żeby manager pytał o każde Twoje działanie i dlaczego tak, a dlaczego nie? DevOps to współpraca oparta na zaufaniu, więc nie ma tutaj miejsca na takie akcje,
  • Ciągłe ulepszanie (Continuous Improvement) – według mnie równie popularne hasło co DevOps, ale do rzeczy. W kulturze devopsowej bardzo duże skupienie jest nakierowane właśnie na ciągłe ulepszanie produktów oferowane klientom. Najczęściej optymalizacji podlegają minimalizacja strat (np. zwalnianie pamięci zamiast jej pochłaniania), zwiększenie prędkości i responsywności programu, cięcie kosztu (przez automatyzacje) czy łatwość dostarczenia (np. sposób instalacji programu),
  • Automatyzuj wszystko co możesz – czasem automatyzacja może być sztuką dla sztuki. Jednak w tej zasadzie chodzi o redukcję czasu spędzanego przez człowieka na tych samych działaniach. Ludzie są od kreatywnego myślenia, to skrypt ma założyć konto / dostarczyć środowisko. Kompleksowa automatyzacja oznacza prawdziwe zrozumienie wszystkich procesów wymaganych do wytworzenia produktu lub dostarczenia serwisu. Sama automatyzacja zapewnia przede wszystkim powtarzalność, oszczędność czasu i zdjęcie „czynnika ludzkiego” z możliwych błędów.

Czy DevOps to recepta na wszystko?

Chyba nie znajdę lepszej odpowiedzi od „to zależy”. Jeśli właśnie zaczynacie startup, to przeanalizujcie dokładnie tę metodę, gdyż koszt jej wdrożenia na tym etapie jest bardzo niski. W dużych organizacjach takie zmiany to prawdziwa rewolucja, ludzie za pewne trafią do nowych zespołów z obcymi ludźmi, co może im nie przypaść do gustu. Koszt reorganizacji jest więc bardzo duży (i to nie tylko finansowy). Jeśli po wnikliwej analizie dojdziecie do wniosku, że jednak warto, to bez dobrego planu to się nie uda.

A Wy jaką macie opinię na temat DevOps? Chwalicie czy nienawidzicie?

Marcin Kuchczyński

Wielki fan automatyzowania wszystkiego, co trzeba wykonać więcej niż 2 razy. Cierpliwie rozwijający się w kierunku rozwiązań chmurowych i raczkujący w sferze sztucznej inteligencji. W IT od 2016 roku.

Leave a Reply