Jak wytworzyć dobre oprogramowanie – czyli o łączeniu dwóch światów, DevOpsach i triceratopsach
- Processes, standards and quality
- Technologies
- Others
DevOps to idea łączenia i współpracy zespołów produkcji oprogramowania i jego wdrażania oraz zespołów utrzymujących. Gdy jest robiony dobrze, pozwala zwiększyć produktywność i podnieść jakość wytwarzanego oprogramowania. A jak to wygląda w praktyce? O pracy DevOpsów w Future Processing opowiedzieli nam Aleksander Owrew, Adam Brodziak i Jarosław Wachowicz.
Jesteście przedstawicielami linii DevOps w Future Processing. Możecie w skrócie powiedzieć, czym zajmujecie się na co dzień i co najbardziej Wam się podoba w Waszej pracy?
Adam Brodziak, DevOps Architect: W pracy DevOpsa najbardziej podoba mi się to, że każdy dzień to nowe, ciekawe wyzwanie. Mam bardzo szerokie pole działania – dotykam tematów związanych z rozwojem oprogramowania, dostarczaniem go i utrzymywaniem.
Właśnie tego brakowało mi, gdy zajmowałem się samym programowaniem. Pracując jako DevOps mam feedback, którego wcześniej nie otrzymywałem. Dzięki temu wiem, co faktycznie dzieje się na produkcji – jak oprogramowanie się zachowuje, czy działa dobrze, czy pojawiają się błędy. Według mnie to jedna z kluczowych informacji, która pozwala tworzyć dobry soft.
I właśnie o to chodzi w DevOpsie, który jest połączeniem pracy programistycznej i działania na produkcji. Widzimy, jak soft jest tworzony i jak działa. Z tego wynika cała dynamika, która tak bardzo mi się podoba – tutaj zawsze coś się dzieje.
Aleksander Owrew, Senior DevOps Engineer: Mnie najbardziej podoba się to, że mamy styczność praktycznie z każdym aspektem cyklu dostarczania oprogramowania – z kodem, testami, konfiguracją aplikacji, wdrożeniem i jej monitorowaniem. Na każdym poziomie czekają na nas wyzwania i dzięki temu możemy się rozwijać.
Spróbujmy teraz rozwikłać chyba największą zagwozdkę. Mamy niezliczoną ilość publikacji tłumaczących, czym jest (lub czym nie jest) DevOps. Możecie powiedzieć, jak Wy rozumiecie termin DevOps i jak wygląda DevOps w praktyce w Future Processing?
Aleks: Jeśli miałbym podsumować DevOps w jednym zdaniu, to powiedziałbym, że to zbiór dobrych praktyk, które pozwalają osiągnąć większą produktywność – pod warunkiem, że są one wdrożone na etapie produkowania oprogramowania i jego dalszego utrzymania.
Adam: Dokładnie tak. Ten zestaw dobrych praktyk wynika z pewnej filozofii. Bo tak naprawdę nie tworzymy oprogramowania, tylko rozwiązujemy problem naszego klienta, dostarczamy mu wartość. I właśnie z tego wynikają te wszystkie działania, które później nazywane są praktykami DevOps.
Aleks: To nie są tylko techniczne dobre praktyki, ale też dobre praktyki na poziomie kulturowym całej organizacji czy na poziomie współpracy. W DevOps chodzi przede wszystkim o ciągłe doskonalenie zarówno procesu, jak i siebie samego.
Aleks, jesteś Senior DevOps Engineerem. Możesz opowiedzieć, jak wygląda ta rola w Future Processing?
Aleks: Jako Senior DevOps Engineer dostałem od FP dużo zaufania. Mogę działać bardzo swobodnie i właściwie sam organizuję swoją pracę. Określam, jak powinna wyglądać infrastruktura na podstawie wymagań zebranych od klienta, konsultuję możliwe rozwiązania z moimi zespołami i dzielę się swoim doświadczeniem z zakresu budowania i utrzymania systemów czy procesów. Obecnie są to dwa zespoły – w jednym jestem jedynym DevOpsem, w drugim współpracuję z kolegą spoza FP.
Oprócz pracy w zespole działamy też w naszym wewnętrznym community. Regularnie spotykamy się, aby wymienić się doświadczeniami, podyskutować i oczywiście zintegrować się.
Adamie, Ty natomiast jesteś Architektem DevOps, więc to już wyższy poziom wtajemniczenia. Jak wygląda Twoja rola w porównaniu do stanowiska Aleksa?
Adam: Moja praca w dużej mierze opiera na działaniach strategicznych i mentorowaniu innym, dbaniu o ich rozwój – choć nie stronię też od działania w kodzie.
Podobnie jak Aleks, mam dużo swobody. Gdy któryś z inżynierów ma wątpliwości, czy kierunek, który w danym projekcie wybrał, jest dobry, zawsze może przyjść do mnie i razem analizujemy sytuację.
Przykładowo, kilka razy było tak, że Aleks miał zagwozdkę techniczną albo procesową i wtedy rozmawialiśmy, jak ją rozwiązać. Mentoring, który praktykujemy w FP nie działa tylko w jedną stronę. Niedługo ja będę pytał Aleksa, jak zrobił niektóre rzeczy w AWS CDK, czyli Cloud Development Kit, bo to jest z kolei mi potrzebne.
Jeśli jest taka potrzeba, to oczywiście sam też “rozgrzebuję” kod albo rozwiązuję problemy związane np. z serwerami. Jednak zdecydowaną większość czasu spędzam na tym, aby upewnić się, że ludzie, którymi się opiekuję, wiedzą, co robić, znają dobre praktyki, podążają za dobrymi wzorcami i unikają pułapek.
Choć czasami sam pozwalam im popełnić błąd – po to, żeby zobaczyli, dlaczego nie warto tego robić. Oczywiście dzieje się to w bezpiecznym środowisku! 🙂 Taka nauka czasami też jest potrzebna.
Możecie powiedzieć coś więcej o mentoringu? Jak to działa w FP?
Aleks: W FP aktywnie wymieniamy się wiedzą. Jak wspomniałem mamy tutaj całe community, w ramach którego możemy wymieniać się informacjami i szukać pomocy nie tylko wśród “starych wyjadaczy”, ale też naszych stażowych rówieśników.
Adam: W ramach community mamy linię biznesową DevOps, gdzie skupiamy się na rozwoju naszej działki. Obecnie w ramach linii DevOps działa kilkanaście osób – docelowo będzie nas więcej. Naszym głównym celem jest to, żeby propagować wartości DevOps w całej firmie i przez to podwyższać standard oprogramowania, które tworzymy.
Z opisu Waszych stanowisk wynika, że DevOps to nie SysAdmin, choć często bywa to mylone np. w nazwach stanowisk w innych firmach. Jak myślicie, z czego to wynika?
Adam: Wydaje mi się, że to wynika z tego, że teraz na DevOps jest hype. Podobnie było w przypadku Agile 10 lat temu. DevOps znajduje się obecnie w podobnym miejscu. Teraz wszyscy mówią, że robią DevOps – chociaż nie zawsze jest to prawda.
Ponieważ DevOps jest mocno powiązany z infrastrukturą, komputerami i serwerami, często admini nazywani są DevOpsami – bez zmiany stanowiska i obowiązków, bez dodatkowego szkolenia i bez zrozumienia filozofii, o której mówiłem wcześniej. Firmy często piszą, że szukają DevOpsów, a tak naprawdę okazuje się, że chcą zatrudnić inżynierów systemowych albo właśnie adminów. My jako linia DevOps w Future Processing tego nie robimy. Jeśli szukamy osób z doświadczeniem w zarządzaniu infrastrukturą IT, z wiedzą i obyciem w obszarze bardziej operation niż dev, ze znajomością Linuxa, rozwiązań chmurowych oraz narzędzi z zakresu Infrastructure as a Code, to proponujemy inne stanowiska z możliwością rozwoju i zmiany na ścieżkę DevOps.
Jarosław Wachowicz, Head of DevOps: Skoro już bierzemy pod lupę nazwy stanowisk, to warto wspomnieć o tym, że sam DevOps różni się od innych -Opsów. A trochę ich jest – mamy np. CloudOps, DevSecOps, DevSecMLOps… Jak w tym memie z triceratopsem.
O co chodzi z triceratopsem? 🙂
Jarek: Wszystko zaczęło się od mema, który pokazywał rozwój DevOpsa. W ciągu kilku lat narodziło się wiele nazw – od samego Opsa po bardziej złożone kompilacje, które brzmią trochę jak buzzwordy. Śmiejemy się, że kolejnym etapem rozwoju będzie TriceratOps. Ludzie zastanawiają się, co stoi za tymi nazwami i co odróżnia jedną linię od drugiej.
Jak wygląda to u Was w Future Processing? Jak odróżniacie role, stanowiska lub linie biznesowe?
Adam: W FP DevOps skupia się na budowaniu platformy wspierającej zespół developerski. W praktyce oznacza to budowanie infrastruktury, która pozwala łatwo – czyli automatycznie – budować i integrować oprogramowanie oraz dostarczać je na środowiska developerskie, testowe czy produkcyjne.
DevOps odpowiednio przygotowuje te środowiska – uruchamia usługi i systemy oraz konfiguruje je zgodnie z zasadą Infrastructure as Code. IaC jest dla nas bardzo ważne, pozwala utrzymywać infrastrukturę w taki sam sposób jak kod aplikacji, w ramach kontroli wersji. Możemy też tworzyć kopie środowisk lub ich modyfikacje bez “wyklikiwania” wszystkiego za każdym razem. IaC stanowi również dokumentację tego elementu systemu.
Platforma, którą tworzymy, realizuje istotne elementy praktyk DevOps, o których już dzisiaj wspominaliśmy. Pozwala wdrożyć oparte na niej procesy i uzyskać cele takie jak np. czas przygotowania i wdrożenia zmiany poniżej 1 godziny.
Te wszystkie dodatkowe elementy w nazwach NoOps, DevSecOps dotyczą pewnych szczególnych sposobów i podejść do praktyk DevOps. Na przykład Sec dotyczy dobrych praktyk, które zapewniają bezpieczeństwo systemu – z kolei NoOps to podejście dotyczące utrzymania oprogramowania w taki sposób, aby być gotowym na awarie i automatycznie obsłużyć jej wystąpienie, by czynności administracyjne były zautomatyzowane. Dzięki temu (prawie) w ogóle nie ma pracy typu Ops (czyli Operational Support).
My nie dodajemy tych wszystkich skrótów do nazwy DevOps, jednak jak najbardziej stosujemy takie podejście. Nie ma więc obowiązkowego supportu typu “on-call” czy “on-standby”. Aspekty techniczne, o których mówię, są bardzo ważne, ale cały czas musimy pamiętać o tej mniej technicznej stronie DevOpsa – o kulturze i dobrych praktykach, za szerzenie których odpowiadamy w firmie.
Skoro przebrnęliśmy przez terminologię, zahaczyliśmy o dinozaury 😉, to przejdźmy do mięcha: w jakich technologiach pracujecie w obecnych projektach?
Aleks: W samych interesujących. 🙂 Z mojej strony jest to najczęściej praca z infrastrukturą w chmurze, obecnie w AWS i Azure. Aplikacje uruchamiam w zarządzanym klastrze Kubernetesa. W zależności od projektu infrastrukturę opisuję za pomocą CDK lub ARM (w przypadku Azure), a pipeline’y utrzymuję blisko repozytorium – w GitLab i Azure Pipelines. Warto wspomnieć, że jeżeli dana technologia nie jest narzucona wymaganiami, to mamy pełne pole do wyboru takiej, która nam najbardziej odpowiada – oczywiście w ramach zdrowego rozsądku i dobrych praktyk. 🙂
Adam: Z CDK obecnie mamy love-hate relationship.
Co to znaczy? Opowiedz nam nieco więcej o CDK.
Adam: To dobre narzędzie, które ułatwia pracę szczególnie programistom. Dzięki CDK możemy skomplikowaną konfigurację opisać za pomocą kodu – czyli czegoś, z czym programiści pracują na co dzień. To przykład działania, które pomaga zbliżyć nasze dwa światy – świat developmentu i operations. A dlaczego mówię o love-hate relationship? Bo to wspaniałe narzędzie ma swoje mroczne strony – występuje w nim dużo bugów. Sam kilka zgłosiłem, a jeden naprawiłem. Mimo wszystko spełnia swoje zadanie i bardzo ułatwia nam pracę.
Jak wyglądają projekty DevOpsowe w FP?
Aleks: Myślę, że każdy projekt wygląda zupełnie inaczej ze względu na ludzi, którzy przy nim pracują. W zależności od tego, jak doświadczony jest zespół, rola DevOpsa może wyglądać nieco inaczej.
Obecnie pracuję w doświadczonych zespołach, których członkowie znają dobre praktyki tworzenia oprogramowania. Moja praca sprowadza się tam głównie do czysto technicznych zajęć, czyli zbudowania i utrzymywania infrastruktury. Zespoły te są otwarte na sugestie i to do nich ostatecznie należy decyzja, które z praktyk włączyć w proces.
Adam: Naszą główną rolą w projektach jest to, żeby szerzyć dobre praktyki DevOpsowe. Jesteśmy w zespołach po to, żeby wzmacniać wiedzę i stosowanie czterech metryk DORA (DevOps Research & Assessment), które dają nam wymierne korzyści ze stosowania DevOpsa.
Poniekąd pełnimy więc rolę konsultantów. Razem z deweloperami i specjalistami, którzy później będą zajmowali się utrzymaniem systemów, budujemy platformy, dzięki którym zespoły deweloperskie mogą działać efektywnie.
Dobrym przykładem będzie tutaj CDK, o którym wspominałem wcześniej. CDK skomplikowaną konfigurację zamienia w kod. Dzięki temu programiści nie muszą uczyć się trudnych konfiguracji w AWS-ie, bo dostają kod, który znają i rozumieją.
Skąd u Was pomysł na zajęcie się zawodowo obszarem DevOps? Nie woleliście być np. programistami Java lub .NET?
Aleks: Według mnie obszar DevOps dostarcza więcej wyzwań niż programowanie. Zawsze ciągnęło mnie do dodatkowych zadań związanych z dostarczaniem oprogramowania – do deploymentu, utrzymania, konfiguracji itp. Jestem ciekawski, dlatego stawiam na szerszy rozwój. Wolę poznać kawałek każdej technologii niż specjalizować się tylko w jednej.
Adam: U mnie wygląda to bardzo podobnie. Moja przygoda z DevOpsem zaczęła się w 2009 roku – jak jeszcze nie wiedziałem, że to, co robię, ma swoją nazwę. DevOps narodził się w Belgii, a ja w tym czasie pracowałem w Holandii, więc pierwsza fala adopcji DevOps szybko na mnie trafiła.
Byłem też przy narodzinach DevOpsa w FP. Pamiętam moją rozmowę z Head of Technology, podczas której okazało się, że nasze wizje, co do istotności DevOpsa są bardzo spójne. Zauważyliśmy, że najlepsi w branży już to robią, a to oznaczało, że niedługo zaczną robić to również nasi klienci – i zaczną nas pytać o DevOps. I tak się stało.
Duże, ustabilizowane firmy, z którymi pracujemy w FP, wiedzą, czym jest DevOps, rozumieją to podejście i chcą je stosować. Widzą, że DevOps przekłada się na lepsze wyniki. W raportach DORA znajdziemy statystycznie udowodnioną korelację między sukcesami a stosowaniem dobrych praktyk DevOps. A nasi klienci wierzą liczbom.
Czy ścieżka kariery DevOps jest rozwojowa? Jak z Waszej perspektywy wygląda możliwość poszerzania wiedzy i zdobywania doświadczenia projektowego w tym obszarze w FP?
Aleks: Ścieżka DevOps jest bardzo rozwojowa. Na co dzień mamy styczność z wieloma problemami, których rozwiązanie często wymaga od nas nabycia nowych umiejętności.
W FP mamy specjalne programy rozwojowe. Możemy się rozwijać w ramach technologii, które stają się coraz popularniejsze i pożądane przez klientów. Trafiłem do takiego programu, pracując jeszcze w poprzednim zespole. Dostałem określony czas, żeby rozwijać się w kierunku DevOps – otrzymałem pakiet do nauki i wsparcie innych, bardziej doświadczonych DevOpsów.
Adam: Pakiety do samodzielnej nauki są zaprojektowane tak, żeby po ukończeniu kursu móc się jak najszybciej wdrożyć w projekt i zrobić coś użytecznego ze świeżo zdobytą wiedzą. Inna opcja to mentoring, o którym wspominałem wcześniej. Każda nowa osoba, która wchodzi w obszar DevOps, ma przydzielonego mentora i razem ustalamy dalszą ścieżkę rozwoju.
W FP mamy cały dział, który zajmuje się rozwojem i szkoleniami – FPAcademy, z którym oczywiście współpracujemy jako trenerzy. Ostatnio rozmawialiśmy o szkoleniu z Kubernetesa, bo widzimy coraz większą potrzebę szerzenia tej wiedzy nie tylko wśród DevOpsów, ale też developerów. To oddolna inicjatywa wspierana właśnie przez dział FPAcademy.
Czy bycie ekspertem DevOps to tylko umiejętności techniczne? Jakie cechy powinien posiadać według Was dobry inżynier DevOps?
Aleks: Umiejętności techniczne to podstawa. DevOpsem raczej nie zaczyna się być na poziomie juniorskim. Na to stanowisko przechodzą osoby, które mają już doświadczenie techniczne – najczęściej są to developerzy i QA, którzy mieli już styczność z kodem.
Jeżeli chodzi o kompetencje miękkie, to zdecydowanie liczy się tu umiejętność przekazania swojej wizji, przekonania do niej i komunikatywność. Jako DevOps muszę być w stanie przekazać klientowi, o co mi chodzi i przekonać go, że dane rozwiązanie jest dobrym wyborem.
Adam: Umiejętności miękkie to tak naprawdę bardzo konkretny zestaw kompetencji. Umiejętność “sprzedaży” (czy inaczej siła perswazji) jest tu naprawdę ważna. Trzeba też umieć komunikować idee, wartości i to, po co one są. Istotne jest też rozumienie procesów, które dzieją się w firmie – chodzi o procesy wytwarzania oprogramowania, dostarczanie go i utrzymywanie. To wszystko przychodzi z doświadczeniem.
Właśnie dlatego szukamy ludzi, którzy takie doświadczenie mają – takich, którzy nie jedną awarię już widzieli i mogą na ten temat opowiedzieć ciekawe historie.
Na koniec powiedzcie, co najbardziej podoba Wam się w pracy w FP.
Jarek: Zdecydowanie atmosfera. Ja i Adam pracowaliśmy wcześniej w wielu firmach i naprawdę doceniamy atmosferę, jaka tu panuje. To, że szczęście pracowników wpisane jest w misję firmy to nie są puste słowa.
Na ścianie mamy napis “Great software, because we put people first”. Przychodziłem tu z nadzieją, że w przypadku tej firmy – w odróżnieniu od wielu innych – nie jest to pusty frazes. Po 5 latach w FP mogę stwierdzić z całą pewnością, że nadzieje te zostały spełnione.
Adam: Ja jestem pod ogromnym wrażeniem ewolucji, jaka zaszła w FP od momentu, kiedy dołączyłem do zespołu. Z dużego, niezorganizowanego biznesu FP zmieniło się w jeszcze większy, zorganizowany biznes, który zachował swoją kulturę i wartości, które były tu na samym początku.
Jarek: Zarząd bardzo dużo uwagi przykłada do tego, żeby zmiany nie zakłócały podstawowych wartości firmy. Prowadzone są badania – np. doroczne “Happy Team”, które pomaga zmierzyć nasze nastroje i wnikliwie analizujemy jak zmiany wprowadzane w ostatnim okresie na to wpływają, jeśli trzeba zmieniamy kierunek, jeśli potwierdza się, że były dobre, to idziemy dalej. I właśnie to jest niezwykłe – że takie “miękkie” rzeczy, jak szczęście czy unikalna kultura są mierzone za pomocą specjalnych modeli i na tej podstawie odpowiednio pielęgnowane. Takie połączenie serca i rozumu 😊.