Todos os ambientes operacionais estão cheios de verificações: health checks, consultas de monitorização, testes após um deployment, controlos após uma alteração na firewall. O seu valor não está em ficarem verdes, mas em ficarem vermelhas quando algo não está certo. É precisamente essa segunda metade que raramente é verificada. Um controlo que nunca disparou pode significar que está tudo em ordem – ou que simplesmente não consegue disparar. Vistos de fora, os dois casos parecem iguais.
Os padrões de que aqui tratamos são muito difundidos e independentes da ferramenta e da dimensão do ambiente. Os exemplos são hipotéticos, mas típicos.
Quatro resultados, não dois
A maioria das verificações conhece dois desfechos: aprovado ou reprovado. Isso não basta. Fazem parte, pelo menos, mais dois resultados:
- Aprovado: a medição ocorreu, e o resultado corresponde ao esperado.
- Reprovado: a medição ocorreu e encontrou um defeito.
- Erro: a medição não ocorreu – a ligação não se estabeleceu, a consulta era inválida, a resposta veio vazia.
- Ignorado: a verificação foi deliberadamente deixada de fora, com uma justificação que permanece visível no resultado.
A diferença decisiva está entre «erro» e «aprovado». «O sistema está com defeito» e «não consegui descobrir» exigem reações diferentes, mas ambos têm de chamar a atenção. O perigo surge quando o caminho de erro e o caminho «nada encontrado» produzem o mesmo valor: aí a verificação dá o sinal de que está tudo bem exatamente no momento em que menos direito tem a isso.
Também «ignorado» nunca pode passar por verde. Uma execução em que cada verificação individual foi deixada de fora não mediu nada – e deveria informar exatamente isso.
Como as verificações mentem sem mentir
Os padrões seguintes não têm nada de espetacular. Precisamente por isso, costumam sobreviver às revisões.
A negação em vez da expectativa. Suponha-se que um health check verifique se um endereço responde «não com o estado 200», porque ali se espera um redirecionamento. Essa condição, porém, também é satisfeita com 403, com 500 – e quando nenhuma ligação chegou a estabelecer-se. Verifique o estado esperado nominalmente e trate a ausência de resposta como um resultado próprio.
O objeto de erro como zero. Suponha-se que uma consulta de monitorização conte ocorrências, por exemplo inícios de sessão falhados. Se a consulta for sintaticamente inválida, o sistema devolve um objeto de erro sem contagem de ocorrências. Um script que lê o campo ausente como 0 informa então «nenhuma anomalia». Um valor ausente não é zero. Certifique-se de que chegou uma resposta válida antes de a avaliar.
A pesquisa de texto que encontra demasiado. Quem procura uma mensagem de erro nos logs também encontra cada ponto em que pessoas falam sobre essa mensagem de erro – em tickets, históricos de chat, comentários. Campos estruturados como origem, tipo de evento ou código de estado são mais fiáveis do que texto livre.
A sonda que se encontra a si própria. Um clássico entre as verificações de processos: uma pesquisa como ps aux | grep dienst devolve frequentemente uma ocorrência – o próprio comando grep (o pgrep, por outro lado, exclui-se a si próprio). O serviço procurado pode estar parado há muito tempo.
A pergunta certa ao destinatário errado
Uma verificação pode ser tecnicamente impecável e, ainda assim, falhar o alvo. Um padrão comum: uma verificação que testa uma aplicação web diretamente no servidor não vê nada dos problemas de DNS, CDN ou certificado com que um visitante se depararia. Estas verificações diretas têm a sua finalidade, mas respondem a outra pergunta. Entre o visitante e o servidor estão a resolução de nomes, eventualmente um load balancer ou CDN, e a cadeia de certificados. Um erro nesse caminho permanece invisível para a verificação no servidor – esta informa verde enquanto o visitante vê uma página de erro.
As duas medições têm a sua razão de ser, apenas não são intercambiáveis. O livro de SRE da Google distingue para isso entre monitorização white-box, que olha para o interior de um sistema, e monitorização black-box, que é orientada para sintomas e representa problemas ativos: «The system isn’t working correctly, right now.» («O sistema não está a funcionar corretamente, agora.») Uma verificação do ponto de vista do visitante – através do nome público, com a cadeia de certificados validada – faz parte, por isso, de qualquer aprovação para produção de uma aplicação acessível publicamente.
«Tudo continua a funcionar» não é uma verificação de firewall
Após uma alteração numa firewall, verifica-se geralmente se os serviços permitidos continuam acessíveis. Isso é necessário, mas comprova apenas que nada se partiu. Se a firewall filtra alguma coisa, esse teste não o mostra – uma firewall sem nenhuma regra ativa passa nele da mesma forma.
Para isso é precisa uma prova negativa: uma tentativa de ligação a partir de uma origem que tem de ser bloqueada, para uma porta que tem de estar fechada. Só quando essa tentativa falha é que a filtragem está comprovada. É importante que a prova venha de fora do sistema verificado; um teste a partir do próprio host pode passar por caminhos que as regras nem sequer abrangem.
Um controlo ausente não se manifesta
A variante mais incómoda diz respeito aos próprios mecanismos de proteção: regras de autorização, regras de alarme, bloqueios automáticos. Um exemplo: uma empresa migra o seu servidor de e-mail para uma nova plataforma. A regra que retém anexos com ficheiros executáveis não é levada. Ninguém se apercebe. Não há indisponibilidade nem aviso, e no log não consta nada de invulgar – uma regra que não existe também não pode registar nada. Para todos os envolvidos, a operação parece um mês tranquilo.
Por isso, não basta configurar um controlo. O seu efeito só está comprovado quando comprovadamente disparou, por exemplo através de um caso de teste direcionado. Essa comprovação deve ser repetida sempre que a configuração mudar de forma fundamental – após uma troca de plataforma, uma atualização maior ou uma migração. E não deve vir apenas do próprio sistema verificado: o que um ambiente relata sobre si próprio só pode conter o que ele próprio conhece. Um olhar independente – um envio de teste a partir de fora, uma segunda ferramenta, outra pessoa – revela o que escapa à autodeclaração.
O BSI prevê no módulo DER.1 do IT-Grundschutz que os sistemas de deteção sejam verificados em auditorias regulares quanto a «se ainda estão atualizados e eficazes». O mesmo documento descreve como ameaça que configurações incorretas podem fazer com que os sistemas de deteção «não funcionem adequadamente». O livro de SRE tira de uma observação relacionada uma consequência dura: a recolha de dados, a agregação e a configuração de alarmes raramente utilizadas – em algumas equipas de SRE, menos de uma vez por trimestre – deveriam ser candidatas à remoção.
Checklist: todas as verificações têm de falhar uma vez
- Prove que a verificação pode falhar. Execute cada nova verificação uma vez contra uma entrada sabidamente defeituosa e veja-a ficar vermelha. Uma verificação que ninguém viu falhar não está comprovada como verificação.
- Dê ao erro um resultado próprio – separado de aprovado e reprovado, com estado ou exit code próprio.
- Verifique o esperado, não a sua negação: estado concreto, valor concreto, título de página concreto.
- Verifique se chegou uma resposta antes de a interpretar. Vazio não é verde.
- Pergunte ao destinatário certo: medir separadamente a origem e a visão do visitante, documentar ambas.
- Torne visíveis as omissões. «Ignorado porque …» faz parte do resultado.
- Corrija a verificação, não o limiar. Se uma verificação informa mal, o que deve ser reparado é o seu tratamento de erros – e não afrouxar a condição de modo que o caso incerto caia do lado verde.
Além disso, um controlo negativo deve ser construído de forma a produzir amanhã ainda o mesmo resultado. Quem testa uma verificação contra um erro existente neste momento na produção tem um controlo que fica verde assim que o erro é corrigido – e, a partir daí, já não prova nada. Dados de teste armazenados, com resultado conhecido, são para isso mais fiáveis do que o estado em tempo real.
Como a sector7 apoia
Apoiamos a construção ou a integração de plataformas de log e SIEM e definimos consigo casos de uso, regras de alarme e playbooks – mais sobre isto em Cibersegurança. Os ambientes que acompanhamos são monitorizados de forma automatizada pelo nosso NOC 24 horas por dia; como funciona a operação contínua, descrevemo-lo em Serviços geridos e suporte.
Fontes
- Site Reliability Engineering, capítulo 6: Monitoring Distributed Systems – Google, consultado em 30 de setembro de 2026
- IT-Grundschutz-Kompendium, Baustein DER.1 Detektion von sicherheitsrelevanten Ereignissen, Edition 2023 (PDF) – BSI, consultado em 30 de setembro de 2026