Spotkanie z Toshikazu Kawaguchim, autorem „Zanim wystygnie kawa”

Tworzenie aplikacji nie kończy się w chwili napisania ostatniej linii kodu. Program trzeba jeszcze przetestować, uruchomić na odpowiednio przygotowanej infrastrukturze, zabezpieczyć, monitorować i rozwijać bez powodowania niepotrzebnych przerw. DevOps porządkuje wszystkie te działania w jeden spójny proces, w którym programiści, administratorzy, testerzy i specjaliści bezpieczeństwa pracują nad wspólnym celem.
Nie jest to pojedyncza technologia ani stanowisko, które można sprowadzić do obsługi kilku narzędzi. DevOps to sposób organizowania pracy nad oprogramowaniem, oparty na współpracy, automatyzacji i szybkim obiegu informacji. Dzięki niemu zespoły mogą częściej wprowadzać niewielkie zmiany, wcześniej wykrywać problemy i sprawniej reagować na potrzeby użytkowników.
Nazwa DevOps powstała z połączenia słów development, czyli rozwój oprogramowania, oraz operations, oznaczającego jego wdrażanie i utrzymanie. W rzeczywistości jest to zbiór zasad, praktyk i rozwiązań technicznych integrujących ludzi, procesy oraz technologie w całym cyklu życia aplikacji. Obejmuje planowanie, programowanie, testowanie, publikowanie kolejnych wersji, codzienną eksploatację i analizę działania systemu.
W tradycyjnym modelu programiści mogli koncentrować się na dostarczaniu nowych funkcji, a administratorzy na zachowaniu stabilności środowiska. Cele obu grup nie zawsze były zbieżne, pierwsza bowiem dążyła do zmian, druga chciała ograniczać ryzyko. DevOps zmniejsza ten podział, ponieważ zespół wspólnie odpowiada zarówno za tempo rozwoju produktu, jak i za jego jakość, bezpieczeństwo oraz niezawodność.
Zanim przejdziemy do szczegółów, warto wcześniej uporządkować nazewnictwo. Poprawnym i powszechnie przyjętym zapisem jest “DevOps”. W zapytaniach internetowych często pojawia się jednak również forma “devop”, ale najczęściej jest ona skrótem myślowym albo nieprecyzyjnym wariantem tej samej nazwy.
Repozytorium kodu, platforma chmurowa czy system automatyzujący wdrożenia mogą wspierać DevOps, ale same nie zmienią sposobu działania organizacji. Podstawą jest współpraca osób o różnych specjalizacjach, przejrzystość procesu i wspólna odpowiedzialność za rezultat. Dobrze funkcjonujący zespół nie porzuca od razu już gotowej aplikacji, lecz od początku projektuje ją z myślą o uruchomieniu, obserwowaniu i późniejszych zmianach.
Istotne jest także podejście do błędów. Awaria nie powinna prowadzić wyłącznie do poszukiwania winnej osoby. Większą wartość daje ustalenie, dlaczego proces, architektura albo zabezpieczenia pozwoliły problemowi wystąpić, a następnie wprowadzenie usprawnień. Taka kultura sprzyja dzieleniu się wiedzą i ogranicza ryzyko ukrywania czy co gorsza bagatelizowania trudności.
DevOps nie oznacza jednak, że każdy członek zespołu musi umieć wszystko. Programista nadal może specjalizować się w kodzie, administrator w systemach, a ekspert bezpieczeństwa w ochronie danych. Zmienia się przede wszystkim zakres współpracy, specjaliści wcześniej uzgadniają wymagania, korzystają ze wspólnych informacji i razem oceniają skutki wdrożenia.
Cykl DevOps można przedstawić jako powtarzającą się pętlę. Koniec jednego wydania staje się początkiem pracy nad kolejnym, ponieważ dane z działającej aplikacji wracają do zespołu i wpływają na następne decyzje. Wszystko zaczyna się od planowania, gdy zespół określa potrzeby użytkowników, priorytety, zakres zmian i kryteria jakości. Następnie programiści tworzą niewielkie fragmenty kodu, poddają je przeglądowi i zapisują w systemie kontroli wersji. Kolejny etap obejmuje automatyczne budowanie aplikacji oraz testowanie jej poprawności, aby możliwie wcześnie wykryć błędy.
Gotowy pakiet jest następnie dostarczany i wdrażany na kolejne środowiska, na przykład testowe, a później produkcyjne. Po publikacji zespół utrzymuje usługę, dbając o jej dostępność, wydajność, konfigurację i bezpieczeństwo. Równocześnie monitoruje działanie aplikacji za pomocą logów, metryk, alertów i opinii użytkowników. Zebrane w ten sposób informacje zwrotne pomagają wskazać obszary wymagające poprawy i wpływają na decyzje podejmowane podczas następnego cyklu.
Oczywiście przepływ ten nie musi wszędzie wyglądać identycznie. W bankowości część zmian może wymagać formalnej akceptacji, a w niewielkiej usłudze internetowej wdrożenia mogą następować automatycznie wiele razy w ciągu dnia. Kluczowe jest to, aby proces był powtarzalny, możliwy do sprawdzenia i dostosowany do poziomu ryzyka.
Jednym z najważniejszych mechanizmów DevOps jest potok CI/CD. Skrót CI oznacza Continuous Integration, czyli ciągłą integrację. Gdy programista zapisze zmianę w repozytorium, system automatycznie buduje aplikację i uruchamia testy. Zespół szybko otrzymuje informację, czy nowy fragment kodu współpracuje z pozostałymi częściami produktu i czy nie spowodował regresji.
CD może oznaczać ciągłe dostarczanie (Continuous Delivery) albo ciągłe wdrażanie (Continuous Deployment). W pierwszym przypadku każda prawidłowo przetestowana wersja jest gotowa do publikacji, ale decyzję o jej udostępnieniu może podjąć człowiek. W drugim poprawna zmiana trafia na produkcję automatycznie. Są to więc pojęcia bliskie, lecz nie tożsame.
Dobry potok nie polega jedynie na przyspieszeniu publikacji. Ma również zatrzymywać wadliwe zmiany, dokumentować przebieg wdrożenia i umożliwiać szybki powrót do poprzedniej wersji. Automatyzacja działa tu jak system kontroli jakości, a więc wykonuje powtarzalne czynności w ten sam sposób i pozostawia ludziom decyzje wymagające oceny sytuacji.
Choć organizacje dobierają własne rozwiązania, kilka praktyk można tu jednak szczególnie wyróżnić.
Repozytorium powinno obejmować nie tylko kod aplikacji. Można w nim przechowywać również konfigurację, definicje infrastruktury, skrypty wdrożeniowe i zmiany baz danych. Dzięki temu wiadomo, kto i kiedy wprowadził modyfikację, można ją sprawdzić przed połączeniem z główną wersją oraz w razie potrzeby wycofać.
Testy uruchamiane po każdej istotnej zmianie skracają czas między popełnieniem błędu a jego wykryciem. Mogą sprawdzać pojedyncze funkcje, współpracę modułów, interfejs użytkownika, wydajność i podatności bezpieczeństwa. Nie eliminują testów manualnych, ale przejmują dużą część powtarzalnej kontroli.
| Obszar | Przykładowe rozwiązania | Zastosowanie |
| Kontrola wersji | Git, GitHub, GitLab, Bitbucket | Przechowywanie kodu i współpraca nad zmianami |
| CI/CD | GitHub Actions, GitLab CI/CD, Jenkins, Azure Pipelines | Budowanie, testowanie i wdrażanie aplikacji |
| Infrastructure as Code | Terraform, Pulumi, Ansible | Automatyczne tworzenie i konfigurowanie środowisk |
| Monitoring i obserwowalność | Prometheus, Grafana, OpenTelemetry | Zbieranie i analizowanie danych o działaniu systemu |
Infrastructure as Code, czyli infrastruktura jako kod, pozwala opisywać serwery, sieci, bazy danych i inne zasoby w plikach możliwych do wersjonowania. Zamiast ręcznie konfigurować każde środowisko, zespół może tworzyć je na podstawie sprawdzonej definicji. Ułatwia to zachowanie spójności, odtwarzanie systemu i skalowanie usługi.
Monitoring informuje, czy znane parametry systemu mieszczą się w przyjętych granicach. Obserwowalność pomaga natomiast szukać odpowiedzi również wtedy, gdy przyczyna problemu nie była wcześniej przewidziana. Wykorzystuje się do tego między innymi metryki, logi i ślady pokazujące przebieg żądania między usługami. Takie dane pomagają ocenić kondycję aplikacji z perspektywy użytkownika i szybciej diagnozować awarie.
Agile pomaga organizować tworzenie produktu w krótkich iteracjach, szybko zbierać informacje zwrotne i reagować na zmianę wymagań. DevOps z kolei rozwija podobną ideę ciągłego doskonalenia, ale mocniej obejmuje techniczną drogę zmiany aż do środowiska produkcyjnego i późniejszego utrzymania.
Najprościej ująć to tak, iż Agile pomaga zespołowi sprawnie zdecydować, co i w jakiej kolejności budować, natomiast DevOps pomaga bezpiecznie to zbudować, przetestować, wdrożyć i obserwować. Oba podejścia uzupełniają się również w warstwie organizacyjnej. Project Manager, czyli osoba odpowiedzialna za koordynację projektu musi rozumieć zależności, ryzyka i potrzeby różnych specjalistów.
Nie ma jednej drogi do tej specjalizacji. Część osób zaczyna jako programiści, administratorzy systemów, specjaliści chmurowi, testerzy automatyzujący albo inżynierowie sieci. Wspólnym mianownikiem jest stopniowe poznawanie całego cyklu życia aplikacji.
Warto przy tym rozwijać się poprzez projekty. Można stworzyć niewielką aplikację, objąć jej kod kontrolą wersji, dodać testy, spakować ją do kontenera, automatycznie wdrożyć i skonfigurować monitoring. Taki projekt pokazuje nie tylko znajomość narzędzi, lecz także rozumienie zależności między nimi.
Niemniej praca w DevOps wymaga też mocnych fundamentów technicznych, które można zdobyć studiując na naszej uczelni. Studia na kierunku Informatyka w PJATK pozwalają rozwijać między innymi umiejętności programistyczne, projektowe i zespołowe oraz poznawać zagadnienia związane z inżynierią oprogramowania, sieciami, systemami rozproszonymi, chmurą i cyberbezpieczeństwem.
W DevOps liczy się jednak nie tylko warstwa techniczna. Trzeba również rozumieć procesy organizacji, potrzeby biznesowe, przepływ informacji i zarządzanie projektem. Taką perspektywę łączącą informatykę, dane, biznes oraz kompetencje menedżerskie oferuje inny nasz kierunek Zarządzanie informacją w PJATK.
Ostatecznie DevOps nie polega na mechanicznym opanowaniu listy technologii. To umiejętność patrzenia na produkt jako na całość, od potrzeby użytkownika, przez kod i infrastrukturę, po niezawodność działającej usługi. Osoba, która rozumie zarówno technologię, jak i współpracę zespołową, ma solidną podstawę do rozwijania się w kierunku roli w zespołach DevOps.
Na koniec warto jeszcze odpowiedzieć na pytanie czy warto? Jak najbardziej, specjalizacja DevOps otwiera drogę do jednych z najlepiej wynagradzanych ról w IT, ponieważ łączy kompetencje programistyczne, administracyjne, chmurowe i automatyzację procesów wdrożeniowych. Według raportu No Fluff Jobs: “Rynek pracy IT 2024/2025”, doświadczeni eksperci mogą liczyć na stawki B2B na poziomie 21 800–28 000 zł miesięcznie, a przy umowie o pracę na wynagrodzenie rzędu 16 000–22 000 zł brutto.


