DevOps — „symfonia kompetencji”

DevOps

Jak wszyscy wiemy, każda koncepcja zarządzania organizacją ma charakter „utopijny”, jest wynikiem pracy wielu wizjonerów, często też realizacja praktyczna mocno odbiega od oczekiwań stawianych czystej teorii. Blog ten chciałbym w całości poświęcić organizacyjnym aspektom wdrażania i stosowania pewnej koncepcji, zwanej dalej DevOps.

Czym DevOps jest teoretycznie, wie chyba każdy „nowoczesny informatyk” (https://pl.wikipedia.org/wiki/DevOps). Oczywiście zestaw definicji i kolorowych, uogólnionych „malunków”, dostępny pod postacią analiz wykonanych przez firmy konsultingowe i innych materiałów reklamowych, lecz skutecznie zaciemniający istotę zagadnienia, jest często największym problemem w dobrym rozumieniu przeróżnych zjawisk i odpowiednim odniesieniu ich do otaczającej nas rzeczywistości.

Do rzeczy więc. Rozwijając tytuł niniejszego artykułu, chciałbym użyć (być może karkołomnej) paraleli z dziedziną bliską nam wszystkim (mniej lub bardziej), a mianowicie z muzyką. Gdzież bowiem współgranie różnych umiejętności jest tak istotne, jak właśnie przy „arcyprecyzyjnym” wykonaniu zespołowego utworu muzycznego. Szczególną kunsztownością w tym względzie cechuje się oczywiście muzyka symfoniczna.

Dla symfoników cel jest jeden, wspólny — doskonałe współbrzmienie (doskonałość to rzecz względna — rzecz jasna) i jak najbardziej precyzyjna realizacja zamysłu kompozytora (ukochanego przez fanatycznych odbiorców, np. Ludwika van Beethovena), a to wszystko ze szczyptą (większą lub mniejszą) pewnej maniery wykonawczej charakterystycznej dla danego okresu muzycznego. Ale cóż to ma wspólnego z DevOps?

Wyobraźmy sobie taką sytuację. Mamy orkiestrę symfoniczną złożoną z samych znamienitych muzyków instrumentalistów. Dostają oni utwór muzyczny w formie zapisu na przykład takiego, jak przedstawiony poniżej (dla muzyków schematy systemów IT wyglądają „mniej więcej tak samo”). I zakładając, że mają podobną wiedzę muzyczną z zakresu notacji oraz niebywałe umiejętności techniczne zaczynają wykonanie utworu.

Xenakis metastasis

Pojawia się pytanie: czy będzie sukces artystyczny? Jeśli ktokolwiek kierował orkiestrą lub zespołami realizującymi skoordynowane zadania czuje, że odpowiedź nasuwa się sama — nie, nie będzie. Spowodują to oczywiście różnice w rozumieniu intencji, w interpretacji zapisu (muzycznego lub projektu informatycznego) itp. Gdy jeszcze dodamy do tego ograniczenie takie, że każdy z muzyków (lub programistów, czy jakichkolwiek uczestników zorganizowanej pracy) „robi swoją działkę” niezależnie od innych, bez uprzedniego porozumienia i poczucia „wykonawczej” więzi z nimi — mamy gotową katastrofę, nawet jeśli ów wykonawca działa w najlepszej wierze, dysponując najlepszą wiedzą i umiejętnościami.

Rozwijając paralelę, popatrzmy trochę z dystansu na pracę w złożonej organizacji, a w szczególności realizację różnych inicjatyw w zinformatyzowanym świecie biznesu. Funkcjonują tam zróżnicowane kompetencyjnie grupy ludzi (specjalistów) realizujące jednak te same cele, a przynajmniej uporczywie dążące do ich realizacji. Tymczasem, jak wszyscy wiemy, w wielu technikach zarządzania realizacja wspólnego celu, jakim jest np. sprawny proces sprzedaży (oparty na systemie informatycznym), ulega istotnej fragmentacji. Każdy obszar pracuje w wielu przypadkach całkiem niezależnie, często sekwencyjnie (naturalne w projektach kaskadowych), w swoim „silosie”, za wystarczające uznając bierne uczestnictwo w procesie przepływu informacji (jeśli w ogóle jest on wpisany w „kulturę organizacyjną”).

Wymianą informacji i znoszeniem „silosów” organizacyjnych zajmują się metodyki, takie jak Lean. DevOps jest jednak organizacyjnym dopełnieniem usprawnienia wymiany myśli i automatyzacji pewnych etapów realizacji (czytaj:).

Klucz do rozumienia DevOps

Żeby dobrze zrozumieć ideę DevOps, nie tylko w znaczeniu „nowoczesnych” narzędzi informatycznych i nowych nazw stanowisk specjalistycznych w firmie, należy z uwagą przyjrzeć się trzem aspektom pracy nad rozwiązaniem IT. Po pierwsze jakości, po drugie terminowości (czynnik „time-to-market”), po trzecie kosztowi wytworzenia danego systemu IT. Czyli zajmijmy się „dachem” „Lean Manufactory” — trzema najważniejszymi czynnikami powodzenia projektu informatycznego (i nie tylko).

Lean manufactory house

Dla przypomnienia oficjalna definicja terminu „jakość” z PN-EN 9000:2001 brzmi: „Jakość to stopień, w jakim zbiór inherentnych właściwości spełnia wymagania”.

Jak wiemy, kanoniczny projekt informatyczny jest poprzedzony fazą studium wykonalności i analizy. W tym „worku” mieści się oczywiście analiza biznesowa, w tym oczywiście ocena rentowności projektu, kosztu całkowitego jego realizacji itp. Jak również wiadomo, w klasycznym podejściu ten etap jest realizowany przez wąską grupę specjalistów z zakresu analizy technologicznej i biznesowej, przy aktywnym uczestnictwie tzw. „biznesu”, czyli zainteresowanych działów. Najczęściej, wypracowane koncepcje techniczne rozpoczynają fazę projektowania systemu — na tym etapie wyraźną dominantą jest już komponent informatyczny.

Projektowanie systemu w klasycznym, kaskadowym podejściu, jest realizacją techniczną wizji określonej w produktach fazy analitycznej (czytaj: w dokumentacji). Nie ma tu zbyt wiele miejsca na „usprawnienia” i „sugerowanie” innych, być może lepszych rozwiązań. Co ciekawe, w wielu przypadkach, projektanci systemów (lub „architekci techniczni”) realizujący fazę projektową bywają specjalistami z wiedzą znacznie wykraczającą poza technologię, tj. obejmującą materię procesową, w której przyszło im realizować projekty informatyczne. Już na tym etapie widzimy „dławienie” potencjału wiedzy.

Idąc dalej, sytuacja ma się podobnie z podziałem na pracę projektantów oraz tzw. programistów, czy „deweloperów”, którzy są zobligowani do realizacji wizji projektantów. Znów tracimy potencjał. I tak dalej, i tak dalej, aż do tzw. „admina”, który ma za zadanie fizyczne uruchomienie, zaprojektowanych i zaprogramowanych artefaktów, zgodnie z przewidzianym kosztem realizacji.

Wielu oczywiście wskaże tutaj możliwość wzajemnych konsultacji na etapie projektowania i tworzenia oprogramowania. Należy jednak wziąć tutaj pod uwagę fakt, że dysponujemy wtedy wiedzą niepełną, fragmentaryczną o rozwiązaniu (często jeszcze niedziałającym) i decyzje lub rekomendacje dotyczące np. potrzebnych zasobów infrastrukturalnych mogą być niedoszacowane lub nawet błędne. Najczęściej sytuacja taka kończy się kaskadowym zwiększeniem kosztu wytworzenia oraz wytracaniem „kontekstu”, tj. w kolejnych fazach projektu mamy niedoszacowanie faz następnych. Na przykład, w fazie analizy nie doszacujemy kosztów (ogólnych) faz projektowania, realizacji, wdrożenia. W fazie projektowania znów nie doszacujemy realizacji i wdrożenia. Dodatkowo, w wyniku pracy sekwencyjnej, a wtórnie pewnej izolacji informacyjnej, może pojawić się brak właściwego rozumienia pewnych cech systemu. W efekcie znane są przypadki realizacji projektów z kilka razy większym (od założonego) kosztem, dodatkowo istotnie opóźnionych i niskiej jakości, niespełniających ostatecznie stawianych im wymagań. Problemu nie rozwiązuje oczywiście zastosowanie podejścia z cyklem „doskonalenia” (cykl Deminga), gdyż w nowoczesnym biznesie, długotrwałe oczekiwania na wykonanie tego cyklu jest zbyt kosztowne.

Jak można łatwo wywnioskować, największym problemem w opisywanym wyżej podejściu jest utrata pewnego utajonego potencjału wynikającego z wiedzy pracowników znacznie większej niż określona w „karcie stanowiska” danego pracownika. Minimalizacja tych negatywnych efektów sprowadza się do umiejętnego wykorzystania efektu „synergii kompetencyjnej” w realizacji rozwiązania informatycznego od jego koncepcji do uruchomienia.

Zapewne wiele osób stwierdzi, że przecież sprawę załatwiają „zwinne” metodyki wytwarzania oprogramowania. Jest to oczywiście myślenie całkowicie błędne, gdyż metodyki te koncentrują się na dostarczeniu artefaktów programistycznych wysokiej jakości w interakcji z odbiorcą, nie zaś całością procesu dostarczania oprogramowania, jako elementu usługi biznesowej o wysokiej jakości. Z pomocą przychodzi tutaj właśnie DevOps. Dlatego też rozumienie podejścia DevOps powinno być rozciągnięte na wszystkich partycypantów i beneficjentów informatyzacji procesów biznesowych, którzy przecież biorą udział w rozwoju oprogramowania. Podejście to nie powinno być rozumiane tylko jako usprawnienie współpracy programistów z „działem operacyjnym departamentu informatyki”.

DevOps

DevOps w praktyce

W ujęciu praktycznym DevOps sprowadza się do aktywnego wspierania przez kadrę kierowniczą opisanych niżej inicjatyw we wszystkich obszarach tworzenia rozwiązań informatycznych (od idei do realizacji).

Uporządkowanie i swobodna wymiana wiedzy

Realizacja tej inicjatywy wiąże się przede wszystkim z uporządkowaniem pracy koncepcyjnej wszystkich uczestników tworzenia oprogramowania (a szerzej rozwiązań informatycznych) poprzez utworzenie wspólnej platformy wymiany wiedzy (nie tylko informacji) na temat tworzonych i rozwijanych projektów. Może to być rozwiązanie w postaci stron „Wiki” zawierających odpowiednio czytelnie udokumentowane opisy przypadków i „wypadków” w prowadzonym projekcie, jego uczestników, jego celów strategicznych i taktycznych itp.

Sama dokumentacja tu nie wystarczy (sic!).wiedza = (nowa) informacja + doświadczenie
informacja = dane + kontekst
doświadczenie = wiedza (już nabyta)

Oczywista jest tu sytuacja taka, że jeśli nie ma wyraźnych przeciwwskazań wynikających z charakteru danego rozwiązania informatycznego, jego dokumentacja powinna być „otwarta” dla wszystkich, tak aby wiedza na temat różnych aspektów tworzenia rozwiązania była powszechna i aktualna wśród wszystkich uczestników projektu.

W wielu przypadkach wystarczające jest zastosowanie gotowych funkcjonalności dostępnych w zintegrowanych systemach wsparcia wytwarzania oprogramowania, takich jak GitLab. Systemy tego typu zazwyczaj zawierają w sobie wszystkie funkcjonalności wykorzystywane w procesie wytwarzania oprogramowania: od stron z wiedzą encyklopedyczną na temat projektów, wykorzystywanych w fazach koncepcyjnych i tworzenia oprogramowania, przez funkcjonalność obsługi zgłoszeń (np. błędów), zarządzanie wersjami kodu i oprogramowania, automatyczne budowanie kodu, do testowania i wdrażania.

Należyta wymiana informacji i wiedzy między członkami zespołów projektowych oraz między zespołami, na każdym etapie tworzenia i utrzymania oprogramowania, to podstawa udanych wdrożeń informatycznych. Należy więc, oprócz odpowiednich narzędzi, koniecznie zapewnić odpowiednią „atmosferę” stymulującą samoistne procesy wymiany informacji w grupie społecznej, w tym wypadku w zespole projektowym, jednostce organizacyjnej i organizacji.

Automatyzacja pracy powtarzalnej

Powtarzalność pewnych czynności jest charakterystyczne przede wszystkim dla działów prowadzących realizację techniczną projektów informatycznych.

W przypadku działów tworzących oprogramowanie istotne jest zapewnienie narzędzi pozwalających na automatyzację testowania kodu, jego próbnego wdrażania, badania jakości tworzonego kodu (a wtórnie tworzonych systemów). Dodatkowo przy pomocy zaawansowanych systemów zarządzania konfiguracją, takich jak np. Ansible lub Puppet Enterprise, można wyeliminować większość pracy powtarzalnej związanej z tworzeniem środowisk testowych, koniecznych do zapewnienia odpowiedniego wsparcia procesów ciągłej integracji i ciągłego dostarczania oprogramowania (ang. continuous integration and continuous delivery).

Co więcej, zastosowanie odpowiedniego środowiska wykonawczego, np. nowoczesnych technik wirtualizacji zasobów systemowych, na przykład „konteneryzacja” lub „technologia maszyn wirtualnych”, pozwala na pełną automatyzację przydzielania zasobów informatycznych poszczególnym projektom lub środowiskom testowym danego projektu informatycznego. Dostępne i sprawdzone rozwiązania to, na przykład, OpenShift i Docker.

Istotą automatyzacji pracy powtarzalnej nie jest oczywiście, jak zapewne wielu kierowników uważa, odciążenie zespołu specjalistów (i na przykład redukcja etatów), a minimalizacja błędów, które są naturalnym następstwem pracy ludzkiej, zwłaszcza w sytuacji pracy rutynowej (powtarzalnej). Takie błędy często kosztują dużo więcej niż praca oszczędzona w wyniku automatyzacji. Ale oczywiście wtórnym efektem jest odzyskanie uwagi i czasu specjalisty oraz możliwość wykorzystania go do bardziej szczytnych celów, związanych na przykład z kontrolą jakości.

Ciągła kontrola jakości

„Ufaj i kontroluj” — brzmi może i złowieszczo, ale oczywiście w praktyce zarządczej pojęcia zaufania i kontroli w żaden sposób się nie wykluczają. Kontrola jakości tworzonego rozwiązania (coś więcej niż kontrola jakości kodu) w żadnym wypadku nie powinna być kojarzona przez pracowników działów informatycznych z próbą wywierania presji. Jeśli tak będzie, nie będzie to proces skuteczny (źródło: doświadczenie autora).

Kontrola jakości tworzonych rozwiązania rozciąga się na kilka obszarów technologicznych:

  • analizy funkcjonalnej — zgodność z oczekiwaniami
  • oprogramowanie — artefakty programistyczne, kod
  • przystosowanie środowiska wykonawczego — konfiguracja komponentów, ustawienia, ograniczenia itp.
  • wykonanie — efekty wdrożenia, rejestry zdarzeń związanych z pracą wdrażanego rozwiązania

W każdym z powyższych obszarów realizacji możliwe jest wskazanie przynajmniej kilku źródeł informacji, których obróbka pozwala na zdefiniowanie i wyznaczenie tzw. kluczowych wskaźników efektywności (ang. key performance indicator) dotyczących jakości tworzonego systemu.

I tak na przykład, dla analizy funkcjonalnej, podstawowym źródłem jakości jest ilość zgłaszanych zmian w trakcie testowania rozwiązania. Przy dodatkowej kategoryzacji, możemy dość dokładnie wskazać obszar funkcjonalny potraktowany w fazie analizy „po macoszemu” i uniknąć podobnej sytuacji w przyszłości. Może nam to również wskazać obszar kompetencyjny, który należy wzmocnić w kadrze analitycznej.

W przypadku oprogramowania i tzw. „kodowania” sprawa wymaga zastosowania specjalistycznych funkcji związanych z analizą syntaktyczną i semantyczną kodu. Pozwala ona również wskazać na problemy kompetencyjne wśród programistów. Wysoka „higiena” tworzonego kodu oprogramowania, wtórnie podnosi także bezpieczeństwo tworzonego rozwiązania (najczęściej luki w bezpieczeństwie powstają w wyniku drobnych zaniedbań). Drugie źródło to oczywiście rejestry dotyczące automatycznego testowania tworzonego kodu i wyników testów oraz dzienniki (rejestry zdarzeń) potwierdzające poprawność działania oprogramowania.

Jeśli chodzi natomiast o konfigurację środowiska wykonawczego i wykonania oprogramowania, najlepszym źródłem wiedzy będzie analiza zapisów dzienników systemów operacyjnych, środowisk wykonawczych (na przykład serwera JBoss lub Oracle Weblogic) oraz ciągłe badanie kondycji systemów na zasadzie odczytu specyficznych wskaźników wykorzystania zasobów.

Jak wynika z powyższego zapisu, źródeł i danych do powiązania jest bardzo dużo. Jak więc radzić sobie z ogromną ilością informacji koniecznej do skutecznej kontroli jakości działania systemów informatycznych?

Z pomocą przychodzą tu rozwiązania takie jak systemy gromadzenia i analizy zdarzeń (ang. event management system). Jednym z takich rozwiązań, oferujących ogromny wachlarz dostępnych funkcjonalności oraz gotowe aplikacje analityczne jest rozwiązanie Splunk Enterprise. Dzięki bogatemu ekosystemowi gotowych konfiguracji (w terminologii Splunk — „aplikacji”), system pozwala bardzo szybko wyzyskać z zastanych, zróżnicowanych źródeł danych maksimum informacji, koniecznej do rzetelnej interpretacji cech jakościowych tworzonych rozwiązań informatycznych.

Podsumowanie

Narzędzia wspierające takie inicjatywy organizacyjne jak DevOps są niewątpliwie istotne, a w kilku sytuacjach (na przykład automatyzacji) nieodzowne i wiele od nich zależy. Jednak najistotniejsza (i o tym nie można zapomnieć) jest zmiana kultury organizacyjnej ułatwiająca stworzenie właściwych warunków dla urzeczywistnienia trzech opisanych wyżej aspektów podejścia DevOps.

Podejścia DevOps nie można realizować w części, na przykład wprowadzając jedynie proces CI/CD (ciągłej integracji i dostarczania). Dlatego, że zastosowanie poszczególnych elementów podejścia DevOps na „nieprzygotowanym gruncie” spowoduje zazwyczaj więcej problemów niż pożytku (i zamiast DevOps może nam wyjść „DevOoops”). Brak organizacyjnej koherencji mści się zazwyczaj po dłuższym okresie, chociażby zdezorientowaniem, zmęczeniem i frustracją kadry (zwłaszcza tej wysoce wyspecjalizowanej).

Jako autor niniejszego artykułu zachęcam więc do mądrego i holistycznego (modne słowo) podejścia do zagadnienia „przejścia na DevOps”.

Tags

top