Um verificador de linkback bloqueou nosso lançamento: um post-mortem hipotético
Equipe inventada, incidente inventado, mecânica real. Contamos na ordem em que um engenheiro de plantão escreveria.
Equipe de pesquisa da Contentin ·
Este é um exemplo
A equipe, o produto e os cronogramas abaixo são fictícios para mostrar como uma falha se desenrola. Nenhuma empresa, cliente ou medição real é descrita.
O incidente, em ordem
1
09:10, uma página de lançamento entra no CMS
Uma equipe de produto de seis pessoas executa um site de marketing em um CMS headless e uma construção estática. Um editor prepara um anúncio de parceiro que faz link para um domínio de parceiro registrado na semana anterior.
2
09:14, o editor clica em publicar
O webhook de publicação chama uma função. A função executa uma chamada de verificador de linkback contra o domínio do parceiro e foi escrita para bloquear o lançamento em qualquer resposta que não seja de sucesso.
3
09:14, a construção nunca começa
Duas coisas falham ao mesmo tempo. O domínio é novo, então nosso índice pode não conhecê-lo ainda. Separadamente, o saldo pré-pago na chave da equipe estava vazio, então a chamada de acompanhamento paga retornou HTTP 402.
4
09:40, a equipe descobre
O editor relata um erro vago. Um engenheiro lê o log da função, vê o 402 e o resultado vazio, e gasta vinte minutos descobrindo qual dos dois causou o bloqueio.
5
10:05, o lançamento é feito manualmente
Alguém contorna o hook com uma implantação manual. O lançamento tem 55 minutos de atraso, e o contorno não deixa registro de quais verificações foram puladas.
O que a equipe verificou antes do lançamento
Muito pouco, como acabou se revelando. A lista de testes continha apenas domínios bem conhecidos, é por isso que a lacuna permaneceu oculta até um link de parceiro chegar. Um teste em um site famoso prova que o encanamento funciona, e não diz nada sobre um domínio que o índice ainda não viu.
Listas de teste melhores contêm três tipos de domínio: um estabelecido, um de nicho pequeno e um domínio registrado recentemente. Execute todos os três através do hook antes que alguém confie nele.
Quais domínios o teste cobriu?
Apenas os fáceis. Cada domínio na lista tinha anos de histórico por trás, então cada resposta voltou completa, e ninguém viu o que uma resposta vazia faz para uma publicação.
Adicione um domínio que seja genuinamente novo e leia seu resultado manualmente. Se a nota disser ruim onde deveria dizer desconhecido, a regra precisa ser reescrita antes do lançamento.
O que a execução de staging deixou de fora?
A execução de staging usou uma chave com saldo saudável, então o caminho de saldo vazio nunca foi executado. Ninguém havia escrito um teste que gasta o crédito de propósito.
Mantenha esse caminho sob teste. Force um 402 uma vez por trimestre e leia o que o editor vê depois, porque um caminho de falha que ninguém executa é um caminho que ninguém pode confiar.
Por que aconteceu
O portão tratou cada não-sucesso como um veredito. Essa foi a causa raiz. Um problema de saldo e um domínio desconhecido são fatos sobre as ferramentas e o índice, e nenhum deles diz nada sobre a página.
Nosso gráfico é reconstruído cerca de uma vez por mês. Um domínio registrado após a última atualização pode parecer vazio, e um novo parceiro é o caso normal para uma página de lançamento. Ninguém havia verificado. A equipe havia testado o hook apenas com domínios antigos e bem conhecidos como nytimes.com.
A segunda falha foi o silêncio. A função registrou o erro, mas não enviou nenhum alerta, e o editor viu uma mensagem de falha genérica sem nenhuma dica de que o crédito havia acabado.
O custo nunca foi o problema. A 2 créditos por chamada, o mês inteiro de verificações para este site inventado custou cerca de $0.60, o mesmo valor da linha de 3.000 publicações na tabela de custos. O portão era barato e ainda custou a eles uma hora em 2026.
O 402 merece sua própria linha. Um saldo pré-pago é um estado que você pode monitorar, então um alarme simples em 10.000 créditos, que é $1, teria disparado dias antes.
Itens de ação que a equipe escreveu
Os responsáveis são funções, não pessoas. Todos os itens fazem parte do exemplo.
Mudança
Responsável
Por que
Tratar 402 como um skip mais um alerta para o canal da plataforma
Plataforma
Crédito é um estado de faturamento, não um estado de página
Tratar um resultado vazio para um domínio novo como desconhecido, não ruim
Plataforma
O índice atrasa cerca de um mês
Mostrar ao editor o motivo em palavras claras
Ferramentas editoriais
20 minutos perdidos lendo logs
Registrar verificações puladas na entrada
Plataforma
Implantações manuais não deixaram rastro
Testar o hook com um domínio registrado esta semana
QA
Domínios antigos escondem a lacuna
Um ensaio para a semana de lançamento
Execute isso antes do próximo lançamento, não após a próxima falha.
1
Escolha um domínio que ninguém verificou
Escolha um domínio registrado recentemente e chame a ação de visão geral gratuita nele. Confirme que uma resposta fina é registrada como desconhecida em vez de como um bloqueio.
2
Drenar um saldo de teste
Use uma chave de teste com um saldo pequeno e deixe-a chegar a zero de propósito. Observe o 402 chegar, o alarme disparar e a publicação continuar para a construção.
3
Leia a mensagem do editor em voz alta
Peça a um colega que não viu o hook para ler o texto do erro. Se ele não conseguir dizer o que fazer a seguir, reescreva a mensagem antes do lançamento.
4
Escreva o skip na entrada
Confirme que uma verificação pulada deixa uma nota datada na entrada, com o motivo. Uma implantação manual então nunca deixa uma lacuna que ninguém pode explicar.
Como a correção foi escrita
A equipe dividiu uma falha genérica em três, porque cada resposta tem um responsável diferente. Um 401 é um problema de chave, um 402 é um estado de faturamento e um resultado vazio para um domínio novo é simplesmente desconhecido. Cada um recebe seu próprio branch e sua própria mensagem. Essa é a mudança inteira.
Ninguém precisava ler um stack trace para saber qual aconteceu. Os nomes dos alertas nomeiam o estado, e o editor vê uma frase que diz o que fazer a seguir.
Por que um alarme de saldo é definido bem acima de zero?
Dez mil créditos são $1 no preço publicado, uma pequena quantidade que ainda dá muito aviso quando chega cedo. Defina o alarme onde um humano vai ver, não em um log que ninguém abre na sexta-feira.
Uma verificação que falha alto uma vez por dia supera uma silenciosa que falha durante um lançamento.
Concordar com o número com a equipe e escrevê-lo no mesmo lugar que a regra para rotacionar chaves, para que os dois sejam revisados juntos.
Um domínio novo deve contar como uma falha?
Não. Um domínio que o índice ainda não viu é um fato sobre o índice, não sobre a página. Armazene-o como desconhecido com a data e deixe um editor decidir se deve esperar pela próxima atualização.
A mesma regra se aplica a qualquer resposta fina. Trate-a como dados ausentes e nunca como um veredito sobre o parceiro.
Registre as respostas desconhecidas em sua própria lista, para que um padrão delas seja visível na próxima revisão em vez de enterrado no log geral.
O que copiar
Falha aberta em dados de link, falhe alto no alerta
Uma verificação de link nunca deve ser a única coisa entre um editor e um lançamento. Deixe a página passar, marque a entrada e torne a falha impossível de perder para a pessoa que é responsável pela chave.
Diferencie 401, 402 e um resultado vazio no código
Mantenha um alarme de saldo bem acima de zero (veja a tabela de custos)
Ensaie a falha no staging antes do dia do lançamento
Perguntas que a equipe fez depois
A reunião de revisão levantou o mesmo punhado de perguntas em cada versão desta história. Aqui está como a equipe inventada respondeu a elas, e por que essas respostas difeririam de uma organização para outra.
Nenhuma dessas respostas é universal, e cada uma depende do propósito da página. O ponto é ter uma resposta no papel antes do próximo lançamento.
O portão deveria ter falhado fechado?
Para esta equipe inventada, não. Uma verificação de link é um sinal construído em um índice mensal, e não deve ser a única coisa entre um editor e um lançamento.
Escreva a política como uma frase, para que o próximo engenheiro possa distinguir um bloqueio intencional de um bug.
Um saldo maior teria evitado?
Teria atrasado o problema em vez de corrigir o design. Um saldo maior ainda pode acabar, e um portão que trata cada não-sucesso como um veredito ainda bloqueará no primeiro domínio desconhecido.
A correção é a divisão em três respostas, mais um alarme que dispara cedo. O saldo é apenas uma parte da história.
Faça a mesma pergunta para qualquer portão que você construir: qual falha seria silenciosa, e quem notaria primeiro?
Uma nota sobre o hipotético
Equipes reais diferirão. A sua pode falhar fechado por bons motivos, como um site regulado onde cada link de saída é revisado por uma pessoa. Tudo bem. Apenas faça dessa uma escolha.
