Skrevet af Publiceret
Drift og overvågning

En stoppet tjeneste skal ikke altid startes igen

Mandag morgen står en tjeneste som stoppet. Alarmen er rød, og den oplagte reaktion er at starte den igen. Men ved siden af kører den nye erstatning uden fejl. Den gamle tjeneste kan være glemt efter en flytning – eller også mangler en vigtig del af driften.

Hvis I vil sætte en digital medarbejder til at følge op på driftsalarmer, skal I derfor beslutte mere end, hvad farven rød betyder. I skal beskrive, hvor medarbejderen finder den ønskede tilstand, hvad den må undersøge, og hvem der kan afgøre, at noget ikke længere skal køre.

Ellers risikerer I enten at genstarte noget, I bevidst har udfaset, eller at kalde en reel fejl for oprydning.

Det er ikke et tænkt problem. I vores egen drift fandt en digital kontrol en ældre stoppet tjeneste, mens mulige erstatninger var aktive, og produktionen så sund ud. Den kunne dokumentere sammenfaldet, men ikke udfasningsbeslutningen. Derfor blev intet genstartet, slettet eller fjernet fra overvågningen; den manglende beslutning blev undersøgelsens resultat.

Beskriv, hvad der skal køre – ikke kun hvad der kører

Begynd med at gøre den ønskede tilstand synlig for den, der skal reagere på alarmen. En liste over aktive tjenester er ikke nok, fordi den kun viser øjeblikket. Der skal også være et sted, hvor I kan se, hvilke tjenester der skal være aktive, hvilke der er på vej ud, og hvornår en ændring er godkendt.

I den konkrete situation står den gamle tjeneste stille, mens erstatningen kører. Det er et vigtigt spor, men ikke en beslutning. At to hændelser ligger tæt i tid, beviser ikke, at den ene med vilje har afløst den anden.

Google skelner i sin SRE-vejledning om overvågning mellem symptomer og årsager. En stoppet proces er en observation. Spørgsmålet om, hvorvidt stoppet er forkert, kan først besvares, når observationen holdes op mod det, I faktisk ønsker at drive.

Det behøver ikke være et stort register. For den første alarmtype kan I begynde med tjenestens navn og formål, om den skal køre nu, hvem der ejer beslutningen, og hvilken godkendt ændring der senest har flyttet den.

Hvis den ønskede tilstand ikke er dokumenteret, skal resultatet være “uafklaret” – ikke en antagelse forklædt som reparation.

Giv adgang til det, der kan forklare alarmen

Den første adgang bør gøre det muligt at samle en tidslinje uden at ændre driften. Giv derfor læseadgang til selve alarmen, tjenestens status, den seneste ændringshistorik og status på de afhængigheder, som kan be- eller afkræfte problemet.

I eksemplet er det relevant at se, at den gamle tjeneste stoppede samtidig med en større omlægning, og at de nye tjenester er aktive. Det er også relevant at kontrollere, om produktionen fortsat leverer det forventede resultat. Men ingen af delene fortæller, hvem der bestilte udfasningen, eller om en opgave stadig afhænger af den gamle tjeneste.

Det er her, en driftsopgave adskiller sig fra ren statusindsamling. Den digitale medarbejder skal kunne forbinde alarmen med ændringerne omkring den, men I bør ikke give skriveadgang alene for at gøre undersøgelsen hurtigere. Genstart, sletning og ændring af overvågningen har forskellige konsekvenser og kræver hver sin tilladelse.

Aftal reaktionen, før alarmen kommer

Beslut på forhånd, hvad der må ske ved de tre udfald i denne type sag: kendt fejl, kendt udfasning og uklar sag.

Ved en kendt fejl kan medarbejderen samle evidensen, oprette den interne driftsopgave og sende den til den aftalte ejer. Hvis I har en gennemprøvet genstart med lav konsekvens, kan den senere blive en del af mandatet. Det bør være en særskilt beslutning – ikke noget, der følger automatisk af ordet “alarm”.

Ved en godkendt udfasning kan medarbejderen lukke sagen og pege på ændringen, der forklarer stoppet. Den må gerne spare jer for gentagen undersøgelse, men kun når beslutningssporet findes.

Ved en uklar sag skal den stoppe før indgrebet. Afleveringen bør vise den korte tidslinje, hvad der stadig virker, hvad der kan være påvirket, og præcis hvilken afgørelse der mangler. Menneskelig kontrol med digitale medarbejdere handler netop ikke om at godkende hvert lille trin. Den handler om at placere de valg, som ændrer ansvar eller konsekvens, hos et menneske.

Lad ejeren ændre forventningen

Udpeg den person, der kan sige: “Denne tjeneste skal ikke længere køre.” Først derefter bør overvågningens forventning ændres.

Det er fristende at fjerne en tilbagevendende alarm, når alt ser roligt ud. Men hvis den digitale medarbejder selv kan beslutte, at en stoppet tjeneste er overflødig, kan den også gøre en reel fejl usynlig. Den må gerne foreslå en ændring af grundlaget og vedlægge sin evidens. Selve beslutningen bør ligge hos den ejer, der kender afhængighederne og kan stå på mål for udfasningen.

Når beslutningen er truffet, skal den føres tilbage til driften. Den gamle tjeneste markeres som udfaset, alarmen fjernes eller ændres, og næste måling kontrolleres. Sagen er ikke afsluttet, blot fordi nogen har skrevet “forventet” i en kommentar.

Den vej fra forsøg til fast drift er også grunden til, at Brokk & Sindre anbefaler, at et AI-forsøg får en navngiven vej ind i driften. En tilbagevendende opgave bliver først robust, når beslutningerne har en ejer og bliver en del af den almindelige arbejdsgang.

Begynd med alarmer, hvor svaret kan kontrolleres

Vælg én type alarm, hvor I allerede har en kendt fejlsag, en kendt udfasning og en uklar sag. Lad den digitale medarbejder undersøge dem med læseadgang og aflevere sin vurdering uden selv at genstarte eller fjerne noget.

Bedøm ikke kun, om den fandt den tekniske årsag. Kontrollér også, om den fandt den gældende forventning, skelnede observation fra beslutning, stoppede ved manglende dokumentation og afleverede sagen til den rigtige ejer.

Når de tre forløb fungerer, kan I udvide med flere alarmtyper eller en afgrænset reaktion, som kan rulles tilbage. Det naturlige næste skridt kan være, at kendt støj lukkes automatisk, mens ukendte stop fortsat går til et menneske. Automatisk genstart bør først komme, når I kan vise, hvilke problemer den løser, og hvilke tegn der skal forhindre den.

En rød alarm er værdifuld, fordi den kræver opmærksomhed. Den er ikke i sig selv en ordre. Før en digital medarbejder får lov til at reagere, skal I gøre forskellen mellem fejl, ændring og uafklaret tilstand tydelig – og sørge for, at en beslutning faktisk ændrer det grundlag, næste alarm bliver målt imod.

Vil I give en digital medarbejder et tydeligt mandat i driften?

Skriv til Mikkel