Virheenkäsittely erottaa prototyypin tuotantokoodista

Skripti toimii. Sitten API vastaa 429, verkko katkee puolessa välissä ja joku ilmoittaa, että automaatio rikkoi tuotannon.

Tämä on se hetki, jolloin prototyyppi eroaa tuotantokoodista.

Yksinkertainen jako: prototyyppi käsittelee happy pathin. Tuotantokoodi käsittelee kaiken muun.

Kolme asiaa, jotka puuttuvat lähes joka kerta

Retry-logiikka

Jos ulkoinen API ei vastaa tai palauttaa 429, skripti kaatuu. Sen sijaan pitäisi yrittää uudelleen, odottaa hetki, yrittää uudelleen, ja vasta sitten ilmoittaa virheestä.

Yksinkertainen esimerkki PowerShellissa:

$attempts = 0
do {
    try {
        $result = Invoke-RestMethod -Uri $url -Headers $headers
        break
    } catch {
        $attempts++
        Write-Warning "Yritys $attempts epäonnistui: $($_.Exception.Message)"
        Start-Sleep -Seconds (2 * $attempts)
    }
} while ($attempts -lt 3)

if ($attempts -ge 3) {
    Send-MailMessage -To "admin@yritys.fi" -Subject "Automaatio epäonnistui" ...
}

Exponential backoff, eli kasvava odotusaika uusintojen välillä, on standardi. Se antaa palvelulle aikaa toipua.

Osittaisten ajojen käsittely

Jos skripti prosessoi 500 käyttäjää ja kaatuu numero 312:ssa, mitä tapahtuu? Ajetaanko kaikki uudelleen alusta? Käsitelläänkö osa käyttäjistä kahdesti?

Tähän tarvitaan joko checkpoint, jossa tallennetaan mihin asti on päästy ja jatketaan siitä, tai idempotenssi: varmistetaan, että sama operaatio voidaan ajaa uudelleen ilman sivuvaikutuksia. Idempotenssia käsitellään tarkemmin erillisessä artikkelissa.

Hälytykset oikeille ihmisille

Try-catch, joka kirjoittaa virheen lokiin kansioon, johon kukaan ei katso, ei ole virheenkäsittelyä. Se on itsepetos.

Virheistä pitää ilmoittaa jollekin. Sähköposti, Teams-viesti, kirjaus seurantatyökaluun. Lokin pitää sisältää riittävästi tietoa, jotta vian voi selvittää ilman arvausta.

Miksi tämä unohtuu

Koska prototyyppi toimii. Kun testivaiheessa kaikki menee hyvin, virheenkäsittely tuntuu tarpeettomalta.

Mutta automaatio, joka hajoaa hiljaa, on pahempi kuin automaatio, joka ei toimi ollenkaan. Ainakin silloin tiedetään, että pitää tehdä jotain.

Tuotantovalmis automaatio ilmoittaa selkeästi kun jokin menee pieleen, eikä jätä virhettä hiljaisesti lokiin.

Haluatko arvioida automaatioidenne tuotantovalmiutta? Otetaan yhteyttä.