Asiakas on logistiikkapalvelu, joka käsittelee kymmeniä tuhansia tilauksia päivässä, kohtaa ilta- ja alennusmyyntihuippuja ja jolla on tiukat SLA-sopimukset kauppakumppaneille. Infrastruktuuri oli kasvanut hallitsemattomasti: hajallaan olevia VPS-palvelimia, ”palvelimille” jääneitä asetuksia ja käsin tehtäviä käyttöönottoja wiki-ohjeiden mukaan. Jokainen julkaisu tarkoitti yöaikaista käyttöönottoa ja käyttökatkoa; jokainen ruuhkahuippu uhkasi tilauksia. Meihin otettiin yhteyttä ennen uuttavuotta järjestetyn alennusmyynnin häiriön jälkeen: alusta oli poissa käytöstä neljä tuntia ja palvelu joutui korvaamaan kumppaneille aiheutuneita menetyksiä.
Siirtää alusta hallittuun infrastruktuuriin liiketoimintaa pysäyttämättä:
infrastruktuuri koodina, automaattinen toimitus, kontitus ja orkestrointi, havaittavuus sekä ennakoitava palautuminen häiriöistä. Perustaja määritteli onnistumisen näin: ”julkaisu työaikana, ilman käyttökatkoa ja ilman SSH-yhteyksiä käyttävää ihmistä”.
Etenimme hyväksi todetussa järjestyksessä: ensin kontit ja toistettavat ympäristöt, sitten toimituksen automatisointi ja vasta sen jälkeen orkestrointi automaattisen skaalauksen kanssa.
- Auditoimme infrastruktuurin: kartoitimme palvelut ja riippuvuudet, mittasimme huippukuorman profiilin ja luetteloimme manuaaliset toimet, jotka johtivat useimmin häiriöihin.
- Kontitimme palvelut: yhdenmukaistimme koonnit, siirsimme asetukset koodista ympäristömuuttujiin ja loimme identtiset kehitys-, stage- ja tuotantoympäristöt.
- Kuvaasimme infrastruktuurin Terraform-koodina: ympäristöt otetaan käyttöön repositoriosta, ja manuaaliset muutokset pilvipalveluntarjoajan konsolissa on kielletty.
- Rakensimme GitLab CI -putken: testit ja levykuvien koonti tapahtuvat automaattisesti, stage otetaan käyttöön heti, tuotanto julkaistaan painikkeella katselmoinnin jälkeen ja palautus tehdään yhdellä toiminnolla.
- Siirsimme alustan Kubernetes-ympäristöön, jossa on automaattinen skaalaus: ilta- ja alennusmyyntihuippuihin vastataan lisäinstansseilla hätätyön sijaan.
- Otimme käyttöön seurannan ja hälytykset kultaisille signaaleille — viiveelle, virheille, liikenteelle ja kuormitukselle — sekä päivystysvuorot ja aikataulutetun eskaloinnin.
- Määritimme varmuuskopiot ja palautumisen katastrofeista: dokumentoimme palautusmenettelyt ja harjoittelimme häiriötä stage-ympäristössä samalla, kun mittasimme todellisen MTTR-ajan.
Projektin arvokkain tulos ei ollut teknologia vaan vastuun siirtyminen: infrastruktuuri ei enää ollut riippuvainen ”SSH-yhteydet omaavasta ihmisestä”. Jokainen käyttöönotto on toistettavissa, jokainen ympäristö palautettavissa koodista ja hallintapaneelit näyttävät häiriön ennen kuin ensimmäinen asiakas ehtii kirjoittaa. Näin käyttökatkosta tulee katastrofin sijasta rutiinihäiriö, jolla on selkeä toimintaohje ja mitattava palautumisaika.
Projektin talousvaikutus koostui kolmesta osasta: suorat infrastruktuurisäästöt 32 % automaattisen skaalauksen ja jatkuvasti ”lämpimänä” pidetyn huippukapasiteetin poistamisen ansiosta; tiimin säästetyt työtunnit, jotka aiemmin kuluivat yöjulkaisuihin; ja ennen kaikkea ruuhkahuipuissa säilynyt liikevaihto, kun häiriöitä ei enää tullut. Suuri vähittäiskauppaketjuun kuuluva asiakas jatkoi sopimusta ensimmäisen uuden infrastruktuurin aikana sujuneen alennusmyynnin jälkeen.
| Mittari | Tulos |
|---|---|
| Julkaisun käyttöönotto | 3–4 tuntia käsin → 15 minuuttia automaattisesti |
| Julkaisutiheys | 2–3 kuukaudessa → Lähes päivittäin |
| Alustan käytettävyys | 97,8 % → 99,95 % |
| Kuormitushuiput | Käyttökatkon riski → Automaattinen skaalaus ilman ihmisen osallistumista |
Tunnusluvut on siirretty tapausmateriaalin alkuperäislähteestä. Ajanjakso ilmoitetaan siellä, missä se on lähteessä määritelty.
- julkaisun käyttöönotto (oli 3–4 tuntia käsin)
- 15 min
- alustan käytettävyys (oli 97,8 %)
- 99,95%
- palautuminen häiriöstä (oli 2–4 tuntia)
- 20–30 min
- infrastruktuurikustannus
- −32%
Näytetään vaihteluvälien ylärajat (4 tuntia, 30 minuuttia). Käyttökatko = 100 % − käytettävyys.
- 01Commit
- 02Testit
- 03Levykuvan koonti
- 04Stageheti
- 05Prodpainikkeella katselmoinnin jälkeen
Infrastruktuurin kehityskohteet seuraavalle jaksolle:
- FinOps-käytännöt: hälytykset kustannuspoikkeamista ja kustannusten läpinäkyvyys tiimeittäin.
- GitOps-lähestymistapa: tuotantoympäristön tila kuvataan repositoriossa, ja muutokset tehdään vain pull requestien kautta.
- Usean alueen ratkaisu: kriittisten palveluiden replika palveluntarjoajan häiriöiden varalta.
Ennen julkaisu tarkoitti yötä, kahvia ja rukousta. Nyt se on painike ja viisitoista minuuttia. Juhlimme ensimmäistä häiriötöntä alennusmyyntiä koko yrityksen voimin.
— Logistiikkapalvelun teknologiajohtaja