TTL de DNS e outras coisas pequenas que mordem às 3 da manhã

As grandes falhas arquiteturais ganham os post-mortems e as palestras. As falhas que de fato acordam gente são menores. Um número num arquivo de configuração. Um default que ninguém leu. Um certificado com data. Nas auditorias que faço, essa categoria produz mais incidentes do que qualquer falha de design, e é a mais fácil de prevenir porque cada item da lista é conhecido com antecedência.

TTL de DNS, a migração que você não desfaz rápido

O time to live de um registro de DNS diz aos resolvers por quanto tempo cachear a resposta. Um TTL de um dia significa que, depois de mudar o registro, alguns usuários vão continuar batendo no endereço velho por até um dia, e você não consegue fazer eles pararem. Numa terça-feira normal, tudo bem. Durante uma migração ou um failover, é desastre, porque o objetivo todo é que o tráfego mude agora.

A disciplina é simples e quase ninguém segue. Uma semana antes de qualquer mudança planejada, abaixe o TTL para um ou cinco minutos. Espere o TTL antigo expirar em todo lugar. Faça a mudança. Confirme. Suba o TTL de volta para algo razoável, uma hora mais ou menos, porque TTL muito curto aumenta a carga no seu provedor de DNS e adiciona latência em toda consulta fria. O TTL que você precisa durante um failover tem que estar definido antes do failover, e failover por definição não é planejado. Então o registro que aponta para a sua origem de produção provavelmente deveria ficar em cinco minutos permanentemente.

Certificados, a bomba de calendário

Certificado vence numa data que era conhecida quando ele foi emitido. Não existe desculpa para ser surpreendido, e mesmo assim certificado vencido derruba uma parcela impressionante dos sistemas que já vi. A causa habitual é que a renovação automática foi configurada para o domínio principal e esquecida para o interno, o subdomínio da API, o servidor de email ou o certificado fixado dentro de um app mobile.

A solução é um inventário: todo certificado do sistema, onde é usado, quem renova e como, e um alerta trinta dias antes do vencimento que vai para um humano, mais um segundo alerta com sete dias que vai para um humano mais barulhento. Automatize a renovação onde a plataforma suportar, e depois verifique que a automação realmente renovou, porque automação que falha em silêncio é o mesmo que nenhuma automação.

Timeouts que não combinam

Um load balancer com timeout ocioso de sessenta segundos na frente de uma aplicação com timeout de requisição de noventa significa que toda requisição entre sessenta e noventa segundos devolve erro para o usuário enquanto a aplicação continua trabalhando nela. A aplicação loga sucesso. O usuário vê falha. O ticket de suporte diz 'às vezes funciona'.

Cada salto no caminho da requisição tem um timeout: navegador, CDN, load balancer, servidor de aplicação, driver do banco, banco. Eles precisam diminuir conforme você entra, para que a camada mais interna desista primeiro e as de cima consigam tratar a falha com limpeza. Escreva todos numa tabela só. Quando um mudar, confira a tabela.

O resto da lista

• Pool de conexões menor que o número de workers concorrentes, que aparece como lentidão aleatória sob carga e nada nos logs.
• Disco cheio no volume do banco porque logs, arquivos temporários ou arquivos de WAL cresceram sem regra de retenção, que aparece como tudo falhando de uma vez.
• Relógio desalinhado num servidor que nunca foi configurado para sincronizar hora, que aparece como falha de validação de token que ninguém consegue reproduzir.
• Limite de taxa numa API de terceiro que era suficiente no lançamento e agora é ultrapassado, que aparece como falha intermitente perto da virada da hora.
• Cron que roda em UTC num servidor que todo mundo assumiu estar no horário local, que aparece como relatório chegando três horas mais cedo.

Nenhum desses é interessante. Todos estão no meu checklist para qualquer sistema, porque as falhas interessantes são raras e essas não são.

O hábito

Mantenha um documento por sistema listando todo número que pode morder: TTLs, datas de certificado, timeouts por camada, tamanhos de pool, regras de retenção de disco, limites de taxa, fusos horários. Revise a cada trimestre. Leva uma hora. É a hora de maior retorno em operação, e é a diferença entre um incidente às 3 da manhã e um lembrete de calendário às 3 da tarde.