Organizacje decydują się na transformację w duchu zwinności i tworzenie interdyscyplinarnych zespołów o różnych kompetencjach, by poprawić wydajność i jakość wytwarzania oprogramowania a także lepiej odpowiadać na potrzeby działów biznesowych. Tymczasem wdrażanie DevOps, chociaż przynosi pożądane rezultaty, nie zawsze należy do najłatwiejszych. 

O tym, że źródłem największych problemów towarzyszących każdej transformacji – strukturalnej, organizacyjnej, technologicznej – są ludzie, napisano i powiedziano już wiele. Pracownicy, przyzwyczajeni do utartych, sprawdzonych schematów funkcjonowania, nie są skłonni do podejmowania wysiłku, który wymaga od nich słynnego „wyjścia ze strefy komfortu”. 

Nie inaczej jest z koncepcją DevOps, czyli łączeniem działów programowania i utrzymania w jednostki wspólnie opracowujące i dostarczające nowe produkty. Skuteczne wdrożenie DevOps wymaga nie tyle zmiany technologicznej, co kulturowej – zgodnie ocenili uczestnicy spotkania „Na skróty do DevOpsa. Jak skleić Dev i Ops”, zorganizowanego przez CIONET Polska. 

O ile zespoły odpowiedzialne za wytwarzanie oprogramowania na ogół nie mają problemu z przejściem z metodyk kaskadowych na zwinne w procesie wytwarzania aplikacji, to kłopot może pojawić się na etapie wdrażania ich. Gdy działa się w ekspresowych cyklach produkcyjnych łatwo o pomyłki, błędy, niedoróbki, które w wymiarze technicznym prowadzą do awarii, a w biznesowym – do realnych strat finansowych czy wizerunkowych.

Rozwiązaniem tej sytuacji może być właśnie DevOps, które pozwala skupić wszystkie kompetencje wdrożeniowe w zespole produkcyjnym. Umożliwia to realizację projektów w wymaganym czasie, przy zachowaniu standardów jakościowych.

DevOps – argumenty „za”
Wprowadzenie DevOps przekłada się na realne korzyści dla organizacji. „DevOps to szybszy time-to-market, mamy też właścicielstwo rozwiązania od początku do końca w jednych rękach” – wymieniał Michał Kurasiński, Head of IT Systems Development w firmie Polpharma.

Z kolei Wojciech Mierzwicki, dyrektor IT w Nationale Nederlanden wskazywał na wyższy uptime (dostępność zasobów), wzrost liczby wdrożeń, a także – co szczególnie ważne – niższy stres organizacyjny.

Nie ma nadgodzin, zespoły dobrze przygotowują się do release'ów i robią to na bieżąco. Zmienił się sposób myślenia: zespoły mogą dość szybko wdrażać pomysły biznesowe. Można spać spokojniej – opisywał skutki wdrożenia DevOps w swojej firmie.

Wreszcie, proces rozwojowy produktu wygląda zupełnie inaczej, gdy informatycy biorą na siebie część odpowiedzialności za niego i to od momentu wypracowania pomysłu z działem biznesowym do chwili wycofania go z użycia (a nie tylko realizują zamówienia biznesu).

Problem w tym, że – co wynika zresztą z wypowiedzi Wojciecha Mierzwickiego – transformacja DevOps wymaga niekiedy przełamania barier mentalnych. Zasypanie podziałów wewnątrzorganizacyjnych „my-oni” lub, innymi słowy, development-utrzymanie, nie zadzieje się od razu.

Przykładowo, jak opisywał Piotr Opolski, bardzo ważnym etapem skutecznej transformacji DevOps powinna być analiza tego, gdzie znajduje się organizacja, jak powinna wyglądać docelowa struktura po zmianach i ile czasu potrzeba na ich przeprowadzenie. Konieczne jest też rozpoznanie potrzeb poszczególnych działów (obszarów) organizacji. W uporządkowaniu tej wiedzy przydają się takie role, jak właściciel produktu czy architekt DevOps.

„Trzeba dać ludziom czas i przestrzeń na poznanie nowej metodyki i narzędzi. Po przełamaniu bariery ‘moje/twoje’ idzie łatwiej, zespoły same motywują się do poprawy, rozwoju, działania” – powiedział Grzegorz Czarnecki, DevOps Team Leader w Polkomtelu.

DevOps to także wyzwania
Wojciech Mierzwicki wskazał jeszcze na jeden problem związany z oporem przed DevOpsem. Otóż, jego zdaniem, większość specjalistów ze ścisłym wykształceniem informatycznym dąży do poszerzania wiedzy i kwalifikacji w jednym obszarze i nie uśmiecha im się bardziej uniwersalne podejście, na przykład zahaczające o analizę i wrażanie potrzeb biznesowych. Tymczasem coraz więcej firm zaczyna pracować w taki właśnie sposób.

Z czasem stanie się standardem, że miejsc, gdzie można sobie ‘uciec’ na spokojne stanowisko programisty, będzie coraz mniej i będą coraz mniej atrakcyjne. Większość dużych firm pracuje w reżimie, gdzie wymaga się szerokich kompetencji i pracy z wieloma technologiami w mieszanych środowiskach – podkreślał.

Dodatkowym czynnikiem, który powinien dać opornym do myślenia, jest popularyzacja informatyki w modelu usługowym. Coraz więcej przedsiębiorstw rezygnuje z własnego działu programistycznego, decydując się na rozwiązania typu Software as a Service czy Platform as a Service. Konsekwencje tego trendu wyłuszczył Piotr Opolski: „Wydaje mi się, że DevOps to etap przejściowy, który będzie dość krótki. Owszem, teraz rozwiązuje jakieś problemy i pomaga, ale potrzeb związanych z operacjami jest coraz mniej, a świat przechodzi na SaaS. Musimy myśleć, by kadrę, którą mamy w obszarze Ops, już dziś zacząć transformować w obszar Dev, bo nie będzie dla nich pracy” – przestrzegał.

„Gdy firma używa dużo SaaS, DevOps też zaczyna przechodzić z obszaru sieciowego czy infrastrukturalnego w stronę biznesu, zarządzania wymaganiami biznesowymi, implementacji procesów biznesowych. Połączenie z biznesem jest coraz ważniejsze i trudniejsze” – dodał Michał Kurasiński.

Dyskusję podsumował Tomasz Krajewski, Senior Technical Sales Director – Eastern Europe & Nordics w firmie Veeam. Działy operacyjne – utrzymania, infrastruktury – trudno przekonać do zmiany status quo. Administratorzy lubią mieć technologię poukładaną tak, by „działała sobie w tle” – skomentował. Na dłuższą metę nie da się jednak w ten sposób funkcjonować. Działy IT czy developmentu muszą bowiem coraz mocniej wspierać biznes i wspólnie pracować na wynik.

„Współczesny świat ma to do siebie, że panuje w nim kultura natychmiastowości. Objawem tego stanu rzeczy jest oczekiwanie biznesu, by wszystko dostarczać mu szybko” – ocenił Krajewski.

Sprzężenie zwrotne jest jednym z filarów DevOpsa. Interdyscyplinarne działy muszą ze sobą rozmawiać i dzielić się doświadczeniem, umiejętnościami, wiedzą. Najważniejsze, by uświadomić sobie, po co robimy transformację w kierunku DevOps i żeby nie był to tylko wynik mody. Potem możemy ‘sprzedać’ tę ideę działom operacyjnym, rozmawiając z nimi językiem korzyści – dodał.