Vou monitorar disponibilidade dos sistemas
Resposta rápida
Monitorar disponibilidade de sistemas é menos sobre comprar ferramenta cara e mais sobre disciplina de configuração. Comece definindo o inventário do que é crítico (não tudo é): sistemas cuja indisponibilidade para o faturamento, a operação ou o cliente direto. Para cada um, configure três níveis de monitoramento: disponibilidade básica (está respondendo?), saúde (está saudável — latência, erros, capacidade?) e ponta a ponta (a jornada principal do usuário funciona?). Defina alerta com limiar realista (alerta toda hora vira ruído, e ruído gera silêncio quando importa) e escalonamento claro: quem é avisado primeiro, em quanto tempo escala, como se aciona o plantão. Sem monitoramento bem configurado, você descobre que o sistema caiu pelo telefone do CEO — e aí já é tarde.
Na empresa pequena, monitoramento sofisticado não cabe — e raramente é necessário. Três a cinco sistemas críticos (ERP, e-mail, internet, site institucional se for transacional) podem ser monitorados por ferramenta gratuita ou de baixo custo: UptimeRobot, Pingdom plano básico, ou o próprio painel do MSP. Alerta por e-mail ou WhatsApp para o ponto focal interno e backup no MSP resolve. O risco é não monitorar nada — confiar que se algo cair, alguém vai avisar. Esse "alguém" é o usuário irritado, e a TI sempre fica sabendo por último. Configurar três checks básicos (ping no firewall, HTTP no ERP, HTTP no site) e mandar para um chat ou e-mail resolve o problema sem custar significativo. Sofisticação aqui é desperdício; mínimo viável já protege bastante.
Na empresa média, o inventário cresce para dez a vinte sistemas críticos e o monitoramento começa a exigir ferramenta dedicada (Zabbix, Datadog plano inicial, New Relic, Grafana com Prometheus, ou similares). A operação ganha plantão informal ou formal — alguém de TI fica de sobreaviso fora do horário comercial. O risco característico desse porte é o alerta ruidoso: ferramenta dispara dezenas de alertas por dia, time aprende a ignorar, e quando o alerta importante toca ninguém olha. Disciplina de tunar alerta (limiar realista, agregação de alertas correlacionados, supressão durante manutenção) é tão importante quanto o monitoramento em si. Escalonamento formal aparece aqui — quem é avisado, em quanto tempo escala, plano B se a pessoa não responder.
Na empresa grande, monitoramento é stack completo: APM (Application Performance Monitoring), infraestrutura, logs centralizados, traces distribuídos, sintético, RUM (Real User Monitoring) e dashboards executivos. O time de NOC ou SRE roda 24/7 com plantão formal e runbooks por tipo de alerta. O risco aqui é diferente: cada equipe configura seu monitoramento sem padrão, alertas duplicam, métricas calculam diferente, e a leitura agregada perde sentido. Governança ganha peso — catálogo único de sistemas, padrão de nomenclatura, definição compartilhada de severidade e ownership claro de cada alerta. Cultura de SRE com error budget e SLO formal funciona melhor nesse porte: a empresa decide explicitamente quanta indisponibilidade aceita por sistema e ajusta investimento por aí.
- Você fica sabendo que o sistema caiu pelo usuário, não pelo alerta
- O canal de alertas tem tanto ruído que ninguém olha mais
- Não há clareza de quem é avisado quando um sistema crítico cai
- Você não sabe a disponibilidade real do mês passado
- Sistemas degradam por dias antes da queda e ninguém percebeu
- Cada sistema é monitorado de um jeito diferente, sem padrão
Comece pelo inventário do crítico
O erro mais comum em monitoramento é tentar monitorar tudo. Resultado: alertas demais, manutenção do monitoramento vira tarefa em si, e o crítico se mistura ao supérfluo. Comece definindo o que é crítico — sistemas cuja indisponibilidade para o faturamento, a operação ou o atendimento ao cliente. Tipicamente três a vinte sistemas dependendo do porte. O resto pode ter monitoramento mais leve ou nenhum.
Para cada sistema crítico, três perguntas: qual o impacto da queda (faturamento parado, atendimento parado, time interno parado, conformidade afetada), qual o SLO desejado (uptime alvo no mês), e quem precisa ser avisado quando degradar ou cair. As respostas alimentam a configuração do monitoramento.
Três níveis de monitoramento
Disponibilidade básica: está respondendo? Check simples de ping, HTTP ou TCP. Detecta queda dura. Baixo custo para configurar, alta cobertura.
Saúde: está saudável? Latência, taxa de erro, uso de CPU/memória/disco, fila de mensagens, espaço em log. Detecta degradação antes da queda. Exige instrumentação mínima.
Ponta a ponta: a jornada do usuário funciona? Monitoramento sintético que executa o fluxo crítico (login, busca, compra, geração de relatório) em intervalo fixo. Detecta o que ping não vê — sistema responde, mas a função não funciona.
- Liste os sistemas críticos. Curte, com impacto descrito. Validação rápida: se cair por uma hora em horário comercial, alguém vai abrir chamado de altíssima prioridade? Se sim, é crítico.
- Defina SLO por sistema. Uptime alvo realista — 99,5% mensal, 99,9% mensal, conforme a criticidade. Não copie SLO da Amazon; defina o que faz sentido para o negócio.
- Configure o nível básico em todos. Disponibilidade primeiro, em todos os críticos. Depois evolua para saúde e ponta a ponta nos que mais importam.
- Tune o alerta. Limiar realista, janela de avaliação (não alertar em pico isolado de 30 segundos), agregação de alertas correlacionados. Ruído mata a confiança no alerta.
- Escreva o escalonamento. Quem é avisado primeiro, em quanto tempo escala para segundo nível, quem é o ponto final se ninguém responder. Sem isso, alerta cai em caixa vazia.
- Teste o pipeline. Simule uma queda. Chega o alerta? Para quem? Em quanto tempo? Se falhar no teste, vai falhar de verdade.
Como configurar alerta que não vira ruído
Cada alerta deve passar em três testes antes de ir para produção. Primeiro: é acionável? Existe algo concreto que a pessoa de plantão pode fazer ao receber? Se a resposta for "monitorar e ver se piora", o alerta não é alerta, é nota. Segundo: o limiar é realista? Disparar acima de 70% de CPU em servidor que normalmente fica em 80% é convite para silenciar. Terceiro: tem janela de avaliação? Pico de cinco segundos não merece alerta; sustentação por dois minutos, sim.
Agregação ajuda muito. Quando uma falha de rede gera cinquenta alertas correlacionados, a ferramenta deveria mandar um alerta agrupado, não inundar o canal. Supressão durante janela de manutenção é outra disciplina — alerta previsto durante mudança planejada vira ruído puro.
Lendo tendência além do alerta
Monitoramento útil não é só alerta de coisa caída — é leitura de tendência para antecipar problema. Disco crescendo 1% por semana cruza o limiar em três meses; melhor agir antes. Latência aumentando 5% por mês indica sistema entrando em sobrecarga gradual. Erros raros aumentando indica bug latente. Revisão mensal de tendência das métricas críticas captura o que o alerta isolado não vê.
O painel de tendência fica em ferramenta separada do alerta — dashboard de série temporal, não notificação. A leitura faz parte do ritual mensal de indicadores, junto com a revisão de capacidade e a discussão de incidentes do mês.
Alerta para tudo. Configurar alerta em cada métrica disponível inunda o canal. Em poucas semanas o time silencia. Limite alertas ao acionável; o resto fica como dashboard de tendência.
Sem escalonamento escrito. Alerta toca, primeira pessoa não viu, ninguém é avisado depois — o sistema fica caído até alguém abrir chamado. Escalonamento por tempo e por hierarquia é tão importante quanto o alerta.
Monitoramento sem ponta a ponta. Todos os sintomas verdes, mas o usuário não consegue logar. O check ponta a ponta — executar a jornada crítica do usuário — pega o que ping e CPU não veem.
Ferramenta diferente por sistema. Sem padrão de catálogo, cada equipe configura à sua maneira. Quando a operação cresce, a visão agregada vira ficção e cada alerta vira ilha.
- Todos os sistemas críticos têm pelo menos disponibilidade básica
- Os mais críticos têm também saúde e ponta a ponta configurados
- Cada alerta é acionável e tem janela de avaliação realista
- Escalonamento escrito com primeiro, segundo nível e ponto final
- Pipeline de alerta foi testado com simulação de queda
- SLO definido por sistema e medido mensalmente
- Tendência das métricas críticas é revisada uma vez por mês