Drift · gjenoppretting · trygg endring
Hvorfor reversibilitet er en produktfunksjon.
Et system er ikke ferdig designet når den nye funksjonen virker. Det må også finnes en kontrollert vei tilbake dersom forutsetningen var feil, testen overså noe eller omgivelsene endret seg.
En sikkerhetskopi er råmateriale, ikke en gjenopprettingsplan
Det er nyttig å ha en kopi av filer eller database, men kopien alene svarer ikke på hva som må gjenopprettes, i hvilken rekkefølge eller hvordan vi vet at resultatet er konsistent. Den kan også være utdatert, uleselig eller inneholde en tilstand som aldri fungerte.
Reversibilitet begynner med en kjent førtilstand. Vi registrerer hvilke komponenter som berøres, kontrollsummer eller versjoner, avhengigheter og kriteriet for at tilbakeføring er tillatt. Deretter bygges rollbacken og prøves før produksjonsendringen får status som ferdig.
Tilbakeføring må beskytte nye data
Den farligste rollbacken er en som blindt gjenoppretter gamle filer etter at verden har gått videre. Kanskje en kunde har sendt inn et skjema, en ordre er registrert eller en kollega har gjort en legitim endring. Da kan en enkel tilbakeføring slette mer enn den reparerer.
Derfor kontrollerer en trygg rollback den nåværende tilstanden. Hvis den bare inneholder endringen vår, kan den ofte fjernes presist. Hvis andre endringer har kommet til, skal mekanismen stoppe og kreve en annen gjenopprettingsplan.
Reversibilitet gjør eksperimenter billigere
Når teamet vet at en endring kan isoleres og tas tilbake, blir det tryggere å teste en liten forbedring. Feil blir mindre dramatiske, og læringen kommer raskere. Men dette gjelder bare dersom tilbakeføringen er reell, avgrenset og øvd.
En god produktopplevelse kan også gjøre dette synlig for brukeren: forhåndsvisning før publisering, angrefrist, versjonshistorikk eller mulighet til å gjenopprette en tidligere konfigurasjon. Kontroll er ikke bare et driftsverktøy; det er en del av tilliten til produktet.
Noen virkninger kan ikke trekkes tilbake
En sendt e-post kan ikke gjøres usendt hos mottakeren. En betaling, fysisk maskinbevegelse, publisert hemmelighet eller slettet ekstern konto kan ha virkninger utenfor systemet vi kontrollerer. Der må produktet bruke andre mekanismer: forhåndsvisning, totrinnsbeslutning, beløpsgrenser, forsinket utførelse eller et menneskelig stoppunkt.
Å kalle alt reversibelt er farligere enn å innrømme grensen. Systemkartet må vise hvilke handlinger som kan rulles tilbake teknisk, hvilke som kan kompenseres med en ny handling, og hvilke som i praksis er irreversible.
Design veien tilbake før du går fremover
For en nettside kan det bety kopi av nøyaktig innhold, kontroll av databasepostene og en hashbeskyttet tilbakeføring. For en integrasjon kan det være idempotente meldinger, en kompensasjonstransaksjon og kontroll på at en hendelse ikke behandles to ganger. For en enhet kan det være signert firmware, to oppstartspartisjoner og en kjent god versjon.
Teknikken varierer. Produktprinsippet er det samme: brukeren og operatøren skal vite hva som endres, hva som bevares og hvordan systemet kommer tilbake til en trygg tilstand. Da blir reversibilitet noe produktet kan love innenfor et presist omfang – og bevise.