Como posso evitar falhas no sistema antes que cheguem ao usuário

Evitar falhas no sistema é disciplina de entrega, não heroísmo de plantão. O orçamento de erro define quanto risco a equipe pode gastar no período, cada liberação segue observada em tempo real contra a linha de base, a entrega gradual limita o raio do defeito e a reversão em minutos interrompe a propagação antes que ela alcance o usuário.

Boa parte das indisponibilidades em ambiente distribuído entra pela porta da própria entrega: configuração nova, versão nova, dependência nova. Um processo que mede o próprio efeito devolve à equipe de operações a chance de interromper a falha antes que ela alcance quem usa o serviço.

Prevenir significa organizar o modo como a mudança entra em produção. A organização abrange quanto risco a equipe pode gastar no período, como cada liberação é acompanhada, em quanto tempo uma versão ruim volta atrás e quando a capacidade do ambiente vai encontrar o teto.

A Rike IS conduz consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte.

Orçamento de erro: quanto risco a entrega pode gastar

Orçamento de erro é a margem de indisponibilidade que uma equipe pode consumir em um período sem romper o compromisso assumido. Ele nasce do Service Level Objective, ou SLO, o objetivo interno de disponibilidade do serviço, e quanto mais rígido o objetivo, menor a fatia do período em que o serviço pode degradar.

Prevenção sem orçamento de erro declarado vira preferência pessoal de quem está de plantão naquele dia.

Enquanto sobra orçamento, a entrega de funcionalidade segue no ritmo normal. Quando o orçamento acaba, a prioridade passa para estabilização, sem nova rodada de negociação a cada liberação. O mecanismo troca a discussão recorrente entre velocidade e risco por um valor que as duas partes aceitaram antes do incidente, e valor acordado antes permite decidir sem disputa no momento em que a pressão está alta.

O orçamento só governa a entrega se o indicador medido corresponder ao que o usuário obtém. O Service Level Indicator, ou SLI, é esse dado. Medir disponibilidade pela resposta do servidor produz número diferente de medir pela conclusão da transação de negócio, e apenas o segundo corresponde ao serviço efetivamente prestado.

O SLO não se confunde com o Service Level Agreement, ou SLA, o compromisso externo firmado em contrato. O objetivo interno costuma ser mais rígido que o acordo, e essa folga deliberada é o espaço de manobra da equipe. Quem trata os dois como sinônimo trabalha sem margem, e descobre o rompimento do contrato no mesmo instante em que descobre o problema técnico.

Para o CIO, o orçamento de erro é previsibilidade: existe um número que traduz risco operacional em decisão de portfólio. Para o Site Reliability Engineer, ou SRE, é o critério que autoriza recusar uma liberação sem transformar a recusa em disputa política.

Deploy observado em tempo real

Deploy observado é a prática de acompanhar cada liberação com métrica de impacto durante a liberação, não no relatório do dia seguinte. A pergunta que o acompanhamento responde é objetiva: o que mudou no comportamento do serviço depois que esta versão entrou?

O modelo antigo compara antes e depois por inspeção manual de painel, quando alguém lembra de olhar. O modelo que previne falha compara a versão nova com a linha de base do próprio serviço em quatro dimensões: taxa de erro, tempo de resposta, consumo de recurso e volume de transação concluída.

Na plataforma Dynatrace, o OneAgent descobre a stack em execução sem configuração manual por componente e alimenta o Smartscape, o mapa de dependências do ambiente em tempo real. Sobre esse mapa opera o Davis, que dentro do Dynatrace Intelligence é responsável pela análise causal, sustenta a comparação entre a versão nova e a linha de base e aponta o evento gerador de uma cadeia de sintomas, em vez de entregar dezenas de alertas que descrevem o mesmo incidente por ângulos diferentes.

Davis pertence à disciplina de Artificial Intelligence for IT Operations, ou AIOps, que aplica inteligência artificial à operação de tecnologia. A IA causal atua na identificação da causa e do contexto do problema, enquanto os dashboards organizam e tornam exploráveis os sinais operacionais.

Observar o deploy exige telemetria no lugar antes da liberação, e não depois do incidente. Instrumentação equivale às câmeras instaladas na fábrica, e o setor sem câmera é o setor sobre o qual nada pode ser explicado depois.

Para o profissional de DevOps, o deploy observado encurta o ciclo de retorno entre publicar e saber. Para o gerente de infraestrutura, evita descobrir o custo de uma versão ruim apenas no relatório de consumo do mês seguinte.

Entrega gradual e reversão rápida

Entrega gradual significa expor a versão nova a uma fatia pequena de tráfego antes de expor a totalidade. Canary release é o nome dessa prática: uma parcela do tráfego real vai para a versão nova, a equipe compara os indicadores das duas versões lado a lado, e a fatia só cresce se o comportamento se manteve.

Três decisões precisam estar escritas antes do primeiro canary. Qual o tamanho da fatia inicial e o critério de ampliação. Quais indicadores autorizam promover a versão. E qual o limite que dispara reversão automática, sem depender de decisão humana.

Reversão é o outro lado da mesma prática. Reverter rápido significa que voltar à versão anterior leva minutos e não exige reunião de aprovação. Quando reverter é caro, a equipe hesita, e a hesitação transforma um defeito restrito a uma fatia em indisponibilidade ampla.

Reverter cedo custa menos do que diagnosticar sob pressão.

Existe um limite a registrar sobre canary. Mudança que altera esquema de banco de dados nem sempre volta atrás pela simples troca da versão da aplicação. Nesse caso a proteção vem de compatibilidade entre versões, com migração em duas etapas: primeiro o esquema aceita os dois formatos, depois o formato antigo sai.

Para o SRE, entrega gradual reduz o raio de alcance de qualquer defeito que passou pelos testes. Para o CTO, é o mecanismo que mantém cadência de entrega sem elevar a exposição do negócio.

Validação automatizada depois da liberação

Validação automatizada é o conjunto de verificações que roda sozinho após cada liberação, sem depender de alguém lembrar de conferir. Ela se conecta à esteira de integração e entrega contínua, ou CI/CD, como etapa de bloqueio: se a verificação reprova, a promoção para o próximo ambiente não acontece.

Quatro verificações costumam bastar nas primeiras semanas. A transação sintética confere a disponibilidade dos caminhos críticos de negócio. O Application Performance Monitoring, ou APM, entrega a taxa de erro por serviço e a compara com a linha de base. O tempo de resposta entra pelo percentil alto, não pela média. E o consumo de recurso por instância revela vazamento visível apenas sob uso prolongado.

Percentil alto merece explicação. A média esconde o pior atendimento, e é o pior atendimento que gera chamado, abandono de operação e retrabalho para a equipe de operações.

Transação sintética é a execução programada de um percurso de uso, disparada em intervalo fixo a partir de pontos externos ao ambiente. Ela pertence ao campo de Digital Experience Monitoring, ou DEM, e acusa indisponibilidade em horário de baixo tráfego, quando o volume real seria pequeno demais para mover qualquer indicador agregado.

Há um detalhe de implantação que costuma passar despercebido. A verificação automatizada precisa de critério de reprovação calibrado sobre dado histórico, e não sobre valor escolhido em reunião. Limite apertado demais bloqueia liberação boa e a equipe aprende a desligar a etapa. Limite frouxo demais deixa passar a versão que degrada aos poucos.

Para o DevOps, a validação automatizada devolve confiança para liberar em dia útil, no meio do expediente. Para o CIO, reduz a dependência de conhecimento concentrado em poucas pessoas da equipe.

Previsão de capacidade e teste de carga

Previsão de capacidade é a projeção de quando o consumo de um recurso vai encontrar o limite disponível, calculada sobre a tendência real medida em vez de estimativa de planilha. A resposta que interessa tem data: em quantas semanas a memória, o número de conexões de banco ou a profundidade da fila chegam ao teto.

Teste de carga é o complemento que antecipa o pico. Submeter o ambiente a volume superior ao esperado revela qual componente cede primeiro e o que ele arrasta consigo. Picos em sistemas críticos costumam ser concentrados: prazo de tributo, período de matrícula, campanha promocional, fechamento contábil.

O resultado útil do teste não é o número máximo suportado, e sim a sequência de saturação. Saber qual recurso satura antes permite corrigir o gargalo certo, em vez de contratar capacidade onde ela não faltava. Essa informação nenhum indicador de operação normal fornece, porque em operação normal o sistema nunca chega perto do limite.

Em ambiente com autoescala, o tempo de reação entra na conta. Um mecanismo que adiciona instância em minutos não protege contra pico que se forma em segundos, e essa defasagem só aparece sob carga controlada.

Capacidade mal prevista também aparece do outro lado, como recurso ocioso pago mês a mês.

Para o gerente de infraestrutura, previsão de capacidade é controle de custo: dimensionar pelo que a tendência mostra evita tanto a indisponibilidade quanto a compra preventiva excessiva. Para o CEO, é a diferença entre planejar investimento com antecedência e reagir a emergência com o preço da urgência.

Equipes que lideram entrega em ambiente crítico costumam chegar a esse ponto com as peças espalhadas: alguma automação de um lado, painel conferido à mão de outro, verificação que ninguém mantém. A Rike IS desenha o encadeamento entre observabilidade e entrega junto dessas equipes, sem exigir que tudo seja trocado de uma vez.

Governança de atributos como prevenção

Governança de atributos é a padronização de nomes, rótulos e metadados aplicados à telemetria de cada serviço. Sem essa padronização, o mesmo serviço aparece com identificações diferentes em contextos diferentes, os painéis fragmentam e a análise de causa raiz perde precisão.

A conexão com prevenção é direta. O dado que apontaria a versão responsável por uma degradação precisa carregar a versão registrada como atributo. Quando cada equipe instrumentou com convenção própria, o dado existe e não é legível no momento em que seria útil, que é o momento do incidente.

A convenção quebra por deriva, não por decisão. Serviço novo copia o arquivo de configuração do vizinho, alguém corrige um nome de atributo sem propagar a correção, e o rótulo de ambiente aparece escrito de duas formas na mesma consulta. Convenção que não é recusada na esteira de entrega envelhece em silêncio, e a fatura chega em forma de consulta que devolve resultado parcial durante o incidente.

OpenTelemetry, ou OTel, é o padrão aberto e vendor-neutral da CNCF para gerar telemetria, e funciona como o padrão USB-C da telemetria. Ele define API, SDK e convenções de nomes para que qualquer origem de telemetria converse com qualquer destino. As semantic conventions do projeto trazem a lista de atributos esperados por tipo de recurso, e adotá-las encerra a discussão interna sobre nomenclatura antes que ela comece.

O OpenTelemetry Protocol, ou OTLP, é o envelope dos correios dessa carga e transporta a telemetria até o destino. Ele opera sobre gRPC na porta 4317, mais eficiente em volume por usar formato binário, ou sobre HTTP com protobuf na porta 4318, mais simples de atravessar firewall e mais fácil de depurar. A plataforma Dynatrace aceita as duas.

A origem do dado se decide entre três caminhos. OneAgent, o agente unificado que faz descoberta automática da stack e instrumenta sem alteração de código. Instrumentação direta por OpenTelemetry, quando a equipe quer controle fino sobre o que é emitido. E o modelo híbrido, que combina os dois conforme o tipo de carga de trabalho.

O Grail retém esse volume de logs, métricas, traces e eventos por períodos que variam conforme o tipo de dado e a configuração adotada, com consulta rápida sobre todo o histórico, e o Dynatrace Query Language, ou DQL, é a linguagem que interroga o dado retido. Consulta precisa depende de atributo previsível, e é aí que a governança deixa de ser burocracia e vira instrumento de prevenção.

Para o SRE, atributo padronizado encurta o Mean Time To Repair, ou MTTR, o tempo médio de resolução, porque a consulta devolve o recorte certo na primeira tentativa. Para o gerente de infraestrutura, o mesmo atributo permite atribuir custo de telemetria por equipe, o que torna a conversa sobre volume de dado objetiva.

Como sustentar a disciplina quando o ambiente muda

Ambiente muda e o desenho de prevenção envelhece sem aviso. Serviço novo entra, dependência é trocada, volume cresce, equipe se renova. Um conjunto de práticas adequado no primeiro trimestre pode estar defasado no terceiro sem que nada tenha falhado ainda, e a ausência de incidente costuma ser lida como prova de que está tudo certo.

Governança de performance é a revisão periódica desses parâmetros. Três perguntas orientam cada rodada. O SLO continua adequado ao que o negócio precisa hoje? O SLI continua medindo o que o usuário obtém? As verificações automatizadas continuam cobrindo os caminhos críticos que existem agora?

Existe um exercício que separa desenho documentado de desenho operante: provocar a falha em janela controlada e verificar se a proteção responde. Reverter uma versão de propósito em homologação mede o tempo real de reversão, que costuma ser maior que o estimado. Injetar uma degradação conhecida mede se o alerta chega, em quanto tempo e com qual informação anexada.

Rotacionar os exercícios de falha provocada ao longo do ano é a cadência que uma equipe consegue sustentar. Concentrar tudo em uma única janela produz risco desnecessário e cansa a equipe de plantão sem ganho proporcional de aprendizado.

Dois indicadores de longo prazo mostram se o conjunto está funcionando. O Mean Time Between Failures, ou MTBF, indica se as falhas estão ficando mais raras, e o MTTR indica se a recuperação está ficando mais curta. Prevenção que funciona move os dois na direção certa, e mover apenas o segundo revela uma equipe que melhorou na resposta sem reduzir a origem do problema.

Perguntas frequentes

Quem define o SLO, a equipe técnica ou a área de negócio?

A definição é conjunta e a palavra final é do negócio. A área de negócio declara qual grau de indisponibilidade o serviço tolera sem prejuízo relevante. A equipe técnica traduz essa tolerância em objetivo mensurável e informa o que custa sustentá-la em arquitetura e em redundância. Objetivo fixado só pela engenharia costuma ficar rígido além do necessário, e objetivo fixado só pelo negócio ignora o custo embutido em cada ponto adicional de disponibilidade.

Canary release e blue-green deployment resolvem o mesmo problema?

Não resolvem. Canary release expõe a versão nova a uma fatia do tráfego e mede o comportamento antes de ampliar. Blue-green deployment mantém dois ambientes completos e desvia o tráfego inteiro de um para o outro, o que torna a volta atrás quase imediata sem oferecer exposição parcial. Canary protege contra o defeito que só aparece sob tráfego real, e blue-green protege contra o tempo de reversão. Em sistemas críticos as duas práticas convivem.

O que fazer quando a reversão automática dispara por falso positivo?

Registrar o disparo como defeito do critério, não como incidente da versão. Falso positivo costuma indicar limite calibrado sobre janela de observação curta demais, ou sobre indicador que oscila por natureza em horário de baixo volume. A correção passa por ampliar a janela e recalcular o limite sobre a base histórica. Desligar a reversão automática depois do primeiro falso positivo é a reação mais comum e a mais cara, porque devolve a decisão ao plantão justamente no pior momento.

Validação automatizada depois da liberação substitui o teste em homologação?

Não substitui, porque as duas etapas cobrem classes diferentes de risco. Homologação verifica se a funcionalidade faz o que a especificação pediu, com dado controlado e ambiente isolado. A validação após a liberação verifica se o serviço continua se comportando como antes sob tráfego real, volume real e dependências reais. Defeito de concorrência, divergência de configuração entre ambientes e integração com sistema legado atravessam homologação sem aparecer.

A governança de atributos precisa estar pronta antes de instrumentar o primeiro serviço?

Precisa existir para o primeiro serviço, não precisa estar completa. A convenção mínima cobre a identificação do serviço, o ambiente, a equipe responsável e a versão. Ela cresce por adição conforme novos tipos de recurso entram no ambiente. Adiar a convenção até chegar ao desenho ideal produz o cenário pior, que é reinstrumentar dezenas de serviços já em produção com a equipe ocupada em outra frente. Quem cobra a convenção é a esteira de entrega, que recusa telemetria sem os atributos obrigatórios.

Organizar orçamento de erro, deploy observado, entrega gradual, validação automatizada e governança de atributos em um ambiente que já está em produção exige diagnóstico, planejamento, execução estruturada e operação contínua. A Rike IS cobre essa sequência inteira sobre a plataforma Dynatrace, do desenho inicial à governança de performance continuada, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve a sua esteira de entrega para uma conversa técnica com os especialistas da Rike IS.