trzy drogi devops

Trzy drogi DevOps i co z nich wynika

Książka “Projekt Feniks. Powieść o IT, modelu DevOps i o tym, jak pomóc firmie w odniesieniu sukcesu” stanowi idealny łagodny wstęp do tej metodyki. Jestem przekonany, że po jej przeczytaniu czytelnik nie raz i nie dwa krzyknie “ależ ja spotkałem podobnego człowieka/sytuację!”. Definiuje ona i pokazuje w działaniu trzy główne zbiory zasad DevOps (nazywane też drogami DevOps). Dzisiaj właśnie o tych zasadach.

Różnice perspektyw, czyli jak patrzy się na to samo z różnych stron

DevOps jest metodyką (czasami zamiast tego słowa używane jest określenie “zbiór praktyk” lub nawet “zbiór najlepszych praktyk”) możliwą do zastosowania w projektach o bardzo różnej skali. Od najmniejszych, kilkuosobowych do projektów dużej skali (również tych realizowanych z wykorzystaniem podwykonawców). Najczęściej, niezależnie od skali projektu DevOps wykorzystuje się łącznie z jedną z metodyk zwinnych – te narzędzia do zarządzania pracami projektowymi mają dużo wspólnych elementów, a w obszarach rozłącznych dobrze się wzajemnie uzupełniają. Niniejszy rozdział przedstawia w bardzo dużym skrócie właśnie tematy związane z funkcjonowaniem DevOps w organizacjach o różnej skali oraz różnych strukturach.

DevOps a struktura i rozmiar organizacji

Projekty prowadzone zgodnie z DevOps zawsze funkcjonują wewnątrz organizacji o określonych strukturach, więc struktury te mają wpływ na funkcjonowanie DevOps. Szczegółowe omówienie tego tematu dalece wykracza poza zakres tego artykułu, ale warto przynajmniej przedstawić wpływ, ma wzajemne ulokowanie zespołów Dev i Ops na funkcjonowanie całości projektu oraz realizację postulatów metodyki DevOps. Dla uproszczenia, poniżej przedstawione są najczęstsze przypadki ulokowania zespołu operacji IT w stosunku do zespołu wykonawczego:

  • Zespoły operacji zlokalizowane w organizacji oddzielnie od zespołu wykonawczego i oparte o organizację funkcjonalną. [Organizacja funkcjonalna to taka, w której działy pełnią określone funkcje, np. dział administracji aplikacjami, dział administracji bazami danych, dział wdrożeń itp.]

Obecnie dość rzadko spotykany sposób współpracy między działami operacji a działami wykonawczymi. Dzieje się tak między innymi ze względu na trudności we wdrożeniu metodyki DevOps w takiej organizacji. Przykładowe trudności to:

  • Konieczność współpracy działu wykonawczego z wieloma różnymi działami realizującymi szczegółowe zadania.
  • Trudności z koordynacji pracy wielu działów.
  • Kolejkowanie pracy w działach operacji – po zlecaniu jej przez różne zespoły wykonawcze.
  • Pracownicy działów operacji często nie posiadają wiedzy o kontekście pracy którą wykonują. Rodzi to wiele negatywnych konsekwencji, np. niską motywację.

Rozwiązanie takie ma też pewne zalety:

  • Zespoły funkcjonalne są zwykle dobrym miejscem do rozwijania kompetencji w obszarach ich odpowiedzialności.
  • W przypadku standardowych prac takie zespoły mogą być również efektywne kosztowo.
  • Zespół operacji funkcjonujący oddzielnie od zespołów wykonawczych i świadczący im usługi na zasadach zbliżonych do rynkowych. Jeden zespół operacji świadczy usługi dla wielu zespołów wykonawczych w oparciu o mniej lub bardziej sformalizowany zbiór usług. Zespoły wykonawcze zlecają zespołowi operacji pewne określone zbiory prac i rozliczają go z ich wykonania nie interesując się szczegółami realizacyjnymi. Rozwiązanie pozbawione części wad rozwiązania z zespołami funkcjonalnymi, ale wciąż posiadające niektóre z nich:
    • Konkurencja o zasoby działu operacji prowadząca do kolejkowania pracy w tym zespole.
    • Trudności w planowaniu obciążenia członków zespołu operacji prowadzące do braku zajęcia lub, co częstsze, do stałego przeciążenia pracowników.
    • Nieuchronne pojawienie się mentalności my-oni prowadzącej do konfliktów i zakłócającej współpracę zespołów.

Zaletami tego rozwiązania są zwykle możliwości połączenia wysokich kompetencji wynikających ze specjalizacji ze sprawnością takich zespołów. Rozwiązania powstające w takim jednolitym zespole mają też zwykle charakter bardziej uniwersalny niż w przypadku zespołów funkcjonalnych. Promuje to reużywalność rozwiązań przez różne zespoły wykonawcze (tzw. “nie wynajdywanie koła”) i ułatwia im korzystanie z usług operacji (“wszystko w jednym miejscu”). Dodatkowo, częściowe nakładanie się kompetencji członków takiego zespołu może sprzyjać minimalizacji wpływu przedstawionych wyżej problemów z obciążeniem pracowników na świadczone przez zespół usługi.

  • Zespół operacji i zespół wykonawczy funkcjonujące łącznie. Rozwiązanie funkcjonujące na tyle często, szczególnie w małych zespołach, że błędnie uważane za wymóg metodyki DevOps. Należy jednak przyznać, że z punktu widzenia DevOps ma wiele zalet i relatywnie mało wad. Niestety, te nieliczne wady są bardzo poważne:
    • Rozwiązanie źle się skaluje – czyli, funkcjonuje tym gorzej im większy zespół. W praktyce dla większych zespołów projektowych i tak konieczne jest wydzielenie wewnątrz nich oddzielnej struktury zajmującej się operacjami, co zbliża to rozwiązanie do omówionego wcześniej rozwiązania opartego o zespół usługowy.
    • Powszechny problem braku transferu wiedzy między zespołami projektowymi. Prowadzi to do “ponownego wynajdywania koła” i zwykle dużych problemów występujących na początku projektu. Efektem tych zjawisk jest brak standaryzacji rozwiązań a więc i bardzo różna jakość procesów projektowych, co utrudnia sprawne funkcjonowanie DevOps. 
    • Nie jest efektywne kosztowo.

Wpływ powyższych problemów na projekty może być do zmniejszony poprzez odpowiednie procedury organizacyjne, nie da się go jednak całkowicie wyeliminować. Natomiast nagrodą za utrzymywanie poprawnego działania tego rozwiązania jest oczywiście jego największa sprawność w wypełnianiu rekomendacji DevOps – a zatem: szybkość, elastyczność, motywacja pracowników, małe narzuty organizacyjne, wysoki stopień współpracy Dev<->Ops w projekcie i inne.

  • Rozwiązania mieszane łączące w sobie kilka lub nawet wszystkie z wyżej wymienionych konfiguracji. Organizacje decydują indywidualnie, jaki poziom redundancji zasobów i różnorodności rozwiązań między projektami są w stanie zaakceptować. Dodatkowo, jakie usługi IT uważają za na tyle standardowe (często określane jako “towar” – ang. commodities), że warto wydzielić je do jednostek funkcjonalnych.

Często do zewnętrznych jednostek funkcjonalnych wydziela się np. administrację IT systemami PaaS (jak OpenShift), czy infrastrukturą baz danych. Dzieje się tak dlatego, że zwykle te usługi nie mają bezpośredniego udziału w pracach projektowych, a ich scentralizowanie jest ważne ze względu na wpływ na wiele różnych projektów.

Usługowe działy operacji natomiast wytwarzają i administrują narzędziami wykorzystywanymi przez działy wykonawcze. Ten sposób ułatwia rozpoczęcie prac osobom bądź zespołom Ops zlokalizowanym w projektach dostarczając im gotowych rozwiązań “z pudełka”.

Głównym celem przedstawienia powyższych informacji jest uświadomienie czytelnikowi, że jak zwykle nie ma jednego idealnego rozwiązania pasującego do wszystkich organizacji i każda z nich wdrażając i funkcjonując zgodnie z DevOps robi to nieco inaczej.

Opaczne rozumienie DevOps

W związku z relatywnie niedawnym rozpowszechnieniem się metodyki DevOps oraz różnorodnym charakterem rekomendacji przez nią dawanych, samo rozumienie pojęcia “DevOps” bywa bardzo różne w różnych środowiskach. Warto tu wymienić kilka najbardziej rozpowszechnionych sposobów opacznego rozumienia tego pojęcia lub wręcz typowych mitów z nim związanych. 

  • wdrożenie DevOps powoduje że działy operacji IT stają się niepotrzebne. W znakomitej większości realnych sytuacji jest to nieprawda choćby dlatego, że praca z szeroko rozumianą infrastrukturą IT wymaga innych kompetencji niż praca programistyczna i zwyczajnie opłaca się grupować podobne kompetencje w celu osiągnięcia choćby synergii niektórych działań, czy łatwiejszej wymiany wiedzy.
  • DevOps to tak naprawdę sytuacja gdy “programiści sami mogą robić operacje IT”. Taką opinię głoszą zwykle osoby mające doświadczenie wyłącznie w niewielkich (kilkuosobowych) projektach, często realizowanych bez większej presji czasowej. Właśnie w takich projektach, szczególnie gdy są realizowane za pomocą standardowych narzędzi używanych w danej organizacji, powszechną praktyką jest współdzielenie ról programistycznych z operacyjnymi. Osoby mające obowiązki z zakresu tych dwóch ról szybko jednak zaczynają specjalizować się w jednej z nich. Dzieje się tak natychmiast, gdy tylko skala wyzwań np. w obsłudze operacji staje się odpowiednio duża i angażująca.
  • DevOps to po prostu inna nazwa podejścia “automatyzujemy wszystko co się da”. Szerokie stosowanie automatyzacji (w tym w szczególności wspomniane tu “build jako kod”, “infrastruktura jako kod” czy “konfiguracja jako kod”) jest oczywiście jednym z filarów DevOps, ale ograniczanie się wyłącznie do niej degraduje tę metodykę do zbioru przepisów technicznych i zupełnie abstrahuje od zawartych w niej rekomendacji dotyczących zasad działania organizacji mającej funkcjonować zgodnie z DevOps. Co najważniejsze, aspekty organizacyjne są kluczowe dla sukcesu wykorzystania DevOps, ponieważ sama automatyzacja nie jest w stanie wprowadzić jakościowych zmian, których oczekuje się od DevOps.
  • DevOps zastępuje metodyki zwinne. Jak starano się to przedstawić we wcześniejszych częściach tego artykułu, jest wręcz odwrotnie – te metodyki to dwie strony tej samej monety. DevOps i metodyki takie jak Scrum opisują po prostu nieco inne elementy tego samego zbioru czynności jakie są wykonywane podczas produkcji, wdrażania i utrzymania oprogramowania. Często opisują one wręcz różne aspekty tych samych czynności. DevOps jest po prostu jedną z metodyk zwinnych – skoncentrowaną głównie na wewnętrznych aspektach funkcjonowania organizacji IT, natomiast w mniejszym stopniu definiujący np. różne aspekty współpracy z klientem podczas procesu realizacyjnego.
  • DevOps nie da się pogodzić z wdrożeniem dobrych praktyk ITIL. Dzięki temu że ITIL (zobacz) nie jest sztywno zdefiniowaną metodyką, a biblioteką najlepszych praktyk (co zresztą podkreśla nawet samo rozwinięcie nazwy będącej skrótem), jej wdrożenie może odbywać się selektywnie. Powoduje to że metodykę DevOps daje się pogodzić z tak wdrożonymi elementami ITIL. Na przykład, powszechną praktyką jest funkcjonowanie w tej samej organizacji procesów zarządzania incydentami i problemami (ang. Incident Management, Problem Management) zdefiniowanymi zgodnie z ITIL oraz metodyki DevOps. Prawdą jest jednak, że zdefiniowanie niektórych procesów szczególnie z zakresu Eksploatacji Usług (ang. Service Operation) tak aby spełniały również wymogi DevOps może stanowić spore wyzwanie.
  • DevOps nie da się pogodzić z wymogami bezpieczeństwa informacji. Wydaje się, że ta opinia ma swoje źródło w charakterystycznym dla DevOps braku wymogów dotyczących stworzenia list kontrolnych, wykonywania ręcznych kontroli/weryfikacji zabezpieczeń, a tym samym braku dokumentów, które można później przedstawić audytorom. Jak zostało to opisane wcześniej, nie oznacza to jednak że DevOps dopuszcza zaniedbanie aspektu bezpieczeństwa informacji. Zapewnienie tego bezpieczeństwa jest po prostu robione swoistymi dla DevOps metodami oraz narzędziami – i właśnie rezultatami z nich należy się posłużyć na audycie.
  • DevOps to po prostu inna nazwa działania metodą “pospolitego ruszenia”. W rozumieniu niektórych osób, za użyciem słowa DevOps kryje się po prostu brak jakiegokolwiek przemyślanego procesu w organizacji która identyfikuje się w ten sposób. Z drugiej strony, niektóre osoby w sposób świadomy używają tego określenia, aby ukryć właśnie taki stan rzeczy, sądząc błędnie, że DevOps sprowadza się właściwie do “róbmy wszystko jak najszybciej i jakoś to będzie”. Oba te punkty widzenia są w oczywisty sposób błędne.
  • DevOps używane jako słowo-klucz mające pokazać że “u nas w firmie stosujemy najnowocześniejsze metody produkcji oprogramowania”. Sytuacja podobna do opisanej powyżej, z tą jednak różnicą, że czasami słowo DevOps używane jest przez reprezentantów organizacji w np. wystąpieniach publicznych jako słowo-klucz mające podkreślić jak nowoczesna jest to organizacja. Samo w sobie nie jest to oczywiście niczym złym, czasami jednak takie deklaracje nie mają wiele wspólnego z rzeczywistością (patrz punkt powyżej) i są wyłącznie sztuczką marketingową.

Podsumowanie, czyli historia na pewno się nie skończyła

Metodyki zwinne, w tym DevOps osiągnęły w ciągu ostatnich dekad wielki sukces i są na najlepszej drodze do zdominowania przemysłu IT. Można nawet zaryzykować twierdzenie, że jedynym znaczącym bastionem który wciąż broni się przed podejściem zwinnym pozostają kontrakty dla instytucji publicznych.

Czy procesy zwinne są ostatecznym etapem ewolucji metod produkcji i obsługi systemów informatycznych? Zapewne nie, choćby ze względu na rozwój technologiczny w branży. 

Dość łatwo przewidzieć, że dalsze upowszechnianie się choćby rozwiązań chmurowych będzie miało wpływ na ewolucję podejścia do produkcji systemów informatycznych. Można też próbować ekstrapolować obecne trendy aby ocenić jaki to będzie miało wpływ – na przykład przewidując powiększające się rozpowszechnienie podejścia SaaS.

Ale już przykładowo wpływu rozwoju sztucznej inteligencji, czy będących wciąż w powijakach komputerów kwantowych na produkcję systemów informatycznych nie sposób obecnie ocenić. Co jeśli na przykład ktoś wpadnie na pomysł aby zaprząc AI stworzone np. w Tensorflow do administrowania bazą danych Oracle? Być może osiągnie w ten sposób przewagę nad konkurencją w efektywności zarządzania infrastrukturą i w kosztach? W końcu metody realizacji różnych systemów informatycznych są ograniczone tylko bieżącymi możliwościami technicznymi… natomiast inwencja ludzka jest nieograniczona – czego dowodzi najlepiej ta lista: ArchOps, BizOps, DataOps, DevSecOps, GitOps, WinOps, TestOps…


Zdjęcie główne artykułu pochodzi z unsplash.com.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
praca zdalna rekrutacja
Praca zdalna. O co pytać na rekrutacji?