Padrões de disponibilidade e desempenho
Saiba mais sobre a confiabilidade bem criada → Arquitetura de alta disponibilidade
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Análise de impacto de negócios | ✅ SLOs definidos por funcionalidade de negócios (por exemplo, “Fluxo de fechamento de oportunidade: Disponibilidade de 99,9%, latência p95 em menos de 2 segundos”) em vez de por componente técnico |
| Documentação do fluxo do usuário | ✅ Cada fluxo de usuário crítico tem SLO mensurável cobrindo disponibilidade, latência, taxa de transferência, taxa de erro e tempo de recuperação vinculado à experiência real do usuário |
| Registros de decisão de arquitetura | ✅ Metas de disponibilidade com base na análise de impacto de tempo de inatividade de negócios com justificativa documentada (por exemplo, relatório de lote interno de 99% vs. processamento de pedido crítico para receita de 99,95%) |
| Especificações de SLO | ✅ Metas realistas considerando a complexidade arquitetônica (99% = funcionalidades de plataforma padrão, 99,5% = redundância básica e monitoramento ativo, 99,9% = reconhecimento de várias regiões e fallover automatizado, 99,95% = padrões ativos e testes de caos, 99,99% = arquitetura de várias organizações) |
| Documentação da plataforma | ✅ SLOs de solução menos rígidos que SLAs de plataforma (por exemplo, SLA de plataforma 99,9% → SLO de solução 99,5%) fornecendo orçamento de erro para falhas na camada de aplicativos |
| Configuração de monitoramento | ✅ Indicadores de nível de serviço (SLIs) mensuráveis de modo objetivo por meio da instrumentação da plataforma: tempo de atividade Trust.salesforce.com, análise do Experience Cloud, tempo de resposta da API de Monitoramento de evento, conclusão do AsyncApexJob |
| Métricas de experiência do usuário | ✅ SLOs refletem jornadas completas do usuário (por exemplo, “Fluxo de envio de caso: todas as cinco etapas concluídas em 8 segundos para usuários p95”) não tempo de atividade de API individual |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Documentação da arquitetura | ⚡️ “O sistema deve ser rápido e confiável” (não mensurável, não determina decisões de arquitetura) |
| Especificações de SLO | ⚡️ “Tudo precisa de tempo de atividade de 99,999%” (custo injustificado ignorando as diferenças de crítica de negócios entre operações de receita e ferramentas internas de administração) |
| Estratégia de monitoramento | ⚡️ Monitoramento de CPU de infraestrutura como SLI principal (os arquitetos de métrica de plataforma não podem agir, não refletindo a experiência voltada para o usuário) |
| Planejamento de capacidade da plataforma | ⚡️ O SLO da solução corresponde exatamente ao SLA da plataforma em 99,9% (sem orçamento de erro para problemas de camada de aplicativo, falhas de integração ou manutenção planejada) |
| Documentação de SLO | SLOs definidos por componente técnico, em vez de por funcionalidade de negócios voltada para o usuário (disponibilidade do componente necessária, mas insuficiente para a confiabilidade da experiência do usuário) |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Estratégia de implementação regional | ✅ Implantação de região única com redundância do Hyperforce gerenciada por plataforma (várias zonas de disponibilidade, failover automático da infraestrutura) fornece 99,9% de SLO para a maioria das soluções |
| Arquitetura de várias organizações | ✅ Padrões de várias organizações apenas quando os negócios exigem RPO/RTO garantido além dos recursos da plataforma, isolamento de dados geográficos regulatórios ou independência regional completa (ativo-pasivo ou ativo-ativo com sincronização de dados) |
| Replicação de dados | ✅ Captura de dados de alteração para dados críticos (RPO quase em tempo real, minutos), Eventos de plataforma para eventos de negócios quase em tempo real, extração agendada da API 2.0 em massa para dados de referência (24 horas de RPO) |
| Monitoramento de integridade da plataforma | ✅ Assinatura de notificações de status Trust.salesforce.com e APIs de status específicas de instância que permitem uma resposta proativa a incidentes, janelas de manutenção e impactos no desempenho |
| Gerenciamento de carregamento dinâmico | ✅ As soluções respondem ao status de integridade da plataforma reduzindo o processamento em lote não crítico durante a degradação, adiando trabalhos em segundo plano durante janelas de manutenção |
| Uso do Centro de escala | ✅ Revisão semanal do Centro de escala identifica transações e operações de execução longa que consomem recursos desproporcionados, habilitando a remediação arquitetônica antes do impacto do usuário |
| Camadas de detecção de falha | ✅ Detecção multinível: falhas de plataforma por meio da API de status, falhas de integração por meio do monitoramento de tempo limite, falhas de aplicativos por meio do registro de exceção, degradação do desempenho por meio de percentis de latência, avisos de capacidade por meio do Proactive Monitoring |
| Limites de alerta | ✅ Alertas são acionados em padrões de taxa de erro (por exemplo, cinco tempos limite de API em 60 segundos) ou degradação sustentada, não falhas isoladas que são normais em sistemas distribuídos |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Design de várias organizações | ⚡️ Arquitetura multifator implementada “apenas no caso” sem exigência de negócios documentada justificando a complexidade operacional da sincronização de dados, provisionamento de usuários e coordenação de implementação |
| Monitoramento de integridade da plataforma | Ignore as notificações de status Trust.salesforce.com, descubra janelas de manutenção quando os usuários relatam falhas (resposta reativa em vez de proativa) |
| Detecção de falha | ⚡️ Alerta sobre cada erro individual, independentemente da taxa (gerará fadiga de alerta ocultando sinais críticos); o tempo limite de API único acionará a páginaout (reacção excessiva ao comportamento normal do sistema distribuído) |
| Replicação de dados | ⚡️ Sem monitoramento específico da integração, apenas descobre falhas de integração quando os usuários relatam operações bloqueadas (falta de visibilidade da integridade do sistema externo) |
| Estratégia de redundância | Chamada síncrona para serviço de aprimoramento externo sem tempo limite ou fallback (usuário bloqueado quando o serviço externo está lento ou indisponível) |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Monitoramento de usuário real (RUM) | ✅ Latência real do usuário medida por meio de análise do Experience Cloud ou instrumentação personalizada refletindo condições reais de rede, desempenho do dispositivo, distribuição geográfica |
| Monitoramento sintético | ✅ Transações automatizadas de vários locais validando a disponibilidade e o desempenho antes de os usuários relatarem problemas (por exemplo, envio de pedido a cada 15 minutos de três regiões) |
| Rastreamento de transação | ✅ Operações de várias etapas instrumentadas com o tempo por etapa para identificar gargalos (por exemplo, as chamadas de validação de endereço da etapa 3 representam 70% da latência total) |
| Otimização de consulta | ✅ Consultas seletivas com filtros indexados, consultas de relacionamento reduzindo viagens de ida e volta, consideração do otimizador de consulta com volumes de dados em escala de produção (o comportamento muda dramaticamente com 10M+ registros) |
| Utilização do Cache da plataforma | ✅ Partições de cache da sessão ou da organização que apresentam dados de referência acessados com frequência, preenchidos previamente durante operações bem-sucedidas, fornecendo dados obsoletos, mas disponíveis, quando a API em tempo real não está disponível |
| Configuração de tempo limite | ✅ Chamadas síncronas voltadas para o usuário de 5-10 segundos (IU responsiva), chamadas assíncronas em segundo plano de 30-60 segundos (desempenho externo variável), processamento em lote de 120 segundos (sem espera do usuário); orçamento total em várias chamadas por transação |
| Monitoramento de latência de integração | ✅ percentuais de latência p50/p95/p99 por integração com SLO por ponto de extremidade; anomalias de latência (tempos de resposta deslizando para cima) indicam saturação de capacidade antes da falha completa |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Estratégia de monitoramento | Monitore apenas métricas de infraestrutura (CPU do servidor, largura de banda da rede) sem medição de fluxo voltada para o usuário (as métricas não refletem a experiência real do usuário) |
| Estratégia de cache | ⚡️ Sem utilização de Cache da plataforma para dados de referência acessados com frequência (consultas repetidas para os mesmos dados, aumentando a latência e consumindo limites de SOQL) |
| Configuração de tempo limite | Chamada de Fluxo síncrono com tempo limite de 120 segundos fazendo o usuário olhar para o spinner de carregamento por 2 minutos (deve usar tempo limite de 5-10 segundos com fallback) |
| Teste de desempenho | Teste em pequena escala com volumes de dados mínimos (o comportamento do otimizador de consulta muda dramaticamente em 10M+ de registros, tornando resultados em pequena escala enganosos) |
| Design de integração | ⚡️ Sem rastreamento no nível da transação de fluxos de trabalho de várias etapas (etapa de gargalos invisível em métricas agregadas) |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Padrões de escala horizontal | ✅ Carga de trabalho distribuída entre vários recursos: a massificação processa vários registros por transação, o processamento assíncrono distribui trabalho ao longo do tempo, o particionamento de dados distribui a carga entre limites |
| Configuração de processamento em lote | ✅ Limites ideais de taxa de transferência e regulador de balanceamento de tamanho de lote (2 mil registros por execução do Apex em lote, 200 registros por invocação do acionador, 25 solicitações por chamada de API composta) |
| Gerenciamento de taxa de API | ✅ O armazenamento em lote e em cache da integração reduz o consumo da API, monitora a alocação de API de 24 horas por edição, o planejamento de capacidade adiciona licenças ou limita aumentos antes do esgotamento |
| Execução concomitante | ✅ Trabalhos em lote paralelos para dados particionados (5 lotes de distribuição regionais executados simultaneamente), os assinantes do Evento de plataforma processam fluxos simultaneamente |
| Monitoramento de profundidade da fila | ✅ Para integrações assíncronas, as tendências de profundidade da fila indicam que o processamento está atrás da taxa de produção exigindo aumento de capacidade ou otimização de taxa de transferência |
| Detecção de anomalia por volume | ✅ Volumes de transações significativamente acima/abaixo dos padrões esperados podem indicar processos inativos que exigem investigação e limitação |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Processamento em lote | Processar todos os registros em sequência quando o volume de dados exigir execução paralela particionada (particionamento baseado em data, baseado em tipo de registro ou baseado em proprietário habilita o processamento simultâneo) |
| Consumo da API | Padrão de integração adiciona 25% de consumo de API sem planejamento de capacidade (erros súbitos de “limite de API excedido” afetam os usuários) |
| Monitoramento de fila | ⚡️ Sem monitoramento da profundidade da fila de integração assíncrona (o processamento fica atrás da taxa de produção sem visibilidade) |
| Gerenciamento de limite do controlador | ⚡️ Operações síncronas processando grandes volumes atingindo limites de tempo de CPU ou tamanho de heap (deve passar para processamento assíncrono com limites dedicados) |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Hierarquia de critérios de recursos | ✅ Níveis definidos: Crítico (receita/conformidade, nunca reduzido), Importante (fluxos de trabalho principais, reduzidos apenas durante incidentes importantes), Suporte (experiência aprimorada, desabilitado durante a falha de integração), Opcional (bem-estar, desabilitado durante carga alta) |
| Implementação do disjuntor | ✅ Estados do circuito (Fechado = normal, Aberto = falha imediatamente após o limite, Meio aberto = sonda de recuperação); Estado do Cache da plataforma, alterações de transmissão de Eventos da plataforma; abre após falhas consecutivas (por exemplo, 10 falhas) |
| Lógica de nova tentativa | ✅ Desvio exponencial para falhas temporárias (1s, 2s, 4s, 8s, limite em 30-60s); repita os tempos limite da rede e erros 5xx com desvio exponencial, repita os limites de taxa 429 após o cabeçalho de Repetir após; nunca repita erros 4xx do cliente ou erros de limite do regulador na mesma transação |
| Estratégias de fallback | ✅ Fontes de dados alternativas (Cache da plataforma quando a API em tempo real estiver indisponível), comportamento padrão (regras padrão quando o serviço de personalização estiver inativo), processo manual (interface do administrador para transações persistentes), fila para nova tentativa (eventos da plataforma com reprodução de 72 horas) |
| Arquitetura de manipulação de erros | ✅ Falha rapidamente (validar entradas na entrada), falha facilmente (processar 197 de 200 registros quando a validação falha em três), falha informativamente (registro com ID da transação, contexto do usuário, rastreamento de pilha), falha com segurança (transacções parciais de reversão, nunca exponha informações internas aos usuários) |
| Automação de recuperação | ✅ O monitoramento de plataforma aciona a recuperação automatizada: mecanismos de nova tentativa assíncronos, filas de letras mortas para processamento com falha, fluxos de trabalho de auto-cura que permitem a recuperação rápida sem intervenção manual |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Dependência de integração | ⚡️ O envio do pedido falha completamente quando o serviço de validação de endereço externo é interrompido (fluxo crítico bloqueado pelo recurso de suporte; deve ser reduzido facilmente com revisão manual) |
| Estratégia do disjuntor | ⚡️ Nenhum interruptor em chamada externa fazendo com que cada transação espere 120 segundos para atingir o tempo limite quando o sistema externo estiver inativo (todos os usuários afetados por uma integração com falha) |
| Lógica de nova tentativa | ⚡️ Tente novamente exceder o limite de CPU do Apex imediatamente no mesmo contexto de transação (falhará novamente; deve ser reenfileirado como operação assíncrona com limites dedicados) |
| Lógica de nova tentativa | Tente novamente indefinidamente até o sucesso (risco de loop infinito, a transação nunca é concluída; o limite máximo de tentativas de nova tentativa deve ser limitado) |
| Manipulação de erros | ⚡️ A tentativa de captura de bloco engole a exceção sem registro (falha invisível aos operadores que impedem o diagnóstico e a remediação) |
| Manipulação de erros | Exibir rastreamento de pilha para o usuário final na página do Lightning (risco de segurança revelando detalhes da implementação, má experiência do usuário) |
| Estratégia de fallback | ⚡️ O serviço de cálculo de taxa falha ao bloquear todos os envios de pedidos (funcionalidade crítica sem fallback; deve ficar na fila para processamento manual ou usar taxas padrão) |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Modelagem de saúde | ✅ Status de saúde agregado: Integridade do serviço (taxa de sucesso de transação >99.5% verde, 98-99.5% amarelo, <98% vermelho), Integridade (todos respondendo verde, amarelo degradado, interruptor aberto vermelho), Integridade de dados (verde de sincronização de corrente, atrás do amarelo, vermelho obsoleto/falhado), Integridade de capacidade (<70% verde, 70-85% amarelo, >85% vermelho) |
| Monitoramento de evento | ✅ Objetos EventLogFile com entrega 24h/1h encaminhada para SIEM externo para retenção além dos limites de retenção nativos; captura chamadas de API, exibições de página, exportações de relatório, atividade de login, execução do Apex |
| Alertas de Proactive Monitoring | ✅ Picos de limite de solicitações da API (investigação de acionadores de limite de 75%), falhas de execução do Apex simultâneas, problemas de limite de linha SOQL, tendências de consumo de armazenamento |
| Painel de integridade | ✅ Métricas por integração: taxa de erro (<1% de destino), latência p50/p95/p99 com SLO, taxa de tempo limite (<0,1% de destino), estado do disjuntor de circuito, profundidade da fila assíncrona; logs estruturados com ID da solicitação, ponto de extremidade, código de resposta, duração |
| Design de alerta acionável | ✅ Cada alerta define quem responde, o que verifica e como remedia; inclui limite cruzado, valor atual, tendência recente, link do painel, link do manual de execuções; gravidade combinada à urgência (páginas críticas na chamada para impacto do usuário, emails de aviso para preocupações de tendência) |
| Detecção de anomalia | ✅ Anomalias de volume (300% da carga típica), anomalias de taxa de erro (2% vs. 0,5% típico mesmo que seja abaixo do limite de 5%), desvio de latência (tendência gradual de aumento), anomalias comportamentais (padrões de login incomuns, trabalhos em lote fora da agenda); usadas para orientar a investigação não acionar escalonamento imediato |
Antipadrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Monitoramento de evento | ⚡️ Monitoramento de evento habilitado, mas nunca exportado (retenção nativa insuficiente para análise de tendência, dados históricos perdidos) |
| Design de alerta | Mensagem de alerta “Ocorreu um erro” sem contexto, limite ou ação de resposta (gerará fadiga de alerta, os operadores não poderão fazer a triagem de modo eficaz) |
| Gravidade do alerta | ⚡️ Trate todas as anomalias como alertas críticos (uma alta taxa de falsos positivos cria fadiga de alerta fazendo com que alertas críticos sejam perdidos) |
| Monitoramento de saúde | ⚡️ Sem modelo de integridade agregado, operadores sobrecarregados com métricas técnicas individuais sem padrões entre sistemas |
| Monitoramento de integração | ⚡️ Sem taxa de erro, latência ou rastreamento de estado do disjuntor de circuito específicos da integração (falhas de integração descobertas reativamente por meio de relatórios do usuário) |
| Monitoramento de capacidade | ⚡️ Sem Proactive Monitoring ou revisão do Centro de escala (riscos de confiabilidade de transações com uso intensivo de recursos não são detectados até o impacto na produção) |
Para obter exemplos em linha e orientações detalhadas, consulte o pilar Confiabilidade ou navegue no explorador Padrões e antipadrões.