Operações e Gestão → Continuidade de Processos

Continuidade de Processos Empresariais (BCP)

1) O que é o BCP e o que é necessário

O BCP (Business Continuity Planning) é uma abordagem de sistema para garantir a estabilidade dos processos de negócios em qualquer falha, desde a falha do datacentro até a crise do provedor, a fuga de dados ou o aumento repentino da carga de trabalho.
Em produtos altamente fabricados (iGaming, fintechs, marketing), não é apenas sobre infraestrutura - é sobre manter a confiança, manter as obrigações regulatórias e proteger as receitas.

• Manter a disponibilidade de serviços e dados críticos.
• Minimizar tempo de recuperação (RTO) e perda de dados (RPO).
• Garantir que equipes, comunicações e parceiros externos funcionem em crise.
• Normalizar reações e treinamento de pessoal.

2) Componentes principais do BCP

1. BIA - Avaliação do impacto da rejeição em processos e negócios.
2. Riscos e cenários - matriz de ameaças (infraestrutura, exterior, humana).
3. RTO/RPO metas - metas de recuperação e perdas permitidas.
4. O Plano de Recuperação (DRP) é um passo detalhado para reiniciar sistemas e processos.
5. Comunicações - canais internos e externos, modelos de notificação.
6. Testes e revisões - verificações regulares, exercícios, pós-análise.
7. Documentação e controle de versões - acesso centralizado e relevância.

3) Análise de influência (BIA)

BIA determina quais processos são críticos e a rapidez com que eles devem ser restaurados.

1. Lista de todos os processos empresariais (Payments, Bets, Games, KYC, Suporte).

2. Definição de dependências (serviços, dados, provedores, funcionários).

3. Avaliação do impacto da rejeição, financeira, jurídica, reputação, operacional.

4. Instale RTO/RPO para cada processo.

5. «Must Have», «Should Have», «Nice to Have».

4) Matriz de risco

5) RTO, RPO e níveis de criticidade

RTO (Recovery Time Objectiva): quanto tempo é permitido antes da recuperação.
RPO (Recovery Point Objectiva): que quantidade de dados pode ser perdida.

6) DRP (Disaster Recovery Plan)

O objetivo é garantir uma recuperação rápida e consistente dos sistemas.

1. Definir cenários (desastre do Centro, falha do PSP, comprometimento de chaves, perda da rede).

2. Cada cenário é um playbook passo a passo.

3. Suporte à infraestrutura DR.: clusters de reserva, réplicas de base de dados, CDN/edge.

4. Testar regularmente RTO/RPO e procedimentos failover.

5. Armazenar todas as instruções em um único armazenamento com controle de versões.

Scenario: EU region falls
RTO: 30 min    RPO: 5 min
Actions:
1. Activate plan DR # EU
2. Switch DNS → AP Region
3. Verify database consistency (replication lag ≤ 60s)
4. Update Status on StatusPage
5. Perform API benchmarking

7) Organização de comandos e papéis

Coordenador BCP: proprietário do programa, organizando revisões e testes.
DR. lead: responsável pela implementação técnica dos planos DR..
Domain Owners: dá continuidade aos seus processos (Payments, Games, KYC).
Comando de comunicação: responsável por notificações internas/externas e plataformas de status.
HR/Admin: BCP para pessoal (remota, ligações, acessíveis).
Legal/Compliance: notificações regulatórias e medidas legais.

8) Comunicações em crise

• Canais claros e contatos de reserva.
• O primeiro update é dentro de 15 minutos após o incidente.
• Um único tom de comunicação, factos e ETA.
• Atualizações a cada N minutos antes do encerramento do incidente.
• Depois de restabelecermos, é um relatório.

[HH: MM] PSP-X failed. Impact: Deposits in EU region.
Measures: feilover on PSP-Y. ETA stabilization: 30 min.
The next update is at 15:00.

9) Testes e exercícios

Testes de failover, recuperação do banco de dados, simulações de DDoS.
Operação: handover/mudança de comando de rol.
Exercício BCP completo: cenário «blackout» ou indisponibilidade do provedor.

• Testes de DR. - trimestralmente;
• Os ensinamentos BCP são de 1 a 2 vezes por ano.
• Documentação: resultados, desvios de RTO/RPO, ações de melhoria.

10) Métricas e KPI

RTO compliance:% dos processos restaurados ≤ alvo.
RPO compliance:% de processos sem perda de dados> destino.
Dr. teste sucess rate: testes de recuperação bem-sucedidos.
BCP coverage: proporção de processos com planos atuais (> 90%).
Comms SLA: primeiro resumo ≤ 15 min, atualizações por ETA.
Postmortem SLA: 100% eventos críticos com análise de ≤ 72 h.

11) Documentação e gestão do conhecimento

Armazenamento BCP único (versões, proprietários, datas de revisão).
Controle de versões - Revisão pelo menos uma vez a cada 6 meses.
Disponibilidade: cópias offline e serviços de segurança (incluindo telecom/mensagens).
Integração: referência a BCP em SOP, processos de incidente e dashboards operacionais.
Sincronizar com Risk Register e Security Policies.

12) 30/60/90 - plano de implementação

• Definir o dono do BCP e os processos críticos.
• Executar BIA básico e classificação (RTO/RPO).
• Criar matriz de risco e diretório de cenário de incidente.
• Desenvolver um modelo de DRP e a primeira versão para serviços prioritários.

• Fazer um teste DR piloto (failover, recuperação de BD).
• Preparar modelos de comunicação e distribuição de papel.
• Criar um único armazenamento de documentos BCP e uma integração SOP.
• Comece a treinar equipes e pessoal on-call.

• Fazer os ensinamentos BCP entre equipes.
• Auditar a conformidade RTO/RPO e métricas KPI.
• Finalizar o plano de revisão e automação de processos BCP.
• Incluir o BCP no OKR trimestral e verificações internas de segurança.

13) Anti-pattern

«BCP somente para caixa»: não há testes e proprietários reais.
Instruções DR. antiquadas que não correspondem às arquiteturas atuais.
Canais de comunicação e contatos não testados.
Dependências não contabilizadas (PSP, CDN, fornecedores KYC).
Falta de pós-mortem após falhas.
Não há acesso offline ao BCP quando a rede cai.

14) Exemplo de estrutura de documento BCP

1. Objectives and Scope
2. Critical Processes (BIA)
3. Risk Matrix
4. Target RTO/RPO
5. DRP (by scenario)
6. Contacts and Roles
7. Communication templates
8. Schedule of tests and exercises
9. Reporting and auditing
10. Version and update history

15) Integração com outras seções

Analista operacional: métricas headroom e degradação antes de incidentes.
Sistema de notificações e alertas: sinais iniciais para iniciar os procedimentos BCP.
Ética de controle: relatórios transparentes e testes honestos.
Assistentes AI: preparação automática de resumos BCP e DR-check-up.
Cultura de responsabilidade: treinamento, «game days», retrospectivas.

16) FAQ

Q: Em que o BCP é diferente do DRP?
A: BCP - abrange pessoas, processos, comunicações, parceiros e infraestrutura. O DRP é um plano técnico de recuperação de sistemas de TI.

Q: Com que frequência atualizar o BCP?
A: Após cada grande mudança de arquitetura, incidente ou pelo menos uma vez a cada seis meses.

É preciso incluir parceiros?
A: Sim. PSP, KYC e estúdios fazem parte da cadeia de continuidade, devem ter seus próprios acordos OLA e BCP.