trzy drogi devops

Trzy drogi DevOps i co z nich wynika

Książka “Projekt Feniks. Powieść o IT, modelu DevOps i o tym, jak pomóc firmie w odniesieniu sukcesu” stanowi idealny łagodny wstęp do tej metodyki. Jestem przekonany, że po jej przeczytaniu czytelnik nie raz i nie dwa krzyknie “ależ ja spotkałem podobnego człowieka/sytuację!”. Definiuje ona i pokazuje w działaniu trzy główne zbiory zasad DevOps (nazywane też drogami DevOps). Dzisiaj właśnie o tych zasadach.

Daniel Rosły. DevOps Engineer oraz Administrator Aplikacji w Robert Bosch. Od początku kariery w IT związany z zarządzaniem konfiguracją, zarządzaniem świadczeniem usług IT, a potem DevOps. Kompetencje w tych obszarach zdobywał współpracując z jednymi z największych projektów realizowanych w kraju. Pracuje w modelu DevOps od czasów sprzed wynalezienia tej nazwy. Aktualnie odpowiada za całość łańcucha narzędzi wytwórczych dla jednej z kluczowych grup projektów informatycznych realizowanych na potrzeby wszystkich działów produkcyjnych w firmie.


Pierwsza droga: Zasady przepływu, nazywane też myśleniem systemowym (ang. Systems Thinking).

Druga droga: Wzmacnianie sprzężeń zwrotnych (ang. Amplify Feedback Loops).

Trzecia droga: Kultura ciągłego uczenia się i eksperymentowania (ang. Culture of Continual Experimentation and Learning).

Zrozumienie konsekwencji tych trzech zasad oraz uświadomienie, jakie powszechnie występujące w IT problemy one rozwiązują pozwala zrozumieć przyczyny wielkiego sukcesu metodyki DevOps a w konsekwencji błyskawicznego jej rozpowszechnienia. Zanim przejdziemy do szczegółowego omówienia dróg DevOps, warto przedstawić poniższy diagram obrazujący związki pomiędzy nimi:

droga devops

Powyższy diagram można podsumować następująco: 

Pierwsza droga zaleca dbanie o sprawność przepływu efektów pracy z obszaru wytwarzania do obszaru operacji (a tym samym do klienta). Druga zaleca dbanie o efektywny przepływ informacji z obszaru operacji do obszaru wytwarzania. Trzecia droga zaleca dbanie o dwa wcześniejsze przepływy i ustawiczne wzmacnianie/poprawianie ich.

Opiszemy tu hasłowo tematy związane z trzema drogami DevOps, po więcej szczegółów odsyłając zainteresowanego czytelnika do odpowiedniej literatury, na przykład do Gene Kim, Patrick Debois, John Willis, Jez Humble, John Allspaw “DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji” wyd. polskie Helion 2017, tłumaczenie Radosław Meryk.

(Poprzednia część artykułu znajduje się tutaj)

Trzy drogi DevOps

Droga pierwsza, czyli przepływ

Zasady przepływu sprowadzają się do prostej rekomendacji: zalecają podjęcie działań mających na celu maksymalne skrócenie czasu od złożenia zamówienia przez klienta do wdrożenia realizującej zamówienie funkcjonalności na środowisku produkcyjnym.

I to właśnie zmiany całości procesu produkcji oprogramowania jakie należy wprowadzić w celu realizacji powyższej zasady mają bardzo daleko idące konsekwencje. Najważniejsze z tych rekomendowanych do wprowadzenia zmian to:

  • Zmniejszenie rozmiarów partii realizowanych zmian.

Ta rekomendacja wynika z ducha zwinnych procesów produkcji i nie jest charakterystyczna wyłącznie dla DevOps. Jej wdrożenie jest uwarunkowane zarówno technicznie, jak i organizacyjnie, ale umożliwia znaczne uproszczenie samego procesu wytwórczego poprzez min. odejście od wielkich zespołów realizujących pojedyncze zmiany. Małe zespoły (których rozmiar określa się często jako “zespół na dwie pizze”) są zwykle sprawniejsze i wymagają mniej dodatkowej pracy związanej z koordynacją i zarządzaniem.

Dodatkową, niebanalną korzyścią z możliwości dzielenia większych zmian i realizowania ich mniejszymi partiami jest zwykle możliwość szybszego dostarczania klientowi funkcjonujących części całości zamówionej zmiany.

  • Zmniejszenie interwałów pracy.

Jest to również standardowa rekomendacja metodyk zwinnych. Przyspieszenie cyklu realizacyjnego przy jednoczesnym zmniejszeniu rozmiarów realizowanej pracy, wśród wielu innych korzyści daje min. większą elastyczność w projekcie, czyli umożliwia szybsze reagowanie na nieoczekiwane sytuacje.

  • Zmniejszenie ilości pracy w toku.

Dwie powyższe rekomendacje mają tę konsekwencję, że przyczyniają się do zmniejszenia ilości prac rozpoczętych, ale jeszcze nie skończonych. To również daje oszczędności związane choćby z nie generowaniem dodatkowych kosztów (a jest nimi np. praca zespołu “zamrożona” w takich nie udostępnionych klientowi zmianach).

  • Spowodowanie żeby praca była widoczna.

Jest to pierwsza nieoczywista zmiana rekomendowana przez DevOps. Aby zrozumieć jej sens należy wrócić do analogii z metodyką Lean i zastanowić się, co powoduje, że widać iż na jakimś stanowisku zgromadziło się zbyt wiele pracy do wykonania. W przypadku fabryki jest to bardzo proste i wystarczy rzut oka na halę produkcyjną: przy niektórych stanowiskach zgromadzone jest po prostu dużo materiałów które służą do wykonywania pracy.

Tak rozumiana praca nie jest widoczna w przypadku technologii informatycznych. Nie da się “na pierwszy rzut oka” określić, gdzie dokładnie spiętrzają się zadania do zrobienia. Do tego potrzebny jest mechanizm monitorowania wykonywania pracy, czyli właśnie spowodowanie, że stanie się ona widoczna, czyli będzie można zawsze określić, gdzie i od kiedy aktualnie jest wykonywana. 

Rekomendacja ta jest ważna jeszcze z jednego powodu. W przypadku fabryki przemieszczanie pracy między różnymi etapami jest bardzo widoczne – szczególnie gdy odbywa się to wstecz normalnego procesu produkcji. Dzieje się tak dlatego, że trzeba fizycznie przemieścić materiały między miejscami pracy. W przypadku technologii informatycznych nie ma takiego “problemu”. Przemieszczanie pracy odbywa się często za pomocą jednego “kliknięcia” – np. przepisania zadania w systemie. 

Dzieje się to równie łatwo w przód, jak i wstecz procesu biegu strumienia wartości technologii. Powyższa cecha przyczynia się do powstawania znanego wszystkim informatykom zjawiska “ping-pong”, czyli cyklicznego przekazywania pracy między dwoma lub więcej wykonującymi ją jednostkami. Zjawisko to jest szczególnie powszechne a więc i uciążliwe, gdy “ping-pong” występuje między dwoma zespołami.

Najczęstszą realizacją tej rekomendacji jest wdrożenie tablic kanban. Jakie korzyści przynosi?

  • Eliminowanie przestojów i opóźnień w procesie.

Rekomendacja ta jest blisko związana z poprzednią, wiąże się jednak z analizą i ewentualną modyfikacją wszystkich tych cech organizacji, które mają wpływ na powstawanie przestojów. Z najważniejszych można wymienić kilka przykładowych:

  • Kwestia zlokalizowania zespołu operacji w stosunku do zespołu wytwórczego. Funkcjonowanie tych zespołów jako oddzielne działy, łączenie, lub w rozwiązaniu mieszanym ma bardzo daleko idące konsekwencje dla efektywności procesu. Temat ten jest opisany bardziej szczegółowo w jednym z kolejnych rozdziałów.
  • Zmniejszenie liczby koniecznych tzw. “przełączeń kontekstu” – tak na poziomie indywidualnym, jak i organizacyjnym. [Pojęcie “zmiana kontekstu”, znane każdemu programiście oznacza konieczność zmiany tematu nad którym dana osoba/zespół pracuje. Jest to zwykle operacja bardzo kosztowna czasowo (trzeba poświęcić czas na np. zapoznanie się lub przypomnienie sobie tematu nad którym rozpoczyna się pracę) – zmniejsza się tym samym efektywność pracy.]
  • Znajomość rzeczywistych czasów realizacji zadań dla poszczególnych osób/zespołów. Pozwala wykrywać te miejsca w procesie, gdzie kolejkowane są zadania, które to sytuacje mogą generować bardzo duże opóźnienia w realizacji całości prac.
    Przykładowo, jeśli jakaś osoba ma zrealizować zadanie trwające zwykle 1h, a ma w kolejce już 4 takie zadania, to średni czas realizacji tego zadania wyniesie 5h, z czego zadanie spędzi 80% czasu oczekując na realizację. Praktyka priorytetyzowania zadań powoduje dodatkowo, że zadania o niskim priorytecie (zwykle to one generują dług technologiczny) mają jeszcze dłuższe czasy oczekiwania.
  • Dbanie o nieprzekraczanie określonego poziomu zajętości elementów procesu.

Warunek bardzo blisko związany ze wskazanym wyżej, nie dotyczy jednak wyłącznie osób i zespołów, ale również zasobów technicznych wykorzystywanych w procesie produkcji. W książce “Projekt Feniks” umieszczony został bardzo sugestywny wykres pokazujący konsekwencje stopnia zajętości zasobu (w procentach) dla czasu oczekiwania na ten zasób. 

zajętość devops

Długość kolejki lub czas oczekiwania na zasób w zależności od jego zajętości – za: Gene Kim, Kevin Behr, George Spafford „Projekt Feniks. (…)”

Wbrew intuicji, zależność ta nie jest liniowa, a wykładnicza – po szczegóły odsyłamy czytelnika do w/w książki.

  • Zwracanie uwagi na sprawność procesu jako całości.

Wydawałoby się, że stwierdzenie to jest oczywiste w świetle powszechnej świadomości faktu, że organizacja realizująca zamówienie klienta jest tylko tak sprawna jak jej najmniej sprawny element. Ta rekomendacja pojawiła się między innymi dlatego, że często z pozamerytorycznych powodów proces doskonalenia organizacyjnego jest ograniczany do wybranych fragmentów całości, co nie gwarantuje pożądanych efektów.

  • Zabezpieczenie funkcjonującego procesu przed nieuprawnionymi działaniami.

DevOps rekomenduje, aby przestrzeganie procedur bezpieczeństwa był wymuszane w większym stopniu poprzez odpowiednio funkcjonujące narzędzia, a w mniejszym przez ręczne procedury. Te drugie są dużo bardziej podatne na błędy ludzkie i bycie świadomie omijanymi.

Te, oraz inne nie wymienione tu, rekomendowane zmiany przekładają się na konkretne tematy techniczne, takie jak:

  • Wybór architektury wspierającej odpowiednią granulację procesu realizacji zmian i ich wysoki stopień niezależności. Realizacja w metodyce DevOps projektu wytwarzania dużej monolitycznej aplikacji jest siłą rzeczy utrudniona. Najbardziej “naturalne” w opisywanej tu sytuacji są architektury rozproszone, np. oparte o mikrousługi.
  • Procesy produkcji oparte na ciągłym budowaniu, ciągłej integracji, testach automatycznych.
  • Procesy wydawania nowych wersji oparte na ciągłym dostarczaniu (ang. continuous delivery) lub najlepiej ciągłym wdrażaniu (ang. continuous deployment) wsparte przez automatyzację nie tylko samego procesu instalacji, ale i przygotowania infrastruktury i jej konfiguracji (tzw. “infrastruktura jako kod” i “konfiguracja jako kod” – opisane dalej).
  • Mechanizmy związane ze śledzeniem realizacji poszczególnych zadań w strumieniu wartości technologii z użyciem tablic (jap. kanban).

Aspekt techniczny DevOps został omówiony szerzej w kolejnym rozdziale.

Droga druga, czyli sprzężenia zwrotne

Zasady sprzężenia zwrotnego zalecają umożliwienie stałego, szybkiego i niezakłóconego przepływu informacji wstecz kierunku strumienia wartości technologii na wszystkich jego etapach. Zasady sprzężenia zwrotnego są drugim niezbędnym składnikiem metodyki DevOps ze względu na fakt, że proces produkcji oprogramowania jest zjawiskiem niezwykle złożonym, składającym się z niezliczonej ilości indywidualnych, ale i współzależnych kroków podejmowanych przez różne osoby i zespoły. 

Poza przypadkami najmniejszych projektów, zwykle też nie ma jednej osoby, która zna całość wszystkich czynności realizowanych w ramach projektu. W związku z tym błędy związane z koordynacją pracy i nieprzewidywalne konsekwencje nieuświadomionych współzależności między czynnościami są w zasadzie nie do uniknięcia. To co jest kluczowe w takiej sytuacji i to co rekomenduje DevOps, to aby wprowadzić mechanizmy umożliwiające rozwiązywanie problemów zaraz po ich wystąpieniu i gromadzić wiedzę zapobiegającą ich powtórzeniu. A do tego, aby takie działania były możliwe, potrzebna jest przede wszystkim informacja o wystąpieniu problemów – informacji tej powinny dostarczać odpowiednie narzędzia – najlepiej w pełni automatycznie. A więc zasady drugiej drogi są w dużej części realizowane przez dość powszechnie znane rozwiązania informatyczne z obszaru telemetrii. 

Z konkretnych rekomendacji, na jakie przekłada się powyższe zalecenie można wymienić następujące:

  • Wykorzystywanie ciągłej integracji.

Jest to pierwszy, najbardziej podstawowy mechanizm dający programistom wprowadzającym zmiany w kodzie informację zwrotną o spełnianiu przez nie najprostszych kryteriów poprawności, czyli tego, że aplikacja jako całość da się zbudować po zmianie i da się poprawnie zainstalować na środowisku integracyjnym.

Oczywiście mechanizmy ciągłej integracji powinny być w pełni automatyczne począwszy od reakcji na zmiany kodu aż po wysłanie do zainteresowanych osób raportu z zainstalowanego środowiska.

  • Wykorzystywanie testowania automatycznego.

Testowanie automatyczne jest kolejnym stopniem zapewniającym wykrywanie błędów w oprogramowaniu na możliwie najwcześniejszym etapie. Jest to znany temat, więc nie będziemy się tu koncentrować się na jego opisie. Należy jednak podkreślić, że DevOps rekomenduje pełną automatyzację zarówno testów jednostkowych, jak i funkcjonalnych – najlepiej wykonywanych każdorazowo podczas procesów CI/CD (zobacz dalej).

  • Stałe udostępnianie danych z monitorowania systemów.

Funkcję jaką pełni testowanie automatyczne na początku strumienia wartości technologii pełnią systemy monitoringu w jego końcowej części. Warto powtórzyć tu kilka standardowych cech takich systemów, które czynią je bardzo przydatnymi w realizacji celów stawianych przez drugą drogę:

  • Udostępnianie na bieżąco danych o funkcjonowaniu systemu w rzeczywistym (nie-testowym) środowisku, czyli w produkcji. Często dodatkowo monitorowaniu podlegają wybrane środowiska testowe, takie jak środowisko do testów akceptacyjnych czy testów wydajnościowych – pozwala to zdobyć niektóre informacje zanim system znajdzie się w produkcji.
  • Monitorowaniu mogą podlegać nie tylko (a nawet nie przede wszystkim) techniczne aspekty działania systemu, ale również te aspekty które mają bezpośredni przełożenie na odczucia użytkowników z jego wykorzystywania. Przykładowo, czasy odpowiedzi poszczególnych funkcjonalności.
  • System może posiadać mechanizmy automatycznego wykrywania anomalii i powiadamiania o nich. Uwalnia to operatorów od ciągłego nadzorowania go i pozwala szybko powiadamiać nie tylko ich, ale i inne zainteresowane osoby. Niektóre z systemów w przypadku wykrycia anomalii automatycznie gromadzą zbiór dodatkowych (standardowo nie zbieranych) informacji o systemie w celu późniejszego ułatwienia analizy przyczyn wystąpienia anomalii, czyli tzw. migawkę systemu (ang. snapshot).
  • Maksymalnie szybkie udostępnianie twórcom (programistom) informacji o efektach ich pracy w środowisku produkcyjnym.

Ostatnim z ważnych strumieni informacji pozwalających realizować założenia drugiej drogi są informacje zwrotne od użytkowników systemu. Tak jak w przypadku innych strumieni informacji zwrotnych, tak i dla zgłoszeń o błędach na produkcji DevOps rekomenduje udrażnianie i przyspieszanie ich przepływu. Oczywiście, nie oznacza to, że bezrefleksyjnie popiera bezpośrednie i niczym nieograniczone zgłaszanie błędów przez użytkowników bezpośrednio  programistom. Jak zawsze, w takiej sytuacji konieczne jest odnalezienie “złotego środka”, z jednej strony zapewniające sprawność przekazywania informacji zwrotnej, a z drugiej przeciwdziałającego marnowaniu czasu wysoko wykwalifikowanych specjalistów na czynności, które mogą być wykonywane przez inny personel – i tutaj z pomocą przychodzi na przykład ITIL (zobacz).

Drugim aspektem rekomendacji DevOps w tym obszarze jest podejście do tematu rozwiązywania krytycznych problemów. Otóż DevOps rekomenduje tutaj coś, co na pierwszy rzut oka wydaje się sprzeczne z ustalonymi zwykle praktykami, czyli grupowe rozwiązywanie problemów (tzw. swarming – od angielskiego słowa oznaczającego “rój”). Zwykle uważa się, że odciąganie większej ilości osób do rozwiązania problemu nie jest dobre, bo zakłóca inne prace (np. poprzez “przełączanie kontekstu”), ale w przypadku krytycznych sytuacji DevOps uważa, że korzyści polegające z jednej strony na opanowaniu problemu zanim stanie się jeszcze bardziej krytyczny (np. dojdzie do najwyższego kierownictwa klienta), a z drugiej strony rozpowszechnianie wiedzy i gromadzenie doświadczenia jest warte poniesionych kosztów organizacyjnych. Oczywiście, przy założeniu, że takie sytuacje stanowią wyjątki od normalnego funkcjonowania systemu, a nie normę.

Wdrożenie praktyk rekomendowanych przez drugą drogę realizuje kilka celów. Ich głównym celem jest stworzenie efektywnego i odpornego na błędy (korygującego je w miarę możliwości samoczynnie i w miejscu wystąpienia) środowiska, w którym realizowany jest projekt. Zapewnia ono też budowanie wiedzy i doświadczenia w zespole wytwórczym. Dzięki szybkości otrzymywania informacji budowana jest też świadomość odpowiedzialności za efekty swojej pracy. Świadomość autora, że zmiana, którą przygotowuje znajdzie się na produkcji w ciągu kilkudziesięciu minut po tym jak podejmie decyzję, że ta zmiana jest gotowa i że w przypadku problemów ze zmianą dostanie jeszcze w tym samym dniu “wezwanie na dywanik” (określenie w przenośni – DevOps w trzeciej drodze przestrzega przed wprowadzaniem tego typu atmosfery pracy) bardzo szybko uświadamia konsekwencje własnych błędnych decyzji i motywuje do uczenia się.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
wysokie-widelki-ogloszenie
Czy wysokie widełki to tylko clickbait? Devdebata