Gestire un guasto d’integrazione con stati attendibili

Durante un guasto d’integrazione renda visibile ciò che il software sa realmente. Un portale può attenuare un’interruzione, ma non deve mostrare un’elaborazione ERP ancora aperta come un ordine completato. Contano stati tracciabili e una ripresa controllata.

Determinare l’ultimo stato accertato

In un portale fittizio un cliente invia una richiesta di creazione ordine. L’ERP è temporaneamente irraggiungibile. Il portale deve poter ricavare dal proprio stato di elaborazione registrato in modo affidabile se la richiesta è già stata accettata. Un’indicazione sullo schermo non salva da sola una richiesta.

Questi stati costituiscono il nostro modello d’esempio. Le etichette devono corrispondere alle prove effettive dell’applicazione. Una ricezione HTTP rapida e riuscita non dimostra da sola che la creazione dell’ordine sia completata.

Associare i tentativi ripetuti alla stessa operazione

Se un cliente invia nuovamente perché lo stato visualizzato resta irrisolto, l’applicazione deve poter riconoscere se si intende lo stesso ordine. Definisca l’identificatore, il suo ambito e la gestione delle richieste già elaborate. Stripe descrive la consegna ripetuta di eventi come un caso concreto di webhook; questo non stabilisce una regola universale di ripetizione per il Suo ERP.

Verifichi soprattutto il caso in cui l’ordine ERP è stato creato, ma la risposta è andata persa. Un nuovo tentativo non deve avviare una seconda creazione senza verifica.

Definire responsabilità e comunicazione

Stabilisca chi valuta il guasto, chi autorizza la ripresa dell’elaborazione e chi aggiorna lo stato visibile. Il Google SRE Workbook distingue la risoluzione di un incidente dal coordinamento e dalla comunicazione. Un piccolo team può riunire i ruoli, ma ha comunque bisogno di responsabilità chiare.

Riprendere in modo controllato dopo il ripristino

La raggiungibilità dell’ERP è il punto di partenza della verifica. Chiarisca le richieste aperte e quelle già elaborate prima di eseguire nuovamente il lavoro in attesa. Mostri lo stato confermato solo quando esiste la prova corrispondente.

Provi un guasto prima del salvataggio, uno dopo e una risposta ERP persa. Verifichi lo stato visibile nel portale e il numero effettivo di ordini creati. Questo mostra se il riscontro resta attendibile quando il cliente vive direttamente il guasto.

Fonti

• Google SRE Workbook: Incident Response

• Stripe: Webhooks