Uwaga! Trwają prace nad nową wersją serwisu. Mogą występować przejściowe problemy z jego funkcjonowaniem. Przepraszam za niedogodności!

🔥 Zgarnij PŁATNY STAŻ w 3 edycji kursu programowania front end (zapisy do 22.01) 🔥

Wprowadzenie do DevOps

Czym/kim jest DevOps i jaką rolę pełni

Wojciech Lepczyński, DevOps Cloud Architect, opowiada o tym, czym jest DevOps, jakie korzyści przynosi firmom i ich klientom oraz czy trudno go wdrożyć. Podczas rozmowy poznasz również rolę DevOpsa w zespole i projekcie oraz dowiesz się, jak rozwijać się w tej dziedzinie i od czego najlepiej zacząć.

Poruszane tematy

  • Czy możesz się przedstawić i powiedzieć, co łączy Cię z branżą IT?
  • Co to jest DevOps i od jakich słów pochodzi?
  • Dlaczego czasem mówi się, że to kultura, a czasem, że metodyka? Czy to się czymś różni?
  • Jakie są cele DevOps – jakie korzyści DevOps przynosi firmie, a jakie jej klientom?
  • Czy z metodyką/kulturą DevOps spotkamy się głównie w większych firmach? Jeśli tak, to dlaczego np. mniejsze software house’y z niej nie korzystają?
  • Czy DevOps engineer jest programistą?
  • Czy jest on członkiem zespołu developerskiego, czy „wolnym elektronem”, który ma pod sobą np. kilka projektów w firmie?
  • Czy DevOps engineer ma coś wspólnego z architektem oprogramowania?
  • Czy DevOps engineer współpracuje też bezpośrednio z klientami firmy?
  • Jaka jest rola DevOps na różnych etapach wytwarzania oprogramowania? Powiedzmy: od pierwszych ustaleń z klientem po utrzymywanie aplikacji.
  • Czy Agile ma coś wspólnego z DevOps?
  • Jakie największe wyzwania stoją przed zespołem, który chce wdrożyć DevOps?
  • Jakie błędy są najczęściej popełniane, gdy zespół przestawia się na pracę w duchu DevOps?
  • Jakie narzędzia pomagają w implementacji DevOps?
  • Jak zacząć przygodę z DevOps? Od jakich umiejętności powinniśmy zacząć? Czy jest jakaś sprawdzona ścieżka dla DevOpsa, np. zaczynamy od administracji serwerami?
  • Jaką książkę polecisz osobie, która zgłębić temat DevOps od podstaw?
  • Gdzie możemy Cię znaleźć w sieci?

Polecane materiały

➡ artykuł „Znajdź swoje najlepsze narzędzie CI/CD”, DevOps w chmurach – technologiczny blog Patrycjusza Czerniga

➡ Jacek Walkiewicz, wystąpienie na TEDx: Pełna moc możliwości

Kontakt do gościa

➡ LinkedIn: linkedin.com/in/wojciech-lepczynski

➡ Kanał na YouTubie: Wojciech Lepczyński

➡ Blog: Wojciech Lepczyński - DevOps Cloud Architect - Cloud computing blog - AWS, Azure, Kubernetes, Automation. Tips and tutorials. (lepczynski.it)

Transkrypcja

Dziś moim gościem jest Wojciech Lepczyński. Wojtek opowie nam o tym, czym jest DevOps.

Wojtku, dziękuję, że przyjąłeś moje zaproszenie na rozmowę!

Cześć, witam wszystkich i dzięki za zaproszenie. Od jakiegoś czasu słucham Twoich podcastów. Muszę powiedzieć, że poruszasz ciekawe tematy, na przykład dotyczące architekta oprogramowania albo Agile – temat mi bliski, bo też związany z naszą dzisiejszą rozmową, czyli z DevOps.

Tak jest.

 

Może zanim zaczniemy mówić o DevOpsie, to powiedz, proszę, coś więcej o sobie – co łączy Cię z branżą IT.

Ja nazywam się Wojciech Lepczyński, aktualnie pracuję jako senior DevOps w GFT. Pomagam tam tworzyć cyfrowy bank w chmurze dla klienta z Azji. Taki bank bez fizycznych biur, budynków, który funkcjonuje w 100% w przestrzeni cyfrowej.

Pracując w IT byłem już administratorem, trochę architektem i konsultantem chmurowym. Teraz głównie jestem DevOpsem. Ogólnie już ponad 12 lat pracuję w IT i od jakichś 7 lat mam do czynienia z samą chmurą, a właściwie z różnymi chmurami.

Można powiedzieć że jestem pasjonatem chmury – mam kilka certyfikatów potwierdzających wiedzę – ale dla mnie bardziej istotne jest wyróżnienie, które otrzymałem od AWS za wkład w budowanie społeczności. Rok temu dołączyłem do AWS Community Builders.

Może mógłbyś nam powiedzieć, czym jest AWS Community Builders.

Jasne. W skrócie, to taki program dla ludzi, którzy dzielą się swoją wiedzą dotyczącą chmury AWS. Masz możliwość nawiązania kontaktu z innymi entuzjastami chmury, dostajesz różne prezenty od AWS, zniżki na egzaminy itp. Kiedyś nagrałem film o tym, co zawiera taki pakiet powitalny i czym jest ten program, a nawet razem z innymi ludźmi wystąpiłem w filmie stworzonym przez AWS reklamującym właśnie ten program.

Będąc w programie, możesz na przykład uczestniczyć w specjalnych webinarach, szybciej się rozwijać i dzięki temu lepiej pomagać innym. Ponadto wiem o rzeczach, które dopiero mają zostać wprowadzone. Niestety nie mogę się tym podzielić, bo podpisałem umowę o zachowaniu poufności. Trochę dziwi mnie, że tak mało osób z Polski w nim uczestniczy. To naprawdę fajny program dający duże możliwości. Nie ma jasnych kryteriów przyjęcia do programu, ale jeśli ktoś dzieli się swoją wiedzą dotyczącą chmury AWS, to ma szanse i moim zdaniem powinien aplikować.

Wracając do Twojego pytania: moja przygoda z IT zaczęła się dawno, dawno temu. Gdy byłem młody, miałem naście lat, to zacząłem od elektroniki. Gdy tylko dostałem swój pierwszy komputer z Windowsem 95, to rozkręcałem go chyba 1000 razy – modernizowałem, naprawiałem, ulepszałem itd.

I psułem.

Też się zdarzało. Nieraz bywało ciężko, ale zawsze jakoś udawało się ten komputer naprawić. Ty się tak nie śmiej, bo kiedyś Internet nie był tak dostępny jak dzisiaj i to nie było takie proste. Trzeba było iść do kolegi, popytać o pomoc albo iść do kafejki internetowej i pytać na forach, czatach itp.

Wiesz, pamiętam te czasy, więc wiem, jak to było. Śmieję się, bo sam może nie bawiłem się sprzętem, ale trochę bawiłem się oprogramowaniem. Pamiętam, że nie podobał mi się układ folderów w Windowsie i postanowiłem go zmienić. Potem ten system był już nie do odzyskania. Dlatego tak się trochę śmieje, bo pamiętam, jak to u mnie wyglądało.

No, czasem tak bywa.

Potem, jak już w końcu nauczyłem się naprawiać ten komputer, to naprawiałem też komputery rodzinie, znajomym, aż trafiłem do serwisu komputerowego – ale to są dawne czasy. Jak o tym pomyślę, to czuję się trochę staro.

Teraz już nie bawię się w naprawy komputerów. Bardziej zainteresowałem się IoT i smart home. Mam podłączone pod Raspberry Pi kilka czujników temperatury, wilgotności i kilka przekaźników, dzięki czemu mogę sterować na przykład oświetleniem z telefonu, ale traktuję to bardziej jako zabawę.

Jako pasjonat chmury i automatyzacji prowadzę także swój blog. Pomagam ludziom przez pisanie różnych tutoriali, porad itp. Kiedy zaczynałem pisać, liczyłem na to, że zainteresuję kilka osób, no może 100. Jednak plan nie wypalił, bo teraz zamiast 100 czytelników mam około 30 tys. miesięcznie. Blog piszę w dwóch językach, po polsku i angielsku, i najwięcej czytelników mam właśnie w Stanach.

Od niedawna jeszcze oprócz wpisów na blogu zacząłem tworzyć filmy oraz prowadzić kanał na YouTubie z poradami i tutorialami dotyczącymi głównie chmury. Czasem łatwiej coś pokazać. Tak właściwie to nie był mój pomysł, tylko czytelników mojego bloga – oni sugerowali, że chętnie zobaczyliby moje porady w wersji wideo.

Muszę przyznać, że potężne doświadczenie, dużo rzeczy robisz, dużo się dzieje.

 

Czas więc chyba zapytać o temat, który dzisiaj mamy poruszać, czyli: co to jest DevOps i od jakich słów pochodzi?

Dobre pytanie na rozgrzewkę, choć nie jest takie proste. Nazwa „DevOps” powstała z połączenia angielskich słów development i operations. Mówi o współpracy pomiędzy działami wytwarzania oprogramowania (development) i zarządzania systemami (operations).

Natomiast wyjaśnienie, czym jest DevOps, będzie trochę trudniejsze. Ludzie rozumieją to pojęcie na swój sposób. W Internecie można znaleźć wiele definicji, co czasem utrudnia zrozumienie, czym naprawdę jest DevOps. Część ludzi przyznaje wprost, że w ich firmach używają metodologii DevOps, choć oni sami nie do końca wiedzą, co ona oznacza. Jedną z najczęściej słyszanych definicji jest ta o podejściu, filozofii – takiej metodyce skupiającej się na współpracy, na pracy jako zespół i wspierającej automatyzację. W gruncie rzeczy pozwala być bardziej wydajnym, szybciej dostarczyć gotowy produkt do klienta.

Dzisiaj często ludzie mówiąc „DevOps” nie mają na myśli filozofii, a konkretną rolę: DevOps engineera. Kiedyś było się developerem albo administratorem. Dzisiaj można być kimś pomiędzy, osobą łączącą te dwa obszary.

 

Dlaczego czasem mówi się, że to kultura, a czasem, że metodyka? Czy to się czymś różni?

Dobrze, że o to pytasz. Nie chcę tu jednak czytać żadnych regułek z Wikipedii czy innego źródła, bo ja nigdy nie lubię uczyć się czegoś na pamięć. Zawsze próbuję coś zrozumieć i potem powiedzieć o tym swoimi słowami. Uważam, że jest to bardziej przystępne.

DevOps dla mnie oznacza zmianę kulturową, zmianę dotychczasowego podejścia. Mówi o współpracy między wszystkimi zespołami wytwarzającymi oprogramowanie, pozwala zobaczyć większy obrazek. Mówi o współpracy i wzajemnym wspieraniu się zespołów, o dążeniu do wspólnego celu, czyli stworzeniu gotowego produktu. Mówi o wspólnym rozwiązywaniu problemów, a nie ciągłym odbijaniu piłeczki: „to nie mój problem, u mnie przecież wszystko działa”.

DevOps to także metodyka, jak wspomniałeś. Stawia ona na budowę wspólnego środowiska, skupia się na uzyskaniu maksymalnej wydajności i wspiera automatyzację kroków oraz promuje stopniowe osiąganie założonych wcześniej celów. W skrócie: mówi ona o ciągłym budowaniu, testowaniu i wdrażaniu. Programiści częściej wypuszczają mniejsze zmiany, które na bieżącą są testowane i poprawiane w razie potrzeby.

 

Jakie są cele DevOps – jakie korzyści DevOps przynosi firmie, a jakie jej klientom?

Na pewno celem jest poprawa współpracy, o której wspomniałem już wcześniej – zwiększa ona efektywność zespołów, usprawnia pracę nad projektem i niesie szereg innych korzyści.

DevOps kładzie nacisk na automatyzację powtarzalnych rzeczy, dzięki czemu przyspieszamy pracę, unikamy drobnych ludzkich pomyłek i możemy skupić się na naprawdę ważnych rzeczach, na przykład czas utworzenia i skonfigurowania gotowej do pracy wirtualnej maszyny spada z godzin do minut.

Dzięki otrzymywaniu ciągłej informacji zwrotnej i wprowadzaniu automatyzacji testów zmniejsza się liczba błędów oraz oczywiście szybkość ich naprawy. Dzięki temu zapewniamy wyższą jakość wytwarzanego produktu. Gotowy produkt zawiera mniej błędów.

Automatyzacja na wielu etapach powoduje szybsze wprowadzenie produktu na rynek oraz co za tym idzie – zmniejszenie kosztów.

DevOps mówi dużo o współpracy: dzięki temu, że zespoły potrafią lepiej ze sobą współpracować i się dogadywać, a praca idzie bardziej płynnie, to wzrasta zadowolenie i satysfakcja pracowników z wykonywanej pracy.

Stosując kulturę DevOps wraz z narzędziami i dobrymi praktykami, zespoły zyskują możliwość szybszego reagowania na potrzeby klienta, co z kolei zwiększa zaufanie od strony klienta i pomaga szybciej dostarczyć produkt, którego potrzebuje klient.

Zawsze istotna jest rozmowa z klientem i zrozumienie jego potrzeb. Wiesz, często jest tak, że klient chce dostać określony produkt, ale przekazanie informacji, jak ma ten produkt wyglądać i jakie ma mieć funkcjonalności, nie jest już takie proste. Ale nawet, gdy wszystko jest realizowane zgodnie z planem, to często okazuje się, że w środku pracy nad projektem coś trzeba dodać, zmienić, poprawić. Zmiany w trakcie trwania projektu w IT nie są niczym nowym i nigdy nie były proste. Im dłużej czekamy, tym zmiany stają się trudniejsze do wprowadzenia. Gdy potrafimy szybko reagować, to możemy zaoszczędzić dużo czasu i szybciej wprowadzić gotowy produkt na rynek.

 

Jak tak opowiadasz, to mam wrażenie, że metodyka czy kultura DevOps jest spotykana głównie w większych firmach. Jeśli tak, to jak myślisz, dlaczego? Czy mniejsze software house’y jej nie wykorzystują, czy może jej nie potrzebują? A może jest to zbyt duży nakład?

W mniejszych firmach dużo rzeczy można było załatwić podczas przerwy na kawę albo po prostu iść do kogoś i pogadać o tym, co potrzeba. Dzięki temu można było szybko wprowadzać zmiany. Jeśli komunikacja była dobra, to nie odczuwało się tak dużej potrzeby zmian.

W małych firmach często wygląda to tak, że jak jesteś z IT, to musisz zajmować się wszystkim. Czasem jesteś adminem, czasem zamawiasz nowy sprzęt, a czasem naprawiasz komuś drukarkę lub komputer. Ogólnie pracownicy w małych i średnich firmach muszą znać się na większej ilości rzeczy, są bardziej wielozadaniowi. Nie zawsze jest to dobre. Czasem jednak po prostu firmy nie stać na to, by stworzyć własny zespół inżynierów DevOps – bo jest to bardzo kosztowne.

Im więcej osób pracuje w firmie, tym trudniej wszystkich znać. Teraz nawet w mniejszych firmach jest to trudniejsze, bo dużo ludzi pracuje zdalnie. Moim zdaniem mniejszy fizyczny kontakt utrudnia komunikację, dogadywanie się i spowalnia wprowadzanie zmian. Gdy dostrzegamy te problemy, to odczuwamy potrzebę zmian i szukamy rozwiązania.

Czasem większe firmy mają także przestarzałe zasady zarządzania i na przykład zmiana drobnych ustaleń wymaga szeregu spotkań. To samo dotyczy wdrażania nowych pomysłów. Długa droga decyzyjna hamowała rozwój i innowacyjność. Dlatego większe firmy widzą większą potrzebę szybszego wprowadzenia DevOps.

Niestety czasem dział developerski i administracyjny, jakby to delikatnie powiedzieć, nie przepadają za sobą. Każdy widzi tylko swoją część i uważa, że ten drugi zespół jedynie utrudnia mu pracę i stwarza jakieś dodatkowe, niepotrzebne problemy. Nie dostrzegają czasem większego obrazka. Wiele dużych firm wprowadziło kulturę DevOps także po to, by przyspieszyć komunikację, poprawić jej jakość i dzięki temu zwiększyć szybkość wprowadzania zmian.

Dodatkowo większe firmy mają większe zasoby. Mogą sobie pozwolić na szybsze zmiany, na zatrudnienie specjalistów, którzy pomogą te zmiany wprowadzić.

Ale absolutnie nie jest tak, że kultura DevOps jest zarezerwowana tylko dla dużych korporacji, bo widywałem także mniejsze firmy, które ją stosują. Jednak to zazwyczaj większe firmy odczuwają większą potrzebę jej wprowadzenia.

 

Czy DevOps engineer jest programistą, czy nie? A może jest administratorem?

Ja bym powiedział, że może być programistą, ale wcale nie musi. Na pewno przydaje się wiedza programistyczna. Jednak z mojego punktu widzenia DevOps engineer może zajmować się mnóstwem rzeczy i nie musi być programistą.

Ja na przykład nie uważam się za programistę. Zanim zostałem DevOpsem, byłem adminem. Programowanie miałem na studiach i strasznie go nie lubiłem. Teraz się to trochę zmieniło. Fajnie, jak znasz coś poza bashem i PowerShellem. Przydaje się umiejętność tworzenia skryptów automatyzujących zadania. Znajomość jakiegoś języka programowania na pewno ułatwia sprawę.

Dużo firm zarządza swoją infrastrukturą z poziomu kodu, używając na przykład CloudFormation czy mojego ulubionego Terraforma – czyli za pomocą kodu możemy utworzyć wirtualne sieci, maszyny, tablice routingu itp. Co więcej, nie tylko możemy je utworzyć, ale także możemy je automatycznie skonfigurować pod każde środowisko. Do konfiguracji maszyn albo budowy gotowych obrazów możemy wykorzystać na przykład Ansible’a, Puppeta, Chefa czy cokolwiek innego.

Używając Infrastructure as Code możemy za każdym razem stworzyć takie samo środowisko. Unikamy dzięki temu błędów, poprawia się możliwość zarządzania i kontroli całego środowiska. Zazwyczaj używa się także systemu kontroli wersji, który ułatwia wprowadzanie i śledzenie zmian oraz – co ważne – powrót do wcześniejszej wersji, gdyby ta nowa okazała się błędna.

Ktoś powie: „no OK, ale ja szybciej coś wyklikam, niż ty stworzysz to w tym kodzie”. Powiedziałbym: to zależy. Zgodzę się, że dla jednego środowiska może i będzie szybciej, ale czy na pewno zrobisz to szybciej na 5 środowiskach i 30 projektach i na pewno się nie pomylisz? A jeśli się pomylisz, to jak wrócisz do wcześniejszej wersji? Przy użyciu Infrastructure as Code i systemu kontroli wersji jest to po prostu łatwe.

 

OK, no dobrze, to może kolejne pytanie. Czy DevOps engineer jest członkiem zespołu developerskiego, czy „wolnym elektronem”, który ma pod sobą na przykład kilka projektów w firmie?

To tak naprawdę zależy od firmy i od doświadczenia tego człowieka. Tu znowu: w mniejszych firmach ze względu na małe zasoby może być kilku DevOpsów zajmujących się wszystkim. W większych – to już zależy.

Wątpię, żeby osoby, które zaczynają, miały pod sobą kilka projektów. Zazwyczaj będą uczyć się od jakiegoś seniora na jednym projekcie. Senior z kolei może zajmować się jednym projektem albo być na kilku jednocześnie, tylko wyznaczając zadania, sprawdzając i służąc radą. Na przykład w GFT, mając większe doświadczenie, możesz wybrać jedną spośród 3 ścieżek swojego rozwoju: ścieżka zorientowana na wiedzę ekspercką, na technologię albo na zarządzanie zespołami. Tak że DevOps może zajmować się naprawdę różnymi rzeczami.

Czy DevOps engineer ma coś wspólnego z architektem oprogramowania?

Zazwyczaj są to dwie osobne role, jednak jakąś wiedzę z zakresu architektury powinno się mieć. Tutaj także w mniejszych firmach może dojść do tego, że te role będą połączone.

Prawdę mówiąc, konkretne obowiązki DevOpsa nie są sztywno wyznaczone. Każda firma może definiować je po swojemu – i tak zazwyczaj jest. Jako konsultant chmurowy miałem styczność z różnymi firmami i obowiązki DevOpsów były różne. Częściowo się pokrywały. Dużo zależy od technologii, wielkości firmy i narzędzi, jakich się używa. Większe firmy mają inne potrzeby i inne wymagania niż mniejsze.

Jeśli chodzi o obowiązki architekta, to tu także nie ma jasno określonych kryteriów. Większość architektów, z którymi rozmawiałem, prowadzi rozmowy z klientami i ma dużą wiedzę techniczną: musi zaprojektować cały system w oparciu o wytyczne i wymagania. Wybór architektury, technologii i każdego pojedynczego składnika nie jest zawsze taki prosty i oczywisty.

O ile naprawa błędu developera może kosztować kilka dni pracy, o tyle naprawa błędu architekta może kosztować już miesiące pracy. Dlatego często tworzone są tak zwane decision logi, w których opisuje się kilka sposobów rozwiązania problemu. Przy każdym sposobie wypisuje się plusy i minusy danego rozwiązania. Każdy członek zespołu może dodać także coś od siebie i wyrazić swoją opinię: jaki sposób rozwiązania problemu jest według niego najlepszy. Decision logi pomagają nam po pewnym czasie zrozumieć, dlaczego wybraliśmy tę drogę, a nie inną. Nawet gdyby całkowicie się zmienił skład zespołu, to ludzie są w stanie zrozumieć, dlaczego takie, a nie inne decyzje zostały podjęte.

Z praktyki wiem, że DevOpsi często uczestniczą w spotkaniach razem z architektami, ponieważ się od nich uczą. Dużo architektów, których znam, było wcześniej DevOpsami. No właśnie. Nie wiem, czy Ty też tak masz, ale ja często spotykałem architektów, którzy wcześniej byli DevOpsami.

Akurat na tym polu nie mam zbyt dużego doświadczenia, bo prowadząc własną firmę, nie miałem kontaktu z wieloma osobami, ale faktycznie wydaje się to dość naturalne, bo jeśli uczestniczą w całym procesie, to go poznają. W ten sposób to ich naturalna ścieżka rozwoju. W zasadzie to podobnie jak z programistami, ale o ten temat pewnie jeszcze zahaczymy.

Architekt według mnie to taka rola, gdzie próg wejścia jest bardzo wysoki. O ile spotykam juniorów DevOpsów z małą wiedzą i doświadczeniem (często im pomagam, byłem kilka razy mentorem i miałem swoich mentee, dlatego jestem na bieżąco), o tyle nie przypominam sobie, bym miał kontakt z architektem juniorem albo po prostu jakimś architektem z małą wiedzą. Ja wiem, że pewnie w różnych firmach różnie to bywa, ale dla mnie architekt nawet na początku swojej drogi musi mieć naprawdę dużą wiedzę. Co Ty o tym myślisz? Wiesz, skąd biorą się ci architekci?

To chyba, tak jak wspomniałem przed chwilą, też spotkałem się z tym, że architekci to po prostu programiści, którzy już są na poziomie seniora czy mida, i to jest ich kolejny etap rozwoju. Może nie ma junior architektów, bo tak jak wspomniałeś: ich błąd powoduje, że trzeba nadrobić to w parę miesięcy. Żadna firma nie chce sobie pozwolić, by projekt był do tyłu o taki czas. Dlatego awansują oni pewnie spośród osób z danego zespołu, co powoduje, że ta ścieżka jest bardziej naturalna.

Może jest też tak, że bardziej doświadczeni architekci idą do innej firmy, ale ta ich wiedza zostaje w dokumentacji, o której wspomniałeś, a rolę jego przejmuje osoba z zespołu. W ten sposób ta wiedza cały czas jest utrzymywana, a dodatkowa wiedza i informacje są zbierane przez tę osobę z zespołu.

Chyba dlatego tak to wygląda. Muszę przyznać, że nigdzie nie widziałem, nie słyszałem, by było coś na zasadzie junior architekta. Po prostu jest architekt.

Zgadza się.

 

Czy DevOps engineer współpracuje też bezpośrednio z klientami firmy?

No i tutaj najlepszą odpowiedzią jest: to zależy – od wielkości firmy, projektu i masy innych rzeczy.

Na pewno nie można nikogo do niczego zmusić. To, że jest się DevOpsem, nie przesądza o tym, czy będzie się miało kontakt z klientem, czy nie. Znam osoby, które już długo są DevOpsami i wcale nie miały kontaktu z klientem, oraz takich ludzi, dla których kontakt z klientem to codzienność. DevOpsi, którzy posiadają wiedzę ekspercką i doświadczenie, na pewno przydają się przy rozmowach z klientem.

DevOpsi, czy wcześniej wspomniani architekci, mogą być także tylko tymczasowym uzupełnieniem zespołu klienta. Nie każdego stać przecież na to, by na stałe utrzymywać zespół specjalistów. Czasem tego typu ludzi potrzeba tylko w niektórych fazach projektu.

Tak prawdę mówiąc, to większość DevOpsów, których znam, interesuje budowa projektu, a nie jego utrzymywanie. Lubią tworzyć coś od podstaw, a utrzymanie zostawić klientowi. Ludzie, którzy uczestniczyli w kilku takich projektach, szybko nabywają doświadczenie. Wiedzą z praktyki, co działa, co się sprawdza, jak można coś zaimplementować. Znają dobre praktyki i umieją ich używać. Nowe projekty to nowe wyzwania, ale udział w wielu projektach sprawia, że zdobywamy bardzo cenne doświadczenie: wiedzę, której nie da się zdobyć, pracując cały czas w jednej firmie, nad jednym projektem i robiąc wciąż to samo. Co Ty o tym sądzisz? Masz podobne zdanie, czy z Twojej perspektywy wygląda to inaczej?

Myślę, że to jest bardzo podobnie jak z programistami. Wszyscy lubią budować nowe rzeczy, rozwijać się i zdobywać doświadczenie, ale niewiele osób chce tkwić w danym projekcie latami. Pewnie dlatego tak często następuje ta zmiana w branży IT – ludzie przechodzą z jednej firmy do drugiej niekoniecznie przez wzgląd na zarobki, ale przez to, że chcą kolejnych wyzwań. A jak siedzi się cały czas w tym samym projekcie, to niestety zazwyczaj na pewnym poziomie te zadania są bardzo podobne i nie wszyscy chcą to robić. To chyba taka natura – tak bym to podsumował.

 

Jaka jest rola DevOpsa na różnych etapach wytwarzania oprogramowania? Powiedzmy: od pierwszych ustaleń z klientem po utrzymywanie aplikacji.

Każdy pewnie kojarzy taki symbol nieskończoności, taką przewróconą ósemkę z wpisanymi w środku fazami. Mówi ona o tym, że projekt wciąż przechodzi z jednego etapu do następnego i może nigdy nie mieć końca, być cały czas rozwijany. Na początku jest planowanie, budowanie, testowanie tworzonych rzeczy, wdrażanie zmian, utrzymanie, monitorowanie tego, co stworzyliśmy, i znowu: planowanie kolejnych rzeczy. Z tym że te etapy różnie się nazywa – chodzi bardziej o to, by zachować sens, a nie spierać się o nazewnictwo.

Metodologia DevOps pomaga tak naprawdę od pierwszego kontaktu z klientem, nastawia nas na częstszy kontakt, na współpracę. Przypomina o tym, że wspólnie tworzymy produkt. Zaangażowanie ze strony klienta także jest ważne, aby upewnić się, czy idziemy w dobrym kierunku.

Podczas tworzenia i testowania oprogramowania duży nacisk jest kładziony nie tylko na ścisłą współpracę wszystkich działów, ale także na automatyzację powtarzalnych czynności. Nie chodzi o to, by wszystko robić szybko. Czasem dobrze jest zatrzymać się na chwilę i zastanowić nad tym, co robimy: czy ma to sens i czy da się to jakoś usprawnić. Czasem 5 minut dodatkowej pracy w jednym zespole może innemu zespołowi zaoszczędzić godzin albo nawet dni monotonnej pracy. Dobrze jest patrzeć szerzej, myśleć nie tylko o tym, co mogę usprawnić u siebie, ale także o tym, co mogę zrobić dla innych, ogólnie dla projektu. To jest ta zmiana sposobu myślenia. To tak w skrócie o podejściu.

Rola DevOps engineera natomiast może być także wykorzystana przy pierwszych kontaktach z klientem. Choć przy rozmowach z klientem bardziej się przydają wspomniani wcześniej architekci, to DevOpsi znający się na swojej pracy też są mile widziani. Pomagają oni stworzyć wstępny plan, mogą doradzać, jakich narzędzi warto używać, znają dobre praktyki z doświadczenia, wiedzą, co się sprawdza, a co nie. DevOpsi, jakby to powiedzieć, częściej dotykają kodu, bo to oni są odpowiedzialni za zbudowanie środowiska, które projektują architekci. Taka praktyczna wiedza jest niezwykle cenna.

Wracając do DevOpsów: odgrywają oni bardzo ważną rolę w procesie automatyzacji, tworzenia oprogramowania, jego testowania i wdrażania. Chodzi mi tutaj o takie bardzo znane hasła, które są zawsze kojarzone z DevOpsami, jak magiczna automatyzacja, czyli Continuous Integration (CI), Continuous Testing (CT) i Continuous Delivery (CD), Continuous Deployment (CD) itd.

DevOpsi, jak już wspomniałem, raczej niechętnie zajmują się utrzymaniem, chociaż.. chociaż to zależy. Zawsze można coś usprawnić. Niektóre projekty cały czas ewoluują, zmieniają się, są budowane nowe funkcjonalności – więc cały czas coś się dzieje. Mam wrażenie, że w świecie IT nie da się zatrzymać. Albo firma się rozwija, albo upada. Wracając do DevOpsów: czasem jest to ewolucja, bo firma się zmienia i zmieniają się obowiązki pracowników, a ludzie po prostu muszą się dostosować. Tak to już jest, że w świecie IT cały czas musisz się czegoś uczyć. Mam wrażenie, że teraz ludzie częściej zmieniają pracę. Dużo ludzi szuka nowych wyzwań i projektów i coraz mniej jest takich, którzy pracują 5, 10 czy 15 lat w jednej firmie. Też to zauważyłeś, czy niespecjalnie?

Zdecydowanie tak. Jak mówiliśmy wcześniej: tak to wygląda, że wolimy wyzwania, wolimy, by coś się zmieniało. Często rekruterzy pomagają nam w zmianie pracy, bo proponują nam coraz to lepsze warunki, więc że tak powiem: dajemy się skusić. Ale dzięki temu bardzo się rozwijamy.

Jeśli jesteśmy w jednej firmie, to często niestety możemy mniej robić, bo wiele rzeczy robi się „automatycznie” – mam na myśli to, że pewne rzeczy powtarzamy, a nie, że mamy stworzone automatyzacje.

 

Dobrze, przejdźmy dalej. Czy Agile ma coś wspólnego z DevOpsem? Jak tak opowiadałeś, to wydawało mi się to bardzo podobne. Jak to wygląda z Twojej perspektywy?

Agile i DevOps różnią się od siebie, ale wzajemnie się nie wykluczają.

Agile, czyli zwinne podejście do zarządzania projektami i tworzenia oprogramowania, pomaga zespołom szybciej dostarczać wartość klientom. Zamiast tworzyć jedno wielkie wdrożenie, zespoły Agile dostarczają pracę w niewielkich, ale użytecznych częściach.

Tradycyjne kaskadowe podejście do zarządzania projektami, tzw. Waterfall, wymuszało bardzo długi czas oczekiwania na gotowy produkt. Założenie było takie, że gdy jeden zespół zakończył pracę, to przekazywał ją innemu zespołowi. Wszystko odbywało się wtedy według wcześniej ustalonego harmonogramu. Niestety często zmieniające się warunki i założenia powodowały wydłużenie czasu realizacji i drastycznie zwiększały koszty niektórych projektów. Doprowadzało to do zamykania projektów, zanim zostały ukończone.

Odpowiedzią na te problemy było właśnie zwinne podejście do zarządzania projektami. Metodykę Agile można w skrócie opisać jako podejście, którego celem jest utrzymanie produktywności i dostarczanie wersji w warunkach stale zmieniających się potrzeb.

To nie jest tak, że Waterfall nigdzie się nie sprawdza – bo tak nie jest. Każde podejście ma swoje plus i minusy. Waterfall sprawdza się tam, gdzie wymagania pozostają stałe, gdzie nie wprowadza się zmian albo wprowadza się ich mało, ponieważ wprowadzanie zmian jest bardzo kosztowne. OK, czyli gdzie się może sprawdzić? Na przykład przy produkcji samochodu albo jakiejś innej linii produkcyjnej. Jak wspomniałem wcześniej: tam, gdzie wstępne założenia się nie zmieniają.

Świat IT bardzo szybko się zmienia. Sposób myślenia w metodyce Agile trochę się do tego dostosowuje, polega na szybkim reagowaniu na błędy, jest skoncentrowany na elastyczności i dostosowywaniu się do potrzeb i oczekiwań klienta, a nie na realizacji sztywno wytyczonych planów. Czyli, bardzo upraszczając, jest to szybkie reagowanie na zmiany.

Dla mnie jest to takie logiczne podejście do rozwiązywania problemów, które zostało opisane. Czyli takie nastawienie, by pracować lepiej, bardziej efektywnie, nastawienie na stały rozwój i równoczesne ograniczanie ryzyka przez otrzymywanie feedbacku i upewnianie się, czy aby na pewno podążamy w dobrym kierunku. Przynajmniej ja to tak rozumiem.

Jeśli ktoś chciałby się dowiedzieć więcej o Agile, to w 2001 powstał Manifest Agile (manifest zwinnego wytwarzania oprogramowania), czyli deklaracja wspólnych zasad dla zwinnych metod tworzenia oprogramowania. Nie chciałbym się teraz w to zagłębiać, bo mogłoby nam dnia zabraknąć. Ważne, że coś takiego jest i jeśli ktoś chciałby zgłębić temat Agile, to powinien od tego zacząć. Tutaj mogę też polecić chyba jeden z odcinków Twojego podcastu, w którym bardziej skupiłeś się na Scrumie i zwinnym podejściu.

Zdecydowanie tak. To był jeden z poprzednich odcinków, więc zapraszamy, jeśli kogoś ten temat zainteresował.

Jeśli chodzi o podejście do klienta, to Agile nastawia się na częsty kontakt z klientem i na dostarczaniu mu wartości. Czyli klient z każdym spotkaniem widzi wykonaną pracę: co 2-3 tygodnie widzi postęp i otrzymuje coś wartościowego. Istotne jest to, że ma on zawsze wpływ na to, co się dzieje, i na każdym etapie ma wpływ na produkt, który dostarczamy. Dzięki temu ta współpraca idzie dobrze. Klient chętnie współpracuje, mówi o tym, czego potrzebuje. W gruncie rzeczy może się okazać, że końcowy produkt będzie inny od tego, o którym rozmawialiśmy na początku, ale klient będzie szczęśliwy, bo otrzyma to, czego naprawdę potrzebuje.

Zespoły pracujące zwinnie zazwyczaj realizują mniejsze zadania, które potrafią szybciej skończyć. Zwiększa się przejrzystość tego, co ktoś realizuje, na jakim jest etapie, i zmniejsza się liczba pracy w toku – takich rozpoczętych zadań, ale niezakończonych. Widzimy dokładnie, co nas blokuje, i możemy szybko na to reagować.

Zarówno DevOps, jak i Agile umożliwiają przyspieszenie dostarczenia końcowego produktu. Co ważne, nie musisz wybierać pomiędzy DevOps a Agile – możesz korzystać z obu. Możesz pracować w metodologii DevOps i wybrać to, czego jeszcze potrzebujesz. Na przykład Scrum jest przydatny do śledzenia zaplanowanych prac, takich jak aktualizacje, migracje itp. Czasem występują nieprzewidziane sytuacje, jak naruszenie bezpieczeństwa, i to raczej nie może czekać sobie w backlogu na kolejną sesję planowania, więc lepiej się sprawdzi metodyka Kanban. Zespoły do pracy używają czasem hybrydy różnych metod – po prostu tego, co się sprawdza.

Silną stroną metodyki Agile jest organizowanie pracy, jak wspomniałem wcześniej, na przykład za pomocą narzędzi Scrum i Kanban. Z kolei metodyka DevOps ma większy zasięg i umożliwia dostarczanie oprogramowania szybciej i w bardziej niezawodny sposób. Kładzie duży nacisk na automatyzację procesów oraz na szybkie dostarczanie informacji zwrotnej.

Jak tak opowiadałeś o tych różnicach, to pomyślałem sobie, że te dwa elementy to po prostu inna warstwa abstrakcji, trochę jak warstwa w sieciach. Tak mi się skojarzyło. Potwierdzisz?

Tak, myślę, że chyba można. Na pewno taki sposób patrzenia ułatwia używanie obu metodyk.

 

Jakie największe wyzwania stoją przed zespołem, który chce wdrożyć DevOps?

Uf, OK, no to na początku powiem, że nie ma jednej uniwersalnej metody i ścieżki wdrożenia DevOps. Dla każdej organizacji jest to bardzo indywidualna sprawa. Każda organizacja i każdy zespół może mieć inny punkt startowy i inne problemy do pokonania. Dobrze jest na początku zrobić jakiś plan, w którym wyznaczymy różne zadania i będziemy wiedzieć, co i kiedy ma się wydarzyć.

Skoro jest to zmiana, to wszyscy w firmie powinni rozumieć, dlaczego ma ona zostać wprowadzona. Często niestety występuje problem z komunikacją albo z jej brakiem. O zmianach powinni wiedzieć wszyscy pracownicy. Nie tylko o tym, jak wspomniałem, że będą zmiany, ale przede wszystkim, dlaczego one będą. Trudności mogą wynikać tutaj ze skostniałych struktur organizacji i naturalnej niechęci do wprowadzania zmian.

Chodzi o rozwijanie kultury wspólnej odpowiedzialności, przejrzystości i szybszego przekazywania informacji zwrotnych. Technologia to tylko narzędzie, ale zmiana musi zacząć się od ludzi.

Skoro mówimy o narzędziach, to organizacja czasem skupia się na technologii, chce szybko wdrożyć DevOps i inwestuje duże środki w najnowsze technologie, a później ich nie używa albo nie wykorzystuje w pełni ich potencjału.

Często istnieje jasny podział na zespół developerów (tworzących rozwiązania) i zespół administratorów (odpowiedzialnych za utrzymanie i infrastrukturę). Niestety te dwa zespoły mają zupełnie inne cele i często obwiniają się za występujące błędy czy awarie. Programistom zależy na szybszym wprowadzaniu zmian, a zespołom utrzymaniowym na stabilności środowiska. Przekonanie ich do wspólnej pracy może nie być takie proste.

W kulturze DevOps oba zespoły pracują razem i mają wspólny cel oraz co ważne: obszar odpowiedzialności. Muszą być częścią procesów, które wcześniej ich nie dotyczyły.

 

Jakie błędy są najczęściej popełniane, gdy zespół przestawia się na pracę w duchu DevOps?

Nie wiem czy najczęściej, ale mogę powiedzieć o tych, z którymi ja się spotkałem, pracując jako konsultant chmurowy.

Ludzie myślą, że automatyzacja wszystko załatwi. Owszem, kluczową częścią DevOps jest automatyzacja. Dla niektórych to właśnie jest najważniejsza korzyść z przejścia na DevOps, ale powinniśmy zrobić o wiele więcej. Automatyzacja nie poprawi komunikacji między zespołami i nie pokona wzajemnej niechęci. Dlatego należy traktować automatyzację jako część DevOps, a nie jako całą metodologię.

Przejdźmy dalej. Niektórzy entuzjaści DevOps podchodzą zbyt rygorystycznie do wdrażania metodologii DevOps i chcą robić wszystko z aptekarską dokładnością, ściśle według listy, a wszelki opór chcą złamać. W praktyce jednak reguły DevOps należy traktować bardziej jako wytyczne, a nie dekalog, którego trzeba się bezwzględnie trzymać. Jak wspomniałem, każda organizacja jest unikalna. Kultura, technologia i procesy są inne w każdej firmie i trzeba to brać pod uwagę przy wprowadzaniu DevOps.

Czasem ludzie zbyt dużo oczekują od DevOps. Myślą, że to lek na całe zło i że wszystkie ich problemy nagle znikną, że pracownicy będą szczęśliwi, wzrośnie sprzedaż, spadną koszty, a błędy w ogóle nie będą występować. Niestety trochę się rozczarują. Trzeba w tej kwestii pozostać realistą. Nie ma idealnych rozwiązań.

Wróciłbym jeszcze do tematu dobrej komunikacji między działami. Każda firma ma już wdrożone jakieś sposoby komunikacji między działami. Tutaj warto się zastanowić – bo może jeśli coś działa, to nie warto tego zmieniać i przyjmować reguł komunikacji stosowanych przez kogoś innego. Może lepiej będzie wykorzystać standardy komunikacji już stosowane w organizacji.

Proces wdrażania DevOps jest dość delikatny – mówimy tu często o zmianie podejścia i sposobu myślenia. Dobrze jest słuchać opinii pracowników. Nie powinniśmy skupiać się tutaj ściśle na małym obszarze, w którym dokonujemy zmian, ale popatrzeć szerzej, zwrócić uwagę na to, jaki skutek nasze zmiany mają na całą organizację.

 

Jakie narzędzia pomagają w implementacji DevOps? Pewnie jest ich dużo i nie będziemy omawiać wszystkich, ale powiedz nam, proszę, jak dla laików: od czego zacząć, co to są za narzędzia, co robią.

No właśnie, jak już wspomniałeś: jest ich bardzo dużo i na pewno nie zdążymy ich omówić, bo by nam dnia nie wystarczyło.

Gdyby się nad tym zastanowić, to jest mnóstwo narzędzi do samej automatyzacji, które robią podobne rzeczy. Kolega rok temu napisał artykuł o poszukiwaniu najlepszego narzędzia do CI/CD. Zrobił porządną tabelkę, wymienił w niej chyba 24 narzędzia – od Jenkinsa, GitLaba, po TeamCity, Argo czy Fluxa. Łącznie, jeśli dobrze pamiętam, 24 narzędzia – i to nie były wszystkie dostępne na rynku, tylko te bardziej popularne. Przy każdym napisał plusy i minusy: takie krótkie podsumowanie, do czego jest dobrze używać konkretnego narzędzia.

Możemy zauważyć, że jedne narzędzia są lepsze dla zespołów, które chcą budować bardzo szybko i mieć dobrą integrację z GitHubem czy Kubernetesem, inne dla zespołów, które już używają konkretnej chmury. No bo właśnie: jedne rozwiązania są chmurowe, inne nie. Jedne integruje się łatwiej, a drugie trudniej. Są darmowe opensource’owe rozwiązania i te płatne, które swoje potrafią już kosztować. Dodatkowo narzędzia te potrafią być prawdziwymi kombajnami, mieć bardzo, bardzo dużo modułów albo mieć tylko kilka konkretnych funkcjonalności, a o resztę musimy zatroszczyć się sami. Wszystko zależy od tego, czego potrzebujemy. Ja nie chciałbym tutaj przechodzić przez wszystkie narzędzia DevOps, tylko troszkę jakby je sklasyfikować, bo inaczej, jak wspominałem, dnia nam nie wystarczy.

Na pewno przyda się więc znajomość systemu kontroli wersji, na przykład Git; ogólnie mówiąc, narzędzi CI/CD (ciągłej integracji i dostarczania), o których wcześniej wspomniałem, jak na przykład GitLab, GitHub, CircleCI czy Jenkins; narzędzi do automatyzacji, jak Ansible, Chef czy Puppet. Dobrze znać narzędzia z zakresu Infrastructure as Code, na przykład mój ulubiony Terraform. Dobrze mieć narzędzie do przeprowadzania testów (SonarQube), robienia audytów, szukania podatności; i jeszcze mnóstwo, mnóstwo innych.

A, zapomniałbym – trzeba pamiętać też o monitoringu, sprawdzeniu, czy wszystko działa. Tu pomoże na przykład Nagios, Zabbix, Grafana, Datadog i wiele, wiele innych. Otrzymywanie informacji zwrotnej jest bardzo ważne. Gdy się coś zepsuje, to na pewno chcielibyśmy o tym wiedzieć.

Ja lubię chmurę i ona też oferuje całą paletę narzędzi do wyboru dla DevOps. Każda chmura ma swoje wbudowane narzędzia, które tak naprawdę działają podobnie. Czy warto ich używać, czy się sprawdzą – to oczywiście zależy głównie od naszych potrzeb i wymagań.

Ogólnie, gdy masz do wykonania jakieś powtarzalne zadanie, to za każdym razem powinieneś zbadać możliwość jego zautomatyzowania. Wprowadzenie procesu automatyzacji (a tym bardziej jego prawidłowy wybór) nie jest proste, ale zaoszczędzi to wiele czasu i pozwoli skoncentrować się na innych, mniej rutynowych zadaniach.

DevOps opiera się na dobrej komunikacji, więc zespół powinien się także dobrze komunikować. W czasach często spotykanej pracy zdalnej sprawdza się Slack, Teamsy czy co kto woli. Ważne, żeby było skuteczne.

Komunikacja powinna dotyczyć także przekazywania wiedzy. Dobrze jest mieć jakąś bazę wiedzy, dokumentację i ją gdzieś trzymać, na przykład w Confluence, na GitHubie, gdziekolwiek – ważne, żeby ją aktualizować.

Zarządzanie projektami i zespołami może być wspierane także przez różne narzędzia, na przykład popularną Jirę.

Narzędzi jest bardzo dużo, cały dzień moglibyśmy o nich rozmawiać i podejrzewam, że jeszcze czasu by nam brakło. Dążę do tego, że nikt nie używa wszystkich i naprawdę nie trzeba znać wszystkich narzędzi. Zazwyczaj ludzie wchodzący do świata DevOps skupiają się na tych najbardziej popularnych. Większość z tych narzędzi jest bardzo intuicyjna i próg wejścia, zrozumienia nie jest taki duży, a gdy popracuje się z jednym narzędziem dłużej, to poznaje się jego tajniki i oczywiście także łatwiej zrozumieć inne narzędzia. Według mnie ważne jest, żeby znać zasadę działania czegoś. Ja nigdy nie uczyłem się regułek, chciałem zawsze zrozumieć, jak coś działa. Mnie to bardzo pomaga w pracy.

Dobrze, że powiedziałeś to ostatnie zdanie, bo jak tak zacząłeś opowiadać o tych wszystkich rzeczach, to zgubiłem się w połowie, a jak pomyślałem, że miałbym się ich nauczyć, to bym się załamał.

 

Podsumujmy: jak zacząć przygodę z DevOpsem? Od jakich umiejętności powinniśmy zacząć? Czy jest jakaś sprawdzona ścieżka dla DevOpsa, np. zaczynamy od administracji serwerami? Może to nam trochę uprości, bo myślę, że ta poprzednia wypowiedź trochę nas przeraziła.

Nieźle trafiłeś z tą administracją serwerami, bo ja zaczynałem jako admin. Jednak nie uważam tego za jedyną słuszną drogę. Nawet powiem Ci, że większość moich znajomych została DevOpsami, będąc wcześniej programistami. Zarówno jedna, jak i druga grupa osób ma przydatne cechy w pracy jako DevOps. Zarówno dla jednych, jak i dla drugich znajdzie się miejsce. Myślę, że nie ma sprawdzonej ścieżki.

Jeśli chcesz być DevOpsem, to nieważne, z jakiego punktu zaczynasz. Ważne, żebyś zaczął i coś zrobił w tym kierunku, był konsekwentny, uczył się kolejnych przydatnych w pracy rzeczy. Według mnie DevOps engineer musi cały czas się dokształcać i być na bieżąco. Wymaga to oczywiście dużo pracy. Trzeba to lubić. Ja, będąc entuzjastą chmury, powiedziałbym, że warto inwestować swój czas w poznanie chmury. Jednak może nie jestem w tym temacie obiektywny, ale takie jest moje zdanie.

Każdy tak naprawdę powinien wybrać swoją ścieżkę. Jest przecież wiele dróg do tego samego celu. Najgorsze według mnie jest chyba zmuszanie się do czegoś, czego się nie lubi. Najlepiej uczyć się przez praktykę. Dobrze jest znaleźć sobie mentora, taką osobę, która już jest DevOpsem i może nas odpowiednio pokierować. Przy wyborze mentora trzeba pamiętać, żeby ta osoba nie tylko miała wiedzę, ale jeszcze umiała ją przekazać. Trzeba tutaj pamiętać, że mentor nie zrobi wszystkiego za nas, on raczej wskaże nam kierunek.

Często obowiązki DevOpsa zmieniają się w zależności od firmy i ścieżki kariery, jaką się wybierze, więc nie jest to takie proste. Jednak są takie rzeczy, które każdy powinien znać albo wiedzieć, jak działają. Tutaj jest właśnie rola mentora, by nam je wskazać, również odpowiednio nas zmotywować do pracy i sprawdzać nasze postępy. Dobry mentor dostosuje poziom nauki do nas, nie przytłoczy nas ogromem wiedzy, ale też nie sprawi, że będziemy się nudzili albo uczyli się niepotrzebnych rzeczy.

Mówiąc o konkretach: przyda się znajomość systemu kontroli wersji, na przykład Git – w sieci jest bardzo dużo bezpłatnych tutoriali na ten temat.

Nie musisz wiedzieć, jak działa każde narzędzie CI/CD, ale fajnie, jak znasz zasadę działania. To samo dotyczy chmury: gdy poznasz jedną chmurę, to łatwo jest zrozumieć kolejną – przynajmniej ja tak miałem, tak to działa u mnie. Znajomość jednego narzędzia pomogła mi szybko zacząć pracę z innym.

Na późniejszym etapie pewnie przyda się umiejętność budowania infrastruktury z kodu. Tutaj chyba najbardziej uniwersalny jest Terraform, ale najpierw trzeba zbudować solidne podstawy.

Gdy już przeszliśmy do infrastruktury, to fajnie, gdy wiesz, jak te klocki są połączone. Może jestem tutaj mało obiektywny, bo ja zanim poszedłem na studia, to już tworzyłem proste sieci komputerowe, ale tak czy inaczej fajnie, gdy znasz podstawowe elementy.

Na sam koniec chciałbym jeszcze wspomnieć o umiejętnościach miękkich, które są równie ważne. Każdy powinien posiadać umiejętność pracy w zespole. W pracy DevOpsa kontakt z innymi ludźmi i zespołami jest niezbędny. Warto więc doskonalić umiejętności pomagające w rozwiązywaniu problemów i komunikacji z innymi, przekazywanie feedbacku itp.

Kolejną umiejętnością jest język angielski. Większość dokumentacji jest w nim pisana, to samo dotyczy tutoriali, poradników i wspomnianej wcześniej komunikacji. Ja na co dzień także kontaktuję się z zespołem w języku angielskim. Rozmowy po polsku też się odbywają, ale tylko gdy wszyscy obecni mówią w tym języku. Pracowałem z ludźmi z wielu krajów i zawsze wspólnym językiem komunikacji był właśnie angielski. W większości firm wymagana jest chociażby jego podstawowa znajomość.

 

To jeszcze dopytam: wspomnieliśmy o programistach, o administratorach – że oni stają się DevOpsami. A czy jesteśmy w stanie jednoznacznie powiedzieć, czy osoby spoza branży IT są w stanie wystartować jako junior DevOps? Myślisz, że jest to możliwe, czy raczej musi być to osoba, która już wywodzi się z branży IT?

Myślę, że jest to możliwe. Oczywiście, taka osoba będzie miała inną drogę, inny próg startowy i będzie musiała się nauczyć innych rzeczy, ale ja osobiście uważam, że jest to możliwe. Nawet spotkałem kilka takich osób, które bez podstawowej wiedzy informatycznej, z zupełnie innej dziedziny, nagle stwierdziły „ja chcę być DevOpsem”.

OK, czyli można.

„Dobrze płacą, ja chcę być DevOpsem”. No i są.

No dobrze, czyli wiemy, że można. Wystarczy chcieć.

 

Jaką książkę polecisz osobom, które chcą zostać DevOpsami?

Niestety zmartwię Cię: nic konkretnego nie polecę, nic mi nie przychodzi na myśl, jeśli chodzi o DevOps. Ostatnio czytam głównie książki związane z rozwojem osobistym, finansami, budowaniem firmy itp.

Mam wrażenie, że książki związane z IT szybko się dezaktualizują. Mam sporo książek dotyczących DevOps, chmury, Kubernetesa itp., ale już w chwili wydania nie wszystkie informacje w nich były aktualne. Dlatego przestałem je kupować. Czasem jednak dostaję różne publikacje za darmo z różnych eventów itp. Jeśli ktoś koniecznie chce czytać książki, to polecałbym czytanie o podejściu, dobrych praktykach, o tym, jak były realizowane projekty. Z tego można się sporo nauczyć.

Jeśli chodzi o branżę IT, to wolę wiedzę, która jest dostępna online, bo jest ona na bieżąco aktualizowana. Dobrze jest też bywać na różnych konferencjach. Jest masa darmowych konferencji i naprawdę wcale nie musisz mieć jakiejkolwiek wiedzy, by tam iść. Zazwyczaj są określone poziomy i jest mnóstwo wystąpień dla początkujących – tych co dopiero zaczynają.

Jeśli miałbym koniecznie polecić jakąś książkę, to może coś od pana Walkiewicza – o życiu. Jedną dałem kiedyś koledze w pracy, jak odchodził po chyba 10 latach. Powiedział mi, że gdyby dostał ją wcześniej, to odszedłby już wcześniej, żeby zmienić swoje życie. Przy okazji – ten kolega aktualnie pracuje jako DevOps.

Może od siebie dodam, że jeśli ktoś nie zna Jacka Walkiewicza, to polecamy jego wystąpienie na TEDx. Myślę, że się zainspirujecie, więc polecam. Często wracam do tego nagrania i myślę, że warto poświęcić te 20 minut, żeby go posłuchać. Czy Ty widziałeś to wystąpienie?

Tak, tak, zdecydowanie. Tak samo: polecam. Oglądałem to już kilka razy i za każdym razem brzmi fajnie.

Polecamy. Taka ciekawostka: to było nagrane chyba w 2010, a ludzie ciągle oglądają, ciągle komentują i ciągle są zadowoleni, więc mamy nadzieję, że przynajmniej parę tysięcy kolejnych wyświetleń będzie właśnie dzięki temu odcinkowi.

Ja właśnie po obejrzeniu tego nagrania kupiłem kilka książek pana Walkiewicza, żeby zgłębić temat, o którym mówił. On ma bardzo fajne podejście, naprawdę ciekawe. Polecam.

Ciekawe. Polecamy.

 

Na koniec: jeżeli mielibyśmy osoby, które chciałyby z Tobą porozmawiać, podpytać o coś, może chciałbyś im wyznaczyć kierunek, w jakim powinny podążać, bo chcą się rozwijać albo w ogóle chcą się zająć tematyką DevOps, to gdzie mogą Cię znaleźć w sieci?

Pewnie na różnych forach internetowych. Można odwiedzić mojego bloga, do czego zachęcam. Mam także kanał na YouTubie – bo czasem łatwiej coś pokazać, niż o tym pisać. No i nie wszyscy lubią czytać blogi, czasem lepiej obejrzeć tutorial i posłuchać.

To może powiedz, jak nazywa się kanał na YouTubie i blog. Oczywiście podlinkujemy, ale dobrze też powiedzieć.

Wpiszecie moje nazwisko (przyp. red. Wojciech Lepczyński) i na pewno znajdziecie.

OK.

Jak ktoś będzie chciał, to na pewno też z łatwością znajdzie mnie na mediach społecznościowych: LinkedInie, Twitterze i tym podobnych. W swoich wypowiedziach skupiam się głównie na temacie chmury, ale od czasu do czasu piszę też coś na inne tematy związane z DevOps, IT, a nawet rozwojem osobistym.

To zapraszamy do odwiedzin i wygooglowania sobie Wojtka. A ja Tobie, Wojtku, bardzo dziękuję za tę naszą dzisiejszą rozmowę i podzielenie się z nami swoim doświadczeniem.

Bardzo dziękuję za zaproszenie, bardzo miło się rozmawiało. Zawsze chętnie dzielę się swoją wiedzą i doświadczeniem. Gdyby ktoś chciał porozmawiać, może śmiało pisać. Łatwo znaleźć mnie w Internecie. Ja chętnie odpiszę, pogadam, wymienię się doświadczeniem na taki czy inny temat.

Super, to zapraszamy. Jeszcze raz: dzięki, Wojtek.

Dzięki, cześć.

Hej.

Słuchaj także na:

Udostępnij ten artykuł:

Mentoring to efektywna nauka pod okiem doświadczonej osoby, która:

  • przekazuje Ci swoją wiedzę i nadzoruje Twoje postępy w zdobywaniu umiejętności,
  • uczy Cię dobrych praktyk i wyłapuje złe nawyki,
  • wspiera Twój rozwój i zwiększa zaangażowanie w naukę.

Mam coś dla Ciebie!

W każdy piątek rozsyłam motywujący do nauki programowania newsletter!

Dodatkowo od razu otrzymasz ode mnie e-book o wartości 39 zł. To ponad 40 stron konkretów o nauce programowania i pracy w IT.

PS Zazwyczaj wysyłam 1-2 wiadomości na tydzień. Nikomu nie będę udostępniał Twojego adresu e-mail.