Riepilogo
Il 19 gennaio 2026, tra le 14:02 e le 14:28 UTC, circa due terzi di tutti i tentativi di accesso al pannello o di autenticazione tramite API sono falliti. Anche le sessioni esistenti sono state invalidate in modo casuale. Le istanze in esecuzione, le loro reti e il loro traffico non sono stati toccati per tutta la durata. Il provisioning si è messo in pausa per ventisei minuti e poi è stato smaltito; nessun ordine è andato perso.
Cronologia
Tutti gli orari in UTC, 19 gennaio 2026.
| Ora | Evento |
|---|---|
| 14:02 | Modifica allo schema dei token di sessione applicata al control plane. Il rilascio è stato contrassegnato come configurazione, quindi è andato a tutti e sei i nodi del pannello contemporaneamente. |
| 14:03 | Il tasso di errore di login sale da quasi zero al sessantuno percento. L'allarme automatico ha una finestra di due minuti e non scatta ancora. |
| 14:06 | L'allarme scatta. L'ingegnere di turno riceve la notifica. |
| 14:08 | Il primo intervenuto si connette. Vede un tasso di errore, nessun deploy nel log delle modifiche al codice, e inizia a guardare il database. |
| 14:14 | Un secondo ingegnere si unisce, controlla il registro delle modifiche di configurazione piuttosto che quello del codice, e trova la voce delle 14:02. |
| 14:16 | Causa compresa: due nodi stanno validando i token con il lettore precedente. |
| 14:19 | Inizia il rollback. |
| 14:24 | I token vengono emessi e validati correttamente su tutti e sei i nodi. Il tasso di errore scende a zero. |
| 14:28 | I lavori di provisioning in coda vengono smaltiti. Recupero completato. |
| 15:10 | Pagina di stato aggiornata. Con quarantadue minuti di ritardo, il che è un fallimento a sé stante ed è affrontato di seguito. |
Causa principale
Il token di sessione ha guadagnato un campo. I writer hanno emesso subito il nuovo formato; il reader su due dei sei nodi del pannello non era stato riavviato e rifiutava qualsiasi cosa che trasportasse il nuovo campo. Le richieste sono distribuite su tutti e sei i nodi, quindi una sessione creata su un nodo nuovo aveva all'incirca una probabilità su tre di essere validata da uno vecchio su ogni data richiesta. Il risultato sembrava intermittente, ed è per questo che i primi sei minuti di diagnostica sono andati al database piuttosto che al log di deploy.
La causa più profonda è una regola che abbiamo scritto nel 2023. Le modifiche che toccano un file di schema piuttosto che il codice dell'applicazione sono state classificate come configurazione, e la configurazione saltava lo stage canary sulla base del fatto che era, cito, solo valori. Quella regola era ragionevole quando gli unici file di schema erano i feature flag. Nessuno l'ha rivista mentre la definizione di file di schema si espandeva, e questa modifica è stata classificata correttamente secondo una regola che era diventata silenziosamente sbagliata.
Non è stato un errore dell'ingegnere che l'ha applicata. La classificazione è stata seguita esattamente come scritto.
Raggio di impatto
- Accessi al pannello: tasso di errore del sessantuno percento per ventisei minuti.
- Token API: stesso tasso di errore, stessa finestra. Le chiavi di idempotenza hanno fatto sì che i create ritentati non duplicassero.
- Istanze in esecuzione: non influenzate. Nessuna perdita di pacchetti, nessun riavvio, nessun impatto sullo storage.
- Provisioning: in pausa, non fallito. Quattro ordini sono stati regolati durante la finestra e tutti e quattro completati entro le 14:28.
Cosa abbiamo cambiato
- Lo stage canary ora è incondizionato. Qualunque cosa venga distribuita, di qualsiasi classificazione, va prima su un nodo per cinque minuti con traffico sintetico prima di andare altrove. Fatto il 21 gennaio.
- I reader accettano il formato precedente per trenta giorni. La validazione dei token è ora esplicitamente versionata con una finestra di sovrapposizione, quindi una modifica parzialmente distribuita degrada a nulla. Fatto il 23 gennaio.
- Un login sintetico viene eseguito ogni quindici secondi dall'esterno della nostra rete, in tre regioni, e fa scattare la pagina alla seconda interruzione consecutiva piuttosto che dopo una finestra di media di due minuti. Fatto il 22 gennaio.
- La pagina di stato pubblica automaticamente quando il login sintetico fallisce due volte, senza aspettare che un umano scriva una frase. Una frase umana la segue. Fatto il 26 gennaio.
Cosa non abbiamo cambiato e perché
Continuiamo a non registrare gli IP dei client o i corpi delle richieste per il traffico del pannello. Averli avrebbe mostrato immediatamente la distribuzione uno-e-tre tra i nodi e probabilmente avrebbe risparmiato nove minuti. Nove minuti non valgono una registrazione permanente di dove ogni cliente accede. La tabella di conservazione su la pagina dei log rimane invariata.
Non abbiamo spostato le sessioni in un archivio condiviso tra siti. Un archivio di sessioni unico che abbraccia ogni sito avrebbe evitato del tutto il problema dei reader misti avendo un solo reader. Creerebbe anche esattamente il record centralizzato, sempre attivo, di chi è connesso a cosa che abbiamo passato sei anni a non costruire.
Non abbiamo aggiunto un canale di annuncio di interruzione al di fuori della pagina di stato. Diverse persone hanno suggerito i social media. La pagina di stato è l'unica cosa che gestiamo di cui possiamo impegnarci a mantenere l'accuratezza, e aggiungere una seconda superficie significa una seconda superficie che diventa obsoleta.
Il credito
Lo SLA copre la disponibilità delle istanze. Le istanze sono state disponibili per tutti i ventisei minuti, quindi secondo il contratto nessuno aveva diritto a nulla. Abbiamo applicato un credito di un giorno a ogni account che ha avuto un'autenticazione fallita nella finestra, per un totale di circa tremilacento euro, perché discutere la distinzione con persone che non potevano raggiungere i loro server è un uso peggiore del pomeriggio di tutti.