Olet varmasti miettinyt, kuinka paljon projektisi infrastruktuuri maksaa. Samalla on yllättävää: kustannusten kasvu ei ole lineaarista kuormituksen suhteen. Monet yrittäjät, huoltoasemat ja kehittäjät ymmärtävät salaa maksavansa liikaa. Mutta mitä varten tarkalleen?
Tyypillisesti kustannusten leikkaaminen johtuu yksinkertaisesti halvimman ratkaisun löytämisestä, AWS-suunnitelmasta tai fyysisten telineiden tapauksessa laitteistokokoonpanon optimoinnista. Ei vain sitä: itse asiassa kuka tahansa tekee tätä, kuten Jumala tahtoo: jos puhumme startupista, tämä on luultavasti johtava kehittäjä, jolla on paljon päänsärkyä. Suuremmissa toimistoissa asian hoitaa CMO/CTO, ja joskus pääjohtaja osallistuu asiaan henkilökohtaisesti yhdessä pääkirjanpitäjän kanssa. Yleensä ne ihmiset, joilla on tarpeeksi "ydinhuolenaiheita". Ja käy ilmi, että infrastruktuurilaskut kasvavat, mutta ne, joilla ei ole aikaa käsitellä sitä, käsittelevät sitä.
Jos sinun on ostettava vessapaperia toimistoon, sen tekee hankintapäällikkö tai siivousyrityksen vastuuhenkilö. Jos puhumme kehityksestä - johtaa ja CTO. Myynti - kaikki on myös selvää. Mutta vanhasta lähtien, kun "palvelinhuone" oli nimi kaappille, jossa oli tavallinen tornijärjestelmä, jossa oli hieman enemmän RAM-muistia ja pari kovalevyä raidissa, kaikki (tai ainakin monet) jättävät huomioimatta se, että kapasiteetin osto tulee hoitaa myös erikoiskoulutetun henkilön toimesta.
Valitettavasti historiallinen muisti ja kokemus osoittavat, että vuosikymmeniä tämä tehtävä siirrettiin "satunnaisille" ihmisille: kuka oli lähimpänä, pohti kysymyksen. Ja vasta äskettäin FinOps-ammatti alkoi muotoutua markkinoilla ja saada konkreettista muotoa. Tämä on sama erikoiskoulutettu henkilö, jonka tehtävänä on valvoa kapasiteetin ostoa ja käyttöä. Ja viime kädessä vähentämällä yrityksen kustannuksia tällä alueella.
Emme kannata luopumista kalliista ja tehokkaista ratkaisuista: jokaisen yrityksen on itse päätettävä, mitä se tarvitsee mukavaan elämään laitteisto- ja pilvitalleissa. Mutta ei voi olla kiinnittämättä huomiota siihen, että ajattelematon ostaminen "luettelon mukaan" ilman myöhempää käytön seurantaa ja analysointia monille yrityksille johtaa lopulta erittäin, erittäin merkittäviin tappioihin taustajärjestelmän "omaisuuden" tehottomasta hallinnasta.
Kuka on FinOps
Oletetaan, että sinulla on hyvämaineinen yritys, josta myyjät puhuvat "yrityksestä" hengähdyttävällä äänellä. Luultavasti "luettelon mukaan" ostit tusina tai kaksi palvelinta, AWS ja joitain muita "pieniä asioita". Mikä on loogista: suuressa yrityksessä tapahtuu jatkuvasti jonkinlaista liikettä - jotkut tiimit kasvavat, toiset hajoavat, toiset siirtyvät naapuriprojekteihin. Ja näiden liikkeiden yhdistelmä yhdessä "luettelopohjaisen" hankintamekanismin kanssa johtaa viime kädessä uusiin harmaisiin hiuksiin, kun tarkastellaan seuraavaa kuukausittaista infrastruktuurilaskua.
Mitä tehdä - jatkaa kärsivällisesti harmaata, maalata sen päälle tai selvittää syyt näiden lukuisten kauheiden nollien ilmestymiseen maksuun?
Olkaamme rehellisiä: saman AWS-tariffin hakemuksen hyväksyminen, hyväksyminen ja suora maksaminen yrityksen sisällä ei ole aina (todellisuudessa tuskin koskaan) nopeaa. Ja juuri jatkuvan yritysliikkeen vuoksi osa näistä samoista hankinnoista saattaa "kadota" jonnekin. Ja on triviaalia seisoa toimettomana. Jos tarkkaavainen järjestelmänvalvoja huomaa palvelinhuoneessaan omistajattoman telineen, niin pilvitariffien tapauksessa kaikki on paljon surullisempaa. Niitä voidaan säilyttää kuukausia - maksettu, mutta samaan aikaan kukaan ei enää tarvitse niitä osastolla, jolle ne ostettiin. Samaan aikaan kollegat naapuritoimistosta alkavat repiä pois ei-harmaita hiuksiaan paitsi pään kohdalta, myös muualta - he eivät ole pystyneet maksamaan suunnilleen samaa AWS-tariffia n:nneltä viikolta, mikä tarvitaan kipeästi.
Mikä on ilmeisin ratkaisu? Aivan oikein, luovuta ohjakset apua tarvitseville, ja kaikki ovat tyytyväisiä. Mutta horisontaalinen viestintä ei aina ole vakiintunutta. Ja toinen osasto ei ehkä yksinkertaisesti tiedä ensimmäisen varallisuudesta, joka jotenkin osoittautui, että se ei todellakaan tarvitse tätä varallisuutta.
Kuka on syyllinen tähän? - Itse asiassa ei kukaan. Näin kaikki on asetettu toistaiseksi.
Kuka tästä kärsii? - Siinä se, koko yritys.
Kuka voi korjata tilanteen? - Kyllä, kyllä, FinOps.
FinOps ei ole vain kerros kehittäjien ja heidän tarvitsemiensa laitteiden välillä, vaan henkilö tai tiimi, joka tietää missä, mitä ja kuinka hyvin se "makaa" yrityksen ostamien samojen pilvitariffien suhteen. Itse asiassa näiden ihmisten on työskenneltävä yhdessä DevOpsin ja toisaalta talousosaston kanssa toimien tehokkaana välittäjänä ja mikä tärkeintä, analyytikona.
Hieman optimoinnista
Pilviä. Suhteellisen halpa ja erittäin kätevä. Mutta tämä ratkaisu lakkaa olemasta halpa, kun palvelimien määrä saavuttaa kaksi- tai kolminumeroisen luvun. Lisäksi pilvet mahdollistavat yhä useampien palveluiden käyttämisen, jotka aiemmin eivät olleet saatavilla: nämä ovat tietokantoja palveluina (Amazon AWS, Azure Database), palvelimettomia sovelluksia (AWS Lambda, Azure Functions) ja monia muita. Ne ovat kaikki erittäin siistejä, koska niitä on helppo käyttää - osta ja mene, ei ongelmia. Mutta mitä syvemmälle yritys ja sen projektit syöksyvät pilviin, sitä huonommin talousjohtaja nukkuu. Ja mitä nopeammin kenraali harmaantuu.
Tosiasia on, että laskut eri pilvipalveluista ovat aina äärimmäisen hämmentäviä: yhdestä tuotteesta saatat saada kolmisivuisen selvityksen siitä, mihin, minne ja miten rahasi menivät. Tämä on tietysti miellyttävää, mutta sitä on lähes mahdotonta ymmärtää. Lisäksi mielipiteemme tästä asiasta ei ole kaukana ainoasta: pilvitilien siirtämiseksi ihmisille on olemassa kokonaisia palveluita, mm. tai . Jos joku vaivautui luomaan erillisen palvelun laskujen tulkitsemiseen, niin ongelman laajuus on kasvanut hiusvärien kustannukset.
Joten mitä FinOps tekee tässä tilanteessa:
- ymmärtää selvästi, milloin ja missä määrin pilviratkaisuja ostettiin.
- tietää, miten näitä kapasiteettia käytetään.
- jakaa ne uudelleen tietyn yksikön tarpeiden mukaan.
- ei osta "jotta voisi olla".
- ja loppujen lopuksi se säästää rahaa.
Hyvä esimerkki on tietokannan kylmäkopion pilvitallennus. Arkistoidaanko se esimerkiksi tilan ja liikenteen vähentämiseksi tallennustilan päivittämisen yhteydessä? Kyllä, tilanne näyttäisi olevan halpa - yksittäistapauksessa, mutta tällaisten halpojen tilanteiden kokonaisuus aiheuttaa myöhemmin pilvipalveluille kohtuuttomia kustannuksia.
Tai toinen tilanne: ostit varakapasiteetin AWS:stä tai Azuresta, jotta et joutuisi huippukuormituksen alle. Voitko olla varma, että tämä on optimaalinen ratkaisu? Loppujen lopuksi, jos nämä tapaukset ovat käyttämättömänä 80%, annat yksinkertaisesti rahaa Amazonille. Lisäksi samoissa AWS:ssä ja Azuressa on tällaisia tapauksia varten purskettavia esiintymiä – miksi tarvitset tyhjäkäynnillä olevia palvelimia, jos voit käyttää työkalua huippukuormitusongelmien ratkaisemiseen? Tai On Premise -tapausten sijaan kannattaa katsoa Reservedin puolelle - ne ovat paljon halvempia ja tarjoavat myös alennuksia.
Muuten, alennuksista
Kuten alussa sanoimme, hankinnan tekee usein kuka tahansa - he löysivät viimeisen, ja sitten hän tekee sen jotenkin itse. Useimmiten jo kiireisistä ihmisistä tulee "äärimmäisiä", ja seurauksena saamme tilanteen, jossa ihminen nopeasti ja taitavasti, mutta täysin itsenäisesti päättää mitä ostaa ja missä määrin.
Mutta vuorovaikutuksessa pilvipalvelun myyjän kanssa saat edullisemmat ehdot kapasiteetin tukkuostossa. On selvää, että et voi saada tällaisia alennuksia autosta, jossa on hiljainen ja yksipuolinen rekisteröinti - mutta puhuttuasi oikean myyntipäällikön kanssa saatat palaa loppuun. Tai nämä kaverit voivat kertoa sinulle, mistä heillä on tällä hetkellä alennuksia. Siitä voi myös olla hyötyä.
Samanaikaisesti sinun on muistettava, että valo ei konvergoinut kuin kiila AWS: ssä tai Azuressa. Oman palvelinhuoneen järjestämisestä ei tietenkään ole kysymys - mutta näille kahdelle jättiläisten klassiselle ratkaisulle on olemassa vaihtoehtoja.
Esimerkiksi Google toi yrityksille Firebase-alustan, jolla ne voivat isännöidä samaa mobiiliprojektia avaimet käteen -periaatteella, mikä saattaa vaatia nopeaa skaalausta. Tallennus, reaaliaikainen tietokanta, isännöinti ja pilvitietojen synkronointi esimerkkinä tämän ratkaisun avulla ovat saatavilla yhdestä paikasta.
Toisaalta, jos emme puhu monoliittisesta hankkeesta, vaan niiden kokonaisuudesta, keskitetystä ratkaisusta ei aina ole hyötyä. Jos projekti on pitkäikäinen, sillä on oma kehityshistoria ja vastaava määrä tallennusta varten tarvittavaa dataa, kannattaa miettiä hajanaisempaa sijoittelua.
Pilvipalveluiden kustannuksia optimoidessasi saatat yhtäkkiä huomata, että liiketoimintakriittisiin sovelluksiin voit ostaa tehokkaampia tariffeja, jotka tuovat yritykselle keskeytymättömät tulot. Samaan aikaan kehityksen ”perinnön”, vanhojen arkistojen, tietokantojen jne. tallentaminen kalliisiin pilviin on ratkaisu. Loppujen lopuksi tällaisille tiedoille tavallinen datakeskus tavallisilla kiintolevyillä ja keskitehoisella laitteistolla ilman kelloja ja pillejä on varsin sopiva.
Tässä taas saattaisi ajatella, että "tämä meteli ei ole sen arvoista", mutta tämän julkaisun koko ongelma perustuu siihen, että eri vaiheissa vastuulliset ihmiset laiminlyövät pienet asiat ja tekevät sen, mikä on mukavampaa ja nopeampaa. Mikä lopulta johtaa parin vuoden jälkeen noihin kauhutileihin.
Tulos?
Yleensä pilvet ovat siistejä, ne ratkaisevat paljon ongelmia kaikenkokoisille yrityksille. Ilmiön uutuus tarkoittaa kuitenkin sitä, että meillä ei ole vieläkään kulutus- ja johtamiskulttuuria. FinOps on organisaation vipu, jonka avulla voit hyödyntää pilvivoimaa tehokkaammin. Tärkeintä ei ole muuttaa tätä asemaa ampumaryhmän analogiksi, jonka tehtävänä on ottaa kiinni huomaamattomat kehittäjät kädestä ja "huida" heitä seisokkeista.
Kehittäjien tulee kehittyä, ei laskea yrityksen rahoja. Ja niinpä FinOpsin tulee tehdä sekä ostoprosessista että käytöstäpoistoprosessista tai pilvikapasiteetin siirtämisestä muille tiimeille yksinkertainen ja miellyttävä tapahtuma kaikille osapuolille.
Lähde: will.com