Engenharia de confiabilidade em ambientes air-gapped: como definir SLIs e SLOs sem acesso ao runtime

Definir SLIs e SLOs em ambientes air-gapped não é só sobre tirar dados da nuvem: é reestruturar quem observa, como detecta falhas e quem decide o que é 'confiável'. Em vez de métricas em tempo real coletadas por agentes remotos, a engenharia de confiabilidade nesses cenários se baseia em dashboards locais com indicadores estáveis (CPU, disco, latência de serviços críticos), runbooks automatizados para erros recorrentes, como reinício de daemon ou limpeza de logs, e códigos de erro projetados para comunicação humana segura, não para APIs. Ferramentas como Kestra e Windmill ganham espaço porque rodam inteiramente offline, com RBAC granular, logs de auditoria nativos e orquestração de workflows sem dependência externa. Isso não substitui observabilidade: transforma-a em um ativo operacional transferido para o time local, com responsabilidade clara sobre detecção, diagnóstico e reparo, mesmo sem acesso ao código-fonte ou à infraestrutura original.

O desafio técnico mais concreto não é a falta de telemetria, mas a perda de fidelidade semântica: um SLI como 'taxa de sucesso de requisições' vira 'número de respostas HTTP 2xx registradas no proxy local em janela de 5 minutos', com tolerância explícita para atrasos de sincronização entre nós isolados. Isso exige instrumentação deliberada, não apenas 'enviar métricas', mas codificar o que é mensurável, relevante e auditável dentro do perímetro fechado. A abordagem evita a armadilha descrita em 'A Falha Silenciosa das Métricas de Confiabilidade': painéis verdes que mascaram degradação funcional, pois cada SLI é vinculado a um comportamento operacional observável pelo operador, não a uma estatística remota.

Antes, a cobertura CEVIU tratava observabilidade e SLOs como um problema de coleta e visualização, com foco em pipelines em nuvem, alertas em tempo real e integração com ferramentas como Prometheus ou Grafana. Agora, a prática muda de paradigma: não se 'ajusta' a observabilidade para o ar, mas se reconstrói a partir do chão, com tooling que opera sem rede, com ciclos de feedback humanos estruturados (ex.: código de erro 0xAF6600BB acionando um runbook específico via interface local) e responsabilidade transferida por design, não por conveniência. Isso vai além do que foi discutido em '5 Princípios de Resposta a Incidentes': aqui, a detecção não depende de um sistema centralizado, e a recuperação é pré-validada, documentada e executável por operadores sem acesso a dev environments ou logs remotos.

Essa mudança não é técnica apenas: ela redefine a governança de confiabilidade em setores regulados. Bancos centrais, forças armadas e hospitais que adotam sistemas air-gapped não podem esperar por atualizações de SLOs baseadas em dados da nuvem. Quando um SLO de 'tempo médio de restauração < 15 minutos' é sustentado por um runbook automatizado que executa limpeza de cache + reinício de serviço em menos de 90 segundos, e é auditado localmente , , a confiabilidade deixa de ser uma promessa de contrato e vira um procedimento operacional validado. Isso reduz a fadiga de SRE, elimina chamadas noturnas desnecessárias e alinha com os 'Novos Valores da Engenharia de Software': a IA (ou automação) não substitui o julgamento humano, mas amplifica sua capacidade de agir com contexto preciso, mesmo em ambientes onde o próprio runtime é inacessível.