Oppdatering av systemer i et lite miljø

I store IT-avdelinger er systemoppdatering en komplisert prosess som involverer et stort antall testmiljøer som speiler produksjonssystemene, slik at hver ny oppdatering fra operativsystem- og programvareleverandører kan testes i et virkelig miljø for å se hvordan de samvirker med tilgjengelig maskinvare og programvare i organisasjonen. I en ideell verden ville hvert miljø ha en styrt oppdateringsprosess som umiddelbart responderte på nylig publiserte oppdateringer, testet dem øyeblikkelig og anvendte dem så snart oppdateringen ble ansett som trygg og relevant. Men verden er ikke ideell, og i virkeligheten må vi klare oss med begrensede ressurser: fysiske, tidsmessige og finansielle.

Oppdateringer utgis generelt av noen få viktige grunner: sikkerhet, stabilitet, ytelse og, av og til, for å levere nye funksjoner. Bortsett fra tillegg av nye funksjoner, som normalt håndteres gjennom en annen utgivelsesprosess, representerer oppdateringer en rettelse av et kjent problem. Dette er ikke et “hvis det ikke er ødelagt, ikke fiks det”-scenario, men er et “det er ødelagt og har ikke feilet fullstendig ennå”-scenario som krever oppmerksomhet – jo raskere jo bedre. En “sitte tilbake og vente”-tilnærming til oppdateringer er uklok ettersom eksistensen av en ny oppdatering betyr at ondsinnede hackere har en “rettelse” å analysere, og selv om en utnyttelse ikke eksisterte tidligere, vil den gjøre det meget snart. Utgivelsen av selve oppdateringen kan være utløseren for det umiddelbare behovet for den nevnte oppdateringen.

Dette oppdateringsøkosystemet skaper et behov for en “oppdater raskt”-mentalitet. Oppdateringer bør aldri ligge og vente; de må anvendes ofte, så snart de er utgitt og testet. Å vente med å oppdatere kan bety å kjøre med kritiske sikkerhetsfeil eller holde systemer unødvendig upålitelige.

Små IT-avdelinger har sjelden, om noen gang, testmiljøer, verken for servere, nettverksutstyr eller selv stasjonære datamaskiner. Ikke ideelt, men realistisk sett, selv om disse miljøene var tilgjengelige, har få små avdelinger de ekstra menneskelige IT-ressursene tilgjengelig for å kjøre disse testene i tide.

Dette er ikke så dystert som det høres ut. Testingen som gjøres for de fleste oppdateringer er redundant med testingen som allerede er gjort av leverandøren. Leverandører kan ikke muligens teste alle maskinvare- og programvareinteraksjoner som noen gang kan forekomme med produktene deres, men de tester generelt brede spektre av permutasjoner og ser på områder der interaksjoner er mest sannsynlige. Det er sjeldent at en stor leverandør ødelegger sin egen programvare med dårlige oppdateringer. Ja, det skjer, og det er viktig å ha gode sikkerhetskopier og tilbakerutingsplaner, men i daglig drift er oppdatering en relativt trygg prosess som er langt viktigere å gjøre raskt enn å vente på muligheter som kanskje kommer eller kanskje ikke.

Som enhver systemendring er oppdateringer best anvendt i hyppige, små doser. Hvis oppdateringer anvendes raskt, er det normalt bare én eller noen få oppdateringer som må anvendes samtidig. For operativsystemer kan du fortsatt måtte håndtere flere oppdateringer om gangen, særlig hvis du bare oppdaterer ukentlig, men sjelden trenger du å oppdatere dusinvis eller hundrevis av filer om gangen når det gjøres på denne måten. Når det gjøres slik, er det langt enklere å evaluere oppdateringer for negative effekter og å rulle tilbake hvis en oppdateringsprosess går galt.

Det verste scenariet for en liten bedrift som mangler en ordentlig arbeidsflyt for oppdateringstesting, er å vente med oppdateringer. Venting betyr at systemer går uten nødvendig vedlikehold i lange perioder, og når oppdateringer endelig anvendes, er det ofte i store, samlede oppdateringsprosesser. Å anvende mange oppdateringer på én gang øker sjansene for at noe går galt, og når det skjer, kan det å identifisere hvilke oppdaterin(g/er) som er skyldige og å finne en vei til utbedring være mye vanskeligere.

Forsinket oppdatering er en prosess som gir liten eller ingen fordel for verken IT eller en bedrift, men den medfører betydelig risiko for sikkerhet, stabilitet og ytelse. Beste praksis for oppdatering i et lite miljø er enten å la systemer oppdatere seg selv så raskt som mulig, eller å planlegge en regelmessig oppdateringsprosess, kanskje ukentlig, i en periode der bedriften er best forberedt på at oppdateringen kan mislykkes og at håndtering av oppdateringsrettelser kan gjennomføres. Enten du velger å oppdatere automatisk eller ganske enkelt regelmessig gjennom en manuell prosess, oppdater ofte og raskt for best resultat.