DevOps, czyli będzie Pan zadowolony

16.09.2019 | Patryk Płonka

Tym razem prezentujemy artykuł nieco z przymrużeniem oka :) Jesteśmy ciekawi Waszego zdania na temat regularnie powtarzanego pojęcia, którego czasami nadużywamy. Zachęcamy do podzielenia się Waszą opinią.


Pewna fikcyjna, niczym niewyróżniająca się firma Soft-pol, siedziba główna:
- Witam pana konsultanta, chcemy zmniejszyć ilość fakapów na produkcji i słyszeliśmy, że są na to dobre metody – rzekł rezolutny dyrektor ‘Wiem-Lepiej’ wkraczając na salę konferencyjną.
- A co dokładnie chcielibyście poprawić?
- Chcemy wdrożyć DevOps ponieważ Agile już mamy ale czegoś nam jeszcze brakuje.
- Ok, DevOps to sposób organizacji pracy, ale zaczniemy od przeglądu i przygotujemy całościowy plan działania.
- Nie, nie, nie – rzekł lekko poirytowany pan ‘Wiem-Lepiej’ – My tego nie potrzebujemy. Wiemy co jest problemem, potrzebujemy tylko nowych narzędzi… Ech myślałem, że Pan nam pomoże.

Nawałnica bodźców

Codziennie jesteśmy zalewani falą przeróżnych informacji, porad oraz tutoriali. Zachęcani do konsumowania kolejnych treści za pomocą coraz to nowszych buzzwordów, czy podstępem poprzez zmyślny clickbait.
Zwykle okazuje się, że nie wnoszą one jednak niczego wartościowego do naszej pracy i przez to zaczynamy je wszystkie traktować co najwyżej jako chwilową modę. Ignorujemy większość chwytliwych sloganów marketingowych podświadomie czując, że to nic więcej niż tylko zdrowy rozsądek opakowany w miłe słowa i kolorowe slajdy. Takie podejście pozwala nam zachować spokój i nie dać się zwariować dzisiejszemu światu, tonącemu w ogromie informacji jakie napływają do nas praktycznie przez całą dobę.

Taka obronna postawa nie pozwala nam jednak zagłębić się w idei, która mogłaby wnieść nową jakość do naszego życia. Jako, że zwykle jesteśmy karmieni mocno przetworzoną treścią opakowaną w chwytliwe hasła, to nie dostrzegamy istoty tej informacji i dalej rozwiązujemy codzienne problemy sami, pomimo, że gotowe rozwiązanie było na przysłowiowe wyciągnięcie ręki. Klasyczny dzień z życia typowego ignoranta i malkontenta.

W tym przypadku brak zrozumienia to kluczowy problem, a wymówek jest dużo, począwszy od klasyków „bo nie miałem czasu”, „bo nikt mi nie powiedział”, „bo myślałem, że oni to zrobią”, aż po awangardę w stylu, „a my od zawsze tak robiliśmy” lub „dziwne, zawsze działało…”. Co ciekawe, jeśli sami udajemy się do lekarza to oczekujemy, że dogłębnie nas zbada, zrobi wywiad, postawi diagnozę, zaproponuje leczenie lub inne środki zaradcze i zweryfikuje ich skuteczność podczas kolejnej wizyty. Widać podobieństwo do klasycznego cyklu doskonalenia PDCA (Zaplanuj – Wykonaj – Sprawdź – Popraw), wszyscy go znamy a jednak zbyt rzadko stosujemy.

Kto z nas choć raz nie widział produkcyjnego „nie-dotykaj-bo-działa-a-nikt-nie-wie-jak” systemu albo pracował w metodyce Agile wdrożonej tak jakby Waterfallem? Dlaczego więc od lekarza oczekujemy dogłębnej diagnozy i dopasowanego leczenia, a we własnych firmach często bierzemy udział w projektach, które czasem wyglądają jakby je ktoś bezrefleksyjnie skopiował z innej firmy i zazwyczaj niezbyt precyzyjnie (o ile w ogóle) określił cele takiego projektu i wizję całego przedsięwzięcia.  

Link: https://www.azquotes.com/

Bądźmy jednak trendy

W dzisiejszym świecie chyba każdy z nas dobrze wie czym jest metodyka Agile, choć zapewne takie stwierdzenie wywoła kwaśny grymas na twarzy co niektórych jej trenerów. Agile został tak zaprojektowany aby wytworzyć synergię pomiędzy wszystkimi zaangażowanymi ludźmi w całym procesie rozwoju aplikacji. Efektem takiej współpracy ma być dostarczenie zmian w aplikacji najszybciej jak to jest możliwe, np. w odpowiedzi na feedback klientów lub ruch konkurencji.

Mam jednak wrażenie, że twórcy Agile skupili się przede wszystkim na wytwarzaniu w pocie czoła inkrementów, czyli efektów prac całego zespołu deweloperów, a zapomnieli o tym jakim problemem może okazać się zbyt mała automatyzacja procesu wdrażania tych wytworzonych zmian na środowisko produkcyjne. Czyli o całej pracy operacyjnej administratorów systemów, sieci, baz danych, itd. w konsekwencji zespół deweloperski działa nowocześnie oraz elastycznie, regularnie dostarczając nowe zmiany. Jednak dalej pojawia się niewidoczna na pierwszy rzut oka bariera, która zaburza regularność i elastyczność. Administratorzy w dobrej wierze, zgodnie z metodyką ITIL lub w wyniku trzymania się kurczowo swoich starych nawyków, kolejkują te zmiany na liście rzeczy do wykonania w kolejnych oknach serwisowych. Wszystko po to, by usługi działały stabilnie, wydajnie i nie powodowały niepotrzebnych pożarów.

Widzimy więc, że z jednej strony dla zespołów deweloperskich motywowanych przez biznes liczy się szybkość dostarczania nowych funkcjonalności, co czasem może wymagać pewnych kompromisów odnośnie jakości oprogramowania. Z drugiej strony dla adminów motywowanych przez audyt, liczy się stabilność i niezawodność, co często odbywa się kosztem tempa wdrażania innowacyjnych rozwiązań.

Tę próżnię zauważyli twórcy idei DevOps, która za cel obrała sobie dostarczenie wszystkich efektów prac deweloperów w jakości i w czasie oczekiwanym przez biznes. DevOps nie zastępuje Agile, a jedynie uzupełnia czy rozszerza go o kwestie wdrożenia, utrzymania, gromadzenia informacji o działaniu aplikacji na produkcji oraz analiz po awariach (np. postmortem).
Link: https://en.wikipedia.org/wiki/DevOps

Jeśli zapytasz 10 osób czym dla nich jest DevOps to prawdopodobnie otrzymasz 10 różnych odpowiedzi.
W mojej ocenie najtrafniejszym stwierdzeniem jest, iż DevOps to unia pomiędzy ludźmi, procesami i produktami, która pozwala nieprzerwanie dostarczać wartość końcowym użytkownikom naszych usług. Ta dostarczona wartość jest efektem realizowania misji firmy, dlatego kluczowa jest koncentracja na jej nieprzerwanym dostarczaniu. Motywuje nas to do dbania o najwyższą kulturę współpracy i komunikacji w organizacji, o dojrzałość zespołów, o zaangażowanie każdej pojedynczej osoby oraz o dobór odpowiednich narzędzi. W efekcie współpraca pomiędzy deweloperami a administratorami kwitnie. Obie strony odkrywają, że jednak posiadają ten sam cel, tą samą wizję i… jednak są po tej samej stronie barykady!

Owocami takiego partnerstwa są wspólne inicjatywy automatyzowania wszystkich rutynowych czynności od wytwarzania, wdrażania, konfiguracji, monitorowania po troubleshooting.

Więcej o DevOps w dobrej i nudnej książce „Effective DevOps”.
Link: https://azure.microsoft.com/pl-pl/resources/effective-DevOps/

Zatem zdetonujmy silosy

Dajcie ludziom swobodę działania, a zaskoczą was swoją pomysłowością. - Peter F. Drucker

Zbudowanie unii pomiędzy ludźmi, procesami i produktami jest możliwe jedynie jeśli pozbędziemy się barier w organizacji i stworzymy dojrzałą kulturę współpracy.

Zaangażowanie i koordynacja wielu zespołów z różnych departamentów w celu wdrożenia nowej funkcjonalności jest czasochłonna, a cały proces podatny na pomyłki. Elementem, który może pomóc zespolić wszystkie współpracujące ze sobą zespoły jest poczucie wspólnej odpowiedzialności za finalną usługę udostępnianą naszym klientom.
Zaprojektujmy cały proces rozwoju oprogramowania tak, aby przebiegał bez zakłóceń od pierwszego commita do repozytorium aż po deploy na produkcję. Nic bardziej nie zmniejsza zaangażowania od czasu oczekiwania na reakcję innego zespołu, kiedy już skończyliśmy naszą część.

Równie ważne jest zapewnienie szybkiej informacji zwrotnej wszystkim zaangażowanym osobom, zarówno tych zebranych od klientów jak i od nas. Pozwala to na szybsze wprowadzenie udoskonalenia, a to z kolei zwiększa jakość finalnego produktu oraz wzmacnia zaangażowanie wszystkich osób uczestniczących w  procesie. Przy okazji budujemy kulturę wspierającą tworzenie ewoluującego zbioru dobrych praktyk, innymi słowy dojrzałego procesu. 

Link: https://faasandfurious.com/

Niepowodzenia są nieodłącznym elementem postępu

Sukces polega na przechodzeniu od porażki do porażki bez utraty entuzjazmu. - Winston Churchill

Każda innowacja to sukces całego zespołu, całej organizacji. Oznacza, że potrafimy robić coś więcej, lepiej, szybciej i na pewno będzie to miało pozytywny wpływ na nasze usługi. Musimy jednak pogodzić się z tym, że nie każdą innowację da się wdrożyć w pierwszym podejściu. Każde  niepowodzenie zbliża nas jednak do jej uruchomienia, a wręcz jedno niepowodzenie może być katalizatorem innej zmiany, której normalnie byśmy nie wdrożyli.

Przeważająca większość niepowodzeń wynika najczęściej z niedoskonałości procesu. Przykładem może być brak zabezpieczenia przed ewentualną interferencją kilku równoczesnych zmian i w konsekwencji wystąpienie sytuacji, której nikt nie przewidział. Niepowodzenie nie jest nigdy wynikiem odizolowanych działań jednego pracownika i w konsekwencji nie jest jego winą, o ile nie zatrudniamy pracowników ze skłonnościami masochistycznymi. Skupianie się i obwinianie osoby, która zainicjowała ten efekt domina oddala nas od znalezienia głównej przyczyny problemu, sprzyja obniżeniu morale we wszystkich zespołach i zwiększeniu prawdopodobieństwa wystąpienie podobnego problemu ponownie w przyszłości.

Jeśli zamiast tego skupimy się na znalezieniu głównej przyczyny problemu to prawdopodobnie uda nam się wprowadzić do procesu zabezpieczenie przed wystąpieniem podobnej awarii w przyszłości nawet jeśli zmienimy zespół wykonujący daną operację. Co więcej jeśli zaakceptujemy niepowodzenie jako nieodłączny element postępu, to zaczniemy myśleć w kategoriach minimalizowania czasu trwania awarii a nie jej unikania za wszelką cenę. Wdrożenie odpowiedniego procesu, narzędzi pomaga wdrażać innowacyjne usługi bez strachu przed awarią i z minimalnym czasem niedostępności, często nawet niezauważalnym dla klientów.

Wprowadzajmy zmiany ewolucyjnie i automatyzujmy proces

Release early. Release often. And listen to your customers - Eric S. Raymond

Wydaje mi się, że wszyscy podświadomie czujemy, że ryzyko wdrożenia drobnej zmiany jest mniejsze niż ryzyko wdrożenia zmiany złożonej. W erze metodyki Agile nauczyliśmy się już, że dekompozycja zmian na jak najmniejsze elementy to jedyna opcja by dostarczyć usługę oczekiwaną przez końcowych użytkowników.

Nie możemy zapomnieć jednak o automatyzacji całego procesu wdrażania zmian i to natychmiast po ich wytworzeniu, aby wykorzystać dekompozycję kompleksowych zmian na drobne paczki. Wydajny i zautomatyzowany mechanizm CI/CD (Continous Integration / Continous Delivery) pozwala nam wykonać automatyczną aktualizację, wycofać się z tej zmiany jak tylko zauważymy, że coś idzie nie tak jak planowaliśmy, wykonać zmianę niezauważenie dla klienta (canary releases) oraz zweryfikować reakcje klienta w bezpiecznej grupie pilotażowej (testy A/B).

Link: https://faasandfurious.com/

Twórzmy kulturę i wdrażajmy narzędzia, które ją wspierają

Culture eats strategy for breakfast - Peter F. Drucker

Czy Netflix powstałby jako projekt waterfallowy? Czy Google przetrwałoby gdyby utrzymali  klasyczny podział departamentów na silosy? Chyba nie muszę odpowiadać na powyższe pytania. Wszystkie firmy odnoszące sukces zbudowały dojrzałą kulturę wewnątrz organizacji, będącą właściwie symbolem unii między pracownikami, procesami a produktami. Kultura to interakcje między ludźmi oraz między zespołami, poczucie wspólnoty wokół produktu, to osiągnięcia wspólnego celu oraz duma z jego osiągnięcia.

Interakcje i współpraca między pracownikami zanikają kiedy ta unia jest zaburzona, jeśli w organizacji istnieją bariery oznacza to, że nie czujemy się wspólnie odpowiedzialni za nasze usługi i zespoły współzawodniczą między sobą, bo posiadają różne priorytety. Dysfunkcyjne procesy również marnują całą naszą energię, ponieważ musimy pokonać tor przeszkód jaki sami sobie przygotowaliśmy, musimy improwizować, a na koniec dnia udawać super bohaterów i ratować nasz produkt. Brak zrozumienia potrzeb klientów, brak reakcji na feedback, brak pomysłu jaką wartość dostarczyć klientowi sprawia, że zaczynamy się kręcić w koło i podejmować złe decyzje.

Narzędzia również nie są w stanie zastąpić kultury, ale stanowią jej dopełnienie, pomagają zmultiplikować pozytywne wartości pozwalając ludziom rozwinąć skrzydła. Narzędzia bez wykształconej silnej kultury multiplikują absurdy organizacyjne i sprzeczne cele zespołów i w konsekwencji podcinają pracownikom skrzydła.

Starajmy się mierzyć wszystko co ma sens

Jeśli nie możesz czegoś zmierzyć, nie możesz tego poprawić - Peter F. Drucker

Szybsza reakcja na incydenty, szybsza diagnoza, mniej fałszywych alertów z systemu monitorującego, gruntowna ocena wpływu wdrożonej zmiany na wydajność aplikacji, śledzenie długofalowych trendów, czy mam wymieniać dalej?

Monitorowanie po automatyzacji kolejny kluczowy element DevOps, to nasze oczy i uszy w produkcie. Podejmowanie decyzji w oparciu o pełnię dostępnych danych jest dużo prostsze niż w przypadku kiedy takich danych nie zbieramy.
Szybka reakcja na incydenty jest również możliwa jedynie wtedy, kiedy jesteśmy w stanie szybko postawić diagnozę ponieważ wszystkie wymagane dane mamy już zebrane i zwizualizowane w czytelny sposób. W dłuższej perspektywie jesteśmy w stanie śledzić trendy i przewidywać wzrost zapotrzebowania na dodatkowe zasoby. Co więcej jesteśmy w stanie budować skalowalne usługi ponieważ widzimy jak zachowuje się nasz produkt, rozpoznajemy dobowe fluktuacje, przewidujemy trendy, a ilość sytuacji, która może nas zaskoczyć spada do zera.

Soft-pol, siedziba główna:
- Chcę poprawić wydajność zespołów, wydawać więcej ficzerów na produkcję… o jakieś 30% być szybciej na produkcji z naszymi nowymi produktami – oświadczył pan ‘Wiem-Lepiej’.
- Wie pan, tylko z backlogów wynika, że zagrożone są obecne terminy, czy nie odbije się to na jakości dostarczanych usług?
- To są manualne procesy, czego nie uda się zrobić wcześniej to wypuścimy jako fixy do usługi.
- Nie myśleliście o automatyzacji całej tej manualnej pracy?
- Wszyscy mi mówią, że się nie da, my jesteśmy specyficzni, u nas to wygląda inaczej niż w innych firmach – rzekł z niezmąconą pewnością w głosie pan ‘Wiem-Lepiej’.
- Może trzeba uporządkować i ustandaryzować proces, zunifikować zadania i zaopatrzyć się w odpowiednie narzędzia?
- Po co tak to komplikować? Nowe narzędzia wystarczą, damy sobie radę, zawsze dajemy – rzekł lekko poddenerwowany.

Soft-pol, jakiś czas później:
- Wiesz co już dwa miesiące nam pomagasz, ale ja nie widzę efektów, wydajność nie wzrasta, wszyscy robią dokładnie to samo, co wcześniej – odrzekł pan Wiem-Lepiej z nieukrywanym zawodem w głosie.
- Tylko wcześniej były wymagane nadgodziny, które były normą, teraz już nie są potrzebne. Poza tym widać, że ludzie boją się automatyzacji, że stracą pracę, bo nie będą potrzebni tak jak ten tester, co go pan zwolnił bo stwierdził, że „teraz jest mniej błędów”…
- Więc co proponujesz?
- Zaangażuj swoich pracowników w proces, daj im trochę wolności, spraw by poczuli się właścicielami swoich zadań. Niech je usprawniają, niech budują nowe standardy, wyznaczają sobie własne normy. Pozwól im się uczyć, niech stają się coraz bardziej wszechstronni.
- Żartujesz? Mam im płacić, by się im chciało pracować? Nie znasz jakiegoś narzędzia by ich pilnowało czy przestrzegają standardów? Może audyt?
- Tak, ale lepiej osiągnąć ten stan kiedy pracownicy sami dbają o jakość i terminy, mają wewnętrzną motywację i kontrolują się nawzajem. Zaangażuj ich i nagródź ich premią z zaoszczędzonych pieniędzy.
- Moment! Każdy z nich podpisał umowę, że będzie wykonywał swoją pracę i będzie to robił najlepiej jak potrafi. Ja mam im za to płacić dodatkowo? – wykrzyczał pan ‘Wiem-Lepiej’ – Myślę, że nie rozumiesz naszego biznesu, poradzimy sobie sami.

Link: https://turnoff.us/

Ale po co nam to…

Sądzę, że na świecie jest zapotrzebowanie jeszcze na jakieś 5 komputerów​ - Thomas Watson

Pomimo, że DevOps  jest ideą w miarę nową, czasem mylącą, dość nieprecyzyjną oraz obejmującą wiele aspektów i obszarów, to korzyści z niej wynikających jest na szczęście niewspółmiernie więcej. Zaczynając od poprawy relacji w zespołach i pomiędzy zespołami, zacierający się podział na DEV i OPS, warunki pozwalające na zbudowanie kultury poczucia wspólnej odpowiedzialności wspierającej innowacje i szalone pomysły, dające wymierną przewagę konkurencyjną na rynku.

Trzeba jednak uważać, patrząc przez pryzmat wdrożonych już metodyk Agile czy ITIL, że adopcja DevOps może okazać się nieraz karkołomnym spacerem przez pole minowe, nie wszyscy rozumieją DevOps tak jak my! Kto z nas nie słyszał o stanowisku inżyniera DevOps albo, że to jedynie inna nazwa automatyzacji. Internet sprawia, że zacierają się granice pomiędzy faktami oraz wyobrażeniami ludzi szczególnie jeśli taki przekaz jest publikowany w sieci przez osoby nie będące w tej kwestii ekspertami. Sprawia to, że definicja DevOps  rozmywa się i w ostateczności może stać się jedynie „ładniejszą” nazwą dla starych przyzwyczajeń.

Pełne zrozumienie idei jaka stoi za DevOps podnosi dojrzałość organizacji. Dodatkowo sprawia, że koszt pracy spada, a ludzie chętnie ze sobą rozmawiają bo zależy im na rozwiązaniu konkretnych problemów. Wtedy czują swoją sprawczość, jest to kultura w której tworzenie nieprzerwanej dyskusji mailowej jest niepożądane, samo zbieranie „dupokrytek” to jedynie wymówka oddalająca nas od faktycznego rozwiązania problemu. Poczucie sprawczości działa cuda, ludzie w gruncie rzeczy są przecież odpowiedzialni, w końcu jakoś radzą sobie w codziennym życiu. Jeśli czują, że mają realny wpływ na kierunek rozwoju produktu to chętnie się angażują, co zwiększa elastyczność całego zespołu i pozwala na szybszą reakcję podczas różnych nieprzewidywalnych sytuacji.

Przepis na sukces wydaje się zarówno prosty jak i skomplikowany, wystarczy tylko stworzyć unię pomiędzy ludźmi, procesami i produktami, która pozwala nieprzerwanie dostarczać wartość końcowym użytkownikom naszych usług.

Google twierdzi, że do sukcesu dzieli nas tylko 7 kroków:

  1. Zacznijmy od pilota małego projektu
  2. Wykorzystaj potencjał Open Source
  3. Wbudujmy bezpieczeństwo w proces rozwoju oprogramowania
  4. Zaaplikujmy najlepsze praktyki DevOps 
  5. Przeprowadźmy dogłębne szkolenia
  6. Ustalmy kulturę nie obwiniania się nawzajem
  7. Stwórzmy wspólne cele, promujmy transparentność oraz podejmujmy decyzje na podstawie twardych danych

Jak myślicie, czy to wystarczy?

Link: https://cloud.google.com/blog/topics/perspectives/seven-steps-to-making-DevOps-a-reality

Soft-pol, siedziba główna:
- Musimy coś zmienić, inaczej konkurencja zje nas żywcem – rzekł pan ‘Wiem-Lepiej’.
- DevOps pozwoliłby nam na ujednolicenie procesów, dostarczył motywację osobom i podniósł jakość naszych produktów – rzekł pan ‘Świadomy’.
- Mówisz o filozofii czy o konkretnych efektach?
- Przecież to jedno i to samo.
- Ale nie mamy już czasu, potrzebujemy efektu natychmiast.
- Uporządkujmy procesy, pozwólmy menedżerom skupić się na zarządzaniu i usprawnianiu, zamiast reagować na codzienne problemy. Te problemy rozwiążą wtedy sami pracownicy bez ich udziału.
- Jeszcze nigdy się nam coś takiego nie udało… – odrzekł z powątpiewaniem pan ‘Wiem-Lepiej’.
- Widzisz, do tej pory zaraz po wdrożeniu kończyło się zaangażowanie, wszystkich dopadała bieżączka i każdy wracał do starych nawyków.
- I czym się ma ten DevOps różnić od tego?
- Zreorganizujemy procesy zastępując złe nawyki dobrymi, dostarczymy ludziom proste i funkcjonalne narzędzia, a gdy zauważą, że im to wszystko pomaga w codziennej pracy to ich zaangażowanie nie zgaśnie.
- Wierzysz w bajki?
- Nie, ale ja tylko streściłem to co mówią sami szeregowi pracownicy. Dodatkowo nie oszukujmy się, być może nie uda się nam za pierwszym razem ale w końcu zrobimy to, w kolejnej iteracji – odrzekł z niesłabnącą pewnością pan ‘Świadomy’
- Chciałbym być takim optymistą…
- Mówisz, że potrzebujemy natychmiastowej zmiany, a tym czasem nic nie robisz oprócz bycia zwykłym malkontentem. Zacznijmy działać, wykorzystajmy kreatywność naszych pracowników, przecież każdego z nich cenisz za wykonywaną pracę.
- Okej, może masz rację. Może zbyt surowo oceniałem nasze inicjatywy patrząc przez pryzmat tych wszystkich kolorowych artykułów. Życie to paleta odcieni szarości a nie wybór między białym a czarnym.