Olha, ultimamente uma conversa vem se tornando bem frequente entre minhas reuniões. Ela sempre começa do mesmo jeito: a empresa já investiu em backup, tem replicação, tem plano de DR documentado, às vezes até faz teste de restore, e mesmo assim continua com aquela pulga atrás da orelha, “se der ruim de verdade, a gente volta… mas volta certo?”. E eu entendo perfeitamente esse incômodo, porque ele aponta para um ponto cego bem comum quando o assunto é continuidade: RPO e RTO não protegem a verdade operacional.
RPO e RTO são métricas fundamentais e não dá para discutir continuidade sem elas. O RPO tenta responder quanto de informação você pode perder sem gerar um impacto inaceitável. O RTO tenta responder quanto tempo você aguenta ficar indisponível até o prejuízo virar uma bola de neve. O problema é que, no mundo real, essas métricas costumam ser aplicadas com um foco muito “infra e sistema”: restaurar banco, subir aplicação, reconfigurar rede, reativar serviços. Quando dá certo, a sensação é de missão cumprida. Só que esse “dar certo” normalmente significa “o ambiente voltou a responder”. E isso não é a mesma coisa que “o negócio voltou a operar com confiança”.
É aqui que entra o conceito de verdade operacional que, apesar do nome, é bem pragmático. Verdade operacional é a capacidade de olhar para os seus sistemas e dados e reconhecer, sem hesitação, o estado real do negócio. É conseguir dizer com segurança se um pedido existe e em que status ele está, se o pagamento está associado ao pedido certo, se o estoque reflete o que foi reservado e expedido, se o faturamento está completo, se houve cancelamento e ele foi respeitado por todas as partes do fluxo, se o atendimento enxerga o histórico inteiro do cliente. É também o oposto do que muita operação vira durante incidentes: um lugar onde todo mundo “acha” alguma coisa, mas ninguém “sabe” com base em sinais confiáveis.
O que torna isso mais crítico hoje é que a operação raramente mora em um único sistema. Ela mora num ecossistema: ERP, CRM, e-commerce, WMS, gateways de pagamento, antifraude, transportadoras, atendimento, automações, parceiros e, claro, a camada de dados que consolida tudo isso para decisão e governança. No meio desse ecossistema existe uma camada que, quando falha, derruba a verdade operacional mesmo que o ambiente “esteja de pé”: integrações e fluxos. APIs, filas, webhooks, conectores, jobs, sincronizações, eventos. É aqui que a continuidade costuma ser mais frágil do que as empresas imaginam, porque a maioria dos planos de recuperação não foi desenhada para restaurar “o estado do negócio”, e sim “os componentes”.
A consequência aparece em formatos que quase todo mundo já viveu, mas nem sempre nomeou. Um deles é duplicidade. Você restaura, volta rápido, tudo “parece normal”, só que retries e reprocessamentos começam a disparar eventos que não são idempotentes. O pedido é confirmado duas vezes, a baixa de estoque acontece duas vezes, a cobrança cai em duplicidade, a conciliação começa a gritar. Não é um incidente de downtime. É um incidente de consistência. Outro formato comum é o buraco silencioso: o evento não duplica, ele simplesmente não chega. Um webhook não foi entregue, um job falhou sem alarme, uma fila expirou mensagem, uma integração com parceiro ficou fora do ar e não tinha compensação. Resultado: existe um “mundo A” no e-commerce e um “mundo B” no ERP. Para o cliente, a compra aconteceu. Para o backoffice, ela não existe ou está incompleta. Isso quebra faturamento, expedição, comissionamento, atendimento e, principalmente, a confiança no que os sistemas estão dizendo.
Tem ainda a quebra de ordem, que é o tipo de problema que mais drena energia porque é difícil de enxergar. Em ambientes distribuídos, você pode processar “entregue” antes de “pago”, ou “cancelado” depois de “expedido”, ou receber atualizações de status fora de sequência por latência, reprocessamento ou inconsistência de relógio/partições. A aplicação responde, o banco está íntegro, o RTO foi atendido… mas o estado final vira uma colcha de retalhos. E quando isso acontece, a empresa entra em modo manual: time financeiro conciliando no braço, operações criando planilha paralela, atendimento pedindo “um minuto” para verificar em três telas, TI rodando scripts de correção e discutindo em war room qual fonte é a certa. É nesse momento que fica claro que continuidade não é só “voltar”, é “voltar com coerência”.
Por isso eu gosto de provocar com uma pergunta simples: no seu plano de recuperação, você consegue dizer, sem depender de reunião de crise, quais fluxos ficaram pendentes, quantos eventos foram para dead letter, quais integrações estão degradadas, qual domínio do negócio está atrasado, e quais transações correm risco real de duplicidade se você reprocessar? Você consegue distinguir o que pode ser reprocessado com segurança do que precisa de reconciliação? Você tem uma forma objetiva de declarar “o estado está consistente de novo”? Se a resposta envolve “vamos olhar logs”, “vamos comparar amostras” ou “vamos pedir para o time conferir”, então RPO e RTO estão cobrindo a parte certa, mas deixando descoberta a parte que realmente determina o custo do incidente: o tempo até recuperar a verdade operacional.
E tem um detalhe que muita liderança sente, mesmo que não fale abertamente: quando a verdade operacional quebra, o BI vira o mensageiro do caos, geralmente tarde. Você percebe que algo está errado quando o dashboard “entorta”, quando um indicador fica estranho, quando a curva cai sem explicação, quando uma meta parece ter sido atingida cedo demais ou tarde demais. Só que BI não deveria ser o primeiro lugar onde você descobre inconsistência. BI deveria ser a camada onde você valida saúde do negócio com sinais: freshness por domínio, completude, qualidade, reconciliação entre fontes, regras semânticas claras. Sem isso, em incidente, a empresa cai no pior estado possível: não sabe qual número é o certo, não sabe qual sistema é a fonte de verdade, não sabe se o problema é atraso ou perda, e começa a decidir na intuição. E “intuição” em operação distribuída custa caro.
Na prática, maturidade aqui começa quando a empresa para de tratar continuidade como checklist de infraestrutura e passa a tratá-la como disciplina de produto e operação: integrações são produto. Integrações têm contrato, versionamento, testes, observabilidade e governança. Têm padrões de retry com backoff, idempotência, correlação ponta a ponta, rastreabilidade de eventos, controle de reprocessamento e mecanismos de compensação. E, do lado de dados, têm camadas que ajudam o negócio a não discutir semântica no meio do incêndio: um catálogo minimamente organizado, regras de qualidade, e uma camada semântica que reduz ambiguidade. Isso tudo, junto, não elimina incidentes, mas reduz drasticamente o tempo de “voltar a operar com confiança”, que é o que interessa quando o relógio está correndo.
Se você estiver revisando sua estratégia de continuidade, eu recomendo inverter a ordem das perguntas. Em vez de começar por “qual é o RTO ideal?”, começar por “qual é o estado mínimo aceitável para a operação ser confiável?”. Quais fluxos são críticos e não podem falhar? Quais eventos precisam ser “exatamente uma vez” porque duplicidade é inaceitável? Onde consistência eventual é aceitável e onde consistência forte é necessária? Quais domínios toleram atraso e quais não toleram? Quando você responde isso, RPO e RTO deixam de ser métricas abstratas e viram um resultado de engenharia: você desenha infraestrutura e DR para sustentar um objetivo que é, no fundo, de negócio.
No fim, o que protege o negócio não é só voltar rápido. É voltar certo. E é exatamente aí que faz sentido ter um parceiro estratégico como a HUB.DEV, porque continuidade moderna não se resolve só com “mais ferramenta”: ela exige desenho de arquitetura de integrações, governança de reprocessamento, observabilidade de ponta a ponta, e uma camada de dados que sustente decisão confiável durante e depois do incidente. Quando essa base está bem montada, RPO e RTO param de ser promessas no papel e viram parte de uma operação resiliente de verdade.
