Wprowadzenie DevOps do organizacji można porównać do procesu odchudzania. Trudno osiągnąć trwałe efekty ćwicząc tylko i wyłącznie z Ewą Chodakowską, bądź też ograniczając się do diety Anny Lewandowskiej, czy też dbając jedynie o higienę snu. Nie uda się to również stawiając wyłącznie na doradztwo Tony’ego Robbinsa, który będzie przekonywał nas, że możemy wszystko. Niestety, transformacja DevOps to praca na wielu poziomach jednocześnie, bez wsparcia celebrytów z telewizji śniadaniowej.
W artykule zostały opisane trzy drogi DevOps (ang. Three Ways of DevOps), które wyjaśniono w książce “The DevOps Handbook”. Są one fundamentem myślenia, czym jest DevOps. Z nich wyprowadzone są konkretne praktyki, z którymi DevOps jest najczęściej utożsamiany. Są to m.in. Continuous Integration, Continuous Delivery, Automated Provisioning itd. Wspomniane trzy drogi to: Przepływ, Pętla Zwrotna oraz Kultura Ciągłego Usprawniania i Eksperymentowania. Jeśli skupisz się tylko na jednej praktyce lub drodze, to istnieje duże ryzyko, że usprawnienie, które wprowadzisz, będzie miało charakter lokalny. Nie przełoży się to jednak globalnie na usprawnienie przepustowości pracy i stabilności systemu, który tworzysz razem z zespołem, co jest celem transformacji DevOps.
W przepływie wartości chodzi o to, aby efekt prac przeszedł jak najszybciej “od lewej strony do prawej”. Na przykład, kiedy deweloper commituje swój kod, to ma on trafić w jak najkrótszym czasie na środowisko produkcyjne bez zbędnego zatrzymywania się (np. czekając na wolne środowisko do testów), powrotów (np. od Operacji do Dewelopmentu z komentarzem, że danej zmiany nie da się wdrożyć), lub bycia przetrzymywanym (ręczna akceptacja zmiany przez Change Advisory Board).
Najczęściej stosowane koncepcje podczas optymalizacji przepływu wartości to: Continuous Integration, Continuous Delivery, Automated Provisioning za pomocą Infrastructure as Code, burzenie silosów funkcjonalnych (np. Dev, Ops, Security) w organizacji.
Co to jest DevOps?
Czym jest kultura DevOps?
Kim jest i czym się zajmuje DevOps Engineer?
Model kompetencyjny i budowanie zespołów w DevOps
Celem optymalizacji feedbacku jest spowodować, aby informacja zwrotna z produkcji przechodziła jak najszybciej “od prawej strony do lewej”, czyli w przeciwnym kierunku niż przepływ wartości biznesowej. Prawdziwa nauka na temat naszego systemu ma miejsce na produkcji, ponieważ tam w interakcje z nim wchodzą nasi klienci. W ten sposób wiemy, w jaki sposób korzystają oni z naszej aplikacji, jakie są błędy, jak szybko i stabilnie ona działa, czy jest to bezpieczne i zgodne z regulacjami. Wiele firm rozumie już, że eliminacja wąskich gardeł (ang. bottleneck) w przepływie wartości jest konieczna. Z naszych obserwacji wynika, że nadal duża liczba organizacji nie docenia negatywnego wpływu wąskich gardeł w pętli zwrotnej na powodzenie transformacji DevOps. Ograniczenie częstotliwości i prędkości podróżowania informacji zwrotnej do zespołu wytwórczego, osłabia systemowo jego zdolność do tworzenia produktu lepiej dopasowanego do potrzeb klientów oraz osłabia jego umiejętność do szybszej reakcji na zmianę.
Najczęściej stosowane koncepcje podczas optymalizacji pętli zwrotnej to: Continuous Integration, Continuous Delivery, burzenie silosów funkcjonalnych w organizacji, proaktywny monitoring, podejście typu Lean Startup, praca w zwinny sposób (ang. agile) zorientowana produktowo (a nie projektowo).
Jeśli nie tworzymy kultury, w której można ponosić porażki w skali, która jest do udźwignięcia i przetrwania przez jednostkę, zespół i organizację, to nie mamy szansy prawdziwie eksperymentować i uczyć się. Bez wspomnianej kultury optymalny przepływ i pętla zwrotna trafia na jałowy grunt, z którego nie wyrosną nowe, lepsze praktyki dopasowane do zmieniającej się rzeczywistości.
Najczęściej stosowane koncepcje podczas tworzenia kultury ciągłego eksperymentowania i nauki to: kultura produktywna (ang. generative culture) wg metodologii Westruma i towarzyszące temu przwyództwo, podejście typu Lean Startup
Jeśli jesteś w trakcie transformacji DevOps i czujesz narastającą frustrację brakiem widocznych efektów, zastanów się, czy nie zaniedbujesz którejś ze wspomnianych Dróg. Jeśli jesteś przed transformacją DevOps, masz szansę uczyć się na błędach innych i od razu zadbać o trzy Drogi, by zwiększyć szansę na sukces.