POIT #259: Jak pracuje DevOps: Ludzie, metodologia i sukces biznesowy

Witam w dwieście pięćdziesiątym dziewiątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to jak pracuje DevOps.

Dziś moim gościem jest Jacek Marmuszewski – DevSecOps z ponad dziesięcioletnim doświadczeniem w budowaniu i zarządzaniu infrastrukturą chmurową. Pracował przy systemach krytycznych dla takich firm jak Sabre i Oracle. Miał również swój udział w startupach, gdzie jako jeden z pierwszych inżynierów wspierał kulturę DevOps i promował architekturę opartą na chmurze. Współzałożyciel Let’s Go DevOps, gdzie pomaga innym w projektowaniu, budowaniu, utrzymaniu aplikacji i infrastruktury opartych na chmurze. Jest gorącym zwolennikiem transformacji chmurowej i pomaga innym wykorzystać jej pełen potencjał, dobierając odpowiednie komponenty do danej pracy.

W tym odcinku o DevOps rozmawiamy w następujących kontekstach:

  • czym jest DevOps?
  • kim jest DevOps engineer? Jaką rolę sprawuje i za co odpowiada?
  • jakie są oczekiwania od takiej roli?
  • jak na codzień przebiega współpraca z działem DevOps?
  • czy umiejętności miękkie są mocną stroną DevOps engineer’a?
  • czy podejściu DevOps czegoś brakuje?
  • jaki jest najczęstszy background zawodowy osób, które zajmują się DevOps?
  • jak AI wpływa na DevOps?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 259. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o tym, jak pracuje DevOps. Wszystko, co potrzebujesz, notatka, linki, transkrypcja, czekają na Ciebie na porozmawiajmyoit.pl/259.

Myślisz o zmianie pracy lub przebranżowieniu się do IT? Zajrzyj na SolidJobs, gdzie znajdziesz przejrzyste oferty z informacją co do zarobków, technologii i projektów. 

Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka Osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz lub podzielanie się tym odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka.

Odpalamy!

 

Cześć! 

Mój dzisiejszy gość to DevSecOps z ponad 10-letnim doświadczeniem w budowaniu i zarządzaniu infrastrukturą chmurową. Pracował przy systemach krytycznych dla takich firm jak Sabre i Oracle, miał również swój udział w startupach, gdzie jako jeden z pierwszych inżynierów wspierał kulturę DevOps i promował architekturę opartą na chmurze. Współzałożyciel Let’s Go DevOps, gdzie pomaga innym w projektowaniu, budowaniu, utrzymaniu aplikacji i infrastruktury opartej na chmurze. Jest gorącym zwolennikiem transformacji chmurowej i pomaga innym wykorzystać jej pełen potencjał, dobierając odpowiednie komponenty do danej pracy. Moim i Waszym gościem jest Jacek Marmuszewski. 

Cześć, Jacku, bardzo miło mi gościcie w podcaście. 

 

Mnie również miło Cię słyszeć dzisiaj. 

 

Dzisiaj z Jackiem będziemy rozmawiać o DevOps, ale nie przez perspektywę technologii, frameworków i bibliotek, ale raczej z perspektywy tego, jak wygląda praca, albo jak może wyglądać praca z ludźmi, od strony troszkę metodologicznej pewnie o tym wszystkim opowiemy i o tych aspektach, które na koniec dnia dzięki temu podejściu DevOps przekładają się na sukces biznesowy. 

Myślę, że brzmi to bardzo ciekawie i myślę sobie, że to będzie kolejny taki podcast dotyczący DevOps, który nam uzupełnia tutaj ten obraz całej tej panoramy DevOps. Było już troszkę wcześniej o różnych aspektach technologicznych, dzisiaj takie dopełnienie całościowe, mam wrażenie, tego tematu będzie, tak że cieszę się, Jacku, na naszą rozmowę. 

Zanim jednak do tego przejdę, to chciałbym Cię standardowo zapytać każdego mojego gościa, czy słuchasz podcastów i być może jakieś ciekawe audycje będziesz w stanie zarekomendować. 

 

Ja Ci powiem szczerze, że jestem bardziej osobą, która szuka takich ciekawych, hardkorowych nagrań konferencyjnych o już takich naprawdę złożonych problemach i podcasty u mnie wchodzą raczej jako taki element odskoczni. W związku z tym mam z takich ulubionych podcastów The One Show, to jest troszeczkę newsów z rynku generalnie technologicznego. Zdarza mi się czasami słuchać 7 metrów pod ziemią, ewentualnie Radiowców bez cenzury, tak że to już taka raczej beletrystyka niż techniczne podcasty. 

 

Czyli bardziej rozrywka. Super, do tego podcasty też się jak najbardziej nadają. Dobrze, chciałbym Cię zapytać na początku o rzecz podstawową i o to oczywiście można się kłócić, pewnie nawet święte wojny gdzieś na ten temat się dzieją, mianowicie jak Ty właściwie definiujesz pojęcie DevOps? 

Rozmawiałem już w ramach tego podcastu oczywiście również poza z wieloma osobami, które z DevOps w jakiś sposób mają do czynienia albo też mówią same o sobie, że są DevOps inżynierami i mam wrażenie, że co osoba, co firma to trochę inne podejście, trochę inna definicja właśnie DevOps, więc jestem ciekawy Twojej definicji. 

 

Tutaj pełna zgoda, nawet słuchałem części Twoich podcastów właśnie z tymi inżynierami, którzy zajmują się infrastrukturą, i tak, zatrudnia się ludzi, którym daje się etykietkę DevOps Engineer, natomiast prawda jest taka, że to powstawało jako pewna kultura organizacji i to kultura, która ma być oparta o dużą transparentność, dużą komunikację między sobą i takie zespoły, które mają mocno zmiksowane kompetencje. 

Ja pamiętam jeszcze takie czasy, gdzie pracowałem w dużych korporacjach, gdzie teraz wydaje mi się to kompletnie nierealne, natomiast były zespoły developerskie, które nie miały zielonego pojęcia o tym, co się dzieje na produkcji. Ich zadaniem było dojść do momentu, kiedy kod można przekazać zespołowi testerskiemu, potem zespołowi operacyjnemu. Zespół operacyjny nie wiedział, co za paczkę dostaje, po prostu miał ją uruchamiać gdzieś tam na produkcji. Co więcej, miałem jedną taką firmę, w której jeszcze był dodatkowy zespół developerski, który zajmował się naprawą bugów produkcyjnych. Więc ten pierwszy zespół, który robił feature’y, nawet nie miał tego feedbacku odnośnie do tego, że coś nie działa, coś jest niewydajne, coś klientowi po prostu nie zadziałało. 

Tu mi się wydaje, że wtedy wpadła ta kultura DevOpsowa. Oczywiście zaczęto zatrudniać inżynierów głównie cloudowych, bo to jest, mam wrażenie, ze sobą mocno połączone i fajnie się robi kulturę DevOpsową dynamiczną w świecie, gdzie możemy dynamicznie stawiać infrastrukturę itd. 

Natomiast DevOps ja traktuję jako kulturę organizacji, właśnie w której my, którzy się zajmujemy głównie infrastrukturą, mamy też wiedzę o tym, jak budować aplikacje, potrafimy przeczytać kod aplikacyjny, potrafimy ją strableshootować, udzielamy się w dyskusjach dotyczących architektury pewnych rozwiązań, doradzamy, jakie bloczki infrastrukturalne, cloudowe wykorzystać, żeby łatwiej się aplikacje budowało. I w drugą stronę developerzy wiedzą mniej więcej, jak ta infrastruktura działa, jakie ma ograniczenia, co fajnie jest zrobić, żeby aplikacje im się po prostu łatwiej budowały. 

Więc dla mnie samo podejście DevOpsowe jest to przede wszystkim podejście do pewnej kultury. Natomiast to, że wpisujemy się też często w umowach i na LinkedInie jako DevOps inżynierowie, to w sumie troszeczkę tak wyszło, że wszyscy po prostu mówią na ten jeden wielki worek ludzi o różnych kompetencjach chmurowo-infrastrukturalnych jako inżynierów DevOps. 

Natomiast DevOps ja traktuję jako kulturę organizacji, właśnie w której my, którzy się zajmujemy głównie infrastrukturą, mamy też wiedzę o tym, jak budować aplikacje, potrafimy przeczytać kod aplikacyjny, potrafimy ją strableshootować, udzielamy się w dyskusjach dotyczących architektury pewnych rozwiązań, doradzamy, jakie bloczki infrastrukturalne, cloudowe wykorzystać, żeby łatwiej się aplikacje budowało. I w drugą stronę developerzy wiedzą mniej więcej, jak ta infrastruktura działa, jakie ma ograniczenia, co fajnie jest zrobić, żeby aplikacje im się po prostu łatwiej budowały. 

 

To może pociągnijmy właśnie ten temat DevOps inżyniera. To jest bardzo ciekawa rzecz. Jako coś, jako ktoś, jako rola, stanowisko, które nie tylko funkcjonuje właśnie na rynku pracy, jako coś, co funkcjonuje w ofertach, ogłoszeniach o pracę, ale też jako osoba, która wykonuje realną pracę. 

Myślę sobie, że to, o czym powiedziałeś jako właśnie definicję DevOps trzeba później jakoś wdrożyć na tę przysłowiową produkcję, czyli jakoś w tych zespołach, w których pracujemy na co dzień po prostu zastosować te wszystkie założenia i z całą pewnością, że właśnie posiadanie w swoim zespole kogoś takiego jak DevOps Engineer jest jakąś tam formą przybliżenia się do stosowania, aplikowania tej kultury DevOpsowej. Z Twojego doświadczenia, z Twojej praktyki, jaka to jest rola i za co odpowiada?

 

I tu chyba najlepsza odpowiedź będzie: to zależy. I nawiążę do takiej anegdotki, gdzieś tam mam taką znajomą, która się zajmowała rekrutacją swego czasu. Jak pierwszy raz dostała zagadnienie zwerbowania DevOpsa do firmy, to wróciła do mnie z pytaniem, powiedziała: dostałam ofertę, ale wydaje się, jakby oni szukali trzech różnych osób tylko w jednej. 

I troszeczkę tak to niestety wygląda w firmach, że mamy bardzo szeroki zakres obowiązków, i próbujemy znaleźć najlepiej pojedynczą osobę, która jest w stanie je realizować. I trochę też tak wygląda nasze portfolio, akurat jesteśmy jako firma, przez co mamy troszeczkę więcej elastyczności, natomiast co klient tak naprawdę to jest inne oczekiwanie tego, co będziemy robić.

W niektórych firmach mocno skupiamy się chociażby na warstwie bazodanowej, troubleshootingu baz danych, optymalizacji rzeczy związanych z bazami danych, w innych zajmujemy się może poniekąd zbliżonym tematem, ale Elasticsearche, i tutaj firmy chcą, żeby pomagać im z troubleshootingiem, z optymalizacją, performancem itd. W innych firmach zarządzamy stricte infrastrukturą cloudową. Gdzieś indziej jeszcze to jest bardziej forma consultingu, która mówi, z jakich bloczków poskładać pewne elementy albo jak zbudować pewne systemy, żeby one się dobrze rozkładały między jednym, dwoma cloudami, ewentualnie żeby wykorzystywały już te bloki, które możemy wykorzystać cloudowo jako usługi. 

Więc ciężko jest powiedzieć, jaki jest spektrum tego, natomiast to, na co my przede wszystkim stawiamy, to mamy głównie inżynierów chmurowych, i tu w sumie pewnie nawiążemy trochę do podcastu o platform engineering, że to jest to, czym się teraz większość tych „DevOpsów” zajmuje, czyli poszliśmy w stronę budowania platform dla firm i budujemy fajne narzędzia do tego, żeby developerom było łatwiej korzystać ze złożonych systemów infrastrukturalnych. 

I to jest jakby jedna część, czyli wiedza chmurowa. Natomiast wymagamy od wszystkich, którzy u nas pracują tego, żeby potrafili pisać przynajmniej w jednym języku, najlepiej w Golangu, stąd też nasza nazwa i Go wielką literą użyte w Let’s Go DevOps. Więc wymagamy, żeby umieli pisać w jednym języku, umieli czytać kod, który developerzy dostarczają. Tutaj język już nie jest aż tak istotny, bo w miarę rozumiemy, co tam się dzieje. I też mocno kładziemy nacisk na umiejętności miękkie, bo naszym obowiązkiem troszeczkę jest to, żeby wychodzić poza tą bańkę tylko i wyłącznie zarządzania infrastrukturą, budować relacje z zespołami, z developerami, pomagać im tak naprawdę przechodzić tę ścieżkę tworzenia infrastruktury i aplikacji, która jest cloud native. 

 

Rozumiem. No właśnie, później świadczycie tego typu usługi dla Waszych klientów. Natomiast gdybyś spojrzał na firmy, które do siebie zatrudniają tego typu role, tego typu osoby, to jakiego typu oczekiwania mają w stosunku do tej roli? Po co właściwie zatrudniają DevOpsów? 

 

W naszym przypadku głównie firmy chcą kompletnie zoutsourcować zarządzanie infrastrukturą. W związku z tym my staramy się też podchodzić do tego kompleksowo, czyli to nie jest taka tickeciarnia, gdzie się dostaje zadanie już jasno zdefiniowane, tylko staramy się uczestniczyć w całej tej procedurze budowania aplikacji, przez cały cykl życia aplikacji przechodzić. I to jest jakby to, gdzie my szukamy klientów i gdzie my staramy się w sumie nawet nie jako klient to traktować, tylko raczej jako partner, bo to są długoterminowe relacje. Często znamy się ze wszystkimi w firmie i znamy aplikację, znamy biznes często od podszewki i potrafimy gdzieś tam go wspomagać pod kątem infrastruktury. 

Natomiast to, co często widzimy, to są firmy, które budują bardzo mocne zespoły nazywane DevOpsowymi, natomiast to są zespoły stricte infrastrukturalne. Dochodzi do takiej często patologicznej sytuacji, że zespół infrastrukturalny blokuje bardzo dużo pracy. Zresztą my też to widzimy, że często ilość zagadnień, które mamy jest taka, że potrafimy troszeczkę przyblokować pipeline dostarczania. To się niestety zdarza. Natomiast są dwa sposoby radzenia sobie z tym. 

Jedno to jest właśnie bycie otwartym, przekazywanie coraz więcej wysokopoziomowych zabawek developerom, żeby oni byli w stanie sami zrobić jak najwięcej rzeczy. To jest to, w co my idziemy, czyli budowanie jakiejś tam platformy pod developerów. 

Natomiast drugi scenariusz, który obserwujemy, to jest to, że przychodzi silny, charyzmatyczny menadżer zespołu DevOpsowego, okopuje go dookoła, buduje taki wielki silos i mówi: Od tego momentu to jest nasza odpowiedzialność. I my stajemy się zespołem, z którym ciężko się rozmawia. I to też jest takie miejsce, gdzie my się pojawiamy po to, żeby troszeczkę te ściany rozbić. Natomiast myślę, że firmy jak myślą o rekrutacji DevOpsów, to liczą na to, żeby tę komunikację przede wszystkim i kulturę zacząć szerzyć, czyli szkolenia, rozmowy, tego typu rzeczy też muszą być w ramach tej pracy DevOpsowej. Często natomiast wychodzi, że to są po prostu Infrastructure Engineerowie, którzy często siedzą zamknięci w swoim silosie i nie zawsze są chętni nawet do tego, żeby wychodzić poza niego. 

 

W teorii tej filozofii, tego podejścia, o którym tutaj mówimy, jest to, żeby zbliżać do siebie różne osoby, różne role odpowiedzialne za wytworzenie aplikacji, software’u i wdrożenie, później utrzymanie, bezpieczeństwo, jakość tych elementów, klocków jest całkiem dużo. Natomiast w praktyce niekiedy jest tak, jak teraz powiedziałeś, że tworzy de facto osobny silos, jak ja to nazywam, taki administrator 2.0, osoba odpowiedzialna za infrastrukturę, która jest swego rodzaju może blokadą, może jakimś zwolnieniem, niekoniecznie natomiast realizuje to, co ta filozofia DevOpsowa gdzieś tam mówi. 

Chciałbym Cię zapytać, jak na co dzień wygląda współpraca właśnie z takimi działami DevOps, czy to się bardzo różni od tego, jak miało wyglądać w teorii? 

 

Tutaj zawsze jest pytanie, jak to miało w teorii wyglądać, bo wszystko ładnie na papierze wygląda i to, że spędzamy dużo czasu z zespołami developerskimi, fajnie wygląda na papierze, natomiast w praktyce okazuje się, że na robotę z kolei infrastrukturalną, platformową tego czasu nie ma. 

Jest nawet taki fajny artykuł pokazujący, jak te zespoły DevOpsowe rozrzucają się po firmie, że czasami to jest podejście, w którym jest DevOps przypisany do zespołu, czasami DevOps do organizacji, czasami jest platform team, więc ciężko tutaj też znaleźć taki idealny twór, ponieważ było to w sumie opisane na tak wysokim poziomie, że nie wiadomo, co z tym dalej zrobić. 

Natomiast w naszej pracy widzimy przede wszystkim, że mamy bardzo dużo takich ad hocowych rzeczy, które wpadają. Developerzy, którzy potrzebują pomocy, wytłumaczenia czegoś, konsultacji. Może to trochę nieładnie brzmi, bo to raczej chodzi o to, żeby z nimi siąść i porozmawiać i znaleźć fajne rozwiązanie całego problemu. To nie jest tak do końca konsultacja, jak myślimy stricte akademicko. Mówimy o rozmowie, o tym, żeby zrozumieć, czego druga strona od infrastruktury oczekuje i doradzić albo zbudować dla niej albo z nią elementy stricte infrastrukturalne. Myślę, że to jest core tej pracy, czyli te relacje, które nawiązujemy z ludźmi w różnych momentach. 

Jest też kwestia myślenia o nich i dawania im pewnych klocków takiej warstwy abstrakcji, żeby np. pogodzić wymagania zespołu security, który zawsze w każdej firmie traktowany jest jako ten, który mówi nie i blokuje wszystko. Natomiast tak nie musi być. Po to mamy narzędzia typu chociażby Terraform, żeby budować już gotowe moduły infrastrukturalne, które zawierają wszystkie rekomendacje zespołów security. 

Jeżeli ja fajnie zrobię ten moduł, jeżeli zrobię fajną abstrakcję, dam go developerowi, który rozumie, dlaczego jest ten moduł, jak go użyć, to on go użyje w sposób, który sprawi, że od razu będzie in line z tym, co mówi zespół security. Więc to staramy się robić, czyli budować im taką platformę, takie klocki, które są przyjazne dla developerów, a zawierają wszystkie te nieprzyjazne rzeczy, które na ogół pojawiają się w firmie pod kątem operacyjnym, pod kątem security i pomagać budować takie większe elementy, skąd potem developer sam może sobie poustawiać swoją infrastrukturę. więc jakby to jest taki nasz endgame w większości firm. 

 

Pamiętam jeszcze jakiś czas temu taki duży hype albo dużą potrzebę na zatrudnianie właśnie DevOps Inżynierów, kiedy ekstremalnie trudno było znaleźć kogoś kompetentnego w tym temacie. Wtedy mam wrażenie, że doszło do czegoś takiego jak de facto poszukiwanie specjalistów od chmury, specjalistów, którzy by właśnie te kompetencje jakieś chmurowe posiadali. Ale kryło się za tym coś takiego, że szukaliśmy inżynierów, osób o twardych umiejętnościach, osób, które znają się właśnie na być może jednej chmurze, być może na wielu, ale trochę zaniedbywaliśmy w tym zakresie w procesie rekrutacji umiejętności miękkie, które no właśnie mam wrażenie, że są jednymi z kluczowych w przypadku DevOps Inżynierów, no bo tutaj jednak jakby nie było, chodzi o to, żeby się komunikować z tymi różnymi działami i usprawniać całość procesu. 

Więc taka taka teoria, którą gdzieś tam mam, jestem ciekawy co Ty o tym myślisz, mówi o tym, że firmy bardzo często chcąc zatrudniać właśnie specjalistów od chmury de facto, z takimi twardymi umiejętnościami inżynierów, wstawiały gdzieś w ogłoszenia być może ten magiczny frazes DevOps Inżynier, chcąc przyciągnąć większą ilość osób, ale na koniec dnia otrzymywały kandydatów, którzy właśnie być może nie domagali, że tak to kolokwialnie nazwę, pod kątem umiejętności miękkich. Czy tak mogło być? Jak ty o tym myślisz? 

 

Jest taki stary dowcip, że nie po to poszedłem na studia informatyczne, żeby teraz rozmawiać z ludźmi. I paradoksalnie to jest niestety domena tych ludzi, którzy mają bardzo mocny kręgosłup techniczny, że nie wszyscy są otwarci na to, żeby te umiejętności miękkie rozwijać. I to jest pewne wyzwanie. 

To, co mówisz odnośnie do zatrudniania specjalistów od infrastruktury chmurowej, ja tutaj bardzo mocno łączę ze sobą ten ruch DevOpsowy z infrastrukturą chmurową, bo ciężko jest robić taki prawdziwy DevOps w korporacji, bo jeżeli na serwer potrzebujemy czekać 6 miesięcy, bo go trzeba zamówić, on musi przyjechać, ktoś go musi wstawić z naszej serwerowni, musimy go spiąć niskopoziomowo i dopiero możemy mówić o tym, że dajemy jakąś warstwę abstrakcji nad tym, to tutaj jasne, da się robić pewne elementy kultury DevOps, natomiast dużo łatwiej jest ją robić w cloudzie. 

I teraz wszystkie małe firmy, które zaczynały dopiero, szukały przede wszystkim inżynierów chmurowych, właśnie licząc na to, że tę kulturę DevOps będą promować. Natomiast to też obserwujemy często w firmach, które dopiero wystartowały, że ilość pracy przy samej infrastrukturze na starcie jest tak duża, że przestajemy trochę zwracać w ogóle uwagę na te umiejętności miękkie. My po prostu wiemy, że od zera do releasu produktu mamy 6 miesięcy, 12 miesięcy, czasami nawet mniej. Natomiast mamy dosłownie kilka miesięcy, tej pracy jest naprawdę dużo i wszyscy zasuwają przy budowaniu infrastruktury. 

I wtedy bardzo łatwo jest pominąć to, że osoba, którą zatrudniam, nie ma umiejętności miękkich, skupia się tylko na tym hardcore’owym, technicznym podejściu, co wcale nie jest złe. Natomiast jak już mówimy o byciu DevOpsem, to to jest coś, na co my zwracamy bardzo uwagę, że wszystkie osoby w zespole muszą się udzielać, że to nie ma być dyskusja między menadżerem zespołu, a resztą świata, tylko to ma być zespół DevOpsowy, który mówi o pewnych swoich oczekiwaniach, pyta o pewne rzeczy, bierze udział w dyskusjach, produkuje jakieś materiały typu dokumentacje, tutoriale, szkolenia i jakby ta kultura ma być otwarta od strony tej infrastrukturalnej w górę. 

I to często drive’uje potem developerów też w drugą stronę, że oni są coraz ciekawsi, robią jakieś szkolenia cloudowe, chcą z nami rozmawiać o pewnych aspektach i z tego można naprawdę fajne rzeczy potem wyciągnąć. 

Jest taki stary dowcip, że nie po to poszedłem na studia informatyczne, żeby teraz rozmawiać z ludźmi. I paradoksalnie to jest niestety domena tych ludzi, którzy mają bardzo mocny kręgosłup techniczny, że nie wszyscy są otwarci na to, żeby te umiejętności miękkie rozwijać. I to jest pewne wyzwanie. 

 

Myślę sobie, że często lepiej albo łatwiej jest się uczyć, podając pewne kontrprzykłady, albo pewne błędy, więc chciałbym Cię zapytać, z Twojego doświadczenia, jakie najczęściej właśnie wpadki, jakieś skrzywienia popełniają firmy albo zespoły, które w sposób nieumiejętny zabierają się za DevOps. Co mógłbyś tutaj podać, co mogłoby posłużyć jako swego rodzaju lekcja dla firm czy właśnie zespołów, które myślą o tym, żeby takie podejście DevOpsowe u siebie zastosować? 

 

Myślę o rzeczach, które gdzieś tam nam przeszkadzają, czy uważamy, że nie są optymalne DevOpsowo, żeby nie mówić, że są błędne, bo to może być zbyt mocne słowo, to często zdarzają nam się takie sytuacje, w których zespoły mają tak sztywno określone granice i to odgórnie określone granice, że bardzo ciężko jest się między nimi przebić i to są często osobne jednostki organizacyjne, to są często osobne nawet silewary, które zarządzają jakimiś fragmentami albo wiceprezydenci, te nazwy w tych większych organizacjach są różne. Natomiast sprawia, że te komórki są osobne i one często między sobą rozmawiają nie face to face, tylko przez menadżera, dyrektora albo jeszcze wyżej.

I to jest duży problem komunikacyjny. Takie bariery są chyba najtrudniejsze do rozbijania, bo w tych firmach często dostajemy taki feedback, że słuchajcie, jesteście w tym silosie i nie powinniście chodzić do drugiego silosu. I my na ogół się nie do końca słuchamy akurat tego stwierdzenia.

Natomiast ta budowa relacji to jest to, czego w tych firmach brakuje pod kątem takich umiejętności miękkich. A jak mówimy o tym DevOpsowaniu i infrastrukturze cloudowej, to też taką częstą bolączką, którą widzimy, jest to, że bierzemy jedną tylko grupę, czyli specjalizującą się w developmencie, która mają troszeczkę kursów zrobionych albo trochę poczytali o cloudzie i już ślepo wierzymy, że to jest zespół DevOpsowy i on zrobi i aplikację, i infrastrukturę.

I owszem, on zrobi tę infrastrukturę, bo są te warstwy abstrakcji, natomiast zdarzają nam się tacy klienci, do których przychodzimy i okazuje się, że backupów w sumie nie ma, bo ich nikt nie włączył i jakoś ta infrastruktura powstała, biznesowo spełnia swoją funkcję, ale pod kątem tym właśnie utrzymania ciągłości działania, to dużo jej brakuje.

W związku z tym myślę, że potrzebujemy w tych zespołach takiego miksu, żeby mieć i developerów, i ludzi od infrastruktury i po prostu ich ze sobą połączyć. Więc ja się często śmieję, że znam dwie grupy ludzi, jeśli chodzi o DevOpsów, że jest mały Dev, duże Ops, czyli ludzi, którzy mają bardzo duży background infrastrukturalny i trochę developmentu i w drugą stronę duże Dev, małe Ops, czyli przede wszystkim tych, co się skupiali na developmencie i dość dobrze znają infrastrukturę. I to jest w sumie taka fajna grupa, która się fajnie zakleszcza. Jeżeli mamy ich wszystkich w ramach jednego zespołu, to potrafimy naprawdę fajne rzeczy wtedy razem budować.

W związku z tym myślę, że potrzebujemy w tych zespołach takiego miksu, żeby mieć i developerów, i ludzi od infrastruktury i po prostu ich ze sobą połączyć. Więc ja się często śmieję, że znam dwie grupy ludzi, jeśli chodzi o DevOpsów, że jest mały Dev, duże Ops, czyli ludzi, którzy mają bardzo duży background infrastrukturalny i trochę developmentu i w drugą stronę duże Dev, małe Ops, czyli przede wszystkim tych, co się skupiali na developmencie i dość dobrze znają infrastrukturę. I to jest w sumie taka fajna grupa, która się fajnie zakleszcza. Jeżeli mamy ich wszystkich w ramach jednego zespołu, to potrafimy naprawdę fajne rzeczy wtedy razem budować.

 

Czy jest coś, czego Ci brakuje w DevOps? Czy według Ciebie jest to już pełne, zamknięte i w pełni dojrzałe podejście, czy może brakuje mu pewnych elementów?

 

Ja myślę, że tutaj przede wszystkim brakuje instrukcji obsługi do tego, bo jakby wszyscy by to chcieli mieć, tylko pytanie, jak do tego dojść i dlatego też nie chciałem mówić, że pewne podejścia są błędne, bo jakby one działają, to są firmy, które przynoszą zyski, często bardzo duże zyski, w związku z czym nie jestem w stanie powiedzieć, ej słuchajcie, robicie wszystko źle, bo oni naprawdę zrobili kupę dobrej roboty.

Natomiast to podejście DevOpsowe często widzimy, że jest może trochę nie po naszemu, albo nie tak, jakbyśmy to widzieli, albo zwracamy uwagę z innej perspektywy na pewne aspekty, które mogą zadziałać. Więc w ramach tej kultury DevOpsowej moim zdaniem przede wszystkim brak tu takiej jasnej instrukcji obsługi, jak to wdrożyć i jak to powinno działać. I te domniemania  nie zawsze są optymalne.

 

No tak, niby takie proste, a jednocześnie wcale niekoniecznie. Dobrze, chciałbym Cię zapytać jeszcze pod kątem właśnie tych kompetencji, które wnoszą do firmy osoby, które się tym DevOps zajmują. Nie znam takich jeszcze póki co studiów w Polsce, które by kształciły właśnie DevOps inżynierów. Może się mylę, może nie mam pełnego pojęcia, natomiast często jest tak, że są to osoby o wcześniejszych doświadczeniach właśnie albo deweloperskich, albo związanych z infrastrukturą, z chmurą.

Jak to wygląda według Ciebie? Co tutaj bardziej przeważy, albo jak ogólnie można byłoby zdefiniować background zawodowy osób, które się właśnie tym DevOps zajmują?

 

Patrząc po ofertach pracy i wymaganiach tego, co przychodzi, to są to raczej ludzie, którzy są po admince, tudzież administratorzy, którzy dodatkowo się właśnie rozszerzyli o to, że potrafią coś nakodować, są bardzo chętni do automatyzacji, więc jakby ten background jest raczej administracyjno-linuksowy. Tutaj trochę Azure’a będę skreślał, natomiast głównie taki administracyjny. I jakby od tego wydaje mi się, że większość ofert wychodzi, od tych kompetencji.

 

Ja pamiętam, swego czasu pracowałem z właśnie takim DevOps Ingenierem, który miał background mocno developerski i przyznam szczerze, że bardzo dobrze mi się z tą osobą pracowało, być może ze względu na takie dość mocne zrozumienie pracy, którą osobiście wykonywałem.

Czy według Ciebie któraś tutaj z tych, można powiedzieć, ścieżek dojścia do zostania DevOps inżynierem, czyli tutaj myślę o tych głównych dwóch, od strony developerskiej albo od strony administracyjnej, jest w jakiś sposób lepsza w określonych zastosowaniach, czy nie ma to do końca znaczenia?

 

Myślę, że nie ma znaczenia. Jeżeli ktoś się naprawdę zajawił tym i chce to rozwijać, to nawet u nas w zespołach mamy kilka osób, które ma background przede wszystkim developerski i w pewnym momencie zaczęli się interesować infrastrukturą. I to są naprawdę komandosi, więc tutaj nie widzę, żeby była jakakolwiek ujma, czy jedna, czy druga strona.

Obie wymagają wyjścia troszeczkę z tej szufladki, do której nas może trochę od początku wstawiają. Natomiast trzeba troszeczkę z tej bańki po prostu wyjść. Ale ważne też przy okazji rozmowy o DevOpsach jest to, że często firmy szukają takich specjalistów, którzy z każdego terenu coś próbowali zrobić. I to jest akurat bardzo trudny kawałek, bo z jednej strony szukamy gości, którzy potrafią coś z sieciami, potrafią z bazami danych, potrafią kodować, potrafią infrastrukturę. Ciężko jest te wszystkie kompetencje w ramach jednej osoby złapać.

Więc myślę, że tutaj też mówiąc o DevOpsach, że siła tak naprawdę leży w grupie, nie w pojedynczej osobie, że dobrze jest fajnie zbudować zespół, z fajnymi kompetencjami i mamy też takie case’y, gdzie łączymy ze sobą ludzi, którzy mają bardzo dobry background cloudowy z ludźmi, którzy bardzo długo byli na bare metalu, ale są naprawdę świetni, jeśli chodzi o jakikolwiek troubleshooting, troubleshooting linuxowy itd. I że to połączenie tak naprawdę sprawia, że nie dostajemy produktywności razy dwa, tylko produktywność razy trzy, bo fakt, że te osoby ze sobą rozmawiają, że potrafią tak szeroki zakres wiedzy skumulować, to jesteśmy w stanie naprawdę przesuwać duże rzeczy i duże projekty pchać do przodu.

 

Z tego, co mówisz, wnioskuję, że są swego rodzaju specjalizacje w ramach DevOps, chociażby wynikające z tego, że jest to dosyć szeroka dziedzina wiedzy i praktyki. Oczywiście też bardzo szybko się zmienia. Popatrzmy chociażby na chmurę, to jest coś, co pędzi niesamowicie do przodu, a to tylko jeden z elementów, jedna ze składowych całego podejścia DevOps.

I myślę sobie, że również AI ma tutaj coś do powiedzenia, które wchodzi do wielu dziedzin wiedzy. Jak sztuczna inteligencja zmienia DevOps w dzisiejszych czasach?

 

To przede wszystkim taki ruch, który widzę, to jest to, że zmniejszamy próg wejścia przede wszystkim dla ludzi od strony developmentu. Czyli developerzy coraz więcej pytają AI o to, jak zrobić pewne rzeczy, i to fajnie działa, ponieważ ten AI potrafi wręcz wygenerować fragmenty kodu terraformowego, który mogą po prostu dołożyć do naszego repozytorium i bardzo dużo rzeczy AI tutaj obniża trochę ten próg wejścia osób, które nie są stricte związane z infrastrukturą.

Natomiast to jest o tyle ciekawe, że zmniejszenie progu wejścia sprawia, że jest też dużo większe łaknięcie takich specjalistów, ale już takich naprawdę specjalistów specjalistów, że widzę z kolei po tej mojej grupie stricte infrastrukturalnej, że tutaj bardzo mocno ciśniemy w takie specjalizacje, żeby wiedzieć, jak to działa od podszewki. Bo to, co nam AI podpowie, to co zrobi, to na ogół fajnie zadziała, czasami może nawet mamy jakąś wizję tego, dlaczego to tak działa i jak to tak działa, ale jak to się zepsuje, to okazuje się, że AI nie zawsze jest w stanie nam pomóc rozwiązać ten problem.

I tutaj widzimy często właśnie takie zapytania, które ostatnio do nas szczególnie przychodzą, o pomoc w naprawdę hardcore’owych problemach, takich, gdzie już ciężko jest wygooglać informacje, trzeba po prostu znać technologię od podszewki, i wtedy też łatwiej jest coś znaleźć.

W związku z tym AI jest super, mega mi się podoba to, że pewne rzeczy automatyzujemy, natomiast z mojej perspektywy, z punktu widzenia inżyniera na rynku pracy też, to on zmniejszy prób wejścia, natomiast dalej szukamy ludzi, którzy są chętni do tego, żeby się nauczyć wszystkiego od zera, od podszewki do samej góry, po to, żeby wspomagać ten AI, jak on już niespecjalnie może wykminić co dalej.

 

Jasne, czyli spokojnie AI nie zabierze nam pracy, być może nieco ją zmodyfikuje, na pewno usprawni, ale póki co traktujmy to jako narzędzie. Super, swoimi spostrzeżeniami, swoim doświadczeniem związanym z DevOps dzielił się dzisiaj z nami Jacek Marmuszewski. 

Jacku, bardzo Ci dziękuję za spotkanie i za tę rozmowę. 

 

Również dziękuję. 

 

Powiedz, proszę, jeszcze na koniec, gdzie możemy słuchaczy odesłać, gdzie możemy Cię znaleźć w sieci? 

 

Myślę, że najłatwiej będzie przez stronę letsgodevops.pl, jak również jesteśmy dość aktywni na LinkedInie, także też profil letsgodevops na LinkedInie możecie obserwować. 

 

Świetnie. Oczywiście linki standardowo znajdziecie w notatkach do tego odcinka. Jacek, jeszcze raz bardzo Ci dziękuję. 

Do usłyszenia i cześć! 

 

Dzięki wielkie.

 

I to na tyle z tego, co przygotowałem do Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania?  Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, jak pracuje DevOps.

Do usłyszenia w następnym odcinku.

Cześć!

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
Tags:
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się backendem aplikacji internetowych i zarządzaniem działami IT. Dodatkowo prowadzę podcast, występuję na konferencjach i jestem autorem książki "Marka osobista w branży IT". Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.