DEV Community

Francisco das Chagas
Francisco das Chagas

Posted on

8h40 com todos os dados e nenhum aviso

Mesa de plantão de madrugada: um monitor mostra as escritas no primário em alta, outro avisa que a réplica está 8h40 atrasada e que os dados do cliente estão desatualizados, e um relógio marca 00:34. Na mesa, um laptop com timeout ao ler a réplica e um rascunho de post-mortem.

00:34. Uma manutenção automática do provedor de nuvem reciclou os dois servidores do banco de produção, com 6 minutos de intervalo entre eles.

O failover funcionou em 4 segundos. A segunda reciclagem derrubou o novo primário no meio da ressincronização, e a réplica travou.

Ficamos 8h40 operando sem cópia de segurança do banco. Ninguém soube.

Quem avisou foi o negócio, pelo impacto, horas depois.

A parte mais incômoda veio depois: reconstruímos o incidente inteiro, minuto a minuto. Os logs estavam lá. As métricas estavam lá.

E a métrica de saúde da réplica marcou "saudável" durante as 8h40.

Três lições que eu levo desse dia:

  1. Telemetria sem alerta é arqueologia. O MTTR não veio de falta de dado, veio de falta de detecção.
  2. Métrica de status mente. O que mostrou o problema foi a diferença entre o que o primário escreveu e o que a réplica aplicou, uma conta simples.
  3. Um aviso num card do chat não acorda ninguém às 00:34.

Em gestão de risco, a pergunta certa não é "temos o dado?". É "quanto tempo levamos para saber?". Naquele dia, a resposta foi 8 horas.

Esse incidente virou o caso de negócio de tudo o que veio depois.

Se o seu banco perdesse a réplica agora, em quanto tempo você saberia?

Top comments (0)