Rozwiązania DevOps szansą dla rozwoju projektów IT

Rozwiązania DevOps szansą dla rozwoju projektów IT DevOps

Skrócenie i uproszczenie procesu wdrażania oraz implementacji projektów, minimalizowanie kosztów i przestojów, ograniczenie biurokracji… To zaledwie część korzyści płynących z zastosowania rozwiązań DevOps.

 W tym roku w Polsce po raz pierwszy będziemy mieli okazję uczestniczyć w najważniejszym wydarzeniu poświęconym tej tematyce – DevOpsDays. Na czym właściwie polega ta metodyka i dlaczego warto poszerzać swoją wiedzę w tym zakresie? O spotkaniu i idei DevOps rozmawialiśmy z Piotrem Szwedem, od wielu lat rozwijającym społeczność DevOps w Polsce.

Czym jest DevOps?

Pojęcie DevOps powstało w wyniku połączenia dwóch angielskich słów – development (rozwój) oraz operations (operacje). W kontekście IT oznaczają one poszczególne działy i grupy specjalistów. W każdej firmie znajduje się dział rozwoju z ekipą developerów programujących aplikacje, a także dział utrzymania, w którym pracują administratorzy utrzymujący środowiska, w których te aplikacje działają. Programiści zajmują się więc tworzeniem kodu, czyli produktu, a administratorzy całą infrastrukturą. Główną początkową ideą DevOps było połączenie tych dwóch zespołów w jeden w celu usprawnienia współpracy obu działów – to połączenie odzwierciedla właśnie nazwa tego rozwiązania. Obok tego, bardzo ważnym fundamentem DevOps jest również znaczne usprawnienie komunikacji pomiędzy zespołami i różnymi warstwami zarządzania w danej organizacji, co zwykle wiąże się z rozwijaniem kultury otwartości, współdzielenia wiedzy, głębszej współpracy i mniej formalnej komunikacji, co w efekcie sprawia, że informacja krąży w obiegu organizacji znacznie szybciej, niż to ma miejsce w typowych sztywnych korporacyjnych procedurach i sformalizowanych metodykach opartych na nie zawsze najefektywniejszych procesach.

Dlaczego współpraca tych działów jest tak potrzebna?

Wcześniej oba te środowiska miały nieco przeciwstawne cele, stały w oddzielnych silosach. Celem developerów było jak najszybsze utworzenie jak największej liczby produktów oraz wdrożenie ich na platformy produkcyjne dostępne dla klienta. Z drugiej strony stał zespół operations, w którego interesie leżało niewprowadzanie zmian, gdyż każda zmiana wiąże się zawsze z jakimś ryzykiem i potencjalnymi przestojami w świadczeniu usług, za które zwykle zespół ten jest odpowiedzialny. Więcej zmian oznacza więcej pracy, a także mniej stabilne środowisko, ryzyko awarii oraz błędów. Zmiany zawsze prowadzić mogą do komplikacji, a w przypadku ich wystąpienia to głównie zespół operations ponosi ich konsekwencje, a nie programiści. W efekcie, developerzy siedzieli w swoim silosie, a administratorzy w swoim, przerzucając piłeczkę z jednego rejonu odpowiedzialności na drugi – tak powstał tzw. ping-pong, czasem zwany również tzw. „gorącym ziemniaczkiem” którego nikt nie chce po swojej stronie.

Idea DevOps miała uwspólniać ich cele?

Na początku DevOps polegał na połączeniu ze sobą tych dwóch zespołów, tak by pracowały razem. W tym celu wykorzystuje się różne metody, jedną z prostszych i ciekawszych jest tzw. shadow programming. Polega ona na tym, że jeden z administratorów zostaje na jakiś czas skierowany do pracy razem z developerem – siedząc obok niego na fotelu i obserwując jego pracę, próbuje ją zrozumieć i nauczyć się wykonywać podobne działania. Później następuje zamiana ról i developer dowiaduje się, w jaki sposób zespół administratorów obsługuje powstałe oprogramowanie, które on tworzy po swojej stronie silosu. Od czasu powstania idei DevOps, czyli od 2009 roku, rozrosło się to i poszło w wielu różnych kierunkach. Dziś pomysł połączenia zespołów development i operations przeniósł się także na inne warstwy, jak np. testowanie kodu, zarządzanie, bazy danych czy sieci. Obecnie główną ideą jest połączenie całości IT w jeden organizm, tak by nie było już żadnego silosu. Zmiany są kompleksowe i dotyczą każdego pionu firmy, ze szczególnym uwzględnieniem warstwy biznesowej, która musi się szczególnie dostosować do nowych warunków, pozwalających jej na osiąganie swoich celów znacznie szybciej i taniej.

Ogromnie ważną rolę w tym wszystkim odgrywają narzędzia do automatyzacji pracy. W DevOps niedopuszczalne są manualne czynności, jak np. ręczne wypełnianie będących zmorą większości firm arkuszy w programie Excel. Każda informacja zapisywana jest w jednym miejscu, a jeśli jest ona potrzebna gdzieś indziej, to systemy informatyczne automatycznie odnajdują ją i wykorzystują.

Kolejna istotna kwestia to zmiana kultury w firmie, która powinna iść w parze z likwidacją silosów oraz automatyzacją pracy. Wbrew pozorom to jeden z najtrudniejszych elementów podczas wdrażania rozwiązań DevOps, ponieważ wymaga od pracowników przywyknięcia do innego systemu pracy – przykładania mniejszej uwagi do sztywnych procesów i procedur i kładzenia znacznie większego nacisku na kolaborację i wymianę informacji, często w nieformalny sposób.

Na czym polega ta kultura?

Możemy tu zwrócić uwagę na kilka różnych aspektów. Jednym z nich jest dzielenie się między sobą informacją i wiedzą o tym, co aktualnie robimy. W kulturze DevOps developer nie zamyka się sam w pokoju, programując, tylko wymienia się z innymi swoimi doświadczeniami, opowiada na bieżąco o tym, co akurat robi. Co ważne, nie są to formalne, ustrukturyzowane wypowiedzi czy prezentacje – chodzi tu raczej o luźne rozmowy „przy kawie”, dzięki którym wszyscy są bardziej świadomi tego, co się dzieje w innych działach. Pozwala to pobudzać kreatywność, wpadać na nowe pomysły czy też nawet wykrywać potencjalne błędy. Tu warto wspomnieć o istotnej sprawie, jaką jest kultura promowania popełniania błędów. Dla wielu osób to absolutna nowość, bo zwykle popełnianie błędów kojarzy nam się z dezaprobatą i dążymy do jak najstabilniejszej produkcji w swoich programach. W kulturze DevOps pozwala się na eksperymenty, testowanie pomysłów oraz publikację nawet tych nie do końca dopracowanych. Chodzi o to, by trafiły do odbiorcy jak najszybciej, żeby ktoś mógł je zobaczyć. Nawet jeśli coś okaże się niestabilne, nie do końca działające w oczekiwany sposób, to nie będzie stanowić to problemu – błąd szybko się naprawi, a i tak produkt końcowy będzie dostępny wcześniej niż w przypadku zastosowania standardowych procedur.

Podsumowując, kultura DevOps to mniej niepotrzebnych procesów, oficjalnych spotkań, biurokracji, czyli jednym słowem: oszczędność czasu. Tam, gdzie jest to możliwe, zamiast mailowania czy komunikacji internetowej wybieramy bezpośredni kontakt, najlepiej mało sformalizowany. Dodatkowym plusem jest empatia, wynikająca z lepszego zrozumienia drugiego działu, oraz poprawienie jakości komunikacji – ludzie przestają ze sobą walczyć, a zaczynają współpracować. Tym samym atmosfera pracy staje się lepsza, a badania pokazują, że większość inżynierów branży IT bardziej ceni sobie lepszą atmosferę w pracy niż wysokość zarobków.

Jakie najważniejsze korzyści otrzymujemy po wprowadzeniu rozwiązań DevOps?

Z punktu widzenia właściciela, kierownika firmy czy dyrektora, DevOps oznacza przede wszystkim szybsze dostarczanie produktów z działu IT, przy jednoczesnym obniżeniu kosztów oraz zachowaniu wysokiej jakości – to są standardowe biznesowe współczynniki. Kluczowe jest tutaj skrócenie tzw. „Time to Market” (TTM), czyli czasu potrzebnego na dostarczenie odbiorcy w pełni gotowego i funkcjonalnego produktu. Dawniej np. banki wrzucały na swoje serwery nową wersję oprogramowania co pół roku albo co rok. Po wdrożeniu metodologii i technik automatyzacji DevOps są w stanie wypuszczać nową wersję aplikacji co tydzień, co dwa dni, a nawet codziennie. Zdarzają się już przypadki, gdzie banki wypuszczają nowe wersje aplikacji nawet 10 razy dziennie. Kiedy konkurencyjny bank wymyśli i wdroży jakąś nową funkcjonalność, to dzięki DevOps możemy w ciągu jednego czy dwóch dni zaimplementować i wdrożyć to samo u siebie, gdy dawniej trwałoby to zwykle kwartał lub kilka. Tak więc zyskujemy znaczną oszczędność czasu i pieniędzy, i to jest najważniejsze z punktu widzenia zarządu w organizacji. To jest to, co sprawia, że warstwa biznesowa jest zwykle również wielkim adwokatem i promotorem wdrażania rozwiązań DevOps. Warto też zaznaczyć, że chociaż automatyzacja pozwala na zmniejszenie kadry, to w DevOps bardzo rzadko dochodzi do takiej sytuacji. Osoby, których obowiązki są zastępowane poprzez automaty, zajmują się zwykle innymi rzeczami – np. rozwojem systemu do automatyzacji, tworzą kolejne jego elementy, poszerzają jego zakres, poprawiają i optymalizują już istniejące moduły – w efekcie wykonują znacznie ciekawsze zadania niż monotonne, mało lubiane i powtarzalne prace manualne którymi zajmowali się wcześniej.

Jedną z przyczyn, dla których DevOps zyskuje popularność na całym świecie, jest fakt, że pojęcie to nie ma ścisłej definicji, jednoznaczniej recepty. Brak tej precyzji oraz sztywnych zasad postępowania jest celowy – ma zachęcać ludzi do kreatywnego myślenia i ciągłego zadawania sobie pytań. To pojęcie ma pozostać otwarte, żeby ludzie poprzez budowanie kultury i społeczności DevOps nieustannie zastanawiali się, jak można jeszcze bardziej udoskonalić ten ich świat IT.

Skąd się wziął DevOps?

Autorem pojęcia DevOps oraz organizatorem pierwszej konferencji związanej z tą tematyką jest Patryk Debois, mieszkający w Belgii. Wspomniana konferencja odbyła się w 2009 roku w Gent i zapoczątkowała dyskusję na temat połączenia dwóch silosów: development i operations. Na spotkanie przybyło 80 osób – wszystkim się spodobało, a na blogach, portalach internetowych oraz różnych innych social media pojawiło się wiele wpisów poruszających zagadnienia związane z DevOps. Wkrótce w różnych miejscach na świecie ludzie zaczęli się organizować i zaczęto kopiować ideę konferencji DevOpsDays. W ciągu pięciu lat społeczność rozrosła się i dziś ma swoich przedstawicieli na całym świecie. Po upływie kilku lat tematem zainteresowali się ludzie biznesu, kierownicy, dyrektorzy i właściciele firm, którzy zauważyli płynące z zastosowania tych rozwiązań korzyści – zaoszczędzone pieniądze i czas, a zwłaszcza współczynnik Time to Market. Od tego czasu DevOps przeżywa prawdziwy boom.

Odkąd biznes zauważył ogromny potencjał DevOps i możliwość zastosowania jego metodyki w każdej firmie posiadającej dział IT, wszyscy starają się iść w tym kierunku, np. poprzez inwestycje, ale przede wszystkim dzięki poszerzaniu swojej wiedzy. Zaczęły powstawać książki, jak np. „Phoenix Project”, która odegrała znaczącą rolę w rozwoju DevOpsu, a na portalach branżowych czy LinkedIn pojawiło się mnóstwo ofert pracy dla specjalistów w tym zakresie.

Skąd pomysł na zorganizowanie DevOpsDays w Warszawie?

Jestem organizatorem DevOps Days w Polsce. Przez rok miałem okazję mieszkać w Belgii, blisko Patryka, więc udało mi się odbyć z nim kilka owocnych spotkań. Zauważyłem, że wśród ludzi uczęszczających na konferencje DevOps, jeżdżących na Zachód lub biorących udział w życiu tej społeczności online, jest duża grupa Polaków. Po kilku spotkaniach z Patrykiem doszliśmy do wniosku, że skoro tyle osób z Polski jest zainteresowanych tym tematem, to warto byłoby zorganizować im konferencję na miejscu. Stąd właśnie pomysł na DevOps Days w Warszawie.

Poza tym warto zauważyć, że w Belgii DevOps Days obchodzą już swoje pięciolecie. Podczas gdy w innych, bardziej rozwiniętych krajach ma miejsce swego rodzaju rewolucja w IT, to w Polsce do tej pory bardzo niewiele działo się w tym zakresie. A to oznacza, że zostajemy nieco w tyle. Chciałbym to zmienić, wypromować ten ruch, narzędzia zbudowane na jego fundamentach i wszystkie powiązane metodyki. Mam nadzieję, że dzięki temu polskie IT ruszy do przodu i nadgoni konkurencję tam, gdzie mamy jeszcze jakieś braki. Nie chcemy przecież, żeby było tak, jak np. w przypadku przemysłu motoryzacyjnego, gdzie korzystamy z wiedzy i technologii architektów samochodów np. z Niemiec, a sami w Polsce jedynie składamy komponenty, stanowiąc tanią siłę roboczą. Moją ideą jest zatem, żeby przy okazji tego wydarzenia dać Polakom motywację oraz zainteresować ich rozwiązaniami, które bez wątpienia są przyszłością IT. Chcę pokazać, że możemy rywalizować z Zachodem, będąc na bieżąco i poprawiając czy udoskonalając wymyślane przez zachodnich specjalistów narzędzia. W przeciwnym razie obudzimy się dopiero za parę lat i będziemy zmuszeni do kupowania takich narzędzi za duże pieniądze, a konkurowanie z coraz bardziej wydajnymi rozwiązaniami IT będzie bardzo trudne. Dziś jeszcze jesteśmy na takim etapie, że możemy je współtworzyć, możemy dołączyć się do ruchu, który definiuje, jak będzie wyglądała przyszłość. Możemy być pionierami.

Moim celem jest też poznanie ludzi z tej społeczności w Polsce, żeby móc razem zastanawiać się, jak możemy skutecznie rozwijać ideę DevOps na naszym rodzimym gruncie i jak współpracować ze światowymi liderami w branży. W Polsce już jakiś czas temu zaczęły powstawać pewne zalążki DevOps w niektórych firmach, np. pracownicy Allegro brali udział w konferencji DevOps Days w Amsterdamie w tamtym roku oraz stworzyli bardzo ciekawe narzędzie DevOps’owe – Ralph. Onet opowiedział o swoich doświadczeniach w kilku artykułach na temat wdrażania DevOps i metodologii DevOps u siebie w firmie. Jest też kilka innych przykładów, że DevOps w Polsce żyje i że pierwszą styczność z tym rozwiązaniem część z nas ma już za sobą. Na DevOps Days wszyscy się spotkają i będzie to wspaniała okazja do zawiązania się społeczności, wymiany doświadczeń i pogłębienia współpracy.

A skoro w Polsce DevOps jest na etapie raczkowania, to kim będą prelegenci na najbliższej konferencji? Czy będą to Polacy, czy raczej ludzie z zagranicy?

Wśród prelegentów pojawią się osoby z całego świata. Będziemy mieć speakerów ze Stanów Zjednoczonych, Austrii, Francji, Białorusi, Ukrainy, Czech – z całej Europy i trochę dalej. Spodziewamy się także gości z wielu różnych krajów i kontynentów, w tym Polaków, którzy pracują w IT za granicą i odwiedzają Polskę prywatnie, przy okazji uczestnicząc w DevOps Days. Część speakerów zaprosiliśmy, inni zgłosili się do nas sami, widząc, że jest taka konferencja. Niektórzy prelegenci zostali przysłani przez zainteresowane biznesowymi korzyściami firmy, które używają technologii DevOps i dzięki temu działają sprawniej oraz wyróżniają się na tle konkurencji. Wiele firm chce się podzielić swoimi doświadczeniami z wdrożenia DevOps po to, żeby dodać odwagi innym. Będziemy mieli zatem okazję poznać DevOps „od kuchni” – około jedna czwarta prezentacji będzie dotyczyła tego, jakie korzyści odniosły konkretne firmy po wdrożeniu DevOps, lecz także jakie problemy oraz doświadczenia się z tym wiązały.

Jaka jest różnica między DevOps na Zachodzie i w Polsce?

Różnica jest zasadnicza – na Zachodzie menedżerowie chętniej rozmawiają z inżynierami. Nikogo nie dziwi, jeśli właściciel firmy czy dyrektor departamentu usiądzie z pracownikami najniższego szczebla i będzie z nimi rozmawiać czy wymieniać się doświadczeniami, a to jest przecież właśnie idea DevOps. W Polsce takie zachowanie wciąż nie jest standardem. Większość menedżerów unika kontaktu z szeregowym pracownikiem, obawiając się bariery kulturalnej czy utraty autorytetu. Wszystko to bardzo utrudnia wprowadzenie zasad DevOps w naszym kraju. A w DevOps idea jest taka, żeby wszyscy – zarówno pomiędzy silosami, jak i pomiędzy szczeblami – komunikowali się ze sobą, spotykali się i rozmawiali w luźnej atmosferze. Polskie uwarunkowania historycznie (wiele lat komunizmu) powodują, że przełamywanie tego typu barier jest szczególnie trudne.

Jak wygląda społeczność DevOpsowa w Polsce i jak do niej dołączyć?

Społeczność DevOpsowa w Polsce to comiesięczne spotkania, ruch w social media i – przede wszystkim – coroczne DevOps Days, które w tym roku po raz pierwszy odbywają się w naszym kraju. W dniach 25-26 września w Warszawie odbędzie się międzynarodowa konferencja DevOps Days Warsaw 2014, podczas której będzie można wysłuchać prezentacji przygotowanych przez największe autorytety w tej dziedzinie oraz przedstawicieli najbardziej znanych w branży międzynarodowych firm, jak np. IBM, Ebay, Samsung, Chef, czy Prezi.

Do społeczności możemy dołączyć w łatwy sposób za pośrednictwem social media – Twittera, Facebooka itp. A wszystkie osoby, które chcą poszerzać swoją wiedzę w tym zakresie, zapraszam na DevOps Days Warsaw 2014.

Czy wdrożenie DevOps powoduje, że poprzednie techniki i metodologie odchodzą do lamusa?

Nie, to nie jest samo w sobie celem. Chodzi raczej o to, aby poprzednie techniki czy metodologie zostały zaadaptowane i ulepszone do tego, co daje DevOps. Nie powinny one blokować możliwości wdrożenia tej idei, a raczej umożliwiać osiągnięcie nowych celów. Dobrze jest pamiętać jednak, że „stare” technologie też wnoszą do organizacji jakąś wartość, z której nie chcemy rezygnować. Natomiast nie we wszystkich aspektach są one kompatybilne z DevOps i tam, gdzie nie są, powinny zostać zaadaptowane.

materiały PR

Dalej

x

5 komentarzy

Nie udało się dodać komentarza, spróbuj ponownie za chwilę

Komentarz powinien być dłuższy niż 5 znaków

Prosze wprowadzić prawidłowy adres e-mail

Nick powinien być dłuższy niż 4 znaki

  • philippe philippe

    magnat> popieram opcje, niekiedy stare ale sprawdzone kwestie są najlepsze. BTW ostatnio poszukiwałem konkretnego miejsca pracy w branży IT w stolicy i słyszałem od znajomego zainteresowanego tą samą branżą, że w Atos poszukują nieustannie specjalistów i to od groma bo ogarniają globalne projekty więc nie ma czasu na zabawę w klocki, i tak wyszło, że współpracuję z nimi już pół roku. Polecam - firma stabilna, konkretne warunki, bardzo dobry socjal, zarobki rosną w miarę dośw., i ekipa świetnych ludzi, robi wrażenie :)

    2015-01-13 14:13:14

    Oceniono 0 razy

    x

    Odpisz na ten komentarz

  • adrian adrian

    Nie specjalnie się na tym znam, ale chyba nic w tym złego, że ludzie o wspólnych zainteresowaniach i pasjach integrują się. Sama nazwa mało mówiąca dla zwykłego śmiertelnika, ale.. to nie moja sprawa, w końcu jet to ''nazwa własna''.

    2014-10-10 16:56:13

    Oceniono 0 razy

    x

    Odpisz na ten komentarz

  • janusz janusz

    U nas idea DevOps zatrzymała się na organizowanych raz czy dwa razy do roku spotkaniach integracyjnych. Wtedy rozmawiają wszyscy ze wszystkimi a nawet poklepują się po ramieniu. :)

    2014-10-10 10:46:27

    Oceniono 0 razy

    x

    Odpisz na ten komentarz

  • Big Man Big Man

    Jak w każdym zawodzie w dzisiejszych czasach są wprowadzane zmiany.Nie dziwi wiec że dosięgły tez rynek IT.Nie wiadomo do czego to doprowadzi ale miejmy nadzieję że idzie ku lepszemu bo nie zawsze narzędzia do automatyki pracy sa dobre,czasem lepiej coś wykonać wolniej a lepiej.

    2014-10-03 15:46:10

    Oceniono 0 razy

    x

    Odpisz na ten komentarz

  • magnat magnat

    Można ulepszać wszystko. Lubię nowości ale wolę pozostać przy sprawdzonych rzeczach. Jak ktoś kiedyś powiedział: "stare ale jare".

    2014-10-03 00:43:06

    Oceniono 0 razy

    x

    Odpisz na ten komentarz