Czy zastanawialiście się, jakie są najczęstsze wymagania stawiane przez biznes działom IT? W dużej mierze skupiają się one na tym, aby nowe oprogramowanie lub nowe wersje czy poprawki pojawiały się coraz częściej i coraz szybciej. Nie jest to jednak łatwe, choćby z powodu różnic w podejściu zespołów odpowiedzialnych za rozwój i utrzymanie. Zadaniem zespołu rozwoju jest tworzenie oprogramowania, wprowadzanie zmian, uwzględnianie nowych funkcji oraz realizacja kolejnych, zmieniających się wymagań biznesowych. Z drugiej strony zespół odpowiedzialny za utrzymanie koncentruje się na stabilności, niezawodności i wydajności obsługiwanych systemów. Te dwa, często sprzeczne cele, generują wiele wyzwań i problemów.
Jeszcze do niedawna wiele działów IT było raczej ograniczeniem, wąskim gardłem biznesu, niż obszarem, który wspierał go strategicznie. Obecnie, często konieczne jest poprawianie jakości usług IT i lepsze wsparcie działalności biznesowej. W wielu organizacjach nowe oprogramowanie dostarczane jest z opóźnieniem oraz dużą ilością błędów, a poprawki i kolejne wersje wydawane są tylko kilka razy w roku. Z tego względu koszty są dalekie od optymalnych, natomiast procesy zarządzania usługami IT są postrzegane jako utrudniające, a nie ułatwiające funkcjonowanie. Warto zastanowić się czy można tą sytuację zmienić.
Niepotrzebne podziały
Typowym wyzwaniem w tradycyjnych organizacjach IT jest tzw. „mur niezrozumienia” pomiędzy zespołami rozwoju (development – w skrócie Dev), a zespołami utrzymania (operations – w skrócie Ops).
Wspomniany mur jest psychologiczną i proceduralną barierą, która utrudnia komunikację oraz przepływ wiedzy między zespołami. Brak właściwego porozumienia może powodować wydłużenie czasu rozwiązania incydentów oraz problemów, pojawiających się w systemach produkcyjnych, które są „pod opieką” zespołów utrzymania. Przyczyną takiego stanu może być to, że:
- Zespoły utrzymania nie są właściwie przygotowane do wsparcia nadchodzących zmian, gdyż zwykle nie uczestniczą we wcześniejszych fazach rozwoju (brak wymiany informacji);
- Zespoły rozwoju nie korzystają z doświadczeń zespołów utrzymania, dotyczących zarządzania środowiskiem produkcyjnym. Te doświadczenia mogłyby pomóc w opracowaniu bardziej niezawodnych rozwiązań;
- Obu zespołom brakuje zaangażowania w tworzenie wspólnej bazy wiedzy, z której mogłyby korzystać.
W sytuacji, gdy odpowiedzialność za rozwój i utrzymanie systemów jest podzielona pomiędzy dwa zespoły, a dodatkowo każdy z nich ma inne cele (rozwój, zmiany vs. stabilność, niezawodność), trudno jest o całościowe, zintegrowane podejście do rozwoju oraz utrzymania czy przyjęcie na siebie całkowitej odpowiedzialności za tworzone i utrzymywane systemy.
Pracujmy razem!
Aby wspierać kulturę wspólnej odpowiedzialności konieczne są zmiany, takie jak: usunięcie zbędnych podziałów pomiędzy zespołami rozwoju i utrzymania; unikanie jednorazowego przekazywania wiedzy oraz dokumentacji – tylko pod koniec projektu (lepszym sposobem dzielenia się wiedzą jest wspólna praca nad rozwiązaniem od samego początku); dostosowanie struktury zasobów w zespołach utrzymania tak, aby umożliwić ich członkom wczesne zaangażowanie w pracę zespołów rozwoju; zorganizowanie wspólnej przestrzeni pracy dla obu zespołów; unikanie formalnego przekazywania i składania podpisów (to zniechęca do dzielenia się odpowiedzialnością oraz przyczynia się do tworzenia kultury obwiniania, a nie kultury wspierającej); zachęcanie członków zespołów rozwoju i utrzymania do przyjęcia odpowiedzialności za sukcesy, ale także za awarie systemu.
Całościowym rozwiązaniem może być zastosowanie kultury DevOps. Zaciera ona granice między zespołami rozwoju oraz utrzymania. Ostatecznie może doprowadzić do całkowitego zniesienia różnic i podziałów, powodując stworzenie jednego zespołu, odpowiedzialnego od początku do końca za rozwój i utrzymanie systemów
Krótka historia DevOps
Według Damona Edwardsa ruch DevOps został zapoczątkowany w Belgii w 2007 roku. Patrick Debois, konsultant IT, był zmęczony ciągłą walką oraz brakiem komunikacji i współpracy pomiędzy działami rozwoju i utrzymania. Znalazł się między dwoma zespołami, pracując nad ogromnym projektem migracji centrów danych dla belgijskiego rządu. Był przekonany, że istnieje lepszy sposób pracy, który pozwoli zlikwidować istniejące bariery między tymi dwoma zespołami.
Rok później, na konferencji Agile w Toronto, Andrew Shafer zaproponował sesję zatytułowaną „Agile Infrastructure”. Patrick Debois był jedynym, który chciał w niej uczestniczyć. Spotkanie doprowadziło do powstania grupy dyskusyjnej Agile System Administration. To między innymi dzięki tym działaniom narodziła się konferencja DevOpsDays, a jej inaugurująca edycja odbyła się pod koniec października 2009 r. w Ghent w Belgii. Wydarzenie przyciągnęło wielu administratorów, programistów i menedżerów z całego świata. Sukces imprezy zainspirował do powtórzenia wydarzenia DevOpsDays w innych częściach świata. Kolejne spotkania zadziałały jak katalizator, wzmacniając ten oddolny ruch. W rezultacie podejście DevOps było i jest coraz częściej stosowane w wielu firmach, m.in. Spotify, Airbnb, Uber, Netflix.
Pomysł z duszą
DevOps jest modelem kulturowym i operacyjnym, który wspiera współpracę w celu uzyskania wysokiej wydajności IT oraz by umożliwić osiągnięcie celów biznesowych.
Najważniejsze zasady DevOps, to:
- Działanie zorientowane na klienta: stosowanie krótkich pętli zwrotnych z klientami i użytkownikami końcowymi.
- Tworzenie produktu (np. oprogramowania) z myślą o całościowym rozwiązaniu: zasada ta koncentruje się na zrozumieniu rzeczywistych potrzeb klientów oraz pracy nad tworzeniem produktów i usług, które rozwiązują ich problemy.
- Odpowiedzialność od początku do końca: w organizacji DevOps zespoły są tak zorganizowane, aby mogły być w pełni odpowiedzialne za dostarczane produkty i usługi – zarówno za ich rozwój jak i utrzymanie.
- Międzyfunkcjonalne, autonomiczne zespoły: muszą być w pełni niezależne, a jednocześnie posiadać całą niezbędną wiedzę konieczną do przyjęcia odpowiedzialności od początku do końca cyklu życia produktu lub usługi IT.
- Ciągłe doskonalenie: w kulturze DevOps kładzie się duży nacisk na ciągłe doskonalenie w celu ulepszania produktów/usług oferowanych klientom.
- Automatyzowanie tego, co się da: automatyzacja jest sposobem na przyśpieszenie rutynowych działań, powoduje powtarzalność i eliminację błędów. Automatyzacja oznacza również doskonałe rozumienie procesów niezbędnych do rozwoju oraz dostarczania usług IT.
Statystyki z raportu State Of DevOps 2018 (jak również raporty z poprzednich lat) pokazują, że stosowanie DevOps znacząco wpływa na skrócenie czasu wprowadzania produktów na rynek, jak również szybsze i bezpieczniejsze nanoszenie zmian w istniejących produktach.
Bez wątpienia kultura ta oddziałuje także na ciągłą integrację i dostarczanie produktów. Ciągła integracja jest praktyką rozwojową, polegającą na wprowadzaniu kodu do wspólnego repozytorium kilka razy dziennie. Zautomatyzowany proces budowania w połączeniu z automatycznym testowaniem, pomaga zweryfikować każde wydanie produktu, co zapewnia stabilniej działające oprogramowanie.
DevOps pomaga też osiągnąć wyższą jakość, zmniejszyć ilość awarii oraz uzyskać większą stabilność. Systemy nie tylko spełniają wymagania funkcjonalne i niefunkcjonalne, ale też cechują się większą niezawodnością, łatwością utrzymania oraz większym bezpieczeństwem. Również z raportów State Of DevOps z lat 2014 do 2018 wynika, że organizacje, które przyjęły sposób myślenia i kulturę DevOps, mają mniej awarii niż te, które nie wykorzystują tego podejścia. Wdrażanie nowych funkcjonalności, często w mniejszych „paczkach”, umożliwia łatwiejsze i szybsze rozwiązywanie problemów. Połączenie narzędzi oraz najlepszych praktyk z automatyzacją pozwala zespołowi DevOps zwiększyć ogólną stabilność systemów.
Co istotne, poprzez wykorzystanie ciągłej integracji, znormalizowanych środowisk produkcyjnych oraz zautomatyzowanych wdrożeń, specjaliści mogą skupić się na innowacjach i kreatywności. Ponadto, DevOps zapewnia środowisko oparte na współpracy i wielu umiejętnościach, co w znacznym stopniu przyczynia się do zadowolenia z pracy. Praktyki oraz kultura DevOps zwiększają satysfakcję pracowników, co prowadzi do lepszych wyników biznesowych. Dodatkowo, dzięki łączeniu wielu zespołów i dyscyplin w jeden, dobrze współpracujący, komunikujący się zespół, DevOps pomaga usunąć silosy organizacyjne. Stosowanie podejścia ciągłego udoskonalania sprawia również, że ten sposób myślenia pozwala zespołom na szybkie i wydajne wykonywanie zadań – przy jednoczesnym zachowaniu stabilności i jakości.
DevOps wpisuje się w nurt rozwiązań bazujących na współpracy, eliminowaniu barier w komunikacji, wymianie wiedzy i doświadczeń w zespołach. Tym samym stanowi jeden z przykładów podejść agile, w pełni zbieżnych z dążeniem do zwinności w projektach. DevOps może stanowić nieocenione wsparcie w bieżącej działalności operacyjnej oraz projektach realizowanych przez działy IT.
A co najważniejsze – podejście DevOps przekłada się na realną pomoc w działalności biznesowej.
Doradca i konsultant w obszarze zarządzania projektami i usługami IT. Wspiera przedsiębiorstwa, które chcą zmienić sposób pracy na bardziej zwinny. Doradza przy tworzeniu i doskonaleniu biur wspierających zarządzanie projektami, programami i portfelami. Uczestniczył w realizacji szeregu projektów w obszarze telekomunikacji, IT oraz edukacji. Konsultant oraz akredytowany trener wielu metodyk i dobrych praktyk w firmie OMEC (www.omec.pl). Posiada tytuł Executive MBA przyznany przez Polish Open University we współpracy z Oxford Brookes University