Jak zostać i rozwijać się jako DevOps?

Krzysztof Kempiński
Jun 22 · 11 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Jackiem Biernatem i Tomaszem Skibińskim o tym jak zostać i rozwijać się jako inżynier DevOps.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Dzisiaj w podcaście moimi gośćmi są: Jacek Biernat, prezes zarządu, CEO, Solution Architect i DevOps w LCloud oraz Tomasz Skibiński, inżynier DevOps i Chief Technology Officer w LCloud.

Jacku, Tomku, cześć! Bardzo miło mi gościć Was w podcaście.

Tomasz Skibiński: Cześć!

Jacek Biernat: Cześć, Krzysztofie! Dzięki za zaproszenie.

Przyjemność po mojej stronie. Wiele razy padło tutaj słowo DevOps i to będzie jeden z głównych tematów, głównych wątków naszego dzisiejszego podcastu. Będziemy rozmawiać o tym, jak zostać, jak pozostać i jak rozwijać się właśnie w roli inżyniera DevOps.

Na początku jednak zadam Wam standardowe pytanie, które zadaje każdemu, kto rozmawia ze mną w podcaście. Mianowicie, czy słuchacie podcastów? Czy to medium jest Wam bliskie?

J.B.: Ok, to może ja odpowiem. Tak, słucham, ale nie ograniczam się tylko do podcastów, raczej do wszelkich nagrań z social mediów czy audiobooków, w których mogę znaleźć więcej informacji na konkretny temat, który mnie właśnie zaciekawił. Nie będę ukrywał, że większość nagrań jest w języku angielskim, z kilku dziedzin, niekoniecznie IT. Ale jeśli mamy dzisiaj rozmawiać o DevOps, to może bym sobie pozwolił wymienić jeden polskojęzyczny kanał z technologii cloud, który ostatnio zadebiutował jako zapowiedź fajnej serii nagrań. Jest to YouTube od AWS Polska, dostawcy chmurowego, który podsumowuje nowości cloud u tego dostawcy z ostatniego miesiąca. Na pewno jest to fajna pigułka wiedzy dla każdego DevOps, który chce specjalizować się w tej konkretnej technologii, być na bieżąco i znać nowe trendy, rozwiązania u lidera tego dostawcy chmurowego.

Tomku, a jak u Ciebie to wygląda?

T.S.: Szczerze mówiąc, ja rzadko słucham podcastów, co jest uzależnione od ilości posiadanego czasu. Od czasu do czasu słucham, staram się słuchać najnowszego podcastu The Cloudcast. Jest to angielskojęzyczny podcast. A tak przeważnie raczej śledzę i oglądam jakieś materiały na YouTube czy innych platformach, na których prezentowane są konkretne rozwiązania. I tak to wygląda, tak naprawdę, u mnie.

Świetnie. Dzisiaj między innymi będziemy rozmawiać o rozwoju w roli DevOpsa, więc z pewnością zapytam Was jeszcze trochę głębiej o materiały czy źródła wiedzy. Ale myślę, że na początku dobrze byłoby wyjaśnić taki podstawowy temat, czyli kim jest DevOps. Albo czym, bo mam wrażenie, że trwa taka dyskusja, czy to jest bardziej filozofia, czy to jest bardziej rola. Więc gdybyście mogli powiedzieć, jaki zakres obowiązków według Was wykonuje inżynier DevOps, jeśli tak już mamy nazwać rolę, jakie zadania na co dzień wykonuje? W jakich projektach można taką rolę znaleźć, a w jakich niekoniecznie?

T.S.: Zacznijmy od tego, że samo pojęcie DevOps jest przede wszystkim kulturą organizacyjną promującą współpracę pomiędzy działami wytwarzania oprogramowania, czyli development oraz zarządzania systemami, czyli operations. Stąd DevOps skupia się na płynnej komunikacji pomiędzy zespołami technicznymi odpowiedzialnymi za rozwój i dostarczanie produktu do klienta końcowego, zmniejszając jednocześnie tarcia pomiędzy tymi różnymi zespołami.

DevOps jest przede wszystkim kulturą organizacyjną promującą współpracę pomiędzy działami wytwarzania oprogramowania, czyli development oraz zarządzania systemami, czyli operations. Stąd DevOps skupia się na płynnej komunikacji pomiędzy zespołami technicznymi odpowiedzialnymi za rozwój i dostarczanie produktu do klienta końcowego, zmniejszając jednocześnie tarcia pomiędzy tymi różnymi zespołami.

Jako inżynier, DevOps jest w pewien sposób łącznikiem pomiędzy światem programistów oraz administratorów. Z jednej strony zajmuje się instalacją, konfiguracją oraz administracją systemami operacyjnymi i różnymi usługami, jednocześnie automatyzując te prace, pisząc nieraz skomplikowane skrypty w Bashu, PowerShellu czy Pythonie lub wykorzystując inne narzędzia do zarządzania konfiguracją czy opisując w konkretnym języku całe infrastruktury. Przygotowuje i rozwija ścieżki ciągłej integracji, dostarczając i wdrażając oprogramowanie, ułatwiając w ten sposób życie programistom i pomagając im w pewien sposób w spełnieniu oczekiwań biznesowych. DevOps jest często kojarzony i niejako zamykany w ujęciu chmury obliczeniowej, takiej jak AWS czy GCP. Jednak według mnie nie powinniśmy o nim myśleć tylko w ten sposób.

Współpraca pomiędzy działami programistów i administratorów oraz automatyzacja procesów wykracza daleko poza tylko ten wycinek IT. Chmura oczywiście z jednej strony ułatwia, a z drugiej w pewien sposób wymusza wykorzystywanie praktyk DevOps poprzez oferowanie różnych funkcjonalności. Jeżeli mamy do dyspozycji jakąś funkcjonalność czy API, które pomaga nam na przykład w przyspieszeniu wdrażania nowych wersji aplikacji czy podnosi bezpieczeństwo systemu, grzechem jest z tego nie skorzystać.

Jedna z zabawniejszych definicji inżyniera DevOps, która zapadła mi w pamięci, opisuje go jako kogoś, kto rozwiązuje problemy, o których nie wiedziałeś, że je masz w sposób, którego nie rozumiesz. Jestem w stanie w pewien sposób się z tym zgodzić. Zaawansowany inżynier DevOps stale poszukuje nowych rozwiązań problemów, z którymi mógł mieć do czynienia już wielokrotnie. Chodzi o to, aby stale poprawiać i usprawniać to, co jest możliwe do poprawy i usprawnienia z wykorzystaniem innych lub nowych rozwiązań, które odkryło się w między czasie.

Czy na bazie Twoich doświadczeń z LCloud, z klientami, z którymi współpracujecie można powiedzieć, że jest jakiś typ projektów albo kilka typów projektów wielkościowych czy technologicznie zorientowanych, w których taka rola ma sens, a w innych nie ma? Czy raczej ciężko wyznaczyć takie granice i tak naprawdę każdy projekt będzie czerpał jakąś wartość z podejścia DevOpsowego?

J.B.: Wszystko zależy od projektu i zastosowanego rozwiązania technologicznego w tym projekcie, ponieważ jest to też uzależnione od wymagań, jakie stawia przed nami klient. I oczywiście, jeśli jest to na tyle prosta infrastruktura, że nie wymaga zbyt skomplikowanych rozwiązań od strony infrastruktury czy dostarczania aplikacji poprzez deployments CI/CD, to wtedy tak, może być taka sytuacja, że developer czy administrator systemowy, tak zwany SysOps, może w takim projekcie być wystarczający, jeśli poznał usługi cloudowe, tę technologię, w której ma wykonać rozwiązanie. Tak myślę.

Jasne. Myślę, że to jest bardzo dobra odpowiedź. Mnie z kolei bardzo bliski jest świat startupowy. Często startuje się tam z jakąś ideą, z jakimś pomysłem, z jakimś NVP, które należy zweryfikować, walcząc z czasem i z kosztami. Więc oczywiście taka rola jest dodatkowym kosztem, niekoniecznie nawet uzasadnionym technologicznie, tak jak Jacku powiedziałeś. Nie wiem, czy się ze mną zgodzicie, że taka rola czy taka osoba inżyniera może dołączyć w późniejszym etapie, kiedy już ten projekt, ta firma dojrzewa, chce pewne procesy, pewną komunikację usprawnić i wtedy ten DevOps nie musi być od samego początku na pokładzie. Dołączając w późniejszej fazie również może wnieść znacząco dużo wartości.

J.B.: Może bym do końca się jednak nie zgodził z tą opinią.

Ok, świetnie.

J.B.: Wszystko zależy od projektu, ponieważ ja się bardzo często spotykam z tym, że w startupach jednak jest aspiracja zbudowania dużej infrastruktury, która będzie docelowa dla klienta. Jeśli już na początku zaniedbamy pewne dobre praktyki, które powinniśmy rozpocząć od tworzenia infrastruktury czy też zaprojektowania aplikacji w ten sposób, żeby się na przykład poprawnie skalowała i żeby później programiści mogli w dobry sposób rozwijać aplikację, która będzie miała taką możliwość zwiększania trafficu z Internetu, to później może być po prostu z tym problem, ponieważ zmiany mogą być dla kogoś kosztowne, a wręcz firma może stwierdzić, że ten cloud nie jest taki idealny, ponieważ może jest i droższy, tak patrząc od strony kosztowej, niż jakieś rozwiązanie on-premise.

Myślę, że DevOps nie będzie potrzebny, jeśli wykorzystamy aplikacje, na przykład e-commerce, która jest już standardowa, monolityczna, która już od dziesięciu czy dwudziestu lat jest wdrażana. Jeśli klient chce prostą konfigurację, wtedy faktycznie DevOps nie jest potrzebny, ponieważ administrator może przygotować konfigurację jeden do jeden na cloudzie, tak jakby to przygotował on-premise. Ale wtedy nie wykorzystujemy tych wszystkich dobrodziejstw rozwiązań chmurowych.

Jasne, rozumiem. Myślę, że z jednej strony to podejście DevOpsowe jest całkiem młode, nawet jak na naszą branżę, to jest de facto kilka lat, kiedy mówi się i rozwija to podejście. Z drugiej strony, nie ma uniwersytetów, które kształcą w tym kierunku, więc ci ludzie muszą się skądś brać. Jak się spojrzy na ścieżkę kariery zawodowej inżyniera DevOps, to zazwyczaj miał on swoje początki w różnych aspektach IT, niekoniecznie na przykład w administracji serwerami, co wydaje się najbardziej oczywiste, ale to nie zawsze jest w ten sposób. Czy możecie zdradzić, jak to wyglądało w Waszym przypadku? Jakie drogi Was doprowadziły do roli czy odpowiedzialności DevOpsa? Jak wyglądał Wasz rozwój zawodowy?

T.S.: Może na moim przykładzie. Moja historia kariery zawodowej jako DevOpsa w pewien sposób zaczęła się już na etapie liceum oraz studiów inżynierskich. Początkowo kierowałem się w stronę kariery jako programista, z uwagi na duży nacisk położony na kwestie programowania i algorytmiki w liceum, do którego uczęszczałem. Mogę powiedzieć, że miałem to szczęście trafić na nauczyciela, który zainteresował mnie programowaniem w C++, dzięki czemu zdobyłem podstawy i nabrałem dobrych nawyków, które przekładają się na inne języki, z którymi mam większą styczność.

Następnie, na etapie studiów inżynierskich skierowałem się bardziej w stronę administracji systemami Linux i sieciami, z uwagi na brak profilu typowo programistycznego w ofercie uczelni, którą wybrałem. Myślę, że to złożyło się w pewien sposób na dobre podstawy pod mój przyszły rozwój jako DevOps. Jednocześnie muszę powiedzieć, że nie ograniczałem się tylko do zadań otrzymywanych od wykładowców, ale spędzałem również długie godziny i wieczory nad poszerzaniem zdobytej wiedzy oraz testowaniem różnych innych języków, rozwiązań, konfiguracji czy narzędzi dostępnych na rynku.

W trakcie studiów, zacząłem też pracę w małej firmie hostingowej, która umożliwiła mi nabycie większego doświadczenia jako administrator. Popełniłem w tym czasie wiele różnych skryptów, które automatyzowały wybrane części konfiguracji istniejącej i nowej części infrastruktury. Tego typu zadania sprawiały, że widziałem sens w tym, co robię i nie muszę spędzać wielu godzin na powtarzaniu tych samych czynności i konfiguracji. W tym czasie, nie wiedziałem jeszcze, że to skieruje mnie na drogę DevOpsa.

Następnie zdecydowałem się na dołączenie do LCloud jako administrator systemów, który będzie miał okazję pracować z chmurą AWS. Pierwsze projekty, w które zostałem zaangażowany, sprawdzały moją wiedzę pod kątem administracji systemami Linux oraz krok po kroku umiejętności automatyzacji różnych aspektów konfiguracyjnych. Wtedy właśnie Jacek zauważył moje predyspozycje do roli DevOpsa i wyjaśnił mi wszystkie założenia oraz wymagania, które musiałbym spełnić. I tak zacząłem zagłębiać się w ten świat pracując nad różnymi projektami, poznając nowe zagadnienia teoretyczne oraz chmurę AWS i metody automatyzacji od praktycznej strony.

Myślę, że kluczowe są tu różnorodne, bogate doświadczenia, bo jednak w podejściu DevOpsowym chodzi o to, żeby usprawniać komunikację. W związku z tym trzeba przykładać ucho do różnych ruchomych części systemu, rozmawiać z różnymi działami w firmie. Różnorodność doświadczeń, nie tylko administracyjnych, ale i programistycznych, nieraz i testerskich jest tu jak najbardziej na plus. Jeśli popatrzymy na tę wstęgę DevOpsową, to mamy przynajmniej kilka różnych odpowiedzialności i fajnie jest, jeśli inżynier DevOps ma jakieś doświadczenia przynajmniej z kilkoma, bo to pozwala mu lepiej w tym modelu działać.

Umiejętności miękkie to jest też bardzo ważny aspekt, ponieważ inżynier DevOps z założenia musi usprawniać komunikację. O tym jeszcze będę chciał z Wami za chwilę porozmawiać. Ale wyjdźmy od tego, co jest niezbędne w tej roli, co też, mam wrażenie, jest najczęściej sprawdzane na rozmowach rekrutacyjnych, czyli od twardych umiejętności merytorycznych. Powiedzieliśmy, że chmura w dzisiejszych czasach to jest już minimum, niezbędna rzecz, która, przynajmniej jedna, w jakimś stopniu powinna być opanowana przez inżyniera DevOps. Czy coś jeszcze z twardych umiejętności, kompetencji technicznych przychodzi Wam do głowy, jeśli chodzi o umiejętności DevOpsa?

J.B.: Na pewno w wybranych projektach ciągle DevOps musi administrować systemami operacyjnymi, jak już powiedzieliśmy, Linux czy Windows, więc to na pewno się przydaje jako doświadczenie. Wiele zadań wymaga prac nad automatyzacją różnych procesów, więc w tym wypadku dochodzi doświadczenie w programowaniu, z czym niekoniecznie każdy administrator wcześniej miał do czynienia. To jest rzecz, którą musi nabyć lub którą po prostu wykorzystywał być może w pracy, będąc trochę programistą, trochę administratorem. Teraz jest to u DevOpsa jednak niezbędna rzecz.

Ważnym aspektem, na który jest teraz kładziony duży nacisk jest, aby każde rozwiązanie cloudowe było bezpieczne jako środowisko, stąd ważne jest, żeby rozumieć działania sieci i mieć znajomość zagadnień związanych z bezpieczeństwem. Nową technologią, która pojawiła się z DevOpsem i w którymś momencie z chmurami obliczeniowymi jest konteneryzacja rozwiązań Docker Kubernetes. W tym momencie stało się to również niezbędnym rozwiązaniem, które można nabyć w tym momencie lub już wcześniej, nie wykorzystując jeszcze nawet rozwiązań chmurowych.

Poza wiedzą techniczną ważne jest doświadczenie procesowe, bo DevOps to nie jest już tylko technologia, ale też kultura pracy i ważnym aspektem jest standaryzacja rozwiązań na poziomie całej firmy czy projektów w zakresie narzędzi czy technologii, którą DevOps czy grupa DevOpsów wykorzystuje do codziennej pracy.

Jacku, powiedziałeś o językach programowania i jeśli mogę coś to dodać, to widziałbym tutaj pewne rozróżnienie. Z jednej strony, to jest faktycznie znajomość języka programowania w stopniu umożliwiającym pisanie skryptów automatyzujących, a z drugiej strony, nie wiem, czy się ze mną zgodzicie, coś, co leżało trochę u podstaw powstania podejścia DevOpsowego. Czyli zbliżenie części deweloperskiej i części operacyjnej z założeniem, że taka osoba zna w jakiś sposób stack technologiczny, rozwiązania programistyczne, żeby móc je testować, coś w nich usprawniać czy właśnie modyfikować albo wpływać jakoś na security tych rozwiązań. Czy według Was jesteśmy właśnie w tym punkcie? Czy obecnie inżynier DevOps w jakiś sposób jest częścią zespołu programistycznego i powinien znać na przykład język czy też stack technologiczny projektu? Czy też nie jest to niezbędne i na co dzień jest po prostu nieprzydatne?

T.S.: Według mnie DevOps niekoniecznie musi być programistą. DevOps nie jest rozszerzoną rolą programisty. Oczywiście nie oznacza to, że programiści nie mogą być DevOpsami, mam tu na myśli to, że DevOps ma zupełnie inne zadania, wyzwania i cele niż tworzenie oprogramowania. Tak więc DevOps nie jest programowaniem, ponieważ są to po prostu różne kultury. To różnica, która jest dosłownie częścią nazwy DevOps, czyli rozwój i operacje. DevOps nie jest według mnie także zaawansowanym programistą, chociaż posiadane doświadczenie programistyczne może mu pomóc w wielu kwestiach.

DevOps nie jest rozszerzoną rolą programisty. Oczywiście nie oznacza to, że programiści nie mogą być DevOpsami, mam tu na myśli to, że DevOps ma zupełnie inne zadania, wyzwania i cele niż tworzenie oprogramowania. Tak więc DevOps nie jest programowaniem, ponieważ są to po prostu różne kultury. To różnica, która jest dosłownie częścią nazwy DevOps, czyli rozwój i operacje. DevOps nie jest według mnie także zaawansowanym programistą, chociaż posiadane doświadczenie programistyczne może mu pomóc w wielu kwestiach.

Są też inżynierowie DevOps, którzy nigdy wcześniej nie pełnili funkcji jako programista, a mają doświadczenie głównie jako administrator systemów i sieci i potrafią się odnaleźć lepiej w takiej roli niż programista z wieloletnim doświadczeniem.

Tak, ja w swoich projektach też mam do czynienia z osobami, które mają i jeden i drugi background, tak jak Tomku powiedziałeś, i faktycznie widzę ich mocne strony w innych aspektach. To się da zauważyć dosyć szybko.

Mamy mniej więcej zarysowany obszar merytoryczny, za chwilę będę chciał go trochę pogłębić. Natomiast inną bardzo ważną cechą w zmniejszaniu barier komunikacyjnych jest posiadanie pewnych umiejętności miękkich, o których coraz szerzej, coraz więcej się mówi w IT. Czy według Was jest jakiś zakres umiejętności, nad którymi DevOps powinien pracować, które mu na co dzień mogą pomóc w pracy?

J.B.: Tak, nad niektórymi umiejętnościami możemy pracować, ale są też umiejętności zawarte w charakterze osoby. Na pewno chęć poszerzania wiedzy, motywacja, żeby poszerzać tę wiedzę, ponieważ rozwiązania chmurowe rozwijają się bardzo szybko i dynamicznie. Z każdym dniem pojawiają się nowości, które mogą zasugerować lepsze, efektywniejsze rozwiązanie w danym projekcie, czego jeszcze wczoraj byśmy nie wymyślili sami albo bez tego rozwiązania, które się dzisiaj akurat pojawiło. Stąd DevOps musi wykazywać dużą ciekawość pojawiających się nowych rozwiązań.

Dzięki temu, że dostawcy chmurowi przygotowują swoje usługi, cloud DevOps ma możliwość użycia wielu gotowych technologii, skonfigurowanych już pod wykorzystanie. Dlatego też nie może być zamknięty na jedno rozwiązanie, ponieważ ma możliwość łatwego wdrażania różnych usług w szybkim czasie. Powoduje to, że te rozwiązania mogą być bardziej efektywne, dostosowane do danego etapu projektu od strony tworzenia aplikacji.

Inną ważną umiejętnością jest zwinność i elastyczność podejścia do realizowania zadań i projektów. Jest to bardzo ważne, aby DevOps mógł szybko zebrać informacje zwrotne, naprawić błędy na wczesnym etapie budowania aplikacji, inspirować deweloperów o dalszym kierunku budowania aplikacji.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-121-jak-zostac-i-rozwijac-sie-jako-devops/

kkempin’s dev blog

kkempin’s dev blog

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

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.