Confiabilidade

O Salesforce opera uma infraestrutura resiliente em várias regiões com failover automatizado e resiliência em nível de infraestrutura. A plataforma lida com redundância do data center, disponibilidade de rede e patch de infraestrutura, com o status de disponibilidade da plataforma em tempo real visível em Trust.salesforce.com.

Você projeta a confiabilidade de tudo o que é executado nessa infraestrutura:: os modelos de dados que se escalonam dentro dos limites do controlador, as transações que antecipam e recuperam de falhas, o monitoramento que detecta quando sua solução se desvia das metas de disponibilidade e os procedimentos de recuperação de desastres que restauram operações de negócios quando ocorrem falhas.

O SLA do Salesforce cobre a plataforma, mas você possui a confiabilidade para tudo acima da camada de infraestrutura. Você é responsável por definir e cumprir seus próprios objetivos de nível de serviço (SLOs) – as metas de confiabilidade de que seu negócio precisa. A confiabilidade da camada de aplicativo continua sendo sua responsabilidade, independentemente do nível de SLA da plataforma. A mesma plataforma que garante a disponibilidade também o limita: o controlador limita o consumo de recursos de cada locatário para que nenhum único locatário possa reduzir a plataforma para outros. Portanto, sua solução deve ser dimensionada de maneira consistente dentro desses limites, em vez de simplesmente solicitar mais capacidade.

Soluções não confiáveis podem criar impactos de negócios em cascata. O fluxo de receita fica mais lento quando as plataformas de comércio estão indisponíveis. A produtividade cai quando as ferramentas internas falham no meio do fluxo de trabalho. O Trust é erodido quando os dados são corrompidos ou os registros são perdidos. Esses problemas se complicam ao longo do tempo à medida que as soluções alternativas se acumulam e o débito técnico aumenta.

A confiabilidade não se refere a evitar todas as falhas. Falhas ocorrem em sistemas distribuídos. A confiabilidade é projetar sistemas que antecipam falhas, ajudam a conter o raio de explosão e restauram o serviço automaticamente. Os requisitos de confiabilidade variam de acordo com o impacto dos negócios. Por exemplo, um portal do Experience Cloud voltado para o cliente que requer 99,9% de disponibilidade envolve escolhas arquitetônicas fundamentalmente diferentes de um processo de relatório em lote interno que tolera atrasos ocasionais.

A confiabilidade e a excelência operacional estão profundamente interligadas. Monitoramento de endereço, resposta a incidentes e disponibilidade do sistema. Essa sobreposição é intencional, não acidental. A distinção reside no tempo de design versus o tempo de execução.

A confiabilidade é o que você arquita em um sistema antes de ele ser executado, incluindo:

• os modelos de dados mencionados anteriormente que têm escala dentro dos limites do controlador
• as transações que antecipam e recuperam de falhas
• os disjuntores de redundância e circuito que contêm raio de explosão
• as metas de recuperação (objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO)) que determinam como seu sistema se comporta quando as coisas dão errado.

A confiabilidade é fundamental; é uma propriedade estrutural da sua solução.

Excelência operacional é como você opera, melhora e mantém o sistema depois de ele estar em execução, incluindo:

• as práticas de implementação que reduzem o risco de alteração
• os manuais e os caminhos de escalação que guiam sua equipe durante incidentes
• os pipelines de capacidade de observação que detectam sinais
• os loops de feedback que melhoram o sistema ao longo do tempo.

A Excelência operacional é praticada; é a disciplina humana e de processo que envolve sua solução.

O terreno compartilhado entre os dois pilares é a camada de monitoramento e capacidade de observação. A monitorização é projetada como uma questão de confiabilidade. Você deve criar sistemas observáveis. É prática como uma preocupação de Excelência Operacional. Sua equipe atua com base no que esses sistemas dizem a você. A confiabilidade abrange padrões arquitetônicos em que você cria, como limites de alerta e painéis de saúde. A Excelência operacional abrange como sua equipe responde a sinais, como manuais de execução e resposta à chamada.

Considere esta distinção: A confiabilidade indica "o sistema sobreviverá?" enquanto a Excelência operacional lida com "a sua equipe pode operá-la?" Um sistema perfeitamente confiável operado por uma equipe sem manuais de execução, implantações inconsistentes ou loops de feedback ainda pode falhar na prática. Uma equipe operacionalmente excelente que gerencia um sistema quebradiço e mal projetado será sobrecarregada por incidentes que eles não poderão evitar. Ambos os pilares são necessários e nenhum deles substitui o outro.

A confiabilidade não funciona isoladamente. Conforme descrito nas seções anteriores, a Excelência operacional é seu parceiro mais próximo. Os dois pilares compartilham a camada de capacidade de observação, com Confiabilidade definindo o que você cria em um sistema e Excelência operacional definindo como sua equipe opera. O Trust também requer infraestrutura que resista a ataques e mantenha a integridade dos dados: um sistema não será confiável se puder ser comprometido. A Otimização de recursos evita o esgotamento do limite do regulador, garantindo que a plataforma permaneça confiável em escala. A Otimização de custo balanceia os investimentos de confiabilidade com relação ao valor comercial que eles proporcionam. As metas de disponibilidade justificam a complexidade arquitetônica necessária para alcançá-las. Nenhum único pilar produz uma solução bem arquitetada isoladamente — A confiabilidade fornece a base estrutural que os outros pilares dependem e reforçam.

Use esses princípios para orientar suas decisões de arquitetura quanto à confiabilidade na plataforma.

• Distribuir a carga de trabalho por meio da massificação. Processe vários registros em transações únicas em vez de depender de operações sequenciais por registro. A massificação compartilha os limites do controlador em um lote processado em uma única transação, respeitando esses limites enquanto maximiza a taxa de transferência. Processamento do Apex baseado em coleções, trabalhos em lote com escopo configurável e eventos de plataforma consumidos em massa incorporam esse princípio. Soluções bem massificadas processam 200 registros com o mesmo número de instruções SOQL e DML que um registro no processamento sequencial. Os padrões de carga de trabalho distribuídos fornecem resiliência porque nenhuma falha de registro único afeta o processamento de todo o lote.
• Presuma que tudo falhe. Limites de controlador, janelas de manutenção de plataforma e dependências de integração criam modos de falha relacionados à arquitetura multilocatário do Salesforce. Projete essas falhas específicas da plataforma desde o início. Consultas SOQL excedem os limites de linha sob distorção de dados. O tempo de CPU do Apex pode expirar durante cálculos complexos. Os tempos limite de chamada podem ocorrer conforme os serviços externos são lentos. Os bloqueios de linha DML falham quando transações simultâneas colidem. Os limites de armazenamento podem falhar quando os carregamentos de arquivos aumentam inesperadamente. Os arquitetos que planejam essas falhas criam soluções confiáveis sem intervenção manual. Esses sistemas confiáveis detectam limites de controlador que se aproximam, contêm raio de explosão por meio do gerenciamento de erros e são recuperados automaticamente por meio de estruturas de nova tentativa e eventos de plataforma.
• Construir sistemas de auto-recuperação. Projete soluções que detectam falhas e são recuperadas automaticamente sem intervenção humana. Os eventos de plataforma habilitam padrões de nova tentativa personalizados. A entrega a um assinante pode ser tentada novamente com EventBus.RetryableException, embora a reprodução da transação original exija uma arquitetura personalizada. A manipulação de erros de fluxo direciona exceções a fluxos de recuperação. Os trabalhos em lote do Apex isolam falhas de pedaços - um pedaço com falha não impede o processamento de outros pedaços - permitindo a conclusão parcial do trabalho e novas tentativas direcionadas. Implemente a lógica de nova tentativa explícita usando o rastreamento de erros no AsyncApexJob para recuperação de falha temporária. Aplique backlog exponencial a esses padrões de nova tentativa ao lidar com falhas temporárias. Os sistemas de auto-recuperação mantêm as metas de disponibilidade mesmo durante incidentes fora do horário, quando os respondentes humanos podem estar indisponíveis, reduzindo a carga operacional enquanto melhoram o tempo médio até a recuperação.
• Design para os requisitos de negócios primeiro. Defina objetivos de nível de serviço com base no impacto real dos negócios antes de selecionar soluções técnicas. Nem todos os componentes exigem disponibilidade de cinco nove. Combine o investimento de confiabilidade com a crítica dos negócios e projete uma degradação agradável para recursos de suporte. Metas realistas permitem escolhas de arquitetura adequadas e evitam engenharia excessiva ou entrega insuficiente.
• Validar a recuperação por meio de exercícios. Agende os exercícios de recuperação de desastres que testam a restauração de backup, os procedimentos de failover e os manuais de resposta a incidentes. Restaure um sandbox de Cópia total do backup de produção para validar processos de recuperação. Apresente falhas deliberadas em ambientes de sandbox para confirmar que seu monitoramento detecta problemas e que a recuperação automatizada é executada corretamente. Os detalhes revelam lacunas em procedimentos, ferramentas e manuais de execução antes que os incidentes reais os exponham. Documente os resultados do drill down e acompanhe a remediação de lacunas descobertas. Os testes regulares garantem que os recursos de recuperação permaneçam atualizados à medida que as soluções evoluem e a associação da equipe muda.

Entender o que o Salesforce opera ajuda você a concentrar os esforços de design de confiabilidade no que você controla. A plataforma lida com preocupações de infraestrutura que exigiriam equipes dedicadas em ambientes de TI tradicionais, como:

• Infraestrutura multi-regional e failover: O Salesforce Hyperforce fornece aos data centers regionais uma alteração de falha automatizada dos serviços internos. Ele também fornece várias zonas de disponibilidade dentro de regiões e replicação de dados na camada de infraestrutura. A plataforma lida com redundância e distribuição de fuso de disponibilidade em regiões de forma transparente.
• Compromissos de SLA da plataforma: Níveis de disponibilidade garantidos com remédios contratuais são negociados por cliente. O trust.salesforce.com publica o status da plataforma e o histórico de tempo de atividade em tempo real, mas qualquer garantia de disponibilidade específica e seus remédios vivem no seu acordo negociado. Revise seu contrato e a documentação atual do Salesforce Trust and Compliance para ver os compromissos que se aplicam à sua organização.
• Redundância da infraestrutura: A plataforma mantém servidores redundantes, caminhos de rede, infraestrutura de banco de dados e sistemas de armazenamento. A alteração de falha no nível da infraestrutura ocorre automaticamente durante falhas de hardware sem ação do cliente. Os backups de plataforma protegem contra perda de dados no nível da infraestrutura.
• Manutenção e atualizações da plataforma: As principais versões da plataforma fornecem recursos e correções de segurança com compatibilidade com versões anteriores gerenciadas pelo Salesforce. Janelas de manutenção de plataforma são agendadas e comunicadas em trust.salesforce.com. O patch de infraestrutura acontece de forma transparente, sem o envolvimento do cliente.
• Monitoração de integridade da plataforma principal: O Salesforce monitora o desempenho da infraestrutura, incluindo tempos de resposta do banco de dados, latência da rede, integridade do gateway da API e desempenho do sistema de armazenamento. O status de integridade da plataforma aparece em Trust.salesforce.com e inclui atualizações de incidentes em tempo real. O status específico da instância está disponível por meio da API de status.

Essas operações de plataforma criam a base em que você cria. Você não gerencia data centers, provisionar servidores ou projetar a recuperação de desastres da infraestrutura. Em vez disso, você é responsável pelo que projeta e configura com base nessa base.

O Modelo de responsabilidade compartilhada especifica que você possui a confiabilidade para tudo o que você cria com o Salesforce. A confiabilidade da plataforma habilita seu trabalho, mas não o substitui. Suas responsabilidades de confiabilidade abrangem seis áreas interconectadas:

Objetivos de nível de serviço (SLOs) quantificam os requisitos de confiabilidade em termos mensuráveis. SLOs conectam requisitos de negócios e arquitetura técnica. Antes de selecionar tecnologias ou projetar modelos de dados, estabeleça SLOs que definam o sucesso para cada fluxo de usuário crítico.

SLOs geralmente medem:

• Disponibilidade - porcentagem de tempo em que o sistema está operacional e acessível
• Latency - tempo necessário para concluir operações, medido em percentis (p50, p95, p99)
• Produção - volume de operações concluídas com êxito por unidade de tempo
• Taxa de erro - porcentagem de solicitações que falham ou retornam erros
• Tempo de recuperação - duração necessária para restaurar o serviço após incidentes

Defina SLOs por funcionalidade de negócios em vez de por componente técnico. Os recursos voltados para o usuário exigem SLOs mais rígidos do que processos administrativos ou em lote. Cada SLO deve ser mensurável de modo objetivo usando a instrumentação disponível.

Acordos de nível de serviço (SLAs) são compromissos contratuais com consequências de falha. Qualquer nível de disponibilidade garantida e seus remédios contratuais são negociados por cliente. Revise seu acordo e a documentação atual do Salesforce Trust and Compliance para os compromissos aplicáveis à sua organização.

SLOs de solução devem ser menos rígidos que SLAs de plataforma para preservar o orçamento de erro. Se seu SLA de plataforma e seu SLO de solução tiverem uma meta de 99,9%, qualquer tempo de inatividade de plataforma significativo consumirá diretamente seu orçamento de erro, não deixando margem para falhas na camada de aplicativos, problemas de integração ou manutenção planejada dentro do mesmo período de medida. Um SLO é violado formalmente apenas quando o tempo de inatividade cumulativo esgota todo o orçamento de erro para o período de medida. Se seu SLA e SLO estiverem definidos para a mesma meta, um único incidente de plataforma poderá esgotar totalmente esse orçamento. Por exemplo, quando a plataforma fornece 99,9%, direcione um SLO de solução de 99,5% para manter uma margem significativa para os problemas que você precisa lidar: bugs de aplicativo, falhas de integração e janelas de implementação.

Indicadores de nível de serviço (SLIs) são medidas usadas para avaliar a realização de SLO. Os SLIs devem ser objetivamente mensuráveis, coletados de maneira consistente e vinculados diretamente à experiência do usuário.

Para soluções do Salesforce, os SLIs incluem:

• Tempo de atividade da plataforma via trust.salesforce.com
• Tempo de carregamento de página por meio da análise do Experience Cloud
• Tempo de resposta da API por meio do Monitoramento de evento (que requer o complemento Monitoramento de evento ou Salesforce Shield)
• Taxa de sucesso da transação por meio de registro de aplicativo personalizado
• Concluição do trabalho em lote por meio do monitoramento AsyncApexJob

Metas de disponibilidade mais altas criam um aumento exponencial de complexidade e custo. Entenda as implicações arquitetônicas antes de confirmar as metas:

Evite metas arbitrárias como "cinco para tudo". Em vez disso, avalie o impacto comercial do tempo de inatividade por funcionalidade e defina as metas de acordo. Relatórios em lote internos que toleram sete horas de tempo de inatividade mensal exigem uma arquitetura fundamentalmente diferente do processamento de pedido crítico à receita que requer recuperação em menos de uma hora.

Defina a confiabilidade de uma perspectiva do usuário, em vez de apenas métricas técnicas. Um sistema com 99,9% de tempo de atividade, mas com tempos limite frequentes, falha na confiabilidade baseada na experiência do usuário. Os usuários se preocupam mais com a conclusão bem-sucedida dos fluxos de trabalho do que com o tempo de atividade da API individual.

Projete SLOs que reflitam jornadas do usuário em vez de chamadas à API individuais. Um fluxo de checkout de várias etapas exige que cada etapa seja concluída com sucesso dentro de um tempo aceitável. Meça as taxas de conclusão de fluxo de usuário de ponta a ponta como um indicador de confiabilidade primário. A disponibilidade do componente é necessária, mas insuficiente para a confiabilidade da experiência do usuário.

O Salesforce Hyperforce fornece data centers regionais que permitem a distribuição geográfica. A plataforma lida com a redundância da infraestrutura em regiões, incluindo várias zonas de disponibilidade, failover automático de serviços internos e replicação de dados na camada de infraestrutura. Os SLAs de plataforma refletem essa redundância de infraestrutura.

Para a maioria das soluções, a implantação de região única com redundância gerenciada pela plataforma fornece disponibilidade suficiente. Trust Salesforce Infrastructure para disponibilidade básica e focar a arquitetura de soluções na confiabilidade da camada de aplicativos, incluindo padrões de integração tolerantes a falhas, degradação aprimorada e recuperação automatizada.

A alteração de falha intra-região entre as zonas de disponibilidade é automática e incluída em compromissos de SLA de plataforma padrão – o Salesforce gerencia isso de forma transparente na camada de infraestrutura. A recuperação de desastres entre regiões (fora da região) é uma oferta paga separada e não está incluída por padrão em nenhuma edição padrão. Se os seus requisitos de continuidade de negócios exigirem failover entre regiões, documente essa dependência explicitamente em seu plano de recuperação de desastres para que as partes interessadas entendam a diferença entre a resiliência da plataforma incluída e os recursos de DR entre regiões comprados.

A arquitetura organizacional múltipla fornece o maior isolamento e redundância geográfica, mas multiplica a complexidade operacional, incluindo sincronização de dados, provisionamento de usuários, coordenação de implementação e custos de licença. Reserve padrões de várias organizações para cenários em que os requisitos de negócios justificam claramente a complexidade. Por exemplo, considere um padrão de várias organizações para estes cenários:

• O negócio exige RPO/RTO garantido além dos recursos da plataforma
• Requisitos regulatórios exigem o isolamento de dados geográficos, o planejamento de continuidade de negócios requer total independência de uma única região
• A consolidação da organização é inviável devido aos requisitos de autonomia da unidade de negócios.

Padrão ativo-pasivo: - A organização principal atende todo o tráfego em condições normais. Organizações secundárias em diferentes regiões permanecem sincronizadas, mas ociosas. A alteração de falha ocorre durante uma indisponibilidade da região primária. Essa solução fornece o padrão de várias organizações mais simples, mas deixa a capacidade secundária inutilizada. As camadas de roteamento de DNS ou autenticação de usuário direcionam os usuários para a organização ativa.

Padrão ativo-ativo: - Ambas as organizações atendem o tráfego de produção continuamente. Os usuários são alocados por geografia, unidade de negócios ou tipo de carga de trabalho. Ativo ativo maximiza a utilização de capacidade, mas requer sincronização de dados sofisticada e roteamento de usuário. A resolução de conflitos é crítica quando o mesmo registro é modificado em ambas as organizações.

Projete a sincronização de dados adequada aos requisitos de RPO. Os Eventos de plataforma fornecem streaming de evento quase em tempo real para alterações de dados críticas. A Captura de dados de alteração oferece rastreamento de alteração automático para objetos selecionados com desenvolvimento mínimo. A replicação de API agendada por meio da API em massa 2.0 em intervalos fixos é adequada a dados de referência menos urgentes.

Aplique redundância a camadas de dados, aplicativo e integração para evitar pontos únicos de falha. A redundância em camadas garante que a falha em qualquer camada única não comprometa a disponibilidade geral do sistema.

• Redundância de dados: A plataforma fornece redundância de dados por meio de backups de infraestrutura. Suplemente essa redundância com a replicação no nível do aplicativo quando a empresa precisar de uma recuperação mais rápida do que os procedimentos de restauração de plataforma fornecem. Use a Captura de dados alterada ou eventos de plataforma para replicar dados críticos para armazenamento secundário ou sistemas externos continuamente. Isso habilita a recuperação de corrupção lógica ou de erros de configuração que os backups de infraestrutura não podem corrigir.
• Redundância da aplicação: Projete a lógica de aplicativo sem estado para que qualquer servidor de aplicativo possa processar qualquer solicitação. Evite o estado no lado do servidor que impeça a escala horizontal. Use tipos de metadados personalizados e configurações personalizadas para ajustes que devem estar disponíveis instantaneamente em todos os servidores de aplicativo. O design sem estado permite que um servidor de aplicativo processe solicitações sem depender de um estado de servidor específico.
• Redundância de integração: Projete integrações que toleram a indisponibilidade temporária do sistema externo. Implemente padrões de disjuntor detectando integrações com falha. Enfileire solicitações por meio de Eventos de plataforma quando os sistemas externos estiverem inativos em vez de bloquear operações do usuário. Isso isola falhas do sistema externo da funcionalidade voltada para o usuário.

Monitore a integridade da plataforma do Salesforce usando APIs de status específicas de instância e Trust.salesforce.com. Assine as notificações de status para sua instância para receber alertas sobre incidentes, janelas de manutenção e impactos de desempenho. Os sinais de integridade da plataforma habilitam a resposta proativa em vez de a solução de problemas reativa.

Projete soluções que respondam ao status de integridade da plataforma. Quando o desempenho da plataforma diminui, reduza a carga de processamento em lote não crítica. Adiar trabalhos em segundo plano durante janelas de manutenção usando o monitoramento de trabalho agendado. Desabilite integrações não essenciais para proteger operações críticas voltadas para o usuário durante incidentes. Essa perda de carga dinâmica mantém a confiabilidade para recursos críticos sob estresse.

Use o Centro de escala para identificar transações e operações de execução longa que consomem recursos de plataforma desproporcionados. O Centro de escala fornece visibilidade no nível da transação, permitindo que os arquitetos detectem riscos de confiabilidade antes de se tornarem incidentes voltados para o usuário. A revisão semanal do Centro de escala revela padrões que exigem remediação arquitetônica.

Implemente a detecção de falhas em vários níveis para detectar problemas antes que eles entrem em falhas completas. A detecção em camadas fornece defesa em profundidade contra falhas não detectadas.

Projete limites de alerta que balanceiem detecção antecipada com positivos falsos. Alerte quando as taxas de erro excederem limites ou ocorrer uma degradação sustentada, não em falhas isoladas. Erros únicos são normais em sistemas distribuídos. Os padrões de erros indicam problemas de confiabilidade que exigem atenção.

O controlador do Salesforce limita o consumo máximo de recursos de cada locatário na plataforma multilocatário para que nenhum único locatário possa reduzir o desempenho de outros. Essas não são restrições arbitrárias; são limites arquitetônicos que moldam o design de soluções. Entenda os limites do controlador antes de projetar uma arquitetura confiável. Soluções que se aproximam regularmente dos limites do controlador sob carga normal provavelmente falharão sob estresse.

Limites críticos do controlador que afetam decisões de arquitetura:

Projete transações que sejam concluídas bem dentro dos limites, mesmo sob carga máxima. Crie margem direcionando 70% dos limites do controlador como o limite operacional sob condições normais, reservando 30% para picos inesperados. Essa folga acomoda aumentos temporários de carga, geralmente sem atingir limites rígidos.

Massificação é o padrão de escalabilidade fundamental para o Salesforce. Processe vários registros em uma única transação, em vez de em operações de registro individuais. A massificação reduz o consumo do limite do controlador enquanto aumenta a taxa de transferência. Todos os arquitetos do Salesforce devem dominar os padrões de massificação, pois eles são a base de todas as soluções escalonáveis.

Projete todos os acionadores do Apex, classes em lote e integrações para processar coleções de registro de maneira eficiente. Colete identificadores de registro primeiro e processe todos os registros com instruções de DML e consulta única. Use mapas e conjuntos para pesquisas eficientes em vez de loops aninhados com consultas individuais. O processamento baseado em coleção fornece melhorias de eficiência em ordem de tamanho em abordagens de registro a registro.

A automação acionada por registro deve lidar com 200 registros por invocação de acionador, pois os processos da plataforma acionam a execução em lotes de até 200 registros. As operações do Lightning Data Service são em lote automaticamente, mas os componentes personalizados devem implementar padrões em massa explicitamente ao realizar operações DML.

O processamento assíncrono distribui o trabalho ao longo do tempo, em vez de tentar a conclusão imediata dentro dos limites do controlador de uma única transação. Use padrões assíncronos quando as operações processam grandes volumes de dados que excedem os limites do controlador síncrono, dependem de sistemas externos com tempos de resposta variáveis, podem tolerar conclusão atrasada ou exigir tempo de execução estendido além dos limites de CPU síncrona.

Recursos assíncronos do Salesforce e seu ajuste arquitetônico:

• Apex em lote: Processe grandes volumes de registro em blocos de até 2.000 registros por método de execução. O lote fornece limites de controlador dedicados por bloco e isolamento de falha. Um bloco com falha não impede a conclusão de outros blocos. Isso habilita o sucesso parcial e a nova tentativa direcionada. Implemente a lógica de nova tentativa personalizada para falhas temporárias rastreando intervalos de bloco com falha no objeto AsyncApexJob e enfileirando novamente os trabalhos em lote direcionados. Use lote para migrações de dados, atualizações em massa agendadas e processamento de dados em grande escala. Há no máximo cinco trabalhos em execução ou com execução pendente simultaneamente por organização. Os trabalhos adicionais ficam na fila na Fila Flex do Apex (até 100 trabalhos no status Espera) e são executados automaticamente quando os períodos são abertos.
• Apex enfileirável: Execute trabalhos assíncronos com funcionalidade de encadeamento para habilitar fluxos de trabalho de várias etapas e parâmetros de objeto complexos. O Apex enfileirável compartilha o limite organizacional de DailyAsyncApexExecutions de 250 mil execuções por 24 horas com todos os outros Apex assíncronos – Apex em lote, futuro e agendado – em vez de manter uma alocação específica do Queueable. Use o Apex enfileirável para fluxos de trabalho de orquestração e integração de várias etapas que exigem processamento sequencial com melhor monitoramento do que os métodos @future.
• Eventos de plataforma: Os eventos de plataforma são usados em uma arquitetura de evento de publicação e assinatura que separa os editores dos assinantes. Os eventos são repetidos em uma janela de retenção de 72 horas (3 dias). A retenção estendida além de 72 horas está disponível como um complemento pago: verifique os limites máximos atuais e o status de GA na documentação mais recente de Eventos da plataforma Salesforce antes de se comprometer com obrigações de SLA que dependem da reprodução estendida. Use os Eventos de plataforma para automação acionada por evento, integração entre sistemas e streaming de dados em tempo real. Os Eventos de plataforma fornecem limites assíncronos naturais entre as fases da transação.
• Apex agendado: Execute trabalhos em uma agenda fixa usando expressões CRON por meio de System.schedule(). Um trabalho pode ser agendado para execução no máximo uma vez por hora. Os campos de segundos e minutos CRON devem usar valores fixos, não intervalos. Fique dentro do máximo de 100 trabalhos do Apex agendados por organização consolidando operações semelhantes em classes agendáveis únicas.

Quando os volumes de dados excedem os limites de processamento práticos, mesmo com padrões de massificação e assíncronos, particione os dados entre limites lógicos para habilitar o processamento paralelo. O particionamento de dados converte grandes operações sequenciais em operações paralelas menores que são concluídas mais rapidamente e permanecem dentro dos limites do regulador.

• Particionamento baseado em data: Processe dados em janelas de tempo, incluindo transações deste mês ou casos do último trimestre. Arquive dados históricos em objetos grandes ou armazenamento externo para manter o conjunto de trabalho gerenciável. A maioria das consultas transacionais se concentra nos dados recentes, tornando o particionamento baseado em tempo naturalmente eficiente.
• Particionamento de tipo de registro: Processe diferentes tipos de registro de modo independente, incluindo Casos do parceiro vs. Casos do cliente ou Contas Enterprise vs. Contas SMB. Trabalhos em lote separados por tipo habilitam a paralelização. O tipo de registro costuma estar correlacionado a processos comerciais distintos que justificam o processamento independente.
• Particionamento baseado em proprietário: Distribua o processamento pelo proprietário do registro, como processar as oportunidades de cada região de vendas de modo independente. O particionamento baseado em proprietário é particularmente eficaz quando combinado a um modelo de compartilhamento, pois a segurança é imposta por meio de mecanismos existentes. O particionamento baseado em proprietário habilita a distribuição geográfica da carga de processamento.

Projete os requisitos de capacidade futuros com base no crescimento dos negócios, em vez de reagir para limitar o esgotamento. O planejamento proativo de capacidade evita incidentes de confiabilidade causados pela falta de recursos da plataforma.

• Licenças de usuário - número de pessoas que impulsiona a alocação de chamadas à API e direitos de armazenamento por usuário
• Armazenamento de dados – volumes de transações e políticas de retenção impulsionam o consumo de armazenamento (nomealmente, planeje um crescimento anual de 10 a 20% no mínimo)
• Chamadas de API - contagem de integração e frequência que conduzem a alocação de API 24 horas (cada novo padrão de integração aumenta o consumo recorrente)
• Capacidade de processamento - Contagem de trabalhos em lote e complexidade impulsionam filas de processamento assíncronas e limites de execução simultânea

Use o Proactive Monitoring para avaliar continuamente o uso da capacidade da organização. O Proactive Monitoring detecta riscos de capacidade, incluindo o uso de API se aproximando de picos de limite de solicitação, limites de armazenamento se aproximando e a profundidade da fila de trabalhos em lote cresce além dos níveis sustentáveis. A revisão de capacidade semanal habilita o tempo de processamento de aquisição para licenças ou limites adicionais antes que o impacto comercial ocorra.

Valide pressuposições de escalabilidade por meio de testes de carga antes da implementação da produção. O teste de carga revela problemas de limite do controlador, gargalos de integração e restrições de capacidade invisíveis em testes de desenvolvimento de baixo volume. Teste com volumes de dados em escala de produção e simultaneidade para validar a confiabilidade em condições realistas.

• Teste de volume de dados: Preencha volumes de dados em escala de produção no Full Copy Sandbox para validar o desempenho da consulta com desvio de dados real, profundidade de relacionamento e contagens de registros. Teste com mais de 10 milhões de registros quando a produção atingir essa escala. O comportamento do otimizador de consulta muda dramaticamente à medida que o volume de dados aumenta, o que pode resultar em resultados de Teste de escala pequena enganosos.
• Teste do usuário simultâneo: Simule a carga de usuário simultânea máxima para validar a taxa de transferência e a contenção da transação. Use os testes de escala disponíveis para organizações qualificadas para simular cargas de trabalho de produção em ambientes de sandbox antes da implementação. A execução concomitante revela problemas de bloqueio invisíveis em testes de usuário único.
• Teste de carga da API: Gere volumes de API de pico para validar a escalabilidade da integração, o tratamento de limite de taxa e o comportamento do disjuntor sob carga sustentada. Os testes de carregamento de API revelam se a lógica de nova tentativa e a manipulação de erros funcionam corretamente em condições de estresse.
• Teste de escala: Teste de escala é um produto do Salesforce usado para simular cargas de trabalho de produção em ambientes de Sandbox de Cópia Completa dimensionados para corresponder à capacidade de produção. O Teste de escala é executado em sandboxes de Cópia Completa no Hyperforce. Sua instância de produção não precisa estar no Hyperforce para usá-la. Você cria planos de teste em sua organização de produção enquanto os testes são executados no sandbox. Use Teste de escala para validar o espaço limite do regulador, a taxa de processamento assíncrona e o comportamento de resposta da integração em condições de carga máxima antes das implantações importantes.

A degradação eficiente mantém a funcionalidade principal quando componentes não críticos falham. Projete sistemas priorizando fluxos de usuário críticos em relação a recursos de suporte durante falhas. Nem todos os recursos têm a mesma importância comercial e as arquiteturas devem refletir essas prioridades.

Defina a hierarquia de critérios de recursos:

Essa hierarquia permite que os arquitetos projetem políticas de degradação que mantenham a continuidade dos negócios mesmo durante falhas parciais do sistema. Os usuários preferem funcionalidade reduzida em vez de indisponibilidade completa.

O padrão do disjuntor impede falhas em cascata quando as integrações ficam indisponíveis. Em vez de acumular tempos limite que consomem o tempo de transação e os limites do controlador, detecte padrões de falha e pare de chamar sistemas com falha. Os disruptores de circuito fornecem falha rápida em vez de falha lenta.

O disjuntor de circuito declara:

• Fechado - operação normal, pedidos fluem para o sistema externo conforme projetado
• Aberto - limite de falha excedido, as solicitações falham imediatamente sem tentar chamadas externas, economizando recursos
• Meio aberto - período de teste de recuperação, solicitações limitadas sondar sistemas externos para detectar recuperação antes de fechar completamente o circuito

Implemente os disruptores de circuito usando o Cache da plataforma para armazenar o estado do circuito acessível em todas as transações. Use Eventos de plataforma para transmitir alterações de estado em toda a organização. A lógica do disjuntor verifica o estado antes de tentar chamadas externas, evitando limites de chamadas desperdiçadas em sistemas com falha conhecida.

Falhas temporárias são normais em sistemas distribuídos. Interrupções de rede, indisponibilidade temporária de serviço e respostas de limite de frequência costumam ser resolvidas em segundos. Implemente uma lógica de nova tentativa que repita operações com falha após atrasos progressivos em vez de falhar imediatamente.

Retroceder exponencialmente evita novas tentativas que sobrecarregam os sistemas de recuperação. Uma primeira nova tentativa pode ocorrer após 1 segundo, uma segunda após 2 segundos, uma terceira após 4 segundos e uma quarta após 8 segundos. Limite o atraso máximo em 30 a 60 segundos, independentemente do crescimento exponencial. Esse padrão de desvio dá aos sistemas com falha tempo para recuperar enquanto limita a duração total da nova tentativa.

Combine a estratégia de nova tentativa ao tipo de falha.

• Tempo limite de rede: Tente novamente com um retorno curto (a operação pode não ter alcançado o servidor)
• Erros de limite de frequência (429): Tente novamente após o valor do cabeçalho Tentar novamente depois ou após o tempo de redefinição do limite de frequência
• Erros do servidor (5xx): Tente novamente com pendências exponenciais, pois o servidor pode estar temporariamente sobrecarregado
• Erros do cliente (4xx exceto 429): Não tente novamente; corrija a solicitação, pois o erro indica entrada inválida
• Erros de limite do governador: Não tente novamente na mesma transação; coloque novamente na fila como uma operação assíncrona com limites dedicados, por exemplo, publicando um evento de falha que um assinante assíncrono reprocessará com pendências sob novos limites de transação

As estratégias de fallback definem abordagens alternativas quando os métodos primários falham, permitindo a operação contínua em condições degradadas.

• Fonte de dados alternativa: Recupere dados da sessão de cache da plataforma ou de uma partição da organização quando a API em tempo real estiver indisponível. Preencha previamente o cache durante operações bem-sucedidas. O cache fornece dados obsoletos, mas disponíveis, o que é melhor do que a falha completa para muitos casos de uso.
• Comportamento padrão: Aplique regras de negócio padrão quando um serviço de aprimoramento ou personalização estiver indisponível. Processe com valores padrão e sinalize para aprimoramento quando o serviço for recuperado. O comportamento padrão mantém a taxa de transferência ao custo da precisão reduzida.
• Processo manual: Habilite a conclusão da operação manual quando a automação falhar. Forneça uma interface de administrador para concluir transações persistentes. O fallback manual evita a perda de dados e mantém a continuidade dos negócios quando a automação é prejudicada.
• Fila para repetição: Armazene operações em eventos de plataforma ou objetos de fila personalizados para processamento quando um sistema externo for recuperado. A repetição de evento de plataforma com retenção padrão de 72 horas permite a recuperação do assinante após falhas temporárias, sem perda de dados.

Configure tempos limite adequados para todas as chamadas de integração. O Salesforce impõe um tempo total de chamada de 120 segundos por transação. Ordem dessa vez em todas as chamadas em uma única transação para evitar esgotar o tempo da transação em conexões pendentes.

Considerações sobre design de tempo limite:

• Chamadas síncronas voltadas para o usuário: Use no máximo de 5 a 10 segundos para manter a IU responsiva, pois os usuários tendem a não esperar mais
• Chamadas assíncronas em segundo plano: Use 30 a 60 segundos para acomodar o desempenho externo variável sem o usuário aguardar
• Chamadas de processamento em lote: Use os 120 segundos filos permitidos quando nenhum usuário estiver esperando por uma resposta
• Múltiplas chamadas por transação: Ordem do tempo total em todas as chamadas, como três chamadas a 10 segundos, cada uma consumindo 30 segundos do seu orçamento de 120 segundos.

Tempos limite mais curtos falham mais rapidamente, permitindo que estratégias de fallback se engajem mais cedo. Tempo limite mais longo aumenta a taxa de sucesso para sistemas externos lentos, mas funcionais. As considerações de equilíbrio são baseadas em se o usuário está aguardando uma resposta e na disponibilidade de estratégias de fallback.

Projete o tratamento de erros abrangente para transformar falhas de travamentos em degradação gerenciada:

• Fale rápido: Valide entradas e pré-condições em pontos de entrada. Verifique o consumo do limite do regulador antes de operações caras. Detecte falhas imediatamente em vez de propagar o estado inválido por meio de várias camadas de processamento. A detecção antecipada reduz o raio de explosão e simplifica a depuração.
• Fail graciosamente: Mantenha os recursos do usuário mesmo quando as operações falharem parcialmente. Se 3 de 200 registros no lote falharem na validação, processe os 197 registros bem-sucedidos e relate as três falhas em vez de falhar em todo o lote. O sucesso parcial é melhor que a falha total para operações em lote.
• Fail informativamente: Registre erros com ID da transação, contexto do usuário, parâmetros de entrada e rastreamento de pilha. Contexto de erro insuficiente é o principal obstáculo à rápida resolução de incidentes. Cada log de erro deve permitir que o respondente entenda o que falhou, por quê e como reproduzir.
• Fale com segurança: Certifique-se de que falhas não comprometam a integridade ou a segurança dos dados. Reverta transações parciais em vez de deixar os dados em um estado inconsistente. Nunca exponha detalhes de erro interno aos usuários finais, pois os rastreamentos de pilha revelam detalhes de implementação úteis para os invasores.

O Objetivo de tempo de recuperação define o tempo de inatividade máximo aceitável após o desastre. A RTO conduz decisões arquitetônicas sobre automação de fallover, frequência de backup e investimento em testes de recuperação. Diferentes recursos de negócios justificam diferentes investimentos de RTO. Como RTO é o tempo de inatividade que seus usuários experimentam diretamente, um alvo perdido se traduz em interrupções prolongadas e erosão da Trust do cliente.

A RTO varia de acordo com a funcionalidade dos negócios:

Defina o RTO por recurso antes de projetar a arquitetura de recuperação de desastres. A RTO forma a seleção de tecnologia, o investimento em automação e o ritmo de teste. Metas de RTO mais agressivas exigem maior investimento em automação e redundância.

O Objetivo do ponto de recuperação define a janela de perda de dados máxima aceitável medida no tempo. A RPO determina a frequência de backup, a estratégia de replicação e os padrões de sincronização. Um RPO mais rígido requer replicação de dados mais frequente, aumentando a complexidade e o custo. Como RPO é a perda de dados que sua empresa absorve, uma meta perdida pode significar transações perdidas e lacunas não recuperáveis em seus registros.

Equilibre os requisitos de RPO em relação ao custo e à complexidade. RPO quase zero requer replicação de dados contínua com investimento significativo em infraestrutura. O backup diário fornece RPO de 24 horas com o mínimo de complexidade. A maioria das organizações pode tolerar alguma perda de dados para dados não financeiros.

A redundância da infraestrutura da plataforma protege contra falhas de infraestrutura, mas replica os resultados de erros do usuário, implantações com defeito e defeitos de integração, que causam a maioria da perda de dados. Há backups para se recuperar dessas falhas de camada de aplicativo, não para compensar a confiabilidade da plataforma. Implemente estratégias de backup abrangendo dados, metadados e arquivos, pois cada uma requer diferentes abordagens de backup:

• Backups de dados: Implemente uma estratégia de backup abrangente que lida com dados e metadados. Exporte dados de objeto críticos usando o Serviço de exportação de dados nativo, a cada 7 dias nas edições Enterprise, Performance e Unlimited; a cada 29 dias nas edições Professional e inferiores. Os arquivos de exportação ficam disponíveis por 48 horas após o envio do email de notificação, sem incluir fins de semana, antes da exclusão automática. Configure um processo de download automatizado para que os arquivos não sejam perdidos permanentemente. Use a API de metadados e o Salesforce CLI (recuperação de projeto sf) para configurar a organização de controle de versão, código personalizado e automação declarativa em um sistema de controle de código-fonte como o Git. Trate o backup de metadados como parte de seu pipeline CI/CD padrão. Complemente o backup de dados com serviços dedicados de backup e recuperação, como Propriedade para restauração pontual, recuperação granular em nível de registro e retenção além do ritmo de exportação nativo. A exportação nativa de dados não oferece suporte à restauração de ponto no tempo, e ferramentas de terceiros são necessárias se sua RTO/RPO exigir janelas de recuperação granulares. Teste os procedimentos de restauração regularmente; um backup que nunca foi restaurado é uma pressuposição não testada.
• Backups de metadados: Controle as versões de todos os metadados usando o formato de origem Salesforce DX nos repositórios do Git. O controle de versão de metadados habilita a restauração rápida da configuração após corrupção ou alterações inadvertidas. Todas as implantações devem ser reprodutibles do controle de origem. Metadados no Git fornecem recuperação de ponto no tempo para configuração.
• Backups de arquivo: Exporte registros, anexos e documentos ContentVersion para armazenamento externo. O Salesforce funciona melhor para dados ativos, não para arquivamento de arquivos de longo prazo – exporte arquivos para armazenamento externo para retenção regulatória. Implemente a exportação automatizada de arquivos para requisitos de retenção regulatórios que excedem os recursos da plataforma.
• Validação: Restaure periodicamente backups para organizações teste ou para sandboxes do desenvolvedor para validar os procedimentos e a integridade do backup. Os backups não testados costumam falhar quando necessário devido ao escopo de backup incompleto ou arquivos corrompidos. Agende a validação de restauração trimestral para detectar problemas antes de ocorrerem desastres. Monitore a atualidade do backup além de restaurar a validação. Alerte quando o backup de sucesso mais recente é mais antigo que seu ritmo esperado, por exemplo, quando uma exportação semanal não foi concluída em mais de oito dias. Com essa validação, um trabalho de backup com falha silenciosa aparece imediatamente, em vez de no próximo detalhamento.

Projete a replicação adequada aos requisitos de RPO e organizações múltiplas:

• Captura de dados de alteração (CDC): Assine eventos de alteração para objetos rastreados. O CDC fornece eventos de criação, atualização, exclusão e cancelamento de exclusão com valores de campo alterados. Fornece replicação quase em tempo real com esforço mínimo de desenvolvimento para objetos com suporte, incluindo padrão e personalizados. Sujeito à alocação de entrega diária com base na edição.
• Eventos de plataforma: Arquitetura de evento personalizada para replicar eventos comerciais e alterações de estado. Mais flexível do que a CDC que dá suporte a cargas úteis personalizadas e estruturas de evento complexas, mas requer lógica de publicação explícita em acionadores ou processos. O padrão da janela de repetição de 72 horas habilita a recuperação de falhas temporárias do assinante.
• Replicação de API agendada: A replicação da API de agenda é a extração em lote por meio da API 2.0 em massa em uma agenda fixa. É a implementação mais simples com um RPO igual à frequência de extração. A replicação de API agendada é adequada para dados não críticos em que a execução quase em tempo real é desnecessária, como com dados de referência ou análise histórica.
• Replicação orquestrada pelo MuleSoft: Para topologias de replicação complexas de vários sistemas, a MuleSoft Anypoint Platform fornece orquestração, transformação e monitoramento. Seu uso é adequado para replicação entre o Salesforce e vários sistemas externos, o que requer roteamento sofisticado e lógica de transformação.

Teste a recuperação de desastres com exercícios agendados que validam pessoas, processos e tecnologia juntos:

• Exercícios de tabuleiro: A equipe percorre cenários de desastre, discutindo papéis e pontos de decisão sem falha real. Essa atividade tem baixo custo e revela lacunas processuais e falhas de comunicação. Realize exercícios de Tabuleiro regularmente para manter a preparação da equipe à medida que a equipe muda.
• Failover parcial: - Teste procedimentos de recuperação específicos, como restauração de metadados do controle de origem, restauração de dados do serviço de backup ou atualização de sandbox. Isso valida procedimentos técnicos com impacto comercial limitado. Realize regularmente, alternando quais procedimentos são testados para cobrir todos os recursos de recuperação anualmente.
• Furificação de failover completa: A alteração de falha completa é a alteração de falha completa para o ambiente de recuperação de desastres com redução de tráfego de produção. Ela oferece a maior confiança, mas requer coordenação de negócios e comunicação com o usuário. Realize esse detalhamento anualmente para sistemas críticos. O detalhamento de failover completo valida todo o recurso de recuperação, incluindo procedimentos de corte e comunicação do usuário.

Documente as lições aprendidas após cada detalhe. Atualize os manuais com base nas descobertas. Os recursos de recuperação podem ser reduzidos à medida que as equipes mudam e as soluções evoluem. Trate a documentação de DR como artefatos vivos que exigem manutenção regular, em vez de entregas únicas.

A continuidade dos negócios vai além da recuperação técnica para incluir pessoas, processos e dependências do fornecedor:

• Disponibilidade da equipe: Documente os procedimentos de escalação e o pessoal de backup para papéis críticos. Garanta que não haja nenhum ponto de falha no Knowledge operacional. Os responsáveis principais podem estar indisponíveis durante desastres, o que torna a equipe de backup crítica.
• Procedimentos de comunicação: Defina como os incidentes são comunicados a usuários, clientes e executivos. Estabeleça canais de comunicação que funcionem quando ferramentas principais (por exemplo, páginas de status externas ou sistemas de notificação por SMS), incluindo o Salesforce em si, estiverem indisponíveis.
• Dependências do fornecedor: Mapeie dependências de fornecedor externas essenciais para a operação da solução. Documente caminhos de escalação e SLAs contratuais para cada fornecedor crítico, incluindo Salesforce, parceiros de integração e provedores de pacote de ISV. Entenda, por exemplo, quais fornecedores oferecem suporte 24 horas por dia, 7 dias por semana, e quais têm suporte somente em horário comercial que afeta o tempo de recuperação.
• Obligações regulamentares: Identifique os requisitos de notificação acionados por indisponibilidades estendidas. Serviços financeiros, serviços de saúde e contratos do governo costumam exigir a notificação de incidentes dentro de períodos específicos. A não conformidade pode criar riscos regulatórios e legais, ambos com impacto de desastre complexo.

Defina um modelo de saúde que agrega vários sinais no status geral de saúde do sistema. Os modelos de saúde apresentam o status operacional em uma visão geral, sem exigir a análise de métricas detalhadas. Por exemplo:

Projete painéis de integridade que mostrem o status operacional imediatamente. O status de integridade orienta a resposta operacional, incluindo operações normais sob o status verde, monitoramento aprimorado sob o status amarelo e resposta ativa a incidentes sob o status vermelho.

Os sinais de status da plataforma (coberto anteriormente em Monitoramento de integridade da plataforma) revelam quando a infraestrutura do Salesforce é degradada, mas não como sua própria solução está se saindo.

Aumente esses sinais com a capacidade de observação específica da solução:

• Monitoramento de evento: O Monitoramento de evento inclui registros detalhados que capturam chamadas à API, visualizações de página, exportações de relatórios, atividade de login e execução do Apex. Os objetos EventLogFile fornecem registros com frequência de 24 horas (diariamente) ou 1 hora – a entrega por hora requer o complemento Monitoramento de evento ou Salesforce Shield. A retenção pode ser configurada até 365 dias por meio de Configuração, mas a retenção estendida requer o Salesforce Shield ou o complemento Monitoramento de evento Sem um complemento, os arquivos de log são retidos por 1 dia. Encaminhe eventos para um sistema externo de Gerenciamento de eventos e informações de segurança (SIEM) ou para uma plataforma de agregação de registro para correlação, alerta e retenção além dos limites nativos. Use o Monitoramento de evento para detectar padrões de consumo de API anormais, identificar processos do Apex inativos e auditar o acesso a dados em ambientes regulados.
• Centro de escala: O Centro de escala fornece visibilidade no nível da transação de operações de execução longa, contenção de bloqueio de linha e transações com uso intensivo de recursos. O Centro de escala permite que os arquitetos identifiquem riscos de confiabilidade de padrões de transação específicos antes que eles causem incidentes voltados para o usuário. As análises semanais podem revelar oportunidades de otimização.
• Proactive Monitoring: O Proactive Monitoring permite a avaliação contínua da integridade da organização, detectando riscos de desempenho e escalabilidade. O Proactive Monitoring fornece alertas sobre picos de limite de solicitações de API, falhas de execução do Apex simultâneas, problemas de limite de linha SOQL e tendências de consumo de armazenamento. Ele está disponível para clientes com um direito de Signature Success (anteriormente, Suporte de assinatura) – não é um recurso de autoatendimento incluído nas edições padrão.

Monitore o desempenho do aplicativo da perspectiva do usuário, em vez de da perspectiva da infraestrutura:

• Monitoramento de usuário real (RUM): Meça a experiência real do usuário por meio da análise do Experience Cloud ou de uma instrumentação personalizada. RUM captura a latência real, refletindo condições reais de rede, desempenho do dispositivo e distribuição geográfica. O monitoramento sintético não pode replicar essa variabilidade.
• Monitoramento sintético: Execute transações automatizadas periodicamente de vários locais para validar a disponibilidade e o desempenho. O monitoramento sintético detecta problemas antes que os usuários os relatem. Implemente monitoramento sintético usando o Apex agendado, execute operações críticas e relate resultados com Eventos de plataforma.
• Rastreamento de transação: Instrumente operações complexas de várias etapas para capturar o tempo por etapa. Em seguida, identifique qual etapa no fluxo de trabalho de cinco etapas introduz a latência. Não trate todo o fluxo como uma caixa negra. O tempo no nível da etapa revela oportunidades de otimização invisíveis em métricas agregadas.

Monitore todas as integrações externas usando taxas de erro, percentis de latência e taxa de transferência. Falhas de integração são uma causa principal de incidentes de confiabilidade:

• Taxa de erro - A porcentagem de chamadas que retornam erros (alvo: <1% para integração saudável)
• Latency - O tempo de resposta medido em p50, p95, p99 (defina o SLO por integração com base no orçamento de tempo limite)
• Taxa de tempo limite - O percentual pelo qual o tempo limite configurado (alvo: <0,1%) é excedido
• Estado do disjuntor - O estado aberto indica falha contínua que requer atenção imediata
• Profundidade da fila - Para integrações assíncronas, a fila crescente indica que o processamento está atrás da taxa de produção

Registre todas as chamadas de integração com ID da solicitação, ponto de extremidade, código de resposta e duração. Esses dados permitem uma análise de causa raiz rápida quando falhas de integração afetam a confiabilidade. Os registros de integração devem habilitar a agregação e a análise de tendência.

Projete alertas para problemas antes que os usuários sejam afetados, habilitando respostas proativas:

• Alertas acionáveis: Cada alerta tem uma ação de resposta definida e um respondente atribuído. Alertas sem resposta clara criam fadiga e ocultam sinais críticos. O design de alertas deve abranger quem responde, o que ele verifica e como ele remedia.
• Uma urgência adequada: Publique pessoal sob chamada sobre falhas que afetam o usuário. Envie email para desempenho reduzido. Inclua problemas em um resumo diário para capturar tendências relacionadas. Urgência sem correspondência cria fadiga de alerta devido a escalonamento excessivo ou incidentes perdidos devido a escalonamento insuficiente.
• Notificações repletas de contexto: Inclua o limite cruzado, o valor atual, a tendência recente e um link para um painel ou manual relevante. Permita que os respondentes iniciem o diagnóstico imediatamente sem coletar contexto. Cada alerta deve incluir informações suficientes para triagem sem consultas adicionais.
• Supressão de tempestade: Quando vários sistemas falham ao mesmo tempo, suprimir alertas redundantes. Um alerta indicando a falha da plataforma de integração é mais acionável do que 50 alertas de falha de integração individuais ocultando a causa-raiz.

A detecção de anomalia identifica padrões incomuns e pode indicar problemas emergentes invisíveis para alertas de limite estático:

• Anomalias de volume: Volumes de transações significativamente acima ou abaixo dos padrões diários esperados podem indicar processos inativos ou problemas de acesso do usuário.
• Anomalias de taxa de erro: Taxas de erro elevadas em comparação às linhas de base da última semana no mesmo momento capturam uma degradação gradual antes de uma violação de limite ocorrer.
• Anomalias de latência: Os tempos de resposta que se desviam para cima em vários dias indicam saturação de capacidade ou regressão de desempenho.
• Anomalias comportamentais: Padrões de login incomuns, picos de uso de API inesperados e trabalhos em lote em execução fora de janelas agendadas podem indicar uso suspeito.

Para clientes com o direito de Signature Success, o Proactive Monitoring fornece detecção de anomalia no nível da plataforma sem configuração adicional. Suplemente-o com a detecção de anomalia específica do aplicativo para SLIs personalizados exportados para plataformas de análise externas. Use sinais de anomalia para orientar a investigação em vez de acionar uma escalação imediata, pois a detecção de anomalia tem taxas de falsos positivos mais altas do que os alertas de limite.

Use essa lista de verificação durante revisões de arquitetura, antes da implementação de produção e periodicamente para avaliação de confiabilidade contínua.

Objetivos de confiabilidade e SLOs

• Defina SLOs para todos os fluxos de usuário críticos antes do início do projeto
• Estabelecer SLIs mensuráveis vinculados à experiência do usuário, não apenas métricas de infraestrutura
• Defina metas de disponibilidade realistas com base na análise de impacto de negócios, não em metas arbitrárias
• Garanta que os SLOs de solução sejam menos rígidos que os SLAs de plataforma para fornecer orçamento de erro
• Metas e fundamentos de disponibilidade do documento em registros de decisão de arquitetura

Arquitetura de alta disponibilidade

• Projetar redundância em camadas de dados, aplicativo e integração
• Monitore a integridade da plataforma por meio do Trust.salesforce.com e da API de status da instância
• Implementar verificações de integridade do aplicativo independentemente do status da plataforma
• Considere a arquitetura de várias organizações apenas quando os requisitos de negócios justificarem claramente a complexidade
• Projete o failover automatizado com manuais testados para padrões de várias organizações

Escalabilidade e planejamento de capacidade

• Projete transações concluídas dentro de 70% dos limites do controlador sob carga normal
• Implemente padrões de massificação em todos os acionadores do Apex, classes em lote e integrações
• Usar processamento assíncrono para operações que excedem limites síncronos
• Integre todas as integrações de API em lote em vez de fazer chamadas de registro individuais
• Realizar testes de carga com volumes de dados em escala de produção antes da implantação
• Monitore a utilização de capacidade por meio da API OrgLimits ou do Apex personalizado e alerte conforme o consumo se aproxima do limite operacional de 70%.
• Requisitos de capacidade do projeto com base nas expectativas de crescimento de 12 meses
• Particione dados de alto volume por data, tipo de registro ou proprietário para habilitar o processamento paralelo quando os volumes excederem limites sequenciais

Tolerância a falhas e resiliência

• Projete degradação aprimorada com níveis de crítica de recurso definidos
• Implementar quebradores de circuito para todas as integrações do sistema externo
• Aplicar lógica de nova tentativa com fallos exponenciais para falhas temporárias
• Configure tempos limite adequados ao tipo de operação (5 a 10s voltado para o usuário, 30 a 60s assíncrono)
• Projete estratégias de fallback usando o Cache da plataforma e padrões baseados em fila
• Implementar tratamento de erro estruturado com contexto de diagnóstico suficiente

Recuperação de desastres e Continuidade dos Negócios

• Definir RTO e RPO por funcionalidade de negócios antes do design
• Implementar backup automatizado para dados, metadados (controle de origem) e arquivos
• Validar procedimentos de restauração de backup trimestralmente em ambientes que não sejam de produção
• Monitore a atualidade do backup e alerte quando um backup agendado vence
• Projete uma estratégia de replicação de dados que corresponda aos requisitos de RPO
• Realizar testes de recuperação de desastres anualmente (trimestralmente no tablet)
• Documentar procedimentos de continuidade de negócios, incluindo caminhos de escalação do fornecedor

Monitoramento e observabilidade

• Defina um modelo de saúde agregando sinais de serviço, integração, dados e capacidade
• Assinar notificações de status de plataforma para sua instância do Salesforce
• Implementar monitoramento de usuário real para fluxos críticos do Experience Cloud
• Monitore a integridade da integração com taxa de erro, latência e estado do disjuntor
• Projete alertas acionáveis com procedimentos de resposta e propriedade definidos
• Encaminhe dados do Monitoramento de evento para plataformas externas para retenção e análise de longo prazo
• Use o Proactive Monitoring and Scale Center para avaliação contínua de risco de confiabilidade
• Aplicar detecção de anomalia para padrões de volume, taxa de erro e latência para capturar a degradação que limites estáticos perdem

Compartilhe seu feedback sobre o Framework bem-construído.