A maioria dos outages acontece sem alerta algum. Seu dashboard nunca foi o problema.

O pior outage que já vi se desenrolar teve um dashboard verde o tempo todo. Toda checagem passou. CPU calma, error rate plano, todas as luzes na cor suave e tranquilizadora de um sistema que está bem. E enquanto isso uma fila enchia um job de cada vez, uma maré lenta para a qual nenhum threshold tinha sido escrito, até a manhã em que ela transbordou e derrubou um fluxo voltado ao cliente. Os gráficos eram honestos. Eles só estavam respondendo uma pergunta que ninguém tinha pensado em fazer três semanas antes.

Essa é a falha que nenhum alerta pega: a que você não sabia que precisava escrever um alerta. E é a maioria delas.

Aqui está a linha sobre a qual quero ser preciso, porque quase toda stack de monitoring é construída do lado errado dela. Alertas te dizem o que já quebrou; um colega percebe a coisa que ainda não tem alerta.

O dashboard responde perguntas que você já tinha

O modelo que todo mundo herda é simples e sedutor. Você decide, antecipadamente, como “quebrado” parece, latência acima de um número, erros acima de uma taxa, disco além de uma linha, e conecta um fio de armadilha a cada um. Quando um fio dispara, um page é disparado. Parece vigilância. É genuinamente útil. E silenciosamente assume algo que não deveria.

Ele assume que você já imaginou a falha.

Todo threshold naquele dashboard é uma pergunta que algum engenheiro fez num dia bom, com café e previsão, meses atrás. “E se a latência der um spike?” Boa pergunta, tem um gráfico para ela agora. Mas a fila que enche um job de cada vez, a API de terceiros que começou a retornar dados sutilmente errados em vez de erros, o config drift que só importa sob um padrão de tráfego que você nunca teve antes, ninguém fez essas perguntas, então ninguém desenhou essas linhas, então o dashboard fica verde durante todo o acidente em câmera lenta.

Um dashboard é um museu das falhas que você já sobreviveu. Ele não tem nada a dizer sobre a que está caminhando na sua direção.

Essa é a parte que dói para qualquer time que já rodou uma frota real. Seu monitoring é um registro perfeito dos seus incidentes passados e cego para o próximo. Todo painel foi adicionado na manhã seguinte a algo doer. Você está, na prática, lutando a última guerra numa parede de telas lindas, e o próximo outage, o sem alerta algum, escorrega por baixo de cada uma delas.

A correção ingênua é adicionar mais alertas. Ela piora as coisas.

Então o movimento óbvio, o que todo time busca, é: adicionar mais fios de armadilha. Cobrir mais casos. Baixar os thresholds. Se o problema são as falhas que você não previu, preveja mais delas.

Vi isso se desenrolar em time após time, e falha de um jeito específico, quase cruel. Você não consegue pré-imaginar a falha que nunca viu, é o que “nunca viu” significa, então os novos alertas ainda só cobrem o passado. E cada um que você adiciona eleva o piso de ruído. Baixe um threshold para pegar mais e ele dispara nas terças quando nada está errado. Agora o engenheiro de plantão tem quarenta pages por semana, trinta e nove deles ruído, e o custo humano chega: alert fatigue. O page que finalmente importa chega na mesma fonte, às 3h, que os trinta e nove que não importavam, e alguém meio adormecido o descarta com um gesto.

A correção ingênua não só falha em pegar o outage desconhecido. Ela treina seu time a ignorar os alertas que funcionam. Você gastou seu orçamento de vigilância em perguntas para as quais já sabia as respostas, e não sobrou nenhum para a pergunta que não tinha ocorrido a você.

E o custo se acumula silenciosamente. Todo novo fio de armadilha é outra coisa para manter, ajustar, silenciar durante a janela de manutenção, lembrar o raciocínio por trás dele daqui a seis meses quando ele disparar e ninguém na rotação atual souber por que ele existe. O dashboard que deveria reduzir seu fardo operacional vira um segundo sistema que você opera. Times terminam com centenas de alertas e um acordo compartilhado e não dito sobre quais doze de fato significam algo, ou seja, o monitoring de verdade silenciosamente voltou para a cabeça das pessoas, de onde começou, exceto que agora há uma parede de telas fingindo o contrário.

O problema mais profundo é que um threshold é um palpite estático sobre um sistema em movimento. Ele não consegue perguntar “isso é normal para agora?” porque não sabe o que é agora. Ele só sabe o número que você digitou em março. Tráfego de Black Friday parece um ataque. Uma migração planejada parece um colapso. O batch job das 3h que sempre roda parece, para um threshold burro, exatamente como o incidente das 3h que nunca rodou. O dashboard não consegue distinguir os dois, porque distingui-los nunca foi algo que uma linha fixa pudesse fazer.

A mudança: de thresholds que você define para um colega que observa

Então como é o outro lado da linha? Não um threshold mais inteligente. Uma coisa diferente inteiramente, algo que observa do jeito que um bom engenheiro de operações observa, ou seja, por mudança de caráter, não por um número cruzando uma linha.

Pense em como a melhor pessoa do seu time de fato pega problemas. Ela não memoriza thresholds. Ela dá uma olhada num gráfico e algo parece estranho, “não é assim que isso costuma parecer a esta hora.” Ela nota que o deploy saiu e o formato do tráfego mudou de um jeito que não tem nada a ver com nenhum alerta. Ela conecta o ticket de suporte que acabou de chegar à latência que ainda está tecnicamente dentro dos limites. Ela não está rodando queries. Ela está segurando um modelo do normal na cabeça e sentindo o desvio dele.

Essa é a capacidade que vale construir, e não é um dashboard maior. Alertas te dizem o que já quebrou; um colega percebe a coisa que ainda não tem alerta. A mudança é de um sistema que você configura com tudo o que teme, para um sistema que aprende como é o seu normal e fala quando a realidade para de combinar, especialmente para os desvios para os quais ninguém escreveu uma regra.

Concretamente, isso muda o que o sistema está fazendo minuto a minuto. Um threshold faz uma pergunta congelada para sempre: “X está acima de N?” Um sistema que observa faz uma viva: “o que estou vendo agora é consistente com como este sistema parece quando está saudável?” A primeira pergunta só consegue pegar as falhas que você enumerou. A segunda consegue pegar as que você não enumerou, porque ela não está comparando contra sua lista de medos, está comparando contra a realidade, e a realidade é onde o outage não imaginado de fato vive.

O que “percebe primeiro” de fato exige

É fácil dizer “um sistema que observa.” Vale ser honesto sobre o que isso demanda, porque é exatamente o conjunto de coisas que um dashboard não tem. Quatro delas, e nenhuma é uma feature que você aparafusa depois.

Primeiro, ele tem que estar rodando quando você não está olhando, não esperando você abrir uma aba, mas continuamente segurando a pergunta. A fila que enchia lentamente transbordou às 6h de um sábado. Um dashboard é tão vigilante quanto a pessoa o encarando, e às 6h de um sábado ninguém está. Um colega que percebe primeiro tem que ser a coisa que está acordada.

Segundo, ele tem que ver através das costuras. O outage sem alerta quase sempre vive entre dois sistemas, o deploy que mudou o tráfego, a API upstream que degradou, a fila que acumulou porque um worker downstream desacelerou um tantinho. Cada sinal individual ficou dentro dos limites. Só a relação entre eles quebrou. Uma parede de painéis separados não consegue ver uma relação; só consegue ver painéis. O observador tem que segurá-los numa visão só para perceber que começaram a discordar.

Terceiro, e essa é a parte que separa um colega útil de um detector de fumaça gritando, ele tem que te trazer o porquê, não só o que. “A latência subiu 12%” é um fato que você agora tem que investigar. “A latência subiu 12% e começou quatro minutos depois do deploy das 14:02, concentrada no caminho de checkout, enquanto a API de pagamentos upstream começou a retornar respostas mais lentas, aqui está a janela correlacionada” é um desvio com uma história anexada. A história é o produto. Uma flag sem razão é mais uma coisa no seu prato. Uma flag com razão é uma investigação que já está meio feita.

Há uma quarta coisa, fácil de pular e a que conquista confiança ao longo do tempo: ele tem que aprender sobre o que ficar quieto. Um observador que sinaliza todo desvio é só o dashboard barulhento de novo, vestindo um casaco mais inteligente. O batch job das 3h, a migração semanal, o surge previsível de segunda de manhã, esses são desvios de uma baseline plana, mas não são problemas, e um colega aprende isso do jeito que uma pessoa aprende: vendo-os acontecer, vendo-os resolver bem, e ajustando o senso de normal de acordo. O objetivo não é perceber tudo. É perceber as coisas certas, e ficar mais quieto, não mais alto, conforme aprende seu sistema. Esse é o inverso do alert sprawl, e é por que essa abordagem fica mais confiável com a idade em vez de mais exaustiva.

Junte essas quatro e você não tem um alerta melhor. Você tem algo mais perto de um colega de time que fica de olho na produção: acordado quando você não está, observando através das costuras, aprendendo o que ignorar, e quando algo genuinamente parece estranho, te dizendo o que mudou e por que pode importar, incluindo, e especialmente, para o tipo de falha para a qual ninguém nunca escreveu uma regra.

A virada: vigilância nunca foi um problema de dashboard

Aqui está a parte que não é sobre software.

A razão pela qual seu melhor engenheiro pega o outage sem alerta não é que ele tem dashboards melhores que todo mundo. É que ele carrega a produção na cabeça. Ele sabe como uma terça parece, como um deploy saudável se sente, quais oscilações de gráfico são chatas e quais são o primeiro tremor de algo ruim. Esse conhecimento é o ativo de verdade, e agora ele vive em uma ou duas pessoas, vai para casa à noite, tira férias, e sai pela porta quando elas pegam outro emprego.

Passamos uma década construindo dashboards para compensar o fato de que esse conhecimento não escala. Mas um dashboard sempre foi um substituto pobre para a coisa que de fato queríamos, que era um colega que percebe. As telas nunca foram o objetivo. O perceber era.

Alertas te dizem o que já quebrou; um colega percebe a coisa que ainda não tem alerta. A pessoa mais valiosa do seu time não é a que construiu mais thresholds. É a que sente o desvio, e esse sentir é finalmente algo que você pode construir no próprio sistema, para que ele não vá para casa às 18h e não saia quando ela sair.

---

É isso que estamos construindo na Apollo Space, não mais uma parede de painéis verdes, mas um colega que segura o normal do seu sistema na cabeça e fala quando a realidade para de combinar, mesmo quando ninguém escreveu a regra. Se o medo mais silencioso da sua semana é o outage durante o qual seu dashboard vai estar verde, isso não é uma lacuna no seu monitoring. É a diferença entre uma tela que você assiste e um colega de time que assiste com você.