Skip to main content

29 Tekniikkaa

29Tekniikka logo
Olen istunut lukemattomissa kokouksissa, joissa pilvipalveluiden laskutusta on perattu yksityiskohtaisesti. Sen perusteella voin sanoa, ettei ongelman ydin ole tekninen. Kyse on siitä, ettei kukaan oikeasti tarkastele lukuja.
Tiedän, että se saattaa kuulostaa laiskalta vastaukselta. Mutta käytyäni läpi kymmeniä ympäristöjä huomaan yhä uudelleen, että ongelmana on usein se, että joku on joskus ottanut jonkin ominaisuuden käyttöön, eikä kukaan ole sittemmin tullut tarkistaneeksi, mitä se maksaa.

Se yksinkertainen asia, joka toistuu kaikkialla

Otetaanpa esimerkiksi lokit.

Lähes jokaisessa yrityksessä, jossa olen työskennellyt, joku kehittäjä on jossain vaiheessa ottanut lokituksen käyttöön tuotantoympäristön ongelman selvittämiseksi. Päivä oli kiireinen. Ongelma saatiin lopulta ratkaistua, mutta lokitus jäi päälle. Nyt kahden vuoden aikana on kertynyt teratavuittain dataa – dataa, jota kukaan ei ole lukenut kertaakaan sen tallentamisen jälkeen.

Tääei ole mikäänteoreettinenesimerkki. Se on ihanoikeakuvio, jonka olen nähnyt varmaan kymmenen kertaa. Ja siitämaksetaanjokakuukausi. Sekä tallennuksesta että siitä että sinne edelleen kirjoitetaan.

Kun joku ulkopuolinen tulee katsomaan näitä, niin yleensä ensimmäiset löydöt ovat juuri tällaisia. Ei mitään hienoa arkkitehtuuri ongelmaa, vaan ihan tavallista laiminlyöntiä joka on kertynythiljaa. Säilytysajan vaihtaminen ikuisesta kolmeenkymmeneen päivään on noinviidenminuutintyöja se voi leikata laskusta useita satoja euroja kuussa. Yhdessä tapauksessa muistaakseni 900 euroa.

NAT Gateway ja muut suosikit

Toinen klassikko on NAT Gateway. Sen hyvänä puolena on, että siitä maksetaan sekä tuntihintaa että käsiteltyä gigatavua kohden laskettavaa maksua. Huonona puolena taas on se, ettei se oikein erotu joukosta; se vain on olemassa.

Erään yrityksen liikenne kulki reittiä, jonka olisi voinut ohjata VPC-päätepisteen kautta – käytännössä ilmaiseksi. Kustannusero oli noin 1 400 euroa kuukaudessa. Kukaan ei ollut huomannut asiaa puolentoista vuoden aikana, sillä kulu sisältyi kokonaislaskuun eikä kukaan tarkastellut sitä rivi riviltä.

Sitten on nämä niin sanotut orvot levyt. Instanssi on sammutettu, mutta levy on jäänyt jäljelle. Se ei laukaise hälytyksiä, koska se ei kuluta laskentatehoa; siitä vain laskutetaan kuukausittain. Eräässä tapauksessa niitä oli kertynyt kahdeksankymmentä kolmen vuoden aikana. En muista tarkkaa summaa, mutta kyse oli tuhansista euroista vuodessa – täysin turhaan.

Ja sitten on tietysti Kubernetes. Tää on vähänhienovaraisempi. Kehittäjälaittaapodin requests-arvoksineljä gigaamuistiajakaksi CPU:ta, koska se tuntuuturvalliselta. Oikeasti se käyttääneljäsataamegaaja 0,1 CPU:ta. Klusteri silti varaa sen pyydetyn määrän, joten solmuja tarvitaan moninkertainen määrä siihen nähden, mitä oikeasti tarvittaisiin. Tätäeihuomaamistään, koska mikään ei kaadu eikä mikään hidastu. Se vain maksaa.

Miksi kukaan sitten katsoo näitä?

Tähän on täysin inhimillinen selitys. Kustannusten seuraaminen ei oikeastaan ​​kuulu kenenkään työnkuvaan. Se on asia, jonka kaikki tunnustavat tärkeäksi, mutta jota kukaan ei lopulta ehdi hoitaa, sillä sprintin aikana on aina jotakin kiireellisempää tehtävää.
Vaikka yrittäisitkin tarkastella laskua, se on aivan liian monimutkainen. Tyypillinen keskisuuri helsinkiläinen SaaS-yritys käyttää 40–60:tä eri palvelua AWS:ssä tai Azuressa. Kunkin palvelun laskutus perustuu eri logiikkaan: laskenta sekuntiperusteisesti, tallennustila gigatavujen ja säilytysajan mukaan sekä verkkoliikenne suunnan ja vyöhykkeiden perusteella. Kukaan ihminen ei pysty käymään laskua läpi ja havaitsemaan siinä mahdollista virhettä.
Tarvitset työkaluja, tägitystä ja ennen kaikkea jonkun, joka on valmis tarkastelemaan kokonaiskuvaa viikoittain. Juuri tässä kohtaa monet yritykset päätyvät siihen, että kyseisen henkilön tulisi tulla organisaation ulkopuolelta.

Mitä ulkoinen tiimi siis oikeastaan ​​tekee?

Ensisijaisena tavoitteena ei ole kustannussäästöjen saavuttaminen, vaan näkyvyyden luominen. Käytännössä kaikki resurssit merkitään järjestelmällisesti – määrittelemällä omistajuus, niihin liittyvä tuote sekä se, onko kyseessä tuotanto- vai kehitystoiminta – ja laskutustiedot yhdistetään näihin tunnisteisiin.

Tämä on työlästä puuhaa. Sitä paitsi se ei tuo välittömiä säästöjä, joten monet yritykset jättävät sen väliin. Sitten ihmetellään, miksei optimointi johda mihinkään. Eihän se johdakaan, jos ei tiedetä, mitä kustannukset ovat.

Toinen tekijä on se, että ulkopuolinen tiimi on nähnyt kymmeniä erilaisia ​​ympäristöjä. He alkavat tunnistaa kaavoja, jotka yksittäiseltä kehittäjältä saattaisivat jäädä huomaamatta. Kun on tarkastellut sataa käyttöönottoa, tietää, miltä tyypillinen hukka näyttää. Tämä nopeuttaa havainnointiprosessia aivan eri tavalla kuin silloin, kun yrityksen oma tiimi alkaa opetella asiaa aivan alusta.

Kolmas seikka liittyy kannustimiin. Ulkopuolisen tiimin kanssa voidaan sopia, että osa sen palkkiosta sidotaan saavutettuihin säästöihin. Tämä toimii, kunhan laskelmat tehdään rehellisesti. Tässä on oltava huolellinen, sillä mallia on melko helppo manipuloida; säästöihin ei tule sisällyttää tuloksia, jotka olisivat toteutuneet joka tapauksessa.

Neljäs seikka – ja ehkäpä kaikkein aliarvostetuin – on se, että ulkopuolinen tiimi pakottaa keskusteluun. Kun ulkopuolinen kysyy, miksi tietty ympäristö on käynnissä yöaikaan, jonkun on pakko vastata. Usein vastaus kuuluu: ”En tiedä.” Se on hyvä hetki.

Tekoälyn laskutusvirheongelma

Tässä on uudenlainen, hiljattain ilmaantunut kuluerä, josta monilla yrityksillä ei ole aavistustakaan: tekoälypalveluiden token-pohjainen laskutus.
Sitä on vaikea ennustaa ja vielä vaikeampi hallita. Monilla yrityksillä ei ole aavistustakaan siitä, mitä yksittäinen tekoälyominaisuus maksaa käyttäjää kohden; ne vain vievät ominaisuuden tuotantoon ja odottavat näkevänsä, miltä lasku näyttää kuukauden kuluttua.
Tämä ulkopuolinen tiimi ottaa ensimmäistä kertaa käyttöön jonkinlaisen mittaristojärjestelmän. Se ei välttämättä vielä optimoi mitään, mutta se näyttää, mitkä asiat maksavat ja kuinka paljon. Se on alku.

Kolme asiaa, joita kysyin itseltäni

Jos joku pohtii, mistä aloittaa omassa kodissaan, tässä on järjestys, jota itse noudattaisin.

Nopea pääsy kaikkiin tallenteisiin

Lokit, tilannevedosten määrät, vanhat levykuvat ja säilöt (bucketit), joihin ei ole koskettu vuoteen – näiden kohdalla saavutetaan yleensä nopeimmat tulokset. Se vaatii vain vähäisiä muutoksia arkkitehtuuriin, ja vaikutukset näkyvät laskussa heti seuraavassa kuussa. Työ on myös palkitsevaa.

Sammuta se, mitä ei käytetä.

Kehitys- ja testausympäristöt sammutetaan illalla ja käynnistetään uudelleen aamulla. Teknisesti tämä on helppo toteuttaa, ja käytäntö onkin jo laajasti käytössä. Se vaatii lähinnä henkilön, joka selittää kehittäjille, miksi näin toimitaan – sekä henkilön, jolla on rohkeutta tehdä kyseinen päätös.

Tarkista laskentatehon käyttöaste

Jos suorittimen käyttöaste pyörii kymmenen prosentin tuntumassa, instanssit ovat joko liian suuria tai niitä on liikaa. Tämä vaatii hieman enemmän vaivaa, mutta tuottaa yleensä parhaat tulokset. Myös muistinkäyttö kannattaa tarkistaa, sillä pelkkä suorittimen käyttöaste ei kerro koko totuutta.

Vasta silloin kannattaa harkita spot-instansseja, siirtymistä palvelimettomaan arkkitehtuuriin tai kapasiteetin varaamiseen liittyviä strategioita. Nämä ovat erinomaisia ​​työkaluja, mutta jos perusta ei ole vankka, hyödyt jäävät vajaiksi eivätkä saavuta täyttä potentiaaliaan.

Kannattaako siis hyödyntää ulkoista tiimiä?

Rehellinen vastaus: se riippuu tilanteesta.

Jos kuukausittainen pilvipalvelulaskusi on alle kymmenentuhatta euroa, ulkopuolisen tiimin palkkaaminen tuskin maksaa itseään takaisin. Tässä mittakaavassa on järkevämpää kouluttaa joku omista työntekijöistä tarkistamaan luvut säännöllisesti; se on edullisempaa ja pitää osaamisen yrityksen sisällä.

Jos lasku on yli 50 tuhattakuukaudessa, tilanne on toinen. Pelkästään se että joku käy ympäristön läpi kerran kvartaalissa ja tekee korjaukset, maksaa itsensä takaisin melkein varmasti. Ensimmäinen kierros tuottaa yleensä enemmän kuin seuraavat kolme yhteensä.

Kustannukset on otettava huomioon – erityisesti oman henkilöstön käyttämä aika. Kustannusten optimointi ei itsessään ole ilmaista, vaan se vie aikaa pois tuotekehitykseltä. Jos kaksi kokenutta kehittäjää käyttää kaksi päivää kuukaudessa kustannusten analysointiin, siitä kertyy merkittävä kustannuserä.

Yksi asia, joka jää usein sanomatta

Suuri osa tästä ei ole tekninen ongelma. Se on organisatorinen.
Kukaan ei kanna vastuuta. Kukaan ei tarkastele lukuja. Kukaan ei halua olla se, joka lakkauttaa työkaverin työympäristön tai poistaa vanhan projektin resursseja, sillä se saattaa käynnistää epämiellyttävän sähköpostiketjun.
Teknologia on siinä mielessä helppo osuus. Työkalut ovat olemassa, ja ne ovat pääosin hyviä. Haasteena on luoda tilanne, jossa kaikki tarkastelevat lukuja kuukausittain, esittävät kysymyksiä ja saavat niihin vastauksia – ja jossa kukaan ei loukkaannu siitä, että omaa vastuualuetta tarkastellaan kriittisesti.
Ulkopuolinen tiimi on tässä avuksi, sillä se tuo mukanaan rutiinia ja objektiivisen näkökulman. On myös helpompi hyväksyä huomautus siitä, että käsillä oleva tehtävä on liian laaja, kun sen tekee joku muu kuin työkaveri.
Mutta jos organisaatiossa ei ole ketään, joka ottaisi vastuun tilanteen hallinnassa pitämisestä konsulttien lähdettyä, kustannukset alkavat jälleen nousta. Olen nähnyt tämän tapahtuvan useita kertoja. Siihen kuluu yleensä noin puolitoista vuotta.

Loppuun

Tämä ei ole hanke, jolla on selkeä alku- ja loppupiste, vaan käytäntö, joka tulee juurruttaa organisaation päivittäiseen toimintaan. Ulkopuolisesta tiimistä on apua liikkeellelähdössä, näkyvyyden saavuttamisessa ja sellaisten merkittävien virheiden tunnistamisessa, jotka ovat jääneet huomaamatta. Pysyvä muutos edellyttää kuitenkin sitä, että organisaation sisältä löytyy henkilö, joka ottaa asian omakseen.

Jos et ole varma, mistä aloittaa, aloita lokien säilytysajasta.

Se on tylsä ​​neuvo. Mutta yllättävän usein juuri se tuo ensimmäiset tuhat euroa kuukaudessa.