Klientas — logistikos paslauga, apdorojanti dešimtis tūkstančių užsakymų per dieną, patirianti vakarinius ir išpardavimų pikus bei privalanti laikytis griežtų SLA prekybos partneriams. Infrastruktūra augo savaime: pavieniai VPS, konfigūracijos „serveriuose“, rankinis diegimas pagal wiki instrukciją. Kiekvienas leidimas reiškė naktinį diegimą su prastova, o kiekvienas pikas — užsakymų praradimo riziką. Kreiptis į mus paskatino incidentas prieškalėdinio išpardavimo metu, kai platforma neveikė keturias valandas ir paslauga turėjo kompensuoti partneriams.
Perkelti platformą į valdomą infrastruktūrą nestabdant verslo:
infrastruktūra kaip kodas, automatinis diegimas, konteinerizavimas ir orkestravimas, stebimumas ir nuspėjamas atsistatymas po gedimų. Sėkmės kriterijų suformulavo įkūrėjas: „diegti darbo metu, be prastovos ir be žmogaus, turinčio SSH prieigą“.
Laikėmės patikrintos sekos: pirmiausia konteineriai ir atkuriamos aplinkos, tada diegimo automatizavimas ir tik po to — orkestravimas su automatiniu mastelio keitimu.
- Atlikome infrastruktūros auditą: sudarėme paslaugų ir priklausomybių žemėlapį, išmatavome piko apkrovos profilį ir surašėme rankinius veiksmus, dažniausiai sukeldavusius avarijas.
- Sukonteinerizavome paslaugas: suvienodinome surinkimą, konfigūraciją iškėlėme iš kodo į aplinkos kintamuosius ir sukūrėme vienodas dev, stage ir prod aplinkas.
- Aprašėme infrastruktūrą kodu „Terraform“: aplinkos diegiamos iš repozitorijos, o rankiniai pakeitimai debesijos paslaugų teikėjo konsolėje uždrausti.
- Sukūrėme „GitLab CI“ tiekimo grandinę: testai ir atvaizdų kūrimas vyksta automatiškai, į stage diegiama iškart, į prod — mygtuko paspaudimu po peržiūros, o atšaukti galima vienu veiksmu.
- Perkėlėme platformą į „Kubernetes“ su automatiniu mastelio keitimu: per vakarinius ir išpardavimų pikus ji pasitinka srautą papildomomis instancijomis, o ne skubiais rankiniais darbais.
- Įdiegėme stebėseną ir perspėjimus pagal pagrindinius signalus — delsą, klaidas, srautą ir prisotinimą — su budėjimais ir eskalavimu pagal grafiką.
- Sukonfigūravome atsargines kopijas ir atkūrimą po nelaimių: atkūrimo tvarką bei gedimo repeticiją stage aplinkoje, išmatuojant tikrąjį MTTR.
Vertingiausias projekto rezultatas — ne technologijos, o atsakomybės pasikeitimas: infrastruktūra nebepriklausė nuo „žmogaus su SSH prieiga“. Kiekvienas diegimas atkuriamas, kiekvieną aplinką galima atkurti iš kodo, o valdymo skydeliai parodo bet kokį sutrikimą anksčiau, nei parašo pirmasis klientas. Taip prastova iš katastrofos tampa įprastu incidentu su aiškiu veiksmų planu ir išmatuojamu atkūrimo laiku.
Projekto ekonominė nauda susidėjo iš trijų dalių: 32% tiesiogiai sutaupytų infrastruktūros išlaidų dėl automatinio mastelio keitimo ir nuolat „įkaitintos“ piko galios atsisakymo; komandos sutaupytų darbo valandų, anksčiau praleistų naktiniuose diegimuose; ir svarbiausia — išsaugotų pajamų per pikus, kurie dabar praeina be incidentų. Didelis mažmeninės prekybos tinklas, vienas klientų, pratęsė sutartį būtent po pirmojo išpardavimo naujoje infrastruktūroje.
| Rodiklis | Rezultatas |
|---|---|
| Leidimo diegimas | 3–4 valandos rankiniu būdu → 15 minučių automatiškai |
| Leidimų dažnumas | 2–3 per mėnesį → Beveik kasdien |
| Platformos prieinamumas | 97,8% → 99,95% |
| Pikinės apkrovos | Prastovos rizika → Automatinis mastelio keitimas be žmogaus įsikišimo |
Rodikliai perkelti iš pirminės atvejo medžiagos. Laikotarpis nurodomas ten, kur jis užfiksuotas šaltinyje.
- leidimo diegimas (buvo 3–4 valandos rankiniu būdu)
- 15 min
- platformos prieinamumas (buvo 97,8%)
- 99,95%
- atkūrimas po sutrikimo (buvo 2–4 valandos)
- 20–30 min
- infrastruktūros kaina
- −32%
Pavaizduotos intervalų viršutinės ribos (4 valandos, 30 minučių). Prastova = 100% − prieinamumas.
- 01Commit
- 02Testai
- 03Atvaizdo surinkimas
- 04Stagenedelsiant
- 05Prodmygtuku po peržiūros
Kitos infrastruktūros plėtros kryptys:
- FinOps praktika — perspėjimai apie neįprastas išlaidas ir skaidrios sąnaudos pagal komandas.
- GitOps metodas — produkcijos būsena aprašoma repozitorijoje, o pakeitimai atliekami tik per pull request.
- Kelių regionų architektūra — kritinių paslaugų kopijos, užtikrinančios atsparumą tiekėjo gedimo atveju.
Anksčiau leidimas reiškė naktį, kavą ir maldą. Dabar tai — mygtukas ir penkiolika minučių. Pirmą išpardavimą be incidentų šventėme visa įmone.
— Logistikos paslaugos technikos direktorius