Start med én oppgave portalen må kunne utføre
Velg en handling som betyr noe i hverdagen: En kunde finner en tidligere bestilling, en medarbeider åpner et vedlegg, eller en godkjent ordre sendes videre til planlegging.
Det gjør testen lettere å vurdere. Dere kan kontrollere både innholdet og arbeidsoppgaven som er avhengig av det. NSM anbefaler å øve på gjenoppretting, måle tidsbruken og undersøke avhengigheter mellom systemer. Kilde: NSM, tiltaksgruppe 2.
Forventet resultat: En rapport som viser hva dere fikk tilbake, hvilke oppgaver som fungerte, hvor lang tid testen tok, og hva som må rettes.
1. Samle bestiller, driftsansvarlig og en bruker
Bestilleren avklarer hva virksomheten trenger. Driftsansvarlig utfører den tekniske gjenopprettingen. En bruker som kjenner portalen, kontrollerer resultatet. Rollene kan fordeles på få personer, men ansvaret må være tydelig.
Før testen trenger dere:
- en oversikt over portal, database, opplastede filer og tilkoblede systemer;
- dokumentasjon på hvor kopiene finnes, og hvem som kan hente dem;
- et separat testmiljø som driftsansvarlig har kontrollert;
- avtalte testoppgaver og en person som kan godkjenne resultatet.
Be også om et estimat for arbeidet og eventuelle kostnader ved testmiljøet. Avklar hva driftsavtalen faktisk omfatter.
2. Bestem hvor mye datatap og nedetid dere tåler
To begreper er nyttige når dere snakker med leverandøren:
RPO beskriver hvor mye datatap virksomheten kan akseptere, uttrykt som tid bakover fra hendelsen. RTO er målet for hvor lenge tjenesten kan være utilgjengelig før den må fungere igjen. DFØ forklarer at gjenopprettingstiden også omfatter feilhåndtering, oppstart og kontroll av funksjonalitet. Kilde: DFØ.
Skriv behovet med vanlige ord først: «Vi må kunne finne bestillinger og fortsette arbeidet innen fire timer. Vi tåler høyst én time med tapte registreringer.» Dette er et konstruert eksempel, ikke en anbefaling for alle portaler.
Be leverandøren undersøke om dagens løsning kan oppfylle behovet. Et avtalt mål er ikke et målt resultat.
3. Avgrens scenarioet og testmiljøet
Et mulig første scenario er at portalens database og vedlegg må hentes fra en sikkerhetskopi, mens planleggingssystemet fortsatt fungerer. Skriv ned hva som antas å være utilgjengelig, og hvilke ressurser deltakerne får bruke.
Driftsansvarlig må kontrollere at testmiljøet har egne skrivbare ressurser, begrenset tilgang og ingen aktiv forbindelse som kan endre produksjonsdata. E-post, betaling, planlagte oppgaver og integrasjoner må styres til testmottakere eller deaktiveres før den gjenopprettede portalen startes.
Hvis reelle data inngår i kopien, må tilgang, oppbevaring og opprydding avklares på forhånd. Bruk konstruerte data for nye testhandlinger. Ikke legg passord eller nøkler i testrapporten.
Denne øvelsen undersøker et avgrenset bortfall. Den dokumenterer ikke alene at virksomheten er klar til å håndtere et angrep som også rammer kontoer, kopier eller andre leverandører.
4. Kontroller sammenhengen mellom systemene
En portal kan bli hentet tilbake til et eldre tidspunkt enn systemet den utveksler opplysninger med. Be derfor om kontroll av hva som skjer med overføringer som allerede er utført.
Konstruert eksempel: Portalen overfører ordre 1042 klokken 10.15. I øvelsen hentes portalen tilbake til tilstanden klokken 10.00. Planleggingssystemet har fortsatt ordren, mens portalen kan mangle informasjon om at overføringen er gjennomført.
I testmiljøet bør dere undersøke:
| Kontroll | Spørsmål til leverandøren |
|---|---|
| Ordren finnes allerede hos mottakeren | Hvordan oppdager løsningen dette før den prøver å opprette en ny? |
| Portal og mottaker viser ulik status | Hvilket system skal være fasit, og hvordan blir forskjellen rettet? |
| Et vedlegg er eldre enn registreringen | Hvordan oppdages og håndteres manglende eller feil versjon? |
| En overføring står som ventende | Hvem vurderer om den skal kjøres på nytt? |
Dette er forslag til testspørsmål, ikke påstander om hvordan deres løsning fungerer. La integrasjonsansvarlig beskrive kontrollen og vise resultatet mot en testversjon av mottakersystemet. Hvis mottakeren bare etterlignes, må rapporten si det; da er den virkelige integrasjonen fortsatt utestet.
5. Mål tiden og skriv ned avvikene
Avtal når den simulerte hendelsen starter. Noter deretter tidspunktene for tilgang til kopi, ferdig gjenoppretting og godkjent arbeidsoppgave. Venting på tilgang eller hjelp må være synlig.
Hvis testmiljøet var ferdig rigget før klokken startet, skal det stå i rapporten. En slik måling viser ikke hele tiden det ville tatt å etablere et nytt miljø under en faktisk hendelse.
Sammenlign siste bekreftede registrering i de gjenopprettede dataene med tidspunktet for den simulerte hendelsen. Noter hvilket mulig datatap dette innebærer, og om det er innenfor behovet dere avtalte.
DFØ anbefaler å kontrollere testresultatet mot målene og bruke funnene til å forbedre prosedyrer og løsning. Kilde: DFØ, testing av gjenoppretting.
6. Bruk denne korte bestillingsmalen
Fyll inn feltene og bruk teksten som utgangspunkt i dialogen med leverandøren:
Vi ønsker en avgrenset gjenopprettingstest av [portal og arbeidsoppgave]. Scenarioet er [hva som er utilgjengelig]. Behovet vårt er høyst [tid] med datatap og [tid] før oppgaven kan utføres igjen.
Bekreft hvilke kopier og avhengigheter testen omfatter, hvordan testmiljøet isoleres, og hvilke kostnader som kommer i tillegg. Ta med kontroll av [aktuell integrasjon] og risikoen for at tidligere overføringer gjentas.
Lever en rapport med gjenopprettingspunkt, målt tidsbruk, utførte kontroller, avvik og det som ikke ble testet. For hvert avvik ønsker vi ansvarlig, foreslått tiltak og dato for ny kontroll. [Rolle/navn] godkjenner resultatet.
Malen er et redaksjonelt forslag. Leverandøren må tilpasse gjennomføringen til løsningen deres.
Vanlige feil når testen vurderes
Å godkjenne fordi innlogging virker. Kontroller også den avtalte arbeidsoppgaven, dataene og relevante brukerrettigheter.
Å omtale planlagt tid som testresultat. Hold behov, leverandørens estimat og faktisk tidsbruk fra hverandre.
Å overse systemer utenfor portalen. Skriv eksplisitt hvilke integrasjoner som er testet, etterlignet eller utelatt.
Å avslutte med en liste uten ansvar. Gi hvert avvik en eier og frist. Avtal hvem som rydder testmiljøet og fjerner midlertidige tilganger etterpå.
Velg én arbeidsoppgave og avtal testen
Start med den delen av portalen dere er mest avhengige av. Fyll ut bestillingsmalen og be driftsleverandøren bekrefte omfanget.
Digital Flow tilbyr hosting, drift og integrasjoner. Ta kontakt med en kort beskrivelse av portalen og hva som må fungere etter et avbrudd, så kan behovet avklares konkret.