FinOps on yksi niistä termeistä, jotka tarkoittavat hyvin eri asioita riippuen yrityksen koosta. Fortune 500 -yritykselle se on 30 hengen tiimi, jolla on CFO sponsorina, työkalubudjetti suurempi kuin palkkalistasi ja neljännesvuosittaiset ohjausryhmät. Sinun 30 hengen SaaS-yrityksellesi se tarkoittaa suunnilleen: "miksi AWS-lasku on 27 % kalliimpi kuin viime kvartaalilla, ja kenen tehtävä on selvittää se?" Tämä artikkeli on jälkimmäistä ryhmää varten.

Ensin rauhoittavat uutiset: pilvihukka on tylsää. Valtaosa siitä syntyy samasta viidestä toistuvasta kaavasta, joka yrityksessä, joka mittakaavassa. Jouten seisova laskenta, jota kukaan ei sammuttanut. Ylimitoitetut instanssit, jotka provisioitiin huippukuormalle, joka ei koskaan palannut. Tägäämättömät resurssit, joita kukaan ei osaa kohdistaa, joten kukaan ei tunne vastuuta niistä. Unohdetut kehitys- ja staging-ympäristöt, jotka pyörivät ympäri vuorokauden ohjelmistolle, joka julkaistaan kaksi kertaa kuussa. Ja tallennustila, joka lojuu premium-tasoilla vuosia sen jälkeen, kun kukaan on sitä viimeksi lukenut. Mikään näistä ei vaadi FinOps Foundation -sertifikaattia korjatakseen. Kaikki ne vaativat, että joku oikeasti katsoo.

Yleisin näkemämme kaava ansaitsee oman kappaleensa. Kehittäjä käynnistää c5.4xlarge-instanssin kuormitustestiä varten torstaina. Testi päättyy perjantaina klo 16. Instanssi jää pyörimään viikonlopun yli, koska sen sammuttaminen on manuaalinen askel konsolissa, jota kukaan ei avaa lauantaina. Maanantain standupiin mennessä tiimi on polttanut 180 € jouten seisovaan koneeseen - ei osaamattomuuden vuoksi, vaan koska järjestelmän oletusarvo on "jatka laskuttamista". Kerro tämä jokaisella tiimillä, jokaisella viikonlopulla, jokaisella unohdetulla kokeilulla, ja saat merkittävän prosenttiosuuden infrastruktuuribudjetistasi tekemään täsmälleen ei mitään.

Miksi dashboardit eivät korjaa tätä? Koska näkyvyys ei koskaan ollut pullonkaula - pilvipalveluntarjoajallasi on jo cost explorer, etkä silti avaa sitä. Dashboard kertoo, mitä tapahtui sen jälkeen kun rahat ovat jo menneet, paikassa, jonka pitää muistaa käydä katsomassa, muodossa, joka vaatii kaksikymmentä minuuttia suodattamista ennen kuin se kertoo mitään toimintakelpoista. "Data on olemassa" -tilan ja "joku toimi sen perusteella" -tilan välissä on koko FinOpsin todellinen käytäntö, ja se on juuri se osa, johon pienellä tiimillä ei ole ylimääräistä kapasiteettia.

On myös rakenteellinen ongelma, jota dashboardit eivät ratkaise: multi-cloud-pirstaloituminen. Sillä hetkellä kun ajat AWS:ää tuotteelle, Hetzneriä eräajoille ja jonkun vuonna 2024 aloittamaa harhautunutta DigitalOcean-projektia, "paljonko kulutamme" lakkaa olemasta yksi ainoa vastaus. Jokainen palveluntarjoaja vie kulut omassa muodossaan, omalla aikataulullaan, omalla käsityksellään siitä, mikä projekti on. Useimmat pienet tiimit reagoivat seuraamalla ison laskun tarkasti ja antamalla pienten ajautua - näin 400 €/kk vuoto selviää kaksi vuotta hengissä.

Miltä FinOps sitten oikeasti näyttää tiimille, jolla ei ole FinOps-tiimiä? Kokemuksemme mukaan neljä tapaa kattaa suurimman osan arvosta. Yksi: yksi totuudenlähde kuluille kaikkien palveluntarjoajien yli, jaoteltuna palvelun, projektin ja ympäristön mukaan - ei siksi, että dashboardit korjaisivat asioita, vaan koska väittelyt kohdistamisesta kuolevat, kun kaikki näkevät samat luvut. Kaksi: poikkeamentunnistus, joka on kynnysarvoa älykkäämpää - pilvilaskut ovat luonnostaan kohinaisia, ja staattinen "hälytä minulle yli X €" joko laukeaa jatkuvasti tai ei koskaan; aitojen poikkeamien merkitseminen omasta perustasostasi on koneoppimisen työtä, ei cron-jobin ja toivon. Kolme: oikeankokoistamissuositukset säännöllisesti - kuukausittainen lista "nämä kaksitoista instanssia ovat ylimitoitettuja, tässä turvallinen pienempi koko, tässä säästö", jonka joku käy läpi viidessätoista minuutissa. Neljä: eskaloituvat budjettihälytykset - hiljainen varoitus insinöörille 80 %:ssa, kovempi tiiminvetäjälle 100 %:ssa, koska budjetti, josta kukaan ei ole vastuussa, on vain toive.

Huomaa, mikä kaikilla neljällä on yhteistä: ne lyhentävät silmukkaa havainnosta toimintaan. Siinä on koko peli. Ei enempää dataa - vähemmän etäisyyttä "järjestelmä huomasi" ja "ihminen päätti" välillä. Pieni tiimi ei tarvitse FinOps-käytäntöä; se tarvitsee ne kaksikymmentä minuuttia viikossa, jolloin kustannuspäätökset sattuvat olemaan hyvin valmisteltuja, valmiiksi priorisoituja ja yhdessä paikassa.

Juuri sen rakensimme Sencaihin: kulut palvelun, projektin ja ympäristön mukaan kaikkien yhdistettyjen palveluntarjoajien yli; koneoppimisen merkitsemät kustannuspoikkeamat; ajastetut oikeankokoistamissuositukset; eskaloituvat budjettihälytykset. Silmukka havainnosta toimintaan, puristettuna mahtumaan standupin sisään. Ja seuraava askel roadmapilla - Autopilot - koskee tämän silmukan sulkemista kokonaan tylsien tapausten osalta: tägättyjen dev-resurssien automaattinen pysäytys aikataulun mukaan, hyväksyttyjen oikeankokoistamisten suorittaminen huoltoikkunoiden aikana. Harkinta pysyy sinulla; napin painamisen ei tarvitse.

Jos haluat tietää, missä seisot tänään, tässä viidentoista minuutin harjoitus: hae viime kuukauden lasku jokaiselta käyttämältäsi palveluntarjoajalta - myös niiltä, jotka olit unohtanut. Järjestä palvelun mukaan. Ympyröi kaikki, mitä et pysty kohdistamaan käynnissä olevaan tuoteominaisuuteen kymmenessä sekunnissa. Useimmissa yrityksissä tuo ympyrä on 25-35 % kokonaissummasta. Se ei ole budjetointiongelma. Se on pelkkää entropiaa - ja entropia on hyvin, hyvin korjattavissa.