DevOps

Termin DevOps jest połączeniem dwóch angielskich słów DEVelopment & OPeartionS. Słowa te można przetłumaczyć jako Rozwój (oprogramowania) i Utrzymanie (systemów IT). Termin DevOps został zaproponowany przez jednego z twórców tego podejścia Patricka Debois w 2009 r.  Pojawienie się DevOps związane było z poszukiwaniem bardziej efektywnych metod pracy i współpracy wszystkich specjalistów IT zaangażowanych w dostarczanie rozwiązań klientom. Zarówno specjalistów zajmujących się rozwojem oprogramowania (deweloperzy, testerzy) jak i odpowiedzialnych za utrzymanie i wsparcie wdrożonych rozwiązań (inżynierowie systemowi, administratorzy, service desk). DevOps przede wszystkim implementuje znaną z przemysłu metodykę szczupłego zarządzania (Lean Management). Czy proces wytwarzania, wdrażania i utrzymania oprogramowania jest podobny do procesu produkcji np: samochodów? Tak! Procesy związane z wytwarzaniem czegoś mają pewne cechy  wspólne, nawet w tak różnych i odległych branżach jak np: branża motoryzacyjna i IT. Zasadniczym celem jest dostarczenie wartości klientowi końcowemu, a wszelkie działania skupiają się wokół jednego złożonego procesu wytwórczego, zwanego strumieniem wartości (ang. value stream). W ramach DevOps proces wytwórczy zaczyna się od ustalenia jakie wymagania ma klient, stworzenia odpowiedniego rozwiązania spełniającego oczekiwania klienta, a następnie jak najszybszym wdrożeniu produktu by klient mógł z niego korzystać. Proces wytwórczy nie kończy się z chwilą oddania produktu do użytku. Nie mniej istotną od rozwoju częścią procesu wytwórczego jest stabilizacja, utrzymanie oraz doskonalenie wdrożonego produktu.  Cała praca odbywa się przy współudziale wszystkich specjalistów zaangażowanych w proces wytwórczy, a więc zarówno tych z Dev jak i tych z Ops. Muszą ze sobą współpracować, bo cel mają wspólny, częste wydania nowych wersji produktów, wysokiej jakości, wdrażane szybko i bez skutków ubocznych. Takie podejście oznacza również, że najlepiej by specjaliści z Dev i Ops stanowili jeden zespół, a nie byli rozrzuceni w różnych działach, które zachowują się jak odrębne „księstwa” z odrębnymi celami, budżetem i zarządzaniem. Taka kultura organizacyjna, w której Dev-si i Ops-i to różne zespoły, nazywana jest kulturą opartą o silosy (ang. silo culture) i jest zaprzeczeniem idei głoszonych przez twórców DevOps.

Kolejnymi niezwykle ważnymi elementami DevOps są optymalizacja i automatyzacja. Proces wytwórczy powinien być maksymalnie optymalny. Wszak celem produkcji jest nie tylko zaspokojenie oczekiwań klientów, ale również prowadzenie biznesu producenta, a zatem zarabianie pieniędzy. Zgodnie z założeniami Lean Management należy analizować wszelkie działania prowadzone w ramach procesu wytwórczego, identyfikować i eliminować wszelkie marnotrawstwo, a te działania, które tylko można automatyzować. Dzięki takiemu podejściu przechodzenie poprzez kolejne kroki procesu wytwórczego jest szybkie, a ewentualnie błędy są szybko wykrywane – jak najwcześniej można w procesie wytwórczym – i eliminowane by nie trafiły jako wada do produktów końcowych.

Co to jest marnotrawstwo? Wszelkie działania, które nie przyczyniają się do wytworzenia wartości dla klienta końcowego. Typowym marnotrawstwem jest usuwanie błędów w oprogramowaniu, które trafiło już na produkcję. Klient zgłasza wady produktu, a dostawca musi te wady usuwać na własny koszt. Błędy w oprogramowaniu to nie tylko dodatkowy koszt dla dostawcy. Błędy mogą również doprowadzić do strat po stronie klienta i pogorszyć jego relacje z jego klientami.
Innym przykładem marnotrawstwa może być wytwarzanie rozwiązań, które są lepsze niż jest to wymagane. Zawierają funkcjonalności i mechanizmy, o które nikt nie prosił, stosują zbyt dokładne metody przetwarzania danych, czy gromadzą więcej danych niż potrzeba. Ogólnie metodyka Lean IT (Lean Management dostosowane do potrzeb branży IT) podaje następujące rodzaje marnotrawstwa:

  • Oczekiwanie (ang. waiting)
  • Nadmierne przetwarzanie i nadprodukcja (ang. over processing, over production)
  • Zapasy (ang. inventory)
  • Zbędny ruch lub transport (ang. transportation, motion)
  • Wady (ang. defects)
  • Źle wykorzystany potencjał ludzki (ang. not utilized / underutilized talent)

Dobrze zbudowany, zgodny z DevOps proces wytwarzania i dostarczania oprogramowania będzie na tyle na ile to możliwe pozbawiony powyższych elementów, rozumianych jako marnotrawstwo, a jednocześnie wszędzie gdzie to tylko jest możliwe zautomatyzowany.

Czy kluczem do sukcesu DevOps jest automatyzacja? Jest niewątpliwe bardzo istotna, ale stanowi tylko pewien element całości. Bez odpowiedniego podejścia, kultury organizacji oraz kultury pracy sama automatyzacja nie zagwarantuje sprawnego działania procesu wytwarzania, dostarczania i utrzymania oprogramowania. Automatyzacja to tylko narzędzia. Jeżeli będziemy automatyzować zły, nieoptymalny proces, w organizacji gdzie panuje bałagan i brak jest chęci współpracy, to automatyzacja tych problemów nie rozwiąże, a jedynie spotęguje. Najczęściej swego rodzaju zator powstaje na styku Dev i Ops gdy wciąż panuje kultura my i oni. Deweloperzy i Sysopsi to odrębne plemiona, które skupione są na realizacji własnych celów. Jeżeli w dziale rozwoju oprogramowania zostaną wdrożone mechanizmy wspomagające pracę, takie jak ciągła integracja (CI – continuous integration), automatyczne testowanie ale brak będzie synergii z działaniami po stronie Ops to na styku tych dwóch obszarów powstanie zator. Dział rozwoju oprogramowania będzie w stanie szybko dostarczać nowe wydania, ale ich wdrażanie oraz co jest niezwykle istotne informacje zwrotne o jakości (ang. feedback) będą mocno opóźnione.

 Trzy drogi DevOps

  • Droga pierwsza: Przepływ pracy
  • Droga druga: Sprzężenie zwrotne
  • Droga trzecia: Ciągłe eksperymentowanie i uczenie się

Przepływ pracy

Zasada przepływu pracy wywodzi się z metodyki Lean. Proces wytwórczy złożony jest z szeregu kroków, a praca w ustalonej kolejności od kroku do kroku. Przepływ powinien być płynny. Nie powinno występować oczekiwanie na pracę, jak również spiętrzanie się pracy. Praca nie może się cofać do kroku lub kroków poprzednich (jeżeli się cofa to znaczy, że wystąpiły błędy lub niedoróbki i trzeba coś poprawiać). Prawidłowy przepływ pracy jest zawsze w jedną stronę. W DevOps praca zaczyna się od programistów, przechodzi do testów, a następnie na produkcję i utrzymanie. Jest to duże uproszczenie, ale chodzi o zasygnalizowanie schematu działania.

Sprzężenie zwrotne

Sprzężenie zwrotne lub informacja zwrotna (ang. feedback).

Ciągłe eksperymentowanie i uczenie się

C

 

to be continued

Dodaj komentarz