DevTalk #134 – O DevOps 2025 z Piotrem Zimochem

Zaczynałem jako frontendowiec, potem trochę back-endu, potem trochę architektury, potem trochę managementu. Potem przeszedłem dość mocno w chmurę publiczną, głównie AWSy, ale w międzyczasie pojawiły się i Azure, i GCP, nawet jakiś Oracle gdzieś tam się pojawiał. I tak jakoś naturalnie z tego mojego doświadczenia wyszło, że fajnie się odnajduję i ciekawe mnie tematyki około DevOpsowe. Mówię około DevOpsowe, bo jak pewnie będziemy rozmawiać, DevOps nie ma jednej wspólnej definicji. Więc zarówno trochę tematyka platform engineeringu, troszeczkę SRE, troszeczkę więcej samej takiego observability. Więc jestem aktualnie na styku software'u i infrastruktury.

unit testami. Kiedyś to było zdecydowanie tak. Moje testy przechodzą, czyli takie słynne works on my machine, teraz wy się martwcie. I ta kultura Okazało się, że całkiem fajnie się zaczęła sprawdzać w Google, to Google potem zaczął troszkę się tym chwalić. W międzyczasie oczywiście też się pojawiła cała szkoła SRE, czyli tego Site Reliability Engineeringu, czyli programistów takich, którzy też się zajmują utrzymaniem produkcji, ale takich programistów w trójkości, czyli nie ludzi, którzy się wywodzą bardziej z systemów operacyjnych, tylko takich, którzy rzeczywiście piszą oprogramowanie na potrzeby utrzymania produkcji. Natomiast wracając jeszcze na chwilę do tego samego źródła DevOpsów, to była kultura.

To jest taki system pluginowy, że tych opcji połączeń z chmurą, z systemami wewnętrznymi jest multum. Kolejna działka się pojawiła. Mieliśmy specjalistów devopsów, teraz mamy specjalistów platform inżynierów, jeżeli to w ogóle dobrze spuszczam, inżynierów od platformy. No i mamy też, jak pójdziemy kawałek dalej, mamy już specjalistów też od tego SRE. To już jest kolejny poziom, kawałeczek dalej. A nawet czasami się chodzi jeszcze w głębiej. Czasami jeszcze mamy już specjalistów tylko od observability. I nagle się okazuje, że trzeba mieć kolejnych specjalistów, którzy się zajmują utrzymaniem naszej infrastruktury, która zbiera informacje o aplikacjach, ale i o samej infrastrukturze. I potem jest to znowu gdzieś udostępniane. Ten poziom skomplikowania tych systemów wzrósł bardzo znacznie i to wymaga, to spowodowało powstanie tych niszy takich, że powiem, nie niszy, tych specjalizacji.

Czyli mieliśmy DevOpsów, teraz DevOpsowie z reguły się już dzielą, nie zawsze. W małych firmach DevOps robi teraz platformę, robi SRE, robi observability. W dużych firmach już jest platform engineer, który robi jedno, SRE engineer, który robi drugie. No i jeszcze węższe specjalizacje się pojawiają. Bardzo jest tego dużo. Zaraz Cię oproszę, żebyś to jakoś ustrukturyzował nam na przykład narzędziami, ale to za moment. Wspomniałeś, że są polityki, które, czy jakieś zasady, czy reguły wpisane na GitHubie, jako czy szablony, czy jakiegoś typu reguły, które firma sobie zdefiniowała i to jest przestrzegane przez tę warstwę infrastrukturalną. Czy tam tutaj ma zastosowanie takie pojęcie jak policy as code? Tak, policy as code jak najbardziej jest jednym z małych takich elementów składowych wchodzących w ten cały proces walidacji tego, co próbujesz finalnie uruchomić.

No i się okazało, że się myliłem. Tu poruszyłeś fajną kwestię właśnie tego, kto utrzymuje produkcję, kto finalnie powinien lub jest za to odpowiedzialny w firmach. I znowu tutaj, ile firm, tyle pewnie szkół. Są organizacje typu Google, które są wyspecjalizowane, mają swoje zespoły SRE, które gdzieś tam tą produkcją się zajmują, z możliwością zawsze odezwania się do programistów w ramach takiej trzeciej linii wsparcia. Ale czasami jest tak, że te zespoły on-callowe to tworzą programiści, bo nie każdy może mieć dedykowaną osobę, która będzie tylko siedziała i patrzyła, czy produkcja działa. I taki programista też musi gdzieś zrozumieć, jak ten kod się finalnie dostaje na tę produkcję. Co więcej, też fajny podać przykład, że coś działa i samo przestaje działać.