~ O Blog de 1999 ~

Os primeiros dez minutos decidem as duas horas seguintes

Alguma coisa está partida em produção. O instinto é abrir o editor e começar a mudar coisas. Esse instinto é a razão pela qual incidentes pequenos se tornam longos. Esta é a ordem em que trabalho, e ainda não me falhou.

1. Lê o erro antes de tocar em nada

A mensagem real, o ficheiro real, a linha real. Não o resumo que alguém te deu no chat. A maioria dos incidentes para que fui chamado já estava explicada numa linha de texto que ninguém tinha lido com atenção. Lê duas vezes. Aponta o timestamp.

2. Estabelece o que o utilizador vê

É uma página em branco, um 500, uma página lenta ou dados errados? São quatro investigações diferentes. Uma página em branco costuma ser um erro fatal com o display desligado. Um 500 é uma exceção a chegar ao handler. Dados errados são piores, porque a aplicação pensa que correu bem.

Confirma o código de estado com curl, não só no navegador, porque o navegador mostra-te alegremente uma página em cache de há cinco minutos.

3. Vê o que mudou

Nove em cada dez vezes, alguma coisa mudou. Um deploy, um valor de configuração, um certificado, uma dependência, uma cron job, uma migração de base de dados, uma atualização de plugin, ou os próprios dados do cliente. Se nada mudou nos teus sistemas, pergunta o que mudou fora deles.

A primeira pergunta não é o que está partido. É o que está diferente desde a última vez que funcionou.

4. Olha para os logs, pela ordem certa

• Log da aplicação, do mais recente para trás.
• Error log do servidor web, porque os erros fatais às vezes nunca chegam ao teu framework.
• Error log do PHP, se estiver separado.
• Slow query log da base de dados, se o sintoma for o tempo.

Se os erros não chegam a um ficheiro que possas ler, isso é a primeira coisa a arranjar depois. Depurar às cegas é a versão cara do mesmo trabalho.

5. Estreita o caminho

Encontra o input mais curto que ainda falha. Se a página falha só para um utilizador, são dados. Se falha para todos, é código ou infraestrutura. Se falha só num servidor, é deriva de configuração. Este passo transforma um mistério numa lista de candidatos.

6. Muda uma coisa, depois olha outra vez

Uma. Se mudares três coisas e funcionar, não aprendeste nada e voltas na semana seguinte. Muda, verifica e anota o que fizeste.

7. Escreve antes de fechar o ticket

Três frases: o que rebentou, qual foi a causa, o que o parou. Não é para o processo. É para a versão de ti que vê o mesmo sintoma daqui a oito meses e não se lembra de nada disto.

O que evitar

Não reinicies o serviço primeiro. Isso destrói a prova de que precisas e muitas vezes só adia o problema. Também não limpes a cache primeiro, pela mesma razão. Reinicia quando perceberes, não quando tiveres esperança.

Se já está partido e precisas que fique corrigido, aceito esses pedidos.