FinOps i Agile: upravljanje troškovima cloud infrastrukture u agilnim IT organizacijama

Key Takeaways – šta je najbitnije u ovom tekstu

• Prelazak na cloud promenio je način na koji kompanije troše novac. Umesto klasičnih kapitalnih investicija (CAPEX) koje su odobravane jednom godišnje, svaki developer danas jednim klikom ili linijom Terraform koda pokreće operativne troškove (OPEX) u realnom vremenu.

• FinOps i Agile nisu suprotstavljeni koncepti, već dve strane istog novčića. Dok Agile daje razvojnim timovima autonomiju i brzinu isporuke, FinOps (Cloud Financial Management) uvodi finansijsku odgovornost u sam proces donošenja inženjerskih odluka, bez vraćanja na spore birokratske procedure.

• Rasipanje resursa u oblaku (Cloud Waste) dostiže alarmantne razmere. Prema industrijskim izveštajima, organizacije u proseku gube oko 30% svog cloud budžeta na zaboravljene testne servere, predimenzionisane Kubernetes klastere i neiskorišćene baze podataka.

• Ukupan račun za cloud je beskorisna metrika bez konteksta. Pravi pokazatelj zdravlja biznisa je Unit Economics (jedinična ekonomija) – koliko vas košta infrastruktura po jednom aktivnom korisniku, jednoj transakciji ili jednom API pozivu.

• Shift Left FinOps pomera kontrolu troškova u fazu dizajna i pisanja koda. Umesto da finansijski direktor (CFO) u panici gasi požare na kraju meseca kada stigne faktura, timovi dobijaju procenu troškova direktno u Pull Request-u pre nego što kod ode u produkciju.

• U 2026. godini, AI i GPU infrastruktura postaju najveći test za FinOps zrelost. Masovno uvođenje velikih jezičkih modela (LLM) i AI agenata u produkciju promenilo je strukturu troškova, čineći optimizaciju inferencije i praćenje potrošnje po tokenu pitanjem opstanka profitabilnosti.

Kulturološki šok: kada developer sa kreditnom karticom sretne finansijskog direktora

Prvi je u mesecu. Finansijski direktor (CFO) otvara elektronsku poštu, vidi mesečnu fakturu od Amazon Web Services-a (AWS) ili Microsoft Azure-a i na trenutak pomisli da je u pitanju štamparska greška. Račun je za 42% veći nego prošlog meseca. Niko u upravnom odboru nije odobrio novu kapitalnu investiciju, broj korisnika nije porastao za 42%, niti je lansiran novi proizvod.

Šta se dogodilo?

Jedan Agile tim je tokom prethodnog sprinta testirao novi algoritam za obradu podataka, podigao nekoliko snažnih instanci sa grafičkim procesorima (GPU) u petak po podne i jednostavno zaboravio da ih ugasi preko vikenda. Drugi tim je podesio automatsko skaliranje (autoscaling) bez gornjeg limita, pa je jedan loše napisan upit tokom noći pokrenuo desetine novih čvorova. Treći tim je ostavio uključeno detaljno logovanje u produkciji, generišući terabajte podataka koji se skupo naplaćuju pri svakom prenosu između različitih zona dostupnosti (cross-AZ data transfer).

Dobrodošli u realnost savremenog razvoja softvera.

Pre petnaestak godina, nabavka hardvera bila je spor, bolan i strogo kontrolisan proces. Ako vam je trebao novi server, pisali ste zahtev, čekali odobrenje budžeta, pregovarali sa dobavljačima, čekali isporuku tri nedelje, a zatim ga fizički montirali u serversku salu. Finansije su imale apsolutnu kontrolu nad svakim dinarom jer se novac trošio unapred kroz CAPEX (Capital Expenditure – kapitalne izdatke).

Cloud infrastruktura je taj model srušila preko noći. Prešli smo na OPEX (Operational Expenditure – operativne izdatke) i model plaćanja po potrošnji (pay-as-you-go). To je donelo neverovatnu agilnost. Timovi više ne čekaju mesecima na resurse – oni ih definišu kao kod (Infrastructure as Code) i podižu za nekoliko sekundi.

Međutim, ta sloboda je sa sobom donela jednu neugodnu istinu: svaki inženjer u kompaniji je preko noći postao osoba sa ovlašćenjem da troši novac firme u realnom vremenu. A niko ga tokom školovanja nije naučio kako funkcioniše računovodstvo, amortizacija ili marža profita.

Šta je zapravo FinOps i zašto nije samo „rezanje troškova“?

Kada računi za cloud počnu da izmiču kontroli, prva reakcija tradicionalnog menadžmenta je uvek ista: panika, zamrzavanje budžeta i slanje direktive inženjerima da „odmah smanje troškove za 30%“. Takav pristup u agilnim organizacijama redovno završava katastrofom. Inženjeri pod pritiskom gase kritične resurse, degradiraju performanse aplikacije, ugrožavaju stabilnost sistema i gube motivaciju jer osećaju da im neko vezuje ruke.

Upravo kao odgovor na ovaj haos nastao je FinOps (skraćeno od Cloud Financial Operations ili Cloud Financial Management).

Prema zvaničnoj definiciji organizacije FinOps Foundation, koja posluje u okviru Linux fondacije, FinOps je operativni model i kulturološka praksa koja donosi finansijsku odgovornost u promenljivi model potrošnje u oblaku, omogućavajući distribuiranim timovima da donose informisane poslovne odluke balansirajući između brzine, troškova i kvaliteta.

Obrati pažnju na te tri reči na kraju definicije: brzina, troškovi i kvalitet.

FinOps nije odeljenje za nabavku koje sedi u podrumu i viče „ne može“ svaki put kada programer zatraži jaču bazu podataka. FinOps nije ni prosto kresanje budžeta. Ponekad je najbolja FinOps odluka da povećate potrošnju u cloudu za 50.000 evra mesečno, ako će vam to doneti 300.000 evra novog prihoda i osvojiti novo tržište pre konkurencije. Suština FinOps-a nije da potrošite najmanje novca, već da izvučete maksimalnu poslovnu vrednost iz svakog evra koji uložite u cloud infrastrukturu.

Ceo životni ciklus FinOps prakse odvija se kroz tri kontinuirane iterativne faze koje se savršeno uklapaju u agilni način rada:

1. Inform (informisanje): Prvi korak je potpuna vidljivost i alokacija troškova. Ne možete upravljati onim što ne možete da izmerite. U ovoj fazi se računi od cloud provajdera raščlanjuju tako da svaki tim, svaki proizvod i svaki mikroservis tačno znaju koliko troše u realnom vremenu. Nema više jedne zajedničke fakture koju niko ne razume.

2. Optimize (optimizacija): Kada timovi vide svoje troškove, počinje pametna optimizacija. Ona ide u dva pravca. Prvi je optimizacija cena (rate optimization) – kupovina rezervisanih instanci (Reserved Instances), Savings Plan-ova ili korišćenje Spot instanci za zadatke koji mogu da podnesu prekid. Drugi pravac je optimizacija upotrebe (usage optimization) – gašenje nekorišćenih resursa, smanjenje predimenzionisanih mašina (rightsizing) i refaktorisanje neefikasnog koda.

3. Operate (operativno upravljanje): Treća faza pretvara ove prakse u svakodnevnu naviku. Definišu se jasne metrike uspeha, automatizuje se gašenje razvojnih okruženja van radnog vremena, uvode se automatska upozorenja za anomalije u potrošnji i kontinuirano se prati usklađenost između inženjerskih odluka i poslovnih ciljeva kompanije.

Sudar svetova: zašto klasično budžetiranje ubija Agile, a nekontrolisani Agile bankrotira firmu

Da bismo razumeli zašto je spoj FinOps i Agile metodologije toliko težak, ali i toliko neophodan, moramo pogledati kako funkcionišu dva sveta unutar iste kompanije.

Finansijski sektor je vekovima treniran da voli predvidljivost. Finansijski direktor pravi godišnji budžet u novembru, deli ga na četiri kvartala i očekuje da stvarna potrošnja odstupa od plana za najviše dva do tri procenta. Za finansije, svako neplanirano odstupanje je znak lošeg upravljanja i rizika.

Agile timovi žive u potpuno drugačijem univerzumu. Njihov horizont planiranja je dvonedeljni sprint. Njihov posao je da eksperimentišu, brzo isprobavaju nove ideje, skaliraju ono što korisnici prihvate i odbacuju ono što ne radi. U takvom okruženju, unapred fiksirani godišnji budžet za infrastrukturu je čista fikcija. Kako Product Owner u novembru može da zna koliko će CPU ciklusa ili S3 prostora trošiti funkcionalnost koju će tim osmisliti tek u maju sledeće godine na osnovu povratnih informacija sa tržišta?

Kada ove dve filozofije sudarite bez prevodioca, dobijate institucionalnu paralizu:

• Ako pobede tradicionalne finansije, timovi dobijaju stroge limite i moraju da pišu zahteve za svaku promenu infrastrukture. Agile umire, isporuka se usporava na nivo iz 2005. godine, a najbolji programeri odlaze kod konkurencije.

• Ako pobedi nekontrolisani Agile, timovi imaju potpunu slobodu bez ikakvog uvida u cenu svojih odluka. Troškovi rastu eksponencijalno, marža profita se topi, a kompanija na kraju godine shvata da joj cloud provajder uzima veći deo zarade nego što ostaje akcionarima.

FinOps nastupa kao prevodilac između ova dva sveta. On finansijama daje predvidljivost kroz trendove i jediničnu ekonomiju, dok inženjerima zadržava autonomiju i brzinu, ali uz jasan finansijski okvir (guardrails) unutar kojeg se kreću.

Cloud Waste (rasipanje resursa u oblaku): tiha crna rupa modernog IT-a

Koliko novca IT organizacije zapravo bacaju u vetar zbog lošeg upravljanja cloud resursima? Brojke su poražavajuće.

Prema godišnjim izveštajima kompanije Flexera (State of the Cloud Report), sami IT lideri procenjuju da između 27% i 32% njihove ukupne potrošnje u cloudu predstavlja čisto rasipanje (Cloud Waste). To znači da ako vaša kompanija troši milion evra godišnje na AWS, Azure ili Google Cloud, oko 300.000 evra odlazi bukvalno ni na šta – bez ikakvog doprinosa performansama, bezbednosti ili korisničkom iskustvu.

Gde se tačno krije taj bačeni novac u tipičnoj agilnoj organizaciji?

1. Zombi resursi (Zombie Infrastructure): Virtuelne mašine koje su podignute za potrebe testiranja jednog pull request-a pre šest meseci i nikada nisu obrisane. Nepovezani diskovi (unattached EBS volumes) koji ostaju da vise u sistemu i naplaćuju se svakog meseca nakon što ste obrisali sam server. Stare rezervne kopije (snapshots) baza podataka iz 2023. godine koje nikome više ne trebaju, ali zauzimaju petabajte prostora.

2. Predimenzionisani resursi (Overprovisioning): Iz straha da aplikacija ne uspori pod opterećenjem, developeri po navici biraju instancu sa 32 GB RAM-a i 8 procesorskih jezgara, iako aplikacija u proseku troši jedva 12% tog kapaciteta. U svetu mikroservisa i Kubernetes-a, ovaj problem se umnožava stotinama puta kroz loše podešene requests i limits parametre za kontejnere.

3. Razvojna i testna okruženja koja rade 24/7: Produkcija mora da radi non-stop, 168 sati nedeljno. Ali zašto vaša dev, staging i QA okruženja rade punom parom u nedelju u tri ujutru, kada svi programeri spavaju? Samo automatsko gašenje neprodukcionih okruženja van radnog vremena (vikendom i noću) donosi uštedu od preko 60% na tim resursima.

4. Skrivene mrežni troškovi (Egress i NAT Gateway zamke): Cloud provajderi obožavaju da vam besplatno prime podatke u svoj oblak, ali naplaćuju svaki gigabajt koji iz njega izađe ili prođe kroz mrežne prolaze. Loše dizajnirana arhitektura u kojoj mikroservisi neprestano razmenjuju velike količine podataka između različitih regiona ili preko skupih NAT Gateway servisa može generisati veći račun za mrežu nego za same servere.

Unit Economics (jedinična ekonomija): jedina metrika koju razumeju i inženjeri i upravni odbor

Jedna od najvećih grešaka u komunikaciji oko cloud troškova jeste posmatranje apsolutnog iznosa na fakturi.

Zamislite da vam je račun za cloud u januaru bio 20.000 evra, a u junu 40.000 evra. Da li je to dobro ili loše? Bez dodatnog konteksta, na to pitanje je nemoguće odgovoriti. Ako vam je u istom periodu broj aktivnih korisnika koji plaćaju pretplatu porastao sa 10.000 na 50.000, onda je dupliranje cloud računa zapravo fantastičan uspeh – vaš trošak po korisniku je prepolovljen, a profitabilnost kompanije je eksplodirala. Ali ako vam je broj korisnika ostao isti, a račun se udvostručio, imate ozbiljan arhitektonski i finansijski požar.

Zato zrele FinOps organizacije napuštaju posmatranje ukupnog računa i prelaze na Unit Economics (jediničnu ekonomiju) – povezivanje troškova cloud infrastrukture direktno sa poslovnim metrikama proizvoda.

Konkretni primeri jediničnih metrika izgledaju ovako:

• Za e-commerce platformu: Trošak cloud infrastrukture po jednoj završenoj porudžbini (npr. 0,04 evra po transakciji).

• Za SaaS B2B softver: Trošak infrastrukture po jednom aktivnom klijentu (tenant-u) mesečno.

• Za streaming servis: Trošak isporuke po jednom satu strimovanog video sadržaja.

• Za AI proizvod: Trošak GPU inferencije po jednom obrađenom korisničkom zahtevu (promptu).

Kada inženjerskom timu kažete „Smanjite AWS račun“, oni to doživljavaju kao dosadan administrativni namet. Ali kada im kažete: „Naša trenutna cena obrade jedne transakcije u cloudu je 0,12 evra, što nam jede 40% marže. Cilj nam je da kroz refaktorisanje keširanja u naredna dva sprinta spustimo tu cenu na 0,05 evra po transakciji“, odjednom ste im dali jasan, merljiv inženjerski izazov. Programeri vole da rešavaju probleme optimizacije kada vide direktnu vezu između svog koda i uspeha proizvoda.

Shift Left FinOps: ugradnja svesti o troškovima u svaki Agile sprint

U razvoju softvera već godinama uspešno primenjujemo koncept Shift Left kada su u pitanju testiranje i bezbednost (DevSecOps). Shvatili smo da je daleko jeftinije i brže otkriti bezbednosni propust dok developer piše kod na svom laptopu, nego čekati da hakeri probiju produkciju tri meseca kasnije.

Potpuno isti princip danas postaje standard u upravljanju cloud troškovima kroz Shift Left FinOps. Umesto da troškove analiziramo retroaktivno – gledajući u retrovizor na kraju meseca kada je novac već potrošen – svest o ceni infrastrukture ugrađujemo u najranije faze Agile razvojnog ciklusa.

Kako to izgleda u praksi kroz sve ceremonije jednog agilnog tima?

1. Pre svega – Tagging strategija (označavanje resursa):

Pre nego što uopšte počnete sa naprednim alatima, morate uvesti strogu disciplinu označavanja (tagging/labeling) svakog resursa u cloudu. Svaka virtuelna mašina, baza podataka, kontejner ili S3 bucket mora imati obavezne oznake: kom timu pripada (team: checkout), kom proizvodu (product: mobile-app), kom okruženju (env: production) i ko je vlasnik (owner: petar.petrovic). Pravilo u zrelim timovima je surovo i jednostavno: ako resurs nema propisane tagove, automatizovana skripta ga briše svake noći u ponoć. Bez ovakve higijene, alokacija troškova je nemoguća.

2. Backlog Refinement i Sprint Planning:

Kada tim procenjuje složenost nove funkcionalnosti (story points), pored tehničke složenosti postavlja se i pitanje: „Kakav je finansijski otisak ove funkcionalnosti u produkciji?“ Ako uvodimo pretragu u realnom vremenu preko Elasticsearch klastera, koliko će nas taj klaster koštati mesečno na očekivanom broju korisnika? Da li postoji jeftinije arhitektonsko rešenje koje zadovoljava iste poslovne zahteve?

3. FinOps u Pull Request-u (CI/CD integracija):

Zahvaljujući modernim alatima kao što su Infracost i slični open-source i komercijalni dodaci, provera troškova postaje sastavni deo CI/CD cevovoda. Kada developer otvori Pull Request u kojem menja Terraform ili CloudFormation konfiguraciju (na primer, menja tip baze podataka sa db.t3.medium na db.r6g.2xlarge), automatski bot u komentaru ispod koda odmah ispisuje: „Ova promena će povećati mesečne troškove AWS infrastrukture za +485,00 USD (+310%).“ Developer i reviewer odmah vide finansijsku posledicu pre nego što kliknu na dugme Merge.

4. Definition of Done (definicija završenog posla):

U listu kriterijuma koji moraju biti ispunjeni da bi se zadatak smatrao završenim ulaze i FinOps pravila: resursi su pravilno tagovani, postavljeni su limiti za autoscaling, podešeni su alarmi za anomalije u potrošnji (budget alerts) i definisana je politika zadržavanja podataka (data retention policy) za logove i backup-ove.

Praktičan primer iz prakse: kako izgleda dvonedeljni sprint kada FinOps sedi za stolom

Zamislimo domaći SaaS tim od osam ljudi koji razvija platformu za analizu e-commerce prodavnica. Klijenti su zatražili novu opciju: automatsko generisanje nedeljnih PDF izveštaja sa AI analizom trendova prodaje za svakog trgovca.

Pristup bez FinOps-a (klasični „brzi“ Agile):

Tim u prvom sprintu pravi rešenje koje radi na zahtev. Svaki put kada korisnik otvori stranicu sa izveštajima, backend pokreće teške SQL upite nad sirovim podacima, šalje velike kontekste ka komercijalnom LLM API-ju i generiše PDF u realnom vremenu na snažnim serverima koji rade non-stop. Funkcionalnost je gotova za dve nedelje. Svi su srećni. Mesec dana kasnije, stigao je račun: troškovi baze podataka i AI poziva skočili su za 18.000 evra mesečno jer korisnici osvežavaju stranicu po deset puta dnevno, iako se podaci menjaju samo jednom nedeljno.

Pristup sa FinOps kulturom ugrađenom u Agile:

Tokom planiranja sprinta, tim (zajedno sa Product Owner-om i FinOps savetnikom) postavlja pitanje jedinične ekonomije: kolika je naša pretplata po klijentu i koliko smemo da potrošimo na generisanje ovog izveštaja? Računica pokazuje da trošak po klijentu ne sme preći 0,30 evra mesečno.

Inženjeri odmah menjaju arhitekturu pre nego što napišu prvu liniju koda:

• Umesto generisanja izveštaja u realnom vremenu pri svakom kliku, odlučuju se za asinhronu obradu (batch processing) jednom nedeljno u nedelju noću.

• Za tu obradu koriste Spot instance (koje su do 70-80% jeftinije od standardnih on-demand instanci) jer posao nije vremenski kritičan u sekundu i može bez problema da se nastavi ako se instanca prekine.

• Generisani PDF i AI sažetak čuvaju se u jeftinom objektnom skladištu (S3) sa definisanim životnim ciklusom (lifecycle policy) koji briše izveštaje starije od 90 dana.

• Za AI analizu koriste manji, optimizovani model za strukturiranje podataka, a skuplji model samo za finalnu sintezu teksta, smanjujući potrošnju tokena za 65%.

Rezultat? Funkcionalnost je isporučena u istom roku od dva nedelje, korisnici dobijaju izveštaj trenutno (jer se učitava gotov fajl sa S3, bez čekanja), a mesečni trošak po klijentu iznosi 0,08 evra umesto planiranih 0,30 evra. Brzina, kvalitet i profitabilnost su u savršenom balansu.

Veza između SRE-a, arhitekture i FinOps-a: sveto trojstvo modernog inženjeringa

U modernim tehnološkim organizacijama, FinOps ne živi u vakuumu. On je neraskidivo povezan sa drugim ključnim disciplinama o kojima redovno pišemo na portalu ITNetwork, pre svega sa Site Reliability Engineering-om (SRE) i Agile Architecture pristupom.

Razlog je jednostavan: svaka odluka o pouzdanosti i arhitekturi ima direktnu cenu u evrima ili dolarima.

Uzmimo za primer dostupnost sistema (SLO – Service Level Objective). Ako Product Owner i arhitekta iz čiste sujete odluče da interni alat za upravljanje zalihama mora imati dostupnost od 99,999% („pet devetki“), to zahteva multi-region aktivno-aktivnu arhitekturu, sinhronu replikaciju baza podataka preko okeana i dupliranu mrežnu infrastrukturu. Takva arhitektura može koštati pet puta više od standardne arhitekture sa dostupnošću od 99,9%, dok poslovni gubitak od dvadeset minuta zastoja godišnje iznosi zanemarljivih nekoliko stotina evra. FinOps pomaže SRE timovima da kvantifikuju cenu svake „devetke“ pouzdanosti i donesu racionalnu poslovnu odluku.

Slična veza postoji i sa automatizacijom poslovnih procesa i pametnom primenom veštačke inteligencije, temama koje detaljno obrađujemo na portalu Joombooz. Kroz brojne primere u praksi jasno se vidi da tehnologija – bilo da je reč o cloud infrastrukturi ili AI agentima – donosi stvarnu konkurentsku prednost tek onda kada se njome upravlja kroz jasne poslovne metrike, a ne kroz slepo gomilanje alata i resursa.

Najčešće greške pri uvođenju FinOps praksi (i kako ih izbeći)

Mnoge kompanije sa najboljom namerom pokrenu FinOps inicijativu, ali se posle šest meseci vrate na staro. Ovo su četiri najčešće zamke koje treba izbeći po svaku cenu:

1. Pretvaranje FinOps tima u centralizovanu policiju:

   Ako formirate FinOps tim i date mu zadatak da juri programere po Slack-u i tera ih da gase servere, stvorili ste toksičnu atmosferu. U zrelom modelu, centralni FinOps tim obezbeđuje platformu, alate, vidljivost i pregovara o popustima sa cloud provajderima, dok su pojedinačni Agile timovi vlasnici svojih troškova i sami donose odluke o optimizaciji.

2. Kupovina dugoročnih ugovora (Reserved Instances / Savings Plans) pre optimizacije arhitekture:

   Ovo je klasična početnička greška. Kompanija vidi da troši 50.000 evra mesečno na određene servere, pa kupi trogodišnji Savings Plan kako bi dobila 40% popusta. Tri meseca kasnije, inženjeri refaktorišu aplikaciju, pređu na serverless ili kontejnere i shvate da im ti serveri više uopšte ne trebaju – ali su ugovorom vezani da ih plaćaju još skoro tri godine. Pravilo glasi: prvo optimizujte upotrebu i arhitekturu (rightsizing), pa tek onda kupujte finansijske obaveze (commitments).

3. Fokus isključivo na računarske resurse (Compute), dok se ignorišu podaci i licence:

   Svi gledaju cenu virtuelnih mašina (EC2, Azure VMs), dok se u pozadini gomilaju ogromni troškovi komercijalnih licenci za baze podataka, alata za praćenje (observability platforme poput Datadog-a koje često koštaju više od same AWS infrastrukture) i mrežnog saobraćaja. Kompletan FinOps mora obuhvatiti ceo tehnološki stek (full-stack cost visibility).

4. Očekivanje da je FinOps jednokratan projekat:

   „Angažovaćemo konsultante na dva meseca, oni će nam smanjiti račun za 25% i završili smo posao.“ Nećete. Cloud okruženje u agilnoj kompaniji je živ organizam koji se menja svakog dana. Bez kontinuirane kulturološke promene u samim sprintovima, troškovi će se vratiti na stari nivo za manje od jednog kvartala.

Budućnost FinOps-a (2026 – 2030): AI/GPU eksplozija, FOCUS standard i GreenOps

Dok privodimo kraju 2026. godinu i gledamo ka periodu do 2030, disciplina FinOps-a prolazi kroz najdramatičniju transformaciju od svog nastanka. Tri velika trenda već sada menjaju pravila igre za svaku IT organizaciju:

1. FinOps za AI (eksplozija troškova GPU-a i LLM inferencije):

Tradicionalni cloud modeli troškova bili su zasnovani na predvidljivom rastu CPU-a i memorije. Masovno uvođenje generativne AI, RAG (Retrieval-Augmented Generation) sistema i autonomnih AI agenata u produkciju u 2026. godini potpuno je srušilo te modele. Jedan neoptimizovan AI agent koji u petlji poziva skupi jezički model sa ogromnim kontekstom može za nekoliko sati potrošiti hiljade dolara. Zbog toga se FinOps danas širi sa klasične cloud infrastrukture na praćenje potrošnje tokena, troškova vektorskih baza podataka, GPU klastera i finog podešavanja modela (fine-tuning vs. inference).

2. FOCUS standard (FinOps Open Cost and Usage Specification):

Većina modernih kompanija danas koristi više cloud provajdera istovremeno (multi-cloud), uz brojne SaaS platforme (Snowflake, Databricks, Datadog, OpenAI). Do skoro je spajanje faktura od AWS-a, Azure-a i Google Cloud-a bila noćna mora jer svaki provajder koristi drugačiju terminologiju i format podataka. Zbog toga je FinOps Foundation pokrenuo otvorenu specifikaciju FOCUS (FinOps Open Cost and Usage Specification), koju su tokom 2025. i 2026. godine usvojili svi vodeći cloud i SaaS provajderi. FOCUS donosi jedinstven, standardizovan format podataka o troškovima, omogućavajući timovima da na jednom mestu uporede svaki evro potrošen u bilo kom oblaku.

3. Spoj FinOps-a i GreenOps-a (održivost kao merljiva metrika):

Regulative u Evropskoj uniji i globalni ESG standardi sve strože zahtevaju od kompanija da izveštavaju o svom ugljeničnom otisku (carbon footprint). Dobra vest za inženjere je da su FinOps i GreenOps prirodni saveznici: svaki ugašeni zombi server, svaki optimizovani upit ka bazi i svaki smanjeni prenos podataka preko mreže istovremeno smanjuju i mesečni račun za cloud i potrošnju električne energije u data centrima. Efikasan kod je istovremeno i jeftiniji i ekološki čistiji.

Zaključak: svaka linija koda danas je i odluka o kupovini

Doba u kojem su programeri pisali kod ne razmišljajući o ceni hardvera na kojem se taj kod izvršava zauvek je završeno. U cloud-native i AI-native eri, svaka arhitektonska odluka je istovremeno i finansijska odluka, a svaka linija koda je i odluka o kupovini resursa.

Spajanje FinOps-a i Agile-a nije pokušaj finansija da ukrote i uspore razvojne timove. Naprotiv, to je način da se Agile timovima da puna zrelost i autonomija. Kada inženjeri imaju trenutnu vidljivost troškova, jasne jedinične metrike i razumevanje poslovne vrednosti onoga što grade, oni sami prave bolja, elegantnija i skalabilnija rešenja.

Kompanije koje ovaj spoj savladaju na vreme neće samo uštedeti desetine procenata na mesečnim računima za AWS, Azure ili Google Cloud. One će osloboditi ogroman kapital koji mogu ponovo da ulože u inovacije, nove proizvode i ljude – dok će njihova konkurencija i dalje u panici gledati u fakture prvog u mesecu pitajući se gde je nestao sav profit.

Često postavljana pitanja (FAQ)

Šta je FinOps?

FinOps (Cloud Financial Operations) je operativni model i kulturološka praksa koja spaja finansije, inženjering i biznis timove kako bi se uvela finansijska odgovornost u promenljivi model potrošnje cloud infrastrukture, omogućavajući donošenje informisanih odluka između brzine, troškova i kvaliteta.

Kako FinOps i Agile funkcionišu zajedno bez usporavanja razvoja?

FinOps ne vraća spore birokratske procedure odobravanja budžeta, već ugrađuje informacije o troškovima direktno u Agile ceremonije i alate koje developeri već koriste (kao što su Sprint Planning, Pull Request provere i Definition of Done). Timovi zadržavaju brzinu i autonomiju, ali dobijaju jasne finansijske okvire i povratne informacije u realnom vremenu.

Šta je Cloud Waste i koliko iznosi u proseku?

Cloud Waste (rasipanje resursa u oblaku) označava plaćanje cloud resursa koji ne donose nikakvu poslovnu vrednost, kao što su zaboravljene virtuelne mašine, predimenzionisani serveri, nekorišćeni diskovi i testna okruženja koja rade vikendom. Prema industrijskim istraživanjima poput izveštaja kompanije Flexera, u proseku oko 30% ukupne cloud potrošnje odlazi na rasipanje.

Šta je Unit Economics (jedinična ekonomija) u FinOps-u?

Unit Economics povezuje troškove cloud infrastrukture sa konkretnim poslovnim pokazateljima proizvoda, kao što su trošak po aktivnom korisniku, trošak po završenoj transakciji ili trošak po obrađenom AI zahtevu. Ova metrika omogućava kompaniji da razlikuje zdrav rast troškova (izazvan rastom broja kupaca) od loše i neefikasne arhitekture.

Šta znači pojam Shift Left FinOps?

Shift Left FinOps predstavlja pomeranje analize i kontrole troškova u najranije faze životnog ciklusa razvoja softvera – u fazu arhitektonskog dizajna i pisanja koda. Umesto da se problemi otkrivaju tek kada stigne mesečni račun, alati ugrađeni u CI/CD procese odmah pokazuju programeru koliko će njegova izmena koda koštati u produkciji.

Koja je razlika između CAPEX i OPEX modela u IT infrastrukturi?

CAPEX (Capital Expenditure) podrazumeva velike, jednokratne kapitalne investicije unapred, poput kupovine fizičkih servera za sopstveni data centar. OPEX (Operational Expenditure) predstavlja tekuće operativne troškove koji se plaćaju mesečno na osnovu stvarne potrošnje, što je osnovni finansijski model cloud provajdera.

Zašto je Tagging (označavanje resursa) prvi korak u svakoj FinOps strategiji?

Bez doslednog označavanja svakog cloud resursa (na primer po timu, proizvodu, projektu i okruženju), nemoguće je precizno utvrditi ko troši novac i zašto. Tagging omogućava potpunu vidljivost i podelu troškova (showback i chargeback), što je osnovni preduslov za bilo kakvu optimizaciju.

Šta je FOCUS standard u FinOps svetu?

FOCUS (FinOps Open Cost and Usage Specification) je otvorena specifikacija koju je razvila FinOps Foundation kako bi ujednačila format i terminologiju podataka o naplati kod svih velikih cloud i SaaS provajdera (AWS, Azure, Google Cloud, Snowflake, Databricks), olakšavajući analizu troškova u multi-cloud okruženjima.

Kako veštačka inteligencija (AI) utiče na troškove cloud infrastrukture?

Masovna upotreba velikih jezičkih modela (LLM) i GPU infrastrukture u 2026. godini donela je nepredvidive i visoke troškove zasnovane na potrošnji tokena i inferenciji. Zbog toga moderni FinOps uključuje praćenje troškova po AI modelu, optimizaciju upita (prompt engineering), keširanje odgovora i izbor manjih, specijalizovanih modela tamo gde je to moguće.

Ko je odgovoran za FinOps u jednoj IT kompaniji?

FinOps nije odgovornost samo jednog čoveka ili jednog odeljenja. To je zajednička praksa u kojoj učestvuju izvršni menadžment (postavlja poslovne ciljeve), finansije (obezbeđuju budžetske okvire i predviđanja), Product Owner-i (određuju prioritete između novih funkcionalnosti i optimizacije) i inženjerski timovi (dizajniraju i održavaju troškovno efikasnu arhitekturu).