Empresas que mais investem em redundância continuam registrando incidentes, e Jean Pierre Lessa e Santos Ferreira, diretor de tecnologia com mais de 25 anos em operações de grande porte, comenta que a contradição some quando se olha a origem das falhas. Quase nunca é o equipamento.
Reduzir falhas na infraestrutura tecnológica costuma ser tratado como problema de compra. Mais servidores, mais links, mais licenças de alta disponibilidade. O orçamento aprovado dá sensação de proteção, e o próximo incidente chega pelo mesmo caminho de sempre.
Esse caminho tem nome: mudança. Implantação de versão, alteração de configuração, certificado renovado, regra de rede ajustada às pressas. Enquanto o processo de mudança não for tratado como parte da infraestrutura, comprar mais capacidade apenas duplica o ambiente em que o erro acontece.
A maior parte das falhas começa em uma mudança
Redundância protege contra defeito físico. Ela não protege contra configuração errada, porque a configuração errada é replicada com fidelidade para todas as cópias no mesmo instante. Duas máquinas idênticas recebem o mesmo parâmetro inválido e param juntas, exatamente como foram projetadas para se comportar.
Um certificado que expira ilustra bem o ponto. Não há hardware defeituoso, não há pico de acesso, não há ataque. Existe uma data que ninguém acompanhou e um serviço que passa a recusar conexões em todas as instâncias ao mesmo tempo, inclusive nas de contingência.
Jean Pierre Lessa e Santos Ferreira acompanha a tecnologia de varejo físico e de comércio eletrônico, ambientes em que uma alteração pequena alcança milhares de pontos de venda em minutos. Quanto maior a escala, menor a distância entre um ajuste mal testado e um incidente de alcance nacional.
Como reduzir o risco de cada mudança?
Lote pequeno é a técnica mais barata de confiabilidade. Uma implantação com trinta alterações agrupadas transforma o diagnóstico em investigação; uma com três alterações aponta a causa em minutos. A frequência maior assusta a gestão no começo e reduz o tempo de indisponibilidade no médio prazo.
Implantação gradual completa o desenho. A versão nova recebe uma fatia mínima do tráfego, as métricas dessa fatia são comparadas com as do restante e a promoção só continua enquanto os números se mantiverem. Se piorarem, a reversão acontece por automação, sem depender de alguém acordar.
Por isso, Jean Pierre Lessa e Santos Ferreira sugere tratar configuração com o mesmo rigor de código. Parâmetro versionado, revisado por outra pessoa e aplicado por processo automático deixa rastro, permite comparação entre ambientes e elimina a alteração manual feita direto no servidor durante a madrugada.
O que medir para perceber a falha antes do cliente?
Jean Pierre Lessa e Santos Ferreira pontua que um painel cheio de gráficos verdes não significa serviço saudável. O que indica saúde é um conjunto pequeno de sinais ligados à experiência real: tempo de resposta, taxa de erro, saturação dos recursos e tamanho das filas de processamento.
Alerta demais produz o mesmo efeito de alerta nenhum. Quando o time recebe duzentas notificações por dia, aprende a ignorá-las, e a que importava chega junto com as outras cento e noventa e nove. Alerta útil é o que exige ação humana imediata, e nada além disso.
A diferença aparece no tempo de detecção. Operações que medem sintoma percebem a degradação enquanto ela ainda afeta uma parcela pequena de usuários. Operações que medem apenas infraestrutura descobrem o problema pelo telefone do atendimento, quando o prejuízo já ocorreu.
Falha repetida é falha não estudada
O maior desperdício de um incidente é encerrá-lo sem entender a causa. Reunião de análise sem busca por culpado produz informação melhor, porque as pessoas descrevem o que realmente fizeram, e não a versão que as protege. Sem esse relato honesto, a causa registrada é sempre a mais conveniente.
Cada análise precisa terminar em ação com dono e prazo, revisada depois. Ação genérica do tipo melhorar o monitoramento não muda nada. Ação específica, como incluir a data de expiração dos certificados no alerta semanal, impede que aquela falha exata volte.
Confiabilidade não é estado alcançado, e sim propriedade mantida a cada mudança. Jean Pierre Lessa e Santos Ferreira reflete sobre esse ponto ao tratar de operações que rodam todos os dias, em que a próxima falha já está sendo escrita em alguma alteração aprovada esta semana.