Un linkback checker ha bloccato il nostro rilascio: un post-mortem ipotetico
Team inventato, incidente inventato, meccanica reale. Lo raccontiamo nell'ordine in cui lo scriverebbe un ingegnere in servizio.
Team di ricerca Contentin ·
Questo è un esempio
Il team, il prodotto e le tempistiche qui sotto sono inventati per mostrare come si svolge un guasto. Non viene descritta alcuna azienda, cliente o misurazione reale.
L'incidente, in ordine cronologico
1
09:10, una pagina di lancio entra nel CMS
Un team di prodotto di sei persone gestisce un sito marketing su un CMS headless e una build statica. Un editore prepara un annuncio di partnership che collega a un dominio partner registrato la settimana precedente.
2
09:14, l'editore preme pubblica
Il webhook di pubblicazione chiama una funzione. La funzione esegue una chiamata al linkback checker contro il dominio partner ed è configurata per bloccare il rilascio in caso di risposta non positiva.
3
09:14, la build non parte mai
Due cose falliscono contemporaneamente. Il dominio è nuovissimo, quindi il nostro indice potrebbe non conoscerlo ancora. Inoltre, il saldo prepagato sulla chiave del team era vuoto, quindi la chiamata follow-up a pagamento ha restituito HTTP 402.
4
09:40, il team lo scopre
L'editore segnala un errore vago. Un ingegnere legge il log della funzione, vede il 402 e il risultato vuoto, e impiega venti minuti per capire quale dei due abbia causato il blocco.
5
10:05, il lancio va in onda manualmente
Qualcuno aggira il hook con un deploy manuale. Il lancio è in ritardo di 55 minuti e l'aggiramento non lascia traccia di quali controlli siano stati saltati.
Cosa ha controllato il team prima del lancio
Molto poco, come si è scoperto. L'elenco dei test includeva solo domini ben noti, motivo per cui il divario è rimasto nascosto fino all'arrivo di un link partner. Un test su un sito famoso dimostra che la canalizzazione funziona, ma non dice nulla su un dominio che l'indice non ha ancora visto.
Elencati di test migliori contengono tre tipi di dominio: uno consolidato, uno di nicchia e un dominio registrato di recente. Esegui tutti e tre attraverso l'hook prima che qualcuno si fidi di esso.
Quali domini ha coperto il test?
Solo quelli facili. Ogni dominio nell'elenco aveva alle spalle anni di storia, quindi ogni risposta è tornata completa e nessuno ha visto cosa fa una risposta vuota a una pubblicazione.
Aggiungi un dominio che è genuinamente nuovo e leggi il suo risultato a mano. Se la nota dice "bad" dove dovrebbe dire "unknown", la regola deve essere riscritta prima del lancio.
Cosa ha lasciato fuori l'esecuzione in staging?
L'esecuzione in staging ha utilizzato una chiave con un saldo sano, quindi il percorso del saldo vuoto non è mai stato eseguito. Nessuno aveva scritto un test che spende il credito appositamente.
Mantieni quel percorso sotto test. Forza un 402 una volta al trimestre e leggi ciò che vede l'editore dopo, perché un percorso di guasto che nessuno esegue è un percorso che nessuno può fidarsi.
Perché è successo
Il cancello ha trattato ogni risposta non positiva come un verdetto. Questa era la causa radice. Un problema di saldo e un dominio sconosciuto sono fatti riguardanti gli strumenti e l'indice, e nessuno dei due dice nulla sulla pagina.
Il nostro grafico viene ricostruito circa una volta al mese. Un dominio registrato dopo l'ultimo aggiornamento può apparire vuoto, e un nuovo partner è il caso normale per una pagina di lancio. Nessuno aveva controllato. Il team aveva testato l'hook solo con domini vecchi e ben noti come nytimes.com.
La seconda mancanza è stata il silenzio. La funzione ha registrato l'errore ma non ha inviato un avviso, e l'editore ha visto un messaggio di guasto generico senza indizi sul fatto che il credito fosse esaurito.
Il costo non era mai stato il problema. A 2 crediti a chiamata, l'intero mese di controlli per questo sito inventato è ammontato a circa $0.60, la stessa cifra della riga 3.000 pubblicazioni nella tabella dei costi. Il cancello era economico eppure è costato loro un'ora nel 2026.
Il 402 merita una sua riga. Un saldo prepagato è uno stato che puoi monitorare, quindi un semplice allarme a 10.000 crediti, che sono $1, sarebbe scattato giorni prima.
Azioni che il team ha scritto
I proprietari sono ruoli, non persone. Tutti gli elementi fanno parte dell'esempio.
Modifica
Proprietario
Perché
Tratta il 402 come un salto più un avviso al canale della piattaforma
Piattaforma
Il credito è uno stato di fatturazione, non uno stato della pagina
Tratta un risultato vuoto per un nuovo dominio come sconosciuto, non come cattivo
Piattaforma
L'indice è in ritardo di circa un mese
Mostra all'editore il motivo in parole chiare
Strumenti editoriali
20 minuti persi a leggere i log
Registra i controlli saltati nella voce
Piattaforma
I deploy manuali non hanno lasciato tracce
Testa l'hook con un dominio registrato questa settimana
QA
I domini vecchi nascondono il divario
Una prova per la settimana del lancio
Esegui queste prima del prossimo lancio, non dopo il prossimo guasto.
1
Scegli un dominio che nessuno ha controllato
Scegli un dominio registrato di recente e chiama l'azione di panoramica gratuita su di esso. Conferma che una risposta sottile sia registrata come sconosciuta piuttosto che come blocco.
2
Svuota un saldo di test
Usa una chiave di test con un piccolo saldo e lasciala andare a zero appositamente. Osserva il 402 arrivare, l'allarme scattare e la pubblicazione continuare alla build.
3
Leggi ad alta voce il messaggio dell'editore
Chiedi a un collega che non ha visto l'hook di leggere il testo dell'errore. Se non può dire cosa fare dopo, riscrivi il messaggio prima del lancio.
4
Scrivi il salto nella voce
Conferma che un controllo saltato lasci una nota datata sulla voce, con il motivo. Un deploy manuale non lascerà mai un divario che nessuno può spiegare.
Come è stata scritta la correzione
Il team ha diviso un guasto generico in tre, perché ogni risposta ha un proprietario diverso. Un 401 è un problema della chiave, un 402 è uno stato di fatturazione e un risultato vuoto per un nuovo dominio è semplicemente sconosciuto. Ognuno ottiene il suo ramo e il suo messaggio. Questa è l'intera modifica.
Nessuno ha avuto bisogno di leggere una traccia dello stack per sapere quale fosse accaduto. I nomi degli avvisi indicano lo stato, e l'editore vede una frase che dice cosa fare dopo.
Perché un allarme sul saldo è impostato ben sopra lo zero?
Diecimila crediti sono $1 al prezzo pubblicato, una piccola quantità che dà comunque un ampio preavviso quando arriva in anticipo. Imposta l'allarme dove un umano lo vedrà, non in un log che nessuno apre un venerdì.
Un controllo che fallisce rumorosamente una volta al giorno batte uno silenzioso che fallisce durante un lancio.
Concorda il numero con il team e scrivilo nello stesso posto della regola per la rotazione delle chiavi, così che vengano revisionati insieme.
Un nuovo dominio dovrebbe contare come un fallimento?
No. Un dominio che l'indice non ha ancora visto è un fatto riguardante l'indice, non la pagina. Archivialo come sconosciuto con la data e lascia che un editore decida se aspettare il prossimo aggiornamento.
La stessa regola si applica a qualsiasi risposta sottile. Trattala come dati mancanti e mai come un verdetto sul partner.
Registra le risposte sconosciute nella loro lista, così che un loro modello sia visibile alla prossima revisione piuttosto che sepolto nel log generale.
Cosa copiare
Falli aperto sui dati del link, falli rumoroso sull'avviso
Un controllo del link non dovrebbe mai essere l'unica cosa tra un editore e un lancio. Lascia passare la pagina, tagga la voce e rendi il guasto impossibile da perdere per la persona che possiede la chiave.
Distingui nel codice tra 401, 402 e un risultato vuoto
Mantieni un allarme sul saldo ben sopra lo zero (vedi la tabella dei costi)
Ripeti il guasto in staging prima del giorno del lancio
Domande che il team ha posto dopo
La riunione di revisione ha sollevato lo stesso manipolo di domande in ogni versione di questa storia. Ecco come il team inventato ha risposto e perché quelle risposte differirebbero da un'organizzazione all'altra.
Nessuna di queste risposte è universale e ciascuna dipende da ciò di cui si occupa la pagina. Il punto è avere una risposta su carta prima del prossimo rilascio.
Il cancello avrebbe dovuto fallire in chiusura?
Per questo team inventato, no. Un controllo del link è un segnale basato su un indice mensile e non dovrebbe essere l'unica cosa tra un editore e un lancio.
Scrivi la politica come una frase, così che il prossimo ingegnere possa distinguere un blocco intenzionale da un bug.
Un saldo più grande avrebbe prevenuto il problema?
Avrebbe ritardato il problema invece di risolvere il design. Un saldo più grande può comunque esaurirsi e un cancello che tratta ogni risposta non positiva come un verdetto bloccherà comunque al primo dominio sconosciuto.
La correzione è la divisione in tre risposte, più un allarme che scatta in anticipo. Il saldo è solo una parte della storia.
Poni la stessa domanda a qualsiasi cancello che costruisci: quale guasto sarebbe silenzioso e chi se ne accorgerebbe per primo?
Una nota sull'ipotetico
I team reali differiranno. Il tuo potrebbe fallire in chiusura per buoni motivi, come un sito regolamentato dove ogni link in uscita è revisionato da una persona. Va bene. Basta che sia una scelta.
