Confiabilidade – Padrões de recuperação de desastres | Padrões |

Confiabilidade – Padrões de recuperação de desastres

Saiba mais sobre a confiabilidade bem construída → Recuperação de desastres e continuidade dos negócios

Padrões

Onde procurar	Qual é a boa aparência
Estratégia de backup de dados	✅ Exportações automatizadas semanais ou mensais usando o Serviço de exportação de dados ou um serviço de backup e recuperação dedicado (como O seu). A frequência de exportação corresponde aos requisitos de RPO. Dados críticos do objeto exportados para o armazenamento de objeto externo quando necessário.
Estratégia de backup de metadados	✅ Todos os metadados com controle de versão no Git usando o formato de origem Salesforce DX. Alterações de metadados implantadas apenas no controle de origem. O pipeline CI/CD pode recriar qualquer ambiente a partir do repositório. Recuperação de ponto no tempo disponível por meio do histórico do Git.
Estratégia de backup de arquivo	✅ Registros, anexos e documentos ContentVersion exportados para armazenamento externo conforme agendado. Exportação de arquivo automatizada para requisitos de retenção regulatória. Sistema de arquivamento externo para arquivos mais antigos que as necessidades operacionais de negócios.
Validação de backup	✅ Restaure trimestralmente os exercícios para ambientes de Developer ou Sandbox completo. Restaure procedimentos documentados em manuais com instruções passo a passo. A restauração de teste valida a integridade e a completude do backup antes de ocorrerem desastres.
Agenda de testes de recuperação	✅ Testes de restauração parcial trimestrais (metadados, objetos específicos, subconjuntos de arquivos). Detalhe de recuperação completa anual com restauração de ambiente completa. Lições aprendidas documentadas e manuais atualizados após cada teste.
Serviço de backup de terceiros	✅ Backup automatizado com recurso de restauração de ponto no tempo. Contrato de nível de serviço definindo RPO/RTO. Verificação automatizada diária da conclusão do backup. Redundância geográfica com backups armazenados em várias regiões.
Objetos e campos personalizados	✅ Objetos personalizados incluídos em execuções agendadas do Serviço de exportação de dados, com valores de campo de resumo de fórmula e totalização recalculados em vez de exportados (não há valor armazenado para capturar) e binários de arquivo ou anexo processados por meio de um caminho de exportação separado. Tipos de campo complexos e relacionamentos de pesquisa documentados e testados na sequência de restauração.
Arquivos e anexos	✅ Objetos ContentDocument e ContentVersion exportados com binários de arquivo. Bibliotecas de documentos com backup, incluindo estruturas e permissões de pasta. Os arquivos exportados mantêm o histórico de versões para tipos de documento críticos.
Estratégia de atualização de sandbox	✅ Organização de produção atualizada para Sandbox completo trimestralmente para testes de carga e validação de recuperação de desastres. A atualização de sandbox usada como teste de procedimento de restauração. O mascaramento de dados aplicado após a atualização para proteger dados confidenciais em ambientes de teste.
Monitoramento e alerta de backup	✅ Alertas automatizados quando backups agendados falham ou são atrasados. Painel mostrando a taxa de sucesso do trabalho de backup, o tempo de conclusão e tendências de volume de dados. Escalonamento na chamada para falhas de backup excedendo a janela de atraso aceitável.

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Estratégia de backup	⚡️ Sem backup automatizado configurado, dependendo apenas de backups de infraestrutura da plataforma. Serviço de backup de terceiros configurado, mas nunca testado: os backups podem estar corrompidos ou incompletos. Exportações manuais do Data Loader contadas para backups (execução inconsistente, cobertura incompleta, sem automação).
Controle de versões de metadados	⚡️ Alterações de metadados implementadas por meio de Conjuntos de alterações sem controle de origem. Sem repositório do Git para histórico de metadados. Recuperação em tempo real impossível – não é possível restaurar a configuração de última boa após alterações destrutivas.
Validação de backup	⚡️ Backups configurados, mas nunca restaurados para o ambiente de teste. A primeira tentativa de restauração ocorre durante um desastre real que revela um escopo incompleto ou arquivos corrompidos. Procedimentos de backup documentados, mas não testados pelo pessoal de backup.
Escopo do backup	Presumir que o Serviço de exportação de dados capture tudo quando os valores de campo de resumo de totalização e fórmula nunca são exportados (recalculados dinamicamente, não armazenados) e binários de arquivo ou anexo exigem tratamento separado, deixando lacunas descobertas apenas na restauração.
Procedimentos de recuperação	⚡️ O manual de recuperação contém etapas desatualizadas da arquitetura de dois anos. Procedimentos de recuperação testados por um único especialista que deixou a empresa. Procedimentos manuais são tão complexos que a execução sob estresse é propensa a erros.
Frequência de backup	⚡️ Dados críticos da transação fazem backup semanalmente quando o requisito de negócios é RPO de 24 horas. Frequência de backup não alinhada à crítica dos negócios – mesma agenda para todos os dados, independentemente da importância. O agendamento de backup foi perdido devido à falta de monitoramento e alerta.
Conformidade regulatória	⚡️ A retenção de backup é mais curta que a exigida pela regulamentação. Por exemplo, documentação de conformidade com HIPAA (apólices, análises de risco, BAAs, registros de violação) limpa antes de sua retenção de seis anos §164.316, ou registros de auditoria financeira governados por SOX excluídos antes de sua retenção de sete anos. Lacuna de conformidade descoberta durante a auditoria.
Armazenamento de arquivos	⚡️ Arquivos grandes armazenados no Salesforce sem estratégia de arquivamento. O armazenamento de arquivos aumenta até o limite de aproximações da organização. Sem backup de registros ContentVersion – arquivos perdidos se a organização for corrompida. Dependendo de usuários para manter cópias pessoais de arquivos críticos.
Teste de sandbox	Sandbox completo nunca atualizado da produção - ambiente de teste muito diferente da produção. O volume de dados no sandbox 1% da produção impede a validação de restauração realista. A atualização do sandbox tratada como uma inconveniência, em vez de uma oportunidade de validação de recuperação de desastres.
Monitoramento	Os trabalhos de Backup falham silenciosamente sem alerta. Descubra falhas de backup semanas depois durante o desastre quando o backup for necessário. Nenhum painel mostrando tendências de sucesso do trabalho de backup. Integridade do serviço de backup monitorada apenas quando a fatura chega.
Chaves de criptografia	⚡️ Tratar dados criptografados por Shield como seguros sem proteger o material de chave: A rotação de chaves sozinha deixa os dados anteriores intactos, mas destruir um segredo do locatário (crypto-shred) ou perder o material de chave somente em cache ou Traga sua própria chave torna os dados criptografados permanentemente irrecuperáveis. O gerenciamento de chaves é omitido dos procedimentos de recuperação.
Dependências organizacionais cruzadas	Faça backup da organização principal apenas quando a solução depender de aplicativos conectados, integrações externas ou SSO: segredos de aplicativo conectados, autorizações de credencial nomeada e OAuth e tokens de autenticação externos não são preservados por uma restauração de dados e metadados e devem ser reconfigurados e reautorizados para que uma organização recuperada possa se autenticar em sistemas externos. Quando o SSO externo é o único caminho de login, um provedor de identidade indisponível bloqueia o login até mesmo em uma organização totalmente recuperada.

Padrões

Onde procurar	Qual é a boa aparência
Definição do objetivo de tempo de recuperação (RTO)	✅ RTO definido por funcionalidade de negócios em vez de uniforme em toda a organização. Operações críticas à receita: minutos a 1 hora. Serviços voltados ao cliente: 1 a 4 horas. Ferramentas internas: 4 a 24 horas. Relatórios históricos: dias. RTOs documentados com aprovação da parte interessada dos negócios.
Definição de objetivo de ponto de recuperação (RPO)	✅ RPO definido com base na perda de dados aceitável por funcionalidade. Transações financeiras: near-zero RPO (segundos, replicação assíncrona conduzida por evento). Registros do cliente: near-zero (minutos por meio da CDC). Dados do Analytics: hours (sincronização agendada). Estado de fluxo de trabalho temporário: dias (nenhuma replicação necessária).
Disponibilidade e papéis da equipe	✅ Equipe principal e de backup documentada para todos os papéis críticos. Nenhum único ponto de falha no Knowledge operacional. Árvore de escalação definindo o respondente principal, primeiro backup, segundo backup. Informações de contato mantidas no sistema acessíveis quando o Salesforce está indisponível.
Procedimentos de comunicação	✅ Plano de comunicação de incidente definindo quem notifica usuários, clientes e executivos. Página de status externo hospedada fora do Salesforce para comunicação do usuário durante indisponibilidades da plataforma. Sistema de notificação por SMS para a equipe de chamada quando as ferramentas de comunicação principais estiverem indisponíveis. Períodos de escalação documentados (quando escalar da equipe para o gerente para o executivo).
Mapeamento de dependência do fornecedor	✅ Todos os fornecedores externos críticos documentados, incluindo Salesforce, parceiros de integração, provedores de pacote de ISV. SLAs do fornecedor e janelas de suporte documentadas (24/7 vs. somente horário comercial). Contatos e procedimentos de escalação do fornecedor documentados. Opções alternativas do fornecedor identificadas para dependências críticas.
Obrigações de notificação regulatória	✅ Requisitos obrigatórios de notificação de incidentes documentados por setor (Serviços financeiros, saúde, governo). Períodos de notificação definidos para corresponder à janela obrigatória de cada regulamento. Matriz de responsabilidade definindo quem registra notificações com quais órgãos regulatórios. Modelos preparados para notificação regulatória rápida.
Análise de impacto de negócios	✅ Cada funcionalidade de negócios classificada por impacto de receita, impacto do usuário e risco regulatório. Priorização de recuperação com base na classificação de impacto de negócios. Recursos alocados para recuperação de desastres proporcionalmente à crítica dos negócios. Análise de impacto revisada anualmente conforme as prioridades de negócios evoluem.

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Definição de RTO/RPO	⚡️ “O sistema deve ser confiável” sem metas de RTO/RPO mensuráveis. RTO/RPO definido pela equipe de TI sem entrada da parte interessada dos negócios. Foque uniformemente em todos os recursos ignorando as diferenças de criticalidade (“tudo precisa de 99,999% de tempo de atividade”).
Prontidão da equipe	⚡️ O administrador único do Salesforce conhece os procedimentos de recuperação de desastres sem nenhuma documentação ou equipe de backup. A rotação na chamada inclui pessoal que nunca executou procedimentos de recuperação. Respondentes principais indisponíveis durante um desastre (vacação, doença, empresa descontinuada).
Planejamento de comunicação	⚡️ Sem plano de comunicação – descobrir a necessidade de notificar os usuários após um incidente já em andamento. Página de status hospedada no Salesforce em si indisponível durante a indisponibilidade do Salesforce. Horas de espera para notificar executivos enquanto tenta a recuperação.
Dependências do fornecedor	⚡️ Não está ciente dos termos do SLA do fornecedor até que ocorra um desastre e espera suporte 24/7 do fornecedor com cobertura somente horário comercial. Nenhum contato de escalação de fornecedor documentado. Provedor de pacote de ISV necessário para recuperação, mas a empresa não está mais nos negócios.
Requisitos regulatórios	⚡️ Não está ciente das leis obrigatórias de notificação de violação. Descubra o requisito de notificação de 24 horas após 48 horas. Nenhum modelo preparado – rascunho de notificações regulatórias durante a resposta ao incidente enquanto o relógio de conformidade toca.
Priorização de recuperação	⚡️ Tentando restaurar todos os recursos simultaneamente durante um desastre, em vez de priorizar operações críticas à receita. Passar oito horas recuperando o recurso de relatórios internos antes de lidar com o sistema de pedidos voltado para o cliente.
Testes e drill downs	⚡️ Plano de continuidade de negócios nunca testado por meio de exercícios. Presumir procedimentos documentados funcionarão sob estresse sem validação. Exercícios de mesa evitados devido a “falta de tempo”, apesar de passar dias recuperando-se de problemas não descobertos durante desastres reais.
Transferência de Knowledge	⚡️ O Knowledge da recuperação de desastres estava concentrado em um arquiteto sênior que não documentou nada. Novos membros da equipe integrados sem treinamento de recuperação de desastres. Presumir que todos saibam o que fazer durante desastres sem treinamento ou exercícios explícitos.
Validação de pressuposição	Os procedimentos de recuperação presumem que o backup está acessível em 15 minutos, mas a recuperação do backup do armazenamento frio leva 8 horas. Presumindo que a equipe esteja disponível em 30 minutos, mas nenhum procedimento de escalonamento ou rotação na chamada seja definido. Estimativas de tempo de recuperação com base em pressuposições otimizadas nunca validadas por meio de testes.

Padrões

Onde procurar	Qual é a boa aparência
Alinhamento arquitetônico de RTO	✅ As decisões de arquitetura correspondem aos compromissos de RTO. Minutes RTO requer failover automatizado e espera rápida. Horas de RTO requer recuperação scriptada e espera calma. A RTO Days aceita a recuperação manual de backup frio. Sobre-engenharia evitada quando os negócios não justificam a complexidade.
Estratégia de replicação de RPO	✅ O método de replicação corresponde ao destino de RPO. RPO quase zero: transmissão de evento assíncrono por meio de Eventos de plataforma em cada salvamento de registro (segundos de atraso de propagação, pelo menos uma entrega). RPO de minutos: Alterar a replicação assíncrona de captura de dados. RPO de horas: extração de API em lote agendada. RPO de dias: backup manual em uma agenda fixa.
Teste de RTO	✅ Procedimentos de recuperação testados em condições temporizadas. RTO real medida durante os exercícios de recuperação de desastres. Lacunas entre o RTO-alvo e o RTO-alvo identificadas e remediadas. RTO alcançável pela equipe de backup, não apenas por especialistas principais.
Validação de RPO	✅ Perda de dados medida durante testes de recuperação. RPO real comparado à meta durante os exercícios. Atraso de replicação monitorado continuamente na produção. Alertas configurados quando a replicação fica atrás do compromisso de RPO.
RTO/RPO específico da funcionalidade	✅ Diferentes recursos de negócios têm diferentes metas de RTO/RPO refletindo a crítica dos negócios. Fluxo de pedido de comércio eletrônico: RTO de 15 minutos, RPO quase zero (justificando ativo-pasivo de várias organizações). Base de Knowledge interna: RTO de 8 horas, RPO de 24 horas (justifica a restauração manual do backup).
Análise de custo-benefício	✅ Metas de RTO/RPO equilibradas em relação ao custo de implementação. Metas mais rígidas exigem um aumento exponencial do investimento. Caso de negócios documentado mostrando o custo de tempo de inatividade justificando o investimento em recuperação de desastres. A revisão anual confirma o alinhamento contínuo entre investimento e valor comercial.
Alinhamento de SLA	✅ Metas de RTO/RPO da solução consideram a linha de base de SLA da plataforma. A solução só pode fornecer RTO melhor que a linha de base da plataforma com a arquitetura de várias organizações. Defina metas realistas considerando os recursos da plataforma como base.
Monitoramento de recursos de recuperação	✅ Monitoramento contínuo da moeda de backup (duração do backup versus meta de RPO). Alerta quando o backup fica atrás da agenda. Verificação automatizada de que a infraestrutura de recuperação (organização secundária, armazenamento externo) está operacional.
Recuperação automatizada vs. manual	✅ Metas de RTO agressivas (minutos) exigem failover automatizado com intervenção humana mínima. Moderar metas de RTO (horas) permite a recuperação com script com início humano. Metas de RTO flexíveis (dias) aceitam a recuperação manual seguindo procedimentos documentados.

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Metas irrealistas	Confirmação de 15 minutos de RTO com procedimentos de recuperação manuais que exigem 4 horas de execução. Promete RPO zero sem infraestrutura de replicação síncrona. Metas de RTO definidas por TI sem suporte arquitetônico.
Desalinhamento da arquitetura	Compromisso de RTO de 30 minutos, mas nenhum processo de fallover automatizado e procedimentos de recuperação são totalmente manuais. Compromisso de RPO zero, mas somente backups diários configurados. Metas agressivas sem investimento correspondente em automação e redundância.
Metas não testadas	⚡️ A RTO nunca foi validada por meio de exercícios de recuperação de desastres temporizados. Presumindo que RTO de duas horas seja alcançável, mas nunca seja restaurada sob restrições de tempo. Descobrir durante um desastre real que registrou quatro horas de RTO, na verdade, requer 18 horas.
Metas uniformes	⚡️ Todos os recursos atribuídos ao mesmo RTO/RPO independentemente da crítica dos negócios. Sistema de relatórios em lote interno projetado para disponibilidade de cinco e nove, enquanto o comércio eletrônico crítico de receita tem o mesmo alvo. Sobre-investimento em recursos não críticos e sub-investimento em sistemas críticos.
Ignorar dependências	⚡️ A RTO presume apenas a restauração da organização do Salesforce, mas a solução depende do provedor de identidade externo também indisponível. A RPO presume que o backup de dados é suficiente, mas as credenciais e os ajustes de integração não têm backup. As estimativas de tempo de recuperação ignoram o tempo para restaurar sistemas dependentes.
Lacunas de replicação	Compromete-se com RPO de 15 minutos, mas a Captura de dados de alteração foi configurada apenas para 3 dos 12 objetos críticos. Replicação de evento de plataforma configurada, mas sem monitoramento do atraso de entrega de evento. A infraestrutura de replicação falha e fica não detectada por semanas até um desastre.
Ignorância de custo	⚡️ Comprometer-se com a disponibilidade de cinco nove sem entender o custo da implementação. Metas de RTO/RPO definidas sem análise de custo-benefício. Negócios que não estão dispostos a financiar a infraestrutura necessária para metas já confirmadas aos clientes.
Metas estáticas	⚡️ RTO/RPO definido há 5 anos nunca reavaliado, apesar do crescimento dos negócios e da mudança de prioridades. As metas continuam inalteradas à medida que a solução evolui e a crítica muda. Processo de revisão anual ausente.
Lacunas na documentação	Metas de RTO/RPO documentadas no documento de arquitetura, mas não comunicadas às partes interessadas dos negócios. Negócios sem conhecimento de recursos de recuperação confirmados. Lacuna descoberta quando a empresa espera uma recuperação de 1 hora, mas a arquitetura oferece suporte apenas a RTO de 24 horas.
Precisão falsa	Comprometer-se com “disponibilidade de 99,97%” quando a infraestrutura de monitoramento não pode ser medida com essa precisão. Metas definidas com precisão falsa sugerindo rigor quando a análise subjacente é estimativa bruta.
Monitorar ausência	⚡️ Sem monitoramento contínuo de recursos de recuperação. O backup fica 2 dias atrás da agenda violando o compromisso de RPO, mas sem alertas. Organização secundária em arquitetura ativa-pasiva não recebendo atualizações de replicação, mas verificações de integridade não configuradas.
Planejar sem execução	⚡️ Belo plano de recuperação de desastres com metas de RTO/RPO agressivas, mas sem automação, teste ou procedimentos validados. Plano criado para cumprir a caixa de seleção de conformidade, mas sem realidade operacional por trás de compromissos.

Padrões

Onde procurar	Qual é a boa aparência
Redundância de dados	✅ A plataforma fornece backup de infraestrutura automaticamente. A replicação em nível de aplicativo complementa o backup de plataforma quando os negócios exigem uma recuperação mais rápida. Captura de dados de alteração ou Eventos de plataforma replicam dados críticos para o armazenamento secundário continuamente. A replicação habilita a recuperação de erros de configuração ou corrupção lógica que os backups de infraestrutura não podem resolver.
Redundância do aplicativo	✅ Lógica de aplicativo sem estado que sobrevive a falhas de transações individuais. Nenhum estado no lado do servidor impede a escala horizontal. Tipos de metadados personalizados e Configurações personalizadas para configuração instantaneamente disponíveis em todos os servidores de aplicativo. Qualquer servidor de aplicativo pode processar qualquer solicitação sem depender do estado do servidor específico.
Redundância de integração	✅ Os padrões do disjuntor detectam integrações com falha. Os eventos de plataforma colocam solicitações na fila quando os sistemas externos estão indisponíveis, em vez de bloquear operações do usuário. Falhas do sistema externo isoladas da funcionalidade voltada para o usuário. Várias opções de fornecedor externo identificadas para integrações críticas que habilitam a mudança rápida do provedor durante indisponibilidades do fornecedor.
Padrões organizacionais múltiplas para cargas de trabalho críticas	✅ Padrão ativo-pasivo: a organização primária atende todo o tráfego, a organização secundária sincronizada, mas ociosa, faz o failover durante a indisponibilidade da região primária. Padrão ativo: ambas as organizações atendem o tráfego de produção continuamente, usuários alocados por região geográfica ou unidade de negócios. Multiorganização justificada apenas quando os negócios exigem RPO/RTO além dos recursos da plataforma.
Sincronização de dados de várias organizações	✅ Captura de dados de alteração oferece replicação quase em tempo real para dados críticos (15 minutos de RPO). Os Eventos de plataforma fornecem streaming de eventos para transações críticas (RPO quase zero). Replicação agendada da API em massa 2.0 para dados de referência (24 horas de RPO aceitável). Estratégia de resolução de conflitos definida para ativo-ativo quando o mesmo registro for modificado em ambas as organizações.
Arquitetura ativa-pasiva de várias organizações	✅ A organização principal na região leste dos EUA atende todo o tráfego de produção. Organização secundária na região da Europa sincronizada por meio da CDC, mas ociosa. O roteamento de DNS ou a camada de autenticação direciona os usuários para a organização ativa. As verificações de integridade automatizadas acionam o failover quando a organização principal está indisponível por 10 minutos consecutivos.
Arquitetura ativa-ativa de várias organizações	✅ Usuários EMEA na organização Europa, usuários AMER na organização dos EUA com base no campo de região do perfil de usuário. Replicação bidirecional para dados de referência compartilhados (contas, produtos). Os dados regionais permanecem nas respectivas organizações (pedidos, casos). A resolução de conflitos usa os últimos ganhos de gravação com autoridade regional para dados mestre do cliente.
Distribuição geográfica	✅ Os data centers regionais do Hyperforce permitem a distribuição geográfica. Implantação de região única com redundância gerenciada por plataforma suficiente para disponibilidade de 99,9%. Multiorganização entre regiões considerada apenas para requisitos de 99,95%+ ou mandatos de residência de dados regulatórios.
Redundância do sistema externo	✅ As APIs externas críticas têm pontos de extremidade primários e de failover. O interruptor de circuito alterna para o ponto de extremidade de failover quando as experiências principais sofrem falhas. Serviços externos com redundância geográfica preferida a provedores de uma só região para integrações críticas.
Monitoramento de infraestrutura	✅ Trust.salesforce.com monitorado por meio da API de status. Assine notificações de status específicas da instância. A solução responde ao status de integridade da plataforma dinamicamente reduzindo a carga não crítica durante a degradação. O Centro de escala identifica operações com uso intensivo de recursos antes de afetarem a capacidade de redundância.
Automação de fallover	✅ Failover automatizado preferencial em vez de manual para metas de RTO agressivas. As verificações de integridade são executadas a cada 1 a 5 minutos para detectar falhas. A lógica de decisão de fallover evita falsos positivos (requer falha sustentada, não erros temporários). Reverter automatizado se o destino de troca de falha também for insalubre.
Pontos únicos de falha	✅ A revisão da arquitetura identifica todos os pontos únicos de falha. Cada SPOF identificado avaliado para impacto comercial e custo de mitigação. SPOFs de alto impacto mitigados por meio de redundância. SPOFs de baixo impacto aceitos com procedimentos de aceitação e recuperação de risco documentados.
Testar os recursos de redundância	✅ Treinamentos de fallover agendados validam a lógica de fallover automatizada. Sistemas de backup testados sob carga (não apenas em espera ativa). Capacidade da organização secundária validada para lidar com a carga de produção durante testes ativos-pasivos. As lições aprendidas de cada teste melhoram a automação e os procedimentos.

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Pontos únicos de falha	⚡️ Toda a solução depende de uma única API externa sem fallback. O provedor de domínio personalizado é SPOF. Se o provedor falhar, os usuários não poderão acessar o Experience Cloud. Conta de usuário de integração única – se desabilitada, todas as integrações falharão.
Redundância não testada	⚡️ Arquitetura ativa e passiva de várias organizações configurada, mas nunca testada. A organização secundária fica fora de sincronia, mas as verificações de integridade não estão configuradas. A primeira tentativa de fallover ocorre durante um desastre real revelando a organização secundária corrompida ou não funcional.
Lacunas de sincronização de dados	⚡️ Multi-organização ativa-passiva com replicação de CDC configurada para 5 dos 30 objetos críticos. A alteração de falha ocorre, mas a organização secundária não tem 80% dos dados necessários. Monitoramento de atraso de replicação ausente – organização secundária 3 dias depois do principal, mas sem alertas.
Redundância falsa	Presumindo a arquitetura multi-região quando ambas as organizações realmente hospedadas na mesma região do Hyperforce. APIs externas “redundantes” que na verdade usam o mesmo provedor upstream. Vários caminhos de integração que todos percorrem o mesmo único ponto de falha.
Arquitetura estatal	⚡️ A lógica de aplicativo depende do estado na memória que impede a escala horizontal. O servidor de aplicativo único contém todo o estado da sessão do usuário. O reinicialização do servidor desconecta todos os usuários. Recursos estáticos armazenados em cache na memória do aplicativo em vez do Cache da plataforma, criando inconsistência entre servidores.
Nenhum interruptor de circuito	A integração externa falha e cada transação espera um tempo limite total de 120 segundos. Todos os usuários afetados quando um único sistema externo está indisponível. Sem isolamento de falha: uma integração com falha degrada todo o desempenho da plataforma.
Somente failover manual	⚡️ Arquitetura organizacional múltipla com apenas procedimentos de failover manuais. Exige um procedimento de duas horas para iniciar o failover enquanto o negócio está inativo. Verificações de integridade automatizadas não implementadas. A decisão de fallover requer aprovação executiva atrasando a recuperação.
Falha no planejamento de capacidade	⚡️ Organização secundária em arquitetura ativa-pasiva com tamanho para 20% da carga de produção. A alteração de falha ocorre, mas a organização secundária não pode lidar com o tráfego de produção completo. Arquitetura ativa com ambas as organizações com 85% de capacidade, sem redundância quando uma organização falha.
Desvio de configuração	As organizações primárias e secundárias divergem ao longo do tempo porque as implantações não são sincronizadas. Metadados implantados como primários, mas não secundários. A alteração de falha revela uma organização secundária executando uma versão de código de seis meses.
Sobre-engenharia	⚡️ Arquitetura organizacional múltipla com replicação ativa-ativa para ferramentas internas de administração usadas por cinco pessoas. A complexidade operacional de várias organizações não é justificada pela crítica dos negócios. Meta de disponibilidade de 99,999% para relatórios em lote aceitável em 99%.
Mal-entendido geográfico	Presumindo que o Hyperforce “multi-region” forneça recursos de multi-organização automaticamente. Não compreender que uma única organização está sempre em uma única região e que a multi-região requer várias organizações. A redundância baseada em geografia é impossível com a arquitetura de organização única.
Acoplamento de integração	⚡️ Todas as integrações síncronas sem fallback assíncrono. A indisponibilidade do sistema externo bloqueia as operações do usuário. Sem mecanismo de enfileiramento – as transações falham se o sistema externo estiver temporariamente inativo. Os usuários não podem prosseguir quando a integração de suporte estiver indisponível.