DocuNote – et forretningskritisk system, der kræver forretningskritisk infrastruktur.
Truslen kommer ikke kun udefra, men også indefra!
Nedetid på forretningskritiske systemer sker oftere som resultat af interne processer end ved udefrakommende angreb. Jeres data er sikret i DocuNote og jeres it-afdeling har styr på de udefrakommende trusler.
Alligevel går det ind i mellem galt. Hvorfor?
Det gør det, fordi test og uddannelse af medarbejderne foregår direkte i produktionsmiljøet, og det kan føre til nedbrud. Fx når I tester ny funktionalitet, nye integrationer eller moduler, eller når I opdaterer systemet, implementerer ny funktionalitet – så risikerer I, at systemet crasher og går ned.
Opdateringer går for det meste godt. Men ved at opdatere i et testmiljø, kan I måske opdage noget, I glemte at være opmærksomme på, og undgå nedetid eller uhensigtsmæssigheder i jeres produktionsmiljø.
I bør overveje et testmiljø, hvis I
- er afhængige af at være tilgængelige for jeres kunder eller medlemmer 24/7
- selv udarbejder integrationer
- synkroniserer Docunote med andre systemer
- tester nye moduler og workflows
- ønsker at teste jeres integrationer, lavet fx via DocuNotes Rest API, inden I går i produktion
- afprøver forskellige kassationspolitikker.
I har brug for et trygt testområde med kopi af alle integrationer og dubletter af jeres øvrige systemer til at arbejde i – så I kan teste, at de ændringer, I foretager, kører som de skal. Med et separat testområde indkapsler I eventuelle uønskede konsekvenser, I kan se konsekvenserne rundt i hele systemet og få overblik over eventuelle uventede hændelser – uden det påvirker jeres drift eller produktion. Når alt kører fejlfrit, kan I flytte ændringerne over i jeres produktionsmiljø.
Hvad kan gå galt?
Eventuelle uheldige konsekvenser kan være, at der opstår fejl i integrationer. En status på en sag kan fejlagtigt ændres til, at den skal afsluttes. Har den påhæftet en kasssationskode, resulterer det i, at sagen kasseres efter afslutning. Og det er irreversibelt, hvis det ikke opdages i tide.
Vi har flere gange set eksempler på, at kassationskoder rulles ud, men man glemmer at afgrænse på en bestemt sagstype. Derfor rulles kassationen ud på alle sager. Hvis det var testet i et lukket miljø, var den forkerte kassation af sagerne undgået.
En ændret status kan også medføre, at sagsbehandlere ikke længere har adgang til sagen, og derfor bliver der ikke fulgt op på den.
Også automatiseringer er gode at teste af i et lukket miljø for at undgå, at eventuelle fejl rulles ud på alle dokumenter og sager.
Selvfølgelig kan I bare tjekke det hele rigtig godt igennem, så er der ingen ko på isen. Hvis I altså er 100 % sikre…
Vi anbefaler et kontrolleret miljø for at undgå at rulle eventuelle fejl ud på hele jeres drift.
Det går nok. Og det gør det også oftest.
Men hvad nu hvis det ikke gør?
At etablere et testmiljø er lige som at have en forsikring (på det korrekte beløb, vel at mærke!) eller daglig backup (som rent faktisk kan restore dine data) af din it. Du mærker ikke behovet for den til daglig, og den er dyr at have. Men den dag, det hele kokser, så er du ekstremt glad for den.
|
Carsten Kjeldsen |