Kilka miesięcy temu podczas audytu jednego z systemów ktoś z zespołu rzucił: „Tu i tak już nic więcej się nie da wycisnąć”. Przesiedziałyśmy nad tym fragmentem kodu dwie godziny. Zmieniłam dosłownie dwie linijki. W symulacji wyszło, że rocznie daje to około 2 ton CO2 mniej. Dwie linijki. Dwie tony. To jest właśnie skala, o której mówię, gdy rozmawiam o Green Ops.

Z mojej perspektywy Green Ops nie jest modą ani ładnym slajdem do strategii ESG. To konkretne decyzje technologiczne – od linii kodu, przez architekturę, po sposób, w jaki automatyzujesz infrastrukturę. I tu zaczyna się niewygodna prawda: ślad węglowy IT nie rodzi się dopiero w centrum danych, ale w edytorze kodu.

Kiedy projektuję cyfrowe ekosystemy, patrzę na kod jak na „umowę” ze sprzętem. Im bardziej rozbudowana, chaotyczna i pełna haczyków, tym więcej energii serwery muszą „dopłacić”, żeby ją obsłużyć. Green coding polega na tym, żeby tę umowę uprościć – bez utraty funkcjonalności, za to z ogromnym zyskiem energetycznym i biznesowym.

I to jest moment, w którym zrównoważony rozwój, automatyzacja i AI przestają być hasłami, a stają się narzędziami. Dobrze poukładany kod + mądrze zautomatyzowana infrastruktura = systemy, które działają szybciej, stabilniej i… emitują mniej CO2. A to wszystko da się policzyć.

Cyfrowy ślad węglowy IT: z czego się składa i gdzie naprawdę „ucieka” energia

Pytanie, które regularnie słyszę od zarządów brzmi: „Ile właściwie CO2 generuje nasze IT?”. Odpowiadam wtedy: „To zależy, jak piszecie kod, jak korzystacie z chmury i skąd macie prąd”.

Cyfrowy ślad węglowy IT to suma emisji związanych z energią, którą zużywają:

  • serwery i urządzenia sieciowe,
  • centra danych (razem z chłodzeniem),
  • urządzenia końcowe (komputery, laptopy, smartfony),
  • transmisja danych w sieci.

U jednego z klientów mierzyłyśmy obciążenie środowiska testowego. Okazało się, że spora część emisji pochodziła nie z produkcji, ale z… zapomnianych środowisk developerskich, które „tykały” miesiącami.

Proces obliczania śladu węglowego IT zwykle układam w pięć kroków:

  1. Zużycie energii przez serwery i urządzenia sieciowe – mierzymy lub szacujemy, ile watogodzin zużywają systemy podczas realizacji konkretnych zadań. To baza do obliczenia emisji CO2 przypisanej do procesów.
  2. Efektywność energetyczna centrów danych – współczynnik PUE (Power Usage Effectiveness) pokazuje, jaka część energii idzie na realną pracę serwerów, a jaka na chłodzenie i infrastrukturę pomocniczą.
  3. Źródło energii elektrycznej – ta sama ilość kWh daje zupełnie inny ślad węglowy, jeśli pochodzi z OZE, a inny, jeśli z węgla czy gazu.
  4. Skala operacji i czas działania infrastruktury IT – długo „mielące” procesy i przewymiarowane środowiska bardzo szybko windują emisje. Tu pierwsze skrzypce gra optymalizacja kodu i automatyzacja.
  5. Użytkowanie urządzeń końcowych – często pomijane, a istotne zarówno w czasie użytkowania, jak i w całym cyklu życia sprzętu (produkcja, transport, utylizacja).

Coraz częściej w projektach Green Ops włączam monitoring emisji w czasie rzeczywistym. I tu ciekawostka: z doświadczeń branży wynika, że tylko około 20% firm faktycznie śledzi emisje algorytmów i aplikacji na bieżąco. Reszta działa „na czuja”.

⚡ PRO TIP: do profilowania zużycia energii przez kod świetnie sprawdzają się narzędzia takie jak Intel Power Gadget czy serwisy w stylu Green Algorithms. Programiści raportują, że po refaktoryzacji pętli w modelach ML udaje się zbić pobór energii o 20–30%, bez zmiany jakości wyników.

Green coding w praktyce: gdzie kod zjada najwięcej energii

Za każdym razem, gdy słyszę „nasz kod jest już wystarczająco szybki”, pytam: „A wiesz, ile energii zużywa?”. Cisza po drugiej stronie jest zwykle bardzo wymowna.

Green coding to dla mnie połączenie trzech rzeczy:

  • sensownego doboru algorytmów,
  • dbałości o IO (bazy danych, zapisy na dysk, operacje sieciowe),
  • ciągłego profilowania pod kątem energii, a nie tylko czasu wykonania.

Przy jednym z projektów ML zaczęłyśmy mierzyć zużycie energii podczas trenowania modelu. Profilowanie pokazało, że około 70% całkowitego poboru energii generuje kilka procent kodu – konkretnie jedna, mocno zagnieżdżona pętla i źle dobrany algorytm sortujący w pre-processingu danych. Po zmianie tego kawałka model trenował się szybciej, a rachunek za energię spadł zauważalnie, mimo że sprzęt się nie zmienił.

W automatyzacji i AI widać to jeszcze wyraźniej. Algorytmy ML/AI potrafią zużywać ogromne ilości energii, bo:

  • przetwarzają gigantyczne zbiory danych,
  • wykonują miliony powtórzeń tych samych obliczeń,
  • często działają w trybie ciągłym (np. rekomendacje, scoring, monitoring).

Dobrze dobrany i zoptymalizowany algorytm potrafi zmniejszyć zużycie energii dosłownie o rząd wielkości. A czasem – wracając do anegdoty z początku – wystarczy zmiana dwóch linijek, żeby zredukować kilka ton emisji CO2 rocznie.

⚠ UWAGA: green coding to nie „upiększanie” kodu. To świadome decyzje, w których rezygnujesz z nadmiarowej wygody (np. pięciu „magicznych” warstw abstrakcji) na rzecz prostszego, bardziej przewidywalnego, a przez to tańszego energetycznie rozwiązania.

Języki programowania a ślad węglowy: Rust, Go i reszta świata

Na jednym z warsztatów z architektur mikroserwisów zapytałam zespół: „Dlaczego wszystkie nowe serwisy piszecie w Javie?”. Odpowiedź: „Bo tak robimy od 10 lat”. Po miesiącu pilotażu w Rust okazało się, że przy tej samej funkcjonalności zużycie CPU spadło w niektórych serwisach o około 25%.

To, w jakim języku piszesz, ma realny wpływ na zużycie energii. Nie chodzi o ideologię, tylko o konstrukcję języka, model pamięci i narzut runtime’u.

Rust i Go są projektowane z myślą o wysokiej wydajności, niskim narzucie i przewidywalnym zarządzaniu pamięcią. Efekt? Mniej cykli CPU, mniej alokacji, mniej GC – a więc niższe zużycie energii serwerów przy tej samej logice biznesowej. Python czy Java są świetne pod względem produktywności, ale ceną bywa większe zapotrzebowanie na zasoby.

Ta różnica jest jeszcze bardziej widoczna, gdy mówimy o dużej skali: mikrousługi, systemy o milionach requestów dziennie, platformy ML.

Poniżej zostawiam tabelę, którą często pokazuję zespołom przy wyborze technologii (zachowując jej uproszczony, orientacyjny charakter):

Język programowania Zużycie zasobów (relatywne) Typowe zastosowania Efektywność energetyczna
Rust Niskie Systemy, aplikacje o wysokiej wydajności Wysoka
Go Niskie Backend, usługi sieciowe Wysoka
Python Wysokie Prototypy, uczenie maszynowe, skrypty Niższa
Java Wysokie Aplikacje korporacyjne, systemy wielowarstwowe Niższa

Nie chodzi o to, żeby nagle przepisywać cały świat na Rust. Chodzi o świadomy wybór: do krytycznych energetycznie komponentów – język bardziej wydajny; do warstwy eksperymentalnej – coś szybkiego w developmentcie.

⚡ PRO TIP: przy projektowaniu architektury mikroserwisów stosuję prostą zasadę:
„Hot path” (najbardziej obciążone serwisy) – Rust / Go,
„Cold path” (rzadziej używane, narzędziowe) – Python / Java.

To zdrowy kompromis między produktywnością a śladem węglowym.

Automatyzacja procesów IT jako silnik Green Ops

Kiedy wchodzę do firmy, w której środowiska chmurowe utrzymuje się „ręcznie”, już wiem, że Green Ops będzie miał z czego żyć. Rachunek jest prosty: im więcej powtarzalnych czynności wykonują ludzie, tym więcej zasobów jest rozkręconych „na zapas”.

Automatyzacja procesów IT w Green Ops pełni kilka ról naraz:

  • dopasowuje zasoby do realnego obciążenia,
  • wyłącza to, co nieużywane,
  • pilnuje polityk energetycznych 24/7, a nie tylko „jak się ktoś przypomni”.

W jednej z firm, z którą pracowałam, przeanalizowałyśmy infrastrukturę chmurową. Po wdrożeniu automatycznego usypiania i kasowania nieużywanych instancji oraz porządków w storage’u okazało się, że zużycie energii spadło o około 30–50% w porównaniu z punktem wyjścia. Koszty – podobnie. To są bardzo typowe wartości, gdy chmura do tej pory rosła organicznie.

Są też rozwiązania idące krok dalej. Przykład: system AREMS, który wykorzystuje AI do zarządzania energią i magazynowaniem nadwyżek z OZE. Dzięki synchronizacji z rynkami energii i automatycznemu sterowaniu udało się tam zredukować emisje o 9543 t CO2 rocznie, czyli około 40% całkowitych emisji firmy. To nie jest science-fiction, tylko sprytne połączenie automatyzacji, danych i energii.

W swoich zespołach układam to tak, żeby automatyzacja była częścią codziennej pracy, a nie oddzielnym „projektem na boku”. W podejściu Agile świetnie działa codzienne przeglądanie fragmentów kodu pod kątem efektywności energetycznej w ramach sprintów – tak samo naturalne jak code review pod kątem bezpieczeństwa. Kiedy dorzucisz do tego systematyczne profilowanie i metryki, Green Ops po prostu wsiąka w kulturę zespołu.

Web, front, hosting: gdzie strona www marnuje energię

Jedna z moich ulubionych scenek: redesign strony produktowej. Marketing chce efektowne wideo w tle, gigantyczne zdjęcia, interaktywne animacje, full SPA. Robimy prosty test: wersja SPA vs wersja SSR + cache + statyczne assety. Wynik? Różnica w śladzie węglowym sięga nawet 80% na korzyść SSR/statycznych stron. A użytkownik? Cieszy się z szybszego ładowania i mniej „mulącego” telefonu.

W Green Ops na poziomie webu koncentruję się na kilku rzeczach:

  • SSR i statyczne strony – mniej pracy po stronie klienta, mniej JavaScriptu do pobrania, mniej renderowania w przeglądarce. W praktyce to często nawet 80% mniejszy ślad węglowy niż ciężkie SPA.
  • Cache’owanie – im rzadziej serwer musi „tworzyć” stronę od zera, tym mniej energii zużywa. Dotyczy to zarówno cache’u aplikacji, jak i reverse proxy czy CDN.
  • Formaty mediów – przejście z JPEG na AVIF potrafi obniżyć wagi grafik o 40–60% przy tej samej jakości. To mniej transferu, mniej energii po stronie serwera i klienta.
  • Wideo – kodek AV1 przy rozsądnej kompresji oszczędza nawet około 50% transferu danych w porównaniu z klasycznymi kodekami, przy nadal bardzo dobrej jakości.
  • Kompresja i protokoły – włączenie kompresji gzip/br, sensowne cache-control, HTTP/2/3 – to relatywnie proste zmiany, które skalują się wraz z ruchem.

Do tego dochodzi wybór infrastruktury. Zamiast przypadkowego hostingu często kieruję klientów w stronę dostawców wspieranych OZE, np. rozwiązań w stylu OVH Green czy innych dostawców z certyfikowanym „zielonym” zasilaniem. Różnica w śladzie węglowym między takim hostingiem a klasycznym data center na energii z węgla jest ogromna – nawet przy tej samej liczbie requestów.

⚡ PRO TIP: przy redesignie strony dodaj do check-listy:
„Czy obrazy są w AVIF, wideo w AV1, gzip włączony, a serwer stoi u green hostera?”.
To drobiazgi, które w skali milionów odsłon dają bardzo konkretne oszczędności energetyczne.

Jak wdrażam Green Ops w firmach: krok po kroku, ale bez złudzeń

Wiele organizacji zaczyna rozmowę od: „Chcemy Green Ops, ale żeby niczego nie spowolnić i nie komplikować”. Odpowiadam szczerze: „Da się, ale trzeba będzie kilka rzeczy zmienić w sposobie pracy”.

Zaczynam od diagnozy. Przeglądamy procesy, architekturę, pipeline’y CI/CD, wykorzystanie chmury, sposób pisania kodu. Szukamy miejsc, gdzie:

  • procesy są niepotrzebnie długie lub blokujące,
  • środowiska są przewymiarowane lub „zapomniane”,
  • kod wykonuje tę samą pracę kilka razy,
  • algorytmy są wygodne, ale ciężkie obliczeniowo.

Czasem wychodzi na przykład, że jedna niewinna integracja odpytuje zewnętrzne API co 5 sekund… a dane zmieniają się raz na godzinę.

Drugi etap to automatyzacja. Tu Green Ops najczęściej spotyka się z DevOps. Wdrażamy:

  • automatyczne skalowanie i wyłączanie instancji,
  • polityki lifecycle dla storage’u,
  • joby sprzątające nieużywane zasoby,
  • pipeline’y CI/CD, które same oceniają wydajność i zużycie energii nowych wersji.

Równolegle włączam monitoring energetyczny i KPI – takie, które da się pokazać zarządowi i zespołom jednocześnie. Przykłady: energia na request, energia na job batchowy, koszt energetyczny epoki uczenia modelu, „ciemne” godziny, gdy infrastruktura działa bez realnego obciążenia.

Trzeci filar to ludzie i nawyki. W jednym z zespołów wprowadziłyśmy prostą zasadę: w każdym sprincie co najmniej jedno zadanie dotyczyło optymalizacji energetycznej – zmiany algorytmu, refaktoryzacji pętli, porządków w chmurze. Po kilku miesiącach deweloperzy sami zaczęli zgłaszać „zielone” usprawnienia, bo widzieli ich wpływ na rachunki i metryki.

Współpraca z partnerem technologicznym, który rozumie temat neutralności węglowej, znacząco przyspiesza całość. Łatwiej wtedy dobrać sensowne narzędzia, platformy chmurowe, rozwiązania oparte na OZE i połączyć to w całość, która jest jednocześnie skalowalna i „lekka” energetycznie.

Jak liczyć, optymalizować i gdzie chmura naprawdę pomaga

Podczas jednego z warsztatów CFO firmy zapytał: „Możemy inwestować w Green Ops, ale proszę mi powiedzieć, o ile to realnie obniży nasze emisje i koszty”. To jest dokładnie ten moment, w którym liczby spotykają się z kodem.

Ślad węglowy IT liczę w uproszczeniu tak:

  • zbieram dane o zużyciu energii przez serwery, sieć, storage,
  • przeliczam to na emisje na podstawie miksu energetycznego (OZE vs paliwa kopalne),
  • rozbijam na usługi: aplikacje, batch’e, modele ML, środowiska,
  • porównuję „przed i po” wdrożeniu optymalizacji.

Kluczowe jest profilowanie kodu – nie tylko czasowo, ale właśnie energetycznie. Narzędzia w stylu Intel Power Gadget czy Green Algorithms pomagają zobaczyć, które fragmenty kodu „grzeją” najbardziej. Często okazuje się, że niewielki kawałek logiki odpowiada za dominującą część poboru energii. To tam inwestuję czas zespołu.

Gdy dobieram algorytmy z myślą o efektywności energetycznej, patrzę na:

  • złożoność obliczeniową (ale realną, nie tylko z książki),
  • zużycie pamięci,
  • liczbę operacji IO (zapytania do baz, dyski, sieć).

Czasem klasyczne algorytmy optymalizacyjne (np. genetyczne, roje cząstek) świetnie się sprawdzają, ale w wielu systemach największy efekt dają po prostu sprytne heuristiczne podejścia + refaktoryzacja „spuchniętych” zapytań do bazy.

No i chmura. Czy chmura pomaga w redukcji śladu węglowego? Z mojego doświadczenia: tak, ale tylko wtedy, gdy:

  • korzystasz z elastycznego skalowania,
  • automatycznie wyłączasz zasoby poza szczytem,
  • wybierasz regiony / dostawców z wysokim udziałem OZE,
  • masz monitoring, który pokazuje, ile kosztuje (także energetycznie) każda usługa.

Bez tego chmura staje się po prostu droższym odpowiednikiem własnego data center – tyle że na cudzym podwórku.

Green Ops jako nowy standard, nie „projekt poboczny”

Gdy zaczynałam wdrożenia automatyzacji 10 lat temu, mało kto pytał o ślad węglowy. Dziś pytania o ESG, neutralność węglową i efektywność energetyczną pojawiają się już na etapie briefu. I bardzo dobrze.

Green Ops staje się standardem z kilku powodów:

  • pozwala obniżyć koszty operacyjne (mniej energii, mniej przewymiarowanej infrastruktury),
  • poprawia wydajność i stabilność aplikacji,
  • wspiera strategię ESG i raportowanie niefinansowe,
  • buduje realną, a nie „zielono-pijarową” przewagę konkurencyjną.

Widzę, że firmy, które podchodzą do Green Ops poważnie – integrując go z DevOps, Agile i codziennymi decyzjami technologicznymi – wygrywają na kilku polach naraz. Kod jest prostszy i szybszy, infrastruktura lżejsza, rachunki niższe, a raporty ESG przestają być problemem, a stają się argumentem.

Podsumowując: Green Ops zaczyna się w kodzie, ale nie kończy na nim. To sposób myślenia o IT jako o ekosystemie, w którym każda decyzja – od wyboru języka, przez format grafiki na stronie, po automatyczne wyłączenie nieużywanej instancji – ma swój mały udział w globalnym bilansie CO2.

Jeśli projektujesz systemy tak, by były jednocześnie wydajne, skalowalne i energooszczędne, robisz coś więcej niż tylko „optymalizację”. Dokładasz cegiełkę do świata, w którym technologia naprawdę współpracuje z planetą, zamiast ją po cichu drenuwać. I dokładnie tym zajmuję się na co dzień.