A cena se repete em empresas de todos os tamanhos. O telefone toca, é alguém da operação: o sistema está fora. A equipe de TI abre o painel de monitoramento — e está tudo verde.
Ninguém fez nada errado ali. A ferramenta está instalada, os painéis existem, os alertas estão configurados. E mesmo assim quem descobriu o incidente foi o usuário.
Essa distância entre “ter monitoramento” e “saber antes” é o que eu queria explorar aqui. Porque ela quase nunca se resolve comprando outra ferramenta.
O problema não é falta de dados
Ninguém sofre por falta de métrica. As ferramentas modernas coletam tudo: CPU, memória, disco, latência, fila, throughput, temperatura do rack. Há dados demais.
O problema é que dado não é informação. Um painel com quarenta gráficos não te diz o que está errado — ele te dá quarenta oportunidades de não perceber. E quando tudo é mostrado com o mesmo peso, nada se destaca.
É por isso que tanta gente tem dashboard bonito e ainda assim descobre os incidentes pelo telefone.
A fadiga de alerta
O segundo sintoma é ainda mais comum, e mais perigoso: o alerta que todo mundo aprendeu a ignorar.
Acontece assim. Alguém configura um alerta com limite apertado. Ele dispara várias vezes por dia por coisas que não são problema. A equipe aprende que aquele alerta é ruído. Passa a silenciar, filtrar, ignorar. Até o dia em que ele dispara por um motivo real — e ninguém olha.
Alerta que sempre dispara não protege nada. Ele só treina a equipe a não confiar no sistema. E o pior: cria uma falsa sensação de cobertura, porque no papel o monitoramento “está configurado”.
Um alerta só vale se alguém for agir quando ele tocar. Se ninguém vai agir, ele não deveria existir. É mais seguro ter cinco alertas confiáveis do que cinquenta que ninguém lê.
A pergunta que reorganiza tudo
Monitoramento útil não começa perguntando “o que eu consigo medir?”. Começa perguntando “o que eu não posso deixar de saber?”.
São perguntas bem diferentes. A primeira leva a coletar tudo e exibir tudo. A segunda leva a uma lista curta e priorizada:
- Quais sistemas, se caírem, param o negócio?
- Qual o sintoma que antecede a queda deles?
- Quem precisa saber, em quanto tempo, e o que essa pessoa vai fazer?
Respondendo isso, o monitoramento deixa de ser um mural de gráficos e vira um instrumento de decisão. O resto dos dados continua lá — para investigar depois do incidente, não para disputar tua atenção durante ele.
Da métrica ao negócio
Há ainda um salto que poucas empresas dão: traduzir métrica técnica em impacto de negócio.
“CPU em 95%” é um dado. “O sistema de faturamento está lento e as emissões estão atrasando” é uma informação — e é essa que faz a diretoria entender por que a TI precisa de investimento.
Quem consegue mostrar a saúde do ambiente em termos de serviço, e não de servidor, muda a conversa: deixa de reportar infraestrutura e passa a reportar operação. E essa é a diferença entre uma TI que pede orçamento e uma TI que justifica orçamento.
O teste final
Volte ao teste do começo. Quando algo quebra, você descobre antes ou depois do usuário?
Se for depois, o caminho não é instalar outra ferramenta nem criar mais painéis. É reduzir: escolher o que realmente importa, alertar só sobre isso, e garantir que cada alerta tenha um dono e uma ação.
Monitoramento não se mede pela quantidade de gráficos. Se mede pela quantidade de vezes que você soube antes.
Foi por isso que criamos o Cobalto Manager — com módulo de monitoramento que consolida as fontes que você já tem em cockpits focados no que importa, e envia o status do ambiente por e-mail todo dia, sem ninguém precisar abrir um painel.
Conheça o Cobalto ManagerEste texto faz parte do “Diário de um Gerente de TI”, uma série sobre os problemas reais de governança, custos e infraestrutura que a TI enfrenta na prática.