Ka\u017cdy CTO i founder wie, \u017ce czas programist\u00f3w to najdro\u017cszy zas\u00f3b w firmie. Ale czy wiesz, \u017ce wed\u0142ug bada\u0144 Stripe a\u017c 32% czasu deweloper\u00f3w marnuje si\u0119 na zadania zwi\u0105zane z zarz\u0105dzaniem infrastruktur\u0105, a nie na pisaniu kodu? W ma\u0142ych i \u015brednich firmach odsetek ten bywa jeszcze wy\u017cszy \u2013 programi\u015bci zamiast tworzy\u0107 nowe funkcje, konfiguruj\u0105 serwery, debuguj\u0105 potoki CI\/CD i walcz\u0105 z niesp\u00f3jno\u015bciami \u015brodowisk. Problem le\u017cy cz\u0119sto nie w z\u0142ym zarz\u0105dzaniu, ale w nieoptymalnej infrastrukturze, kt\u00f3ra jest cichym zab\u00f3jc\u0105 produktywno\u015bci. W tym artykule przyjrzymy si\u0119 trzem konkretnym b\u0142\u0119dom infrastrukturalnym, kt\u00f3re powoduj\u0105, \u017ce Tw\u00f3j zesp\u00f3\u0142 pracuje wolniej, a Ty p\u0142acisz za to podw\u00f3jnie \u2013 w kosztach operacyjnych i utraconych szansach biznesowych.<\/p>\n
Znasz to? Nowy programista do\u0142\u0105cza do zespo\u0142u i pierwsze dwa tygodnie sp\u0119dza na konfigurowaniu lokalnego \u015brodowiska. Albo inna sytuacja: na produkcji dzia\u0142a, na stagingu nie, a lokalnie w og\u00f3le nie odpala. To klasyczny objaw braku zdefiniowanych, reprodukowalnych \u015brodowisk.<\/p>\n
Ka\u017cda godzina sp\u0119dzona na r\u0119cznym setupie to godzina, kt\u00f3rej nie po\u015bwi\u0119cono na rozw\u00f3j produktu. W zespole 5-osobowym, gdzie ka\u017cdy traci \u015brednio 2 godziny tygodniowo na problemy \u015brodowiskowe (a to konserwatywne za\u0142o\u017cenie), przy stawce 150 z\u0142 za godzin\u0119, daje to 1500 z\u0142 tygodniowo, czyli 72 000 z\u0142 rocznie. Do tego dochodzi frustracja i rotacja \u2013 programi\u015bci nie lubi\u0105 traci\u0107 czasu na rzeczy, kt\u00f3re powinny by\u0107 zautomatyzowane.<\/p>\n
Standardem powinny by\u0107 kontenery (Docker, Podman) po\u0142\u0105czone z narz\u0119dziami do zarz\u0105dzania konfiguracj\u0105 (Ansible, Terraform). Ka\u017cde \u015brodowisko \u2013 od lokalnego po produkcyjne \u2013 powinno by\u0107 opisane w plikach i odtwarzalne jednym poleceniem. W JurskiTech wdra\u017camy takie podej\u015bcie od dawna i widzimy, \u017ce skraca to onboarding z tygodni do jednego dnia. Co wi\u0119cej, eliminuje to problem \u201edzia\u0142a na moim komputerze\u201d \u2013 je\u015bli \u015brodowisko jest identyczne, b\u0142\u0119dy s\u0105 powtarzalne i \u0142atwiejsze do debugowania.<\/p>\n
Klient z bran\u017cy e-commerce mia\u0142 zesp\u00f3\u0142 10 deweloper\u00f3w, kt\u00f3rzy na zmiany \u015brodowiska marnowali \u0142\u0105cznie oko\u0142o 30 godzin tygodniowo. Po wdro\u017ceniu Docker Compose dla lokalnych \u015brodowisk i Terraform dla stagingu, czas ten spad\u0142 do 5 godzin. Ca\u0142y proces zaj\u0105\u0142 dwa tygodnie, a zwr\u00f3ci\u0142 si\u0119 w ci\u0105gu miesi\u0105ca.<\/p>\n
Drugi b\u0142\u0105d, kt\u00f3ry cz\u0119sto widz\u0119, to traktowanie infrastruktury jako \u201ejednoraz\u00f3wki\u201d \u2013 co\u015b, co konfiguruje si\u0119 raz i zapomina. Brak wersjonowania konfiguracji serwer\u00f3w, baz danych, load balancer\u00f3w czy regu\u0142 firewall prowadzi do chaosu. Gdy co\u015b si\u0119 psuje, nikt nie wie, co zosta\u0142o zmienione, a przywracanie do dzia\u0142aj\u0105cego stanu trwa godzinami.<\/p>\n
Bez wersjonowania infrastruktury tracisz mo\u017cliwo\u015b\u0107 audytu zmian, \u0142atwego rollbacku i odtworzenia ca\u0142ego \u015brodowiska po awarii. W praktyce oznacza to, \u017ce ka\u017cda zmiana wi\u0105\u017ce si\u0119 z ryzykiem, a debugowanie problem\u00f3w produkcyjnych trwa d\u0142u\u017cej, bo trzeba r\u0119cznie sprawdza\u0107 co, kiedy i kto zmieni\u0142.<\/p>\n
Wszystko \u2013 od konfiguracji serwera po definicje Kubernetes \u2013 powinno by\u0107 trzymane w repozytorium Git. Procesy CI\/CD powinny automatycznie stosowa\u0107 zmiany do \u015brodowisk. Dzi\u0119ki temu mamy pe\u0142n\u0105 histori\u0119, mo\u017cliwo\u015b\u0107 cofni\u0119cia si\u0119 do poprzedniej wersji i weryfikacj\u0119 zmian przez code review. Dodatkowo, w przypadku awarii, odtworzenie ca\u0142ego \u015brodowiska to kwestia minut, a nie dni.<\/p>\n
Firma SaaS, z kt\u00f3r\u0105 wsp\u00f3\u0142pracowali\u015bmy, mia\u0142a problem z przypadkowymi zmianami na produkcji \u2013 kto\u015b r\u0119cznie modyfikowa\u0142 konfiguracj\u0119 Nginx i powodowa\u0142 przestoje. Wdro\u017cenie GitOps z wykorzystaniem ArgoCD i repozytori\u00f3w Git wyeliminowa\u0142o te zdarzenia ca\u0142kowicie. Czas przywracania po awarii spad\u0142 z 2 godzin do 10 minut.<\/p>\n
Trzeci b\u0142\u0105d to pipeline, kt\u00f3ry zamiast pomaga\u0107, przeszkadza. Z jednej strony widz\u0119 zespo\u0142y, kt\u00f3re maj\u0105 zbyt prosty proces \u2013 bez test\u00f3w, bez automatycznego wdra\u017cania, wszystko r\u0119cznie. Z drugiej strony s\u0105 te\u017c takie, kt\u00f3re maj\u0105 prze\u0142adowany pipeline \u2013 50 etap\u00f3w, kt\u00f3re trwaj\u0105 godzin\u0119, a po\u0142owa z nich to martwe kontrole, kt\u00f3re nigdy nie wykry\u0142y b\u0142\u0119du. Efekt? Programi\u015bci czekaj\u0105 na wdro\u017cenie, blokuj\u0105 si\u0119 na sobie i unikaj\u0105 cz\u0119stych deploy\u00f3w.<\/p>\n
D\u0142ugi czas budowania i wdra\u017cania hamuje iteracj\u0119. Zamiast wypuszcza\u0107 ma\u0142e zmiany kilka razy dziennie, zesp\u00f3\u0142 robi du\u017ce release raz w tygodniu, co zwi\u0119ksza ryzyko b\u0142\u0119d\u00f3w i konflikt\u00f3w. Ponadto, je\u015bli pipeline cz\u0119sto si\u0119 psuje z b\u0142ahych powod\u00f3w (np. flaky testy), programi\u015bci trac\u0105 zaufanie do procesu i zaczynaj\u0105 go omija\u0107 \u2013 co jest jeszcze gorsze.<\/p>\n
Pipeline powinien by\u0107 projektowany w my\u015bl zasady: jak najszybciej dawa\u0107 feedback. Najpierw szybkie testy (unit, lint, build), potem powolne (integracyjne, e2e) je\u015bli przejdzie pierwszy etap. Warto r\u00f3wnie\u017c u\u017cywa\u0107 cache dla zale\u017cno\u015bci, buildu warstwowego i ograniczy\u0107 liczb\u0119 etap\u00f3w do niezb\u0119dnego minimum. Idealnie, czas od pusha do wdro\u017cenia na staging nie powinien przekracza\u0107 10-15 minut.<\/p>\n
Startup technologiczny mia\u0142 pipeline trwaj\u0105cy 45 minut \u2013 g\u0142\u00f3wnie przez buildowanie obraz\u00f3w Docker od zera za ka\u017cdym razem i uruchamianie pe\u0142nego zestawu test\u00f3w e2e przy ka\u017cdej zmianie. Po optymalizacji (cache warstw, r\u00f3wnoleg\u0142e testy, dzielenie pipeline na szybkie i wolne) czas spad\u0142 do 8 minut. Cz\u0119stotliwo\u015b\u0107 wdro\u017ce\u0144 wzros\u0142a z 1 raz w tygodniu do 3-4 razy dziennie, a liczba b\u0142\u0119d\u00f3w produkcyjnych spad\u0142a o 40%.<\/p>\n
Infrastruktura to nie tylko \u201ekwestia techniczna\u201d \u2013 to bezpo\u015bredni wp\u0142yw na tempo pracy zespo\u0142u, koszty operacyjne i satysfakcj\u0119 programist\u00f3w. Trzy opisane b\u0142\u0119dy \u2013 brak reprodukowalnych \u015brodowisk, brak wersjonowania infrastruktury i \u017ale zaprojektowany pipeline CI\/CD \u2013 to najcz\u0119stsze pu\u0142apki, kt\u00f3re widz\u0119 w ma\u0142ych i \u015brednich firmach. Na szcz\u0119\u015bcie ka\u017cde z nich mo\u017cna naprawi\u0107 stosunkowo szybko i tanio, a zwrot z inwestycji liczony jest w tygodniach. Je\u015bli tw\u00f3j zesp\u00f3\u0142 ci\u0105gnie nogami, zanim obwiniasz ludzi \u2013 sp\u00f3jrz na infrastruktur\u0119. Cz\u0119sto to ona jest prawdziwym winowajc\u0105.<\/p>\n","protected":false},"excerpt":{"rendered":"
Wprowadzenie Ka\u017cdy CTO i founder wie, \u017ce czas programist\u00f3w to najdro\u017cszy zas\u00f3b w firmie. Ale czy wiesz, \u017ce wed\u0142ug bada\u0144 Stripe a\u017c 32% czasu deweloper\u00f3w marnuje si\u0119 na zadania zwi\u0105zane z zarz\u0105dzaniem infrastruktur\u0105, a nie na pisaniu kodu? W ma\u0142ych i \u015brednich firmach odsetek ten bywa jeszcze wy\u017cszy \u2013 programi\u015bci zamiast tworzy\u0107 nowe funkcje, konfiguruj\u0105<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[482,425,92,447],"class_list":["post-2708","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-bledy-w-devops","tag-infrastruktura-it","tag-optymalizacja-kosztow","tag-wydajnosc-zespolu-it"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2708","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2708"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2708\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2708"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2708"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2708"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}