Under blodige slag for over to hundre år siden oppdaget Napoleons feltkirurger noe viktig. Om de prøvde å hjelpe de skadde etter hvor ille skadene så ut, risikerte de å prioritere pasienter det var umulig å redde.
De kunne også sløse vekk verdifull tid på soldater med lettere skader. Så hvordan finne tilfellene der øyeblikkelig hjelp ga best effekt?
Svaret ble et sett av sorteringskriterier, kalt «triage» – fransk for sortering.
- Les også: Lys med «ører» gir milliardinntekter
Fra slagmarken til dataindustrien
Prinsippet ble kjent for alvor gjennom franske legers praksis i felten under første verdenskrig. Fortsatt brukes det på store ulykkessteder.
Med tidlige og raske ekspertvurderinger deler helsepersonell de skadde i to grupper: de som har nytte av behandling det er mulig å gi, og de som ikke har det.
Fra Norge har ikt-verdenen nå fått en metode som på liknende vis hjelper systemutviklere å sortere. Hos TietoEVRY og hos Digitaliseringsdirektoratet har den alt spart arbeid og bedret kvaliteten på datasystemer.
Datasystemer er som deg og meg
Metoden viser utviklerne allerede på «tegnebrettet» hvilke arbeidsoppgaver som kan få et datasystem til å kræsje, om de ikke vies nok oppmerksomhet i utviklingsfasen.
Verktøyet er resultatet av et prosjekt der vi som er forskere og vi som representerer ikt-industri og systemeiere har samarbeidet, med støtte fra Forskningsrådet. Bakteppet er at datasystemer er som oss alle.
Får de for mye å gjøre, møter de nemlig veggen. Det skjer hvis de får flere brukere på en gang enn forutsatt, eller om brukerne gir datasystemet tyngre oppgaver enn det er lagd for. Systemet har «skaleringsproblemer», heter dette på fagspråket.
Egenskapen skalerbarhet
- Skalerbarhet er navnet på en evne ved databaserte tjenester.
- Nærmere bestemt den evnen som avgjør hvor mye tjenestens kapasitet kan økes med økt bruk av maskinvareressurser som prosessorer (CPUer), minne (primærminne og disk) og nettverk.
- Skalerbarheten blir satt på prøve jo flere brukere systemet får, jo tyngre bruken er, jo sterkere kravet er til responstid og jo større integrasjonen er mellom kjeder av tjenester.
- Et system med god skalerbarhet kan bygges ut i takt med belastningen, mens et system med dårlig skalerbarhet vil krasje når det ikke lenger kan dimensjoneres for ønsket belastning.
- Det er krevende å endre skalerbarheten etter at et system er bygget. Det blir som å
bygge ny grunnmur på et eksisterende hus. - Det er også dyrt å konstruere et system med for stor skalerbarhet, for da blir det unødvendig komplisert og dyrt å utvikle og drifte systemet. Det blir som å bygge en for solid grunnmur under oppføring av et nytt hus.
- For noen systemer er skalerbarhet svært viktig, for andre systemer betyr det lite.
- Derfor er det viktig å finne ut hvor skalerbart et nytt datasystem må være. Her er "skalerbarhetstriage" (som beskrives i artikkelen) en egnet teknikk.
Likheter med korona-sykehus
Viktigheten av riktig skalering i dataverdenen blir lettest å forstå om du sammenlikner datasystemer med sykehus.
Et sykehus har mange ulike arbeidsoppgaver. Noen må gjøres ofte, noen er lette og noen haster mer enn andre.
Da koronaen kom ble det klart at arbeidskrevende respiratorbehandling av mange dødssyke samtidig, kunne knekke sykehusene. Som mottrekk økte de kapasiteten ved å kjøpe flere respiratorer og frigjøre sykepleiere fra annet arbeid.
- Les også: Møt oppdrettsbransjens nye vaktmester
Gjør vanskelige vurderinger håndterbare
På lignende vis analyserer metoden vår arbeidsoppgavene til et datasystem.
Noen oppgaver er tunge, andre er hyppige og noen haster mer enn andre. Eksperter vurderer hver oppgave og gir den separate «verdier» for hvor tung den er, hvilken frekvens den har og hvilken hastegrad. Enten lav, middels eller høy.
At verdiene angis hver for seg, er den sentrale innovasjonen som gjør det håndterbart å vurdere hvor krevende hver arbeidsoppgave er.
Fellestrekk med feltlegens hverdag
Kombinasjonen «høy-høy-høy» er opplagt skummel og må vies omtanke for å bli løst best mulig.
Sammen vurderer ekspertene om også kombinasjoner som «høy-middels-høy» kan knekke systemet. Akkurat slik feltlegene vurderte hvem som ville ha best effekt av behandling, sirkler metoden inn de delene av datasystemet der «kræsjforebygging» må til.
Mulighetene for å tilføre datasystemer ekstra ressurser, på linje med «respiratorer og sykepleiere», ligger eksempelvis i å gi systemet flere prosessorer (CPUer). Men dette er ikke rett frem.
«Ringelmanneffekten»
Det blir som når flere personer sammen skal løfte en tung gjenstand. Kanskje klarer hver av dem 30 kilo.
To kan samarbeide perfekt og løfte 60 kilo. Men seks personer klarer neppe å samarbeide perfekt om å løfte 180 kilo. Dette kalles Ringelmanneffekten, og slik er det også med prosessorer.
Desto viktigere er det for systemutviklere å vite nøyaktig hvilke av datasystemets arbeidsoppgaver de bør bruke kreftene sine på for å få systemet til å tåle økte arbeidsmengder.
Unngår dyr brannslukking
Til nå har skaleringsproblemer ofte blitt oppdaget først etter at arbeidsoppgavene er ferdige. Slik kostbar brannslukking gir forsinkelser.
Metoden vår endrer dette. Når ekspertene på forhånd vet hvilke arbeidsoppgaver som kan få datasystemet til å bryte sammen, kan de gi verdifulle innspill underveis. Dette sparer både tid og penger. Mindre stress blir det også.
Metoden trenger fortsatt mer utprøving. Samtidig utvider vi den slik at den kan analysere programvaresikkerhet og drift av kritiske datasystemer.
Det hele ved hjelp av et gammelt og enkelt prinsipp fra katastrofemedisin, som vi har tilpasset moderne systemutvikling.
Forskningen
Hvem: Gunnar Brataas, Geir Kjetil Hanssen, Niklas Herbst, André van Hoorn
Hva: Agile Scalability Engineering: The ScrumScale Method
Hvor: IEEE Software, August/September 2020. Åpent tilgjengelig her
Artikkelen ble første gang publisert i Dagens Næringsliv 3. februar 2020 og gjengis her med DNs tillatelse.
