Configuração da ferramenta de Domain Rating para uma planilha e um job cron

Onde esta configuração falha

O silêncio é a falha usual. Um job cron que falha parece o mesmo que um que funcionou.

Verifique o código HTTP. Um 401 significa que a chave está faltando ou errada, e um 402 significa que o crédito acabou, então alerte sobre qualquer um deles e corrija antes que o relatório do próximo mês esteja vencido.

Lembre-se também que a paginação é limitada a 50.000 linhas de profundidade, e que bulk_dr aceita até 2.000 domínios por chamada. Listas maiores precisam de chunking, que é um loop extra e custa um crédito por chunk.

Teste manualmente primeiro. Execute a linha cron em um terminal, leia o arquivo de log e verifique se o saldo caiu exatamente pelo custo esperado. Depois, veja como os números se comparam com um plano de suite e decida com que frequência executá-lo.

Versione sua lista de domínios. Mantenha o arquivo em um repositório ou unidade compartilhada com histórico, para que, quando um número mudar em março, você possa ver se a lista também mudou. Adicione uma coluna de notas para domínios que você adicionou propositalmente, como um novo concorrente ou um cliente que assinou no mês. Trate a lista como dados com um proprietário, porque o bug mais barato é aquele que você encontra em um diff.

Dividindo uma lista longa em chunks

Listas longas são onde uma configuração elegante encontra seu limite. Uma chamada em massa aceita até 2.000 domínios, então uma lista de 5.000 precisa de três solicitações, e a divisão deve acontecer antes da primeira chamada ser enviada.

Divida por uma regra estável, como a ordem classificada da coluna de domínio. Dessa forma, o mesmo domínio cai no mesmo chunk todo mês, e a comparação se mantém.

Listas com mais de 2.000 linhas

Escreva cada chunk na planilha como seu próprio bloco, com o número do chunk na primeira coluna. Um chunk falho é então fácil de encontrar.

Cada chunk custa um crédito, então uma lista de 5.000 linhas resulta em 3 créditos por execução, o que equivale a $0,0003. Uma ferramenta de Domain Rating é tão útil quanto a lista que ela lê, então mantenha essa lista organizada.

Se a lista crescer além de 5.000 linhas, reconsiderar a estrutura da própria planilha. Uma aba por mês mantém cada execução legível quando as linhas se acumulam.

Reexecutar um único chunk falho

Se o chunk dois retornar um erro, reexecute apenas o chunk dois. Reexecutar a lista inteira gastaria crédito em linhas que já retornaram.

Registre o número do chunk com o código de status, para que a reexecução seja uma linha no log, não uma busca na planilha.

Mantendo o mapa de chunks estável

Se a ordem da lista de domínios mudar, os chunks se movem, e uma comparação mês a mês quebra. Classifique a lista antes de dividi-la, sempre.

Armazene o mapa de chunks ao lado da lista.

Um teste simples: escolha qualquer chunk e recalcule suas linhas contra a lista. Uma discrepância significa que o mapa se desviou, e isso é mais barato de encontrar na planilha do que no relatório.

O que uma linha de log mensal útil contém

Um log que apenas diz ok não é muito de um log. Cada execução deve escrever uma linha que uma pessoa cansada possa ler em dez segundos: a data, o chunk, o status, os créditos gastos e o saldo após a chamada.

Hipotético: uma linha que mostra o chunk quatro, status 200, um crédito gasto e o saldo restante após a chamada responde à maioria das perguntas um mês depois sem abrir a resposta.

Campos dignos de registro

Registre a data, o nome da lista, o número do chunk, o código de status, os créditos cobrados e o saldo após a chamada. Esses seis campos cobrem a maioria das perguntas um mês depois.

Adicione uma nota de texto livre apenas quando uma pessoa alterou algo manualmente.

Alertas que não gritam lobo

Alerte imediatamente sobre um 401 ou 402, pois ambos significam que o job não pode fazer seu trabalho. Um aviso de saldo baixo deve usar o limite que você escolheu, para que dispare uma vez e diga o que fazer a seguir.

Envie um alerta por execução, não um por linha, ou a caixa de entrada se tornará ruído.

Quem nota quando o job quebra

Um job mensal é executado sem ninguém observando. Esse é o ponto de automatizá-lo, e é também por isso que uma falha pode ficar despercebida por semanas.

Nomeie a pessoa que lê o log e a pessoa que conserta o job. Dois nomes batem um. Feriados acontecem. O runbook explica como escolher a lista em primeiro lugar.

Tempo gasto na configuração versus manutenção

A primeira execução leva a maior parte da hora, já que a chave, a planilha e a chamada de teste precisam de atenção. Depois disso, a rotina deve precisar de uma olhada a cada mês, não de uma reconstrução.

Se a manutenção crescer, a lista geralmente é a causa. Uma lista que muda toda semana precisa de um proprietário, uma versão e uma regra para adições.

Tornando uma falha visível

Uma linha faltando na saída é mais fácil de ver do que um erro silencioso. Compare a contagem de linhas com o comprimento da lista em cada execução e escreva um aviso quando eles diferirem.

Mantenha esse aviso no mesmo arquivo de log, para que a pessoa que lê o log o veja primeiro.

Agendamento em torno da atualização do índice

O índice é atualizado aproximadamente uma vez por mês, então uma execução no primeiro dia do mês pode ler figuras da construção anterior. Executar alguns dias depois, como as etapas acima sugerem, dá tempo para a atualização ser concluída.

Escolha o mesmo dia a cada mês para que a série permaneça comparável, e escreva esse dia em um comentário na linha cron.

Quando parar de automatizar

Um job que é executado uma vez por trimestre pode não justificar uma linha cron. Uma planilha e um lembrete de calendário podem ser suficientes, e uma rotina semi-automatizada é pior do que uma manual clara.

Automatize quando as mesmas etapas forem executadas limpas por vários ciclos seguidos.