1. Comece por um monitor de uptime já existente e abra as definições de alerta
Se já tiver uma verificação a correr, está a meio caminho. Agora, a tarefa não é criar uma configuração completa de monitorização de uptime do site do zero; é transformar essa verificação em algo que avisa a pessoa certa na hora certa.
Abra o monitor que quer acompanhar de perto e procure as definições de alerta, regras de notificação ou opções de incidente. O nome exato pode variar, mas o objetivo é o mesmo: ligar um monitor ativo a uma ação quando surgir indisponibilidade.
É aqui que como configurar alertas de uptime da Astrina passo a passo começa a fazer sentido na prática. Não está a redesenhar o monitor. Está a decidir o que deve acontecer depois de o monitor falhar duas vezes, ou cinco, ou no ponto que a sua equipa considerar necessário para receber aviso.
Comece apenas com um serviço. Se a página inicial, a página de login e a página de checkout falharem todas ao mesmo tempo, um monitor é suficiente para começar. Assim, o primeiro alerta mantém-se simples — e alertas simples são lidos.
Confirme o nome atual do monitor, o URL de destino e a frequência de execução antes de mexer nos alertas. Um nome como “Login Prod” é melhor do que “Verificação 1”, porque a sua caixa de alertas fica menos confusa às 2:14 da manhã.
2. Escolha as condições de indisponibilidade que devem disparar um alerta
O centro da configuração é o gatilho. Precisa de limiares de alerta para indisponibilidade que façam sentido para o serviço, e não de uma regra genérica copiada de outro lado.
Um gatilho comum são falhas consecutivas. Duas verificações falhadas podem ser suficientes para uma pequena ferramenta interna, enquanto uma página de pagamento voltada para clientes pode precisar de três ou mais falhas antes de alertar. O número importa, porque uma falha pontual não deve acordar um engenheiro de plantão, a menos que o serviço já esteja frágil.
Picos no tempo de resposta também podem ser relevantes. Um site pode continuar a devolver 200 OK e, ainda assim, estar praticamente avariado se a página demorar demasiado a carregar, especialmente durante o checkout. Lento não é o mesmo que em baixo, mas os utilizadores muitas vezes sentem as duas coisas como falha.
Padrões de códigos de estado também merecem atenção. Uma resposta da série 500 costuma justificar atenção mais rápida do que uma 404, enquanto uma 401 num painel privado pode significar apenas que a página está protegida. O truque é alinhar o padrão de código com o comportamento esperado do serviço.
Escolha o gatilho mais específico que corresponda ao serviço. Se o monitor for para uma página inicial sem login, uma 403 geralmente deve ser investigada. Se for para um ambiente de staging, o mesmo código pode ser apenas ruído. Uma regra não serve para todos os endpoints.
Não torne o limiar demasiado permissivo. Um monitor que alerta na primeira verificação falhada pode tornar-se inútil em uma semana. Também não o torne demasiado rígido. Se uma indisponibilidade real puder durar 10 minutos antes de alguém ser avisado, o limiar está demasiado lento para tráfego voltado para clientes.
3. Defina os canais de notificação e encaminhe os alertas para as pessoas certas
Escolha para onde o alerta deve ir. E-mail serve para urgência baixa, mas chat, SMS ou outro destino de notificação costuma ser melhor para resposta ativa a incidentes. O objetivo é garantir que alguém veja o alerta enquanto a indisponibilidade ainda está a acontecer.
Encaminhe cada alerta para a equipa que pode agir. Um erro de base de dados não deve cair apenas no chat de marketing. Uma falha no checkout não deve ficar à espera numa caixa geral onde três pessoas assumem que outra é a responsável.
Mantenha a cobertura fora do horário explícita. Se a equipa diurna recebe o primeiro alerta e a equipa noturna recebe o segundo, escreva isso nas notas do monitor. Caso contrário, o alerta pode chegar a um beco sem saída depois do expediente.
Um monitor pode enviar para mais de um destino, mas isso não significa que deva fazê-lo. Dois canais chegam para muitas equipas: um respondente principal e um de reserva. Demasiados destinos podem gerar o tipo errado de ruído.
Pense na pessoa que recebe a mensagem às 1:00 da manhã. Ela precisa do nome do serviço, do URL que falhou e do último estado conhecido. “Algo está em baixo” não é um alerta; é um enigma.
4. Separe alertas de produção do ruído de manutenção e testes
Os alertas de produção precisam do seu próprio espaço. Manutenções planeadas, verificações de staging e janelas de deploy podem gerar falsos positivos se forem misturados no mesmo fluxo de alertas. É aí que uma configuração organizada poupa tempo.
Se um deploy estiver agendado para 15 minutos, silencie o monitor relacionado durante essa janela. Se o staging for verificado a cada 5 minutos, mantenha-o num grupo separado para que não possa notificar a equipa de produção. O objetivo não é esconder problemas; é impedir que ruído de teste pareça dano real.
Isto é diferente de uma configuração básica de monitorização de uptime de um site, em que a primeira preocupação é apenas saber se uma página está acessível. O alerta é mais seletivo. Faz uma segunda pergunta: um ser humano deve ser interrompido agora?
Use nomes que tornem a separação óbvia. “API Prod”, “API Staging” e “Teste de Manutenção” são melhores do que três etiquetas quase iguais. Às 3 da manhã, um nome claro poupa mais tempo do que qualquer esquema criativo.
As janelas de manutenção devem ter limite temporal. Se silenciar uma verificação por 2 horas e se esquecer de a reativar, o sistema de alertas fica cego. É um mau negócio, mesmo que o deploy original tenha corrido bem.
Uma nota à margem: falsos positivos parecem inofensivos até acontecerem três vezes numa semana. Depois, toda a gente começa a ignorar o quarto alerta. Esse é o verdadeiro custo.
5. Ajuste o tempo de escalonamento para que os alertas de indisponibilidade se tornem acionáveis
O escalonamento é o ponto em que um monitor se torna um processo de incidente. Pode atrasar o primeiro alerta, repeti-lo após um intervalo definido ou passá-lo para outro respondente se a indisponibilidade continuar.
Comece por decidir quem deve receber a primeira notificação. Essa pessoa deve conseguir agir sem andar à procura de contexto. Se o primeiro respondente não puder alterar o serviço, o alerta está a apontar para a pessoa errada.
Depois decida o que acontece após o primeiro alerta. Uma repetição ao fim de 10 minutos pode fazer sentido para uma indisponibilidade teimosa, enquanto um segundo encaminhamento para um engenheiro de reserva pode adequar-se a uma equipa pequena que partilha plantões. O tempo deve refletir a rapidez com que a sua equipa costuma responder, não a rapidez com que gostaria que respondesse.
Escalonamento não é o mesmo que spam. Duas notificações podem ser úteis se a segunda chegar a uma pessoa diferente, com um nível diferente de autoridade. Seis cópias para a mesma caixa de entrada só treinam as pessoas a parar de ler.
Seja específico quanto à consequência da indisponibilidade contínua. Se o primeiro alerta for ignorado, o seguinte vai para um gestor, um telefone de serviço ou um canal partilhado de incidentes? Escreva a sequência nas notas do monitor para que ninguém tenha de adivinhar sob pressão.
Uma regra ajuda aqui: se o serviço for voltado para clientes, o escalonamento deve ser mais curto. Se for um relatório interno que pode esperar, o tempo pode ser mais longo. Mesma plataforma, urgência diferente.
6. Verifique um alerta do início ao fim com um teste controlado de indisponibilidade
Antes de confiar no alerta em produção, teste-o uma vez do início ao fim. Precisa de confirmar três coisas: o monitor falha quando esperado, o limiar é acionado quando esperado e a notificação chega à pessoa certa.
Use um teste controlado, não uma indisponibilidade real. Uma alteração temporária no URL, um endpoint de teste ou uma janela de manutenção pode ser suficiente para acionar o monitor com segurança. O objetivo é ver toda a cadeia funcionar sem estragar algo importante só para provar um ponto.
Este é o passo que muitas equipas saltam. Depois, o primeiro incidente real torna-se o primeiro teste real, e essa é uma forma miserável de descobrir erros de encaminhamento.
Observe a linha temporal com atenção. Se a verificação falhar às 10:00, o alerta não deve aparecer às 10:17, a menos que o limiar tenha sido definido de propósito assim. Se chegar ao chat errado, corrija isso antes do próximo incidente, e não depois.
Registe o que aconteceu durante o teste. Uma nota simples com o nome do monitor, o gatilho usado, o destinatário e qualquer atraso ajudará mais tarde, quando alguém perguntar por que motivo um alerta disparou duas vezes. O número 2 importa mais do que uma memória vaga.
Se ainda estiver a construir o próprio monitor, pode querer definir primeiro o agente. O caminho de configuração com * pode ajudar quando a verificação precisa de uma instalação nova, e depois as definições de alerta podem ser adicionadas por cima sem adivinhar.
7. Reveja o histórico de alertas e refine os limiares após incidentes reais
Os primeiros alertas ensinam mais do que uma semana de planeamento. Reveja-os após incidentes reais e procure padrões: falsos positivos repetidos, alertas que chegaram tarde demais ou alertas que foram para a equipa errada.
Se uma falha de rede de 2 minutos disparou um alerta, aumente o limiar. Se uma indisponibilidade de 12 minutos gerou apenas uma notificação e nenhuma escalada, reduza o atraso ou adicione um encaminhamento de seguimento. Cada incidente real dá-lhe um ponto de dados, e um ponto de dados já pode justificar uma pequena mudança.
O ruído é o inimigo aqui. Demasiados alertas de baixo valor fazem com que as pessoas demorem a responder, e isso pode transformar uma falha curta numa mais longa. Poucos alertas fazem o mesmo no sentido oposto. O equilíbrio certo não fica fixo para sempre.
Observe os códigos de estado, a hora do dia e o serviço afetado. Uma página de login que falha duas vezes durante dias úteis pode merecer um limiar mais apertado do que a mesma página durante um fim de semana de pouco tráfego. O contexto importa porque o custo da interrupção não é o mesmo a todas as horas.
Mantenha o ciclo de revisão curto no início. Após os primeiros 3 a 5 alertas, ajuste as notas do monitor, a lista de destinatários e o tempo de escalonamento, se necessário. Essa pequena revisão pode impedir que um alerta ruidoso passe a fazer parte do dia a dia.
Se também acompanhar percursos relacionados do utilizador, como o checkout, pode ser útil comparar o que o alerta diz com o que os utilizadores realmente viram. Um alerta ao nível da página e uma visão ao nível da sessão muitas vezes contam partes diferentes da mesma história, e a reprodução de sessão da Astrina para verificar o checkout pode facilitar a identificação dessa diferença.
Um último ponto prático: escreva as alterações de volta no próprio monitor, e não apenas num tópico de chat. Um comentário no Slack desaparece no meio da rolagem. O monitor permanece.
