Optymalizacja kosztów chmury i platform engineering

Dwanaście podów prosi o 2 rdzenie procesora (CPU) każdy. Percentyl 95. użycia, czyli p95, to 0,22 rdzenia. Scheduler Kubernetesa pakuje pody według prośby (request), nie według zużycia. Rezerwacja: 24 rdzenie. Praca: 2,6 rdzenia. Autoskaler poziomy (Horizontal Pod Autoscaler, HPA) liczy procent requestu i widzi luz, więc nie zmniejsza liczby replik. Autoskaler klastra (Cluster Autoscaler) dokłada kolejną maszynę tego samego typu, bo puste miejsce na węźle jest zajęte prośbą, której nikt nie ruszył od migracji.

Optymalizacja kosztów chmury nie zaczyna się od rabatu u dostawcy. Zaczyna się od tego, kto w platform engineering ma prawo zmienić request, rodzinę maszyny i godzinę, o której gaśnie środowisko nieprodukcyjne. Źle ścięty limit podnosi opóźnienie p99 (99. percentyl) albo zabija proces brakiem pamięci (out of memory, OOM). Dobrze ścięty request zdejmuje węzły, których nikt nie używa.

Trzy słowa, które w briefach zlewają się w jedno:

• Platform engineering to zespół, który buduje wewnętrzną platformę: klaster, ciągłą integrację i ciągłe dostarczanie (CI/CD), katalog usług, budżety. Zespoły produktowe nie składają Kubernetesa od zera.
• FinOps (Financial Operations) to rytm, w którym inżynieria i finanse widzą koszt jednostki pracy, na przykład tysiąca żądań, a nie tylko fakturę na koniec miesiąca.
• Slack, czyli zapas, to różnica między limitem albo requestem a realnym użyciem. U Google’a ręcznie ustawiane zadania miały zapas 46%. Automat obniżył go do 23%.

1. Anatomia: trzy pętle, które nie widzą tej samej liczby

Na klastrze działają trzy regulatory. Każdy optymalizuje inną zmienną. Żaden sam nie widzi faktury.

1. Request i limit na podzie. Request to rezerwacja dla schedulera. Limit to sufit: powyżej niego CPU jest dławione, a pamięć kończy się zabiciem procesu. Request 4× większy niż p95 zostawia na węźle dziurę, do której nie wejdzie kolejny pod.
2. Liczba replik (HPA). HPA dokłada pody, gdy procent requestu przekroczy cel, często 50–80%. Gdy request jest 9× za duży, zużycie wygląda jak 11%. HPA śpi. Albo oscyluje, gdy limit dusi CPU i opóźnienie rośnie, zanim średnia „nadąży”.
3. Liczba węzłów (Cluster Autoscaler). CA dokłada i zdejmuje maszyny ze zdefiniowanej puli. Pula jest jednorodna: ten sam typ instancji, który ktoś wpisał w infrastrukturze jako kod (Infrastructure as Code, IaC). Pod, który nie mieści się w wolne miejsce, budzi nową maszynę tej samej rodziny, nawet gdy tańsza rodzina (więcej pamięci, mniej CPU) załatwiłaby robotę jednym węzłem.

Czwarty element nie jest regulatorem. Jest kalendarzem. Dev i stage w tej samej wielkości co produkcja, 24 godziny na dobę, 7 dni w tygodniu. Robocze 8–19 to 55 godzin z 168. Reszta, około dwóch trzecich tygodnia, jest rachunkiem za pustkę.

resources:
  requests:
    cpu: "500m"       # rezerwacja: scheduler i HPA patrzą tutaj
    memory: "512Mi"
  limits:
    cpu: "1500m"      # sufit; wyżej CPU jest dławione
    memory: "1Gi"     # wyżej proces ginie (OOM)

Pionowy autoskaler (Vertical Pod Autoscaler, VPA) umie przepisać request. W trybie automatycznym restartuje pody. Na pamięci potrafi ukryć wyciek: aplikacja rośnie, VPA podnosi limit, błąd znika z wykresu i zostaje na fakturze. Dlatego rekomendacja VPA bez bramki to nie to samo co wdrożenie.

Narzędzia, które dobierają typ maszyny do oczekujących podów (na Amazon Web Services jest to Karpenter, na innych chmurach odpowiednik node auto-provisioning), obchodzą ograniczenie jednorodnej puli. Nie zastępują right-sizingu requestu. Pakują to, o co pody proszą. Jeśli proszą 9× za dużo, Karpenter kupi mniej dziur, nie zero dziur.

Rachunek za procesor graficzny (GPU) i trening modelu to inna pętla: detekcja dryfu i retraining, nie bin packing węzłów. Opisaliśmy ją osobno w artykule o usługach MLOps. Mieszanie obu briefów w jednym „DevOpsie od wszystkiego” daje dyżur. Nie daje ani FinOpsu, ani retreningu.

2. Optymalizacja kosztów chmury: co mierzą badania

Slajd „zaoszczędzimy 40%” nie mówi, na jakim układzie i wobec jakiej bazy. Cztery źródła mierzą co innego. Trzeba je rozdzielić, zanim ktokolwiek wpisze procent do umowy.

• Ręczny zapas 46%, automat 23%. Rzadca, Findeisen, Świderski i in., Autopilot: Workload Autoscaling at Google (EuroSys 2020, DOI 10.1145/3342195.3387524). Autopilot ustawia i skalę poziomą (liczba zadań), i pionową (CPU oraz pamięć) na podstawie historii. Zapas spada z 46% przy ręcznej konfiguracji do 23%. Liczba zadań mocno dotkniętych OOM spada około 10×. W chwili publikacji Autopilot obejmował ponad 48% zużycia zasobów floty Google. To jest Borg, wewnętrzny system Google, nie produkt do wgrania na EKS (Elastic Kubernetes Service). Przenosi się mechanika: pion i poziom razem, na historii, z celem „mniej zapasu bez OOM i bez dławienia CPU”.
• Jednorodne maszyny i upgrade psują wzorzec. Hua, Yang, Qian i in., Humas (arXiv:2406.15769, 2024). Eksperyment na 50 rzeczywistych mikroserwisach i ponad 11 000 kontenerów. Wobec metod uznanych za stan sztuki Humas poprawia efektywność zasobów o około 30,4% i stabilność o około 48,0%. W tabeli zapas na surowych śladach wynosi 52,87%, przy reimplementacji Autopilota 16,63%, przy Humas 11,58%. Średni przydział CPU spada o około 46,8% wobec surowych śladów. Osobno: po wdrożeniu nowej wersji usługi wzorzec zużycia się zmienia (drift wzorca). Autoskaler nauczony na starej wersji znowu pudłuje. To nie jest ten sam 23% co u Rzadcy. Inny ślad, inna liczba.
• Próg CPU na usłudze nie widzi opóźnienia końca do końca. Sachidananda i Sivaraman, Collective Autoscaling for Cloud Microservices (COLA, arXiv:2112.14845). Każdy mikroserwis skalowany osobno progiem CPU nie wie, że opóźnienie użytkownika jest sumą kilku usług. Na Google Kubernetes Engine (GKE), w trybie standard i Autopilot, COLA spełnia cel mediany albo ogona opóźnienia na 53 z 63 obciążeń i jest wtedy średnio o 19,3% tańszy od następnego autoskalera, który ten cel też trzyma. Na 48 z tych 53 jest najtańszy. Na małych aplikacjach, gdzie da się przejrzeć konfiguracje w całości, jest optymalny w 90% przypadków. Autorzy piszą, że oszczędność zwraca koszt treningu w kilka dni. To jest ich układ eksperymentalny, nie obietnica na Waszą fakturę.
• Cluster Autoscaler nie zmienia rodziny maszyny. Boghani, Kirimlioglu, Moturi i Tso, Cloud Resource Allocation with Convex Optimization (arXiv:2503.21096, 2025). CA skaluje w górę i w dół istniejące pule identycznych instancji. Nie wybiera miksu typów. Praca porównuje optymalizację wypukłą z takim CA w symulacji (Python, mediana z pięciu przebiegów), nie na rachunku AWS. Scenariusz 1, prosta aplikacja webowa od zera: brak istotnej różnicy. Standardowy autoskaler wystarcza. Scenariusz 2, dokładanie do istniejącej infrastruktury: 42,5% taniej (0,12 USD/h wobec 0,07 USD/h). Scenariusze 3–5: 80,5%, 87,2% i 71,1%. Średnia z pięciu: 56,3%. Obciążenie pamięciożerne (scenariusz 4): z 1,08 USD/h do 0,14 USD/h. Skrajne „przepakowanie” rzędu tysięcy procent pojawia się w scenariuszu, w którym wolno użyć tylko małych instancji. To nie jest typowa faktura. To dowód, że zła rodzina maszyn mnoży węzły.
• VPA bez bramki na wyciek dokupuje pamięć do błędu. Karakaya, Şengül i Kaplan, Safety-Gated Autoscaling (arXiv:2607.26503, 29 lipca 2026). Detektor wycieku pamięci (regresja liniowa, współczynnik R²) blokuje rekomendację, zamiast powiększać zepsuty kontener. Na żywym GKE szacunek oszczędności 20–40% to projekcja „co by było, gdyby”, nie zmierzony rachunek. Detektor trafia w 83%. Zestaw testów: 1118, pokrycie 80,3%. Jest tryb dry-run i akceptacja przez człowieka. Tę liczbę 20–40% wolno cytować tylko z tym zastrzeżeniem.

3. Studium: 24 rdzenie zarezerwowane, 2,6 w użyciu

Liczby z papierów nie przenoszą się 1:1 na Waszą fakturę. Przenosi się podział: najpierw request, potem typ maszyny, potem gaszenie tego, co nie obsługuje ruchu. Kto zaczyna od Karpentera na requestach 2000m przy użyciu 220m, kupuje ładniejsze pakowanie tej samej dziury.

4. Tabela decyzyjna: co ruszać, a czego nie automatyzować

DevOps / SRE / cloud: stawka specjalisty 140–200 PLN/h, stawka dla klienta 200–325 PLN/h. Marża dostawcy 10–25%. To mapa rynku, nie oferta. Rozpisanie: ile kosztuje body leasing IT w 2026. No Fluff Jobs podaje za 1. kwartał 2026 widełki B2B specjalisty DevOps 23,5–28,5 tys. zł. To faktura kontraktora, nie stawka, którą płaci klient.

5. Anty-wzorce, których nie ma w tutorialu HPA

1. HPA na 80% requestu, który jest 4× za duży. Autoskaler widzi bezczynność. Węzły zostają. Dashboard „wykorzystania klastra” pokazuje 20% i nikt nie łączy tego z manifestem.
2. VPA w trybie auto na pamięci, bez detektora wycieku. Rekomendacja rośnie razem z błędem. Incydent OOM znika. Faktura nie. Sucha akceptacja (dry-run) istnieje po to, żeby człowiek zobaczył trend, zanim limit pójdzie w górę.
3. Cztery pule „na wszelki wypadek” i CA, który umie tylko dokładać ten sam typ. Boghani: na prostej aplikacji od zera nie widać zysku. Zysk jest tam, gdzie kształt podów nie pasuje do rodziny wpisanej dwa lata temu w Terraform.
4. FinOps jako PDF i DevOps w 20% etatu. CI/CD, dyżur, koszt, Kubernetes i jeszcze GPU. Jedna osoba na pięć pętli nie domknie żadnej. Narzędzie do kosztów w trybie tylko do odczytu, bez prawa zmiany requestu, jest droższym PDF-em.

6. Playbook: kogo wynająć i w jakiej kolejności

Nie zaczynajcie od kolejnego klastra. Zacznijcie od pytania, która pętla trzyma fakturę: request, typ maszyny, środowiska nieprodukcyjne czy GPU.

1. Klaster, tożsamość (IAM, identity and access management) i Terraform już stoją. Brakuje właściciela requestów, budżetu namespace’u i przeglądu raz w tygodniu. To klasyczny body leasing inżyniera DevOps: jedna osoba, Wasz stand-up, Wasze kryterium ukończenia (Definition of Done). Body leasing znaczy tu wynajem specjalisty do Waszego zespołu, zwykle w rozliczeniu za czas (time and materials, T&M). Nie sprzedajemy imiennej ławki na poniedziałek rano.
2. Nikt nie jest właścicielem klastra. Cztery konta, brak IaC, dev w rozmiarze produkcji, manifesty z requestem „skopiowanym z tutoriala”. Jedna osoba tego nie zszyje w sprincie. Skład platformy: ktoś od klastra i IaC, ktoś od CI/CD, ktoś kto ma prawo powiedzieć „ten namespace gaśnie o 19”. To bliżej leasingu zespołów IT niż „dokupimy jeszcze jednego DevOpsa”. Kiedy squad, a kiedy jedna rola, rozpisaliśmy w team leasing vs body leasing 2026.
3. Dane i kubeconfig nie wychodzą na laptop. Kontraktor w Waszym IAM, Wasza chmura, umowa o poufności (NDA) i powierzenie. Eksport kubeconfiga „żeby szybciej policzyć requesty” jest dostępem do produkcji. Klauzule: umowy, marże, prawa autorskie.
4. Ramp-up. Osoba do istniejącego zespołu: pierwsze profile w ciągu dni, start po Waszych rozmowach i umowie. Skład od zera: tygodnie, bo zszywacie uprawnienia i Definition of Done na zmianę requestu na produkcji. Zapowiedź „trzech seniorów platformy od poniedziałku” to albo CV, albo ławka, której nie mamy.

Commoditech od 2012 robi T&M i rekrutację stałą z Warszawy. W sieci jest 80+ specjalistów. Nie trzymamy ich bezczynnie na ławce. Brief na body leasing albo na etat (wynagrodzenie za sukces, success fee, bez zatrudnienia nie ma opłaty) da się złożyć też z edytora, przez MCP dla agentów AI (Model Context Protocol, protokół, którym asystent w IDE woła narzędzia). Kwotę na konkretny stack liczy człowiek. Widełki są w artykule o stawkach, nie w odpowiedzi automatu. Kontakt: formularz.

FAQ

Źródła

• Rzadca, K., Findeisen, P., Świderski, J. i in. (2020). Autopilot: Workload Autoscaling at Google. EuroSys 2020. doi.org/10.1145/3342195.3387524. Skrót liczb: research.google.
• Hua, Q., Yang, D., Qian, S., Cao, J., Xue, G., Li, M. (2024). Humas: A Heterogeneity- and Upgrade-aware Microservice Auto-scaling Framework. arXiv:2406.15769. arxiv.org/abs/2406.15769.
• Sachidananda, V., Sivaraman, A. (2022). Collective Autoscaling for Cloud Microservices. arXiv:2112.14845. arxiv.org/abs/2112.14845.
• Boghani, S., Kirimlioglu, E., Moturi, A., Tso, H.-T. (2025). Cloud Resource Allocation with Convex Optimization. arXiv:2503.21096. arxiv.org/abs/2503.21096.
• Karakaya, A., Şengül, E., Kaplan, A. (2026). Safety-Gated Autoscaling. arXiv:2607.26503. arxiv.org/abs/2607.26503.
• Commoditech — stawki body leasingu 2026, wynajem inżynierów DevOps, team leasing vs body leasing.