DevOps ofiarą kultu cargo

Czy DevOps jest jeszcze innowacją czy też stał się standardem, wymogiem dojrzałego IT? Tego zorientowanego na nowoczesne technologie i oferującego rozwiązania o określonej jakości i czasie? A może realne ryzyko by stał się standardem a’rebours, ofiarą kultu cargo, przynosząc rozczarowanie i chaos? Jeśli tak, to nigdy nie jest za późno na korekty.

Na polskim rynku od 2-3 lat DevOps bez wątpienia stał się modnym tematem. Mamy do czynienia z pierwszą falą implementacji, która pozwala ustalić, co się sprawdza a co nie. Nasze doświadczenia i obserwacje tego wycinka rynku, na którym pracujemy, wskazują jednak na to, że możemy mieć do czynienia z odmianą kultu cargo, którego przykłady w IT na naszym rynku już się zdarzały. Zaszczepiona wtedy zostaje imitacja metody, a nie metoda. Imitacja generuje szum informacyjny, zamiast wiedzy i wsparcia decyzji; ruch pozorny zamiast ukierunkowania i szybkości; pogłębienie podziałów i fasadowość zamiast transparentności i współodpowiedzialności. Dlatego, choć pozornie zaszczepiony, DevOps wówczas nie spełnia podstawowych celów. Staje się też kłopotliwy: trudno zaprzeczyć, aby nie podejmowano tematu, ale trudno też pochwalić się szerzej jego wdrożeniem a całkiem już trudno – realnymi efektami tej zmiany. Można przerwać ten rysujący się klincz i magiczny kult cargo zastąpić podejściem racjonalnym.

Czy jest jakieś referencyjne wdrożenie DevOps w Polsce?

Jeśli jest, to przemyka gdzieś cichaczem. Na bardzo dużym poziomie ogólności można dowiedzieć się o projektach w niektórych firmach, ale szczegółowej informacji co się udało, co nie, co okazało się szczególnym wyzwaniem, jak zmieniano procesy, jak ewoluowała kultura organizacji – – na taką informację nigdzie nie natrafiliśmy.

DevOps, jako recepty na nowoczesne IT, szuka przede wszystkim branża finansowa, bankowa. Pojawił się także w branży farmaceutycznej, ale i w sektorze publicznym czy energetycznym.  Kultura DevOps jest niezależna od branży i specyfiki sektora czy organizacji. Mozna powiedzieć, że ma charakter unisex – jest funkcją dojrzałości, tego co dzieje się w danym segmencie, próbą odpowiedzi na wyzwania, a nie modą w branży.

Jest też inna jego odsłona – DevOps zaszyty przez dostawców technologii w dostarczane produkty i rozwiązania. Taki DevOps faktycznie potem funkcjonuje, ale w ekosystemach technologii określonych dostawców. DevOps a’la vendor. Działa, ale z dużym prawdopodobieństwem powiedzieć można, że nie rozwinie się i nie stanie się podejście uniwersalnym. O ile nie nastąpi po nim szerokie, odnoszące się do czystego DevOps wdrożenie (roll-out).

Grawitacja pcha ku DevOps

Ciążenie ku DevOps dotyczy przede wszystkim firm, które produkują własne oprogramowanie. Albo tych, które chcą odbudować własne działy developmentu po okresie wydzielenia ich do oustrsourcingu. Dążą do powrotu, ale już w architekturze DevOps.

Najważniejszym czynnikiem wywołującym tę skłonność do DevOps jest presja wewnętrzna w firmach. Nie ma już zgody na projekty, które trwałyby wiele miesięcy i dłużej. Zmienność rynku, potrzeba szybkiej reakcji, wykorzystania w lot zaobserwowanej szansy biznesowej – to wszystko sprawia, że IT nie sposób zmieścić się w stosunkowo niewielkim czasowym okienku biznesowej szansy ze starym podejściem. Kwestia ta zresztą stawiana jest często w firmach jasno: albo zrobimy to i wdrożymy w ciągu miesiąca – dwóch, albo zrealizujemy rozwiązanie na zewnątrz i decyzja ta będzie miała aprobatę najwyższych władz, a w dalszej perspektywie – będzie to działanie powtarzalne, które doprowadzi do wyprowadzenia na zewnątrz IT.

Ugruntowało się już przekonanie, że świat technologii i biznesu zmieniają się bardzo dynamicznie. Ponadto, niezależnie od wielkości budżetów, nie ma już chęci do wielkich decyzji inwestycyjnych – według nowej filozofii cnotą jest wstrzemięźliwość. Zresztą nawet w królestwie bankowości zyski są dziś istotnie mniejsze, co skutecznie pacyfikuje nastroje i chęć do wielkich długofalowych inwestycji na rzecz mniejszych, ale ciągłych zmian, których wpływ jest szybko widoczny w wynikach biznesowych. Kończy się też przyzwolenie dla wielkich księstw IT.

CIO próbują reagować na to tworząc około produktowe, wydzielone zespoły wielofunkcyjne, ale to nie wystarcza. Rozbicie klasycznych silosów na mniejsze „zwinne” oddziały nie zmienia dynamiki dostarczania. Owszem, lepiej jest rozumiana wzajemna specyfika pracy, potrzeba klienta, rośnie świadomość UX, CX oraz pojawia się temat bezpieczeństwa na wczesnym etapie projektowania. Presji, aby zmienić realia czasowe dostarczania usług nie udaje się jednak udźwignąć ani w takim modelu ani zwiększając zatrudnienie. Trzeba zmienić podejście.

Pierwszym krokiem prowadzącym do niego jest implementacja prawdziwego Agile, który nie jest traktowany jak sfragmentowany waterfall, a który od początku uwzględnia jakość i wspomniane bezpieczeństwo. To pozwala dostarczać szybciej i trafniej, tak jak tego oczekuje biznes. A równocześnie zacząć myśleć o transformacji DevOps.

Co poszło nie tak?

Dzisiaj, przynajmniej wśród dużych firm, dochodzi już do refleksji, że pierwsze próby pozwalają zweryfikować, co nie działa w naszej implementacji.

Najpierw uściślijmy jeszcze, jak szeroką falą rozszedł się dotychczas DevOps i jak szerokie były to implementacje. Wśród dużych firm szacować można, że przynajmniej połowa jest zainteresowana wykorzystaniem DevOps. Z tej grupy, przynajmniej połowa dokonała prób implementacji. Nie ma specjalnie wątpliwości, że firmy chcą jednak przeważnie wdrażać PEWNE ELEMENTY DevOps. I tego, że świadomość pojawiających się w konsekwencji deficytów jest nie do przemilczenia.

Tak, jak do prowadzenia wojny potrzeba trzech rzeczy: pieniędzy, pieniędzy i jeszcze raz pieniędzy, tak trzy zasadnicze przyczyny dzisiejszych problemów z DevOps można sprowadzić do zaniechań i autokastracji dokonywanej w toku implementacji podejścia. Po pierwsze, drugie i trzecie – brak informacyjnego sprzężenia zwrotnego na wielu poziomach. Najłatwiej wyciąć pozornie nieistotne małe elementy komunikacyjne, które uwierają i wydają się nadmiarowe. Chociażby codzienną informacje o statusie. A potem poszczególne „małe” parametry jakości, np. dotyczące przyrostu funkcjonalności, bieżącej informacji z perspektywy bezpieczeństwa, prognozowanego czy przetestowanego wpływu aktualnej wersji na wynik biznesowy.

Istotny jest też inny czynnik: immanentna anarchiczność działów IT w niektórych polskich firmach, która paraliżuje i obnaża niemoc CIO do wyegzekwowania zaplanowanych założeń. Na przykład – dobranej architektury rozwiązań, kiedy założona zmiana jakiejś technologii wetowana jest nawet przez poszczególnych administratorów. Już pojedynczy administrator może skutecznie wypaczyć kształt technologicznej transformacji. W sytuacji braków ludzkich wybiera się jakieś zło – niekoniecznie mniejsze.

Ale i wyżej paraliż nie ustępuje – widoczny w nieudanych próbach wyegzekwowania wspólnego słownika i definicji od „kolegów” ze średniego szczebla, którzy wolą działać przy świetle nieco przygaszonym, nikłym i dopomagać danym dopasować się do ambitnych marzeń. To trochę jak z historią – nikt nie wie, jak było naprawdę – wiedzę o historii budujemy na podstawie relacji tj subiektywnej oceny rzeczywistości i wydarzeń. Nawet jeśli są to dokumenty, to były spisywane ręką człowieka – czy zachował obiektywizm? Zwłaszcza jeśli ocena dotyczy weryfikacji własnej historii? A o tym mówimy w kulturze DevOps. To sprawia, że dom DevOps można nieopatrznie zbudować bez fundamentu. Kompromis zawarty przez CIO wynika z fetyszu technologicznego: np. administrator jest ekspertem w danej technologii, ambasadorem rozwiązania w firmie, z którym kontaktuje się bezpośrednio poseł dostawcy. Miałby jednym ruchem, dla kaprysu CIO, przekreślić lata doświadczeń i nauki, relacje, odciąć firmę od tych benefitów? Brak przyzwolenia CIO na taki fetysz, to początek prawdziwie magicznej ścieżki implementacji DevOps…

Fetysz technologiczny, magia i kult

Jak łatwo sprzedać ideę DevOps za technologiczne paciorki… Kompromis na tym podstawowym poziomie wpycha już zrezygnowanego lub pełnego jeszcze złudzeń CIO w ramiona magii i szamanizmu… W efekcie niektóre wdrożenia przypominają kult cargo: prymitywne ludy czczą przelatujące stalowe ptaki, porzucane przez nie przedmioty, na ich podobieństwo budują drewniane konstrukcje i nocami rozpalają ogień wzdłuż magicznych pasów startowych czekając na ich przybycie. Ale ich własne wiklinowe samoloty nigdy nie wzbijają się w powietrze.

Istnieje spiskowa teoria, że nigdy też nie mają się wzbić. To przypadek świadomego kompromisu. Nasze samoloty mają TYLKO przypominać stalowe ptaki, które widzi się w górze, ich „gniazda” – mają tylko przypominać lądowiska, oglądane z buszu. Podziwiamy i czcimy, ale nie mamy ambicji, aby nasz samolot wzbił się w powietrze. Lepiej przy pomocy nowych czarów – czynionych z fachową pomocą średniego szczebla kolegów-szamanów – imitować, akrobatycznie dostarczać dane, które potwierdzą realizację kursu. Jesteśmy dojrzali, mamy nowoczesne podejście, a jak się odpowiednio dokręci, to i wyniki okazują się właściwe. Wówczas odpowiedź na pytanie biznesu „A dlaczego nie działa” jest faktycznie nie do udzielenia. Mówimy o szczerej odpowiedzi.

Cofnijmy się w naszej opowieści na chwilę z tej ścieżki, która prowadzi w zaczarowany świat opowieści z mchu i paproci całą firmę. Cofnijmy się do pryncypiów DevOps.

Przepis na DevOps

Kiedy w świecie rosnącej zmienności biznesowej pojawiła się cudowna recepta – DevOps, dostarczona została z zestawem kilku prostych i jasno wyłożonych zasad.  Podchwyciło ją wielu decydentów, ale bez wielkiego szacunku dla zbyt prostych, dla części (choć nie wszystkich!) CIO wręcz banalnych zasad. Proste czy banalne nie nosi znamion ambitności, dlatego zasady były przez nich przerabiane, w swoim mniemaniu udoskonalane.

Albo odwagi starczało im na archipelagowe implementacje. Czy można jednak firmę podzielić na orbity różnej metodyki i prędkości, DevOps i resztę? Nie ma klarownej odpowiedzi i zapewne: to zależy. Opowiadamy się za oszczędzaniem czasu i zasobów. Cała istota DevOps wyraża się w haśle: dać ludziom władzę i odpowiedzialność, wiedzę, jak ich praca wpływa na całość firmy. Jeśli tak, to nielogiczne byłoby domagać się od nich, aby w pewnych wycinkach tę wiedzę mieli, a w innych nie, żeby panowało dwójmyślenie, dwa podejścia kulturowe. Dlaczego w jednych kwestiach ich świadomość powinna być pełna, i ma to znaczenie, a w innych nie?

Pewnie trzeba zacząć po trochu. Nie da się jednorazowo wdrożyć gotowego wzorca. Nie istnieje coś takiego jak DevOps in a box. To trudny proces wymagający dojrzałych decyzji managerskich. Trzeba próbować, potwierdzać procesy, a potem je upowszechniać.

IT od zawsze szuka rozwiązania dobrego na wszystko – taka obsesja „silver bullet”. Umówmy się, że DevOps sprzyja racjonalizacji, nadaniu oprogramowaniu charakteru dzieła inżynierskiego, dostarczającego zimne, obiektywne dane o sytuacji. Oprócz doskonale do tego mogącej posłużyć koncepcji DevOps, którą dekadę temu w „Project Phoenix” wyłożył Gene Kim, dochodzą doświadczenia znane np. z japońskich fabryk samochodowych. W ciągu dekady pojawił się też szereg rozwiązań technologicznych, które wprost nawiązują do DevOps i potrafią fantastycznie zwiększyć efektywność, jaką uzyskuje się w tej metodzie. Warto pamiętać jednak, że Gene Kim mówił o zasadach a nie o konkretnych technologiach. Pisał o szybkim uwzględnieniu bezpieczeństwa czy stałym monitorowaniu jakości i przyrostu funkcjonalności, ale nie o konkretnym rozwiązaniu technologicznym. Warto o tym pamiętać i nie ubezwłasnowolniać DevOps w swojej firmie.

Do prostych zasad sformułowanych przez Kima należała kwestia włączenia bezpieczeństwa w proces wytwórczy. W podejściu sprzed epoki Agile i DevOps dział bezpieczeństwa nie ma dość czasu ani wyznaczonego właściwie momentu, aby analizować produkty. Testy bezpieczeństwa odbywały się zawsze na końcu, kiedy wahadło projektu dawno się wychyliło – z nowym produktem musiało dziać się dramatycznie źle, aby bezpieczeństwo mogło wymóc zatrzymanie. W kulturze DevOps kładziemy nacisk na przesunięcie bezpieczeństwa w lewo tj. przeprowadzamy przeglądy bezpieczeństwa aplikacji od początku, uwzględniamy informacje w projektach i wersjach demonstracyjnych, używamy wstępnie zatwierdzonych bibliotek, testujemy funkcje bezpieczeństwa jako część zautomatyzowanego zestawu testów. Pomagamy ludziom z bezpieczeństwa mówić ‘GO’.

Kolejna prosta zasada dotyczy szacunku do informacji i jej stałej aktualizacji, właściwie ciągłego monitoringu. To sposób, aby CIO, ale i interesariusze oraz twórcy, na bieżąco kontrolowali sytuację. Paragraf drugi tej zasady mówi, że należy posługiwać się spójnym aparatem pojęciowym i zobiektywizowanym aparatem pomiarowym, aby budować dane całościowe, spójne  i obiektywne. Aby nie było szansy – szansy, która rodzi pokusę – by je poprawiać, dopasowywać do oczekiwań.

Ta zasada prowadzi do właściwego celu DevOps: nowej metody zarządzania. W oparciu o dane spójne, czytelne, zrozumiałe. Świat ekscytuje się kokpitami zarządczymi od lat, ale warstwa informacyjna musi być rzeczywista. DevOps stwarza świetne warunki, aby taką informację generować i wykorzystywać, nie będzie ona gromadzona na próżno. Tak się stanie, jeśli informacja będzie gromadzona w największym zakresie automatycznie. W zasadzie wyznacznikiem powinna być ewolucja deski rozdzielczej samochodu, która informuje na pierwszym ekranie tylko o poziomie paliwa, obrotach, ciśnieniu oleju, światłach. Dla DevOps takie zegary to na przykład przyrost funkcjonalności i średnie czasy znalezienia błędu. Od ideału zejdźmy ponownie do przyziemnej rzeczywistości. Nawet idealne wzorce powstają w praktyce, w ogniu projektu.

Nie śpij, bo Ci DevOps wypaczą

Wtedy też dochodzi do wspomnianych samookaleczeń. Co najchętniej się poświęca z DevOps, skutkiem czego się on nie udaje? Świadomie, nieświadomie… najchętniej rezygnuje się ze świetnych pomysłów, bo zespół daje negatywny feedback: „jest nas za mało, priorytety są inne”. Ale właściwy problem jest w innym miejscu.

Wycięte elementy zastąpione kadłubkami przytrafiają się najczęściej w obszarze budowania komunikacji i właściwej pętli sprzężenia zwrotnego opartego o dane. Nie możesz co dwa tygodnie korygować kierunku jazdy samochodem, bo od dawna jesteś na drzewie. To trzeba robić na bieżąco – w przypadku firm i projektów – codziennie. Już na samym początku procesu musi być to zasada realizowana– od etapu wymagań biznesu, stały monitoring czy kryteria sukcesu, tempo budowy pozostają adekwatne do oczekiwań. To od przodu – Agile. Ale pozostaje cała kwestia developerska: bieżąca ocena, testowana automatycznie, oparta na danych odnoszących się do tego, co powstaje. I na bieżąco ocena uzyskiwana z rynku (znowu – na konkretnych danych, nie ‘wydawaczach-mi-się’), czy usługa się pogorszyła, czy nie; jak wpływa na biznes, na wyniki.

Trzeba wybrać odpowiednią metodę sprzężenia zwrotnego, aby stale sprawdzać czy twoja hipoteza biznesowa jest prawdziwa. Czy nie trzeba jej modyfikować. Ta pętla sprzężenia zwrotnego i komunikacji najczęściej jest kastrowana. Biznes nie ma czasu, ktoś inny nie ma czasu. Dochodzi właśnie do rozciągnięcia dziennych spotkań do formuły dwutygodniowych, pozorowanych spotkań.

W istocie jest to powrót do waterfallowego modelu. Zmienia się wszystko, aby wszystko pozostało nie zmienione.

Małe-wielkie szczegóły za podwójną gardą

Czyja to odpowiedzialność, aby bronić takich rzeczy pozornie małych, które mają kolosalne znaczenie? Pozornie małe, pozornie nieprzynoszące wartości – pozornie łatwe i bezszkodowo możliwe do pominięcia. Kilka prostych cieć, po których okazuje się, że obciąłeś nogę: nie masz spójnych i prawdziwych danych. Często te skróty motywuje się ergonomią projektową – w istocie te oszczędności są okradaniem samych siebie z wiedzy…

To musi być zatem podwójna garda i podwójna odpowiedzialność: świadomego kierownika projektu, którego rola nie skończy się w momencie oddania na produkcję przygotowanych funkcjonalności. Ale rozciąga się na etap produkcyjny, uzyskania benefitu biznesowego, utrzymania i propagacji wartości z rozwiązania. Drugi poziom odpowiedzialności za ortodoksyjny DevOps, to rola dyrektora tribe’u. Świadomy szef tribe’u nigdy nie zgodzi się mydlenie mu oczu, chce być na bieżąco z sytuacją z każdego ze streamów wytwarzania. Jeśli tego brak, to nieszczęścia zwykle chodzą parami: szefowie tribe’ów, którzy nie przykładają wagi do odpowiedzialności za pętlę informacyjną, zwykle też nie przykładają wagi do tego, aby pilnować, czy pracują na tych samych definicjach danych i słownikach co inne tribe’y. W efekcie nie widzą tego samego, a w firmie funkcjonuje np. kilka dość różnych definicji poziomu Customer experience.  I z tak niespójnych źródeł pochodzą informacje, które dostaje CIO, co oznacza, że nie widzi nic. I na tej podstawie musi podjąć, często kluczowe dla biznesu organizacji, decyzje.Powodzenia. Tak więc to CIOpowinien czuć się odpowiedzialny za koordynację naszej podwójnej gardy.

DevOps to wspaniała idea współodpowiedzialności i świadomości rozłożonej demokratycznie, która nie może jednak działać bez ram. Polityka projakościowa nadal ma sens i ma w DevOps swoje miejsce. Polityka operacyjna – ma sens i musi być zatwierdzona.  I tak po kolei. To nie jest święto demokracji ludowej i wiecowanie. Ramy te musi ustanowić i wyegzekwować CIO. Nie musi wnikać w to, czego używa się do developmentu – to nie ma żadnego znaczenia! Ale wszyscy muszą działać w ramach dostarczania spójnych danych.

Poletko CIO

CIO musi mieć do siebie zaufanie. Musi bazować na własnej, opartej o dane, refleksji i na tej podstawie podejmować decyzje, a nie jedynie na kolegialnym odpytaniu „swoich chłopaków”(co zdarza się dość często). „Chłopaków”, choćby mieli najlepsze intencje, nie opuści subiektywizm oceny, w tym obawy o własną rolę, przejrzystość, która może obnażyć ich słabe strony. Mogą walczyć o swój wpływ na obraz ‘historii’ i nawet nieświadomie ubierać ją w subiektywny osąd. .

Dlatego w DevOps tak uważnie zajmujemy się diagnostyką i monitoringiem. Jeśli CIO nie wyjmie danych na wierzch, nie będzie na nich pracować – to operuje na fikcyjnej rzeczywistości. Refleksja oparta ma być na danych, a nie przeczuciach.

Po drugie: musi działać system informacji zwrotnej, spójny wskroś całej organizacji.

Po trzecie: trzeba zapewnić poletko eksperymentowania i testy AB, stale weryfikować; i przestrzeń do tego, aby organizacja pracowała nad swoim reagowaniem na awarie.

Powrót z krainy baśni na ścieżkę inżynierską

A jeśli zdarzyło się już nieszczęście? Czy da się cofnąć do punktu wyjścia?

Pomimo, że brak jest fundamentów i ściany wiszą w powietrzu, można brakujące partie zrekonstruować. Na pewno są pełnowartościowe fragmenty DevOpsowej struktury. Da się je zachować i upowszechnić na resztę organizacji. Zebrać zewnętrzny feedback. Ustanowić standardy na nowo, z posiadanych elementów i dobudować brakujące. Na warstwie danych i komunikacji zintegrować istniejące procesy w spójny system, aby wiedzieć, gdzie się jest.

To musi być już projekt naprawczy, metodyczny a nie naprawianie przy okazji zwykłego projektu. Warstwę narzędziową i ramy, trwałą i właściwą, da się wytworzyć w ciągu kwartału. Wszystko musi mieć jednak swój rytm, regularność. Musi zostać zaszyta regularna rewizja sytuacji w oparciu o dane.

Przy okazji tego projektu należy także zaprzestać złego zwyczaju upierania się przy aklamacyjnym przyjmowaniu założeń. Nie wszyscy są w stanie zrozumieć pomysł, którego celem nie jest załatwienie problemu pojedynczego administratora tylko problemu, który zdefiniował CIO. A dziś w Polsce jest niepokojąca nadreprezentatywność takich przypadków. Można winić za tę sytuację historię najnowszą polskiego IT. Współczesna polska kultura informatyczna została wychodowana przez kilku globalnych dostawców i zbieramy tego plony. Ale swoją rolę odgrywa także pra-wzorzec kulturowych korzeni: „szlachcic na zagrodzie równy wojewodzie”.

Tymczasem administrator jakiegoś serwera nie może decydować, jaki ma stos technologiczny firma. Nawet jeśli użyje zaklęcia, np.: „jesteśmy specyficzni”, „nie jesteśmy na tym etapie rozwoju” albo: „stracisz nas szefie, jeśli nie dostaniemy TEJ roboty”.

Powrót do normalności: IT nie musi być walką o życie

Działając w magicznym nurcie DevOps odkryliśmy, że CIO powinien mieć sojusznika- klient często nie ma zdolności czy zasobów do utrzymania czystości rozwiązania i dostawca musi mu towarzyszyć po wdrożeniu.

Niektórzy z naszych Klientów nazywają nas Avengers – to nas bawi, bo lubimy świat Stana Lee, a naszą specjalnością są po prostu misje ratunkowe, ale nie można cały czas biegać po świecie w masce. IT nie może kojarzyć się z kombatanckimi opowieściami o ludziach nocujących w śpiworach pod biurkami z głową w pudełku po pizzy przez 3 weekendy z rzędu w trakcie wydania, które trwa …trzy weekendy z rzędu. IT to powinna być czysta inżynieria. Dość szaleństwa – racjonalne podejście wreszcie można stosować. Można wykształcić w organizacji zdolność do ciągłego dostarczania oprogramowania kilka razy dziennie, bez stresu i pospolitego ruszenia.

Jeśli coś nie działa, to powrót do stanu sprzed awarii zajmuje minuty i odbudowa środowiska jest formalnością. Nie tematem z pierwszych stron serwisów informacyjnych.  Po to został wymyślony DevOps.

Portfolio firm wspierających DevOps, jest naprawdę ciekawe i mocne.. Zwłaszcza wśród firm wąsko specjalizowanych np. w zakresie rozwiązań dających przejrzystość. Odkrywanie tego świata dopiero się rozpoczyna. Niekiedy anegdotycznie, kiedy np. pierwsze tej kategorii narzędzie nabywa – bo można kupić je kartą firmową – zdesperowany admin. Pierwsze doświadczenie zwykle dopiero daje przedsmak tego, co i jak da się udoskonalić, ale początek jest zrobiony i pomaga zakiełkować idei poszukiwania specjalizowanych narzędzi DevOpsowych.

Odwrotnie ma się natomiast rzecz z ideami dotyczącymi ewolucji a raczej obalenia DevOps. Jego miejsce miałyby zająć modele noOps czy FinOps. Ale naszym zdaniem to mrzonki. Te i podobne koncepcje mają swoich fanów, ale patrzymy na to raczej jak na epizody gwiezdnowojennej sagi, które obok wątków głównych pojawiają się i znikają nie mając specjalnego wpływu na losy głównych bohaterów. Wierzymy, że DevOps jest realny. Jego korzyści są widoczne i zbadane. I jest na wyciągniecie ręki.

I jeszcze jedno. Dobrze prowadzony DevOps czyni nasze miejsce pracy lepszym. Człowiek i jego komfort pracy chyba nigdy nie miał takiego znaczenia jak dotychczas. I chyba nigdy samo uposażenie pracownika nie było tak słabym gwarantem jego lojalności. W tej kulturze nie tylko wstrzymujemy proces rozkwitu chorób wynikających z nadmiernego stresu przy ciśnieniu na wydaniu na produkcję – gdzie nie mówimy o ucisku w żołądku, ale o dosłownej autodestrukcji dokonującej się w trzewiach. DevOps może też zapobiegać wypaleniu zawodowemu, rozumianemu nie tylko jako zmęczenie, ale silne stany lękowe, wyczerpanie, cynizm, ale najważniejsze – nie odnajdywanie już przyjemności w tym, co się kiedyś kochało.