Pensamento de Produto

O alerta das 4h da manhã é um erro de medição

Ninguém deveria estar acordado às 2h55 quando o pool começou a subir. Não construímos um pager mais inteligente, construímos a coisa que fica de pé na hora em que nenhum humano consegue.

ASR

Apollo Space Research

Apollo Space

· 13 min de leitura

Há uma hora, na maioria das noites, para a qual ninguém está acordado.

É a hora depois de um deploy ficar quieto e antes de qualquer coisa quebrar, onde um connection pool começa a subir de saudável para tensionado, um por cento de cada vez, e ninguém está olhando, porque observar um pool que ainda está bem às 2h55 não é um trabalho que alguém jamais teve. O dashboard que mostraria o drift está escuro, porque os humanos estão dormindo, que é o estado correto e humano para um humano estar às 2h55.

Então às 4h02 o pager dispara. A taxa de erro de checkout está subindo. O engenheiro que tirou a palha mais curta esta semana alcança um laptop no escuro e começa a mesma arqueologia que fez as últimas três vezes, qual deploy, o que mudou, banco de dados ou fila, quem eu acordo em seguida. Vinte minutos depois ele encontra: o pool que começou a saturar por volta das 3h. O fix é uma linha. O custo foi uma hora de sono e um trecho de checkout degradado que os clientes já sentiram.

Gastamos a atenção de toda a indústria naquele momento das 4h02, tornando o pager mais inteligente, o runbook mais apertado, o respondente mais rápido, e quase nada na coisa que de fato deu errado, que aconteceu noventa minutos antes e nunca foi um problema de resposta, antes de mais nada. O pager que dispara às 4h não é um incidente. É o recibo de uma hora que ninguém teve permissão de observar. Essa frase é o post inteiro, e é por que nada no mercado resolveu bem a dor: todo mundo vendeu um recibo melhor.

A hora que não tem dono

Percorra a linha do tempo de um incidente real e a parte cara não está onde todo mundo olha.

O pool começa a subir às 2h55. Ele cruza o limiar de alerta às 3h58. O pager dispara às 4h02, o humano está acordado às 4h05, a causa é encontrada às 4h25, a linha é enviada às 4h30. Toda ferramenta, todo processo, toda rotação de plantão que já construímos vive nesses últimos vinte e cinco minutos, o intervalo entre pager disparou e fix enviado, e o otimizamos implacavelmente, medindo o mean-time-to-resolve até o minuto.

E o tempo todo, o fix barato estava ali das 2h55 em diante, sem dono, porque a hora em que ele vivia não pertencia a ninguém. Não a uma ferramenta, ferramentas esperam o limiar. Não a um humano, humanos, corretamente, dormem. O State of DevOps report de 2021 descobriu que times de elite restauram o serviço em menos de uma hora enquanto os de baixa performance levam uma semana ou mais, e o instinto é ler essa lacuna como uma lacuna de habilidade na resposta. A maior parte não é. É tempo-até-notar, quanto tempo o sintoma ficou numa sala sem observador algum. Você pode ser impecável nos vinte e cinco minutos e ainda ser dono dos incidentes mais lentos da terra se cada um deles começa com uma hora silenciosa.

Então a dor nunca foi “nosso pager é lento demais”. A dor, a que sentimos rodando nossos próprios sistemas, a que nossos clientes sentem, é que uma falha recorrente, previsível e consertável só é descoberta no seu momento mais caro, porque o momento em que era barata não tinha ninguém de pé nele. Você não consegue contratar seu jeito para fora disso. Um humano que observa a hora das 2h55 é um humano que você arruinou.

Por que o fix óbvio torna a coisa errada mais rápida

A resposta do mercado para o plantão é tornar o alerta mais inteligente, e vale ser honesto sobre por que isso é tentador: ajuda, um pouco, que é exatamente a armadilha.

Você conecta um modelo ao seu alerting. O pager dispara, e em vez de seis gráficos crus o engenheiro recebe um parágrafo arrumado, três causas prováveis, o deploy suspeito, um resumo dos dashboards. Parece progresso porque o pior momento da noite ficou mais confortável. Mas olhe o que não mudou: o pager ainda disparou, um humano ainda foi arrancado do sono, e o sistema ainda não fez nada até um limiar quebrar. Você tornou o penhasco um pouso mais suave. Você não moveu ninguém para longe da beirada.

Esse é o mesmo erro de categoria da hora silenciosa, disfarçado. Um alerta mais inteligente ainda é um alerta, ele assume que a hora certa de agir é o momento em que algo já está pegando fogo. Ele aceita a função degrau como uma lei da natureza: nada, nada, nada, então tudo de uma vez. Toda a esperteza derrama em tornar o tudo-de-uma-vez legível, e nenhuma na longa rampa suave anterior, onde o fix de verdade era de graça.

Por isso essa não é uma corrida que estamos tentando vencer. Não queríamos um pager mais rápido ou mais eloquente. Queríamos a hora de volta, e você não consegue a hora de volta melhorando a coisa que só fala depois que a hora já se foi.

O que é preciso para ficar de pé na hora chata

Então o design não é “responder melhor”. É mais estranho e mais quieto: estar presente na hora que não tem dono. E no momento em que você enuncia o trabalho desse jeito, você nota que ele não tem nada a ver com incidentes especificamente, tem a ver com que tipo de coisa está fazendo a observação. Três coisas precisam ser verdade, e nenhuma delas é uma feature de alerting.

Duas linhas do tempo do mesmo incidente: na via do recibo uma métrica sobe sem observação até cruzar um limiar, o pager dispara, e um humano começa uma investigação fria às 4h; na via da hora-com-dono um agent observa o drift no próprio relógio, o correlaciona ao deploy que o causou, e age enquanto a curva ainda é suave, então nenhum pager jamais dispara.

O diagrama são dois desenhos da mesma noite. Eles divergem inteiramente na hora antes do limiar, a única que a segunda via tem um observador e a primeira não. Tudo que segue é a jusante dessa única diferença.

Ele está ligado quando ninguém está

Um tripwire conhece dois estados: bem e disparado. Não tem nenhum conceito de “piorando”, que é o único conceito que te compra tempo. A hora em que o pool subiu de saudável para tensionado não é ignorada por um tripwire, ela é invisível para ele, porque nada existia para estar olhando. Não havia observador algum naquela hora.

Uma coisa que está genuinamente ligada não tem esse ponto cego. Ela lê a mesma telemetria que o dashboard mostra, mas continuamente, inclusive às 3h quando o dashboard está escuro. Na maior parte do tempo ela não vê nada que valha dizer, e não diz nada, e esse silêncio é a feature, não uma lacuna na cobertura. Isso não é uma propriedade que aparafusamos numa ferramenta de incidentes. É o estado baseline de um sistema construído para ser proativo: sempre ligado, ganhando seu sustento precisamente nas horas chatas em que um humano não pode e não deveria.

Um tripwire conhece “bem” e “disparado”. Não tem palavra para “piorando”, e “piorando” é a única palavra que te compra tempo.

Ele já sabe o que mudou

Pegar o drift é metade do trabalho. A outra metade é a pergunta que todo engenheiro de plantão faz às 4h e odeia: o que mudou?

Chegando frio, você a reconstrói sob pressão, abra o deploy log, o histórico de flags, a lista de migrations, cruze cinco linhas do tempo na sua cabeça enquanto o relógio corre. Essa caça é o que come a hora, não o fix. Um sistema que já estava presente nunca perdeu a linha do tempo, porque estava na sala quando a mudança saiu. O deploy às 2h40, o flag virado às 2h50, o pool subindo das 2h55, não cinco logs para reconciliar depois do fato, mas uma sequência observada. Correlacionar um sintoma à sua causa é brutal quando frio e tarde; é quase de graça quando você já estava lá.

Essa memória também não é uma feature de incidentes. É a mesma coisa que deixa o sistema lembrar da data de contrato que ninguém sinalizou ou da thread de cliente que ficou em silêncio, um cérebro da empresa que segura contexto através do tempo, apontado aqui para um pool saturando. A diferença entre um investigador que chega depois do arrombamento e uma câmera que filmou a coisa toda é a diferença entre reconstruir uma linha do tempo e simplesmente tê-la.

Ele tem permissão de fazer a coisa pequena e reversível

Aqui está o estágio que transforma observação em prevenção, e o que os times estão com razão nervosos: a coisa tem que ter permissão de agir enquanto o problema ainda é pequeno.

Não “reiniciar o banco de dados de produção”. Ninguém está pedindo um agent com root e gatilho fácil. A ação que previne o pager é quase sempre a jogada pequena e reversível que um humano faria sem pensar duas vezes se estivesse acordado, reciclar um pool saturando, escalar um worker pool por um antes da fila acumular, fazer rollback do único deploy cujo timestamp bate com o drift. Cada uma é barata, reversível, limitada. Cada uma, tomada na rampa, é o que impede a curva de alcançar o penhasco.

Uma escada de ação protegida: o agent observa o drift continuamente; se um drift correlaciona a uma causa conhecida ele toma uma pequena ação reversível dentro dos seus limites e verifica que a curva achatou; se o sintoma está fora dos seus limites ou a ação não se sustentou, ele escala para um humano com a linha do tempo completa já montada, para que uma pessoa seja acordada apenas pelo genuinamente novo.

A disciplina é a fronteira, e essa é a segunda figura. A ação autônoma vive dentro de um envelope explícito e estreito, uma lista de jogadas que ele pode fazer por conta própria, cada uma reversível, cada uma verificada depois do fato. Se o drift bate com uma causa que ele tem permissão de lidar, ele age, observa a curva achatar, e anota o que fez. Se o sintoma é novo, ou a ação não se sustentou, ou está fora do envelope, ele escala, mas para um humano que recebe a linha do tempo inteira, não um dashboard frio às 4h. Confiança é um perímetro que você desenha, não um botão que você liga; a permissão de agir-pequeno só significa algo porque o perímetro é real.

Então o pager ainda existe. Ele é rebaixado de primeiro respondente para último recurso, disparando apenas pelo genuinamente novo, a falha que nenhum playbook cobre ainda, o único caso onde acordar uma pessoa de fato vale a pena.

A amplitude entrega o jogo

Recue e note o que essas três coisas são. Ligado. Lembra. Permitido de agir dentro de uma fronteira. Nenhuma delas é sobre incidentes. Nenhuma delas é uma feature que construímos para plantão.

Por isso a mesma espinha que fica de pé na hora das 2h55 fica de pé em toda outra hora com uma falha quieta e não-observada nela. O relatório que deveria ter sido rascunhado antes da chamada do board. A renovação que vence porque a data ficou num contrato que ninguém releu. O cliente que ficou em silêncio e nunca recebeu follow-up. Essas falham do mesmo jeito que o pool, lentamente, numa hora sem dono, descobertas tarde no seu momento mais caro. Só não disparam um alarme, que é o que as tornou mais difíceis de resolver, não mais fáceis.

Não chegamos a essa amplitude entregando cinco ferramentas que se parecem com cinco produtos de nicho. Chegamos porque acabou havendo um substrato sob todas essas tarefas, estar ligado, segurar memória, agir dentro de confiança, e uma vez que você o tem, as tarefas caem de graça. A amplitude não é uma checklist da qual nos orgulhamos. É evidência de que a coisa que construímos é o tipo certo de coisa, e incidentes são simplesmente onde sua ausência grita mais alto.

O que sobra para os humanos é a parte que sempre foi deles

Se um sistema fica de pé na hora chata impecavelmente mil noites seguidas, a tentação é perguntar o que sobra para as pessoas. A resposta honesta: a única parte que de fato sempre foi delas.

O sistema pode reciclar o pool. Ele não pode decidir quais ações tem permissão de tomar sozinho, onde a fronteira fica, ou o que conta como novo o suficiente para valer a noite de uma pessoa. Esses são julgamentos, e eles não vêm do npm. Toda noite que o sistema roda limpo, ele ganha um pouco de confiança, mas ele não pode conceder essa confiança a si mesmo, não pode alargar o próprio envelope, não pode decidir que ganhou o banco de dados quando ontem só tinha o pool. Essa decisão fica com as pessoas cujo sono está em jogo, e deveria.

Essa é a inversão. Achávamos que o trabalho do humano no plantão era a heroica salvação das 4h, o engenheiro que pulou no pager e enviou antes dos clientes darem churn, e ganhou os parabéns na retro. Mas a salvação nunca foi a parte valiosa; era o sintoma de um sistema que deixou o problema crescer sem observação. O trabalho humano valioso sempre foi o trabalho lento e deliberado de decidir o que uma máquina tem permissão de fazer às 3h quando ninguém está olhando, e esse trabalho fica mais importante, não menos, quanto mais a máquina consegue fazer.

A noite sem história

O verdadeiro prêmio nunca foi uma linha do tempo de incidente mais esperta. É a noite que não produziu história alguma.

O engenheiro de plantão dormiu a noite toda. O pool foi reciclado às 2h58, a curva achatou, uma linha foi escrita num log que ninguém leu até de manhã, e o checkout nunca degradou o suficiente para um único cliente notar. Não há história de guerra, porque não houve guerra. A coisa mais valiosa que o sistema fez a noite toda não deixou traço, e você não vai encontrar um dashboard em lugar nenhum que saiba como celebrar isso. Toda métrica que temos recompensa a salvação barulhenta e é cega à prevenção silenciosa.

Essa cegueira é a pista. Não estamos construindo um bombeiro mais rápido, e não estamos na corrida para construir um, porque a corrida assume que o fogo é a unidade de trabalho. Achamos que o fogo é um erro de medição, o clarão visível de uma hora que nunca demos a ninguém permissão de ficar de pé. Uma empresa onde essa hora tem um dono não é uma empresa com um pager melhor. É um tipo diferente de empresa, uma que ainda não está no mercado, porque o mercado ainda está vendendo alarmes mais brilhantes. O turno de plantão que ninguém lembra de ter feito não é a melhor versão de plantão. É a primeira noite de uma empresa que parou de rodar com base em alguém estar acordado pela hora em que nenhum humano deveria ter que estar.

A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.

Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.

Entrar na lista de espera