GDPR og hvorfor vi ikke kan bruke skarpe testdata

Forfatter: Richard Rostad, Promis Qualify

Bilder hentet fra: https://unsplash.com/photos/

NAV lagrer og vedlikeholder sensitiv personinformasjon om nesten alle mennesker i Norge. Å bevege seg bort fra å bruke skarpe date i utviklingsmiljø handler litt om verktøy, metoder og teknologi, men aller mest om organisasjonsstruktur og finansiering. NAV beveger seg bort fra den gamle fossefall-tankegangen (med kontrakter på anbud), til å bli å bruke smidig utvikling med egne utviklere og syntetiske data. Denne artikkelen handler derfor om to (litt ulike) sider av samme sak: Hvordan skal man organisere seg for å lykkes i en smidig verden, og hvordan kom vi fram til brukbare syntetiske testdata for utviklingsteamene våre?

Syntetiske testdata har flere potensielle fordeler: Bedre kontroll over uvanlige datakombinasjoner, hurtig generering av testsett for ytelsestest, samt spesifikke testsett som bestilles av andre konsumenter, og på toppen av det hele har du innbakt samsvar med GDPR. Selv om disse fordelene slår et godt slag for syntetiske testdata, er det ingen som har påstått at det var lett å få til. For å få til dette må man ta hensyn til kjente problemstillinger, ukjente problemstillinger, samt problemstillinger som viste seg å ikke være problemstillinger en gang, i dette nye regimet. Første delen av artikkelen tar for seg de administrative delene, del to ser på de tekniske løsningene vi fant, samt utfordringene vi fant underveis. Flesteparten av de tekniske problemstillingene finnes fordi NAV IT er skrudd sammen av over 200 forskjellige IT-systemer fra de siste fem tiår.

Tekniske grunner til ikke å bruke skarpe data

Forbruk av testdata

Testing med skarpe data representerer flere tekniske problemer. Først og fremst forbruk av testdata, i NAVs tilfelle betyr det forbruk av personinformasjon. En gitt person når pensjonsalder kun én gang, og når denne hendelsen er saksbehandlet i et testmiljø er det vanskelig å tilbakestille personen til en tilstand før pensjonsalder. Ytelsestester forbruker eksepsjonelt store mengder skarpe data, dette begrenser mengden testing som kan foretas.

Videre vil det brukes store mengder tid til å søke opp spesialtilfeller og disse grensetilfellene blir enda raskere brukt opp enn normale testdata. Ved å kunne produsere persondata til spesielle behov blir det betydelig enklere å finne en person med påkrevde kriterier for testing av grenser og kompliserte saksbehandlingstilfeller.

Testautomatisering

Testautomatisering med skarpe data blir fort avhengig av systemets tilstand i produksjon slik at man ikke får adskilt test og testdata. Det betyr som over at automatiserte tester ofte kan kjøres kun én gang mellom hver gang det lastes nye data fra produksjon over de eksisterende, noe som gjør gevinsten av automatisering betydelig mindre. Videre får man problemer når data i produksjon endrer seg og alenemoren plutselig er gift. Hvis man kan generere data som passer til testen ved behov forsvinner alle disse problemene.

Mange testmiljøer som må være synkronisert

NAV har over 200 forskjellige systemer som i særs stor grad forholder seg til det samme datasettet, som er Norges befolkning. Saksbehandling / endringer av personer i ett miljø kan forårsake at testdata for et annet system blir invalidert slik at tester feiler. Dette forårsaker unødvendig mye tid brukt på feilsøking. Igjen forsvinner problemet ved muligheten for å generere data som passer testen ved behov, istedenfor å basere seg på eksisterende produksjonsdata.

Test Doubles blir avhengig av produksjonsdata

Man har også problemer ved forsøk på mocking og stubs av perifere systemer der stub'en også må speile eksisterende produksjonsdata. Dette gjør testgrensesnittene betydelig mindre fleksible og vanskeliggjør isolering av problemer og feilsøking.

Totalt i NAV ser man at omkring to tredjedeler av innsatsen som kunne blitt benyttet til faktisk testing blir benyttet til søking, flytting og annen preparering av produksjonsdata. En enkel og lett tlgjengelig metode for ad-hoc generering av relevante data ville ha enormt potensiale for innsparinger eller heving av kvaliteten på NAVs systemer.

Motforestillinger

Den største motforestillingen mot syntetiske data er at de ikke er "levende", i den forstand at det ikke blir født nye barn, personer blir ikke eldre etc. Dette er enkelt å komme rundt ved å ha skedulerte jobber som genererer hendelser og om ikke det minste problemet med syntetisering, så ihverfall blant de enkleste.

 

Behov

Syntetiseringsprosjektet hos NAV har identifisert fire distinkte behov som må stilles til et godt syntetisert testmiljø.

                   1: Data for basis testing og ad-hoc exploratory testing

Så produksjonslike data som mulig for testformål

Dette betyr en statistisk representativ basisbefolkning som på alle måter speiler de signifikante aspektene av en reell befolkning. Siden de fleste av testene blir basert på behovene nedenfor, trenger denne befolkningen ikke å være i fullskala, noe som også reduserer ressursbehovet i form av CPU, stormaskintid, disk, minne etc. NAV baserer seg på en basisbefolkning på 100 000 som vil vokse i tilnærmelsesvis samme rate som den reelle befolkningen.

                   2: Grensetilfeller for spesifikk testing

Dette behovet dekker det meste av den spesifikke testingen av grensetilfeller og vanskelige saker. Eksempelvis en funksjonshemmet person som er adoptert av sin yngre søster og derfor har en mor som er yngre enn seg. Disse personene vil opprettes umiddelbart før testen og så saksbehandles gjennom systemene til en gitt endetilstand. Vi ønsker ikke å slette / resette personer til utgangstilstanden, så ved neste kjøring av testen vil man opprette en ny person med utgangstilstanden. Siden dette gjøres på den samme databasen som inneholder basisbefolkningen vil denne over tid langsomt endre seg fra den statistisk representative speilingen av virkeligheten som var utgangspunktet. Dette er akseptabelt fordi:

a)    Det er ønskelig at mest mulig av disse testene gjøres gjennom test-doubles av ytelse og reproduserbarhetshensyn slik at den statistiske effekten blir relativt liten.

b)    Basistesting vil i alle tilfelle gjøre endringer på testbefolkningen slik at vi uansett vil ha en glidning vekk fra realiteten. Dette må enten løses ved resetting av befolkningen til utgangspunktet eller ganske enkelt aksepteres. Kun utstrakt bruk av syntetdataene over tid vil vise hvilken løsning som er ønskelig.

                   3: Store datasett for ytelsestesting

Det vil fra tid til annen være behov for store datasett med et begrenset utvalg av signifikante variable for ytelsestesting. Eksempelvis en morgen med 15000 ferske mødre for test av automatisk saksbehandling av engangsstønad.

                   4: En levende testbefolkning

Det vil være et kontinuerlig behov for hendelser som skjer "av seg selv" for test av automatiske innslag i systemene ved passering av aldersgrenser, fødsler, dødsfall etc. Disse hendelsene må foregå kontinuerlig og i en frekvens som både gjenspeiler en statistisk virkelighet og er av tilstrekkelig omfang til å kunne forårsake nødvendig testing.

 

Hindringer

Enorm kompleksitet

Det største problemet med syntetisering av et helt land er den enorme kompleksiteten, både i virkeligheten og NAVs systempark. Siden den statistiske analysejobben vil vokse eksponensielt med antall analyserte variable er det ekstremt viktig å foreta et fornuftig utvalg av parametere som er relevante for syntetiseringen. Eksempelvis har vi ved generering av innvandringsmeldinger identifisert at både statsborgerskap og opprinnelsesland er relevante, men at kombinasjonen ikke er relevant. Det betyr at en svensk statsborger som er innvandret fra Azerbaijan er OK og analysen ser derfor på de to landene uavhengig slik at vi har et "riktig" antall svensker og et tilsvarende riktig antall innvandringer fra Azerbaijan, men kombinasjonen er ignorert.

Mange platformer og 6 tiår med løsninger

Det eldste systemet på NAV er skrevet i 1968 og er optimalisert for batch prosessering av hullkort. Det nyeste systemet er fra 2018 og bygget på Apache Kafka og json events. I mellom disse to ytterpunktene har vi alle tenkelige varianter av UNIX RPC kall, Java, Javascript, Visual Basic og Oracle Forms. Syntetisering av data for alle disse systemene er en utfordring

Avhengigheter til forretningslogikk som ligger i andre systemer

Problemet over blir forsterket av at systemene er avhengig av at dataene har blitt gjenstand for transformering gjennom eksisterende forretningslogikk gjennom andre systemer slik at en Oracle forms applikasjon forutsetter at en batchprosess har sendt data over UNIX RPC til et COBOL program før dataene kan benyttes til saksbehandling.

 

Løsning

1: Syntetisering av basispopulasjon

Syntetiseringsprosessen består av fire distinkte ledd; Ekstrahering av produksjonsdata, maskering, analyse og generering av syntetiske data på grunnlag av analysen. Nøkkelen til suksess er å ikke basere seg på innholdet i databasene, men fokusere analysen på flyten av data mellom systemer og dermed generere data gjennom eksisterende forretningslogikk.

Ekstrahere

I NAV er vi så heldige at vi har meldingshistorikk både på eksterne og interne data. Det er flere grunner til at vi har slik historikk, deriblant hensyn til sporing og validering av historiske hendelser som har dannet grunnlaget for saksbehandling og vedtak. Ekstraktet blir dermed bare en "dump" av meldingshistorikken for en gitt tidsperiode. Dette er fremdeles skarpe data og er således gjenstand for de samme sikkerhetsregler som online produksjonsdata.

Maskere

Neste skritt er en maskering og anonymisering av datagrunnlaget. Dette skrittet er overflødig dersom personellet som arbeider med syntetiseringen fra før har tilgang til produksjonsdata, men koster lite og har den fordelen at man kan redusere sikkerhetskravene til tilgangen til datagrunnlaget. Maskeringen i dette tilfellet fjerner også all informasjon som ikke er statistisk relevant, slik som navn og adresse, noe som gjør maskeringen sterkere enn en ukritisk maskering av hele produksjonsdatasettet hadde blitt.

Analysere

Deretter foretas en statistisk analyse av det maskerte datasettet. Denne analysen er skrevet i R og baserer seg på teknikker fra SDV - Synthetic Data Vault og Synthpop, begge utviklet for lignende formål ved MIT. Det er viktig å merke seg at det beregnes statistikk for sammensatte variable slik at man ikke bare får riktig antall 42-åringer, men også riktig antall skilte 42-åringer med 3 barn hvorav to er gutter, etc. Denne analysen er ressurskrevende og bør fortrinnsvis kjøres på dedikert hardware med tilstrekkelige ressurser. I forkant av den statistiske analysen har det blitt gjort en analyse av hvilke variable som er relevante å se i sammenheng. Eksempelvis er det relevant for systemene i NAV hvilket statsborgerskap en utlending har og også hvilket land han har innvandret fra. Imidlertid er kombinasjonen av opprinnelsesland og statsborgerskap ikke viktig, så systemet tar ikke hensyn til det, slik at vi har svenske statsborgere som innvandrer fra Azerbaijan. Siden tidsbruken for analysering stiger eksponensielt med antallet variable er en slik analyse viktig.

Generere

Det siste skrittet i prosessen er å generere "realistiske" hendelser og legge dem i et mellomlager. En systemprosess plukker så meldinger fra lageret og distribuerer til de forskjellige systemene. Vi genererer opp et langt større antall hendelser enn det vi initielt trenger, slik at systemet kan plukke meldinger over tid. Dette både av hensyn til belastning på systemer under genereringen og slik at vi kan simulere hendelser og endringer i befolkningen over tid. En interessant detalj er at vi har begynt med å simulere innvandringer siden systemet ikke har noen andre måter å skape personer ex nihilio; en fødsel forutsetter en mor etc. Dette er i praksis en simulering av folkevandringen etter istiden bare med andre datoer.

2: Randtilfeller og spesifikke testdata

Som testere har vi til stadighet behov for ekstreme, urealistiske eller på andre måter vanskelige data for testing av grensetilfeller og negativ testing. Eksempelvis barn som er eldre enn sine mødre. Genereringen av slike data vil ikke bli ivaretatt av basispopulasjonen. Både fordi vi har valgt å kjøre syntet-Norge med en lavere befolkning enn det virkelige og fordi sannsynligheten for slike tilfeller er statistisk lik null.

Selv om vi hadde generert nok personer til å få alle mulige slike varianter hadde vi allikevel endt opp med samme problemet vi tidligere hadde ved bruk av reelle data, nemlig problemet med å finne frem til slike personer. Det ville også være en mangel på umulige tilfeller.

Slike problemer løses best av et system der man kan spesifisere nøyaktig hva slags personer man ønsker testet og så genererer et lite antall slike spesifikt for sine tester. Ulempen med en slik løsning er at disse sære personene over tid vil forskyve den statistiske balansen i basispopulasjonen. Dette er delvis løst ved å legge mye randtilfeller i dedikerte testgrensesnitt som ikke er koblet mot de sentrale systemene, såkalte test-doubles. Dette er ikke en fullgod løsning og der det kreves en flyt gjennom mange systemer vil den statistiske representasjonen til basispopulasjonen endres vekk fra virkeligheten over tid. Dette problemet er ikke fullgodt løst ennå.

3:  Store antall "like" personer for ytelsestesting.

Systemene må fra tid til annen ytelsestestes. I slike tilfelle trenger vi mange personer som har et sett med parametre, men der øvrige egenskaper ikke er viktige for testen. Eksempelvis 15 000 nybakte mødre samme tirsdag for stresstesting av systemet for utbetaling av engangsstønad. Dette har vi løst ved at systemene i pkt. 2 også kan generere mange personer relativt enkelt. Løsningen er at man bare spesifiserer de relevante verdiene og så genererer systemet opp tilfeldige verdier for resten av de påkrevde parametrene. I eksempelet over spesifiserer man kvinne over 16 og under 50 og lar systemet håndtere resten. Vi har valgt å legge systemene opp slik at blanke felt gir en tilfeldig gyldig verdi, mens et spenn gir en tilfeldig verdi innenfor maks / min verdier.

Slike personer har en enda større innvirkning på basispopulasjonen enn randtilfellene og det er derfor ønskelig å ha mest mulig slik testing i test-doubles. Eventuelt drepe syntet-personene etter at man er ferdig med testen, noe som også gir en "gratis" ytelsestest av systemene for gravferdsstønad.

4:  En levende populasjon

I virkeligheten skjer det hendelser med befolkningen jevnlig. Folk blir født, dør, giftes og skilles. For at dette skal foregå også i syntet-Norge har vi laget en prosess som kontinuerlig plukker syntetiske hendelser fra lageret av genererte hendelser og propagerer dem ut i systemene gjennom eksisterende forretningslogikk. Teknisk er det ikke noen forskjell på denne og engangsgenereringen over.