DevOps – trudno, ale warto

Blog / Dobre praktyki / DevOps – trudno, ale warto

Jak nie wiadomo o co chodzi, to …

Hasło “DevOps” spotyka się często z uśmiechem i komentarzem o mrzonkach współpracy dwóch części IT, podczas gdy od jednej wymaga się ciągłego dostarczania nowych funkcjonalności, a od drugiej zapewnienia bezawaryjności i stabilności działania. Jeszcze inni sprowadzają taką współpracę jedynie do poziomu narzędzi mających uzupełnić lukę komunikacyjną między wymienionymi obszarami. A mimo to popularność DevOps rośnie i co raz częściej możemy czytać o realizacji tego hasła w wielu firmach [1]. O co chodzi?

Najprostszą odpowiedzią będzie – o wspólny cel biznesowy dla developerów i administratorów jakim jest dostarczanie najlepszego z możliwych produktu. Zatem ideą DevOps jest dążenie do doskonalenia dostarczania wartości klientom i biznesowi, a jej realizacja w strukturach i procesach IT może być różna. Redukcja kosztów czy automatyzacja nie stanowią celów samych w sobie.

startup-593343

Dla wielu takie ujęcie tematu brzmi jak otworzenie Puszki Pandory. Macie rację, praca nad relacjami między obszarem produkcji i operacji nie jest łatwa i napotka wiele trudności, o których później. Pytanie czy warto?

Doroczne badania [2] pokazują ogromny i bezpośredni wpływ współpracy Dev i Ops na wysoką wydajność IT i całych organizacji. Optymalizacja całego procesu wytwarzania produktu, zamiast wybranych obszarów nie tylko przyspiesza dostarczanie, ale podnosi jakość i bezpieczeństwo. Gdzie w tym pieniądze?

Po pierwsze w oszczędnościach związanych z redukcją kosztów pracy nadmiarowej (co najmniej $2mln rocznie w przypadku małych i średnich przedsiębiorstw [2]) i czasu niedostępności systemów (różnica na poziomie $2mln przy pojedynczym wdrożeniu między organizacjami nisko i wysoko wydajnymi [2]). Po drugie w zyskaniu 10% więcej czasu pracy nad nowymi rozwiązaniami (tu ROI jest już bardzo zależne od danego biznesu) [2]. Inaczej mówiąc IT odgrywa bardzo istotną rolę w redukcji czasu między pomysłem a dochodem, a szeroko rozumiany DevOps ten czas skraca.

Warto

devops-gearDevOps jest drogą do minimalizacji ryzyka błędów aplikacji produkcyjnych. Podejście organizacyjne, na które nie ma jednej prawidłowej recepty (choć istnieją zalecane, sprawdzone typologie), jest wpierane przez grupę technologii automatyzujących proces (continuous integration i deployment) czy pracę z infrastrukturą oraz ujednolicenie i łatwiejsze zarządzanie środowiskami. Są to elementy stanowiące wyzwania dla informatyków, którymi wielu z nich chętnie się zajmuje.

Rosnące zaangażowanie załogi zaczyna się często od indywidualnych inicjatyw, które odpowiednio wsparte, doprowadzają do szerszego sprawdzania rozwiązań usprawniających pracę nad produktem. Na tej drodze można często usłyszeć “my” i “oni”, aż do pierwszej wspólnej inicjatywy Dev i Ops, kiedy to obie strony zaczynają rozumieć perspektywę “tych drugich”.

Wraz z zaangażowaniem rośnie odpowiedzialność za rozwiązania – od ich propozycji, przez realizację, po wdrożenie, a co za tym idzie dbanie o jakość na każdym etapie rozwoju produktu. Wymiernym rezultatem jest o 22% mniej czasu poświęcanego na nieprzewidziane zadania i poprawki [2].

Na kanwie zaangażowania, zaufania i poczucia odpowiedzialności można budować organizację korzystającą z eksperymentalnego podchodzenia do rozwoju produktów. DevOps wspiera transparencję procesu od pomysłu po produkcji (Lean), interacyjność i przyrostowość (Scrum) i sposoby realizacji próbkowania pomysłów (Lean Startup, Design Thinking). Przy czym nie stwierdzono ograniczeń w osiąganiu wysokiej wydajności przez rozmiar firmy, czy rodzaj realizowanych projektów (greenfield, brownfield, czy legacy). [4]

Ma to znaczący wpływ na kulturę pracy i poczucie zespołowości. Employee Net Promoter Score (eNPS) [2] pokazuje, że pracownicy bardzo wydajnych (high-performance) organizacji 2 razy częściej polecają pracę w swoim zespole i u danego pracodawcy swoim kolegom i koleżankom, niż pracownicy organizacji mało wydajnych.

Trudno

workplace-1245776Środowisko pracy nad produktami IT jest z reguły złożone i w odróżnieniu do skomplikowanego, zgodnie z modelem Cynefin [5], powinno czerpać z empirycznego podejścia próbkowania. Kluczowym staje się stworzenie środowiska dla bezpiecznych eksperymentów. To z kolei kładzie dużą odpowiedzialność na liderach organizacji, których należy wspierać w tworzeniu otoczenia sprzyjającego międzyfunkcjonalnym (cross-functional) i samoorganizującym się zespołom [3].

Zmiana dokonuje się nie tylko w procesie, ale również (a może przede wszystkim?) w kulturze organizacyjnej [3]. Organizacje, które opisują swoją drogę do DevOps podkreślają, że aspekt kulturowy jest czynnikiem mogącym zapewnić trwałość zmian. Zatem pojawia się kolejna trudność, z zakresu zarządzania zmianą i to tą najtrudniejszą, bo dotykającą ludzkich przekonań, zachowań i nawyków.

Istotne by pamiętać jaka jest wizja dokonywanej zmiany [6], gdyż pozwala ona obrać prawidłowy kierunek, podczas gdy odkrycie najlepszej dla danej organizacji drogi będzie trwało dłużej i samo w sobie powinno być serią eksperymentów. Czynniki mające wpływ na finalnie wybrane rozwiązanie (struktura, proces, narzędzia) to między innymi rodzaje produktów, poziomi rozproszenia decyzyjności, indywidualne chęci rozwojowe pracowników, czy nawet kultura kraju, w którym znajduje się biuro.

Im później zaczynamy budować środowisko zaangażowane w ciągłe doskonalenie, tym trudniej jest o inwestycję czasową i tym trudniej o utrzymanie regularnego procesu plan – do – study – act [7].

Nie “czy?”, a “kiedy?”

Potencjalna nagroda DevOps w postaci wysoko wydajnej organizacji jest odpowiedzią na dynamikę rynku. W zależności od otoczenia biznesowego może pozwolić na przetrwanie lub nawet na osiągnięcie pozycji lidera. Decyzja o próbie zbudowania kultury DevOps jest kusząca – przy odpowiednio zdefiniowanych potrzebach i reakcjach na pojawiające się przeciwności, realizacja zdaje się w zasięgu wielu. Najwięksi gracze już realizują tą strategię. Nie warto ich kopiować, bo sposobów realizacji jest wiele. Warto zrozumieć, dlaczego podjęli takie kroki – zostać liderem może się przytrafić, pozostać nim na długo to dzisiejsze wyzwania.

 

[1] “DevOps War Stories”, InfoQ, styczeń 2014
[2] “2016 State od DevOps Report”, Puppet Labs
[3] “The DevOps mindset, real-world insights fromtech leaders”, Rackspace
[4] “2015 State od DevOps Report”, Puppet Labs
[5] https://en.wikipedia.org/wiki/Cynefin_Framework
[6] “8 steps to accelerate change in 2015” Kotter International
[7] https://en.wikipedia.org/wiki/PDCA

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *