DevOps

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Michałem Bohuszewiczem o podejściu DevOps.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć, mój dzisiejszy gość jest w branży IT, już od ponad 19 lat, pracował jako project manager i service menager. Zajmował się analizą biznesową, brał udział w kilku różnych transformacjach IT oraz zarządza zespołami IT. Obecnie pracuje jako senior project manager w Netguru. Moim i waszym gościem jest Michał Bohuszewicz.

Cześć Michał, bardzo mi miło gościć Cię ponownie w podcaście.

Cześć Krzysztof, dziękuję za zaproszenie.

Michał był już niedawno moim gościem, występował w odcinku o Scrumie, do tego odcinka jak najbardziej zachęcamy. Dzisiaj natomiast porozmawiamy sobie o takim drugiej specjalizacji Michała, mianowicie o DevOps. Na początku nie może, nie paść to sakramentalne pytanie, na które już odpowiedziałeś w tamtym wspomnianym odcinku, mianowicie, czy słuchasz podcastów? Jeśli tak, to gdybyś mógł pokrótce przypomnieć, jakie to są podcasty.

Staram się sięgać, do podcastów, które poruszają tematy, aktualnie mnie interesujące. Niejednokrotnie słucham Maćka Aniserowicza i jego gości w podcaście DevTalk, często sięgam też do podcastu Porozmawiajmy o IT, chętnie słucham też podcastu Management 3.0, który można znaleźć np. Spotify jako Happy Melly albo Happiness at Work. Zachęcam do zapoznania się z tymi materiałami, bo bardzo dużo ciekawych podcastów, zostało tam nagranych. Może jeszcze tak nowa rzecz, którą ostatnio słucham, żeby podszkolić swój angielski — Plain English, dość ciekawy podcast, bardzo interesujące historie są opowiedziane zrozumiałym, prostym angielskim, ale też z dawką dodatkowych słówek, czy gramatyki, którą można sobie przyswoić.

Formalności mamy już za sobą, możemy przejść do tematyki dzisiejszego podcastu. Michał, skąd się u Ciebie wzięło zainteresowanie tematyką DevOps?

Przez te swoje 19 lat spędzone w IT, większą część spędziłem po stronie związanej z utrzymaniem, wsparciem użytkowników, ogólnie po angielsku, natomiast od 6 lat, jestem po tej drugiej stronie barykady, w tym obszarze odpowiedzialnym za rozwój systemów informatycznych. Tego słowa barykada używam celowo, bo przez lata pracy odnoszę takie wrażenie, że ten rozwój i utrzymanie, czyli ten development and operation, to takie dwa wrogie obozy, które zwykle nie za bardzo się lubią albo nawet walczą ze sobą w taki otwarty sposób. Często w organizacjach są oddzielne departamenty odpowiedzialne za rozwój i utrzymanie, mające oddzielnych managerów, dyrektorów. Tworzą się takie silosy, które w najlepszym przypadku nie najbardziej się lubią, a często prowadzą otwartą wojnę między sobą. Gdy zacząłem poznawać podejście, które jest reprezentowane przez DevOps, to zobaczyłem, że można inaczej, że można współpracować, można wspólnie starać się dostarczać wartość do tzw. biznesu. To bardzo mi się spodobało i zrozumiałem, że zamiast walczyć ze sobą, możemy walczyć z problemami, które nam się przytrafiają w naszej pracy i razem dostarczać wartość klientom organizacji.

Często spotykam się, z tym że jest sporo nieporozumień wokoło DevOps. Jest takie podejście, że to jest taki administrator 2.0, taka nowsza wersja administratora IT i serwerów. Tymczasem DevOps, to nie jest rola w takim rozumieniu, ale metodyka, nowe podejście czy też nowa kultura dostarczania oprogramowania. Czy mógłbyś na początku, zdefiniować czym jest DevOps?

DevOps to ruch społeczny o charakterze kulturowym i profesjonalnym, podkreślający komunikację, współpracę i integrację ludzi, procesów i technologii

Fajnie, że zacząłeś od tych nieporozumień odnośnie DevOps, bo często można odnieść takie wrażenie, że jest np. stanowisko DevOps’a w jakiejś organizacji albo mówimy o komórkach DevOpsów, tymczasem rzeczywiście jest to coś więcej. Jest to kultura organizacyjna. Może na początku zacznijmy od tego, skąd wziął się ten termin DevOps. Otóż w roku 2009 na konferencji VeloCity, dwóch panów, John Allspaw i Paul Hammond, którzy wtedy pracowali w Flickr, mieli prezentację “10+ Deploys per Day: Dev and Ops Cooperation at Flickr”. Wtedy po raz pierwszy, pojawił się ten zlepek, obok siebie. Na tej konferencji był również obecny Patrick Debois, został na tyle zainspirowany na tyle tą prezentacją, że następnego roku zorganizował konferencję, która nazywała się DevOpsDays. Mówi się, że od tej konferencji i nazwy DevOps, powstał cały ruch, cała metodyka, która rozwija się do dzisiejszego dnia. Niektórzy twierdzą, że DevOps, nie ma jakiejś konkretnej definicji, natomiast DevOps Institute, definiuje DevOps, jako ruch społeczny o charakterze kulturowym i profesjonalnym, podkreślający komunikację, współpracę, oraz integrację ludzi, procesów i technologii, w całym strumieniu wartości. Automatyzujący proces dostarczania oprogramowania i zmian w infrastrukturze. Ma na celu ustanowienie kultury i środowiska, w którym można budować, testować i wdrażać oprogramowanie szybciej i częściej, bez poświęcania szybkości i niezawodności usług procesowych wspieranych przez IT. Tak brzmi ta definicja, która jest podana przez DevOps Institute. Warto podkreślić, że w tej definicji jest mowa o automatyzacji i pewnym przyspieszeniu, ale podkreślona jest kwestia zbudowania pewnej kultury i odpowiedniego środowiska pracy. To w mojej opinii jest chyba najważniejszy element DevOps, który niestety dość często jest pomijany, tzn. czasami zbudowanie takiego działu powoduje, że mamy kolejny silos w organizacji, który przepycha się i walczy z innymi komórkami organizacyjnymi w IT. DevOps definiuje takie 3 drogi, które zostały po raz pierwszy opisane w książce Projekt Feniks, a potem bardzo ładnie rozwinięte w książce The DevOps Handbook. Pierwsza droga to flow, czyli przepływ pracy, strumieni wartości i tutaj rozumiemy taki przepływ pracy od pomysłu, który pojawi się w obszarze biznesowym, poprzez jego realizację przez deweloperów, następnie poprzez wdrożenie przez operations, a następnie dostarczenie danej wartości do klienta. Chodzi o to, aby ten przepływ był jak najszybszy, jak najsprawniejszy, generujący jak najmniej kosztów i problemów. Druga droga to pętle zwrotne, czyli tzw. feedback, chodzi o to, żeby jak najczęściej i jak najszybciej uzyskiwać informację zwrotną o tym, co dzieje się w naszej strukturze IT, jaki jest odbiór rzeczy, które dostarczamy na produkcję naszych klientów, jak biznes postrzega to, co jest dostarczane itd. Chodzi o to, żeby ten feedback nie odbywał się raz na kwartał czy raz na miesiąc, tylko jeśli to możliwe to nawet każdego dnia. Jeżeli chodzi o infrastrukturę informatyczną, to żebyśmy mieli przez cały czas, na bieżąco mieli informację, w jakim stanie jest ta infrastruktura i czy działa prawidłowo. Trzecia droga polega na stworzeniu generatywnej struktury wysokiego zaufania, która pozwala na dynamiczne podejście do eksperymentowania i podejmowania ryzyka. Te trzy drogi zawierają szereg technik, metod, które można wykorzystywać, są odpowiednie narzędzia, które te drogi wspierają, ale też pewne założenia teoretyczne, które leżą u podstaw. Można powiedzieć też, że DevOps, dzieli zdolności organizacji w takie 5 obszarów tj. ciągłe dostarczanie architektura, produkty i procesy, zarządzanie szczupłe, monitorowanie oraz kultura. Wydaje się, że właśnie w książce “Accelerate” wydanej w roku 2018, zwrócono uwagę na poprawę w tych 5 obszarach.

To co powiedziałeś, bardzo mi się kojarzy z takim podejściem agile’owym do wdrażania programowania. Pamiętam czasy zanim agile stał się modny, wówczas dosyć mocne było rozgraniczenie pomiędzy zespołem developerskim i komórką ludzi, którzy zajmowali się utrzymaniem, administratorów. Zastanawiam się, czy według Ciebie wprowadzenie tylko takiego podejścia agile’owego do developmentu, z pominięciem tego Ops, ma sens? Czy też może powinno się do tego podchodzić w ten sposób, że jeżeli jesteśmy już zwinni to traktujemy te dwie części równolegle i w sposób zwinny staramy się dostarczać oprogramowanie w sposób ciągły, monitorować je, przedkładać ludzi ponad procesy i wszystko to, co agile wniósł nam ze sobą?

To jest dobre pytanie, bo wydaje się, że ta cała rewolucja DevOps, o której sobie teraz rozmawiamy, która miała miejsce w okolicach roku 2009, wzięła się właśnie z tego problemu, że często organizacje w obszarze developmentu, zaczynały działać już zwinnie, coraz lepiej IT współpracowało z biznesem i to dogadywanie było na zdecydowanie lepszym poziomie, biznes był coraz bardziej zaangażowany w ten proces i wszystko było dobrze, do momentu, kiedy trzeba było pójść z tym wszystkim na produkcję. Kiedy trzeba było to wdrożyć i utrzymywać, to w organizacjach panowały dość sztywne reguły, procesy i przebicie się przez to, nie było łatwe. W swojej książce DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji, jest taki ciekawy cytat — “w dekadzie 2000–2010 ze względu na wdrożenie zasad i praktyk Agile czas potrzebny na opracowanie nowych funkcji, skrócił się do tygodni lub miesięcy”, dzisiaj powiedzielibyśmy, że nawet do dni, ale wdrożenie rozwiązań do produkcji wymagało tygodni lub miesięcy, co często miało katastrofalne skutki. To niestety, można zauważyć, bo o ile development jest w stanie dość szybko dostarczyć pewnych zmian, o tyle potem często napotyka się na taki mur w organizacji pod tytułem “kalendarz zmian” i jest informacja, że świetnie, że macie przygotowaną i przetestowaną tę zmianę, ale jej wdrożenie nastąpi dopiero w następnym kwartale, bo tak przewiduje to kalendarz wdrożeń i wtedy mamy okienko, kiedy będziemy wdrażać zmiany w systemach. Tak naprawdę w dzisiejszym świecie, niestety nie można czekać tak długo na wdrażanie zmian, bo biznes wymaga tego, żeby te zmiany były wdrażane jak najszybciej i jak najsprawniej. Mawiało się kiedyś, że duże ryby łowią małe, a dzisiaj często to szybkie ryby zjadają te wolne. Pokazuje to rzeczywiście przykład wielu firm, że ta szybkość wdrażania zmian w systemach informatycznych, decyduje o przewadze konkurencyjnej, dlatego niezbędne było zmienienie nie tylko, tego obszaru dostarczania nowych funkcji, ale również obszaru utrzymania, zarządzania, monitoringu, a także bezpieczeństwa, które w wielu firmach stanowi dużą wartość i DevOps, również o tym wspomina.

Zastanawiam się, czy w związku z tym, zwinne metodyki wdrażania są czymś wymaganym przy metodyce DevOps, czy to jest coś takiego, co musi najpierw być wdrożone albo czego świadomość musi być w firmie nastąpić, zanim wdrożenie DevOps, będzie możliwe? Czy też z Twojego doświadczenia, czy przykładów z biznesu jesteś w stanie powiedzieć, czy DevOps, również do takich projektów typu waterfall się nadaje?

Wydaje się, że pewne korzyści z wdrożenia modelu DevOps w takich tradycyjnych organizacjach też się sprawdzają, aczkolwiek trzeba zauważyć, że jeżeli mamy takie tendencyjne podejście i na samym początku mamy duży obszar do narzucenia pewnych wymagań, następnie tworzymy architekturę do tego, potem dopiero kodujemy, potem testujemy i na koniec mamy gotowy produkt na wdrożenie, który wdrażamy i utrzymujemy, no to w tym modelu niestety tracimy coś bardzo ważnego, czyli ten plan to market, czyli jak najszybsze dostarczenie wartości dla użytkownika końcowego. Z drugiej strony wiele praktyk, które opisuje DevOps, można zastosować również w takim tradycyjnym modelu. Stabilność i bezpieczeństwo środowiska można osiągnąć. Dlatego też, w książce, na którą już się powoływałem, stwierdzono, że metodyka DevOps, może być stosowana zarówno przy zwinnym wytwarzaniu oprogramowania, jak i w takim podejściu tradycyjnym, waterfallowym.

Dzięki wprowadzeniu kultury i technik, które dostarcza nam DevOps jesteśmy w stanie uzyskać efekt, kiedy szybciej dostarczamy zmian w oprogramowaniu

Gdybyś mógł tak podsumować, jakie korzyści z wprowadzenia kultury DevOps, mogą nastąpić w firmie. W różnych częściach firmy, czyli części developerskiej, części utrzymaniowej, części biznesowej. Co każda z tych grup, może uzyskać, jeśli wprowadzimy kulturę DevOps?

Można by stwierdzić, że dzięki wprowadzeniu i kultury i pewnych metod, technik, które dostarcza nam DevOps, jesteśmy w stanie uzyskać efekt, kiedy szybciej dostarczamy zmiany w oprogramowaniu, ale co ważne przy jednoczesnym zachowaniu, wysokiej dostępności, niezawodności oraz bezpieczeństwa. Osiąga się to dzięki, takim różnym, mniejszym krokom, czy elementom składowych tej metodyki tj. zmniejszanie porcji, które są deployowane na środowisko produkcyjne, sprawianie, że dzielimy nasze zmiany na małe części, które są później umieszczane w środowisku produkcyjnym, ale bardzo często. Dzięki temu przyspieszamy ten time to market, te zmiany są szybciej widoczne. Dzięki temu jesteśmy też w stanie poprawić jakość kodu, deploymentu software, zmniejszamy koszty produkcji pojedynczej instalacji, ale przez to też zmniejszamy ryzyko, które wiąże się zawsze ze zmianą w systemie. Dodatkowo DevOps, jest odpowiedzialny za takie zaszczepienie w całej organizacji kultury komunikacji i współpracy, to jest niezwykle ważne. Wspominaliśmy o tym, podczas naszej rozmowy i Scrumie i to jest rzecz, którą DevOps bardzo mocno podkreśla. Możemy dzięki temu szybciej i w bardziej planowy sposób dostarczać pewne zmiany, których wymaga biznes.

Powiedziałeś, że DevOps, to nie tylko takie aspekty techniczne, do których jeszcze wrócimy, ale to też nacisk na współpracę, komunikację między programistami, specjalistami od eksploatacji i wszystkimi tymi, którzy pracują dla sukcesu danego projektu. Po co, według Ciebie uwypukla się tak mocno to pojęcie komunikacji i współpracy? Jakie to ma przełożenie na projekt? Czy nie może to funkcjonować w takim tradycyjnym rozumieniu, gdzie są te silosy, o których powiedzieliśmy i działy, które komunikują się wąskim kanałem, ale pracują wewnątrz? Czy ten model jakoś się nie sprawdza?

Komunikacja jest niezwykle ważna w każdym etapie dostarczania rozwiązań informatycznych. Na to też kładł nacisk manifest agilowy, który został napisany w roku 200. To też wynikało z tego, że developerzy, którzy wtedy pracowali zauważyli ogromny problem w komunikacji z biznesem i też konsekwencje, które z tego wynikają. Książka The DevOps Handbook, zawiera takie ciekawy cytat na samym początku — “wyobraź sobie świat, w którym właściciele produktu, developerzy, inżynierowie walidacji, operacji IT, bezpieczeństwa informacji, współpracują ze sobą nie tylko po to, żeby sobie nawzajem pomóc, ale też po to, by zapewnić sukces całej organizacji”. Brzmi trochę jak sen, jak takie pobożne życzenie, ale wydaje mi się, że rzeczywiście jest to możliwe do osiągnięcia i wiele organizacji pokazuje, że można w tym kierunku iść. Taka współpraca i komunikacja pomiędzy poszczególnymi zespołami i w obrębie zespołów to podstawa filozofii DevOps i druga droga, czyli ten feedback, opiera się na takiej dobrej komunikacji. Zarówno pomiędzy biznesem jaki i IT, ale także pomiędzy poszczególnymi komórkami czy zespołami, które są w obrębie IT. Nie wiem czy zauważyłeś to w organizacjach, w których pracowałeś, ale ja to widziałem, że taki podział na utrzymanie i rozwój doprowadziło do powstania silosów, z których każdy miał swoje oddzielne cele, KPI-aje. Popatrz na przykład jeżeli chodzi o dział rozwoju, to z pewnością, to na czym zależy rozwojowi to to, żeby zmiany były wprowadzane jak najszybciej, z drugiej strony dział utrzymania wie o tym dobrze, że te zmiany, powodują potem najczęściej problemy, skargi użytkowników, niedostępność systemów informatycznych itd. Prawdopodobnie zależałoby im na tym, żeby te zmiany, były wprowadzane do systemów informatycznych jak najrzadziej, aby uzyskać wysoką dostępność i niezawodność środowiska. W końcu, jak zapytamy się biznesu, dla którego to wszystko robimy, czego on chce, czy woli mieć zmiany, które są wprowadzane często i szybko na jego żądanie, czy chce mieć system niezawodny, dostępny i bezpieczny. Oczywiście, powie, że chce jednego i drugiego. Dlatego też, DevOps, łączy te dwa światy i stara się w jak najlepszy sposób, zaspokoić potrzeby biznesu.

Współpraca i komunikacja pomiędzy poszczególnymi zespołami i w obrębie zespołów to podstawa filozofii DevOps

Gdy przeglądam oferty pracy na stanowiska specjalistów, inżynierów DevOps, to pierwsze co tam się rzuca w oczy, kiedy patrzymy na takie umiejętności twarde, to jest znajomość Chmury. Żyjemy obecnie w czasach, kiedy to jest już dosyć powszechne i coraz mniej firm posiada takie urządzenia fizyczne, gdzieś w piwnicy. Coraz więcej tych usług jest przenoszonych do Chmury. Czy według Ciebie jej znajomość, to jest taki obowiązek, jeśli chodzi o umiejętności inżyniera DevOps, taki powiedziałbym wymóg, który jest minimalny dla tej roli?

Zdecydowanie. Jak słusznie zauważyłeś dzisiaj rzeczywiście, coraz więcej organizacji przenosi swoją infrastrukturę z takich tradycyjnych serwerowni do rozwiązań chmury publicznej. Nie mówiąc już o nowych firmach, o startupach, które zwykle bazują na tego typu rozwiązaniach i jest to bardzo rozsądne podejście, bo mimo wszystko zakupienie pewnej mocy obliczeniowej w takiej chmurze publicznej, jest o wiele tańsze niż wybudowanie własnej serwerowni, zapewnienie tam wszystkich potrzebnych dostępów, zasilania, internetu itd. W związku z tym wydaje mi się, że znajomość przynajmniej dwóch z trzech, takich podstawowych rozwiązań chmurowych, czyli AWUs, Google Cloud, czy Azura, to jest must have, w tej chwili dla osób, które chcą się zajmować tym obszarem DevOps, nazwijmy ich DevOps inżynierami, myślę, że to jest dobre określenie, bo wiemy, że DevOps, to nie stanowisko, ale DevOps inżynier, to już może być określenie stanowiska. Dzięki korzystaniu z Chmury, wiele takich rozwiązań typu Docker, Kubernetes, Continuous Integration, Continuous Delivery jest dostępnych i możemy z tych narzędzi korzystać, dlatego na pewno warto zainteresować się przynajmniej jednym lub dwoma rozwiązaniami. Myślę, że AWS w tej chwili jest takim najpopularniejszym, ale z pewnością Azure, powoli go goni, jeżeli chodzi o udostępniane funkcje i też coraz więcej klientów korzysta z tego rozwiązania, podobnie jak z Google Clouda.

Skoro już jesteśmy przy takich twardych kompetencjach, to DevOps również kojarzy mi się z częstym wdrażaniem aplikacji, również jej rozległe monitorowanie, po to, żeby zapewnić tę wysoką dostępność. Czy mógłbyś powiedzieć, czym są takie pojęcia, o których przed chwilą wspomniałeś, czyli Continuous Integration, Continuous Delivery, Continuous Monitoring i Continuous Deployment?

To oczywiście bardzo szeroki temat i również nie jestem specjalistą, żeby się, w tym obszarze wypowiadać jakoś bardzo szeroko. Najkrócej rzecz ujmując Continuous Integration, to jest istotna praktyka developerska, która polega na tym, że kod, który jest tworzony przynajmniej raz dziennie, jest mergowany do wspólnego repozytorium kodu, podczas takiego mergowania odbywają się oczywiście automatyczne testy, zbudowanie takiej aplikacji. Dzięki temu osiągamy to, że możemy na koniec dnia, mieć wszystkie zmiany, które zostały wdrożone przez różnych developerów. Mamy to wszystko po prostu w jednym miejscu. Continuous Delivery, czyli ciągłe dostarczanie, czyli praktyka, która pozwala na uzyskanie deploymowanego stanu aplikacji. W każdym momencie tę aplikację możemy umieścić na produkcji. Trzecia rzecz, czyli Continuous Deployment, jest to monitoryzacja tego ostatniego kroku. O ile w Continuous Delivery aplikacja może być umieszczona na produkcji, przy czym samo umieszczenie jest czynnością ręczną, o tyle w Continuous Deployment, jest także zautomatyzowana. Taka aplikacja, automatycznie trafia na środowisko produkcyjne, ma to oczywiście swoje zalety, bo dzięki temu unikamy ręcznych akceptacji i kroków, które są do wykonania, może mieć też swoje wady, ponieważ wtedy tracimy kontrolę nad tym, kiedy taka zmiana zostaje na produkcji umiejscowiona. Dlatego niektóre organizacje decydują się na takie podejście Continuous Deployment, inne poprzestają tylko na Continuous Delivery, a sam moment umieszczenia aplikacji jest już wyzwalane ręcznie przez jakąś osobę w organizacji IT, która ma do tego uprawnienia. Pytałeś jeszcze o Continuous Monitoring i to jest też rzecz, która jest związana z drugą drogą, czyli tym feedbackiem, chodzi o to, żeby nasze systemy informatyczne, były w sposób ciągły monitorowane i żeby na bieżąco zbierać informację o tym, w jaki sposób te systemy działają. DevOps tak naprawdę zaleca, żeby monitorować i mierzyć dosłownie wszystko, co się da. Dzięki temu jesteśmy w stanie stworzyć bogatą bazę dotyczącą tego, w jaki sposób aplikacja zachowywała się na przestrzeni ostatnich tygodni, miesięcy, czy nawet lat i wychwytywać wszelkiego rodzaju anomalie, które pokazują, że coś w tej aplikacji, nie działa w sposób właściwy. Jeżeli mamy wiedzę o tym, że ilość klientów w naszej aplikacji jest duża i każdego dnia między godziną 8 a 10, a potem między 16 a 18 i któregoś dnia widzimy, że to zachowanie użytkowników jest inne niż zwykle, to być może coś nie tak jest z aplikacją. Być może jakiś jej moduł jest niedostępny albo proces zakupu nie może być dokończony. Jest to sygnał do tego, żeby sprawdzić, czy wszystko z tym systemem jest w porządku.

To, co łączy te wszystkie pojęcia, to jest ten pierwszy człon nazwy, czyli Continuous, czyli ciągłość. Żeby taką ciągłość zapewnić, musimy myśleć oczywiście o jakości i osiąga się to w różny sposób, np. przez jakieś automatyczne testy regresji, albo tak jak to robi Netflix, symulowanie awarii na produkcji. Tutaj wchodzimy w obszar QA. Mam wobec tego pytanie, czy podejście DevOps, to jest takie multidyscyplinarne działanie związane z dostarczeniem oprogramowania? Poruszyliśmy kilka różnych ról, które mogą być wpisane w taką filozofię DevOps, QA, utrzymanie stabilności strony. To, co mi przychodzi na myśl, to to, że poruszamy wiele różnych aspektów, wiele różnych dyscyplin i zastanawiam się, czy ten DevOps to nie jest coś szerszego, czy to nie jest taka multidyscyplinarna działalność dotycząca tego, jak dostarczyć oprogramowanie. Co Ty o tym myślisz?

Zdecydowanie tak. Nawet ten cytat, który pozwoliłem sobie tutaj przytoczyć, o współpracy różnych osób czy działów, zwraca uwagę na takie role jak właściciel produktu, developer, ale też inżynierowie walidacji, czyli ten obszar QA, potem operacje IT i bezpieczeństwo. Jak najbardziej DevOps, w szeroki sposób podchodzi do kwestii, wytwarzania oprogramowania, jego późniejszego utrzymania i wszystkich elementów, które są z tym związane. Bardzo istotną rolę odgrywają też testerzy. Tutaj jedna ważna uwaga, jeśli mówimy o automatyzacji, o Continuous Integration, Continuous Delivery, to mamy świadomość, że coraz większy nacisk, będzie kładziony na automatyzację. Oczywiście są pewne obszary aplikacji, które prawdopodobnie zawsze, będą musiały być przetestowane w sposób manualny, ręczny. Takich testów nie unikniemy, aczkolwiek trend jest taki, żeby tych testów automatycznych było jak najwięcej, żeby one pokrywały jak największą część aplikacji.

Wiele razy powiedziałeś o automatyzacji, to bardzo ważny aspekt DevOps. Co chcemy automatyzować i dlaczego tak nam zależy na tym?

Automatyzować chcemy wszystko. Im więcej rzeczy zautomatyzujemy, tym mniejsze jest prawdopodobieństwo popełnienia błędu. Prawda jest taka, że większość problemów, które były w środowiskach informatycznych wyniknęły z tego, że ktoś popełnił jakiś ludzi błąd, np. jest jakaś ilość skryptów, które trzeba uruchomić w odpowiedniej kolejności i ktoś albo pomylił tę kolejność, albo zapomniał, któregoś skryptu. Jeżeli ten obszar zautomatyzujemy, to znaczy napiszemy taki program, który wykona nam te skrypty w poprawnej kolejności, to wtedy unikamy tych błędów ludzkich, które mogą wystąpić. Oczywiście automatyzację, trzeba wprowadzać z głową, w każdej organizacji jest takie powiedzenie, że jeżeli mamy w jakiejś części bałagan i zaczniemy tam wprowadzać automatyzację, to efekcie otrzymamy tylko automatyczny bałagan i nic więcej. Na początku, na pewno trzeba pewne obszary uporządkować, przejrzeć, postarać się wyszczuplić pewne procesy, a dopiero potem wprowadzać automatyzację, a nie na odwrót. Natomiast rzeczywiście, dzięki takiej dobrej automatyzacji możemy uzyskać na pewno przyspieszenie pewnych działań, a po drugie większą niezawodność tych wszystkich działań. Jeżeli mamy naprawdę dobrze napisany skrypt, który podnosi nam całość środowiska i jeśli nastąpi jakaś awaria, to odtworzenie tych środowisk zajmuje nam bardziej minuty i godziny, niż dni i tygodnie, jak to było w poprzednich czasach, kiedy trzeba było ręcznie te systemy odtwarzać, przenosić itd.

Jeśli ktoś chciałby zostać tym DevOps inżynierem, to jakie umiejętności musi posiąść, bardziej myślę o takich umiejętnościach twardych, żeby móc szukać pracy jako DevOps inżynier.

Wspominaliśmy już o tym, że znajomość Chmury, to jest takie must have, takiej osoby, naprawdę to są bardzo poszukiwane umiejętności, jak działania w AWS, Azure albo Google Cloud. Oczywiście, mamy na uwadze to, że to są bardzo rozbudowane systemy, myślę, że mało kto jest zdolny być specjalistą, we wszystkich funkcjach, które udostępnia np. AWS, bo są ich setki. Zauważa się, że następuje w tej chwili pewna specjalizacja w wąskich dziedzinach, jeśli chodzi o rzeczy, które są np. na AWSie, do zrobienia. Natomiast z pewnością, taka osoba, która chciałaby się tym zajmować, powinna posiadać jakąś ogólną wiedzę o środowiskach chmury publicznej i głębszą w tych obszarach, które dotyczą zarządzania samą infrastrukturą IT. Bardzo przydatna jest też znajomość wszelkich narzędzi typu Continuous Integration, Continuous Delivery, Continuous Deployment oraz narzędzi do monitorowania. Jest tego całkiem sporo i też wydaje się, że na dzień dzisiejszy trudno być specjalistą, we wszystkich tych narzędziach, ale trzeba po prostu zobaczyć, które z nich są aktualnie najczęściej pożądane przez pracodawców, najczęściej wykorzystywane przez kolegów po fachu. Być może dobrym kierunkiem jest np. nauczenie się przynajmniej dwóch jakichś narzędzi, z pewnością znajomość wszelkich repozytoriów opartych o Gita. Wszelkie rzeczy związane z kontenerami, narzędzia, które umożliwiają nam testowanie i sprawdzanie, czy te środowiska są dostępne, czy został spełniony losowy sposób zabijania podów i patrzymy, czy są one w stanie automatycznie podnieść się i wrócić do życia. Upewniamy się, czy cała struktura, na której stoi nasza organizacja, rzeczywiście jest dostępna dla użytkowników końcowych, bo to jest najważniejsze.

Na początku, kiedy Cię przedstawiałem, wspomniałem, że uczestniczyłeś w kilku dużych transformacjach IT. Jak się wdraża taką kulturę DevOps, w firmie? Czy to jest też, coś, w czym brałeś udział? Zastanawiam się, czy to się robi w etapach, czy to po prostu jest proces, który musi nastąpić z przysłowiowego wtorku na środę? Czy kiedykolwiek można uznać, że jesteśmy już za tym procesem i mamy go z głowy?

Z przykrością muszę stwierdzić, że te transformacje, w których brałem udział, akurat nie przybliżały organizacji do tego modelu DevOps. Natomiast w mojej ocenie, adaptowanie w organizacji kultury DevOps, ma proces ciągły. To na pewno nie jest coś, co ma nastąpić z wtorku na środę. To jest proces, który będzie zajmował miesiące i lata, a nie dni i tygodnie. Trudno też mówić, kiedy nastąpi taki konkretny moment zakończenia tej transformacji. Na pewno można w pewnym momencie uznać, że udaje nam się zaimplementować wiele pozytywnych zmian, które stwierdzają, że możemy powiedzieć, że jesteśmy organizacją działającą zgodnie z praktykami DevOps, tym niemniej, będzie na pewno dużo różnych obszarów, w których można coś usprawnić, polepszyć. Sama technologia IT, cały czas idzie do przodu, więc na pewno pojawią się nowe narzędzia, nowe rozwiązania, które trzeba będzie w naszej organizacji wykorzystać i zaimplementować. Ta droga nigdy się nie skończy, zawsze będzie mogła być kontynuowana. Powiedzieliśmy też, że DevOps, to tak naprawdę pewna kultura organizacyjna i tutaj też jest na pewno wiele do zrobienia. Zarówno w transformowaniu myślenia pracowników, jak i w szkoleniu tych pracowników, którzy przychodzą, którzy są nowi, oni też muszą tę kulturę poznać, muszą się z nią identyfikować i zgodnie z nią działać. Podsumowując, jest to na pewno proces, który trwa długie tygodnie, miesiące, może nawet lata, gdzie stopniowo poszczególne obszary należy implementować, patrzyć co możemy zrobić, żeby je usprawnić.

Czytaj dalej na: https://porozmawiajmyoit.pl/poit-050-devops/

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

More From Medium

More on Podcast from kkempin’s dev blog

More on Podcast from kkempin’s dev blog

Druk 3D

More on Podcast from kkempin’s dev blog

More on Programista from kkempin’s dev blog

More on Programista from kkempin’s dev blog

Specjalista IT zostaje managerem

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade