Automatisering som krever manuell overvåking er ikke automatisering

En oppgave er ikke automatisert bare fordi et skript starter den. Hvis noen må følge med, oppdage avvik og rydde opp hver gang virkeligheten ikke følger oppskriften, har vi først og fremst flyttet det manuelle arbeidet.

Min erfaring er at de mest frustrerende automatiseringene ikke alltid er de som stopper tydelig. Det er de som ser ut til å fungere, men bare så lenge ingenting uventet skjer. De er ofte laget av noen som har fått normalforløpet til å virke, uten å tenke gjennom hva systemet skal gjøre når en forutsetning endrer seg.

Da blir resultatet et paradoks: Løsningen ble innført for å spare tid, men krever at et menneske kontrollerer den, tolker uklare feil og husker hva som må gjøres etterpå. Den ansatte er fortsatt en del av arbeidsflyten, bare uten at dette står i prosedyren.

Et skript er ikke det samme som en automatisert prosess

Det er enkelt å automatisere den lykkelige veien: En fil kommer inn, et felt leses, en oppføring opprettes og en melding sendes. Utfordringen begynner når filen mangler et felt, tilkoblingen svarer for sent, samme hendelse kommer to ganger eller mottakersystemet godtar forespørselen uten å fullføre behandlingen.

Dette er ikke sjeldne særtilfeller som kan ignoreres. Det er en del av den virkeligheten automasjonen skal fungere i. En robust løsning må derfor gjøre mer enn å utføre hovedhandlingen. Den må kunne avgjøre om handlingen faktisk lyktes, og den må vite hva den skal gjøre når svaret er nei eller uklart.

Her går grensen mellom et nyttig skript og en automatisert arbeidsprosess. Skriptet utfører kommandoer. Prosessen håndterer også tilstand, avvik, ansvar og dokumentasjon.

Overvåking er nødvendig, men barnevakt er et faresignal

All viktig automasjon bør overvåkes. Det betyr ikke at et menneske skal sitte og se på at den kjører. God overvåking gjør resultatet synlig og varsler når noen faktisk må gripe inn. Dårlig overvåking betyr at en ansatt må åpne flere systemer, sammenligne tall og håpe at fravær av feilmeldinger betyr at alt gikk bra.

Forskjellen ligger i kvaliteten på signalet. «Jobben kjørte» sier bare at noe startet. «Tre av tre oppføringer ble opprettet, lest tilbake og knyttet til riktig kunde» sier noe om resultatet. Og hvis behandlingen stopper, bør varselet forklare hvilken hendelse som feilet, hva som allerede er gjort, og om det er trygt å prøve på nytt.

Googles fagbok om Site Reliability Engineering skiller mellom målinger som beskriver årsaker inne i systemet og målinger som viser symptomer brukeren faktisk merker. Den anbefaler også at varsler skal være konkrete nok til at et menneske kan handle på dem. Det er et nyttig prinsipp langt utenfor store nettsystemer: Overvåk utfallet, ikke bare aktiviteten.

Den virkelige testen er hva som skjer ved en overraskelse

Før en automasjon settes i drift, bør noen stille spørsmålene som vanligvis blir utsatt:

• Hva er et gyldig og komplett utgangspunkt?
• Hvordan bekrefter vi at mottakersystemet faktisk lagret riktig resultat?
• Hva skjer hvis samme melding eller fil behandles to ganger?
• Kan jobben kjøres på nytt uten å opprette duplikater eller gjøre skade?
• Hvilke avvik kan løses automatisk, og hvilke krever en beslutning?
• Hvem mottar varselet, og hvem eier oppfølgingen?
• Hva blir stående uferdig hvis prosessen stopper halvveis?
• Hvordan finner en annen person ut hva løsningen gjør om seks måneder?

Hvis svarene er «det ser vi når det skjer», er ikke løsningen ferdig. Da er den menneskelige feilrettingen en skjult del av designet.

Dokumentasjon er en del av automasjonen

Selv en enkel automatisering bør dokumentere hensikt, datakilder, avhengigheter, ansvar, normalforløp og kjente stoppunkter. Dokumentasjonen trenger ikke være lang, men den må være presis nok til at løsningen kan forstås uten personen som laget den.

Dette handler ikke bare om fremtidig vedlikehold. Dokumentasjonen tvinger fram avklaringer mens løsningen fortsatt bygges. Hvilken konto kjører jobben? Hva skjer når en tilgang utløper? Hvilke data kan endres? Hvor finnes loggen? Hvem kan stoppe prosessen? En kort beskrivelse av disse punktene avslører ofte hull som ellers først blir synlige i drift.

Derfor henger god automasjon tett sammen med at virksomheten eier og forstår sin egen IT-dokumentasjon. En udokumentert automasjon er i praksis avhengig av hukommelsen til én person.

Manuelle kontrollpunkter kan være riktig

Poenget er ikke at alle prosesser må være hundre prosent selvkjørende. Et manuelt kontrollpunkt kan være fornuftig når konsekvensen av feil er stor, grunnlaget er tvetydig eller en beslutning krever menneskelig skjønn. Men da må vi beskrive løsningen ærlig: Den er en delvis automatisert arbeidsflyt med en bevisst godkjenning, ikke en helautomatisk prosess.

Et godt kontrollpunkt presenterer et avgrenset valg og nødvendig kontekst. Et dårlig kontrollpunkt ber en ansatt undersøke hele saken på nytt. I det første tilfellet har automasjonen fjernet rutinearbeid. I det andre har den bare lagt til et nytt system som må passes på.

Dette er også grunnen til at enda et IT-system ikke automatisk gir en enklere arbeidsdag. Verdien ligger i redusert friksjon og bedre kontroll, ikke i antall funksjoner eller integrasjoner.

Bygg for avvik før dere bygger for volum

Det kan være fristende å måle automasjon i hvor mange oppgaver den utfører. Jeg mener en bedre målestokk er hvor mye trygg, forutsigbar oppfølging den fjerner. En løsning som behandler tusen hendelser, men skaper ti uklare avvik hver dag, kan være dårligere enn en enklere løsning som stopper kontrollert og gir ett presist varsel.

AWS Well-Architected anbefaler blant annet små, reversible endringer, å forutse feil og å lære av hendelser. Oversatt til en mindre virksomhet betyr det at automasjoner bør innføres i avgrensede steg, med en tydelig tilbakevei og en plan for hvordan faktiske feil skal forbedre neste versjon.

Start derfor med en liten arbeidsflyt. Kjør den på realistiske variasjoner, ikke bare perfekte testdata. Kontroller resultatet i mottakersystemet. Fremprovoser en feil. Forsøk å kjøre samme hendelse på nytt. La en annen person bruke dokumentasjonen. Først når dette fungerer, er det fornuftig å øke volumet.

Automatisering skal redusere behovet for oppmerksomhet

En god automasjon gjør ikke mennesker overflødige. Den bruker oppmerksomheten deres bedre. Den håndterer det forutsigbare, dokumenterer det som skjedde og ber om hjelp når det finnes et reelt avvik.

En dårlig automasjon gjør det motsatte. Den skjuler kompleksitet bak en knapp eller en tidsplan, mens ansvaret for å oppdage feil fortsatt ligger hos den som allerede har andre oppgaver.

Derfor er min enkle regel denne: Hvis løsningen krever løpende manuell overvåking for å være trygg, er den ikke ferdig automatisert. Den kan fortsatt være nyttig, men vi bør kalle den det den er, dokumentere den menneskelige rollen og forbedre den til oppfølgingen blir unntaket, ikke selve driftsmodellen.

Kilder og videre lesning

• Google SRE: Monitoring Distributed Systems
• AWS Well-Architected: Operational Excellence design principles