Disponibilidade e recuperação com metas definidas em contrato

Como definir RTO e RPO para o seu sistema?

RTO e RPO saem de uma conversa de negócio, não de uma escolha técnica: quanto tempo o sistema pode ficar parado e quanto de dados pode ser perdido sem prejuízo inaceitável. A arquitetura vem depois, para sustentar essas metas.

• RTO (Recovery Time Objective): tempo máximo para o sistema voltar a funcionar depois de uma falha.
• RPO (Recovery Point Objective): quantidade máxima de dados que se aceita perder, medida em tempo. Um RPO de uma hora significa que, no pior caso, se perdem os registros da última hora.

Para chegar às metas, ajudam perguntas como:

• Quanto custa cada hora de sistema parado, em vendas, multas contratuais ou operação interrompida?
• Quais dados são impossíveis de recriar, e quais podem ser recuperados de outra fonte?
• Há obrigações contratuais ou regulatórias de disponibilidade?
• O sistema precisa voltar inteiro, ou algumas funções podem voltar antes de outras?

Metas mais exigentes custam mais: um RPO perto de zero exige replicação contínua dos dados, e um RTO curto exige um ambiente pronto para assumir. Por isso, as metas podem variar por função e por sistema, e só entram no contrato depois de validadas por arquitetura e testes.

O que é um teste de contingência?

Teste de contingência é a simulação controlada de uma falha para verificar se o sistema se recupera como o plano diz. Ele transforma o plano de recuperação de desastres de documento em capacidade demonstrada.

No WIP Mission Critical, os testes são planejados e periódicos. Exemplos do que pode ser simulado:

• perda do servidor ou da zona principal da aplicação;
• falha do banco de dados principal, com promoção da réplica;
• restauração completa a partir do backup, em ambiente separado;
• perda de um serviço externo do qual o sistema depende;
• ausência de uma pessoa-chave, para verificar se os procedimentos estão documentados.

Cada teste mede o tempo real de recuperação e a perda real de dados e compara com o RTO e o RPO do contrato. O resultado vira um registro: o que funcionou, o que demorou mais do que o previsto e o que precisa mudar.

Quando o teste mostra uma diferença entre o plano e a realidade, ela é corrigida e testada de novo. É por isso que a WIP só assume metas de recuperação em contrato quando há arquitetura validada e testes que as sustentem: a promessa precisa ter sido demonstrada antes.

Por que o atendimento 24/7 depende de avaliação?

Porque atendimento 24/7 de verdade exige pessoas de plantão, procedimentos documentados, ferramentas de acionamento e acesso preparado a qualquer hora. A WIP só oferece esse atendimento quando ele é contratado e quando a estrutura operacional consegue sustentá-lo.

Prometer resposta a qualquer hora sem essa estrutura seria vender uma garantia que não existe. O incidente das três da manhã encontraria um telefone sem resposta ou uma pessoa sem acesso, e o contrato não teria valido de nada.

A avaliação técnica considera:

• Criticidade: o que acontece com o negócio se o sistema parar fora do horário comercial.
• Arquitetura: quanto da recuperação é automática e quanto exige intervenção humana.
• Procedimentos: se cada tipo de incidente tem roteiro de resposta testado.
• Acesso: se quem está de plantão tem acesso seguro aos sistemas, com o mínimo de permissões.
• Escala de plantão: se há pessoas suficientes para cobrir os horários sem depender de uma só.

Com isso, o SLA de cada contrato define horários de atendimento, tempos de resposta por severidade e canais de acionamento. Em alguns casos, horário estendido com monitoramento contínuo atende ao risco com custo menor, e a avaliação também pode recomendar esse caminho.

O que o WIP Mission Critical entrega?

• Arquitetura de redundância e plano de recuperação de desastres.
• Objetivos de recuperação (RTO e RPO) definidos em contrato.
• Monitoramento e resposta a incidentes conforme o SLA contratado.
• Testes de contingência periódicos e revisão de segurança.

Para quem é o WIP Mission Critical?

• Aplicações em que a indisponibilidade causa perda financeira ou risco operacional relevante.
• Empresas com obrigações contratuais ou regulatórias de disponibilidade e recuperação.
• Sistemas que precisam de resposta a incidentes fora do horário comercial.

O que não está incluído no WIP Mission Critical?

• Promessa de disponibilidade absoluta ou de recuperação garantida sem arquitetura validada e testes que a sustentem.
• Atendimento 24/7 sem contratação específica e sem estrutura operacional que o suporte.
• Custos de infraestrutura redundante, licenças e serviços de terceiros.

Quanto custa o WIP Mission Critical?

O preço do WIP Mission Critical é definido sob avaliação. Sob avaliação técnica: depende da arquitetura, das metas de RTO e RPO, do SLA e dos horários de atendimento. Infraestrutura, licenças e serviços de terceiros são à parte.