Practio har budt på udbuddet om at skulle vaccinere danskerne mod COVID-19.
Man kan sige, at vi har forberedt os på denne opgave over de sidste mange år; vi har arbejdet med vaccinationer i stor skala, blandt andet på danske apoteker. Vi driver også allerede COVID-19-vaccinationscentre under NHS i samarbejde med vores partnere i UK og har gjort det i et stykke tid.
Det team jeg er en del af, står for Practio’s skræddersyede IT-platform, som bruges til at udføre og journalføre vaccinationer. IT-platformen bliver brugt i Danmark, Tyskland og UK.
Når vi kører for fuld damp med vaccinationer i Danmark, kan en times nedbrud eller fejl på IT-platformen betyde, at 5-10.000 personer bliver påvirket. Det ser vi meget nødigt sker. Derfor er det blandt andet vigtigt, at vi kan rulle en rettelse af en eventuel fejl i systemet ud så hurtigt og sikkert som muligt.
Vi har et kvalitets-princip der dikterer, at hver gang vi ruller en ændring på, så SKAL den køres gennem alle vores automatiserede tests. Kode-formatering, linting, unit-tests, integrationstest, acceptance-tests osv. Det princip har vi for at sikre, at alt stadig virker korrekt, også med den ændring vi ruller ud.
Over de sidste 3 år hvor vi har udviklet IT-platformen, er der kommet flere og flere tests til. Vi tæller dem i tusinder. Derfor er det blevet langsommere og langsommere for os at rulle en ændring ud.
For at sikre, at vi kan reagere hurtigt i tilfælde af problemer, har vi i løbet af den sidste måneds tid arbejdet på at forbedre udrulningstiden. Resultatet af disse forbedringer kan du se for vores forskellige microservices her:
Vi kører stadig nøjagtig lige så mange, og de samme automatiserede tests som før. Testene kører bare hurtigere.
Sådan har vi gjort det
Vi udruller via Circle CI og vi har opnået forbedringerne ved at gøre følgende:
- Brug store servere med mange CPU cores og meget RAM. Når dit build er 10x hurtigere, og du bruger en pay-per-use -øsning, kan du tillade dig at bruge 10x så meget på en større server og stadig betale det samme som før.
- Læg alt du overhovedet kan i RAM og på RAM-disk, al source code, alle filer, databasefiler og logs, caches som dine build tools normalt ligger på disk osv.
- Brug et simpelt basisimage, der kan starte op hurtigt.
- Brug nøjagtig samme konfiguration til build på alle dine microservices, så du nemt kan rulle en performanceopdatering ud til dem alle. Mens vi har lavet disse optimeringe, har vi udrullet ændringer tusindvis af gange på vores kørende produktionssystemer, så vi har samtidig fået testet, at vores zero-downtime-deploys virker fuldstændigt som de skal.
- Lad din ene build konfiguration automatisk detektere hvad der er brug for at installere i hvert repository, og installer kun det nødvendige.
- Installer så meget som muligt fra .tgz filer. Disse installationer kan køre parallelt og er hurtige. Hvorimod apt-get ikke kan køre parallelt og er langsommere. Vi har stadig nogle få ting, som vi installerer via apt-get, da de har så mange dependencies, at det virker som for meget arbejde implementere og vedligeholde installation via .tgz filer. Det gælder for eksempel dependencies til at køre acceptance tests via cypress.
- Kør alt du overhovedet kan parallelt på den enkelte maskine og koordiner buildet nøjagtig de steder hvor der er behov for det.
- Prøv at sikre dig, at steps der tager mere end nogle få sekunder udnytter multi-core CPU’er, hvis det kan lade sig gøre. Her er dit build-step specielt vigtigt, men brug fx også --use-compress-program=pigz, hvis du zipper/unzipper tar-filer.
- Brug flere lag af persistent caching på tværs af dine builds på strategiske steder.
- Kør tungere builds spredt ud parallelt på flere server. Dette gør vi på cirka en femtedel af vores builds. Når vi vil køre en udrulning parallelt på flere servere, har vi implementeret, at vi bare skal rette et tal med det ønskede antal servere og så virker det. Parallel-eksekvering af builds koordineres via Redis.
Din situation er selvfølgelig unik, og I skal finde løsninger, der passer ind i jeres systemers kontekst. Jeg håber alligevel at ovenstående måske kan inspirere.
Måske kører din udrulning allerede super hurtigt? Del gerne dine egne råd til hurtigere udrulning i kommentarerne. Jeg ville ikke have noget imod at vores udrulninger blev endnu hurtigere.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
