Pit stop i deployment: Zašto brzina bez preciznosti uništava sistem

Autor: Miloš Vujčić, Junior Software Developer, Egzakta

Topao decembarski dan u Abu Dabiju 2021. negde oko 18:30 po lokalnom vremenu. Dvadeset mehaničara nepomično stoji i čeka svetlo na semaforu. Čuje se dobro poznat zvuk Hondinog V6 hibrida dok prilazi pitu i zaustavlja se pred timom. Bez pogleda, bez pitanja, bez improvizacije. Štender podiže bolid, pištolji zuje, stare gume lete napolje dok nove dolaze na njihovo mesto. Maks je već u prvoj brzini i na izlaznim vratima pit lane-a, a gledalac nije stigao ni da trepne.

Ispostaviće se da je ovo bio verovatno najvažniji dan u karijerama ovih ljudi, pit stop koji nije smeo da ima grešku je nije ni imao, a zahvaljujući njemu Formula 1 je dobila nove šampione. To nije samo Maks Ferštapen već i tim koji je savršeno orkestrirao deployment nazad na stazu.

Taj savršen trenutak u Abu Dabiju nije bio rezultat puke sreće ili trenutne inspiracije već pobeda sistema nad haosom.

Sistem ispred „Vozača dana“

Jedno od priznanja koja se dodeljuju na trkama Formule 1 je titula „Vozača dana“. Ovo priznanje je individualna nagrada koja se dodeljuje vozaču za kojeg se smatra da je u trci povukao više od svog tima i da je ono što je postigao na stazi uglavnom njegova zasluga. Gledano iz ugla rezultata ovi vozači retko su pobednici u trkama jer pobedu odnose oni timovi koji su besprekorno izneli trku i iz ugla vožnje i iz pit lane-a.

U pobedničkim sistemima kao što je Red Bull Racing ništa se ne prepušta slučaju te je tako svaki pokret mehaničara rezultat hiljada simulacija gde se greške otkriju pre nego što do njih dođe na stazi. Takva „mašina za simulaciju“ bi u svetu softverskog razvoja bio CI/CD pipeline (Continuous Integration/Continuous Deployment).

• Continuous Integration (CI) – Skup automatskih provera kroz koje prolazi prosleđen kod kako bi se greške otkrile u ranom razvoju. Greške se otkrivaju u “garaži” ne želimo da se greške dese u poslednjem krugu poslednje trke sezone
• Continuous Delivery (CD) – Softver je u svakom trenutku testiran i spreman za trku, ali se čeka odluka tima (klik na dugme) za izlazak na stazu
• Continuous Deployment (CD) – Automatizovana isporuka proizvoda = samouveren izlazak na stazu

Continuous Integration je praksa u kojoj developeri povremeno spajaju svoje izmene koda u centralni repozitorijum gde svako spajanje pokreće niz automatskih provera.

Neke od ključnih faza CI procesa su:

• Automatski build: server pokreće build i u slučaju da ima sintaksnih grešaka proces se odmah prekida
• Unit testiranje: najsitniji testovi koji su deo CI-a a koji proveravaju logiku pojedinačnih celina. Automatizacija ovog procesa služi kao provera da nova logika nije pokvarila očekivano funkcionisanje sistema
• Analiza kvaliteta koda: ovde spadaju alati koji proveravaju da li je kod napisan po standardima kompanije, akcenat se stavlja na čist i čitljiv kod
• Artifact creation: poslednja faza integracije gde sistem kreira paket koji je spreman za dalju distribuciju

Suština ovakvog pristupa je rana detekcija grešaka. Što se greška ranije otkrije u razvojnom ciklusu to će njeno ispravljanje biti jeftinije.

Nakon što CI potvrdi da je kod stabilan i ispravan, nastupa Continuous Deployment faza koja se fokusira na to kako taj kod stiže do okruženja gde se aplikacija zapravo izvršava.

Neke od ključnih faza CD procesa su:

• Deployment na test okruženja: softver se instalira na realne servere koji imitiraju realne uslove
• Integration & Smoke Testing: proverava se da li funkcioniše komunikacija sa spoljnim servisima
• Automatski Rollback: sigurnosni mehanizam koji nakon detekcije kritičnih grešaka može da vrati aplikaciju na stabilnu verziju

Prednosti implementacije ovakvog sistema su višestruke:

1. Smanjenje rizika: postojanje checkpointa i stabilnih verzija povećava sigurnost u funkcionisanje sistema
2. Brži feedback: ručna provera je skupa i iziskuje vreme, developer dobija instant povratnu informaciju o funkcionisanju novonastalih promena
3. Standardizacija: svaki deo koda prolazi kroz identičan proces čime se eliminiše ljudski faktor i smanjuje šansa za greškom

Precizno utvrđene procedure automatizacije ovakvih procesa utemeljuju pouzdanost sistema i doprinose njegovoj skalabilnosti.

Eksponencijalna cena greške

Labavo utvrđene procedure na pipeline-u, male greške u konfiguraciji i trenuci nepažnje, nažalost, nemaju linearnu cenu. Pogrešno navrnuta matica na točku neće vozaču oduzeti sekundu već će mu potencijalno uvesti dodatno stajanje i bačen krug a možda i trku. Proaktivno reagovanje na situacije je gotovo podrazumevan put na obe strane kako u svetu Formule 1 tako i u softverskom razvoju iako su i reaktivne akcije česta pojava o njima nekom drugom prilikom.

Greška na produkciji izaziva lančanu reakciju koja neposredno utiče na eksponencijalni rast troška do kog ne bi došlo da je postojala prevencija.

Kada bismo posmatrali sistem koji vrši neku prodaju lančana reakcija bi mogla izgleda ovako:

Minut 1: Zbog greške na produkciji korisnici ne uspevaju da završe kupovinu.

Minut 10: Nastaje krizna situacija, zaustavlja se dalji razvoj, resursi se preusmeravaju na rešavanje gorućeg problema.

Minut 60: Poslovanje i poverenje opada, konkurencija koristi priliku.

Proteklih 60 minuta reagovanja na novonastali problem mogu koštati skuplje nego razvoj same funkcionalnosti baš zbog direktnih gubitaka, oportunitetnog troška itd.

Formula 1 je u svojoj poslednjoj eri postala biznis koji ne prašta greške, svaka odluka košta milione dolara a propuštene prilike verovatno znače da će ih neko drugi iskoristiti u bari punoj krokodila.

Sinhronizacija protiv brzine

U poslednjih par sezona „najbržeg cirkusa na svetu“ kako ga mnogi nazivaju, postalo je popularno izricanje „stop and go“ kazne. Naime, kazna se izriče vozaču nakon učinjenog prekršaja gde je vozač dužan da prilikom sledećeg odlaska u pit lane parkira bolid na 10 sekundi (nekad i manje) te sa njim ništa ne radi. Nakon isteka kazne mehaničari mogu započeti sa svojim zaduženjima.

Ceo tim je upoznat sa procedurama, poznata su zaduženja ali ovde na red dolazi sinhronizacija kao ključni segment posla koji treba obaviti. Ako se desi da ruka mehaničara dotakne bolid trenutak pre isteka izrečene kazne smatraće se da vozač nije odslužio kaznu iako je stajao 9,9 sekundi, vreme koje mu je izrečeno biće dodato na kraju trke na njegovo ukupno vreme.

Gotovo je neverovatno koliko dobri sistemi suštinski liče jedni na drugi ma u kojoj grani industrije da se oni nalaze.

U svetu softverskog razvoja i proces deploymenta mora biti koordinisan gde škripanje nekog činioca i trčanje pred rudu može izazvati trošak kasnije. Uspešan deployment podrazumeva orkestraciju uloga kao što su:

• QA – mora dati zeleno svetlo da je kod stabilan
• DevOps – mora potvrditi da je infrastruktura spremna
• Product Manager – mora utvrditi tačan trenutak puštanja u produkciju a u komunikaciji sa klijentima

Kako cilj kome svi u organizaciji teže ne bi postao rizik, svi akteri u procesu moraju biti koordinisani u realnom vremenu. Sinhronizacija u ovom slučaju je imperativ u odnosu na brzinu kako u formuli 1 tako i u ovoj grani softverske industrije.

Checklista protiv improvizacije

Red Bull Racing je u Formulu 1 ušao kao autsajder. Proizvođač energetskog pića koji traži nešto među fabričkim proizvođačima motora poput Mercedesa i Ferrarija, ekipa koje nisu zavisile od outsourceovane pogonske jedinice. Proizvođač energetskog pića je pokazao da se sistematskim radom, jasnim dugoročnim planom i pre svega stručnim kadrom može preći preko neki na prvi pogled ograničenja ekipe.

Ovde se izdvojila Hannah Schmitz, britanska inženjerka koja radi na pit wall-u Red Bull Racinga a koja je glavna i odgovorna za strategiju tima.

Kada stvari postanu haotične tu preuzima Hana, njene odluke nisu rezultat intuicije ili nečeg neopisivog već su rezultat hiljada simulacija i unapred definisanih checklista koje je projektovala. „Ako se desi X, izvrši plan Y“

Da li ovo malo podseća na Rollback Plan?

U trenucima kada se desi problem na serveru, vanredna situacija koja iziskuje momentalnu akciju iznuđeno rešenje skoro nikad nije optimalno. Tada želimo proceduru koja je napisana hladne glave danima unapred a koja nas vodi na sigurno mesto.

Checklista bi trebalo da ima jasno definisane uloge, ko vrši praćenja a ko odlučuje. Takođe, stavke na listi bi trebalo da „čekiraju“ unapred definisani trigeri za akciju. Recimo ako error rate u logovima premaši određeni procenat možda je vreme za rollback. U kontekstu formule 1, trigger za promenu guma na pneumatike za kišne uslove trebalo bi da budu prve kapi kiše na stazi.

Plan povratka je centralna stavka ovakve checkliste i opisuje proceduru kojom se u par koraka aplikacija vraća na stabilnu verziju.

Nevidljivost kao čuvar vrednosti: dosadno je dobro

Priču o deploymentu započeli smo anegdotom iz Abu Dabija 2021. godine u garaži Red Bull Racinga. Analogiju za ovo poglavlje možemo naći u 4 godine koje će uslediti nakon tog događaja. Usledila je „dosadna“ dominacija Red Bull Racinga koji je, istini za volju, imao kalibar svetskog šampiona za volanom ali i podršku tima u pit lane-u koja je ovu dominaciju učinila dosadnom jer su samo radili svoj posao. Bez drame, bez greške, samo checklist i praćenje procedura. Da li su oni onda deo core value-a?

Core value proizvoda se ne ostvaruje direktno kroz deployment. Ulaganje u razvoj procesa deploymenta neće uticati na povećanje vrednost proizvoda ali ga i te kako može učiniti irelevantnim.

Cilj je izgraditi sistem koji je toliko robustan da postane nevidljiv a njegovo funkcionisanje potpuno dosadno u svojoj efikanosti. Od deploymenta se očekuje dosadan jer korisnici svakako ne kupuju CI/CD pipeline već aplikaciju ali se prosto podrazumeva da CI/CD besprekorno radi.

Pobednički krug

Na kraju, posle svih analogija i paralela koje smo povukli sa Formulom 1 vratio bih se još jednom u Abu Dabi.

Maks Ferštapen podiže svoj prvi pehar šampiona Formule 1. Pehar „najbržeg cirkusa na svetu“ je iskovan u garaži, mesecima ranije kroz dosadne simulacije, nevidljive popravke i ponovljene procedure.

Peharom je nagrađena ne samo brzina već i konzistentnost, pouzdanost i kontinuitet. Sistemi kao što je Red Bull Racing se ne oslanjaju na sreću i improvizaciju nego na checkliste i automatizaciju.

Baš kao i u softverskom razvoju, prava pobeda nije u jednom herojskom podvigu koji ispravlja grešku u poslednji čas već u onih hiljadu trenutaka kada se greška nije dogodila jer je sistem bio jači od haosa.

Šampionski pehar, kao i uspešan deployment, pripada onima koji su shvatili da je vrhunska efikasnost često nevidljiva.