Disponibilidade do SQL Server: como medir de verdade

"Disponibilidade" costuma ser tratada como binário — o servidor respondeu ou não respondeu — mas isso esconde três problemas: um ping que passa não confirma que o SQL Server aceita conexão real; um gap de monitoramento (agente parado, rede instável) não é a mesma coisa que o banco estar fora; e se a ferramenta de monitoramento em si cai, isso não pode contar como o SEU banco tendo ficado indisponível.

As duas métricas que importam

Disponibilidade (%) mede o percentual de tempo com o SQL Server comprovadamente disponível, sobre o tempo observado. Cobertura de Monitoramento (%) mede o percentual do tempo total em que foi possível observar o ambiente. São métricas diferentes de propósito: se a ferramenta de monitoramento ficar fora do ar, a cobertura cai — mas a disponibilidade do banco não é penalizada por isso. Misturar as duas é o erro mais comum em cálculo de SLA feito na mão.

Sonda de verdade, não estimativa

Medir disponibilidade de verdade exige uma sonda ativa e frequente — um SELECT 1 numa conexão dedicada, não reaproveitada de pool (uma conexão de pool pode "passar" mesmo com o caminho de rede já degradado, mascarando a falha). E a medição precisa continuar acontecendo mesmo durante o envio dos dados coletados — se parar durante o envio, o monitoramento fica cego justamente quando a rede está ruim, que é exatamente quando mais importa.

Diferenciar banco fora de rede instável

Quando a sonda falha, a causa importa: sondas que falharam por timeout mas sem indício de reinício do serviço apontam pra rede instável, não pro SQL Server ter caído. Sondas que falharam E o horário de início do serviço avançou (instance_start_time mudou) confirmam reinicialização real. Conexão recusada sem reinício detectado indica serviço parado ou host inacessível. E credencial incorreta não é indisponibilidade — é configuração, e tratar como downtime infla o número artificialmente.

Gap não é 100%

• Período sem dado (agente parado, atualização de servidor, rede fora) precisa aparecer como lacuna, nunca como se o banco estivesse disponível — ausência de evidência não é evidência de disponibilidade.
• Janela de manutenção planejada deveria ser excluída do cálculo, não contar contra o SLA nem a favor — é tempo intencionalmente fora.
• Se a ferramenta de monitoramento ficou fora, esse período deveria reduzir a cobertura, não penalizar (nem inflar) a disponibilidade do banco.

Arredondar pra cima esconde downtime real

99,976% arredondado pra uma casa decimal vira 100,0% — e isso é literalmente falso: houve downtime real naquele período, só que pequeno demais pra sobreviver ao arredondamento. Truncar em vez de arredondar (99,9%, não 100%) é a diferença entre um número que soa bem e um número que é verdade.

É exatamente essa metodologia — sonda dedicada a cada 15 segundos, classificação de causa, exclusão de gaps do denominador, truncamento em vez de arredondamento — que o codeDB usa pra calcular a disponibilidade dos seus ambientes.