En länkbackkontroll blockerade vår utgivning: en hypotetisk efteranalys

Vad teamet kontrollerade innan lansering

Mycket lite, som det visade sig. Testlistan innehöll bara kända domäner, vilket är varför gapet förblev dolt tills ett partnerlänk anlände. Ett test på en känd webbplats bekräftar att rörsystemet fungerar, och säger inget om en domän som indexet inte sett ännu.

Bättre testlistor innehåller tre typer av domäner: en etablerad, en liten nischdomän och en domän som registrerats nyligen. Kör alla tre genom webhooken innan någon litar på den.

Vilka domäner täckte testet?

Endast de lätta. Varje domän på listan hade år av historik bakom sig, så varje svar kom tillbaka fullständigt, och ingen såg vad ett tomt svar gör med en publicering.

Lägg till en domän som är riktigt ny, och läs dess resultat manuellt. Om notisen säger "dåligt" där den borde säga "okänt", behöver regeln skrivas om innan lansering.

Vad lämnade stegkörningen utanför?

Stegkörningen använde en nyckel med en frisk balans, så vägen för tom balans kördes aldrig. Ingen hade skrivit ett test som spenderar krediten avsiktligt.

Håll den vägen under test. Tvinga en 402 en gång i kvartalet, och läs vad redaktören ser efteråt, eftersom en felväg som ingen kör är en väg ingen kan lita på.

Varför hände det

Gränsen behandlade varje icke-lyckat svar som en dom. Det var rotorsaken. Ett balansproblem och en okänd domän är fakta om verktygen och indexet, och varken av dem säger något om sidan.

Vår graf byggs om ungefär en gång i månaden. En domän som registrerats efter den senaste uppdateringen kan se tom ut, och en ny partner är det normala fallet för en lanseringssida. Ingen hade kontrollerat det. Teamet hade testat webhooken endast med gamla, kända domäner som nytimes.com.

Det andra missandet var tystnad. Funktionen loggade felet men skickade inget larm, och redaktören såg ett generiskt felmeddelande utan ledtråd om att krediten hade tagit slut.

Kostnad var aldrig problemet. Till 2 kredit per anrop kom hela månaden av kontroller för denna uppfunna webbplats till cirka $0.60, samma siffra som raden med 3 000 publiceringar i kostnadstabellen. Gränsen var billig och kostade dem ändå en timme 2026.

402:an förtjänar sin egen rad. En förskottsbalans är ett tillstånd du kan övervaka, så ett enkelt larm vid 10 000 kredit, vilket är $1, hade utlöstes dagar tidigare.

Hur fixen skrevs

Teamet delade upp ett generiskt fel i tre, eftersom varje svar har en annan ansvarig. En 401 är ett nyckelproblem, en 402 är ett faktureringstillstånd, och ett tomt resultat för en ny domän är helt enkelt okänt. Varje en får sin egen gren och sitt eget meddelande. Det är hela ändringen.

Ingen behövde läsa en stackspårning för att veta vilken som hände. Larmnamnet anger tillståndet, och redaktören ser en mening som säger vad som ska göras härnäst.

Varför är ett balanslarm satt väl över noll?

Tusen kredit är $1 till det publicerade priset, en liten summa som fortfarande ger gott varsel när den anländer tidigt. Ställ in larmet där en människa kommer att se det, inte i en logg som ingen öppnar på en fredag.

En kontroll som misslyckas högljutt en gång om dagen slår en tyst en som misslyckas under en lansering.

Kom överens om siffran med teamet, och skriv in den på samma ställe som regeln för att rotera nycklar, så att de granskas tillsammans.

Ska en ny domän räknas som ett misslyckande?

Nej. En domän som indexet inte sett ännu är en fakta om indexet, inte om sidan. Spara den som okänd med datumet, och låt en redaktör avgöra om man ska vänta på nästa uppdatering.

Samma regel gäller för alla tunna svar. Behandla dem som saknad data, och aldrig som en dom om partnern.

Logga de okända svaren i sin egen lista, så att ett mönster av dem är synligt vid nästa granskning snarare än begravt i den allmänna loggen.

Frågor som teamet ställde efteråt

Granskningmötet lyfte fram samma handfull frågor i varje version av denna historia. Här är hur det uppfunna teamet svarade på dem, och varför dessa svar skulle skilja sig från en organisation till en annan.

Inget av dessa svar är universellt, och varje en beror på vad sidan är till för. Poängen är att ha ett svar på papper innan nästa utgivning.

Skulle gränsen ha misslyckats med att stänga?

För detta uppfunna team, nej. En länkkontroll är en signal byggd på ett månadsindex, och den bör inte vara det enda som står mellan en redaktör och en lansering.

Skriv policyn som en mening, så att nästa ingenjör kan skilja på en avsedd blockering och en bugg.

Skulle en större balans ha förhindrat det?

Det hade fördröjt problemet snarare än fixat designen. En större balans kan fortfarande ta slut, och en gräns som behandlar varje icke-lyckat svar som en dom kommer fortfarande att blockera vid den första okända domänen.

Fixen är uppdelningen i tre svar, plus ett larm som utlöses tidigt. Balansen är bara en del av historien.

Ställ samma fråga till vilken gräns som helst du bygger: vilket misslyckande skulle vara tyst, och vem skulle märka det först?

En notis om det hypotetiska

Verkliga team kommer att skilja sig. Ditt kan misslyckas med att stänga av av goda skäl, till exempel en reglerad webbplats där varje utgående länk granskas av en person. Bra. Bara gör det till ett val.

Den webhook-runboken listar samma beslut som en checklista, och mytlistan täcker de övertygelser som ledde detta uppfunna team i fällan.