Resiliência exige recuperar a operação
Por anos, a discussão sobre proteção de dados esteve concentrada em uma pergunta relativamente simples: “Temos uma cópia segura caso alguma coisa aconteça?”.
A pergunta continua válida, mas já não é suficiente. Ambientes corporativos se tornaram distribuídos entre data centers, nuvens, plataformas SaaS e diferentes camadas de serviços. Aplicações dependem de identidade, rede, bancos de dados, APIs, certificados, configurações e componentes externos. Nesse contexto, recuperar os dados representa apenas uma parte do caminho para recuperar a operação.
Uma organização pode manter múltiplas cópias, utilizar armazenamento imutável, replicar informações e apresentar excelentes indicadores de backup. Ainda assim, pode descobrir durante um incidente que não consegue restabelecer um serviço crítico no prazo esperado.
A diferença está entre proteger componentes
e construir uma arquitetura capaz de se recuperar.
Backup protege o dado. O negócio depende de uma cadeia
Considere uma aplicação crítica que tenha banco de dados e servidores protegidos adequadamente. Em um evento de grande impacto, restaurar esses componentes não significa necessariamente devolver o serviço aos usuários.
A aplicação pode depender do serviço de identidade para autenticação, de DNS para localização de recursos, de certificados para comunicação segura, de APIs internas, de configurações específicas e de integrações com outros sistemas. Algumas dessas dependências também possuem suas próprias dependências.
Forma-se, assim, uma cadeia de recuperação.
Se um componente essencial dessa cadeia não estiver disponível, todo o restante pode ter sido recuperado corretamente e o serviço ainda permanecer indisponível. É por isso que analisar a recuperabilidade de servidores, bancos ou volumes de forma isolada oferece uma visão incompleta da resiliência.
O objeto que realmente importa para o negócio não é o servidor. É o serviço que aquele conjunto de tecnologias sustenta.
O RTO de um componente não é o RTO do negócio
RTO e RPO continuam sendo referências importantes para qualquer estratégia de continuidade. O problema aparece quando esses objetivos são definidos e medidos apenas no nível dos componentes.
Um banco pode ter um RTO de uma hora. Uma aplicação, duas. Isso não significa que o processo de negócio estará novamente disponível em duas horas.
O tempo efetivo de recuperação depende da sequência necessária para reconstruir o serviço, das relações entre seus componentes e da capacidade das equipes de executar essa sequência sob condições adversas.
Em arquiteturas complexas, essa diferença pode ser significativa. O indicador técnico pode mostrar que todos os objetivos individuais foram atendidos enquanto o serviço de negócio continua indisponível.
O indicador técnico pode mostrar que todos os objetivos individuais foram atendidos enquanto o serviço de negócio continua indisponível.
Por isso, uma estratégia madura de resiliência precisa relacionar os objetivos técnicos aos serviços que a organização considera críticos.
A arquitetura de recuperação também precisa ser projetada
Arquiteturas de produção recebem atenção constante. São documentadas, monitoradas, otimizadas e modificadas à medida que o negócio evolui. A arquitetura necessária para recuperá-las nem sempre acompanha essa mesma evolução.
Cada nova integração, serviço ou dependência pode alterar a sequência necessária para uma recuperação. Uma mudança no sistema de identidade pode afetar dezenas de aplicações. A adoção de uma nova API pode introduzir uma dependência externa. Uma alteração na arquitetura de rede pode tornar um procedimento de recuperação anteriormente testado insuficiente.
Isso significa que resiliência não pode ser tratada como uma camada adicionada depois que a arquitetura está pronta. Ela precisa fazer parte das decisões sobre como sistemas críticos são construídos, operados e modificados.
A pergunta deixa de ser apenas o que precisa de backup e passa a incluir o que precisa existir para que aquele dado volte a ter utilidade para o negócio.
Recuperar componentes é diferente de recuperar capacidade operacional
Essa mudança de perspectiva também altera a forma como os testes deveriam ser realizados.
Testar se um banco pode ser restaurado comprova uma capacidade técnica importante. Testar se um serviço crítico consegue voltar a operar comprova algo diferente. Exige validar dependências, sequência de recuperação, acessos, configurações, integrações e a participação das equipes responsáveis.
É nesse momento que premissas não documentadas costumam aparecer.
Quanto mais representativo for o teste das condições reais de recuperação, maior será a capacidade de identificar essas dependências antes que elas se tornem um problema durante uma interrupção.
Resiliência é uma propriedade da arquitetura
Backup, replicação, imutabilidade e disaster recovery continuam sendo componentes fundamentais de uma estratégia de proteção. Nenhum deles, isoladamente, garante que a organização conseguirá restabelecer uma operação crítica.
Resiliência surge da forma como essas capacidades são combinadas com arquitetura, processos, pessoas e conhecimento das dependências que sustentam cada serviço.
Isso muda também a maneira de medir o resultado. Taxa de sucesso dos backups, quantidade de cópias e tempo de restauração continuam relevantes, mas precisam estar relacionados a uma pergunta maior:
Quanto tempo a organização leva para devolver ao negócio uma capacidade que foi interrompida?
A unidade de medida da resiliência não deveria ser o componente recuperado, mas o serviço de negócio restabelecido.
