Een linkbackchecker blokkeerde onze release: een hypothetische post-mortem
Verzonnen team, verzonnen incident, echte mechanismen. We vertellen het in de volgorde waarin een on-call engineer het zou opschrijven.
Contentin research team ·
Dit is een voorbeeld
Het team, het product en de tijdslijnen hieronder zijn verzonnen om te tonen hoe een storing zich afspeelt. Er wordt geen echt bedrijf, klant of meting beschreven.
Het incident, in volgorde
1
09:10, een launch-pagina gaat de CMS in
Een productteam van zes personen beheert een marketingwebsite op een headless CMS en een statische build. Een editor bereidt een partneraankondiging voor die linkt naar een partnerdomein dat een week daarvoor geregistreerd werd.
2
09:14, de editor drukt op publiceren
De publish-webhook roept een functie aan. De functie voert een linkbackchecker-aanroep uit tegen het partnerdomein en is zo geschreven dat hij de release blokkeert bij elk niet-succes-antwoord.
3
09:14, de build start nooit
Twee dingen falen tegelijk. Het domein is gloednieuw, dus onze index kent het mogelijk nog niet. Daarnaast was het prepaid-saldo op de sleutel van het team leeg, dus de betaalde follow-up-aanroep gaf HTTP 402 terug.
4
09:40, het team vindt het
De editor meldt een vaag foutbericht. Een engineer leest de functielogs, ziet de 402 en het lege resultaat, en besteedt twintig minuten aan het uitzoeken welke van de twee de blokkade veroorzaakte.
5
10:05, de launch gaat uit via handmatige deploy
Iemand omzeilt de hook met een handmatige deploy. De launch is 55 minuten vertraagd, en de omzeiling laat geen spoor achter van welke checks zijn overgeslagen.
Wat het team voorafgaand aan de launch gecontroleerd had
Zeer weinig, bleek achteraf. De testlijst bevatte alleen bekende domeinen, vandaar dat de kloof verborgen bleef totdat er een partnerlink binnenkwam. Een test op een bekende site bewijst dat de bedrading werkt, en zegt niets over een domein dat de index nog niet gezien heeft.
Betere testlijsten bevatten drie soorten domeinen: een gevestigd domein, een klein niche-domein en een recent geregistreerd domein. Laat alle drie door de hook lopen voordat iemand erop vertrouwt.
Welke domeinen dekte de test?
Alleen de makkelijke. Elk domein op de lijst had jaren aan geschiedenis achter zich, dus elk antwoord kwam volledig terug en niemand zag wat een leeg antwoord doet met een publicatie.
Voeg één domein toe dat echt nieuw is, en lees het resultaat handmatig. Als de notitie 'bad' (slecht) zegt waar 'unknown' (onbekend) had moeten staan, moet de regel herschreven worden voor de launch.
Wat liet de staging-run achterwege?
De staging-run gebruikte een sleutel met een gezond saldo, dus het pad voor een leeg saldo werd nooit uitgevoerd. Niemand had een test geschreven die het krediet opzettelijk opmaakte.
Houd dat pad onder test. Forceer een 402 eenmaal per kwartaal en lees wat de editor daarna ziet, want een foutpad dat niemand uitvoert is een pad dat niemand kan vertrouwen.
Waar het misging
De poort behandelde elk niet-succes als een oordeel. Dat was de root cause. Een saldo-probleem en een onbekend domein zijn feiten over de tooling en de index, en niets daarvan zegt iets over de pagina.
Onze grafiek wordt ongeveer een keer per maand herbouwd. Een domein dat na de laatste refresh geregistreerd is, kan leeg lijken, en een nieuwe partner is het normale geval voor een launch-pagina. Niemand had dit gecontroleerd. Het team had de hook alleen getest met oude, bekende domeinen zoals nytimes.com.
De tweede miss was stilte. De functie logde de fout maar stuurde geen alert, en de editor zag een generiek foutbericht zonder hint dat het krediet op was.
Kosten waren nooit het probleem. Bij 2 credits per aanroep kwam het hele maandpakket checks voor deze verzonnen site neer op ongeveer $0.60, hetzelfde bedrag als de rij met 3.000 publicaties in de kosten tabel. De poort was goedkoop en kostte hen toch een uur in 2026.
De 402 verdient een eigen regel. Een prepaid-saldo is een status die je kunt bewaken, dus een eenvoudige alarm bij 10.000 credits, wat $1 is, zou dagen eerder afgegaan zijn.
Actiepunten die het team schreef
Eigenaars zijn rollen, geen personen. Alle items zijn onderdeel van het voorbeeld.
Verandering
Eigenaar
Waarom
Behandel 402 als een skip plus een alert naar het platformkanaal
Platform
Krediet is een billing-status, geen pagina-status
Behandel een leeg resultaat voor een nieuw domein als unknown, niet als bad
Platform
De index loopt ongeveer een maand achter
Toon de reden aan de editor in duidelijke woorden
Editoriale tooling
20 minuten verloren aan het lezen van logs
Registreer overgeslagen checks op de entry
Platform
Handmatige deploys lieten geen spoor achter
Test de hook met een domein dat deze week geregistreerd is
QA
Oude domeinen verbergen de kloof
Een repetitie voor de launchweek
Voer deze uit voor de volgende launch, niet na de volgende storing.
1
Kies een domein dat nog niet gecontroleerd is
Kies een recent geregistreerd domein en roep de gratis overview-action erop aan. Bevestig dat een dun antwoord gelogd wordt als unknown in plaats van als een block.
2
Laat een testsaldo leeglopen
Gebruik een testsleutel met een klein saldo en laat deze opzettelijk naar nul lopen. Kijk toe hoe de 402 aankomt, het alert afgaat en de publish doorgaat naar de build.
3
Lees het bericht van de editor hardop voor
Vraag een collega die de hook niet kent om de fouttekst voor te lezen. Als zij niet kan zeggen wat de volgende stap is, herschrijf het bericht voor de launch.
4
Schrijf de skip in de entry
Bevestig dat een overgeslagen check een gedateerde notitie op de entry achterlaat, met de reden. Een handmatige deploy laat dan nooit een kloof achter die niemand kan verklaren.
Hoe de fix geschreven werd
Het team splitste één generieke fout in drieën, omdat elk antwoord een andere eigenaar heeft. Een 401 is een sleutelprobleem, een 402 is een billing-status, en een leeg resultaat voor een nieuw domein is gewoon unknown. Elk krijgt zijn eigen branch en zijn eigen bericht. Dat is de hele verandering.
Niemand hoefde een stack trace te lezen om te weten wat er gebeurde. De alert benoemt de status, en de editor ziet een zin die zegt wat de volgende stap is.
Waarom is een saldoalarm ver boven nul ingesteld?
Tienduizend credits is $1 tegen de gepubliceerde prijs, een klein bedrag dat toch veel waarschuwing geeft als het vroeg aankomt. Stel het alarm in waar een mens het ziet, niet in een log die niemand op een vrijdag opent.
Een check die één keer per dag luid faalt, is beter dan een stille die faalt tijdens een launch.
Spreek het aantal af met het team en schrijf het op dezelfde plek neer als de regel voor het roteren van sleutels, zodat de twee samen beoordeeld worden.
Moet een nieuw domein als een failure tellen?
Nee. Een domein dat de index nog niet gezien heeft, is een feit over de index, niet over de pagina. Sla het op als unknown met de datum, en laat een editor beslissen of hij wacht op de volgende refresh.
Hetzelfde geldt voor elk dun antwoord. Behandel het als missende data, en nooit als een oordeel over de partner.
Log de unknown antwoorden in hun eigen lijst, zodat een patroon ervan zichtbaar is bij de volgende review in plaats van begraven in de algemene log.
Wat te kopiëren
Fail open op linkdata, fail loud op het alert
Een linkcheck mag nooit het enige ding zijn tussen een editor en een launch. Laat de pagina door, tag de entry en maak de failure onmisbaar voor de persoon die de sleutel beheert.
Scheid 401, 402 en een leeg resultaat in code
Houd een saldoalarm ver boven nul (zie de kosten tabel)
Repeter de failure op staging voor launchdag
Vragen die het team achteraf stelde
De reviewvergadering bracht dezelfde handvol vragen naar voren in elke versie van dit verhaal. Hier is hoe het verzonnen team ze beantwoordde, en waarom die antwoorden per organisatie verschillen.
Geen van deze antwoorden is universeel, en elk hangt af van het doel van de pagina. Het punt is om een antwoord op papier te hebben voor de volgende release.
Had de poort closed moeten falen?
Voor dit verzonnen team, nee. Een linkcheck is een signaal gebouwd op een maandelijkse index, en het zou niet het enige ding moeten zijn tussen een editor en een launch.
Schrijf het beleid als één zin, zodat de volgende engineer een bedoelde block kan onderscheiden van een bug.
Zou een groter saldo het voorkomen?
Het zou het probleem uitgesteld hebben in plaats van het ontwerp opgelost. Een groter saldo kan ook leeglopen, en een poort die elk niet-succes als een oordeel behandelt, blokkeert nog steeds op het eerste onbekende domein.
De fix is de splitsing in drie antwoorden, plus een alarm dat vroeg afgaat. Het saldo is slechts één deel van het verhaal.
Stel dezelfde vraag aan elke poort die je bouwt: welke failure zou stil zijn, en wie zou het eerst opmerken?
Een noot over het hypothetische scenario
Echte teams zullen verschillen. Jouw team kan om goede redenen closed falen, zoals bij een gereguleerde site waar elke outbound link door een persoon beoordeeld wordt. Prima. Maak er gewoon een keuze van.
De webhook runbook somt dezelfde beslissingen op als een checklist, en de myth list behandelt de overtuigingen die dit verzonnen team in de val lieten lopen.
