# architect Estrutura bem arquitetada (well-architected) - Full Documentation # A empresa agente ## Visão geral A Agentic Enterprise representa uma mudança fundamental na maneira como as empresas usam a IA. Ele passa de ferramentas passivas que exigem direção humana constante para agentes autônomos que sentem, raciocinam e agem por conta própria enquanto permanecem alinhados à intenção humana. É uma organização em que humanos, agentes e plataformas trabalham juntos dentro de sistemas de negócios governados para entregar resultados que ninguém poderia alcançar sozinho. Este documento é um acompanhamento do [Quadro Bem-Arquivado](/docs/architect/pt-br/well-architected/guide/framework.html). Os cinco pilares da estrutura – Trust, Reliabilidade, Excelência operacional, Otimização de recursos e custos e Fairness – fornecem a orientação fundamental que se aplica a *todas as* soluções do Salesforce. Esta visão geral explica o que muda quando as soluções se tornam agentes e direciona você para os detalhes de cada pilar. Os sistemas agentes combinam grandes modelos de linguagem, geração aumentada por recuperação, chamada de função e padrões de orquestração para criar recursos que se adaptam ao contexto em vez de seguir caminhos programados rígidos. Os agentes combinam o raciocínio probabilístico (inferência de LLM) com a execução determinística (fluxos de trabalho e orquestração) para habilitar a adaptabilidade e a governança. Para arquitetos, esse comportamento introduz considerações de design em todos os pilares. Os agentes operam com comportamento não determinista em sua camada de raciocínio, o que exige novos padrões de confiabilidade, monitoramento e controle. A autonomia do agente exige limites de segurança aprimorados e supervisão humana no loop. A coordenação com vários agentes cria complexidade emergente que requer orquestração deliberada. A Agentic Enterprise não está apenas adicionando recursos de IA a arquiteturas existentes, ela reimagina como os sistemas são projetados, implementados e governados. Feito bem, essa combinação cria valor comercial real: Os agentes lidam com fluxos de trabalho complexos de várias etapas que antes exigiam intervenção humana, sintetizam informações entre fontes e expandem o conhecimento em toda a organização. Ele também apresenta desafios que exigem design deliberado. O comportamento não determinista complica o teste, o monitoramento e o tratamento de erros. A autonomia gera questões de controle, responsabilidade e segurança. As estruturas de custo mudam de uma infraestrutura fixa para o consumo de inferência variável. Os arquitetos devem equilibrar a autonomia com relação ao risco, a inovação com relação ao controle e o recurso com relação ao custo. > ### Assistências vs. ações > > Uma distinção fundamental na arquitetura agente é se um agente *assiste* um humano (padrão de copiloto: sugerir, recomendar, elaborar) ou *agir* de forma autónoma (padrão do agente: decidir, executar, concluir). Os copilotes exigem aprovação humana para ações de modificação de estado; os agentes operam de modo independente dentro dos limites de permissão. Essa distinção determina requisitos de Trust, necessidades de observabilidade e padrões de supervisão. A mudança de assists para acts é uma mudança arquitetônica, não uma mudança de configuração. Isso exige reavaliar cada pilar por meio da lens de operação autônoma. ## O Sistema unificado: Pessoas + agentes + plataformas A Agentic Enterprise é uma organização em que humanos, agentes e plataformas trabalham juntos dentro de sistemas de negócios governados para entregar resultados que ninguém poderia alcançar sozinho. Esse modelo de três partes forma cada decisão arquitetônica: - Os **Humanos** fornecem supervisão, julgamento e intervenção quando as capacidades dos agentes faltam ou quando os interesses exigem a responsabilidade humana. A colaboração entre agentes humanos permite que as pessoas se concentrem em estimativas de alto valor enquanto os agentes lidam com a execução de rotina e a síntese de informações. Os humanos permanecem no controle no nível do sistema: eles definem os limites e os agentes decidem e agem dentro deles. - Os **agentes** fornecem automação inteligente, interfaces de linguagem natural e tomada de decisão adaptável. Os agentes não são recursos independentes, mas participantes integrados em fluxos de trabalho de negócios. Eles percebem o contexto dos dados gerenciados, justificam ações adequadas usando técnicas probabilísticas e determinísticas e atuam por meio de fluxos de trabalho de negócios e integrações externas. - As **Plataformas** fornecem a infraestrutura gerenciada que possibilita o trabalho agenciado: lógica de negócios acumulada, dados unificados, orquestração e infraestrutura de colaboração. A plataforma distingue sistemas agentes de nível corporativo de experiências de IA não governadas: ela aplica permissões, mantém trilhas de auditoria, aplica regras de conformidade e mantém os agentes operando dentro da governança organizacional. Remova pessoas e você perde a responsabilidade; remova agentes e você perde inteligência; remova plataformas e você perde a governança. A Agentic Enterprise exige todos os três como um sistema unificado. ## Os recursos de que os agentes precisam Qualquer arquitetura agente, em qualquer pilha de tecnologia, deve fornecer um conjunto comum de recursos. Um agente precisa de dados confiáveis para raciocinar, lógica de negócios pela qual ele pode agir com segurança, governança em seu próprio ciclo de vida, uma compreensão compartilhada do que os dados significam e um caminho para escalar para humanos. Estes são requisitos arquitetônicos, não produtos: em que o Salesforce fornece parte da pilha, os recursos restantes ainda precisam de atenção. O Salesforce oferece esses recursos como um conjunto integrado. Tratá-los como um sistema torna as dependências explícitas: enfraquecer qualquer um e os agentes serão limitados de maneira previsível. Esta seção descreve cada recurso, por que ele é importante para os agentes e como o Salesforce o fornece. ### Dados confiáveis e contexto Os agentes precisam de dados controlados e verificados para justificar de modo eficaz. Os modelos de IA conhecem padrões dos dados de treinamento, não dos registros de clientes, do catálogo de produtos ou do histórico de transações de uma empresa. Essa funcionalidade fecha essa lacuna fundamentando os agentes em dados precisos, autorizados, atuais e rastreáveis, em vez de conteúdo da Web arbitrário ou origens não verificadas. - Os **datos operacionais atuais** permitem decisões urgentes: um agente de comércio respondendo *"Qual é o status do meu pedido?"*, um agente de serviço detectando casos abertos, ou um agente de vendas classificando oportunidades que fecham neste trimestre. - Os **dados históricos** – por exemplo, grandes conjuntos de dados mantidos no Data 360 – dão suporte à análise de tendências, previsões e aprendizado com base em padrões passados. - O **acesso federado** permite que os agentes entendam os dados onde quer que estejam. Ele reduz a duplicação de origens conectadas e apresenta uma visualização unificada. *A Salesforce fornece isso por meio do portfólio do Data 360.* > **Implicação arquitetônica:** A qualidade do agente depende da qualidade dos dados. Investir em governança, classificação e lineagem de dados. Um agente que apresenta dados incorretos erode o Trust mais rapidamente do que um que diz "Eu não sei". ### Os agentes de lógica de negócios podem agir por meio dela Um agente que pode responder apenas perguntas é um copiloto. Um agente que pode criar registros, atualizar oportunidades, enviar comunicações e acionar automações é autônomo. Essa autonomia permite aos agentes *agir* em vez de apenas *ajudar* — invoca processos de negócios existentes e bem testados, em vez de reimplementá-los no código gerado. - Os agentes traduzem a intenção de linguagem natural em operações comerciais padrão em vez de exigir que os usuários escrevam código. - Os agentes delegam a processos de várias etapas encapsulados (por exemplo, um fluxo de reembolso que lida com verificações de crédito, atualizações de inventário e notificações). - Conforme as regras de negócios evoluem, os agentes herdam as alterações automaticamente, desde que a lógica fique no fluxo de trabalho e não seja refletida nas instruções do agente. *A Salesforce fornece essa funcionalidade por meio da lógica de negócios e da automação de plataforma do Customer 360.* > **Implicação arquitetônica:** Projete agentes para invocar fluxos de trabalho existentes, não substituí-los. Os agentes que chamam automações comprovadas são mais confiáveis do que os agentes que reimplementam a lógica de negócios por meio do código gerado. ### Governança sobre o ciclo de vida do agente Os agentes precisam de governança de desenvolvimento a implantação, monitoramento e descontinuação. Sem isso, a proliferação de agentes não gerenciados cria a IA de sombra: agentes com permissões imprecisas, sem trilhas de auditoria, comportamento não testado e custo desconhecido. Esse recurso garante que os agentes sejam criados com proteções, implementados por meio de portões de aprovação, monitorados para desvio e descontinuados quando não forem mais necessários. - As ferramentas de **desenvolvimento** geram configurações iniciais a partir de descrições em linguagem natural e impõem proteções (validação de permissões, escopo do subagente) no momento do projeto. - A **orquestração de tempo de execução** gerencia a invocação do agente, a imposição de permissões, o registro de auditoria e o tratamento de falhas. - Os **funcionalidades reutilizáveis** permitem que as equipes adotem agentes e ações predefinidos, incluindo funcionalidades verticais de especialistas em domínio, em vez de criar cada agente do zero. - A **observabilidade da sessão** armazena interações do agente, etapas de raciocínio e resultados para análise, depuração e detecção de desvio. *A Salesforce fornece essa funcionalidade por meio do Agentforce Studio, do Agent Fabric e do AgentExchange.* > **Implicação arquitetônica:** Trate os agentes como ativos gerenciados, não scripts únicos. A governança no nível do sistema evita a disseminação do agente. ### Uma compreensão compartilhada do que os dados significam Os agentes que consultam dados precisam entender a semântica: o que "receita" significa, qual campo é "nome do cliente", como as tabelas se relacionam. Sem uma definição semântica compartilhada, os agentes geram consultas que usam os campos errados, interpretam nulos incorretamente ou violam regras de negócios. Com um, cada agente consulta definições governadas e retorna resultados consistentes e corretos, com a lógica de calendário fiscal e reconhecimento de receita vivendo na definição, não em avisos do agente. Essa camada opera dentro do modelo de segurança nativo da plataforma: o acesso é controlado pelos próprios controles no nível de linha e no nível de campo da plataforma, não reimplementados na camada semântica. Como resultado, os agentes são vinculados pelas mesmas permissões de dados que a plataforma impõe. *O Salesforce fornece essa funcionalidade por meio do Tableau Semantics, uma camada semântica governada integrada ao Tableau Next e ao Data 360.* > **Implicação arquitetônica:** Defina a camada semântica antes de implementar agentes analíticos. Os agentes que consultam tabelas brutas criam lacunas de governança e resultados inconsistentes. ### Um caminho para escalar para humanos Agentes totalmente autônomos sem supervisão humana criam riscos de conformidade, lacunas de responsabilidade e desconfiança do usuário. Esse recurso mantém os humanos no controle: Os agentes escalonam quando há incertezas, solicitam aprovação para ações de alto impacto e permanecem transparentes sobre seu raciocínio. - Os fluxos de **trabalho de aprovação** permitem que os agentes solicitem o logout humano antes de executar ações consecutivas (emitir um reembolso, fechar uma oportunidade, excluir dados). - O **histórico de interações persistente** registra a intenção, os dados acessados, as etapas de raciocínio e as ações realizadas, permitindo auditoria, depuração e melhoria contínua. - Os **padrões de escalação** são transmitidos aos especialistas humanos com contexto completo quando um agente não tem confiança ou atinge um caso de ponta. *O Salesforce fornece essa funcionalidade por meio de fluxos de trabalho de aprovação e escalação Human-in-the-Loop com histórico de interações persistente e auditável.* > **Implicação arquitetônica:** Projete regras de escalação explícitas com antecedência. Defina quais decisões exigem aprovação humana (limites financeiros, ações irreversíveis, dados regulamentados) e implemente esses fluxos de trabalho antes de implantar agentes autônomos. ### Como os recursos funcionam juntos Esses recursos são interdependentes. Um agente utiliza dados confiáveis para fundamentar seu raciocínio, atua por meio da lógica de negócios, opera sob a governança de ciclo de vida, consulta por meio de semântica compartilhada e escala para humanos quando necessário. Remova dados confiáveis e os agentes alucinam; remova a lógica de negócios e eles só podem responder, não agir; remova a governança e eles se proliferam em IA sombra; remova a semântica compartilhada e seus desvios de consultas; remova a escalação humana e eles agem sem supervisão. Um modelo de consumo de primeira API, o Salesforce Headless 360, permite que os agentes acessem esses recursos por meio de interfaces programáticas consistentes (API, MCP e CLI), em vez de integrar sistemas separados um a um. ## Como os pilares se aplicam a sistemas agentes Os pilares da Estrutura bem criada continuam a ser a base para sistemas agentes. Os agentes ainda operam dentro dos limites do regulador, exigem controles de acesso adequados, precisam de monitoramento, consomem recursos e atendem os usuários de maneira justa. Comece com a orientação do principal pilar e aplique as considerações agentes que cada companheiro do pilar adiciona. Diretrizes do principal pilar: - [Trust](/docs/architect/pt-br/well-architected/guide/trust.html) — Modelo de responsabilidade compartilhada, controle de acesso de quatro camadas (org/object/field/record), criptografia, fluxos OAuth, trilhas de auditoria, estruturas de conformidade - [Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html) – limites do regulador com um buffer operacional recomendado (o limite de 70% é uma prática recomendada da comunidade, não uma especificação oficial do Salesforce), processamento assíncrono, interruptores de circuito, planejamento de capacidade, padrões de várias organizações, recuperação de desastres - [Excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) — Monitoramento de evento, Proactive Monitoring, Práticas de DevOps (desenvolvimento orientado por fonte, CI/CD), automação, gerenciamento de incidentes, métricas DORA - [Otimização de recursos e custos](/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization.html) — Otimização SOQL, prevenção de data-skew, organização de código, estratégias de empacotamento, monitoramento de desempenho, modelagem de TCO, compilação vs. compra, otimização de licenças, monitoramento de custos - [Justiça](/docs/architect/pt-br/well-architected/guide/fairness.html) — acessibilidade ([WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/)), padrões de não discriminação (regras de partilha, FLS), arquitetura de privacidade, governança ética da IA ### Trust for Agentic Systems Os padrões principais Trust (Modelo de responsabilidade compartilhada, privilégio mínimo, criptografia, OAuth) permanecem fundamentais. Os sistemas agentes adicionam: - **Autenticidade e autenticação do agente** – os agentes podem usar autenticação baseada em JWT em vez de chaves de API estáticas, o que habilita trilhas de auditoria por agente e rastreamento de permissão granular - **Propagação de identidade do usuário** – quando os agentes invocam sistemas externos em nome de um usuário, propagam a identidade do *usuário* (não apenas a do agente) para que os sistemas a jusante apliquem permissões no nível do usuário e rastas de auditoria - **Limites de permissão** – privilégio mínimo para agentes, herança de permissão do usuário em execução, permissões explícitas do agente e validação nos limites de delegação - **Human-in-the-Loop para decisões consequenciais** — fluxos de trabalho de aprovação para ações de alto impacto ou irreversíveis e dados regulamentados - **Explicabilidade** – os agentes explicam o seu raciocínio, citam fontes para alegações factuais e tornam transparentes os dados e ações que tomaram - **Conformidade para sistemas autônomos** — aderir à classificação de risco do [Ato UE de IA](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) (diferenciando implantações de risco limitado em relação a implantações de alto risco) e aos regulamentos específicos do setor, como a [HIPAA](https://www.hhs.gov/hipaa/index.html) e a lei de serviços financeiros funcionais; manter uma gestão rigorosa do consentimento para o processamento orientado por agentes **Por que isso importa:** Os agentes que atuam de forma autônoma sem limites de Trust adequados criam vulnerabilidades de segurança, violações de conformidade e desconfiança do usuário. O pilar principal Trust fornece o Modelo de responsabilidade compartilhada e controle de acesso de quatro camadas; a variante agente adiciona autenticação de agente opcional baseada em JWT, portas de aprovação HITL e capacidade de explicação. **Saiba mais:** [Agent Enterprise Trust](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-trust.html) ### Confiabilidade para sistemas agentes Os principais padrões de confiabilidade (limites do regulador, processamento assíncrono, interruptores de circuito, planejamento de capacidade) permanecem fundamentais. Os sistemas agentes adicionam: - **Manuseio de raciocínio não determinístico** – a mesma entrada pode produzir diferentes saídas; design para variação com pontuação de confiança, verificações de validação e estratégias de fallback - **Degradação graciosa** — quando a inferência falha ou retorna baixa confiança, degrade para capacidades mais simples em vez de falhar completamente - **Manuseio de falha de orquestração** – fluxos de trabalho de vários agentes precisam de isolamento de falha, estratégias de repetição e tratamento de resultado parcial para que um agente especializado que falha permaneça isolado em vez de ser encadeado - **SLOs de desempenho do modelo** – definir metas aceitáveis de latência, precisão e disponibilidade para serviços do agente - **Disparadores para coordenação do agente** – evitar falhas em cascata quando um agente experimenta erros ou latência excessiva **Por que isso importa:** O comportamento do agente probabilístico significa que os padrões de confiabilidade determinística não são suficientes. O pilar de confiabilidade central fornece padrões assíncronos e quebradores de circuito para integrações externas; a variante agente adiciona degradação agradável para falhas de inferência e tratamento de falha de orquestração para coordenação de vários agentes. **Saiba mais:** [Confiabilidade corporativa dos agentes](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-reliability.html) ### Excelência operacional para sistemas agentes Os principais padrões de excelência operacional (Monitoramento de evento, DevOps, automação, gerenciamento de incidentes) permanecem fundamentais. Os sistemas agentes adicionam: - Ciclo de vida de **desenvolvimento do agente (ADLC)** – gerencie os agentes em todo o ciclo de vida, desde o design e os testes até a implantação, o monitoramento e o ajuste - **Observando sistemas probabilísticos** — capturar etapas de raciocínio, pontuações de confiança, fontes de dados acessadas e raciocínio da decisão, não apenas entrada→output - **Detecção de desvio** – monitore a degradação do desempenho de turnos de distribuição de dados, alterações de regras de negócios ou atualizações de modelo a montante em relação às linhas de base comportamentais - **Versão do agente e implementação** – distribuição gradual, teste A/B, reversão e controle de versão para avisos e configurações - **Resposta de incidente para falhas do agente** – distinguir falhas de modelo, falhas de orquestração e falhas de dados para remediação direcionada **Por que isso importa:** Comportamento não determinista dificulta a observação. O principal pilar de Excelência operacional fornece práticas de Monitoramento de evento e DevOps; a variante agente adiciona ADLC, detecção de desvio e observabilidade específica do agente. **Saiba mais:** [Excelência operacional da Agtic Enterprise](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-operational-excellence.html) ### Otimização de recursos e custo para sistemas de agentes Os padrões de otimização de custo e recurso essenciais (otimização de SOQL, limites do controlador, organização de código, monitoramento de desempenho, modelagem de TCO, criação vs. compra, otimização de licença, monitoramento de custo) permanecem fundamentais. Os sistemas agentes adicionam: - **Otimização de latência de inferência** — respostas de streaming, execução paralela, armazenamento em cache e otimização de prompt - **Economia de token** — cada etapa de chamada, recuperação e raciocínio consome tokens; crie estratégias de gerenciamento de contexto (resumo, recuperação seletiva) para janelas de contexto limitadas - **Otimização de recuperação de memória** — pesquisa vetorial eficiente e recuperação semântica para que padrões RAG não criem gargalos de latência - **Gerenciamento de latência de vários agentes** – execução especializada em paralelo, delegação assíncrona e orçamento de tempo limite para evitar que cadeias de agentes sequenciais acumulem latência - **Modularização de agentes** — Dividir agentes monolíticos em agentes especializados para reutilização, escalação independente e otimização direcionada - **Preço baseado em consumo** — Ao contrário da licença por usuário, os custos dos agentes aumentam com o uso, exigindo orçamento e previsões diferentes - **Unidades de trabalho agentes (AWUs)** — medir o gasto em relação ao trabalho realizado pelos agentes, não apenas o consumo bruto do token, e ajustar o consumo em relação ao valor entregue - **Construir vs. comprar para recursos agenciais** — avaliar a criação de recursos diferenciados em relação à adoção de recursos de commodity - **Medida do ROI do agente** – acompanhar os resultados de negócios em relação aos custos operacionais do agente **Por que isso importa:** O consumo de token e a latência de inferência são novas restrições de recurso, e os modelos de custo de agência diferem fundamentalmente dos custos de infraestrutura. O pilar principal fornece orientação de limite do regulador, otimização de SOQL e a estrutura de TCO; a variante agente adiciona economia de token, otimização de latência de inferência, gerenciamento de precificação baseado em consumo e Unidades de trabalho agente para medir o custo em relação aos agentes de trabalho concluídos. **Saiba mais:** [Otimização de recursos empresariais e custo](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-resource-and-cost-optimization.html) ### Fairness para sistemas agentes Os principais padrões de equidade (acessibilidade, não discriminação, privacidade, governança de ética de IA) permanecem fundamentais. Os sistemas agentes adicionam: - **Explicabilidade** – os agentes explicam por que decidiram, quais dados usaram e quais alternativas consideraram. (O pilar Trust abrange a explicabilidade como um controle de auditoria e transparência; Fairness abrange-a como o direito de um usuário entender uma decisão que os afeta.) - **Contestabilidade** – os usuários podem desafiar as decisões do agente, solicitar revisão humana e entender o processo de apelações - **Detecção e mitigação de desastres** — teste com entradas diversas e monitoramento de resultados diferentes em grupos demográficos - **Supervisão humana proporcional ao impacto** — Decisões de alto nível exigem Human-in-the-Loop; decisões de baixo nível podem operar de forma autónoma - **Experiências equitativas conduzidas por agentes** — atendem todos os usuários de forma eficaz, independentemente de proficiência linguística, conhecimento técnico ou necessidades de acessibilidade **Por que isso importa:** Agentes autônomos tomando decisões que afetam as pessoas aumentam os juros de justiça. O principal pilar de Fairness fornece padrões de acessibilidade e padrões de não discriminação; a variante agente adiciona explicabilidade, contestabilidade e supervisão humana proporcional. **Saiba mais:** [Agent Enterprise Fairness](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-fairness.html) ## Usar este documento com os guias de pilares Ao arquivar soluções agentes: 1. **Comece aqui** para o modelo conceitual: os recursos de que os agentes precisam e como os pilares se aplicam aos agentes. 2. **Leia os guias básicos** para as abordagens fundamentais que se aplicam a todas as soluções do Salesforce. 3. **Leia os companheiros de pilares agenciais** para detalhes de design específicos para os agentes. Crie em padrões de plataforma comprovados e, em seguida, aborde as considerações apresentadas pelos agentes. Os pilares centrais fornecem a base, os acompanhantes agentes fornecem os detalhes e essa visão geral os une. ## Prontidão organizacional: O Centro de excelência Os recursos e os pilares acima descrevem como arquivar um sistema agente. Colocar esse sistema em produção requer uma estrutura de governança permanente: um Centro de excelência (CoE). No sistema unificado de humanos, agentes e plataformas, o CoE dá controle aos humanos. O CoE define os limites dos agentes, decide o que atinge a produção e alinha o trabalho do agente à intenção comercial e aos requisitos regulatórios. Um CoE é a diferença entre sistemas agentes governados e experiências não governadas que se desviam para a IA sombra – agentes com permissões imprecisas, sem trilha de auditoria e custo desconhecido. A autonomia torna cada decisão de governança consequente. O CoE ajuda as equipes a tomar essas decisões deliberadamente e aplicá-las de modo consistente, em vez de resolvê-las em uma equipe por vez. ### O que o Centro de excelência controla Um CoE une negócios, TI e conformidade em torno de uma pendência compartilhada e uma definição compartilhada de pronto. Sua associação abrange as perspectivas que uma decisão agente toca: - **Um patrocinador executivo** detém a autoridade orçamental e limpa os bloqueadores organizacionais. - Os **líderes empresariais** traduzem a estratégia em prioridades e possuem o backlog. - **Um escritório de programa e administradores de dados** conectam o trabalho agente a iniciativas mais amplas e avaliam a integridade e a segurança dos dados. - **Arquitetos, administradores e desenvolvedores** possuem o modelo de dados, os padrões de integração e o ritmo de entrega e detectam restrições técnicas antes do início do trabalho. Os agentes enviam, alteram e desviam mais rapidamente do que o software tradicional. Para manter a governança alinhada à entrega, o CoE é executado em um ritmo de revisão primeiro assíncrono e acelerado. O ritmo fica mais apertado em comparação a um CoE convencional, e a revisão assíncrona se torna o modo de trabalho padrão: - A revisão **contínua assíncrona** é o modo principal: os membros permanecem alinhados em um canal compartilhado à medida que as mudanças chegam, não apenas em reuniões agendadas. - As **revisões operacionais semanais** confirmam que as alterações no voo permanecem compatíveis com agentes ativos e integrações, um ritmo mais rápido do que as revisões mensais ou trimestrais que um ritmo mais lento de entrega permitiria. - As **exames estratégicos mensais** ponderam o atraso em relação às prioridades de negócios e avaliam a prontidão em relação à linha de base atual de qualidade dos dados. O Conselho de Administração toma decisões explícitas sobre quem aprova alterações nos objetos, campos e automações de que os agentes dependem; quem tem prioridade quando as solicitações competem; quando descontinuar o débito técnico; e quais métricas de negócios definem o sucesso. ### Avaliando a prontidão entre os pilares Um CoE pronto para agentes controla cada pilar. Os guias de pilares principais fornecem os controles fundamentais; é no CoE que eles se tornam prática observável imposta. - **Trust** – a segurança em nível de objeto, campo e registro controla os dados que os agentes usam. Os controles de acesso no nível do agente limitam os dados e ações que cada agente pode acessar. Identidade, privilégio mínimo e modelagem de ameaça são integrados ao design do agente. Consulte [Trust](/docs/architect/pt-br/well-architected/guide/trust.html) e [Agentic Enterprise Trust](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-trust.html). - **Excelência operacional** – Registros de rastreamento e auditoria capturam decisões, ações e resultados dos agentes. Os painéis de monitoramento revisam o desempenho e o alinhamento em relação às metas no ciclo de vida de desenvolvimento do agente. Consulte [Excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) e [Excelência operacional](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-operational-excellence.html) da agência. - **Confiabilidade** e **Otimização de recursos e custos** – Especificação, geração de testes, loops de feedback e descontinuação controlam todo o ciclo de vida do agente. Limitação de taxa, controles de recurso e estratégias de remediação contêm os efeitos de erros do agente. Consulte [Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html) e [Otimização de recursos e custos](/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization.html). - **Justiça** — Os pontos de verificação humanos permitem que as pessoas interceptem ou revisem ações consequentes. Os caminhos de escalação e o treinamento da equipe preparam as pessoas para revisar e substituir fluxos de trabalho agentes. Consulte [Fairness](/docs/architect/pt-br/well-architected/guide/fairness.html) e [Agent Enterprise Fairness](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-fairness.html). ### Sinais de prontidão Um CoE está pronto para controlar cargas de trabalho agentes quando estas condições são atendidas: - **Política** — Políticas de acesso e ação para agentes são definidas, aplicadas e auditáveis. - **Observabilidade** — As ferramentas de monitoramento e auditoria dão suporte a análises retrospectivas e em tempo real do comportamento dos agentes. - **Secure by design** – Segurança, privacidade e conformidade são integrados aos fluxos de trabalho da agência desde o início. - **Ciclo de vida** — Um processo estruturado rege a integração, a atualização e a descontinuação dos agentes. - **Supervisão humana** – Os revisores lidam com exceções e usam feedback para melhorar os fluxos de trabalho da agência. Confirme estas quatro noções básicas antes de implementar seu primeiro agente de produção: - **Uma linha de base de qualidade dos dados documentada**, revisada em um ritmo regular. - **Um processo formal de aprovação de alteração de esquema** com um proprietário nomeado e logout registrado. - **Um registo de dívida técnica mantido**, revisado no ritmo estratégico. - **Uma política de governança de IA** que abrange o acesso aos dados, o escopo do agente e os requisitos de auditoria. > **Implicação arquitetônica:** Estabeleça o CoE e confirme essas bases antes de implantar agentes autônomos. Governança integrada nas escalas iniciais com a adoção pelo agente. A governança adaptada posteriormente compete com a disseminação que deve ser evitada. **Veja também:** [Processos de aprovação de implantação](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-operational-excellence.html#deployment-approval-processes) no guia de Excelência operacional da empresa agente — a lista de verificação por agente que complementa a visualização de prontidão no nível da organização desta seção. ## Introdução As organizações que começam sua jornada agente devem: 1. **Comece com casos de uso de alto valor** — Concentre os agentes iniciais em fluxos de trabalho com ROI claro; o sucesso cria um impulso. 2. **Criar capacidades fundamentais** — Estabelecer governança de dados, bases de Knowledge e padrões de integração. 3. **Desenvolva o conhecimento dos agentes** — Desenvolva habilidades em engenharia rápida e arquitetura de agentes, mesmo que as ferramentas com pouco código e linguagem natural reduzam a barreira de entrada. 4. **Estabelecer um Centro de Excelência** – defina o órgão de governança responsável pelos processos de aprovação, testes de segurança e monitoramento antes de implantar agentes de produção (consulte Prontidão *organizacional: O Centro de Excelência* acima). 5. **Iterate** – plano para refinamento contínuo em vez de uma implantação inicial perfeita. 6. **Mede o valor** – rastreie resultados de negócios, poupança de custos e satisfação do usuário para informar o investimento. A Agentic Enterprise é uma oportunidade de transformação para organizações prontas para adotar fluxos de trabalho desenvolvidos com IA. Um design arquitetônico deliberado permite que você o realize enquanto gerencia o risco e a complexidade.

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

# Acessibilidade e design inclusivo – Padrões
Saiba mais sobre a [justiça](/docs/architect/pt-br/well-architected/guide/fairness.html) bem criada → [Acessibilidade com Lightning e Experience Cloud](/docs/architect/pt-br/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud) ## Conformidade com WCAG 2.2 AA **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Padrões de design | ✅ WCAG 2.2 Nível AA é a barra de acessibilidade mínima para trabalho personalizado (Experience Cloud, LWCs, temas personalizados), verificada pela equipe de criação | | Plataforma \| Padrões de design | ✅ Princípio perceptível: Existem alternativas de texto para imagens e ícones; as legendas acompanham vídeos | | Plataforma \| Padrões de design | ✅ Princípio operável: Toda a funcionalidade pode ser operada apenas por meio de teclado, sem precisar de mouse ou toque — as tecnologias auxiliares de controle de voz e acesso de alternância dependem do mesmo modelo de teclado/foco | | Plataforma \| LWC | ✅ Componentes da Web Lightning padrão são usados conforme projetado, proporcionando acessibilidade de linha de base automaticamente | | Plataforma \| LWC | ✅ Componentes personalizados implementam acessibilidade explícita validada por meio de testes com leitores de tela | | Plataforma \| Planos de teste | ✅ O teste de acessibilidade está incluído em todas as fases de teste (não ad hoc nem opcional) | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Padrões de design | ⚡️ WCAG 2.2 Nível AA é tratado como opcional ou "belo ter" em vez do requisito mínimo | | Plataforma \| Padrões de design | Imagens e ícones não têm alternativas de texto; vídeos não têm legendas | | Plataforma \| Padrões de design | A funcionalidade exige interação com o mouse ou o toque sem alternativa de teclado | | Plataforma \| LWC | Componentes personalizados são criados sem implementação ou validação de acessibilidade | | Plataforma \| LWC | Componentes de entrada personalizados usam elementos div e estilo CSS sem significado semântico ou acessibilidade ao teclado | | Plataforma \| Planos de teste | ⚡️ O teste de acessibilidade é ad hoc, opcional ou realizado apenas antes do lançamento (não durante todo o desenvolvimento) | ## Arquitetura do Leitor de tela **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| LWC | Elementos HTML semânticos (cabeçalho, navegação, principal, lado, rodapé, artigo, seção) são usados em Componentes da Web Lightning personalizados | | Plataforma \| LWC | ✅ Marcos, papéis e propriedades de ARIA são aplicados quando HTML semântico apenas não pode transmitir o comportamento da interface | | Plataforma \| LWC | ✅ Atualizações de conteúdo dinâmico usam regiões ativas aria anunciando alterações aos usuários do leitor de tela | | Plataforma \| LWC | ✅ Componentes interativos personalizados têm definições de papel explícitas que correspondem ao comportamento | | Plataforma \| LWC | ✅ Os rótulos de formulário são explicitamente associados a todas as entradas de formulário usando elementos de rótulo adequados ou atributos aria-labelledby | | Plataforma \| LWC | ✅ Componentes de entrada do Lightning são configurados com atributos de rótulo obrigatórios que fornecem associação de rótulo integrada | | Plataforma \| Planos de teste | ✅ O teste é realizado com leitores de tela reais: JAWS e NVDA no Windows, VoiceOver no macOS e no iOS, TalkBack no Android | | Plataforma \| Planos de teste | ✅ O teste manual com tecnologia assistiva real é realizado por pessoas que entendem como os usuários do leitor de tela navegam | | Plataforma \| Padrões de design | ✅ O texto de espaço reservado nunca é usado como o único rótulo porque os espaços reservados desaparecem no foco e fornecem contexto insuficiente para leitores de tela | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| LWC | ⚡️ As linhas de marcação dividas significam da hierarquia de conteúdo forçando os usuários do leitor de tela a navegar em linha | | Plataforma \| LWC | ⚡️ A ARIA não é usada quando apenas HTML semântico não pode transmitir o comportamento da interface | | Plataforma \| LWC | Atualizações de conteúdo dinâmico não usam regiões ativas aria; usuários do leitor de tela perdem alterações importantes | | Plataforma \| LWC | Componentes interativos personalizados carecem de definições de papel explícitas; os leitores de tela os anunciam incorretamente | | Plataforma \| LWC | ⚡️ Entradas de formulário não têm associação de rótulo explícita; o texto do espaço reservado é usado como único rótulo | | Plataforma \| Planos de teste | ⚡️ Ferramentas de acessibilidade automatizadas são usadas exclusivamente; o teste manual do leitor de tela não é realizado | | Plataforma \| Planos de teste | O teste é realizado por usuários visuais que não estão familiarizados com a maneira como os usuários do leitor de tela realmente navegam | ## Navegação do teclado **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Padrões de design | ✅ A funcionalidade completa está acessível por meio do teclado sem exigir interação com o mouse ou o toque em qualquer ponto nas jornadas do usuário | | Plataforma \| LWC | ✅ Ordem de foco lógica segue o layout visual e o fluxo de interação | | Plataforma \| LWC | ✅ Quando o conteúdo dinâmico é carregado ou os modais são abertos, o foco é gerenciado programaticamente para orientar os usuários do teclado para o novo conteúdo | | Plataforma \| LWC | ✅ Componentes modais e pop-overs movem o foco para título modal ou primeiro elemento interativo em aberto; retorne o foco para o botão de acionador em fechamento | | Plataforma \| Padrões de design | ✅ Indicadores de foco visíveis mostram claramente qual elemento tem o foco do teclado em todos os momentos | | Plataforma \| Padrões de design | ✅ Indicadores de foco atendem ao requisito de contraste 3:1 em relação ao conteúdo envolvente | | Plataforma \| LWC | ✅ Os usuários podem navegar para dentro e para fora de todos os componentes usando apenas o teclado sem ficarem presos | | Plataforma \| LWC | ✅ Diálogos modais capturam o foco no modal enquanto estão abertos (impedindo o acesso a conteúdo oculto), mas o foco da versão é fechamento | | Plataforma \| Padrões de design | ✅ Atalhos de teclado para ações frequentes evitam conflitos com atalhos do leitor de tela e atalhos do navegador | | Plataforma \| Padrões de design | ✅ Atalhos de letra única são ativados apenas quando componentes específicos têm foco (não globalmente) para evitar conflitos com os comandos de navegação do leitor de tela | | Plataforma \| Documentação | ✅ Todos os atalhos de teclado personalizados são documentados em conteúdo de ajuda acessível | | Plataforma \| Planos de teste | ✅ As etapas de teste incluem navegação somente por teclado em todas as jornadas do usuário sem usar mouse ou toque | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Padrões de design | ⚡️ A funcionalidade requer interação com o mouse ou o toque; usuários somente de teclado não podem concluir as principais tarefas | | Plataforma \| LWC | ⚡️ A ordem de foco não segue o layout visual lógico; os usuários percorrem elementos em sequência inesperada | | Plataforma \| LWC | ⚡️ Os modais são abertos sem gerenciamento de foco; os usuários do teclado estão presos no botão de acionador agora oculto | | Plataforma \| LWC | ⚡️ O fechamento modal não retorna o foco ao botão de acionador; os usuários devem procurar seu lugar na página | | Plataforma \| Padrões de design | Indicadores de foco são suprimidos por motivos estéticos; os usuários não podem ver qual elemento tem foco | | Plataforma \| Padrões de design | Indicadores de foco têm contraste insuficiente (<3:1) | | Plataforma \| LWC | ⚡️ Os usuários ficam presos em regiões da interface sem mecanismo de escape (trampas de teclado) | | Plataforma \| LWC | ⚡️ O conteúdo integrado (iframes, widgets de terceiros) captura permanentemente o foco do teclado | | Plataforma \| Padrões de design | Atalhos de letra única acionam conflitos globais com os comandos de navegação de letra única do leitor de tela | | Plataforma \| Documentação | ⚡️ Atalhos de teclado personalizados não são documentados; os usuários não podem descobri-los | ## Design visual e contraste **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Padrões de design | ✅ Proporção de contraste mínima de 4,5:1 para texto normal abaixo de 18pt ou 14pt em negrito | | Plataforma \| Padrões de design | ✅ Proporção de contraste mínima de 3:1 para texto grande e para componentes e gráficos de UI relevantes (borda de formulário, ícones informativos); elementos exclusivamente decorativos e desabilitados estão isentos | | Plataforma \| Experience Cloud | ✅ Temas personalizados e sites do Experience Cloud com marca incluem validação de contraste explícita usando ferramentas de desenvolvimento de navegador ou verificadores automatizados | | Plataforma \| Padrões de design | ✅ Há suporte para redimensionamento de texto para 200% sem perda de conteúdo ou funcionalidade (requisito de WCAG) | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Padrões de design | As proporções de contraste de texto ficam abaixo de 4,5:1 (texto normal) ou 3:1 (componentes de UI e texto grande) | | Plataforma \| Experience Cloud | ⚡️ Os temas personalizados são implementados sem validação de contraste; usuários com baixa visão não podem ler o conteúdo | | Plataforma \| Padrões de design | Redimensionamento de texto além de 200% quebra layouts perdendo conteúdo ou funcionalidade | ## Teste e validação de acessibilidade **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| CI/CD | ✅ A varredura de acessibilidade do Axe Core ou do Lighthouse é integrada a pipelines CI/CD, capturando problemas estruturais em cada implantação | | Plataforma \| CI/CD | ✅ As compilações falham quando problemas críticos de acessibilidade são detectados | | Plataforma \| Planos de teste | ✅ O teste manual com leitores de tela, navegação somente do teclado e zoom do navegador para 200% é realizado regularmente ao longo do desenvolvimento | | Plataforma \| Planos de teste | ✅ O teste revela problemas de interação, incluindo confusão na ordem do anúncio, falhas no gerenciamento de foco e armadilhas de teclado | | Plataforma \| Negócios | ✅ Usuários com deficiência são incluídos nos testes de usabilidade em todo o processo de design | | Plataforma \| Negócios | ✅ O teste de usabilidade revela barreiras práticas que os testes automatizados e manuais de especialistas ignoram | | Plataforma \| Planos de teste | ✅ Testes automatizados (~57% dos problemas por volume), testes manuais (problemas de interação) e testes do usuário (barreiras do mundo real) são todos realizados | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| CI/CD | A varredura de acessibilidade não está integrada a pipelines de CI/CD | | Plataforma \| CI/CD | ⚡️ As compilações continuam apesar de problemas críticos de acessibilidade | | Plataforma \| Planos de teste | Teste manual com tecnologia assistiva não é realizado; apenas leitura automatizada é usada | | Plataforma \| Negócios | ⚡️ Usuários com deficiência não são incluídos nos testes de usabilidade | | Plataforma \| Planos de teste | ⚡️ O scanner de acessibilidade automatizado é executado uma vez antes do lançamento e o teste de acessibilidade é considerado concluído | # Armazenamento e otimização de custo de API – Padrões Saiba mais sobre o recurso bem-arquitetado [e otimização de custo](/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization.html) → [Otimização de dados](/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization.html#data-optimization) ## Otimização do armazenamento de dados **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Dados ativos do **modelo de dados** | ✅ **Dados ativos recebem tratamento de armazenamento premium** \- Os dados acessados regularmente para operações comerciais permanecem em objetos padrão do Salesforce com capacidade de consulta completa, automação de fluxo de trabalho e acesso do usuário. Dados ativos justificam o investimento em armazenamento porque o acesso frequente requer disponibilidade imediata
✅ Exemplo: Oportunidades e casos ativos do ano atual permanecem em objetos padrão com funcionalidade completa | | **Modelo de dados** Dados quentes | ✅ **Dados quentes usam uma estratégia de armazenamento intermediária** \- Os dados acessados ocasionalmente para relatórios ou referência podem permanecer no Salesforce com sinalizadores de arquivamento que permitem visualizações filtradas ou migrar para Objetos grandes que oferecem suporte à recuperação baseada em índice sem funcionalidade de fluxo de trabalho
✅ Exemplo: Oportunidades do ano anterior sinalizadas como arquivadas, mas permanecem consultáveis para análise histórica | | Dados frios do **modelo de dados** | ✅ **Dados frios arquivados em objetos grandes ou sistemas externos** \- Dados retidos para conformidade, mas raramente acessados, movem-se para objetos grandes (não contam em relação aos limites de armazenamento de dados padrão) ou sistemas de arquivamento externos. Objetos grandes adequados para arquivamento de alto volume com padrões de acesso previsíveis. O arquivamento externo para armazéns de dados ou armazenamento de objeto fornece a retenção de menor custo para dados de conformidade
✅ Exemplo: Casos mais antigos que 36 meses arquivados em objetos grandes com recuperação baseada em índice para acesso de conformidade | | Dados expirados do **modelo de dados** | ✅ **Dados expirados excluídos por meio de processos de ciclo de vida automatizados** \- Dados anteriores aos requisitos de retenção sem valor comercial devem ser excluídos por meio de processos automatizados em vez de serem acumulados indefinidamente. Muitas organizações nunca excluem dados devido a preocupações de "e se precisarmos disso algum dia", resultando em crescimento do armazenamento consumindo orçamento sem justificativa comercial
✅ Exemplo: A política de retenção de dados exclui automaticamente registros após sete anos com base nos requisitos de retenção regulatória | | **Configuração** → Visão geral do sistema → Armazenamento de dados
**Configuração** → Uso do armazenamento | ✅ Padrão:**** Os painéis de capacidade mostram o consumo de armazenamento por objeto com tendências de crescimento, o uso de API por integração a padrões de pico e a utilização de capacidade de processamento com projeções
✅ Habilite a otimização proativa antes que os limites criem interrupções ou cobranças excedentes inesperadas | | **Sem rastreamento de armazenamento** → Surpresas anuais | ⚡️ **Anti-Padrão**: Excedente de armazenamento descoberto durante a negociação de renovação exigindo compra imediata a precificação premium sem tempo para avaliar estratégias de arquivamento
⚡️ A organização compra armazenamento adicional anualmente sem analisar qual capacidade dos dados consome ou se o arquivamento reduziria o crescimento | ## Otimização do armazenamento de arquivos **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Arquivos grandes do **Salesforce Files** | ✅ **Integração de armazenamento de arquivos externos para poupança de custo em escala** \- Armazene arquivos em serviços como Amazon S3 ou Azure Blob Storage com o Salesforce mantendo registros de referência vinculados a conteúdo externo. O armazenamento externo custa US$ 0,02 a 0,05 por GB por mês em comparação ao armazenamento de arquivos do Salesforce a US$ 1-3 por GB por mês, dependendo da edição, criando 10 a 20 vezes mais economia de custo em escala
✅ Exemplo: A solução de gerenciamento de contrato armazena contratos ativos (últimos 24 meses) no Salesforce Files para visualização e colaboração nativas, migra automaticamente contratos mais antigos para o S3 com links do Salesforce, reduzindo o armazenamento de arquivos em 70% enquanto mantém o acesso
✅ Descontinuação: A integração de armazenamento externo requer esforço de desenvolvimento e introduz dependência de serviço externo, mas proporciona 10 a 20 vezes mais economia de custo para casos de uso pesados em arquivos, interrompendo até mesmo em meses | | Ciclo de vida do arquivo de **Gerenciamento de conteúdo** | ✅ **Gerenciamento de ciclo de vida arquiva ou exclui arquivos antigos** \- Implemente arquivo automatizado movendo arquivos além dos limites de retenção para armazenamento externo ou exclusão. Arquivos raramente acessados após a criação inicial, incluindo anexos de caso para casos fechados e versões de documentos substituídas, são os principais candidatos ao arquivamento
✅ Nota: O armazenamento de arquivos inclui Salesforce Files, anexos, documentos e conteúdo. Organizações com casos de uso pesados em documentos, incluindo gerenciamento de contratos, bibliotecas de ativos e anexos de caso, frequentemente se aproximam dos limites de armazenamento de arquivos mais rapidamente do que o armazenamento de dados | ## Otimização do armazenamento de sandbox **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Modelos de cópia parcial de **Gerenciamento de sandbox** | ✅ **Modelos de dados seletivos otimizam a capacidade de armazenamento de sandbox** \- Exclua objetos de grande volume de modelos de Cópia parcial quando o volume de dados completo for desnecessário para cenários de teste. Implemente a retenção de dados específica do sandbox removendo registros mais antigos do que o necessário para testes, liberando capacidade para dados de teste adicionais
✅ Exemplo: O modelo de sandbox de Cópia parcial inclui os últimos 12 meses de oportunidades e casos, mas exclui dados arquivados, fornecendo dados de teste representativos com capacidade de 5 GB em vez de exigir Cópia completa
✅ Descontinuação: Definir modelos de dados seletivos requer esforço de análise, mas permite usar tipos de sandbox de baixo custo eliminando dados desnecessários para cenários de teste | | Ritmo de atualização do **Gerenciamento de sandbox** | ✅ **Cadência de atualização alinhada aos requisitos reais de atualização de dados** \- Alinhe a atualização de sandbox aos requisitos reais de atualização de dados, em vez de agendas arbitrárias. Muitas organizações atualizam sandboxes de Cópia completa mensalmente quando a atualização trimestral seria suficiente para seus padrões de teste, desperdiçando capacidade de atualização que poderia dar suporte a sandboxes adicionais
✅ Exemplo: Sandbox de Cópia completa atualizado trimestralmente em vez de mensalmente, liberando capacidade de atualização para sandboxes de Cópia parcial adicionais | | Sandboxes temporários de **Gerenciamento de sandbox** | ✅ **Gerenciamento temporário de sandbox com políticas de expiração** \- Acompanhe ambientes criados para projetos específicos ou testes de pico com datas de exclusão documentadas. A proliferação temporária de sandbox é uma fonte comum de resíduos à medida que os sandboxes do projeto passam para o status permanente sem justificativa. Implementar políticas de expiração que exigem justificativa de renovação para manter ambientes temporários além do escopo inicial
✅ Exemplo: Sandbox de projeto criado com expiração de 90 dias exigindo justificativa comercial para se estender além da conclusão do projeto | ## Otimização de chamada de API **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Análise de pico de uso do **monitoramento de integração** | ✅ **Análise de pico de uso identifica oportunidades de otimização de agendamento** \- Identifique padrões de consumo diários e semanais. Agendas de integração concentradas durante o horário comercial competem com chamadas à API iniciadas pelo usuário. Espalhar integrações em lote em janelas fora do pico otimiza a utilização de capacidade sem aumentar os limites
✅ Exemplo: Integrações em lote reagendadas das 9h às 14h, reduzindo a contenção de API de horário de pico e habilitando integrações adicionais dentro da capacidade existente | | **Código personalizado** API 2.0 em massa | ✅ **API em massa 2.0 para qualquer operação processando centenas de registros** \- Use a API em massa 2.0 para qualquer operação processando mais de algumas centenas de registros. A API em massa processa até 150 milhões de registros por trabalho, consumindo o mínimo de chamadas à API em comparação ao processamento de registros individualmente
✅ Exemplo: A sincronização de dados noturna usa a API 2.0 em massa que processa 100 mil registros com consumo mínimo de API, em vez de chamadas de API individuais por registro | | Cache da plataforma de **código personalizado** | ✅ **Cache da plataforma elimina consultas repetitivas para dados de referência** \- Cache de dados de referência acessados com frequência para eliminar consultas repetitivas. Armazenar em cache códigos de país, catálogos de produtos ou dados de configuração reduz o consumo de API para integrações que consultam repetidamente dados de referência inalterados
✅ Exemplo: Catálogo de produtos armazenado em cache no Cache da plataforma, reduzindo as chamadas à API de mil consultas diárias para atualização de cache única | | Captura de dados de alteração da **arquitetura de integração** | ✅ **Captura de dados de alteração elimina padrões de pesquisa desperdiçados** \- Use a captura de dados de alteração para sincronização de dados em vez de padrões de pesquisa. O CDC publica eventos apenas quando os dados mudam, eliminando chamadas à API desperdiçadas verificando alterações que não ocorreram
✅ Exemplo: A sincronização de dados do cliente usa a Captura de dados de alteração para publicar eventos quando os clientes atualizam, consumindo chamadas à API apenas para alterações reais (200 diariamente) em vez de pesquisar cada registro do cliente por hora (1.2 milhões de consultas diárias)
✅ Descontinuação: A arquitetura conduzida por evento requer esforço de implementação de CDC ou Eventos de plataforma, mas reduz o consumo de API em 95%+ para padrões de detecção de alteração, interrompendo mesmo dentro de semanas | | **Sem monitoramento** → Reactive Discovery | ⚡️ **Anti-Padrão**: O consumo da API monitorado apenas quando ocorrem exceções de limite, criando mudanças reativas de arquitetura de emergência e combate a incêndios sob pressão
⚡️ Análise de tendência proativa ausente para habilitar a otimização antes que os limites restrinjam as operações comerciais | ## Custo da arquitetura de integração **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | **Padrão de integração** síncrono em tempo real | ✅ **Integrações síncronas consomem maior capacidade de API** \- Integrações em tempo real consomem uma ou mais chamadas de API por transação. Fluxos de transação de alto volume podem consumir uma capacidade de API significativa. Os padrões síncronos são adequados quando a consistência de dados imediatos é um requisito de negócio obrigatório, mas têm o maior custo de consumo da API
✅ Exemplo: A submissão do pedido requer verificação de inventário imediata e reserva no sistema ERP justificando padrão síncrono apesar do maior custo da API | | Processamento em lote de **padrão de integração** | ✅ As **integrações em lote reduzem o consumo de API em 90% + em comparação com os** registros síncronos - Processar em massa, reduzindo drasticamente as chamadas de API por registro. A API em massa 2.0 processa milhões de registros com o consumo mínimo da API. Adequado quando a sincronização quase em tempo real atende às necessidades de negócios e elimina 90% ou mais do consumo de API em comparação a padrões síncronos
✅ Exemplo: A sincronização de dados do cliente é executada em lote por hora, em vez de atualizações em tempo real, reduzindo o consumo de API em 95% com uma latência de dados de 1 hora aceitável | | Padrão de **integração** conduzido por evento | ✅ Os padrões conduzidos por **evento consumem eficientemente recursos apenas em mudanças reais** \- Use Eventos de plataforma ou Captura de dados de alteração para distribuição eficiente de eventos sem sobrecarga de consulta. Os padrões conduzidos por evento têm escala eficiente porque consomem recursos apenas quando ocorrem alterações reais, em vez de verificar repetidamente alterações que não ocorreram
✅ Exemplo: Alterações no estágio da oportunidade publicam eventos de plataforma consumidos por sistemas downstream, eliminando pesquisas e reduzindo o consumo de API em 98% | | **Plataforma de Integração** MuleSoft TCO | ✅ A **MuleSoft aumenta o custo da plataforma, mas pode reduzir o TCO total de integração** \- A MuleSoft Anypoint Platform aumenta o custo de licenciamento da plataforma (US$ 20K-200K+ por ano), mas pode reduzir o TCO total da integração por meio de armazenamento em cache inteligente, pool de conexões, otimização em lote e governança unificada em todos os padrões de integração
✅ Descontinuação: O middleware justifica o investimento quando a contagem de integração excede 5 a 7 conexões, proporcionando reutilizabilidade e governança que reduzem os custos de manutenção de longo prazo | | Precificação da API de **integração de terceiros** | ✅ **Custos da API de terceiros modelados com base em volumes de transações projetados** \- Modelos de custos de terceiros baseados em volumes de transações projetados que refletem o uso real, em vez de níveis mínimos que presumem volumes baixos. A precificação da API de terceiros varia de níveis gratuitos até faturamento medido por chamada para licenças corporativas de tarifa fixa
✅ Exemplo: O modelo de TCO de integração para o gateway de pagamento inclui taxa de plataforma anual de US$ 15 mil + US$ 0,10 por transação estimada em 50 mil transações anuais (US$ 5 mil) + desenvolvimento de integração de US$ 25 mil + manutenção anual de US$ 5 mil para um total de US$ 50 mil no primeiro ano, US$ 10 mil em andamento | | Manutenção de **integração** ponto a ponto vs. hub | ✅ As **integrações ponto a ponto multiplicam o esforço de manutenção exponencialmente** \- Cada ponto de integração inclui criação inicial, manutenção contínua, evolução do tratamento de erros e adaptação quando qualquer ponto final muda. Integrações ponto a ponto multiplicam o esforço de manutenção exponencialmente à medida que a contagem do sistema aumenta. Cinco sistemas com conexões de ponto a ponto exigem 10 fluxos de manutenção de integração. Dez sistemas exigem 45 fluxos. Padrões de hub-and-spoke por meio de plataformas de integração reduzem o crescimento exponencial para escala linear
✅ Exemplo: Organização com oito sistemas conectados faz a transição de 28 integrações de ponto a ponto para oito conexões de hub e spoke, reduzindo os fluxos de manutenção em 71%. | | Custos de suporte de **operações de integração** | ✅ Os custos de **suporte e solução de problemas aumentam com a contagem de integrações** \- Cada integração cria possíveis pontos de falha que exigem infraestrutura de monitoramento, configuração de alerta, documentação do manual de execução e capacidade de resposta a incidentes. Inclua custos de suporte contínuos no TCO de integração além do desenvolvimento inicial
✅ Exemplo: Custos de suporte de integração modelados a 15-20% do custo de desenvolvimento inicial anualmente para monitoramento contínuo, solução de problemas e resposta a incidentes | ## Armazenamento e API **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | ------------ | ------------------- | | **Todos os dados históricos permanecem no armazenamento ativo indefinidamente.** | ⚡️ Armazenar crescimento que consome orçamento sem justificativa de negócios. As organizações compram armazenamento adicional anualmente sem analisar quais dados consomem capacidade ou se as estratégias de arquivamento podem reduzir a taxa de crescimento
⚡️ **Remediação:** Defina a política de retenção de dados com estágios do ciclo de vida: ativo (0 a 12 meses), quente (12 a 36 meses), frio (36 meses ou mais arquivado) e expirado (excluído após a retenção regulatória). Implementar o arquivamento automatizado para objetos grandes ou armazenamento externo | | **O modelo de Cópia parcial inclui todos os objetos sem filtragem** | Consome capacidade de 5 GB com dados históricos irrelevantes para testes, forçando a compra de Cópia completa quando a seleção de dados estratégica habilitaria o uso de Cópia parcial a um custo significativamente menor
⚡️ **Remediação:** Analise os requisitos de teste e crie modelos seletivos de Cópia parcial, incluindo apenas os últimos 12 a 18 meses de dados e excluindo objetos de grande volume desnecessários para cenários de teste | | **A integração consulta todos os registros a cada 15 minutos para verificar alterações** | Consome 5 milhões de chamadas à API diariamente quando 95% das pesquisas não encontram alterações, desperdiçando capacidade da API em consultas desnecessárias. Cria risco de atingir limites de API e impedir a conclusão de integrações legítimas
⚡️ **Remediação:** Substitua o padrão de consulta por Captura de dados de alteração ou Eventos de plataforma que consomem chamadas à API apenas quando ocorrem alterações reais, reduzindo o consumo da API em 95%+ | | **A integração faz chamadas à API separadas para cada tipo de registro em sequência** | ⚡️ Multiplica o consumo da API de 5-10x em comparação a abordagens em lote. Processamento de pedido consumindo oito chamadas à API por pedido quando uma única chamada composta seria suficiente
⚡️ **Remediação:** Implemente operações relacionadas ao lote da API composta em uma única chamada à API, reduzindo o consumo de oito chamadas por transação para uma chamada por transação (87% de redução) | | **Sandboxes Full Copy comprados para cada equipe de desenvolvimento** | ⚡️ As multiplicações custam cinco vezes mais quando a Cópia parcial atenderia à maioria dos requisitos de teste. Cópia completa custa 5-10 vezes mais do que Cópia parcial e é atualizada apenas mensalmente versus a cada 5 dias
⚡️ **Remediação:** Reserve a Cópia completa exclusivamente para UAT pré-produção e validação de desempenho. Use o Developer Pro para desenvolvimento e Cópia parcial com modelos de dados direcionados para testes de integração | | **Integração aprovada com base no "nível de API livre" sem modelagem por volume** | ⚡️ Os volumes de transações projetados excederam o nível livre no mês 2, resultando em custos anuais de US$ 15 mil não incluídos na análise de orçamento ou TCO
⚡️ **Remediação:** Modele os custos da API de terceiros com base em volumes de transações projetados, incluindo projeções de escala. Inclua tarifas de plataforma, custos por transação e encargos excedentes no TCO de integração antes da aprovação | | **O consumo da API é monitorado apenas quando ocorrem exceções limites** | ⚡️ Cria alterações de arquitetura de emergência e combate a incêndios reativos sob pressão. Os limites criam interrupções antes que as oportunidades de otimização sejam identificadas
⚡️ **Remediação:** Implemente o painel de monitoramento de API proativo com atribuição de nível de integração, análise de uso de pico e projeção de crescimento. Defina alertas em limites de utilização de exemplo, como 70% e 85%, fornecendo tempo de processamento para otimização | | **Construindo a geração de documentos personalizados porque "temos desenvolvedores disponíveis"** | ⚡️ Desenvolvimento personalizado na compilação inicial de US$ 80 mil + manutenção anual de US$ 15 mil quando a opção do AppExchange de US$ 15 por usuário mensalmente (US$ 18 mil anualmente para 100 usuários) proporciona implementação mais rápida, manutenção do fornecedor e menor TCO de 5 anos
⚡️ **Remediação:** Avalie as soluções do AppExchange antes do desenvolvimento personalizado para recursos de commodities. TCO de modelo de 3-5 anos comparando a compilação e a compra, incluindo manutenção, compatibilidade da plataforma e custos de suporte | | **Sandboxes temporários de projetos passam para status permanente sem justificação** | ⚡️ Proliferação de sandbox que consome orçamento sem valor comercial. As organizações acumulam mais de 20 sandboxes quando 10 atendem às necessidades reais de desenvolvimento com o gerenciamento adequado do ciclo de vida
⚡️ **Remediação:** Implemente políticas de expiração de sandbox que exigem justificativa de renovação. Rastreie sandboxes com datas de exclusão documentadas e alertas automatizados para revisão de expiração | ## Recursos relacionados - [Pilar de Otimização de Recursos e Custo](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guides/resource-and-cost-optimization.md) - [Otimização de recursos e custos - Padrões de licença](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization-license-patterns.md) - Pilar de [Excelência Operacional](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guides/operational-excellence.md) --- **Última atualização**: 2026-06-08 # Ciclo de vida seguro de desenvolvimento – Padrões Saiba mais sobre Well-Architected [Trust](/docs/architect/pt-br/well-architected/guide/trust.html) → Ciclo de vida do [desenvolvimento seguro](/docs/architect/pt-br/well-architected/guide/trust.html#secure-development-lifecycle) A segurança deve ser integrada em todo o ciclo de vida do desenvolvimento, do design inicial até a implantação e operações. Esses padrões habilitam práticas de segurança de turno à esquerda, corrigem vulnerabilidades comuns e protegem seus pipelines de implementação. ## Segurança de turno esquerdo **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Desenvolvimento \| Conjunto de ferramentas | ✅ Verificação de segurança do IDE integrada ao fluxo de trabalho do desenvolvedor | | Desenvolvimento \| Design | ✅ Modelagem de ameaças concluída durante a fase de design usando a metodologia STRIDE | | Desenvolvimento \| Requisitos | ✅ Requisitos de segurança incluídos em histórias de usuário e critérios de aceitação | | Desenvolvimento \| Controle de origem | ✅ Ganchos pré-confirmação aplicam políticas de segurança (escaneamento secreto, análise de código) | | Desenvolvimento \| Treinamento | ✅ Treinamento de segurança do desenvolvedor atualizado regularmente para refletir ameaças em evolução | | Desenvolvimento \| CI/CD | ✅ O teste de segurança automatizado no pipeline CI/CD falha com base em descobertas críticas | | Desenvolvimento \| Revisão de código | ✅ Análises de colegas de segurança exigidas para autenticação, autorização e código de acesso a dados | | Desenvolvimento \| Análise de código | ✅ Padrões de codificação seguros impostos por meio de linters e análise estática | | Desenvolvimento \| Dependências | ✅ A verificação de vulnerabilidade de dependência é executada em cada confirmação | | Desenvolvimento \| Testes | ✅ O escopo de teste de penetração inclui novos recursos antes da versão GA | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Desenvolvimento \| Testes | Teste de segurança adiado para revisão manual antes da versão | | Desenvolvimento \| Treinamento | ⚡️ Treinamento de segurança realizado apenas uma vez durante a integração | | Desenvolvimento \| Revisão de código | ⚡️ A equipe de segurança revisa o código após a mesclagem | | Desenvolvimento \| Design | ⚡️ Modelos de ameaças não atualizados quando a arquitetura muda | | Desenvolvimento \| Controle de origem | ⚡️ Verificação secreta desabilitada para reduzir falsos positivos | | Desenvolvimento \| CI/CD | ⚡️ As descobertas de segurança ignoradas quando os prazos da versão chegam | ## Principais 10 OWASP para Salesforce **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Injeção | ✅ Consultas SOQL usam variáveis bind para evitar injeção | | Injeção | ✅ Entrada do usuário validada e limpa antes de usar em consultas SOQL, SOSL ou dinâmicas | | Injeção | ✅ SOQL dinâmico restrito apenas a entradas confiáveis | | Controle de acesso | ✅ Permissões CRUD e FLS impostas usando Security.stripInaccessible() | | XSS | ✅ Componentes do Lightning escapam conteúdo gerado pelo usuário na renderização da IU | | Injeção | ✅ Integrações de API externas validam e limpam todas as entradas | | Controle de acesso | ✅ Acesso do usuário convidado minimizado e fortemente restrito | | Autenticação | ✅ Credenciais nomeadas usadas para autenticação externa (não credenciais embutidas em código) | | Autenticação | ✅ Fluxos do OAuth 2.0 implementados corretamente com a PKCE | | Gerenciamento de sessão | ✅ As políticas de segurança da sessão impõem restrições de tempo limite e IP | | Configuração | ✅ Verificação de integridade de segurança revisada trimestralmente e descobertas de alto risco remediadas | | Controle de acesso | ✅ Metadados e permissões personalizados auditados para evitar privilégios excedentes | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Injeção | Consultas SOQL criadas usando concatenação de string com entrada do usuário | | Controle de acesso | Perfis de usuário convidado com as permissões Criar, Atualizar ou Excluir concedidas | | XSS | Componentes do Lightning usam expressões não escapadas em modelos | | Autenticação | ⚡️ Integrações externas usam credenciais embutidas em código | | Registrando | ⚡️ Os registros de depuração contêm dados confidenciais, como senhas ou PII | | Controle de acesso | ⚡️ Verificações FLS e CRUD omitidas porque "controla todos os usuários" | | Configuração | ⚡️ Descobertas da Verificação de integridade de segurança ignoradas ou adiadas indefinidamente | ## Design seguro de pipeline **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Pipeline \| Controle de origem | ✅ Regras de proteção de filial aplicam revisões obrigatórias e verificações de status | | Pipeline \| Controle de acesso | ✅ Os pipelines de implementação usam contas de serviço com o mínimo de permissões necessárias | | Funil \| Segredos | ✅ Segredos armazenados em cofres seguros (nunca em variáveis de ambiente ou controle de origem) | | Pipeline \| Implantação | ✅ Implantações de produção exigem a aprovação manual do pessoal autorizado | | Pipeline \| Auditoria | ✅ Os registros de implementação capturam quem implementou o que quando com trilhas de aprovação | | Pipeline \| Validação | ✅ A validação pré-implementação inclui verificações de conformidade e verificações de segurança | | Pipeline \| Controle de acesso | ✅ Autenticação multifator necessária para acesso administrativo ao pipeline | | Funil \| Monitoramento | ✅ Alterações na configuração do pipeline acionam notificações da equipe de segurança | | Pipeline \| Validação | ✅ A validação pós-implementação automatizada confirma os controles de segurança esperados ativos | | Pipeline \| Dependências | ✅ Atualizações de dependência avaliadas quanto ao impacto de segurança antes da implementação | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Funil \| Segredos | ⚡️ Segredos confirmados no controle de versão (mesmo que sejam removidos posteriormente) | | Pipeline \| Controle de origem | ⚡️ Qualquer pessoa pode ser mesclada com a ramificação principal/produção sem revisão | | Pipeline \| Controle de acesso | ⚡️ Os pipelines de implementação são executados com permissões em nível de administrador | | Pipeline \| Implantação | Implantações de produção totalmente automatizadas sem portões de aprovação | | Pipeline \| Auditoria | ⚡️ Os registros de implementação não capturam quem iniciou ou aprovou alterações | | Pipeline \| Validação | ⚡️ Verificações de segurança com falha ignoradas ou ignoradas para cumprir prazos | | Funil \| Monitoramento | Alterações de configuração do pipeline não rastreadas nem revisadas | | Pipeline \| Validação | ⚡️ A validação pós-implementação verifica apenas a correção funcional | ## Estratégia de teste de segurança **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Testar \| Análise estática | ✅ O Salesforce Code Analyzer é executado em IDEs do desenvolvedor para feedback imediato e em pipelines CI/CD como portões automatizados | | Testes \| Testes de penetração | ✅ Teste de penetração realizado para aplicativos personalizados expostos a usuários não confiáveis, especialmente sites do Experience Cloud e APIs voltadas para o público | | Testes \| Testes de unidade | ✅ Testes de unidade do Apex focados em segurança são executados como usuários com diferentes perfis de permissão | | Testar \| Dependências | ✅ A varredura de dependência monitora pacotes do AgentExchange e bibliotecas JavaScript quanto a vulnerabilidades conhecidas | | Testes \| Revisão de segurança | ✅ Relatório de análise estática preparado para cada envio do AppExchange ou da Análise de segurança do AgentExchange | | Testes \| Revisão de segurança | ✅ Relatório de verificação dinâmica (teste de penetração) preparado quando uma solução integra um aplicativo ou serviço da Web de terceiros | | Testar \| Dependências | ✅ Avisos de segurança para pacotes instalados assinados e monitorados | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Testar \| Cobertura | ⚡️ O teste de segurança depende de uma única técnica, como análise estática apenas | | Testes \| Testes de unidade | Os testes do Apex validam o comportamento funcional, mas nunca são executados como usuários com privilégios inferiores | | Testes \| Revisão de segurança | ⚡️ Envio do AppExchange ou do AgentExchange preparado sem a análise estática necessária ou relatórios de digitalização dinâmica | | Testes \| Testes de penetração | Teste de penetração ignorado para APIs e sites do Experience Cloud voltados para o público | ## Padrões relacionados Consulte também: - [Conformidade e padrões regulatórios](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-compliance-patterns.md) — Controles de governança e auditoria da plataforma - [Padrões de gerenciamento de identidade e acesso](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-identity-access-patterns.md) – autenticação e autorização - Padrões de [resposta a incidentes](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-incident-response-patterns.md) – detecção e resposta de incidentes de segurança - [Padrões agentes](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-agentic-patterns.md) — Controles de segurança específicos do agente # Confiabilidade Confiabilidade ## Visão geral 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. ### Confiabilidade e excelência operacional: Dois lados da mesma moeda A confiabilidade e a [excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) 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](/docs/architect/pt-br/well-architected/guide/trust.html) 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*. ## Princípios de design 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. ## Confiabilidade da plataforma: O que o Salesforce gerencia 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](http://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](http://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](http://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. ## Confiabilidade da solução: O que você projeta e gerencia 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: ### Metas de confiabilidade e SLOs #### Definir objetivos de nível de serviço 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. #### SLAs vs. SLOs vs. SLIs 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](http://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 realistas Metas de disponibilidade mais altas criam um aumento exponencial de complexidade e custo. Entenda as implicações arquitetônicas antes de confirmar as metas: | Meta | Tempo de inatividade anual | Tempo de inatividade mensal | Requisitos arquitetônicos | | :---- | :---- | :---- | :---- | | 99% | 3,65 dias | 7,3 horas | Recursos de plataforma padrão | | 99.5% | 1,83 dias | 3,6 horas | Redundância básica, monitoramento ativo | | 99.9% | 8,76 horas | 43,8 minutos | Sensibilidade de várias regiões, failover automatizado | | 99.95% | 4,38 horas | 21,9 minutos | Padrões ativos, teste de caos | | 99.99% | 52.6 minutos | 4,4 minutos | Arquitetura organizacional múltipla, automação abrangente | 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. #### Confiabilidade baseada em experiência do usuário 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. ### Arquitetura de alta disponibilidade #### Estratégias multarregionais 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. ### Padrões de várias organizações para cargas de trabalho críticas 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. #### Redundância em várias camadas 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. #### Monitoramento de integridade da plataforma Monitore a integridade da plataforma do Salesforce usando APIs de status específicas de instância e [Trust.salesforce.com](http://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. #### Detecção de falha 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. | Camada de detecção | Origem do sinal | O que captura | | :---- | :---- | :---- | | Falhas de plataforma | [Trust.salesforce.com](http://trust.salesforce.com), API de status | Incidentes de infraestrutura, manutenção | | Falhas de integração | Monitoramento de tempo limite, rastreamento de taxa de erro | Problemas do sistema externo, problemas de rede | | Falhas no aplicativo | Registro de exceções, taxas de sucesso da transação | Defeitos de código, erros de configuração | | Degradação do desempenho | Monitoramento de percentil de latência | Aceleração antes da conclusão de falhas | | Avisos de capacidade | Alertas de Proactive Monitoring | Limites do controlador se aproximando, esgotamento da API | 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. ### Escalabilidade e planejamento de capacidade #### Limites do controlador como restrições arquitetônicas 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: | Recurso | Limite síncrono | Limite assíncrono | Impacto arquitetônico | | :---- | :---- | :---- | :---- | | Consultas SOQL | 100 por transação | 200 por transação | Consolidação de consulta, consultas de relacionamento | | Instruções DML | 150 por transação | 150 por transação | DML em massa, operações de coleta | | Tamanho de heap | Síncrono de 6 MB | 12 MB assíncrono | Particionamento de dados, padrões de streaming | | Tempo de CPU | Síncrono de 10.000 ms | 60.000 ms assíncrono | Eficiência do algoritmo, descarregamento assíncrono | | Tempo limite de chamada | Total de 120 segundos | Total de 120 segundos | Orçamento de tempo limite entre chamadas | | Chamadas de API (24hrs) | Varia de acordo com a edição | N/A | Lotes de integração, cache | 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. #### Padrões de massificação 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. #### Processamento assíncrono para escala 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](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) 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. #### Particionamento e compartilhamento de dados 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. #### Planejamento de capacidade 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. #### Carregar teste 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. ### Tolerância e resiliência a falhas #### Padrões de degradação agradáveis 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: | Nível | Descrição | Comportamento de degradação | Exemplo | | :---- | :---- | :---- | :---- | | Crítico | Receita ou conformidade | Nunca degradado, redundância total | Processamento de pagamento, registro de auditoria | | Importante | Fluxos de trabalho do usuário principal | Diminuiu apenas durante incidentes importantes | Criação de caso, atualizações de oportunidade | | Suporte | Experiência aprimorada | Desabilitado durante qualquer falha de integração | Recomendações, aprimoramento | | Opcional | Recursos adequados para uso | Desabilitado proativamente durante alta carga | Widgets do Analytics, feeds sociais | 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. #### Padrão do circuit breaker 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. #### Repetir lógica e pendências exponenciais 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 #### Estratégias de fallback 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. #### Configuração de tempo limite 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 **f**ilos 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. #### Arquitetura de tratamento de erros 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. ### Recuperação de desastres e continuidade dos negócios #### Objetivo de tempo de recuperação (RTO) 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: | Tipo de capacidade | RTO típico | Implicação arquitetônica | | :---- | :---- | :---- | | Operações críticas à receita | Minutos | Failover automatizado, espera rápida | | Serviços voltados ao cliente | 1 a 4 horas | Warm standby, recuperação scriptada | | Ferramentas de negócios internas | 4 a 24 horas | Emergência fria, recuperação manual | | Relatórios históricos | Dias | Restaurar do backup sob demanda | 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. #### Objetivo de ponto de recuperação (RPO) 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. | Tipo de dados | RPO típico | Estratégia de replicação | | :---- | :---- | :---- | | Transações financeiras | Quase zero (segundos) | Replicação assíncrona acionada por evento em cada confirmação | | Registros do cliente | Quase zero (minutos) | Alterar captura de dados, replicação assíncrona | | Dados do Analytics | Horas | Sincronização de lote agendada | | Estado de fluxo de trabalho temporário | Dias | Nenhuma replicação necessária | 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. #### Estratégias de backup 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. #### Estratégias de replicação de dados 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 de recuperação de desastres 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. #### Planejamento de continuidade dos negócios 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. ### Monitoramento e capacidade de observação para confiabilidade #### Modelagem de saúde 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: | Dimensão de saúde | Sinais | Verde | Amarelo | Vermelho | | :---- | :---- | :---- | :---- | :---- | | Integridade do serviço | Taxa de sucesso da transação | >99.5% | 98–99.5% | <98% | | Integration health | Disponibilidade do sistema externo | Todos respondendo | Resposta reduzida | Interruptor aberto | | Integridade dos dados | Sucesso do trabalho de sincronização, qualidade dos dados | Todos os atuais | Atrás da agenda | Falha ou desatualizado | | Integridade da capacidade | Consumo do limite do controlador | <70% | 70–85% | >85% | 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. #### Monitoramento de plataforma 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. #### Monitoramento de desempenho do aplicativo 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. #### Monitoramento de integridade 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. #### Proactive Monitoring 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. #### Detecção de anomalia 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. ## Lista de verificação de resumo 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.

# Confiabilidade – Padrões O pilar de Confiabilidade foca a disponibilidade do sistema, o desempenho, a recuperação de desastres e a escalabilidade para que suas soluções suportem falhas e sejam dimensionadas conforme a demanda. Esses padrões transformam os princípios de design do pilar em práticas concretas revisáveis: o que procurar em uma solução, o que é bom e os antipadrões que a minam. ## Princípios de design Esses padrões colocam os princípios de design do pilar de Confiabilidade em prática. Leia-os junto com o [pilar Confiabilidade](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/reliability.md) para obter a orientação completa por trás de cada um. - **Distribuir a carga de trabalho por meio da massificação** – processe em lotes para que um pico no volume não esgote os limites do regulador. - **Assuma que tudo falha** — projetar para a falha de cada dependência, não apenas as que você espera. - **Construir sistemas auto-recuperação** \- recuperar automaticamente de falhas temporárias em vez de exigir intervenção manual. - **Design para os requisitos de negócios em primeiro lugar** — metas de disponibilidade de terreno e recuperação no impacto de negócios, não números de tempo de atividade arbitrários. - **Valide a recuperação por meio de exercícios** — prove que seus procedimentos de recuperação de desastres funcionam antes de você precisar deles. ## Como usar estes padrões Cada categoria combina **padrões** (o que parece bom) com **antipadrões** (o que evitar), organizados para que você possa revisar uma área de solução por área. Comece com o resultado de confiabilidade de que você precisa: - **Definir ou defender metas de disponibilidade e latência?** Comece com a opção **Disponibilidade e desempenho** para determinar o impacto dos SLOs nos negócios antes de escolher uma arquitetura. - **Proteger contra perda de dados ou falha regional?** Use a **Recuperação de desastres** para alinhar os procedimentos de backup, failover e continuidade de negócios ao seu RPO/RTO. - **Lidar com crescimento ou carga picante?** Use a **Escalabilidade** para massificar cargas de trabalho e manter-se dentro dos limites do regulador conforme o volume aumenta. - **Agentes operacionais na produção?** Use **Padrões agentes** para cadeias de fallback, tratamento de tempo limite e monitoramento de saúde dos agentes. ## Categorias de padrão ### [Padrões agentes](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/reliability-agentic-patterns.md) Padrões específicos de confiabilidade para sistemas agentes, incluindo estratégias de fallback, tratamento de tempo limite e monitoramento de saúde do agente. ### [Disponibilidade e desempenho](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/reliability-availability-performance-patterns.md) Padrões para alta disponibilidade, otimização de desempenho, armazenamento em cache e gerenciamento de carga. ### [Recuperação de desastres](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/reliability-disaster-recovery-patterns.md) Padrões para estratégias de backup, recuperação de dados, continuidade dos negócios e procedimentos de failover. ### [Escalabilidade](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/reliability-scalability-patterns.md) Padrões para escala horizontal e vertical, gerenciamento de limite do regulador e gerenciamento de crescimento. ## Recursos relacionados - [Pilar de confiabilidade](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/reliability.md) — os princípios de projeto e orientação arquitetônica que esses padrões implementam - [Confiabilidade para a empresa agente](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/agentic-enterprise-reliability.md) – orientação de confiabilidade para soluções baseadas em agente - [Framework bem arquitetado](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/framework.md) — como a confiabilidade se encaixa junto com os outros pilares - [Padrões e Antipadrões](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/patterns-and-anti-patterns.md) — a biblioteca completa de padrões em todos os pilares # Confiabilidade – Padrões de recuperação de desastres
Saiba mais sobre a [confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html) bem construída → [Recuperação de desastres e continuidade dos negócios](/docs/architect/pt-br/well-architected/guide/reliability.html#disaster-recovery-and-business-continuity) ## Fazer backup e restaurar **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. | ## Planejamento de continuidade dos negócios **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. | ## RPO/RTO **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. | ## Redundância **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. | # Confiabilidade para a empresa agente Confiabilidade para a Agência ## Visão geral Os agentes autônomos apresentam padrões de execução não deterministas fundamentalmente diferentes da automação tradicional do Salesforce. Enquanto o Salesforce Flow e o Apex seguem caminhos previsíveis que produzem resultados repetíveis em condições controladas, os agentes explicam os problemas dinamicamente. Por exemplo, a mesma pergunta feita duas vezes pode seguir caminhos de execução diferentes, consumir recursos diferentes e produzir resultados diferentes. Esse não determinismo cria desafios de confiabilidade que as abordagens tradicionais de teste e monitoramento não abordam. Os modos de falha de confiabilidade do agente são categoricamente diferentes das falhas do Salesforce Flow ou do Apex. Os serviços de inferência de modelo de idioma grande (LLM) representam dependências externas com características de disponibilidade separadas da Salesforce Platform. Os agentes geram respostas que ocasionalmente violam a estrutura esperada, apesar das instruções de prompt. A preparação de contexto do agente consome os limites do controlador de modo imprevisível. A recuperação de dados sem limite afeta os agentes mais severamente porque os agentes podem solicitar contexto de término aberto, enquanto as consultas determinísticas têm controle de escopo explícito. Uma arquitetura de agente confiável exige uma cadeia de fallback de vários níveis que se degrada de modo simples: de agentes sofisticados a agentes mais simples com contexto reduzido, a mecanismos de regras deterministas e, por fim, a transferência humana por meio do Omni-Channel. Os Eventos de plataforma aprimoram filas de novas tentativas duráveis com padrões de ponto de verificação, permitindo que fluxos de trabalho com falha sejam retomados da última etapa bem-sucedida. Os interruptores de circuito rastreiam a integridade do serviço LLM no Cache da plataforma para status em tempo real, com o suporte de Tipos de metadados personalizados para limites e configuração, roteando para padrões de fallback após falhas consecutivas. O monitoramento exige rastrear as taxas de sucesso da conversa, o tempo médio entre falhas (MTBF), o tempo médio até a recuperação (MTTR) e a precisão de fundamentação. A Agentforce Observability fornece rastreamentos de sessão, métricas de integridade e latência, e taxas de escalação e desvio, mas você ainda precisará instrumentar métricas de confiabilidade como MTBF, MTTR e precisão de fundamentação. Este documento abrange as alterações quando os agentes estão no cenário. Para obter padrões de confiabilidade fundamentais aplicáveis a todas as soluções do Salesforce (design de objeto de nível de serviço (SLO), tolerância a falhas, escalação e monitoramento), consulte o pilar [Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html). ## Modos de falha específicos do agente Agentes Agentforce falham de maneiras diferentes do Salesforce Flow ou do Apex. É entender esses modos de falha que moldam a arquitetura de confiabilidade. - **Indisponibilidade do serviço LLM:** Os pontos de extremidade de inferência do LLM enfrentam picos de latência ocasionais ou problemas de disponibilidade. Agentforce é listado como um produto monitorado em [trust.salesforce.com](http://trust.salesforce.com) junto com o Analytics e outros serviços do Salesforce. No entanto, a latência de inferência de LLM granular e as métricas de desempenho por solicitação não são expostas lá. Implemente os disruptores de circuito usando o Cache da plataforma para o estado em tempo real de baixa latência, com suporte em Tipos de metadados personalizados para limites e configuração, para rastrear a integridade do serviço do LLM. O Cache da plataforma é o melhor esforço: as entradas podem ser expulsas antes de seu tempo de ativação (TTL), portanto, mantenha o estado aberto/descartado em um repositório durável, como um Objeto personalizado, em vez de apenas no cache. Ajuste a condição da viagem para o ponto de extremidade: uma contagem de falhas consecutivas (por exemplo, cinco) ou uma taxa de erro que ultrapassa um limite em uma janela dinâmica. Quando o circuito viaja, abra-o e encaminhe para padrões de fallback, como avisos mais simples, respostas em cache ou transferência humana, até que uma solicitação de teste bem-sucedida indique a recuperação. - **Falhas de validação de resposta:** Os agentes ocasionalmente geram respostas que violam a estrutura esperada, apesar das instruções de prompt. Às vezes, um agente retorna JSON malformado, omite campos obrigatórios ou inclui tipos de dados inesperados. O Cache da plataforma pode armazenar esquemas de resposta validados, habilitando a validação rápida. Quando a validação falha, tente novamente com avisos refinados, incluindo o erro de validação e um exemplo de estrutura correta. Defina um número máximo de novas tentativas (3 a 5) para evitar loops infinitos de novas tentativas. - **Detecção de alucinação:** Quando os dados de fundamentação estão incompletos, os agentes produzem informações plausíveis, mas incorretas. Diferentemente de consultas determinísticas que retornam "não encontrado", os agentes preenchem lacunas com inferência. A Trilha de auditoria da Camada de Trust do Einstein registra cada aviso, aviso mascarado, resposta, resultado da detecção de toxicidade e feedback do usuário para revisão de governança pós-hoc. No entanto, ele não captura rastreamentos de raciocínio passo a passo. Para captura de raciocínio passo a passo, use o Rastreamento de sessão do Agentforce, que registra as execuções do mecanismo de raciocínio. Exija que os agentes citem fontes de recuperação de geração aumentada por recuperação (RAG) do Data 360 (antigo Data Cloud). Reivindicações de agente de referência cruzada contra origens recuperadas para capturar desvios fatos antes da execução da ação. Uma verificação em linha adiciona pouca latência, pois é executada em fontes que já estão no contexto. Uma verificação que precisa de uma viagem de ida e volta separada, como uma segunda chamada de modelo ou um serviço externo, custa mais. Reserve essas verificações para gravações de alto impacto, incluindo atualizações financeiras ou de pedido, e execute-as de modo assíncrono durante a conversa em tempo real. - **Governor limit picos:** A preparação de contexto do agente consome consultas de linguagem de consulta de objeto (SOQL) do Salesforce, tempo de CPU e memória de heap de modo imprevisível com base no fluxo de conversa. O Proactive Monitoring é um serviço de direitos do Signature Success (antigo Suporte de assinatura) no [Plano Salesforce Success](https://www.salesforce.com/services/success-plans/), em que o Salesforce monitora proativamente as contas dos clientes. O Proactive Monitoring não é um alerta configurável por autoatendimento disponível a todos os clientes. Para monitoramento de limite do regulador de autoatendimento, use o [Centro de escala](https://help.salesforce.com/s/articleView?id=xcloud.scale_center_overview.htm&type=5) para identificar operações de agente com uso intensivo de recursos que se aproximam dos limites. Implemente a paginação em ações do agente recuperando grandes coleções de registros. Para dados de referência acessados com frequência, use o Cache da plataforma. - **Dados discrepantes no contexto do agente:** Os agentes que recuperam contexto para contas com mais de 10 mil oportunidades, ou casos com históricos de atividades comparáveis, encontram os mesmos desafios de distorção de dados que o Apex em lote. Diferentemente de consultas determinísticas em que você controla o escopo, o raciocínio do agente pode solicitar "todo o histórico" de modo imprevisível. Para evitar isso, projete ações do agente com limites rígidos sensíveis (por exemplo, um limite na ordem de 200 filhos por pai) e implemente estratégias de amostragem quando os limites forem excedidos. O limite define quantos dados entram no contexto do agente. Combine-o com filtros seletivos indexados para que a consulta em si fique barata, pois um filtro não indexado ou agregado em um pai discrepante verifica o conjunto filho completo antes da aplicação do limite. ## Degradação generosa com cadeias de fallback Projete cadeias de fallback de vários níveis, permitindo que os agentes continuem funcionando com capacidade reduzida em vez de falhar completamente. - **Agente principal com contexto completo:** Agente sofisticado com a fundamentação completa do Data 360, amplo histórico de conversas e raciocínio complexo. Qualidade mais alta, mas com maior uso de recursos e maior risco de falha. - **Agente secundário com contexto reduzido:** Agente mais simples usando contexto condensado (por exemplo, últimos 30 dias vs. todo o histórico, os cinco principais resultados da pesquisa do vetor versus os 20 principais). O contexto menor significa menos tokens, inferência mais rápida e menor probabilidade de falha, mas somente se o contexto reduzido ainda abranger os dados de que a tarefa precisa. - **Mecanismo de regras deterministas:** Fluxo do Salesforce tradicional ou lógica do Apex que lida com cenários comuns quando o raciocínio do agente falha. As regras não podem se adaptar a novas situações, mas lidam com padrões conhecidos com confiança. O agente de validação de pedido volta para regras de validação padrão, enquanto o agente de pontuação de lead volta para o cálculo de pontuação baseado em regra. - **Envio humano via Omni-Channel:** Roteie para a fila humana quando as opções automatizadas estiverem esgotadas. Configure o roteamento baseado em habilidades para garantir que os escalonamentos alcancem o conhecimento adequado. Passe todo o contexto da conversa, incluindo tentativas de estratégias, quaisquer pontuações de confiança que você calcular para o agente e motivos de falha, para habilitar uma intervenção humana eficiente. Implemente a lógica de fallback na orquestração do Salesforce Flow ou do Apex acionada por Eventos de plataforma. Cada nível registra qual estratégia foi bem-sucedida, criando visibilidade dos padrões de falha e da eficácia de fallback. ## Eventos de plataforma para resiliência do agente Todos os padrões de Evento de plataforma nesta seção presumem tipos de Evento de plataforma de alto volume, que fornecem a janela de retenção de repetição de 72 horas. Eventos de plataforma de volume padrão são retidos por apenas 24 horas. Use tipos de evento de alto volume para todos os padrões de resistência do agente, fila de nova tentativa e ponto de verificação em que a durabilidade de repetição é um requisito de confiabilidade. Os Eventos de plataforma fornecem mensagens duráveis que permitem que os fluxos de trabalho do agente sobrevivam a falhas e se recuperem automaticamente. - **Progresso do agente do ponto de verificação:** Fluxos de trabalho de agente de várias etapas publicam eventos de ponto de verificação após cada etapa bem-sucedida. O agente de processamento de contrato conclui a extração de documento, publica o evento ContractParsed com os dados extraídos e avança para a análise da cláusula. Se a análise de cláusula falhar, reproduza o evento ContractParsed para retomar dos dados extraídos sem analisar novamente. Isso funciona quando a carga útil do ponto de verificação carrega esses dados e o assinante é idempotente, pois a reprodução reenvia eventos em vez de retomar um fluxo de trabalho no meio da etapa. Armazene o estado do ponto de verificação na carga útil do evento, incluindo ID de correlação, etapas concluídas e estado necessário para continuação. - **Fila de repetição com recuo exponencial:** Solicitações de agente com falha são publicadas no evento AgentRetryRequested com contagem de novas tentativas na carga útil. O assinante do evento processa novas tentativas com atrasos exponenciais em pendências (por exemplo, 30 segundos, 2 minutos, 8 minutos, 30 minutos). Após o máximo de novas tentativas (geralmente 5), encaminhe para a fila de falhas e operações de alerta. Os **eventos de plataforma de alto volume** preservam uma janela de repetição de 72 horas. Use o tipo de evento de alto volume para filas de nova tentativa do agente para que os assinantes possam acompanhar as janelas de manutenção da organização ou o tempo de inatividade da implementação. Eventos de plataforma de volume padrão são retidos por apenas 24 horas. - **Orquestração acionada por evento:** Projete fluxos de trabalho do agente como cadeias de eventos soltas. A criação de lead publica LeadCreated. O agente de pontuação de lead assina, pontua e publica LeadScored. O agente de roteamento de lead assina LeadScored e atribui à fila apropriada. Cada agente pode falhar e tentar novamente de modo independente. Uma falha de um único agente não bloqueia todo o fluxo de trabalho – os agentes a jusante processam quando as dependências são recuperadas. - **Rastreamento de ID de correlação:** Inclua um ID de correlação como um campo personalizado em todas as cargas úteis de evento relacionadas. Repita eventos usando a API Pub/Sub by replayId, um identificador opaco e não contíguo, para reconstruir o histórico de fluxo de trabalho dentro da janela de retenção de 72 horas. Para habilitar a depuração baseada em ID de correlação, implemente um padrão no lado do assinante que registra eventos recebidos com seu replayId e ID de correlação em um objeto personalizado, habilitando o rastreamento entre eventos. Esse padrão de registro é uma implementação personalizada que você mesmo cria, não uma funcionalidade de consulta de plataforma nativa. ## Processamento assíncrono para cargas de trabalho do agente Mova operações de agente que excedem limites síncronos para um contexto assíncrono, o que permite limites de controlador maiores e tempos limite mais longos. - **Apex em lote para operações de agente em massa:** Um agente que analisa mais de 1.000 registros se beneficia do Apex em lote que fornece 200 consultas SOQL, 150 instruções DML (até 10.000 linhas DML) e 60.000 milissegundos (60 segundos) de tempo de CPU por método de execução. Agente de pontuação de lead processando importações de leads noturnas. Análise de sentimento do caso em casos históricos. Previsões de oportunidade analisando pipelines completos. - **Cadeias enfileiráveis para fluxos de trabalho em várias etapas:** Fluxos de trabalho de agente complexos que exigem várias chamadas de API externas, análise de conjunto de dados grande ou tempo de processamento estendido usam cadeias do Apex enfileiráveis. Cada trabalho enfileirável obtém 60 CPU de tempo e 12 MB de heap. Encadeie para o próximo enfileirável para fluxos de trabalho que excedem os limites de trabalho único. Acompanhe o progresso em Objetos personalizados para que um trabalho com falha possa ser retomado na última etapa concluída. - **@future para transferências assíncronas simples:** Operações de agente leves, como envio de notificações, registro em sistemas externos ou atualizações não urgentes, usam métodos @future. O padrão de foco e esquecimento é adequado quando um fluxo de trabalho não precisa de resultados de volta e pode tolerar falha. Monitore a capacidade de processamento assíncrono por meio da página Trabalhos do Apex (Configuração → Trabalhos do Apex) e da Fila Flex do Apex. Um máximo de 5 trabalhos em lote simultâneos limita o processamento de agente paralelo; fila de trabalhos adicionais na Fila flexível do Apex, que contém até 100 trabalhos no status de Espera. Todos os tipos de Apex assíncronos, Lote, Futuro, Enfileirável e Agendado do Apex compartilham o mesmo limite diário em toda a organização (**DailyAsyncApexExecutions**) em execuções assíncronas do Apex: maior que 250 mil ou 200 vezes o número de licenças de usuário. Quando você executa a pesquisa de agente de alta frequência ou tenta novamente as filas do assinante, o Filas pode rapidamente esgotar essa cota. Para evitar isso, coloque essas filas em lote ou no limite para permanecer dentro do limite, o que se aplica em toda a organização em todos os tipos assíncronos do Apex, não como uma alocação separada apenas para o Queueable. Alerte quando o consumo se aproximar desses limites para que as equipes possam gerenciar a capacidade de modo proativo. ## Testar a confiabilidade do agente Valide a resiliência do agente antes da produção por meio de estratégias de teste que lidam com o comportamento não determinista. - **Teste de carregamento no Full Copy Sandbox:** Teste o desempenho do agente sob a carga em escala de produção usando volumes de dados completos. Simule conversas simultâneas que correspondem à demanda máxima. Meça a latência p95 e p99, identificando a degradação do desempenho sob estresse. Validar o consumo do limite do regulador permanece abaixo dos limites na carga máxima. O carregamento de testes em um sandbox de Cópia parcial com dados reduzidos proporciona confiança enganosa, pois o volume de dados afeta diretamente o desempenho do agente. Antes de executar esses testes, obtenha a aprovação da Salesforce (pelo menos uma semana antes para solicitações de teste de desempenho). Testes não aprovados podem ser limitados ou bloqueados. - **Injeção de falha:** Introduza intencionalmente falhas para validar mecanismos de recuperação. Simule falhas de inferência do LLM na camada de serviço que seu disjuntor monitora para verificar se o disjuntor é ativado. Injecte exceções SOQL para testar o tratamento de erros. Respostas corrompidas do agente para testar a lógica de validação. Apresente o desvio de dados (contas com mais de 10.000 filhos) para testar a lógica de paginação. Defina tempos limite agressivos para testar a manipulação de tempo limite e tentar estratégias novamente. - **Engenharia de caos:** Desabilite aleatoriamente os assinantes de Evento de plataforma para testar a recuperação de reprodução. Encerre trabalhos assíncronos no meio da execução para testar a reinicialização do ponto de verificação. Apresente a latência variável a sistemas externos para testar estratégias de tempo limite progressivo. Experimentos de caos validam a resiliência em combinações de falha realistas. Agende dias de caos regulares em ambientes de preparação, mantendo a resiliência à medida que os agentes evoluem. - **Testes de estabilidade de longa duração:** Execute cargas de trabalho do agente continuamente por mais de 72 horas, monitorando falhas dependentes de tempo. Erros acumulados e degradação gradual do desempenho só surgem em operação sustentada. Acompanhe tendências de tempo de CPU para identificar degradação gradual ao longo da execução. ## SLIs do agente de monitoramento Defina indicadores de nível de serviço (SLIs) habilitando a medição de confiabilidade do objeto. Estabeleça SLOs antes de criar agentes, não após falhas de produção. - **Taxa de sucesso da conversa:** Percentual de conversas do agente concluídas sem erros ou tempos limite. Conta uma transferência agradável para um ser humano como um sucesso, não como uma falha: a escalação é o nível de fallback final por design. Conte escalonamentos com falha ou inadvertidos com base na métrica – é um sinal de confiabilidade útil, mas um proxy imperfeito para a experiência do usuário, pois um logout educado pode mascarar um problema não resolvido. Acompanhe separadamente por tipo de agente e caso de uso, pois os critérios de sucesso da pontuação de lead diferem da revisão do contrato. Alerte quando a taxa de sucesso cair abaixo do SLO (geralmente de 95 a 99%). - **Tempo médio entre falhas (MTBF):** Tempo médio de operação entre falhas do agente. MTBF maior indica menos falhas e maior confiabilidade. Calcule como o total de horas operacionais do agente dividido pela contagem de falhas. Acompanhe por tipo de agente para identificar os agentes menos confiáveis que exigem investimento na otimização. - **Tempo médio até a recuperação (MTTR):** Tempo médio da detecção de falha até a restauração do serviço. A recuperação automatizada por meio de repetição de evento de plataforma e quebradores de circuito restaura o serviço com muito mais rapidez e com menos erro manual do que a intervenção prática. MTTR inferior reduz o impacto dos negócios por incidente. - **Precisão de aterrissagem:** Percentual de respostas do agente factualmente corretas com base na validação dos dados de origem. Amostras de respostas aleatórias do agente para validar declarações em fontes do Data 360. A precisão da fundamentação abaixo de 95% indica problemas de alucinação que exigem refinamento imediato ou melhor recuperação de contexto. - **Falhas de repetição de evento de plataforma:** Contagem de eventos perdidos ou não entregues, por exemplo, um assinante offline além da janela de retenção. Lacunas zero são um sinal positivo de uma arquitetura orientada por evento saudável. Lacunas indicam problemas do assinante, falhas na publicação de eventos ou restrições de capacidade. Acompanhe essas lacunas com o padrão de registro no lado do assinante descrito acima e registre o replayId e o ID de correlação de cada evento em um objeto personalizado. ## Criar agentes confiáveis Agentes confiáveis vêm de projetar antecipadamente para falhas: definir SLIs/SLOs, manipulação de contexto sensível ao limite do regulador e cadeias de fallback de vários níveis antes de criá-las, em vez de aprimorá-las posteriormente. Interruptores de circuito de camada e lógica de ponto de verificação baseada em evento de plataforma para que os fluxos de trabalho sejam recuperados automaticamente, com transferência humana como último recurso. Valide esse projeto por meio de carregamento sistemático, injeção de falhas e teste de caos e, em seguida, continue monitorando os mesmos SLIs em produção para confirmar que ele se mantém com o tempo. A orientação de confiabilidade no principal pilar de [Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html) se aplica a agentes com considerações específicas da plataforma abordadas aqui. Arquiteturas de agente bem-sucedidas equilibram a funcionalidade autônoma com a supervisão adequada, permitindo a auto-recuperação de falhas temporárias enquanto escalam quando a confiança diminui ou casos de ponta aparecem.

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

# Detecção de viés e imparcialidade de IA – Padrões agentes Saiba mais sobre [Fairness](/docs/architect/pt-br/well-architected/guide/fairness.html) bem arquitetado → [Agent Enterprise Fairness](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-fairness.html) ## Detecção e mitigação de viés **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Configuração do agente | ✅ Teste os agentes sistematicamente quanto ao viés demográfico usando diversas personas representando grupos protegidos; gere solicitações idênticas variando apenas sinais demográficos, como nomes, locais ou estilos de comunicação | | Data 360 \| Segmentos de dados | ✅ Antes de usar dados do Salesforce para treinamento do agente ou fundamentação de RAG, audite a representação demográfica e identifique grupos subrepresentados | | Data 360 \| Base de Knowledge | ✅ Auditar bases de Knowledge e fontes de recuperação para o equilíbrio demográfico; garantir que a qualidade, a completude e a exatidão da documentação sejam comparáveis em todos os segmentos de clientes | | Agentforce \| Monitoramento do agente | ✅ Monitore interações do agente entre grupos demográficos para a consistência do comportamento; analise a duração da resposta, o nível de detalhes, os marcadores de educadeza e a qualidade da solução estratificados por características do usuário | | Agentforce \| Monitoramento do agente | ✅ Detectar loops de feedback monitorando alterações de distribuição de decisão ao longo do tempo; quebrar loops por meio de revisão humana de casos de ponta e reequilibramento periódico | | Data 360 \| Dados de treinamento | ✅ Exemplo de grupos demográficos subrepresentados em dados de treinamento garantindo representação equilibrada; sintetize dados adicionais usando técnicas como SMOTE quando os dados reais forem insuficientes | | Agentforce \| Modelo de prompt | ✅ Restringir o comportamento do agente por meio de avisos do sistema: "Tratar todas as demografias do cliente com o mesmo profissionalismo e detalhes. Forneça explicações de comprimento e qualidade comparáveis, independentemente do estilo ou do segundo plano de comunicação do cliente." | | Einstein \| Modelo de previsão | ✅ Calcule coeficientes de correlação entre todos os recursos do modelo e características protegidas; avalie se o valor preditivo legítimo justifica a inclusão de recursos altamente correlacionados | | Einstein \| Modelo de previsão | ✅ Identifique e remova recursos de proxy que estão correlacionados com características protegidas (proxy de código zip para raça, proxy de padrões de nome para gênero/etnia, proxy de tempo de comunicação para religião/atendimento, proxy de tipo de dispositivo para renda, proxy de atribuição de território para composição demográfica) | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Data 360 \| Dados de treinamento | ⚡️ Usar dados históricos do CRM para treinamento do agente sem auditar a representação demográfica, permitindo um viés algorítmico para complicar o viés humano | | Agentforce \| Configuração do agente | ⚡️ Implementar agentes sem testes de viés demográfico sistemáticos em várias personas que representam grupos protegidos | | Data 360 \| Base de Knowledge | ⚡️ Fornecer artigos do Knowledge detalhados para clientes corporativos, mas apenas respostas genéricas para clientes de pequenas empresas, perpetuando disparidades de qualidade de serviço | | Agentforce \| Monitoramento do agente | Permitir que os agentes adaptem o comportamento com base em dicas conversacionais correlacionadas a características protegidas (estilo de comunicação, complexidade de linguagem, padrões de tempo) sem monitoramento | | Einstein \| Modelo de previsão | Incluir recursos de proxy (código zip, padrões de nome, tipo de dispositivo) em modelos de decisão consequente sem avaliar a correlação com características protegidas | | Agentforce \| Configuração do agente | Permitir loops de feedback em que as decisões do agente criam a discrepância que justifica futuras decisões adversas (por exemplo, roteamento do agente reduzindo oportunidades para determinados territórios, gerando menos dados de sucesso, reduzindo ainda mais o sucesso previsto) | | Data 360 \| Segmentos de dados | ⚡️ Referências de cultura majoritária como padrão em exemplos de conteúdo que alienam usuários subrepresentados | ## Orquestração de vários agentes **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Monitoramento do agente | ✅ Registrar entradas e saídas completas para cada agente em uma cadeia de orquestração para que o viés em um resultado final possa ser rastreado de volta para o estágio que o lançou e onde a ampliação ocorreu | | Plataforma \| CRM Analytics | ✅ Crie painéis mostrando distribuições de decisão em cada estágio de orquestração divididas por demografia para identificar onde as discrepâncias na cadeia surgem ou se expandem | | Plataforma \| CRM Analytics | ✅ Calcule a paridade demográfica, a igualdade de oportunidades e o impacto distinto em cada estágio da cadeia, não apenas no resultado final; métricas de estágio capturam a composição que parece aceitável em qualquer estágio, mas degrada em toda a cadeia | | Agentforce \| Configuração do modelo | ✅ Maximize a diversidade entre agentes em padrões de consenso para reduzir erros correlacionados: diferentes modelos de base quando possível (como por meio de configurações de Traga o seu LLM), diferentes origens de recuperação, diferentes abordagens de prompt e diferentes calibrações de limite de confiança | | Agentforce \| Configuração do agente | ✅ Insira revisão humana em pontos de inflexão da orquestração em que um estágio restringe significativamente as opções a jusante, mesmo quando a confiança do agente individual é alta, pois a orquestração cria efeitos emergentes que as pontuações de confiança por agente não capturam | | Agentforce \| Configuração do agente | ✅ Configure quebradores de circuito de orquestração que param e aumentam para um humano quando a confiança de qualquer agente cair abaixo do limite, produzir turnos de distribuição de saída significativos entre os estágios, a cadeia encontrar dados não representados no treinamento ou na validação ou o usuário desafiar uma decisão intermediária | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Monitoramento do agente | Executar cadeias de orquestração sem registrar entradas e saídas de cada agente, impossibilitando rastrear qual estágio introduziu um viés quando um resultado discriminatório aparece | | Agentforce \| Configuração do modelo | ⚡️ Tratar o consenso de vários agentes como correção de viés quando todos os agentes compartilham o mesmo modelo de base ou dados de treinamento, de modo que o acordo valida apenas o viés compartilhado em vez de corrigi-lo | | Plataforma \| CRM Analytics | ⚡️ Medindo a equidade apenas no resultado final da orquestração, sem composição por estágio em que cada estágio parece aceitável em isolamento, mas a cadeia se compõe em uma discrepância inaceitável | | Agentforce \| Configuração do agente | Confiar em pontuações de confiança de agente individuais para criar um gateway para uma cadeia de orquestração sem inserir revisão humana em pontos de inflexão em que um estágio restringe as opções a jusante | | Agentforce \| Configuração do agente | Permitir que uma cadeia de orquestração continue sem interruptor quando um agente a montante tiver baixa confiança, as distribuições mudarem entre estágios ou a cadeia encontrar dados fora de seus conjuntos de treinamento e validação | ## Métricas de fairness **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Negócios \| Gate de implementação | ✅ Torne a avaliação de imparcialidade um gateway de implementação obrigatório equivalente em autoridade à revisão de segurança antes de implantar qualquer agente tomando decisões consequentes | | Einstein \| Modelo de previsão | ✅ Calcule a paridade demográfica dividindo a população em segmentos demográficos, medindo as taxas de resultados positivos por segmento e comparando as taxas entre segmentos | | Einstein \| Modelo de previsão | ✅ Garanta a igualdade de oportunidades verificando se os agentes identificam indivíduos qualificados igualmente bem, independentemente das características demográficas; verifique se as taxas de positivos verdadeiros são comparáveis entre os grupos | | Einstein \| Modelo de previsão | ✅ Aplicar a regra de quatro quintos: se qualquer grupo receber resultados positivos em menos de 80% da taxa do grupo com melhor desempenho, investigue quanto ao viés | | Einstein \| Modelo de previsão | ✅ Calcule proporções de impacto diferentes para todas as decisões consequentes do agente e documentos resultados da investigação quando as proporções estiverem abaixo de 80% | | Negócios \| Documentação | ✅ Documente quando violações de paridade demográfica refletem fatores comerciais legítimos em vez de discriminação | | Negócios \| Revisão legal | ✅ Consulte um consultor jurídico ao implementar odds igualizadas por meio de limites específicos do grupo, observando que nos Estados Unidos, o ajuste de pontuações ou cortes por classe protegida para decisões relacionadas ao emprego é proibido pelo Título VII (Lei de Direitos Civis de 1991), e que outras jurisdições impõem suas próprias restrições | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Negócios \| Gate de implementação | ⚡️ Implementar agentes tomando decisões consequenciais sem calcular métricas de equidade entre grupos demográficos | | Einstein \| Modelo de previsão | ⚡️ Ausência sistemática de candidatos qualificados de grupos subrepresentados definindo limites de evidência mais altos para esses grupos do que para grupos de maioria | | Einstein \| Modelo de previsão | ⚡️ Implementar limites específicos do grupo sem justificação legal ou validação que os limites melhorem a equidade sem criar outros efeitos discriminatórios ou, nos Estados Unidos, implementá-los para decisões relacionadas ao emprego, em que o Título VII proíbe ajustar as pontuações ou cortes por classe protegida | | Negócios \| Documentação | ⚡️ Falha em documentar quando violações de métrica de imparcialidade refletem diferenças de negócios legítimas versus discriminação | ## Detecção de viés **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Einstein \| Camada Trust | ✅ Use dados de auditoria da Camada de Trust para analisar distribuições de resposta entre grupos demográficos; crie painéis do CRM Analytics comparando taxas de aprovação, padrões de recomendação e pontuações de risco por segmento de cliente | | Einstein \| Camada Trust | ✅ Consulta Camada Trust registra regularmente: mostrar todas as previsões de alto valor agrupadas por setor do cliente, região e tamanho da conta para verificar se as distribuições de previsão são consistentes entre segmentos | | Agentforce \| Rastreamento de sessão | ✅ Amostra de 100 decisões dos agentes estratificadas por grupo demográfico e que os revisores avaliem se a qualidade do raciocínio é comparável entre os grupos usando os rastreamentos de raciocínio de rastreamento de sessão do Agentforce | | Plataforma \| CRM Analytics | ✅ Configure alertas quando os padrões de decisão do agente se desviarem significativamente da linha de base (por exemplo, taxas de aprovação para um segmento específico caem 20% semana a semana) | | Plataforma \| CRM Analytics | ✅ Criar monitoramento personalizado para alertar sobre sinais de imparcialidade: "Notifique quando a duração média da conversa para qualquer segmento de cliente exceder 1,5x a média geral por três dias consecutivos" | | Plataforma \| CRM Analytics | ✅ Crie modelos de painel do CRM Analytics reutilizáveis que rastreiam métricas de equidade para casos de uso de agente comuns, incluindo paridade demográfica, igualdade de oportunidades, proporções de impacto diferentes e gráficos de tendências | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Rastreamento de sessão | Ignorar os rastreamentos de raciocínio de rastreamento de sessão do Agentforce e a trilha de auditoria da Camada de Trust quando os usuários relatam um viés, perdendo quais etapas de raciocínio, fontes de dados ou padrões de recuperação introduziram o viés | | Plataforma \| CRM Analytics | ⚡️ Falha na configuração de alertas de detecção de anomalia para sinais de fairness, permitindo que turnos de distribuição súbitos não sejam detectados | | Plataforma \| CRM Analytics | Criar painéis de fairness ad-hoc por equipe em vez de compartilhar modelos reutilizáveis padronizando o monitoramento de fairness | ## Supervisão humana **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Configuração do agente | ✅ Projetar agentes para decisões de alto interesse (emprego, crédito, saúde, legal, habitação) para analisar, recomendar e preparar decisões e exigir aprovação humana antes da execução | | Plataforma \| Processo de aprovação | ✅ Configure o Agentforce para gerar recomendações com evidências de apoio, encaminhar decisões acima dos limites para revisores humanos por meio do Processo de aprovação e detectar rastreamentos de raciocínio do agente na interface de aprovação | | Agentforce \| Configuração do agente | ✅ Implementar a escalação baseada em confiança: alta confiança (>90%) prossegue de modo autônomo, moderado (70-90%) requer revisão humana, baixo (<70%) adiamento totalmente para humano com resumo de contexto | | Agentforce \| Configuração do agente | ✅ Calibrar limites de confiança usando dados de produção; amostrar decisões do agente em cada faixa de confiança e calcular taxas de sucesso reais para validar a calibração | | Agentforce \| Configuração do agente | ✅ Definir acionadores de escalação com prazo definido: após 5 a 7 turnos sem resolução, após 10 minutos, quando o usuário expressa frustração ou quando o agente repete a mesma resposta | | Plataforma \| Omni-Channel | ✅ Configure o Omni-Channel para rotear casos escalonados para filas baseadas em habilidades adequadas com contexto de conversa completo; treine agentes humanos para lidar com escalonamentos sem exigir que os usuários repitam informações | | Agentforce \| UX | ✅ Forneça uma opção "Conectar-se ao agente humano" nas interfaces de chat do agente a qualquer momento, não ficando atrás de um número mínimo de interações com falha | | Agentforce \| Configuração do agente | ✅ Permita que os humanos autorizados substituam qualquer decisão do agente a qualquer momento com uma justificativa documentada; adicione o botão "Substituir agente" a todas as interfaces de decisão do agente que exigem uma explicação de texto de várias linhas | | Plataforma \| Objeto personalizado | ✅ Registrar substituições em objeto personalizado com ID de decisão, substituir carimbo de data e hora, fundamento e substituto; criar padrões de substituição de rastreamento de painel do CRM Analytics por agente, tipo de decisão e demografia do cliente | | Negócios \| Documentação | ✅ Exigir a fundamentação documentada para aprovações ou recusas que divergem da recomendação do agente; rastrear padrões de substituição para identificar deficiências sistemáticas do agente | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | ⚡️ Implementar agentes como tomadores de decisão autônomos para decisões de alto interesse (emprego, crédito, saúde, legal, habitação) sem portões de aprovação humana | | Agentforce \| Configuração do agente | ⚡️ Usando pontuações de confiança mal calibradas em que as decisões de "alta confiança" são bem-sucedidas apenas 75% do tempo, minando a Trust nos mecanismos de escalação | | Agentforce \| Configuração do agente | ⚡️ Arrastar clientes em loops automatizados não úteis sem escalonamento com limite de tempo ou de turno para humanos | | Plataforma \| Omni-Channel | ⚡️ Roteamento de casos escalonados sem contexto de conversa completo, forçando os usuários a repetir as informações já fornecidas ao agente | | Negócios \| Governança | Permitir a difusão de responsabilidade quando todos presumem que a IA é responsável e ninguém assume o controle das decisões | | Negócios \| Governança | ⚡️ Atribuir responsabilidade após incidentes, em vez de antes da implantação, com indivíduos nomeados documentados em registros de decisão de arquitetura | ## Atribuição de responsabilidade **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Negócios \| Documentação | ✅ Atribuir responsabilidade antes da implantação: proprietário do modelo (justiça/precisão), proprietário da decisão (use caso/impacto), autoridade de recurso (apelidos de justiça), autoridade de auditoria (auditorias periódicas) | | Negócios \| Documentação | ✅ Documente todos os papéis de responsabilidade com nomes, não apenas títulos, garantindo que a responsabilidade persista por meio de alterações organizacionais | | Negócios \| Governança | ✅ Capacitar a autoridade de recurso (comissão de análise de ética ou equipe designada) para lidar com recursos de usuários que acreditam que as decisões do agente eram injustas com processos acessíveis e oportunos que podem reverter as decisões do agente | | Negócios \| Governança | ✅ Autorizar a autoridade de auditoria (equipe de conformidade) a realizar auditorias periódicas e suspender agentes com falha nos padrões de imparcialidade aguardando remediação | | Negócios \| Governança | ✅ Agende a revisão mensal de padrões de substituição de alta frequência com a equipe de desenvolvimento do agente | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Negócios \| Governança | ⚡️ Documentar papéis de responsabilidade apenas com títulos (por exemplo, "Data Science Lead") sem indivíduos nomeados, permitindo que a responsabilidade desapareça durante alterações organizacionais | | Negócios \| Governança | Permitir que os proprietários de decisão delegem a responsabilidade a sistemas de IA em vez de reter a responsabilidade pessoal para o impacto do mundo real | | Negócios \| Governança | ⚡️ Tornar os processos de recurso inacessíveis, atrasados ou sem autoridade para reverter as decisões do agente | ## Transparência e capacidade de explicação **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Configuração do agente | ✅ Arquite várias camadas de explicação: voltado para o usuário (linguagem simples), negócio (principais fatores de decisão), técnico (detalhes do modelo/pesos de recurso) e auditoria (traços de decisão completos) | | Agentforce \| Configuração do agente | ✅ Exiba o raciocínio de resumo em tempo real ao tomar decisões: "Recomendi o Produto A com base em seu histórico de compras (3 compras semelhantes), promoção atual (20% de desconto) e disponibilidade de inventário" | | Agentforce \| Configuração do agente | ✅ Forneça "Por que você recomendou isso?" link que permite aos usuários visualizar o raciocínio completo, incluindo todos os artigos do Knowledge recuperados, registros consultados e lógica de decisão | | Agentforce \| Rastreamento de sessão | ✅ Recupere rastreamentos de raciocínio do Rastreamento de sessão do Agentforce para reconstrução histórica quando os usuários desafiarem decisões anteriores semanas ou meses depois | | Agentforce \| Rastreamento de sessão | ✅ Exemplo de Sessão do Agentforce Rastreamento de raciocínio estratificado por grupos demográficos para analisar se a qualidade da decisão é consistente; examine 100 rastreamentos de cada segmento de cliente | | Agentforce \| Configuração do agente | ✅ Comunique confiança em termos adequados ao usuário: "Alta confiança" / "Moderar confiança" / "Baixa confiança" com contexto de confiabilidade de linguagem simples em vez de pontuações de probabilidade brutas | | Agentforce \| Configuração do agente | ✅ Para decisões moderadas ou com baixa confiança, explique qual revisão adicional ocorrerá e a linha do tempo esperada | | Agentforce \| Configuração do agente | ✅ Forneça explicações contrafatuais mostrando aos usuários o que mudaria o resultado: "Sua pontuação de lead aumentaria com informações de emprego verificadas (+8 pontos)" | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | Exibir pontuações de probabilidade brutas (por exemplo, "confiança de 73%") que os usuários interpretam incorretamente em vez de usar a linguagem de confiança apropriada para o usuário | | Agentforce \| Configuração do agente | ⚡️ Fornecer contrfatuais que incentivam o uso do sistema ou revelam inadvertidamente características protegidas como fatores de decisão (por exemplo, "Sua solicitação pontuaria mais se você fosse 10 anos mais novo") | | Agentforce \| Configuração do agente | ⚡️ Fornecer apenas um nível de explicação que não atende aos usuários finais (técnicos demais) nem aos auditores (simplificado demais) | | Agentforce \| Configuração do agente | ⚡️ Falha na armazenagem de rastreamentos históricos, impossibilitando a explicação de decisões anteriores quando desafiadas | ## Divulgação de IA **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Configuração do agente | ✅ Indicar claramente quando os usuários interagem com agentes Agentforce com divulgação proeminente e contínua (não enterrado em termos de serviço ou mostrado apenas uma vez no início da interação) | | Agentforce \| Configuração do agente | ✅ Exibir indicadores visuais persistentes: Avatar do agente marcado como "AI Assistant", o cabeçalho mostrando "Você está conversando com um agente de serviço Agentforce" e a opção "Conectar-se com um agente humano" é visível ao longo da conversa | | Agentforce \| Configuração do agente | ✅ Garanta que os usuários que preferem interação humana possam alternar sem fricção ou penalidades de qualidade do serviço | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | ⚡️ Ocultar a divulgação de IA em termos de serviço ou mostrá-la apenas uma vez no início da interação em vez de manter indicadores visuais persistentes | | Agentforce \| Configuração do agente | Penalizar usuários que escolhem interação humana com serviço degradado ou tempos de espera maiores | | Agentforce \| Configuração do agente | Ocultar a opção "Conectar-se ao agente humano" ou exigir que os usuários concluam interações com o agente antes de acessar o suporte humano | ## Auditoria e responsabilidade algorítmica **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Monitoramento de evento | ✅ Configure o Monitoramento de evento para rastrear: Logs de evento de API mostrando interações do sistema do agente, eventos de login para contas de serviço do agente e exportações de relatório quando os agentes acessam dados em massa | | Plataforma \| Monitoramento de evento | ✅ Registrar o Monitoramento de evento de streaming para SIEM externo para retenção de longo prazo e comprovação de adulteração atendendo aos requisitos regulatórios | | Plataforma \| Trilha de auditoria de campo | ✅ Habilite a Trilha de auditoria de campo (manutenção indefinida do histórico arquivado) nos objetos que armazenam ou são influenciados por decisões do agente, escolhendo entre os objetos padrão que ele oferece suporte, além de objetos personalizados com rastreamento de histórico de campo habilitado; crítico para crédito, emprego e outros casos de uso de alto risco | | Plataforma \| Shield | ✅ Use o Monitoramento de evento Shield para decisões de agente de maior interesse em que a integridade da trilha de auditoria é crítica (funcionalidades aprimoradas, campos de evento estruturados, integração de relatórios de conformidade) | | Plataforma \| Objeto personalizado | ✅ Criar armazenamento de objeto personalizado AgentDecision__c: Decision_ID, Timestamp, Agent_Type, Model_Version, Confidence_Score, Resultado, User_ID, Record_ID; com o objeto de junção DecisionInput__c vinculando decisões a instantâneos de recursos de entrada | | Plataforma \| Objeto personalizado | ✅ Armazene valores de recurso de entrada exatos no momento da decisão (não valores atuais que podem mudar) para habilitar o teste de se as decisões difeririam com os dados atualizados | | Negócios \| Documentação | ✅ Registrar a versão do modelo, o estado da configuração (limites, regras de negócios, parâmetros) e o contexto ambiental (identidade do usuário, carimbo de data e hora, histórico da conversa) para cada decisão consequente | | Plataforma \| LWC | ✅ Criar integração de componente do LWC em registros para exibir o histórico de decisão com links "Visualizar fundamento" | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Trilha de auditoria de campo | ⚡️ Com base no histórico de campo padrão (18 meses de retenção) para decisões de alto nível que exigem retenção regulatória de vários anos | | Plataforma \| Objeto personalizado | ⚡️ Armazenar apenas valores de registro atuais em vez de instantâneos de entrada de hora de decisão, impossibilitando a reconstrução de decisões históricas com precisão | | Negócios \| Documentação | ⚡️ Falha ao registrar a versão do modelo e o estado de configuração ativos no momento da decisão, tornando a análise de causa raiz impossível quando o viés é descoberto | | Plataforma \| Monitoramento de evento | ⚡️ Manter registros de auditoria apenas no Salesforce sem streaming de SIEM externo, sem evidência de adulteração para conformidade regulatória | ## Monitoramento de imparcialidade contínuo **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| CRM Analytics | ✅ Criar painéis mostrando: distribuição de decisão por segmento demográfico (gráficos de barras), métricas de imparcialidade ao longo do tempo (linhas de tendência com limites de alerta), proporção de impacto distinta com indicador de regra de quatro quintos, principais preditores que contribuem para decisões, taxa de substituição por grupo demográfico | | Plataforma \| CRM Analytics | ✅ Alerta quando as distribuições de entrada mudam significativamente da demografia de dados de treinamento; monitore o turno de distribuição indicando uma possível degradação de equidade | | Agentforce \| Configuração do agente | ✅ Adicione a opção "Relatar preocupação" à interface de chat do Agentforce; encaminhe relatórios ao painel de análise de ética com contexto de conversa completo; rastreie no objeto personalizado com o fluxo de trabalho de investigação necessário | | Negócios \| Governança | ✅ Monitorar painéis de imparcialidade semanalmente, investigar violações de limite em 24 horas, realizar análises de padrão de substituição mensais, realizar auditorias de imparcialidade abrangentes trimestrais | | Negócios \| Governança | ✅ Permitir que os usuários relatem viés percebido por meio de mecanismos acessíveis; os relatórios do usuário detectam problemas qualitativos que as métricas quantitativas ignoram | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Negócios \| Governança | ⚡️ Tratar a detecção de viés como validação de pré-implementação única, em vez de monitoramento contínuo conforme os agentes evoluem por meio de atualizações de prompt, alterações de versão do modelo e distribuições de dados de turno | | Plataforma \| CRM Analytics | ⚡️ Falha na configuração de alertas quando métricas de justiça violam limites definidos, permitindo que o desvio gradual não seja detectado | | Agentforce \| Configuração do agente | ⚡️ Não fornecer aos usuários mecanismos acessíveis para relatar viés percebido, sem problemas qualitativos que as métricas quantitativas não podem detectar | ## Suporte para auditoria externa **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Integração | ✅ Criar a funcionalidade de exportação que habilita as equipes de conformidade a extrair conjuntos de dados de decisão completos com estratificação demográfica para revisão do auditor externo, respeitando as normas de privacidade de dados | | Negócios \| Documentação | ✅ Mantenha a documentação atual abrangendo: propósito e casos de uso pretendidos do agente, demografia de dados de treinamento e limitações conhecidas, métricas de equidade (pré-implementação e produção), estratégias de mitigação de viés, configurações de supervisão humana, abordagem de monitoramento e atribuições de responsabilidade | | Negócios \| Governança | ✅ Antes de implantar agentes tomando decisões consequenciais, realize avaliações de impacto algorítmicas avaliando possíveis efeitos positivos e negativos entre grupos de partes interessadas | | Negócios \| Governança | ✅ Agende auditorias de imparcialidade externas semestral por terceiros; mantenha a leitura de horizonte regulatório adaptada à Lei de IA da UE, às leis estaduais e aos regulamentos do setor | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Integração | ⚡️ Projetar arquiteturas de agente sem prever auditorias externas por reguladores, organizações de direitos civis ou clientes; sem recursos de exportação para revisão de auditores | | Negócios \| Documentação | Permitir que a documentação se torne obsoleta à medida que os agentes evoluem por meio de atualizações de prompt ou alterações de modelo sem atualizar métricas de fairness e estratégias de mitigação | | Negócios \| Governança | ⚡️ Implementar agentes tomando decisões consequenciais sem realizar avaliações de impacto avaliando os efeitos entre grupos de partes interessadas | ## Consentimento e agência do usuário **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Configuração do agente | ✅ Exigir adesão explícita para agentes consequenciais (decisão de crédito, triagem de emprego, elegibilidade para serviço) em vez de ativar por padrão | | Plataforma \| Objeto personalizado | ✅ Criar AI_Consent__c com campos: User_ID, Use_Case, Grant_Date, Grant_Method, Withdrawal_Date, Status; habilite Trilha de auditoria de campo para retenção de registro de consentimento de longo prazo | | Agentforce \| Configuração do agente | ✅ Adicionar verificação de consentimento à lógica de invocação do agente: consultar AI_Consent__c para consentimento ativo antes do processamento; dar suporte ao consentimento no nível do caso de uso (agente de serviço vs. agente de vendas) | | Plataforma \| Site da comunidade/Experiência | ✅ Criar interface de gerenciamento de consentimento por autoatendimento acessível a partir do perfil de usuário; agendar lembretes de renovação de consentimento a cada 12 meses | | Agentforce \| Configuração do agente | ✅ Ao implantar novos recursos que afetam os usuários existentes, proativamente procure consentimento para novos casos de uso em vez de contar com o consentimento original que não contemplava aplicativos específicos | | Agentforce \| Configuração do agente | ✅ Habilite a retirada de consentimento a qualquer momento com o encerramento imediato do processamento do agente; torne a retirada tão fácil quanto conceder sem exigir contatos de suporte | | Agentforce \| Configuração do agente | ✅ Habilitar o gerenciamento de preferências do usuário: estilo de comunicação (conciso vs. detalhado), nível de proatividade, preferência de escalação; armazenamento em campos personalizados de registro do usuário e referência em avisos do sistema do agente | | Plataforma \| Omni-Channel | ✅ Forneça a opção "Conectar-se ao agente humano" persistente em interações; quando selecionada, encaminhe para o Omni-Channel com contexto de conversa completo e sinalizador de prioridade sem penalidades de tempo de espera ou serviço degradado | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | Ativar agentes consequenciais por padrão sem aceitação explícita do usuário para entender como os agentes os afetarão | | Agentforce \| Configuração do agente | ⚡️ Exigir consentimento de IA geral em vez de habilitar o consentimento granular no nível de caso de uso (um cliente pode consentir com agentes de serviço enquanto recusa agentes de vendas) | | Agentforce \| Configuração do agente | Fazer a retirada do consentimento requer contatos de suporte ou processos burocráticos em vez de autoatendimento com efeito imediato | | Agentforce \| Configuração do agente | ⚡️ Com base no consentimento original ao implantar funcionalidades de agente materialmente novas que não foram consideradas no consentimento original | | Agentforce \| Configuração do agente | ⚡️ Exigir que os usuários concluam interações com agentes ou expliquem suas preferências antes de conectá-los a um agente humano | ## Não discriminação no design do agente **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Configuração do agente | ✅ Revise todas as fontes de dados usadas no raciocínio do agente para conteúdo de características protegidas; remova ou mascare características protegidas de entradas do agente quando não for legalmente justificado para o tipo de decisão | | Agentforce \| Modelo de prompt | ✅ Inclua instruções explícitas de não discriminação em avisos do sistema: "Tratue todos os clientes com o mesmo profissionalismo, independentemente de nome, local, estilo de comunicação ou qualquer outra característica. Nunca faça pressuposições sobre os clientes com base nas características demográficas." | | Agentforce \| Configuração do agente | ✅ Teste com diversas personas antes da produção: gerar solicitações idênticas variando apenas sinais demográficos (nomes sugerindo diferentes etnias, locais, estilos de comunicação); comparar respostas quanto à qualidade, ao comprimento, ao profissionalismo e aos resultados | | Agentforce \| Monitoramento do agente | ✅ Calcular taxas de resolução de primeiro contato estratificadas por segmento do cliente; investigar quando há discrepâncias significativas entre os segmentos | | Agentforce \| Monitoramento do agente | ✅ Amostra de conversas do agente entre segmentos e faça os revisores avaliarem a qualidade da resposta em dimensões consistentes (precisão, completude, profissionalismo, utilidade) com testes de confiabilidade entre classificações | | Agentforce \| Monitoramento do agente | ✅ Rastreie taxas de escalação estratificadas por demografia do cliente; taxas mais altas para determinados segmentos indicam que os agentes são menos eficazes para esses usuários | | Negócios \| Pesquisas | ✅ Pesquise usuários de todos os grupos demográficos e compare as pontuações de satisfação; a alta satisfação geral pode mascarar experiências ruins para grupos minoritários | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | Incluir dados de características protegidos (status de deficiência, religião, origem nacional) em entradas do agente para decisões em que essas características não são legalmente justificadas | | Agentforce \| Modelo de prompt | ⚡️ Implementar agentes sem instruções explícitas de não discriminação em avisos do sistema, dependendo apenas do comportamento do modelo de base | | Agentforce \| Configuração do agente | ⚡️ Testar agentes apenas com personas de maioria demográfica, sem viés em relação a grupos subrepresentados | | Negócios \| Pesquisas | ⚡️ Com base em pontuações de satisfação geral que mascaram experiências ruins para grupos minoritários afogados pela satisfação da maioria | ## Acessibilidade em experiências do agente **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| LWC | ✅ Para implementações de chat personalizadas, garanta: estrutura HTML semântica com marcos adequados, regiões ativas do ARIA anunciando novas mensagens, navegação por teclado no histórico de mensagens, indicadores de foco claros em elementos interativos | | Plataforma \| LWC | ✅ Teste com JAWS, NVDA e VoiceOver em todo o desenvolvimento, não apenas verificação automatizada | | Agentforce \| Configuração do agente | ✅ Configure as respostas do agente para usar linguagem simples para públicos gerais; evite jargões e forneça glossários para termos técnicos inevitáveis; estruture respostas longas com títulos e listas com marcadores | | Agentforce \| Configuração do agente | ✅ Validar a qualidade da resposta é comparável entre idiomas por meio da avaliação do locutor nativo, não apenas métricas automatizadas que ignoram nuances culturais | | Agentforce \| Configuração do agente | ✅ Para casos de uso críticos para negócios que atendem populações de idiomas diversas, configure o tratamento específico do idioma (variáveis de idioma, avisos localizados, filtragem de artigos do Knowledge por idioma) e valide a qualidade por idioma, em vez de depender apenas da transferência multilíngue do modelo de base | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| LWC | Criar implementações de chat personalizadas sem testes de acessibilidade manuais (com base apenas em verificação automatizada) | | Agentforce \| Configuração do agente | ⚡️ Usar jargão e linguagem complexa sem glossários, criando barreiras cognitivas para os usuários | | Agentforce \| Configuração do agente | ⚡️ Dependendo apenas da transferência multilíngue do modelo de base para idiomas de recursos inferiores, fornecendo qualidade reduzida para usuários de idiomas não maioritários | | Agentforce \| Configuração do agente | ⚡️ Validar a qualidade da resposta multilíngue apenas por meio de métricas automatizadas sem nuances culturais | ## Gates de implementação e governança de justiça **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Negócios \| Governança | ✅ Estabelecer o painel de análise de ética com a autoridade de imposição antes de implantar agentes de produção | | Negócios \| Governança | ✅ Defina os portões de implantação obrigatórios: auditoria de dados, cálculo de métricas de equidade e avaliação de impacto algorítmico | | Plataforma \| CRM Analytics | ✅ Criar painéis de monitoramento de equidade de linha de base no CRM Analytics antes da primeira implantação do agente | | Plataforma \| Monitoramento de evento | ✅ Habilite a captura de auditoria da Camada de Trust do Einstein e configure o Monitoramento de evento para ações do agente como base antes da produção | | Negócios \| Governança | ✅ Implementar o teste de regressão de equidade automatizado em pipelines de CI/CD para escala | | Negócios \| Governança | ✅ Padronizar padrões de gerenciamento de consentimento em todos os novos agentes conforme a escala de implantações | | Plataforma \| Integração | ✅ Criar ferramentas de reconstrução de decisão do agente habilitando o autoatendimento da equipe de conformidade | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Negócios \| Governança | ⚡️ Implementar agentes de produção antes de estabelecer um conselho de análise de ética com autoridade de imposição | | Negócios \| Governança | ⚡️ Tratar a imparcialidade como uma reflexão, em vez de um gateway de implementação obrigatório equivalente à revisão de segurança | | Negócios \| Governança | ⚡️ Ignorar avaliações de impacto algorítmico antes de implementar agentes tomando decisões consequentes | | Plataforma \| CRM Analytics | ⚡️ Implementar o primeiro agente de produção sem painéis de monitoramento de equidade de linha de base em vigor | # Estrutura bem arquitetada A Estrutura bem-arquivada do Salesforce oferece aos arquitetos uma base compartilhada e fundamentada para tomar decisões que ajudam uma solução a ter sucesso ao longo do tempo. Ele é organizado em torno de cinco pilares – Trust, Reliabilidade, Excelência Operacional, Otimização de Recursos e Custos e Fairness – cada um dos quais captura uma dimensão de qualidade que importa em todas as fases da vida de uma solução, desde o projeto inicial até a operação e crescimento a longo prazo. A estrutura aborda as realidades que os arquitetos enfrentam hoje: humanos, agentes e plataformas que trabalham juntos dentro de sistemas de negócios governados. Uma solução segura, mas frágil sob a carga, ou eficiente, mas opaca em suas decisões, não está bem arquivada. Esses cinco pilares trabalham juntos para garantir que a qualidade seja tratada como um todo e não como uma lista de verificação de preocupações independentes. Os arquitetos usam a estrutura como um lens consistente durante revisões de design, conversas de compensação e governança contínua. Ela não prescreve uma única resposta à direita. Ele fornece as perguntas certas para você fazer, os padrões certos para considerar e um vocabulário comum para usar entre as equipes. | [Exiba o Log de alterações](/docs/architect/pt-br/well-architected/guide/change-log.html) para ver atualizações recentes na documentação do Centro de arquitetura. | | :---- | ## O que é a estrutura bem arquitetada A Estrutura bem-arquivada do Salesforce é um guia de opinião sobre a qualidade arquitetônica para soluções criadas na Salesforce Platform. Ele codifica os princípios, os padrões e os prós e os contras que diferenciam soluções de escala e adaptação daquelas que acumulam débito técnico ou falham sob pressão. A estrutura é organizada em torno de cinco pilares. Cada pilar define uma dimensão de qualidade, articula os principais princípios de design, identifica padrões comuns e fornece orientação explícita para funcionalidades tradicionais da plataforma e cargas de trabalho de IA agentes. Juntos, os pilares abrangem de modo abrangente o que significa criar algo bom no Salesforce. Essa estrutura não é um manual de produto ou um guia de implementação. É uma estrutura de decisão arquitetônica, uma maneira de pensar sobre qualidade que se aplica independentemente das nuvens, recursos ou ferramentas que uma solução usa. ## Por que o Salesforce precisa de sua própria estrutura As estruturas do setor de provedores de nuvem de hiperescala fornecem orientação geral valiosa, mas são criadas principalmente para questões operacionais e de infraestrutura de nuvem, como máquinas virtuais, rede, armazenamento e computação. Os arquitetos do Salesforce enfrentam diferentes restrições e recursos: plataforma multitenant com limites de regulador, décadas de lógica de negócios no Customer 360, soluções de integração sofisticadas, automação declarativa, configuração orientada por metadados e modelos de compartilhamento gerenciado. Eles moldam cada decisão arquitetônica de maneiras que a orientação genérica de nuvem não pode lidar. A mudança para agentes autônomos introduz considerações adicionais. Agentes que raciocinam e atuam apresentam padrões de supervisão Human-in-the-Loop, não determinismo, raciocínio probabilístico e que as estruturas anteriores não abordavam originalmente, embora as estruturas de finalidade geral tenham começado a se estender para esse espaço por meio de lenses de IA dedicados. A Estrutura bem-arquivada do Salesforce lida com arquitetura de plataforma tradicional e sistemas agentes por meio de um lens unificado. ## Quem deve usar essa estrutura Essa estrutura atende a qualquer pessoa responsável pela qualidade da arquitetura na plataforma Salesforce: - **Salesforce Architects** projetando novas soluções ou ampliando as existentes - Os **Administradores do Salesforce** configuram e protegem as organizações em que essas soluções são executadas - **Leads de desenvolvimento** estabelecendo padrões e padrões para suas equipes - **Consultores e parceiros** que aconselham os clientes sobre as melhores práticas da plataforma - **Especialistas de IA e agentes** que criam e gerenciam sistemas autônomos de agentes Nenhum conhecimento prévio em IA agente é necessário. A estrutura está acessível a todos os arquitetos enquanto fornece profundidade para aqueles que trabalham na fronteira de sistemas autônomos. ## Como usar essa estrutura ### Ordem de leitura Não há uma ordem de leitura correta única. Escolha com base em seu papel e necessidade imediata: - **Se você é novo no framework:** Leia este documento de visão geral de ponta a ponta e explore o pilar mais relevante para seu projeto atual. - **Se você estiver projetando uma nova solução:** Comece com Trust and Reliability (fundamentos não negociáveis) e, em seguida, aborde Excelência operacional (como você vai operá-la), Otimização de recursos e custos (como você vai mantê-la) e Fairness (como você vai garantir que atenda a todos os usuários de forma equitativa). - **Se você estiver construindo soluções agentes:** Leia a [Visão geral da empresa](/docs/architect/pt-br/well-architected/guide/agentic-enterprise.html) do agente primeiro para obter orientação abrangente sobre a arquitetura do agente. Em seguida, leia os documentos de pilares principais (vinculados acima) para padrões fundamentais (Modelo de responsabilidade compartilhada, limites do regulador, ferramentas de monitoramento, modelagem de TCO, padrões de acessibilidade) que as soluções de agência criam. Por fim, consulte as variantes de pilar da Enterprise do agente (vinculadas de cada pilar) para sobreposições específicas da agência em cada dimensão de qualidade. - **Se você estiver realizando uma revisão de projeto:** Use os documentos de pilares como uma lista de verificação de análise estruturada. Uma solução bem projetada tem respostas claras às principais perguntas em cada pilar relevante. ### Aplicar a estrutura a decisões de compensação As decisões arquitetônicas mais importantes envolvem compensações entre os pilares. A estrutura ajuda a tornar isto explícito: - **Trust vs. Otimização de recursos e custos:** O registro de criptografia e auditoria consome recursos. A estrutura ajuda você a identificar onde o requisito de Trust é não negociável versus onde você tem flexibilidade. - **Confiabilidade vs. Otimização de recursos e custos:** Uma disponibilidade maior custa mais. As definições de SLO ajudam você a combinar o investimento com os reais requisitos de negócios em vez de usar como padrão a redundância máxima. - **Excelência operacional vs. Velocidade:** A observação abrangente e o teste levam tempo para serem implementados. A estrutura ajuda a identificar a observabilidade mínima viável para seu perfil de risco. - **Justiça vs. Autonomia:** Maior autonomia do agente permite a eficiência, mas cria risco de equidade. Os padrões humanos no loop ajudam a encontrar o equilíbrio certo para cada tipo de decisão. Não há uma resposta universal a esses prós e os contras. A estrutura ajuda você a fazer as perguntas certas e fazer as compensações de forma consciente em vez de descobri-las na produção. ## Princípios de estrutura A estrutura bem arquivada em si é projetada considerando estes princípios: - **Especificamente para a plataforma, mas sem tecnologia:** A orientação lida com restrições específicas do Salesforce (limites de governador, arquitetura multilocatário, ajustes conduzidos por metadados) sem prescrever produtos ou recursos específicos. Os arquitetos escolhem os recursos certos para o contexto. - **Opened without prescriptive:** A estrutura assume posições claras sobre o que constitui qualidade, mas não determina um único caminho de implementação. Ele fornece princípios, padrões e perguntas, não requisitos. - **Olhando para o futuro, respeitando o presente:** A estrutura lida com padrões emergentes (IA eficiente, sistemas autônomos) enquanto continua relevante para soluções de plataforma tradicionais. Ambos os casos de uso se beneficiam dos mesmos princípios fundamentais. - **Vivo, não estático:** A estrutura evolui conforme a plataforma, as práticas do setor e as necessidades do cliente mudam. O Log de alteração rastreia atualizações para que os arquitetos possam se manter atualizados com novas orientações. - **Acionável em todos os estágios:** Quer você esteja projetando uma nova solução, realizando uma revisão ou melhorando uma implementação existente, a estrutura fornece orientação relevante. Não é apenas uma lista de verificação de certificação, é uma ferramenta de trabalho. Esses princípios garantem que a estrutura permaneça útil em diversos contextos arquitetônicos enquanto mantém uma orientação clara e consistente sobre o que a qualidade arquitetônica significa para as soluções do Salesforce. ## Os cinco pilares Cada pilar aborda uma dimensão fundamental da qualidade arquitetônica. Juntos, os pilares fornecem uma cobertura abrangente: nenhum único pilar é suficiente sozinho, e as compensações entre os pilares são onde as decisões arquitetônicas mais importantes estão. ### Pilares da estrutura e Enterprise do agente: Trabalhando juntos Os cinco pilares a seguir fornecem orientação arquitetônica básica para **todas as** soluções do Salesforce: aplicativos de plataforma tradicionais, integrações e sistemas agentes. O [Agent Enterprise Overview](/docs/architect/pt-br/well-architected/guide/agentic-enterprise.html) e suas variantes de pilares complementares fornecem a sobreposição específica da agência: como os agentes criam esses recursos, o que muda quando os sistemas agem de modo autônomo e os padrões arquitetônicos necessários para IA governada. **Use ambos juntos:** - Comece com a orientação de pilares para padrões arquitetônicos principais (por exemplo, o Modelo de responsabilidade compartilhada, limites do regulador, ferramentas de monitoramento, modelagem de TCO, padrões de acessibilidade). - Em seguida, consulte o pilar Enterprise do agente correspondente para considerações específicas do agente (por exemplo, permissões do agente e cadeias de auditoria, tratamento de falha de orquestração, ciclo de vida do agente de desenvolvimento, otimização de token, unidades de trabalho do agente, explicabilidade e capacidade de contestação). Os pilares não são "tradicionais" vs. "agentes", são a arquitetura fundamental em que as soluções agentes se baseiam. Os sistemas agentes devem satisfazer os mesmos requisitos de Trust, confiabilidade, excelência operacional, otimização de recursos e custos e equidade que qualquer outra solução empresarial, com considerações adicionais para operação autónoma. Esta tabela fornece uma rápida referência. A orientação detalhada para cada pilar segue. | Pilar | O que ele lida | Ângulo agencial | | :---- | :---- | :---- | | [Trust](/docs/architect/pt-br/well-architected/guide/trust.html) | Segurança, acesso, privacidade, governança | Regular o que os agentes podem fazer e auditar o que eles fizeram | | [Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html) | Disponibilidade, recuperação, escalabilidade | Lidar com não determinismo, falhas de orquestração e capacidade de interrupção do agente | | [Excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) | Observabilidade, DevOps, automação | Observando sistemas probabilísticos e gerenciando o ciclo de vida de desenvolvimento do agente | | [Otimização de recursos e custos](/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization.html) | Eficiência, desempenho, custo, valor | Economia de token, recuperação de memória e custo baseado em consumo do trabalho do agente | | [Justiça](/docs/architect/pt-br/well-architected/guide/fairness.html) | Acessibilidade, transparência, supervisão | Capacidade de explicação, capacidade de contestação e experiências equitativas conduzidas pelo agente, viés | ### Trust Proteja sua solução, seus dados e seus usuários por meio de segurança moderna, acesso de privilégio mínimo, controles de privacidade e governança clara. O Trust no Salesforce opera por meio do **Modelo de responsabilidade compartilhada**: O Salesforce protege a infraestrutura e a plataforma, então você arquita soluções seguras nessa base. Suas responsabilidades abrangem: - Gerenciamento de identidade e acesso (papéis, perfis, conjuntos de permissões, MFA, SSO, OAuth) - Governança de dados (Shield Platform Encryption, segurança em nível de objeto/campo/registro) - Segurança de integração (autenticação de API, credenciais nomeadas) - Práticas de desenvolvimento seguras ([Top 10 do OASP](https://owasp.org/www-project-top-ten/) adaptado para o Salesforce, análise estática, portões de segurança de CI/CD) **Para soluções agentes:** Quando agentes agem de forma autônoma, os requisitos de Trust se estendem a governar o que os agentes têm permissão para fazer, auditar o que eles fizeram e proteger os limites de agente para plataforma (Agent Fabric, Einstein Trust Layer). Consulte [Agentic Enterprise Trust](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-trust.html). Para saber mais, consulte Pilar [Trust](/docs/architect/pt-br/well-architected/guide/trust.html) e [Agent Enterprise Trust](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-trust.html). ### Confiabilidade Projetado para disponibilidade contínua, recuperação rápida de interrupção e capacidade de escala sob demanda inesperada. A confiabilidade exige compreender as garantias da plataforma (infraestrutura de várias regiões, SLAs da plataforma) enquanto projeta soluções que permaneçam confiáveis dentro dessas restrições. O pilar abrange: - Limites do controlador com 70% de orientação de limite operacional - Padrões de processamento assíncrono (Apex em lote, Apex enfileirável, Eventos de plataforma) - Interruptores de circuito para integrações externas - Planejamento de capacidade - Carregar teste - Padrões de várias organizações - Recuperação de desastres - Modelagem de saúde **Para soluções agentes:** Os sistemas conduzidos pelo agente apresentam um comportamento probabilístico que requer novos padrões para falhas de orquestração, disruptores de circuito para erros de agente em cascata e Gráficos de agente determinísticos em que os resultados de negócios exigem previsibilidade. Consulte [Agent Enterprise Reliability](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-reliability.html). Para saber mais, consulte Pilar de [Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html) e [Confiabilidade corporativa da agência.](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-reliability.html) ### Excelência operacional Crie observabilidade abrangente em sua solução e gerencie-a por meio de procedimentos e automação bem definidos. A Excelência operacional abrange: - Observabilidade (Monitoramento de evento, Proactive Monitoring, Centro de escala) - Práticas de DevOps (desenvolvimento orientado por origem, pipelines de CI/CD, estratégia de teste) - Automação (principalmente declarativa com o Flow Builder, padrões programáticos com Apex) - Gerenciamento de incidentes (níveis de gravidade, rotação na chamada, pós-mortems sem culpa) - Melhoria contínua (métricas DORA, análises operacionais) **Para soluções agentes:** A capacidade de observação fica mais difícil quando o comportamento do sistema é probabilístico. O ciclo de vida de desenvolvimento do agente (ADLC) fornece estrutura por meio de cinco fases: conceção e design, desenvolvimento, testes e validação (incluindo avaliações do Centro de Testes do agente para precisão, coerência e adesão às instruções), implantação e liberação, e monitoramento e ajuste (incluindo Rastreamento de sessão do Agentforce para visibilidade de ponta a ponta da interação). Consulte Excelência operacional da [Agent Enterprise](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-operational-excellence.html). Para saber mais, consulte Pilar de [Excelência Operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) e [Excelência Operacional da Agência](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-operational-excellence.html). ### Otimização de recurso e custo Retorne o valor comercial máximo para cada dólar e cada unidade de recurso da plataforma por meio do uso eficiente do que você tem e do investimento deliberado no que você compra. No lado do recurso, isso significa entender os limites do controlador (consultas SOQL, instruções DML, tamanho de heap, tempo de CPU) e projetar dentro deles por meio de otimização SOQL, processamento assíncrono e prevenção de discrepância de dados. No lado do custo, isso significa modelagem abrangente de TCO em custos diretos (implementação, operacional, manutenção) e custos indiretos (débito técnico, sobrecarga de governança) que geralmente excedem custos diretos de licença. O pilar abrange: - Padrões de organização de código ( manipuladores de acionador, camadas de serviço, seletores) - Empacotamento e modularidade (pacotes gerenciados 2GP vs. desbloqueados, que são ambos tipos de empacotamento de segunda geração, composição do LWC) - Gerenciamento de ciclo de vida de dados (estratégias de arquivamento, otimização de fluxo) - Ferramentas de monitoramento de desempenho (Centro de escala, Ferramenta do plano de consulta, ApexGuru, Analisador de código do Salesforce) - Análise de criação vs. compra (avaliação do AgentExchange) - Otimização de licença e sandbox - Monitoramento e governança de custo (painéis, controles de orçamento, modelos de showback vs. chargeback) **Para soluções agentes:** Os fluxos de trabalho do agente complicam o consumo de recursos compostos em etapas de raciocínio, chamadas de ferramentas e recuperações de dados, portanto, o uso de token, a latência de inferência e os padrões de memória exigem otimização. Os sistemas agentes também introduzem custos baseados em consumo (Creditos flexíveis, tokens de inferência) que são mais difíceis de prever do que o licenciamento por usuário. Unidades de trabalho agentes (AWUs) medem o consumo de token bruto que os agentes de fato concluíram (tarefas separadas concluídas). Consulte [Recurso corporativo e otimização de custo da agência](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-resource-and-cost-optimization.html). Para saber mais, consulte Pilar de Otimização de [recurso e custo](/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization.html) e [Otimização de recursos empresariais e custo](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-resource-and-cost-optimization.html) do agente. ### Fairness Garanta que sua solução seja acessível, não discriminatória, inclusiva e transparente, com a supervisão humana adequada de decisões automatizadas. A justiça é baseada nas noções básicas da plataforma. O Salesforce Lightning Design System (SLDS) fornece acessibilidade integrada para componentes padrão, enquanto os componentes personalizados exigem implementação explícita do WCAG 2.1 AA (com [WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/), a Recomendação atual do W3C a partir de dezembro de 2024, recomendado para novos trabalhos). O pilar abrange: - Teste de acessibilidade (exe-core, scanner sfdx) - Padrões de não discriminação (OWD, regras de compartilhamento, FLS com monitoramento de evento Shield) - Arquitetura de privacidade (Gerenciamento de consentimento do Data 360, Trilha de auditoria de campo) - Governança de ética de IA (quadros de revisão, portões de equidade, conformidade regulatória). **Para soluções agentes:** Quando os agentes tomam decisões autônomas que afetam as pessoas, os riscos de imparcialidade aumentam. Capacidade de explicar (entender por que um agente agiu), capacidade de contestação (decisões desafiadoras) e Human-in-the-Loop (supervisão proporcional) se tornam essenciais. Consulte [Agent Enterprise Fairness](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-fairness.html). Para saber mais, consulte Pilar de [Justiça](/docs/architect/pt-br/well-architected/guide/fairness.html) e [Justiça empresarial da agência](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-fairness.html). ## Como os pilares interagem Nenhum pilar existe em isolamento. Decisões arquitetônicas em um pilar inevitavelmente afetam outras: - Controles de Trust mais fortes (criptografia, registro de auditoria) consomem mais recursos e aumentam o custo (Otimização de recursos e custo) e aumentam a latência afetando a confiabilidade - Maior confiabilidade (redundância, várias regiões) aumenta o custo (Otimização de recursos e custos) e a complexidade operacional (Excelência operacional) - A imposição de equidade mais abrangente (supervisão humana, monitoramento de viés) diminui a taxa de transferência do agente (Otimização de recurso e custo) - Maior maturidade de Excelência Operacional (instrumentação abrangente) permite uma melhor imposição do Trust e detecção antecipada de problemas de Fairness Essas interações significam que a qualidade arquitetônica é sempre um equilíbrio. A estrutura ajuda os arquitetos a entender o que estão negociando e fazer essas negociações intencionalmente. A meta não é maximizar cada pilar ao mesmo tempo, é alcançar o perfil de qualidade certo para os requisitos de uma determinada solução, tolerância ao risco e contexto de negócios.

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

# Ética e governança de IA – Padrões Saiba mais sobre a [justiça](/docs/architect/pt-br/well-architected/guide/fairness.html) bem arquitetada → [Praxis Ethical AI Governance](/docs/architect/pt-br/well-architected/guide/fairness.html#practice-ethical-ai-governance) ## Detecção de viés e validação de imparcialidade **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Einstein \| Dados de treinamento | ✅ Os dados do Salesforce CRM são auditados quanto a lacunas de representação demográfica e inconsistências de medição antes de treinar modelos preditivos | | Einstein \| Dados de treinamento | ✅ Os dados de conversão históricos são analisados pela demografia do cliente para identificar segmentos subrepresentados que exigem excesso de amostragem ou coleta de dados adicionais | | Einstein \| Implantação | ✅ A avaliação de imparcialidade é tratada como um gateway obrigatório equivalente à revisão de segurança antes que os modelos preditivos cheguem à produção | | Einstein \| Implantação | ✅ Paridade demográfica, igualdade de oportunidades e índices de impacto diferentes são calculados entre grupos protegidos antes da implementação | | Einstein \| Implantação | ✅ As métricas de imparcialidade são avaliadas em relação à regra de quatro quintos (limite de 80%) como um acionador de triagem, não uma linha de aprovação/falha legal, para todos os segmentos do cliente antes da implantação do modelo | | Einstein Discovery \| Instrumentação | ✅ Dados de decisão de modelo preditivo – entradas de previsão, saídas e versões de modelo – são capturados por meio do Einstein Discovery e de instrumentos personalizados que permitem a detecção de viés | | CRM Analytics \| Monitoramento | ✅ Painéis do CRM Analytics analisam dados de decisão de modelo preditivo capturados para padrões de decisão em grupos demográficos ao longo do tempo | | CRM Analytics \| Monitoramento | ✅ Os alertas do CRM Analytics são acionados quando as métricas de paridade demográfica ou de igualdade de oportunidades ultrapassam limites aceitáveis | | Einstein \| Engenharia de recursos | ✅ Todos os recursos do modelo preditivo são analisados quanto à correlação com características protegidas usando métodos estatísticos | | Einstein \| Engenharia de recursos | ✅ Recursos de proxy (território, CEP, padrões de nome da conta, momento da atividade, tipo de dispositivo) são identificados e avaliados quanto à correlação demográfica | | Einstein \| Engenharia de recursos | ✅ Recursos de proxy são removidos ou transformados depois de avaliar se o valor preditivo justifica a inclusão apesar dos efeitos de proxy | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Einstein \| Dados de treinamento | A pontuação de lead é treinada com base em 10 anos de dados históricos sem examinar a representação demográfica ou as diferenças de qualidade do serviço | | Einstein \| Dados de treinamento | Dados de conversão históricos são usados diretamente sem auditar se diferentes demográficos receberam tratamento diferente | | Einstein \| Implantação | Os recursos do Einstein são implementados apenas com base em métricas de precisão gerais sem avaliação de equidade | | Einstein \| Implantação | ⚡️ Paridade demográfica ou índices de impacto diferentes não são calculados antes da implementação da produção | | Einstein \| Camada Trust | ⚡️ As interações do Agentforce são implementadas sem habilitar a captura de auditoria da Camada de Trust para detecção de viés | | CRM Analytics \| Monitoramento | Padrões de decisão não são rastreados por grupos demográficos ao longo do tempo; o desvio de viés não é detectado | | Einstein \| Engenharia de recursos | Características protegidas são removidas dos dados de treinamento presumindo que isso elimine automaticamente o viés | | Einstein \| Engenharia de recursos | Padrões de território, CEP e nome da conta são usados como recursos sem análise de correlação de proxy | | Einstein \| Engenharia de recursos | Recursos de proxy que servem como proxies demográficos perfeitos são retidos sem avaliar alternativas | ## Monitoramento de imparcialidade contínuo **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Análise | ✅ Os painéis do CRM Analytics rastreiam os resultados da decisão do Agentforce por demografia do cliente usando dados de auditoria da Camada de Trust do Einstein | | Agentforce \| Análise | ✅ Taxas de aprovação, tempos de resposta de serviço, taxas de escalação e pontuações de satisfação são monitorados estratificados por grupo demográfico | | Agentforce \| Análise | ✅ Os alertas do CRM Analytics são configurados para serem acionados quando métricas de justiça violam limites definidos exigindo investigação | | Agentforce \| Monitoramento de evento | ✅ Os registros de Monitoramento de evento são roteados para SIEM externo para retenção de longo prazo excedendo os limites de retenção nativos | | Agentforce \| Monitoramento de evento | ✅ Consultas SIEM identificam concentrações anômalas de resultados negativos para populações de usuários específicas | | Agentforce \| Trilha de auditoria de campo | ✅ A Trilha de auditoria de campo é ativada em objetos personalizados que armazenam dados de decisão do Agentforce, mantendo o histórico arquivado indefinidamente até ser excluído | | Agentforce \| Trilha de auditoria de campo | ✅ A Trilha de auditoria de campo dá suporte a auditorias de equidade de longo prazo e investigações regulatórias que exigem reconstrução de decisões históricas de IA | | CRM Analytics \| Monitoramento | ✅ Painéis do CRM Analytics rastreiam sinais de imparcialidade: mudanças súbitas em distribuições de decisão, picos em casos relacionados a viés, degradação do desempenho para populações específicas | | CRM Analytics \| Monitoramento | ✅ Alertas são acionados quando as taxas de aprovação de qualquer segmento de cliente caem mais de 15% semanalmente exigindo investigação de imparcialidade | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Análise | ⚡️ Os resultados da decisão não são rastreados pela demografia; o desvio de viés não é detectado conforme as distribuições de dados mudam | | Agentforce \| Análise | As métricas de qualidade do serviço não são estratificadas por grupo demográfico; resultados diferentes permanecem invisíveis | | Agentforce \| Monitoramento de evento | ⚡️ Os registros de Monitoramento de evento dependem de limites de retenção nativos sem SIEM externo para auditorias de imparcialidade de longo prazo | | Agentforce \| Monitoramento de evento | Padrões de decisão não são analisados em grandes volumes de interações; concentrações anômalas são perdidas | | Agentforce \| Trilha de auditoria de campo | A Trilha de auditoria de campo não está habilitada; decisões históricas de IA não podem ser reconstruídas para investigações regulatórias | | CRM Analytics \| Monitoramento | Os sinais de imparcialidade não são monitorados; alterações súbitas nas distribuições de decisão ficam despercebidas | ## Estratégia de mitigação de viés **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Einstein \| Dados de treinamento | ✅ Os dados do Salesforce CRM são reequilibrados excedendo a amostragem de segmentos subrepresentados ou subexcluindo a amostragem de segmentos sobrerepresentados antes do treinamento | | Data 360 \| Arquitetura | ✅ O Data 360 agrega dados em várias organizações garantindo vários conjuntos de treinamento para modelos preditivos | | Einstein \| Dados de treinamento | ✅ A geração de dados sintéticos complementa segmentos escassos enquanto preserva a privacidade por meio de técnicas de privacidade diferencial | | Einstein \| Engenharia de recursos | ✅ Recursos de proxy são substituídos por recursos alternativos que fornecem poder preditivo sem correlação demográfica | | Einstein \| Engenharia de recursos | ✅ Classificação do setor ou tamanho da empresa são usados em vez de território quando o território serve como proxy demográfico | | Einstein \| Engenharia de recursos | ✅ Atributos firmográficos são usados em vez de padrões de nome da conta quando os nomes estão correlacionados com a demografia | | Agentforce \| Pós-processamento | ✅ Os limites de decisão são ajustados por segmento demográfico para igualar as taxas de resultados após o treinamento de modelo, exceto que, nos Estados Unidos, o Título VII (Lei de Direitos Civis de 1991) proíbe ajustar pontuações ou cortes por classe protegida para decisões relacionadas ao emprego, e outras jurisdições impõem suas próprias restrições | | Agentforce \| Pós-processamento | ✅ Limites de confiança diferentes são usados para diferentes contextos que alcançam taxas de aprovação justas enquanto usam o mesmo modelo preditivo subjacente | | Agentforce \| Pós-processamento | ✅ Os ajustes de limite são documentados com a justificativa de negócios para tratamento diferencial, reconhecendo que, nos Estados Unidos, nenhuma documentação torna o ajuste de pontuação por grupo legal para decisões relacionadas ao emprego sob o título VII | | Einstein \| Treinamento de modelo | ✅ A agenda de treinamento trimestral ou conduzido por evento é estabelecida capturando padrões de viés emergentes e corrigindo o desvio das linhas de base de fairness originais | | Einstein \| Treinamento de modelo | ✅ As métricas de imparcialidade são revalidadas em cada versão do modelo antes da implementação de produção, garantindo que o treinamento novamente não tenha introduzido um novo viés | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Einstein \| Dados de treinamento | Dados de treinamento são usados diretamente sem reequilibrar segmentos subrepresentados ou sobrerepresentados | | Einstein \| Dados de treinamento | Segmentos demográficos escassos não são complementados com dados sintéticos ou agregação entre organizações | | Einstein \| Engenharia de recursos | Recursos de proxy são retidos sem avaliar recursos alternativos, fornecendo poder preditivo sem correlação demográfica | | Agentforce \| Pós-processamento | ⚡️ Os mesmos limites de confiança são aplicados a todos os segmentos demográficos sem igualar as taxas de resultado | | Agentforce \| Pós-processamento | ⚡️ O tratamento diferencial por meio de ajustes de limite não tem justificativa comercial documentada ou, nos Estados Unidos, é aplicado a decisões relacionadas ao emprego, em que o Título VII proíbe ajustar pontuações ou cortes por classe protegida independentemente da documentação | | Einstein \| Treinamento de modelo | ⚡️ Os modelos são implementados e nunca são treinados novamente; padrões de viés e desvio emergentes não são corrigidos | | Einstein \| Treinamento de modelo | ⚡️ O treinamento novamente ocorre sem revalidar as métricas de fairness; o novo viés é introduzido silenciosamente | ## Capacidade de explicação e transparência de IA **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Einstein Discovery \| UX | ✅ Explicações do Einstein Discovery mostrando fatores de previsão aparecem nos componentes do Lightning no ponto de decisão | | Einstein Discovery \| UX | ✅ As explicações mostram quais variáveis mais influenciaram previsões específicas com impacto direcional para os usuários em pontos de decisão | | Einstein Discovery \| UX | ✅ As explicações são estratificadas para diferentes públicos: usuários de negócios, usuários técnicos, clientes e auditores | | Einstein Discovery \| UX | ✅ Usuários de negócios veem "Esse lead pontuou alto porque a receita anual excede US$ 1 milhão e a pontuação de engajamento está no top 10%" | | Einstein Discovery \| UX | ✅ Usuários técnicos veem cartões de modelo com pesos de recurso, características de dados de treinamento e métricas de validação | | Einstein Discovery \| UX | ✅ Os clientes veem "Essa recomendação é baseada em suas compras recentes e clientes com preferências semelhantes" | | Einstein Discovery \| UX | ✅ Os auditores veem a linha de decisão completa do Einstein Discovery e do Gerenciador de modelo com a versão do modelo, os valores de entrada e os fatores que impulsionaram a previsão | | Einstein Discovery \| UX | ✅ A confiança da previsão é exibida em termos adequados ao usuário como categorias (Alta confiança, Moderar confiança, Requer revisão) com explicações | | Einstein Discovery \| UX | ✅ Categorias de confiança explicam o que o nível de confiança significa para a confiabilidade da decisão e qual revisão adicional ocorrerá | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Einstein Discovery \| UX | ⚡️ As explicações são adaptadas aos sistemas opacos após a implantação, em vez de criar capacidade de explicação na arquitetura desde o início | | Einstein Discovery \| UX | ⚡️ As explicações de previsão exigem navegação para separar painéis do CRM Analytics em vez de exibir em pontos de decisão | | Einstein Discovery \| UX | ⚡️ Os usuários veem métricas de desempenho de modelo abstrato em vez de explicações transparentes quando as decisões os afetam | | Einstein Discovery \| UX | As explicações não variam de acordo com o público; os cartões de modelo técnico são mostrados a clientes ou usuários de negócios | | Einstein Discovery \| UX | As pontuações de previsão brutas (0,73) são exibidas sem explicação do que o número significa ou quais fatores impulsionaram a previsão | | Einstein Discovery \| UX | A confiança é mostrada como porcentagens de probabilidade que os usuários interpretam incorretamente sem contexto sobre a confiabilidade ou a revisão | ## Trilha de auditoria e conformidade **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Einstein \| Camada Trust | ✅ Einstein Trust Layer registra avisos, respostas, origens de fundamentação e sinais Trust automaticamente sem instrumentação personalizada | | Einstein \| Camada Trust | ✅ As políticas de retenção de dados são projetadas para atender aos requisitos regulatórios que variam de acordo com o setor e a jurisdição (por exemplo, a regra FINRA 4511(b) define um período de retenção padrão de seis anos e a HIPAA exige um mínimo de seis anos para a documentação de conformidade) | | CRM Analytics \| Monitoramento | ✅ Os painéis do CRM Analytics analisam dados de decisão de modelo preditivo capturados para padrões de decisão, métricas de imparcialidade e desempenho do modelo ao longo do tempo | | CRM Analytics \| Monitoramento | ✅ Os lenses do CRM Analytics mostram distribuições de previsão por nível de confiança, segmento demográfico e tipo de resultado | | CRM Analytics \| Monitoramento | ✅ Histórias do Einstein Discovery identificam padrões anômalos que exigem investigação | | Plataforma \| Trilha de auditoria de campo | ✅ A Trilha de auditoria de campo está habilitada em objetos personalizados que armazenam dados de decisão de IA, mantendo o histórico arquivado indefinidamente até serem excluídos para registros de consentimento, substituir decisões e reportar vieses | | Plataforma \| Monitoramento de evento | ✅ Monitoramento de evento captura transcrições de conversa do Agentforce, invocações de ferramentas e pontos de decisão | | Plataforma \| Monitoramento de evento | ✅ Os registros de Monitoramento de evento são roteados para SIEM externo por meio de Eventos de plataforma para armazenamento com evidência de adulteração | | Plataforma \| Monitoramento de evento | ✅ Consultas SIEM detectam padrões de viés em grandes volumes de interações do Agentforce | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Einstein \| Camada Trust | ⚡️ As interações do Agentforce são implementadas sem habilitar a captura de auditoria da Camada de Trust nem definir políticas de retenção | | Einstein \| Camada Trust | ⚡️ As políticas de retenção não consideram requisitos regulatórios específicos do setor (Serviços financeiros, cuidados de saúde) | | CRM Analytics \| Monitoramento | Dados de decisão de modelo preditivo capturados não são analisados; padrões de decisão e métricas de imparcialidade não são rastreados ao longo do tempo | | Plataforma \| Trilha de auditoria de campo | ⚡️ O histórico de campo padrão de 18 meses é baseado em trilhas de auditoria de decisão de IA sem considerar requisitos de retenção regulatória | | Plataforma \| Trilha de auditoria de campo | A Trilha de auditoria de campo não está habilitada em objetos com registros de consentimento, decisões de substituição e relatórios de viés | | Plataforma \| Monitoramento de evento | ⚡️ Os registros de Monitoramento de evento dependem de limites de retenção nativos sem SIEM externo para armazenamento de longo prazo com evidência de adulteração | | Plataforma \| Monitoramento de evento | ⚡️ Os registros de interação do Agentforce não são analisados quanto a padrões de viés em grandes volumes | ## Posicionamento de conformidade regulatória **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Governança \| Lei de IA da UE | ✅ Os sistemas de IA de alto risco são documentados com documentação de transparência, documentação técnica, recursos de supervisão humana e métricas de precisão/justiça | | Governança \| Lei de IA da UE | ✅ Trilhas de auditoria da Camada de Trust do Einstein e cartões de modelo do Discovery fornecem as bases para os requisitos de transparência da Lei de IA da UE | | Governança \| Lei de IA da UE | ✅ Demografia de dados de treinamento do modelo, abordagens de validação e limitações conhecidas são documentadas em registros de decisão de arquitetura | | Governança \| GDPR | ✅ Os sistemas geram explicações coerentes para qualquer decisão histórica sob demanda dentro dos períodos de solicitação de acesso do sujeito dos dados (que variam conforme a jurisdição, entre 15 e 45 dias) | | Governança \| GDPR | ✅ Os dados de decisão do modelo preditivo capturados e os fatores de explicação do Einstein Discovery são armazenados com retenção suficiente para permitir a reconstrução da explicação para o direito de explicação do GDPR | | Governança \| Responsabilidade algorítmica | ✅ As avaliações de impacto algorítmico são realizadas antes de implementar a IA consequente como conformidade proativa, em vez de resposta reativa | | Governança \| Responsabilidade algorítmica | ✅ Dados de decisão de modelo preditivo capturados e painéis de monitoramento de equidade do CRM Analytics fornecem bases de dados para relatórios de responsabilidade algorítmica | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Governança \| Lei de IA da UE | Os sistemas de IA de alto risco são implementados sem documentação de transparência, recursos de supervisão humana ou métricas de imparcialidade | | Governança \| Lei de IA da UE | ⚡️ A demografia de dados de treinamento do modelo e as limitações conhecidas não são documentadas nos registros de decisão de arquitetura | | Governança \| GDPR | ⚡️ Os sistemas não podem gerar explicações coerentes para decisões históricas dentro dos períodos de solicitação de acesso do sujeito dos dados do GDPR | | Governança \| GDPR | A retenção de dados de decisão do modelo preditivo capturada é insuficiente para dar suporte à reconstrução de explicações para decisões anteriores | | Governança \| Responsabilidade algorítmica | As avaliações de impacto algorítmico não são realizadas antes da implantação de IA consequente; a conformidade é reativa após a consulta regulatória | ## Acesso a dados e não discriminação **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| OWD | ✅ Os padrões privados para toda a organização são estabelecidos para objetos que contêm dados confidenciais do cliente com acesso concedido por meio de hierarquia de papéis e regras de compartilhamento | | Plataforma \| OWD | ✅ OWDs privados com concessões de compartilhamento explícitas criam padrões de acesso auditáveis compatíveis com a conformidade de não discriminação | | Plataforma \| Segurança em nível de campo | ✅ Campos confidenciais contendo características protegidas (etnia, religião, status de deficiência) são ocultados por meio do FLS de usuários sem necessidade comercial legítima | | Plataforma \| Segurança em nível de campo | ✅ O acesso de leitura a campos confidenciais é removido por meio do FLS para a maioria dos perfis; o acesso é concedido pelo menos por meio de conjuntos de permissões com justificativa documentada | | Plataforma \| Atribuição e roteamento | ✅ Regras de atribuição, filas e roteamento do Omni-Channel distribuem trabalho de maneira uniforme entre territórios, equipes e agentes de serviço com base em critérios objetivos | | Plataforma \| Regras de compartilhamento | ✅ Regras de compartilhamento automáticas são baseadas em critérios objetivos (industria, geografia, linha de produto) em vez de critérios de discrição subjetiva do gerente | | Plataforma \| Conjuntos de permissões | ✅ O acesso temporário a dados confidenciais é concedido por meio de conjuntos de permissões com expiração documentada em vez de modificações de perfil permanentes | | Plataforma \| Conjuntos de permissões | ✅ Fluxo agendado revoga conjuntos de permissões automaticamente após períodos definidos quando o acesso a dados demográficos é necessário para projetos específicos | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| OWD | ⚡️ OWDs de leitura/gravação pública tornam a restrição de acesso mais tarde disruptiva (aprimorar o padrão aciona um recálculo de compartilhamento); padrões de acesso auditáveis não existem | | Plataforma \| OWD | O OWD da conta é definido como Leitura/Gravação pública com campos demográficos não protegidos visíveis a todos os usuários habilitando viés subjetivo | | Plataforma \| Segurança em nível de campo | Campos demográficos confidenciais são visíveis a todos os perfis sem restrições de FLS; o uso de dados discriminatórios não é impedido | | Plataforma \| Regras de compartilhamento | ⚡️ O compartilhamento manual concentra oportunidades de alto valor com grupos de usuários específicos sem justificativa de negócios documentada | | Plataforma \| Regras de compartilhamento | ⚡️ Regras de compartilhamento dependem de critérios subjetivos do gerente, em vez de critérios objetivos que permitem viés | | Plataforma \| Conjuntos de permissões | ⚡️ Os perfis são modificados de modo permanente, afetando todos os usuários em vez de conceder acesso temporário por meio de conjuntos de permissões | | Plataforma \| Conjuntos de permissões | Conjuntos de permissões que concedem acesso a dados confidenciais não expiram automaticamente; o acesso permanece indefinido após a conclusão do projeto | ## Acessar monitoramento de padrão **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Shield \| Monitoramento de evento | ✅ O Monitoramento de evento Shield rastreia o acesso a campos que contêm características protegidas ou atributos confidenciais | | Shield \| Monitoramento de evento | ✅ O Monitoramento de evento consulta quem acessa os campos demográficos, quando e em que contexto detectar padrões anômalos | | Shield \| Monitoramento de evento | ✅ Padrões de acesso anômalos (picos súbitos, acesso por usuários inesperados) acionam investigação para possíveis abusos | | Plataforma \| Relatórios | ✅ Relatórios analisam como as regras de compartilhamento distribuem registros entre usuários, equipes e territórios calculando estatísticas de distribuição por demografia do cliente | | Plataforma \| Relatórios | ✅ Os relatórios identificam concentrações em que grupos de usuários específicos recebem acesso desproporcionado a registros valiosos sem justificativa documentada | | Plataforma \| Trilha de auditoria de configuração | ✅ A Trilha de auditoria de configuração é revisada quanto a alterações nas configurações de OWD, regras de compartilhamento, configurações de FLS e conjuntos de permissões detectando alterações não autorizadas | | Plataforma \| Segurança da transação | ✅ As políticas de segurança da transação atuam em eventos de Monitoramento de evento em tempo real de alto risco (atividade de API anômala, logins suspeitos, grandes exportações de dados confidenciais); as alterações de FLS e compartilhamento dependem da Trilha de auditoria de configuração e aprovações de gerenciamento de alterações documentadas | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Shield \| Monitoramento de evento | ⚡️ O acesso a campos demográficos confidenciais não é monitorado; possíveis abusos não são detectados | | Shield \| Monitoramento de evento | Padrões de acesso anômalos (piques, usuários inesperados) não são rastreados nem investigados | | Plataforma \| Relatórios | As distribuições de regra de compartilhamento não são analisadas; o acesso desproporcionado a registros valiosos permanece invisível | | Plataforma \| Relatórios | Concentrações de contas de alto valor com grupos de usuários específicos não têm justificativa de negócios documentada | | Plataforma \| Trilha de auditoria de configuração | A Trilha de auditoria de configuração não foi revisada; alterações não autorizadas nos controles de acesso a dados que permitem acesso a dados confidenciais não são detectadas | | Plataforma \| Segurança da transação | Eventos de Monitoramento de evento em tempo real de alto risco (atividade de API anômala, grandes exportações de dados confidenciais) não são atendidos com as políticas de segurança da transação | ## Gerenciamento de consentimento do usuário **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Objetos personalizados | ✅ O consentimento granular por caso de uso de IA é habilitado por meio de propósito de rastreamento de objeto de consentimento personalizado, data/método de concessão, data de retirada e ID de usuário/contato relacionado | | Plataforma \| Objetos personalizados | ✅ Consentimento dos clientes para recomendações de produto do Einstein enquanto recusa decisões de crédito conduzidas por IA por meio de registros de consentimento separados por caso de uso | | Plataforma \| Trilha de auditoria de campo | ✅ A Trilha de auditoria de campo está habilitada no objeto Consentimento para cumprir requisitos regulatórios de retenção de longo prazo | | Data 360 \| Consentimento | ✅ O gerenciamento de consentimento do Data 360 é usado para recursos de Personalização do Einstein, ingerindo e armazenando preferências de consentimento por meio de conectores mapeados para o Modelo de dados de privacidade e usando-os como critérios de filtro na segmentação e na ativação | | Data 360 \| Consentimento | ✅ Categorias de consentimento são mapeadas para casos de uso de IA específicos que permitem que os usuários recusem a personalização enquanto mantêm o serviço principal | | Marketing Cloud \| Consentimento | ✅ Consentimento do Marketing Cloud integra-se com o Einstein Messaging Insights e agentes de marketing Agentforce respeitando o status da assinatura | | Marketing Cloud \| Consentimento | ✅ O status do consentimento do Marketing Cloud é consultado antes que o Agentforce inicie o esforço de contato automatizado para evitar contato indesejado com usuários que optaram por sair | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Objetos personalizados | ⚡️ O consentimento de IA é rastreado em planilhas ou depende do login como consentimento geral implícito sem registros explícitos | | Plataforma \| Objetos personalizados | ⚡️ O consentimento de IA em branco é usado em vez do consentimento granular por caso de uso; os usuários não podem recusar recursos de IA específicos | | Plataforma \| Trilha de auditoria de campo | A Trilha de auditoria de campo não está habilitada no objeto Consentimento; a retenção de longo prazo cumpre os requisitos regulatórios não é mantida | | Data 360 \| Consentimento | O consentimento do Data 360 não é usado para Personalização do Einstein; as categorias de consentimento não são mapeadas para casos de uso específicos | | Marketing Cloud \| Consentimento | O consentimento do Marketing Cloud não é integrado ao Einstein ou Agentforce; o status da assinatura não é respeitado no alcance automatizado | ## Recusa e preferência do usuário **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Experience Cloud \| Configurações de perfil | ✅ Os usuários recusam interações do Agentforce por meio de controles de preferências acessíveis nas configurações de perfil do Experience Cloud ou Minhas configurações com descrições claras | | Plataforma \| Registros de usuário/contato | ✅ As preferências de IA são armazenadas nos registros de Usuário ou Contato ativando a consulta na lógica de decisão de Fluxo e Agentforce | | Agentforce \| Omni-Channel | ✅ Usuários que optam por sair do Agentforce são encaminhados para agentes humanos por meio do Omni-Channel em vez de receber um serviço degradado | | Agentforce \| Fluxo | ✅ O fluxo verifica o consentimento e os campos de preferência antes do engajamento do Agentforce; se o usuário optou por sair, o registro de trabalho é criado e roteado para a fila humana | | Agentforce \| Omni-Channel | ✅ A equipe da fila humana fornece tempos de espera comparáveis ao serviço automatizado para usuários que recusaram | | Plataforma \| Registros de usuário/contato | ✅ As preferências de IA são armazenadas em registros de Usuário ou Contato garantindo a consistência entre canais (web, celular, telefone, email) | | Plataforma \| Fluxo | ✅ A preferência é consultada de modo consistente em todos os fluxos de interação, impedindo que os usuários precisem declarar preferências repetidamente em cada canal | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Experience Cloud \| Configurações de perfil | O cancelamento está disponível apenas por email para a equipe de suporte; controles de preferência acessíveis não existem | | Plataforma \| Registros de usuário/contato | As preferências de IA não são armazenadas nos registros de Usuário ou Contato; as preferências não podem ser consultadas na lógica de Fluxo ou Agentforce | | Agentforce \| Omni-Channel | ⚡️ Usuários que recusam receberem serviço degradado como pressão implícita para aceitar a IA em vez de rotear para agentes humanos | | Agentforce \| Fluxo | O Fluxo não verifica os campos de consentimento ou preferência antes do engajamento do Agentforce; as preferências de recusa são ignoradas | | Plataforma \| Registros de usuário/contato | As preferências não são consistentes entre canais; os usuários devem declarar novamente o cancelamento na Web, dispositivo móvel, telefone e email separadamente | ## Documentação de governança de IA **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Governança \| Documentação | ✅ Cada modelo preditivo de produção é documentado com dados demográficos de treinamento, métricas de equidade, casos de uso pretendidos, estratégias de mitigação de viés e abordagens de monitoramento | | Governança \| Documentação | ✅ A documentação do modelo inclui a abordagem de monitoramento de equidade, limites de alerta, requisitos de supervisão humana, agenda de revisão e considerações regulatórias | | Plataforma \| Objetos personalizados | ✅ A documentação do modelo é armazenada no Salesforce usando o objeto Modelo personalizado ou Salesforce Files anexado a Projetos habilitando a capacidade de pesquisa e controle de versão | | Governança \| Gates de implementação | ✅ Os portões de equidade pré-implementação exigem auditoria de dados de treinamento, cálculo de métricas de equidade, avaliação de impacto, design de supervisão humana e análise de transparência antes da produção | | Governança \| Gates de implementação | ✅ Lacunas de representação de dados de treinamento são analisadas e documentadas como gateway de implementação obrigatório | | Governança \| Gates de implementação | ✅ Paridade demográfica, oportunidades iguais e impacto distinto são calculados para cumprir limites como gate obligatório | | Governança \| Gates de implementação | ✅ A avaliação de impacto avalia possíveis danos em populações afetadas como gateway obrigatório | | Governança \| Gates de implementação | ✅ O design de supervisão humana, incluindo padrões de escalação, fluxos de trabalho de aprovação e mecanismos de substituição, é projetado e testado como um gate obligatório | | Governança \| Gates de implementação | ✅ Os recursos de explicação são validados para todos os tipos de decisão como gate obligatório | | Governança \| Gates de implementação | ✅ Os portões de imparcialidade são tratados com a mesma rigor que os portões de segurança com autoridade para bloquear implantações com falha em qualquer portão | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Governança \| Documentação | Os recursos do Einstein são implementados sem documentar dados de treinamento, métricas de equidade, mitigação de viés ou abordagens de monitoramento | | Governança \| Documentação | A documentação do modelo não inclui a abordagem de monitoramento de equidade, requisitos de supervisão humana ou considerações regulatórias | | Plataforma \| Objetos personalizados | A documentação do modelo é armazenada em planilhas ou wikis sem capacidade de pesquisa ou controle de versão | | Governança \| Gates de implementação | Os recursos do Einstein passam à produção sem portões de equidade; a implantação é baseada apenas em métricas de precisão gerais | | Governança \| Gates de implementação | ⚡️ Auditoria de dados de treinamento, cálculo de métricas de equidade ou avaliação de impacto são ignorados antes da implementação da produção | | Governança \| Gates de implementação | ⚡️ Design de supervisão humana, revisão de transparência ou validação de explicação não são realizados antes da produção | | Governança \| Gates de implementação | ⚡️ Os portões de imparcialidade são somente consultoria sem autorização para bloquear implantações; os modelos avançam apesar de critérios de imparcialidade falharem | ## Board de revisão de ética de IA **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Governança \| Conselho de revisão | ✅ O painel de revisão inclui especialistas técnicos (arquitetos, cientistas de dados), partes interessadas de negócios, consultores jurídicos, especialistas em privacidade e representantes de comunidades afetadas | | Governança \| Conselho de revisão | ✅ Diversas perspectivas detectam problemas de equidade que grupos homogêneos ignoram durante a revisão de ética | | Governança \| Revisar acionadores | ✅ Os acionadores de revisão são definidos: decisões que afetam direitos de emprego/crédito/alojamento/saúde/legal, sistemas que afetam >10 mil usuários por ano, novos casos de uso, risco significativo de dano | | Governança \| Revisar acionadores | ✅ Os aplicativos de IA que usam dados pessoais confidenciais (saúde, financeiro, demográfico) exigem revisão de ética antes da implementação | | Governança \| Autoridade de revisão | ✅ O comitê de análise de ética tem autoridade para exigir alterações, impor condições de monitoramento ou bloquear implantações com falha nos padrões éticos | | Plataforma \| Objetos personalizados | ✅ Todas as revisões são documentadas no nome do aplicativo de rastreamento de objeto personalizado do Salesforce, na data da revisão, nas preocupações levantadas, nos requisitos de mitigação e nas condições de aprovação | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Governança \| Conselho de revisão | ⚡️ O painel de revisão não tem diversidade (apenas especialistas técnicos); grupos homogêneos não têm problemas de equidade que afetam diferentes populações | | Governança \| Conselho de revisão | ⚡️ Representantes de comunidades afetadas não são incluídos; resultados de pontos cegos em considerações de imparcialidade | | Governança \| Revisar acionadores | Acionadores de revisão não são definidos; aplicativos de IA de alto risco prosseguem sem revisão de ética antes da implementação | | Governança \| Autoridade de revisão | ⚡️ A revisão de ética é somente consultoria sem imposição; as implantações prosseguem apesar da falha nos padrões éticos (teatro de responsabilidade) | | Plataforma \| Objetos personalizados | As revisões não são documentadas sistematicamente; decisões de revisão históricas, preocupações e mitigações não são rastreadas | ## Governança de imparcialidade contínua **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | CRM Analytics \| Monitoramento | ✅ Painéis do CRM Analytics rastreiam métricas de fairness do Einstein e do Agentforce de dados de decisão capturados e dados de auditoria da Camada de Trust em um ritmo agendado | | CRM Analytics \| Monitoramento | ✅ Paridade demográfica, oportunidades iguais, índices de impacto diferentes e métricas de qualidade do serviço são monitoradas pelo segmento do cliente | | CRM Analytics \| Monitoramento | ✅ Os alertas do CRM Analytics são configurados para serem acionados quando métricas de justiça violam limites definidos exigindo investigação | | CRM Analytics \| Monitoramento | ✅ Painéis do CRM Analytics rastreiam sinais de imparcialidade: mudanças súbitas em distribuições de decisão, picos em casos relacionados a viés, degradação do desempenho para populações específicas | | CRM Analytics \| Monitoramento | ✅ Acionam alertas para a Pontuação de oportunidade do Einstein quando as taxas de aprovação de qualquer segmento caem mais de 15% semanalmente, exigindo investigação de equidade | | Governança \| Auditorias agendadas | ✅ Auditorias de imparcialidade abrangentes são realizadas trimestralmente para IA de alta participação (crédito, emprego, saúde) ou semestral para sistemas de baixa participação | | Governança \| Auditorias agendadas | ✅ Auditorias examinam métricas de fairness atuais, revisam padrões de substituição, analisam relatórios de feedback e viés do usuário e validam os controles de governança que permanecem efetivos | | Governança \| Resposta a incidentes | ✅ Processos de resposta a incidentes claros são documentados no Salesforce Knowledge para responder quando viés é detectado | | Governança \| Resposta a incidentes | ✅ Avaliação de gravidade imediata consultando dados de decisão de modelo preditivo no CRM Analytics; um viés grave suspende a tomada de decisão automatizada aguardando a investigação | | Governança \| Resposta a incidentes | ✅ A mitigação temporária implementa maior supervisão humana por meio de limites de confiança ajustados, desabilitação de recurso ou suspensão completa do agente | | Governança \| Resposta a incidentes | ✅ A análise de causa raiz identifica como o viés foi inserido ou evoluído; dados de treinamento, versões do modelo e alterações de configuração são analisados por meio da Trilha de auditoria de campo | | Governança \| Resposta a incidentes | ✅ A remediação permanente implementa a correção de dados, o novo treinamento de modelo ou as alterações de processo com a comunicação adequada aos usuários afetados | | Governança \| Resposta a incidentes | ✅ Medidas de prevenção são documentadas em manuais que impedem a recorrência de incidentes de viés | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | CRM Analytics \| Monitoramento | As métricas de imparcialidade não são rastreadas em nenhum ritmo agendado de dados de decisão capturados ou dados de auditoria da Camada de Trust; o desvio de viés não é detectado conforme as distribuições de dados mudam | | CRM Analytics \| Monitoramento | Alertas do CRM Analytics não são configurados; violações de métrica de justiça que exigem investigação não são acionadas | | CRM Analytics \| Monitoramento | Os sinais de imparcialidade não são monitorados; alterações súbitas nas distribuições de decisão não são detectadas | | Governança \| Auditorias agendadas | ⚡️ Auditorias de imparcialidade abrangentes não são realizadas em nenhuma agenda; os controles de governança se desviam e tornam-se ineficazes | | Governança \| Auditorias agendadas | Padrões de substituição, feedback do usuário e relatórios de viés não são analisados sistematicamente durante auditorias | | Governança \| Resposta a incidentes | ⚡️ Processos de resposta a incidentes claros não são documentados; a detecção de viés leva a respostas ad hoc sem abordagem sistemática | | Governança \| Resposta a incidentes | ⚡️ A mitigação temporária ou a remediação permanente não são implementadas sistematicamente; o viés persiste afetando os usuários | | Governança \| Resposta a incidentes | A análise de causa raiz não é realizada; como o viés inserido ou evoluído permanece desconhecido | | Governança \| Resposta a incidentes | ⚡️ As medidas de prevenção não são documentadas; a recorrência não é evitada | ## Qualidade dos dados e equidade representativa **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Campos obrigatórios | ✅ Cada campo obrigatório contém uma justificativa comercial documentada para o motivo pelo qual os dados são obrigatórios em vez de opcionais; os campos sem os quais um processo pode funcionar são tornados opcionais com o tratamento a jusante para valores ausentes | | Plataforma \| Campos obrigatórios | ✅ Email é opcional com métodos de comunicação alternativos (SMS, telefone, correio postal) para que usuários sem email pessoal ou confiável na Internet não sejam excluídos da criação da conta | | Plataforma \| Campos de nome | ✅ A arquitetura de nomes usa um único campo de nome completo ou uma estrutura flexível de várias partes que acomoda monônimos, sistemas de apelidos e vários nomes de família ou dados sem presumir ordem ou herança | | Plataforma \| Campos de nome | ✅ Campos de nome são testados com diversos nomes internacionais, aceitando nomes de palavra única, nomes longos, diácritos, apostrofes, hifens e scripts não latinos (árabe, chinês, cirílico, devanagari) | | Plataforma \| Validação de endereço | ✅ A validação de endereço permitida aceita entrada em forma livre quando a validação estruturada falha e armazena endereços conforme os usuários os inserem, em vez de forçar correções inválidas | | Plataforma \| Validação de endereço | ✅ A verificação de endereço é integrada em processos de cumprimento em que a precisão importa operacionalmente em vez de bloquear a captura de dados antecipadamente | | Plataforma \| Preferências de comunicação | ✅ Os métodos de comunicação preferenciais são armazenados em registros de Contato e respeitados de maneira consistente em todos os sistemas de saída, oferecendo alternativas de omnichannel em vez de pressuposições de canal único | | Objeto personalizado \| Dados demográficos | ✅ Dados demográficos voluntários são coletados por meio de uma pesquisa separada com uma opção "Preferir não responder", armazenados em um objeto personalizado com OWD privado, restritos pelo FLS e usados apenas para análise de equidade agregada | | Shield \| Monitoramento de evento | ✅ O Monitoramento de evento Shield registra eventos de acesso (exportações de relatório, consultas de objeto da API) em dados demográficos para padrões de acesso de auditoria | | Plataforma \| Aprimoramento de terceiros | ✅ Fornecedores de aprimoramento de terceiros são auditados quanto a testes de fairness, cobertura demográfica e precisão, metodologia de inferência e restrições de uso de dados contratuais antes da implementação | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Campos obrigatórios | Email é necessário para a criação de conta sem alternativa, e a validação de telefone ou endereço rejeita formatos fora dos EUA, caixas de PO e rotas rurais, excluindo usuários que não podem fornecer os dados | | Plataforma \| Campos obrigatórios | Os campos são marcados como obrigatórios sem documentar se o processo pode funcionar sem os dados, criando preenchimentos invisíveis de registros incompletos rejeitados | | Plataforma \| Campos de nome | Campos de nome impõem convenções Western First/Last e rejeitam monônimos, diácritos ou scripts não latinos, sujeitando os usuários à rejeição do sistema com base na identidade cultural | | Plataforma \| Validação de endereço | A validação de endereço exige formato postal dos EUA e não reconhece endereços internacionais, caixas de PO, endereços militares (APO/FPO) ou endereços tribais, bloqueando a criação de conta e a entrega de serviços | | Plataforma \| Preferências de comunicação | Presume-se que um só canal de comunicação seja universal (somente email ou somente telefone), excluindo usuários sem acesso à Internet, sem acesso telefônico ou com deficiência auditiva ou surdo | | Objeto personalizado \| Dados demográficos | Dados demográficos são inferidos de nomes ou locais sem o Knowledge do usuário, armazenados em campos de contato padrão visíveis a todos os usuários e usados na pontuação de leads ou previsões sem divulgação | | Plataforma \| Aprimoramento de terceiros | Dados de terceiros são anexados sem auditar práticas de fairness do fornecedor ou cobertura demográfica, importando viés introduzido pelo fornecedor para decisões da organização | ## Fairness na Automação do Salesforce **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Atribuição e roteamento | ✅ As regras de atribuição e roteamento usam critérios de objetivo (linhas de produto, SLAs, requisitos de idioma) e as distribuições de atribuição são auditadas trimestralmente, estratificadas por demografia do cliente, para garantir que nenhum padrão de concentração apareça | | Plataforma \| Omni-Channel | ✅ Tempo médio de atendimento, resolução no primeiro contato e satisfação do cliente são monitorados em todos os caminhos de roteamento para detectar se os segmentos do cliente recebem sistematicamente agentes menos experientes | | Plataforma \| Fluxo | ✅ Fluxos que tomam decisões consequentes são revisados quanto a critérios correlacionados com características protegidas (tendência da conta, preferência de canal, histórico de compras, horário comercial) e sua lógica de decisão é documentada nos registros de decisão da arquitetura | | Plataforma \| Fluxo | ✅ Fluxos com alta participação que afetam o acesso ao emprego, ao crédito ou ao serviço estão sujeitos ao mesmo processo de análise de ética que os sistemas de IA | | Plataforma \| Regras de validação | ✅ As regras de validação são testadas com dados diversos (endereços internacionais, nomes não ocidentais, formatos de telefone alternativos) e expandidas sempre que rejeitam dados legítimos; Campos de nome aceitam Unicode e todos os scripts | | Plataforma \| Design de território | ✅ A demografia do cliente é mapeada entre os limites de território propostos antes de os designs serem finalizados; quando ocorrem concentrações, a alocação de recursos é avaliada quanto à equidade e a justificativa dos negócios é documentada e monitorada | | Plataforma \| Auditoria | ✅ A lógica de automação (regras de negócios, critérios de atribuição, decisões de fluxo) é documentada no Salesforce Knowledge ou ADRs, e os resultados são auditados trimestralmente estratificados por demografia – distribuições de atribuição, taxas de aprovação de fluxo, taxas de rejeição de validação e alocação de recursos de território | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Atribuição e roteamento | ⚡️ Regras de atribuição priorizam leads de determinados códigos postais para "melhor desempenho" com base em taxas de ganho históricas sem examinar se esse sucesso reflete habilidade ou vantagem demográfica | | Plataforma \| Omni-Channel | As métricas de qualidade do roteamento não são monitoradas entre segmentos do cliente, portanto, as discrepâncias na experiência ou resolução do agente não são detectadas | | Plataforma \| Fluxo | ⚡️ Os critérios de decisão de fluxo se correlacionam com características protegidas (continuação, canal, volume de compras, fuso horário) e são tratados como objetivo porque a lógica determinística parece neutra | | Plataforma \| Fluxo | Fluxos de alta participação tomam decisões consequentes sem revisão de ética, documentação de ADR ou tratamento para usuários fora do perfil de cliente típico | | Plataforma \| Regras de validação | A validação de nome é restrita a A-Z e rejeita diácritos ou scripts não latinos, e a validação de endereço requer formato postal dos EUA – dados legítimos são rejeitados e os usuários abandonam solicitações não relatadas | | Plataforma \| Design de território | ⚡️ Os limites de território seguem a geografia correlacionada com a demografia, com diferentes remunerações ou pessoal entre territórios e sem análise da concentração demográfica | | Plataforma \| Auditoria | A lógica de automação é não documentada e os resultados nunca são auditados, assim, padrões discriminatórios em atribuição, aprovações, validação ou alocação de território permanecem invisíveis | # Excelência operacional Excelência operacional ## Visão geral As ótimas soluções do Salesforce não são criadas uma vez, são refinadas continuamente. Integre excelência operacional aos seus sistemas monitorando o desempenho das suas soluções e refinando o funcionamento para que elas proporcionem valor comercial de modo previsível e se recuperem rapidamente quando algo falha. Negligenciar a excelência operacional tem consequências previsíveis para as soluções. Processos de implementação manual se tornam gargalos que tornam a entrega de recursos mais lenta e aumentam o risco de erros. A monitorização inadequada atrasa a detecção de incidentes até que os usuários relatem problemas, prolongando a duração do impacto e erodindo a Trust. A ausência de automação exige que as equipes de operações cresçam proporcionalmente à complexidade da solução, criando trajetórias de custo insustentáveis. Um trabalho em lote mal monitorado que falhe pode corromper dados ou processos a jusante antes que alguém o observe. As soluções projetadas para excelência operacional permitem que as equipes observem o comportamento do sistema por meio de monitoramento abrangente, implementem alterações com segurança usando pipelines automatizados, respondam a incidentes de modo eficaz com procedimentos predefinidos e aprendam com a experiência operacional por meio de revisões impecáveis. Esses recursos se compõem ao longo do tempo. Equipes que investem cedo em bases operacionais fornecem recursos de modo mais rápido e confiável do que equipes que adiam preocupações operacionais até que problemas de produção obrigem o investimento reativo. A excelência operacional se conecta a outros pilares arquitetônicos diretamente. A [fidelidade](/docs/architect/pt-br/well-architected/guide/reliability.html) depende do monitoramento que detecta falhas e da automação que permite uma recuperação rápida. O [Trust](/docs/architect/pt-br/well-architected/guide/trust.html) exige práticas seguras de ciclo de vida do desenvolvimento e trilhas de auditoria para mudanças operacionais. A otimização de recursos se beneficia de melhoria contínua informada pela telemetria operacional. A otimização de custo exige eficiência de implantação e automação que impeça o crescimento da despesa operacional. Juntos, esses pilares criam soluções que proporcionam valor de negócio contínuo com investimento operacional sustentável. O Salesforce opera a infraestrutura: os servidores, o banco de dados, o tempo de execução e a rede. O que você opera é tudo o que é criado sobre ele: os metadados que definem sua solução, a configuração que controla seu comportamento, os dados que fluem por ela, as integrações que a conectam e os agentes que atuam dentro dela. Essa divisão de responsabilidade forma cada decisão operacional que você toma. Embora o Salesforce garanta que a plataforma esteja disponível, de bom desempenho e segura, você deve projetar soluções observáveis, implantáveis, automatizáveis e recuperáveis. A arquitetura de vários locatários da plataforma significa que problemas operacionais em sua solução podem acionar limites de controlador que falham em transações individuais e bloqueios de linha ou contenção de recurso que se propagam em cascata em sua organização. Não é possível aumentar a capacidade de observação, a segurança da implementação ou a prontidão para incidentes após o fato sem esforço adicional ou retrabalho. Neste guia, você aprenderá a projetar e implementar as práticas operacionais (monitoramento, automação de implantação, resposta a incidentes e melhoria contínua) que transformam as soluções do Salesforce em sistemas confiáveis e sustentáveis. ## Princípios de design Use esses princípios para orientar suas decisões de arquitetura para excelência operacional na plataforma. - **Evoluir com observabilidade.** Projete a observabilidade abrangente da versão inicial em vez de ajustar a instrumentação de modo reativo após o surgimento de problemas. Os sistemas observáveis revelam como eles se comportam de fato em condições reais, permitindo melhorias arquitetônicas orientadas por dados e diagnóstico rápido de problemas. A capacidade de observação é uma preocupação arquitetônica que forma o design de soluções desde o início: as decisões de instrumentação, monitoramento e coleta de telemetria afetam modelos de dados, padrões de integração e limites de componentes. - **Padronizar os procedimentos operacionais.** Configuração de versão e procedimentos operacionais no controle de código-fonte junto com o código do aplicativo. As operações codificadas permitem implantações automatizadas do Salesforce DX, automação de atualização de sandbox e implantações de metadados que são executadas de forma consistente entre ambientes. O Knowledge tribal sobre a configuração da organização transforma-se em scripts executáveis que qualquer membro da equipe pode executar. Quando os procedimentos estão ativos no controle de versão, eles evoluem pelos mesmos ciclos de revisão e melhoria que os recursos do aplicativo, criando padrões operacionais reproduzíveis que reduzem significativamente o desvio de configuração. Implemente um Centro de excelência. - **Abrace uma cultura DevOps.** Divida silos organizacionais entre equipes de desenvolvimento, operações e negócios. A responsabilidade compartilhada pelos resultados da solução substitui jogar o trabalho sobre os muros. A cultura DevOps reduz o atrito, acelera os loops de feedback e cria a responsabilidade pelo impacto operacional. Os arquitetos habilitam o DevOps por meio de opções de tecnologia que dão suporte à colaboração e por meio de advocacia organizacional que remove barreiras estruturais à responsabilidade compartilhada. - **Automate para eficiência.** Automatize tarefas operacionais repetitivas para eliminar o trabalho manual, reduzir erros humanos e permitir que as operações sejam dimensionadas enquanto otimiza o custo e o uso de recursos. Operações manuais frequentes são bons candidatos para automação. Meça o valor da automação por meio de horas salvas, redução de erros e capacidade operacional criada. - **Aprenda com todos os eventos operacionais.** Extraia o aprendizado organizacional de incidentes, anomalias de desempenho, quase falhas e operações bem-sucedidas. Os trabalhos de pós-morte inocentes focam melhorias do sistema, em vez de falhas individuais, criando segurança psicológica para avaliação honesta. A telemetria operacional revela padrões entre incidentes que permitem a prevenção proativa. A cultura de aprendizado transforma a experiência operacional em capacidade organizacional que se compõe ao longo do tempo. ## Operações de plataforma: O que o Salesforce gerencia Entender o que o Salesforce opera ajuda você a concentrar os esforços de design operacional no que você controla. A plataforma lida com preocupações de infraestrutura que exigiriam equipes dedicadas em ambientes de TI tradicionais: - **Confiabilidade e desempenho da infraestrutura:** O Salesforce monitora e mantém a capacidade do servidor, o desempenho do banco de dados, a disponibilidade de rede e os sistemas de armazenamento em todas as instâncias. O status da plataforma aparece em [status.salesforce.com](http://status.salesforce.com) com atualizações de incidentes em tempo real e janelas de manutenção planejadas. - **Atualizações e correções da plataforma:** Três versões principais por ano (Spring, Summer, Winter) fornecem novos recursos, correções de segurança e melhorias de desempenho. O Salesforce gerencia o momento da versão, o suporte e a descontinuação da versão da API e o gerenciamento de alterações para alterações no nível da plataforma. Você testa sua solução com relação a versões em ambientes de sandbox antes da implantação de produção. - **Gerenciamento de recursos de vários locatários:** Existem limites de controlador para manter a infraestrutura compartilhada justa. Como você está executando nos mesmos recursos que outros clientes, o Salesforce impõe limites em coisas como tempo de CPU, tamanho de heap, consultas Salesforce Object Query Language (SOQL), instruções de Data Manipulation Language (DML) e chamadas à API para que nenhum único locatário consuma capacidade excessiva. Embora o Salesforce rastreie o uso geral e permita que os clientes solicitem alocações mais altas para alguns limites (como chamadas à API) por meio de níveis de licenciamento, os limites do controlador do Apex por transação são fixados e aplicados da mesma maneira para todos. - **Operações de segurança da plataforma principal:** As equipes de segurança do Salesforce monitoram ameaças, gerenciam a divulgação e o reparo de vulnerabilidades, mantêm as certificações de segurança e respondem a incidentes de segurança no nível da plataforma. Essa segurança fundamental cria a linha de base com base na qual você cria controles de segurança específicos da solução. - **Recuperação de desastres e continuidade dos negócios:** O Salesforce mantém data centers distribuídos geograficamente, testa procedimentos de recuperação de desastres e mantém sistemas redundantes que permitem a alteração de falha sem ação do cliente. A recuperação no nível da plataforma acontece de forma transparente durante falhas de infraestrutura. Essas operações de plataforma criam a base em que você cria. Você não provisionar servidores, corrigir bancos de dados ou projetar a recuperação de desastres para infraestrutura. No entanto, você continua responsável por tudo o que cria e configura com base nessa base. ## Operações de solução: O que você projeta e gerencia O Modelo de responsabilidade compartilhada significa que você possui excelência operacional para tudo o que você cria no Salesforce. As operações de plataforma habilitam seu trabalho, mas não o substituem. Suas responsabilidades operacionais abrangem cinco áreas interconectadas: ### Observabilidade e monitoramento A capacidade de observação é a capacidade de entender o estado interno do sistema de saídas externas. As soluções do Salesforce observáveis permitem que os operadores respondam perguntas sobre o comportamento do sistema, diagnostiquem falhas e validem hipóteses sem implantar uma nova instrumentação para cada investigação. A distinção entre monitoramento (responder a perguntas conhecidas com painéis predefinidos) e capacidade de observação (responder a perguntas arbitrárias com telemetria abrangente) é importante porque os sistemas de produção geram comportamentos inesperados que excedem o esperado durante o design. #### Estrutura de capacidade de observação abrangente Para soluções do Salesforce, a capacidade de observação abrange três tipos de sinal complementares adaptados ao modelo de vários locatários da plataforma: - **Logs -** Capture eventos discretos com informações contextuais completas. O Monitoramento de evento fornece Arquivos de log de eventos que capturam chamadas à API, eventos de login, execução do Apex, consultas SOQL, páginas do Visualforce, páginas do Lightning e execuções de relatórios com contexto de solicitação, incluindo identidade do usuário, carimbo de data e hora, duração e resultado. Os registros respondem a perguntas como "Quais usuários tiveram esse erro?" e "O que mudou entre execuções bem-sucedidas e com falha?" - **Medidas -** Medidas numéricas agregadas ao longo do tempo revelando tendências e padrões. As métricas incluem taxas de consumo de API, distribuições de tempo de CPU do Apex, taxas de sucesso de trabalho em lote, percentis de latência de integração e taxas de conclusão de fluxo de usuário. As métricas respondem a perguntas como "O desempenho está diminuindo ao longo do tempo?" e "Estamos se aproximando dos limites do controlador?" - **Rastreamentos -** Mostrar caminhos de solicitação por sistemas distribuídos revelando fontes de latência e pontos de falha. Para soluções do Salesforce, os rastreamentos podem conectar chamadas de API síncronas a cadeias de processamento assíncronas, eventos de plataforma a execuções de assinante e solicitações de integração a respostas do sistema externo. Rastreia perguntas como "Onde a latência se acumula nesse fluxo?" e "Qual componente falhou nesse processo de várias etapas?" Projeto para capacidade de observação da arquitetura inicial. Decisões sobre quais tipos de evento de Monitoramento de evento habilitar, como estruturar as cargas úteis de Evento de plataforma para visibilidade operacional, onde colocar pontos de verificação de integração e qual registro personalizado implementar moldam a operabilidade de longo prazo da solução. A retroajuste da capacidade de observação em soluções existentes exige alterações de instrumentação que afetam a maioria dos componentes e correm o risco de introduzir bugs durante o trabalho de melhoria operacional. | Fase | Aspecto | Compromissos | | :---- | :---- | :---- | | **Lean Otimizado** — Alta velocidade de entrega com zero sobrecarga de configuração | Logs de monitoramento de evento de plataforma padrão e logs de erro nativos | Ajusta-se a implementações padrão. Conforme a complexidade aumenta, como operações assíncronas ou transações entre vários objetos, mais esforço é feito para unir informações desconectadas. | | **Otimizada em escala** – reconhecimento de padrão, isolamento de limite e execução rastreável | Estruturas de registro personalizadas, ingestão padronizada de registro de evento em visualizações centralizadas e configuração de mecanismo de correlação exclusivo em eventos de plataforma, cargas úteis de integração e cadeias assíncronas | Detecta tendências de desempenho do sistema e o controlador limitam riscos de modo proativo e detecta o nó de falha na execução de várias etapas. Conforme a pegada se expande, é necessária uma disciplina de desenvolvedor consistente para integrar esses ganchos a cada novo ativo, afastando a largura de banda da entrega de recursos. | | **Governação Otimizada** – observabilidade provável e responsável além das fronteiras | A telemetria é retida para uma obrigação definida, controlada pelo acesso e provável de adulteração, com residência de dados de registro e correlação entre organizações preservadas entre limites de conformidade e equipe | Produz o histórico de nível de auditoria e responde quem fez o que, quando e quem o viu. Requer orquestração contínua em equipes de engenharia distintas para preservar chaves e retenção, introduzindo uma sobrecarga de governança significativa. | #### Funcionalidades de monitoramento de plataforma O Salesforce fornece funcionalidades de monitoramento projetadas para fins específicos que os arquitetos devem projetar desde o início. O **Monitoramento de evento** captura dados operacionais detalhados em toda a sua organização. Os tipos de evento incluem uso de API, atividade de login, eventos de logout, execução do Apex, consultas SOQL, carregamentos de página do Visualforce, visualizações de página do Lightning, execuções de relatórios, anexos de documento, transferências de conteúdo e eventos personalizados definidos. O Monitoramento de evento fornece a base para análise de segurança, otimização de desempenho, planejamento de capacidade e relatório de conformidade. Habilite o Monitoramento de evento para ambientes de produção e estabeleça a exportação automatizada de Arquivos de log de evento para plataformas de agregação externas. A retenção nativa é limitada para a maioria dos tipos de evento, insuficiente para análise de tendência, planejamento de capacidade e requisitos de conformidade. A agregação externa habilita a análise histórica, a correlação com a telemetria corporativa de outros sistemas, a análise avançada e os períodos de retenção que correspondem aos requisitos regulatórios. O **Proactive Monitoring** avalia continuamente sua organização quanto a riscos de desempenho e escalabilidade, alertando sobre sinais predefinidos antes que eles se tornem incidentes visíveis ao usuário. O Proactive Monitoring detecta padrões, incluindo picos de limite de solicitação de API que se aproximam da alocação diária, falhas de execução do Apex simultâneas que indicam contenção de recursos compartilhados, limites de linhas SOQL que se aproximam de limites de regulador e contenção de bloqueio de linha que sugere melhorias de design. O Proactive Monitoring usa um conjunto de limites de alerta e aviso predefinidos gerenciados pelo Salesforce. Para organizações que precisam de mais visibilidade de desempenho e querem investigar linhas de base e tendências, o Centro de escala fornece análise de tempo de execução detalhada que abrange tempos limite de CPU, simultaneidade e bloqueios de linha, erros de limite do regulador e desempenho do banco de dados. A **Detecção de dados** (requer Salesforce Shield) verifica campos de objeto padrão e personalizados para identificar, categorizar e remediar dados confidenciais (por exemplo, informações de identificação pessoal (PII)) em campos de texto, rich text e criptografados. Ele usa processamento de plataforma nativa com correspondência de padrão e regex personalizado para minimizar falsos positivos. Execute verificações recorrentes (semanal ou mensal) direcionadas a registros novos ou modificados, com exclusões para campos já classificados ou descontinuados. Use as descobertas para promover a governança a jusante para atualizar classificações de conformidade, impor a Shield Platform Encryption, acionar políticas de segurança de Monitoramento de evento ou aplicar o mascaramento de dados de sandbox. O **Scale Center** fornece visibilidade em nível de transação de operações de execução longa, padrões de rendimento, hotspots de exceção e consumo de limite do regulador. O Centro de escala revela quais operações consomem mais recursos, quais transações se aproximam dos limites de tempo limite e onde o investimento em otimização geraria o maior impacto operacional. Estabeleça as linhas de base do Centro de escala durante a estabilização da solução e revise as linhas de base após cada versão principal. Desempenho sem contexto é difícil de interpretar. A comparação da linha de base revela se as alterações melhoraram ou reduziram o desempenho, guiando decisões de otimização adicionais. - **Configurar trilha de auditoria:** rastreia alterações de configuração, incluindo modificações de permissão, implantações de metadados, ações administrativas e atualizações de configuração de segurança com retenção de até 180 dias nativamente. A Trilha de auditoria de configuração dá suporte a investigações de segurança, validação de conformidade e postmortems de incidentes revelando quem alterou qual configuração e quando. Exporte as entradas da Trilha de auditoria de configuração para retenção além de 180 dias quando requisitos de conformidade ou contratuais exigirem janelas históricas mais longas. - **Trilha de auditoria em campo:** (requer Salesforce Shield) rastreia alterações de valor de campo históricas. Habilite a Trilha de auditoria de campo de modo seletivo para campos que contêm dados confidenciais, dados regulamentados que exigem histórico de alterações ou dados críticos de negócios em que a compreensão de valores históricos ajuda a operações e relatórios de conformidade. - **Verificação de saúde:** fornece avaliação de configuração de segurança automatizada comparando as configurações atuais com as recomendações de linha de base de segurança do Salesforce. Agende análises trimestrais da Verificação de integridade e remedia as descobertas com base na priorização de risco para seu ambiente. Nem todas as descobertas exigem remediação se você tiver controles compensatórios ou tolerâncias de risco diferentes das recomendações padrão, mas cada descoberta merece uma revisão deliberada. #### Monitoramento de aplicativo e integração O monitoramento de plataforma revela a integridade no nível da organização, mas omite problemas específicos do aplicativo. Monitore a integridade do aplicativo da perspectiva do usuário instrumentando jornadas de negócios essenciais: Defina processos críticos do usuário com base no impacto dos negócios e monitore taxas de sucesso de ponta a ponta, tempo de conclusão, pontos de abandono e taxas de erro. Os fluxos críticos geralmente incluem atividades geradoras de receita (envio de pedido, execução de contrato, fechamento de oportunidade), atividades de alto volume (login do usuário, operações de pesquisa, criação de registro) e atividades obrigatórias de conformidade (captura de consentimento, cumprimento de direitos de sujeito de dados, fluxos de trabalho sensíveis à auditoria). Processos de instrumento com marcadores de marco indicando início, conclusão, abandono e falha em cada etapa significativa. Alerte quando as taxas de sucesso do fluxo ficam abaixo dos limites aceitáveis ou a duração excede as metas de latência. O monitoramento em nível de processo revela problemas invisíveis no monitoramento em nível de componente porque uma jornada do usuário que afeta várias classes do Apex, vários fluxos, três eventos de plataforma e duas integrações externas pode falhar em qualquer ponto de transição. Monitore a integridade da integração bidirecionalmente. Acompanhe chamadas de saída para sistemas externos para taxas de sucesso, latência, padrões de nova tentativa e tipos de erro. Acompanhe chamadas de entrada de sistemas externos para padrões de volume, falhas de autenticação, erros de validação de dados e duração do processamento. O monitoramento de integração costuma revelar problemas do sistema externo antes que os operadores os detectem, habilitando a escalação proativa. Estabeleça SLAs de integração com parceiros externos e monitore o desempenho real em relação às metas confirmadas. Quando ocorrem violações do acordo de nível de serviço (SLA), a telemetria distingue se os problemas se originam no Salesforce, na camada de integração, no caminho de rede ou no sistema externo. Essa distinção é importante durante a escalação de incidentes e negociações de contrato. #### Indicadores e objetivos de nível de serviço Indicadores de nível de serviço (SLIs) são métricas cuidadosamente selecionadas que representam a qualidade percebida pelo usuário. Objetivos de nível de serviço (SLOs) são valores de destino para SLIs que balanceiam as expectativas do usuário com o investimento operacional. Para soluções do Salesforce, os SLIs eficazes incluem: - **Disponibilidade:** Percentual de tempo pelo qual a solução responde com sucesso às solicitações do usuário. Meça a disponibilidade da perspectiva do usuário, não da perspectiva da infraestrutura. Uma solução em que a plataforma está disponível, mas os usuários não podem fazer login devido a uma configuração incorreta de Single Sign On (SSO) não está disponível independentemente do tempo de atividade da plataforma. - **Latency:** Tempo do início da ação do usuário até a resposta visível. Defina metas de latência em percentis específicos (p50, p90, p99) em vez de médias, pois as médias obscurecem as experiências terríveis sofridas pelas solicitações mais lentas. Uma latência p99 de 8 segundos significa que 1 em cada 100 solicitações leva mais de 8 segundos, o que pode representar milhares de experiências ruins diariamente em soluções de alto tráfego. - **Taxa de sucesso:** Percentual de operações concluídas sem erros visíveis ao usuário. Diferencie entre erros causados pelo usuário (entrada inválida, permissões insuficientes) e erros causados pelo sistema (falhas de limite do regulador, tempos limite de integração, exceções não tratadas). Somente erros causados pelo sistema são considerados nos SLOs de taxa de sucesso. - **Transferência:** Volume de operações concluídas por unidade de tempo. A taxa de transferência é importante para processamento em lote, importações de dados, trabalhos agendados e operações em massa em que cumprir prazos de negócios depende da capacidade de processamento. Defina SLOs com base nos requisitos do usuário, não nos recursos técnicos. A pergunta não é "quão rápido podemos fazer isso?" mas, em vez disso, "quão rápido isso deve ser para os usuários atingirem suas metas?" Um destino de carregamento de página de 200ms será sem significado se os usuários puderem tolerar dois segundos. Por outro lado, uma meta de dois segundos será sem significado se os usuários abandonarem após 500ms. Pesquisa do usuário, análise da sessão e requisitos de negócios informam metas de SLO realistas. Monitore a taxa de queima de SLI para detectar quando as violações de SLO acumuladas esgotam os orçamentos de erro. Orçamentos de erro representam taxas de falha aceitáveis que balanceiam a experiência do usuário com o investimento operacional. Quando a taxa de queima exceder os níveis sustentáveis, pare o trabalho do recurso e concentre-se em melhorias de confiabilidade até que os SLOs sejam recuperados. Essa disciplina impede o padrão comum em que as equipes ignoram a confiabilidade degradante enquanto perseguem prazos de recurso até que falhas catastróficas obrigem a resposta de emergência. #### Arquitetura de alerta Os alertas notificam os humanos quando sistemas automatizados detectam problemas que exigem julgamento ou ação humana. O alerta eficaz equilibra a cobertura (detectando problemas reais) com a precisão (evitando falsos alertas). O aviso ruim perde incidentes (faixa de alertas, limites muito altos) ou cria fadiga de alerta (muitos alertas, limites muito baixos), em que os operadores aprendem a ignorar notificações. Elabore alertas sobre a capacidade de ação. Cada alerta deve responder a três perguntas: 1. Qual é o problema? 2. Por que isso importa? 3. O que devo fazer? Alertas sem respostas claras treinam os operadores a ignorá-los. Por exemplo, um alerta informando que "chamadas à API excederam 80% do limite" sem contexto sobre qual API, qual integração ou qual ação realizar fornece informações insuficientes para resposta. Implemente os níveis de gravidade do alerta que correspondam aos procedimentos de escalação operacionais: - **Alertas críticos:** indicar a degradação do serviço voltado para o usuário que requer resposta imediata independentemente da hora do dia. Engenheiros na chamada da página de alertas críticos. Exemplos incluem falhas de login que excedem o limite definido, fluxos geradores de receita abaixo do SLO de disponibilidade ou detecção de perda de dados. - **Alerta de alerta:** indicar problemas que se tornarão críticos sem intervenção, mas que ainda não afetam os usuários. Os avisos geram pedidos para investigação no horário comercial. Exemplos incluem tendência de consumo de API em relação aos limites diários, trabalhos em lote concluídos, mas sem metas de SLA, ou erros de integração aumentando, mas ainda abaixo do limite de falha. - **Alertas de informação:** fornecer conhecimento sobre alterações operacionais sem exigir ação. Os alertas de informações aparecem nos painéis de monitoramento, mas não geram notificações. Exemplos incluem implantações bem-sucedidas, conclusão de manutenção agendada ou alterações de configuração. Estabeleça o ritmo de revisão de alerta para avaliar a qualidade do alerta e ajustar limites com base nos padrões reais de incidentes. Acompanhe as métricas de alerta, incluindo taxa de positivos verdadeiros (alertas indicando problemas reais), taxa de positivos falsos (alertas em que não havia problema) e tempo para resolução (quão rápido os alertas levaram à resolução do incidente). As altas taxas falsas positivas indicam limiares excessivamente sensíveis que precisam ser ajustados para restaurar a Trust do operador. ### Práticas de DevOps A cultura DevOps combina responsabilidades de desenvolvimento e operações em equipes unificadas que são proprietárias dos resultados da solução da confirmação inicial de código até a operação de produção. O DevOps permite uma entrega mais rápida, maior qualidade e melhores resultados operacionais em comparação a organizações isoladas tradicionais em que os desenvolvedores entregam trabalho a equipes de operações que não têm o contexto para executá-lo de modo eficaz. | Fase | Aspecto | Compromissos | | :---- | :---- | :---- | | **Lean Otimizado** — Envie rápido com sobrecarga mínima do pipeline | Metadados controlados por origem implementados manualmente por meio da interface de linha de comando (CLI) ou de um ambiente de desenvolvimento integrado gerenciado (IDE)/ferramenta. Validação e reversão são manuais, reversão sendo desfazer as alterações manualmente e reimplantar a versão anterior. | Sobrecarga do pipeline mais baixa e caminho mais rápido para produção para uma pequena área. Conforme a contagem de equipe e componente aumenta, a implantação manual se torna o gargalos e a qualidade depende inteiramente da disciplina individual, em vez de de um gate imposto. | | **Otimizada em escala** — Mudança repetível com chave no ritmo seguro | Integração/implementação contínua automatizada. Cada compromisso é criado e testado em um ambiente novo, uma ramificação principal protegida bloqueia mesclagens até as verificações serem aprovadas e as alterações são promovidas por meio de níveis de sandbox com validação antes da produção. | Alteração repetível e encaixada em um ritmo seguro mais rápido, com regressões capturadas antes da mesclagem. Exige que a engenharia crie e opere o pipeline, mantenha os pacotes de teste dos quais depende e mantenha os níveis de sandbox atualizados. | | **Governação Otimizada** – versão provável e controlada em toda a empresa | Liberação controlada. Portões de aprovação e exposição progressiva no pipeline, alteração regulada de maneira consistente em várias organizações e sistemas, com cada implantação auditável e reversível em relação a um padrão definido. | Alteração provável, responsável e reversível em escala corporativa. Contra a aprovação e o peso de auditoria que desacelera cada alteração e a orquestração para manter a governança de versão consistente entre organizações. | #### Desenvolvimento conduzido por origem O desenvolvimento conduzido por origem trata todos os artefatos de solução (metadados, configuração, código, documentação) como arquivos de origem controlados por versão, em vez de uma configuração de apontar e clicar que reside apenas em organizações. O controle de origem habilita compilações reproduíveis, desenvolvimento colaborativo, rastreamento de alteração e pipelines de implementação automatizados. O Salesforce DX fornece a cadeia de ferramentas para desenvolvimento orientado por origem. A API de metadados expõe a configuração da organização como arquivos XML. Organizações teste fornecem ambientes de desenvolvimento descartáveis criados com base no controle de origem. As ferramentas da CLI habilitam a implantação com script e a manipulação da organização. Os sistemas de controle de versão, incluindo o Git, rastreiam alterações e habilitam fluxos de trabalho colaborativos. Estruture metadados deliberadamente para habilitar a colaboração da equipe. As estruturas de pacote modulares permitem que as equipes trabalhem de modo independente sem conflitos de mesclagem. Separe componentes compartilhados (layouts de página, conjuntos de permissões e campos personalizados) de componentes específicos do recurso (classes do Apex, fluxos e componentes do Lightning). Limites de propriedade claros impedem o caos de todos mudando tudo. #### Revisão de código A revisão de código fornece controle de qualidade, compartilhamento de Knowledge e oportunidades de aprendizagem antes que as alterações cheguem à produção. As análises de código efetivas equilibram a rigor com a velocidade, fornecendo feedback relevante sem se tornarem gargalos de implantação. Estabeleça critérios de análise claros. Os revisores verificam: - Correcção – o código faz o que afirma? - Capacidade de manutenção – os desenvolvedores futuros podem entender e modificar isso? - Desempenho – essa abordagem escala adequadamente? - Segurança – Há riscos de injeção ou desvios de permissão? - Consistência – Isso corresponde aos padrões e padrões do projeto? Sem critérios explícitos, as análises se tornam subjetivas ou superficiais. Exigir duas aprovações para alterações vinculadas à produção. A aprovação de um único revisor cria silos do Knowledge e elimina questões que perspectivas alternativas capturariam. O requisito de dois revisores distribui o Knowledge, mantém o fator de barramento acima de um e captura mais defeitos. Equilibrar os requisitos de aprovação com o tamanho da equipe: exigir três aprovações em uma equipe de cinco pessoas cria gargalos. Mantenha solicitações de pull (PRs) pequenas. Os PRs com centenas de linhas alteradas recebem revisão cursória porque os revisores enfrentam uma sobrecarga cognitiva. Os PRs que alteram um recurso em 200-400 linhas recebem uma revisão aprofundada que captura problemas sutis. Divida recursos grandes em partes revisáveis que são entregues incrementalmente. Automatize verificações mecânicas. Formatação de código, conformidade da convenção de nomenclatura, requisitos de cobertura de teste e verificações de análise estáticas devem ser executadas automaticamente em vez de consumir a atenção do revisor. Os revisores devem se concentrar em questões de lógica, design e capacidade de manutenção que exigem estimativa humana. #### Estratégia de teste Os testes dão confiança de que as soluções funcionam corretamente e continuam funcionando conforme as alterações se acumulam. O teste efetivo equilibra a cobertura (quanto teste de código e funcionalidade é realizado) com a velocidade de execução (quão rápido os pacotes de teste são concluídos) e a carga de manutenção (quanto esforço é necessário para manter os testes). - **Testes de unidade:** validar componentes individuais em isolamento. Os testes de unidade do Apex validam métodos e classes isoladamente dos dados da organização existentes e dependências externas. Os testes do Componente da Web Lightning validam a lógica do componente e a renderização sem APIs de back-end. Testes de unidade bem projetados são executados em segundos, fornecendo feedback instantâneo durante o desenvolvimento. Foque uma cobertura de código de requisito mínima acima de 75% apenas de testes de unidade, tratando a cobertura como piso, não teto. - **Testes de integração:** validar interações entre componentes. Os testes de integração realizam operações reais de banco de dados, chamadas reais para sistemas externos simulados e comportamento de limite de controlador autêntico. Os testes de integração capturam pressuposições que os testes de unidade ignoram: estados de dados inesperados, problemas de permissão, limites de operação em massa e dependências de pedido acionador. Os testes de integração são executados em segundos a minutos por teste. - **Testes completos (E2E):** validar jornadas do usuário concluídas do login até a conclusão da tarefa. Os testes E2E são executados em ambientes de Sandbox completo, exercendo interações da IU, processos de back-end, operações assíncronas e pontos de contato de integração. O E2E testa problemas que só aparecem quando o sistema completo é executado: condições de corrida, fluxos de trabalho do usuário inesperados, problemas de configuração do ambiente. Os testes E2E são executados em minutos a horas para pacotes abrangentes. - **Testes de desempenho:** validar o comportamento da solução sob carregamento. Os testes de desempenho medem tempos de resposta, taxa de transferência, consumo de recurso e proximidade do limite do controlador sob padrões de tráfego realistas. Os testes de desempenho impedem a liberação de alterações que prejudicam o desempenho, capturam padrões de consulta N+1 antes da produção e validam o tempo limite de capacidade antes das estações de pico. Os testes de desempenho exigem volumes de dados semelhantes a produção e são executados em ambientes de teste dedicados. Implementar estratégia de pirâmide de teste: muitos testes de unidade rápidos, menos testes de integração, testes seletivos E2E junto com testes de desempenho validados separadamente sob carga. Esse saldo permite uma iteração rápida (testes de unidade rápidos fornecem feedback imediato) ao mesmo tempo que garante que os pontos de integração funcionem corretamente (testes de integração capturam problemas entre componentes) e a experiência do usuário permaneça aceitável (testes E2E validam jornadas completas). Automatize a execução de testes em pipelines de CI. Não execute manualmente pacotes de teste antes de confirmações, em vez disso, deixe o CI executar pacotes de teste automaticamente antes de cada confirmação. O teste automatizado captura regressões imediatamente, impõe padrões de qualidade de maneira consistente e impede a degradação gradual da qualidade que ocorre quando o teste manual se torna opcional durante a pressão do prazo. #### Pipelines CI/CD Os pipelines de integração contínua (CI) e implantação contínua (CD) automatizam o caminho da confirmação de código à implantação de produção. O CI/CD reduz erros humanos, acelera o feedback, oferece verificações de qualidade consistentes e habilita o ritmo de liberação rápido. - A **integração contínua** cria, testa e valida automaticamente cada compromisso de código. Quando os desenvolvedores enviam confirmações por push para o controle de versão, os sistemas CI ativam novas organizações, implementam as alterações, executam pacotes de teste automatizados, realizam análise de código estático, verificam os requisitos de cobertura de teste e relatam resultados em minutos. O feedback rápido permite que os desenvolvedores corrijam problemas enquanto o contexto está atualizado, em vez de descobrir problemas dias depois durante os testes manuais de integração. Exigir o sucesso do CI antes de permitir mesclagens para a ramificação principal. Essa disciplina (geralmente chamada de "proteger principal") impede que código corrompido se acumule em ramificações compartilhadas em que bloqueie outros desenvolvedores. As ramificações protegidas com portões de CI mantêm a ramificação principal implementável a qualquer momento, habilitando a liberação sob demanda em vez de liberação quando principal acontece para o trabalho. - A **implementação contínua** implanta automaticamente alterações validadas por meio de ambientes para a produção. Depois que o CI valida alterações em ambientes isolados, os pipelines de CD são implementados em sandboxes de integração, executam testes adicionais, implantam no preparo, executam a validação final e, opcionalmente, implantam na produção automaticamente ou após os portões de aprovação manual. Implemente estratégias de implantação progressiva que limitam o raio de explosão durante implantações de produção: - **Implantação azul-verde:** mantém dois ambientes de produção idênticos. O tráfego é roteado para o ambiente azul enquanto o ambiente verde recebe uma nova implantação. Após a validação, o tráfego alterna para o ambiente verde. O ambiente azul permanece em execução como um destino de reversão instantânea. - **Implantação do Canary:** libera alterações a pequenos subconjuntos de usuários antes da implantação completa. A canária inicial recebe um pequeno percentual do tráfego enquanto monitora as taxas de erro, a latência e o comportamento do usuário. Canários bem-sucedidos se expandem progressivamente (por exemplo, de 5% a 25%, depois de 50% e depois de 100%). Problemas detectados durante a implementação do Canary cancelam a liberação antes de afetarem todos os usuários. A implantação Canary funciona bem para soluções do Salesforce com camadas de roteamento externas ou sinalizadores de recurso que permitem a exposição seletiva de recursos. - **Bandeiras de recurso:** habilite o controle de tempo de execução da visibilidade de recursos independentemente do momento da implementação. Novos recursos são implementados em produção, mas permanecem ocultos atrás de sinalizadores até serem explicitamente habilitados. Os sinalizadores de recurso oferecem suporte à implantação canária, testes A/B, distribuição gradual e reversão instantânea alternando sinalizadores em vez de implantar código. *Nota*: Os padrões de implementação canário e azul-verde se aplicam a aplicativos personalizados hospedados no Heroku ou aplicativos MuleSoft implantados no CloudHub 2.0 por meio de controles de alocação de recursos e distribuição de tráfego. As principais implantações de metadados da Salesforce Platform são transações de tudo ou nada. #### Infraestrutura como código A infraestrutura como código (IaC) trata a definição de um ambiente – forma da organização, metadados, dependências e os dados de configuração e seed que a tornam funcional – como uma origem controlada por versão, em vez de uma configuração feita manualmente em cada organização. No Salesforce, não há servidores para provisionar, assim, o IaC controla como um ambiente é montado, não o hardware sob ele. Ambientes codificados são reproduíveis, comparáveis e descartáveis, e é exatamente isso que os impede de se desviar. Os ambientes são definidos a partir da origem, em vez de ajustes manuais. Um arquivo de definição de organização teste especifica edição, recursos habilitados e configurações para que qualquer pessoa, ou um pipeline, possa ativar uma organização idêntica descartável sob demanda. Os sandboxes seguem um caminho diferente: eles são provisionados de uma definição que dá um nome ao tipo de cópia e ao modelo, depois herdam a configuração da organização de produção que clonam, proporcionando ambientes de maior fidelidade para integração e preparação. As definições de pacote declaram os componentes e as dependências de uma solução, tornando as compilações reproduíveis da origem em vez de dependentes do estado acumulado de uma organização de longa vida. A linha de base que todos os ambientes presumem também tem controle de versão. Metadados personalizados, configuração da credencial nomeada e definições de configuração personalizadas são implementados como metadados, enquanto valores de configuração e registros de referência são carregados de dados de seed com controle de versão. Manter ambos no controle de origem junto com o código significa que cada ambiente começa com uma linha de base conhecida e consistente, em vez de uma configurada manualmente. Codificar ambientes dessa maneira ataca o desvio de configuração em sua origem. Quando a definição de um ambiente fica no controle de versão, as diferenças entre os ambientes aparecem como discrepâncias visíveis em vez de discrepâncias silenciosas, e a recriação de um ambiente limpo é mais rápida do que depurar um que foi desviado. O reprovisionamento da origem reduz a recuperação quando um ambiente se torna corrompido e permite que os pipelines apresentem ambientes descartáveis para cada alteração sem configuração manual. #### Estratégia de sandbox Os sandboxes fornecem ambientes isolados para desenvolvimento, teste e treinamento sem arriscar dados ou configuração de produção. Uma estratégia de sandbox eficaz equilibra a fidelidade do ambiente (quão perto os sandboxes correspondem à produção) com o custo e a frequência de atualização. - Os **developer sandboxes** fornecem ambientes isolados leves para desenvolvimento de recursos individuais. Os desenvolvedores criam organizações teste usando o controle de origem para trabalho diário, usando sandboxes do desenvolvedor para testes de integração com dependências compartilhadas. Os Developer Sandboxes e as organizações teste são atualizados com frequência mantendo a configuração sincronizada com a produção. - Os **sandboxes de integração** (developer pro ou copy parcial) fornecem ambientes compartilhados em que vários recursos se integram e interagem. Os sandboxes de integração incluem dados de produção suficientes para testar fluxos de trabalho realistas sem o custo e a complexidade de cópias de dados completas. Os testes de integração são executados em sandboxes de integração antes da promoção para preparação. - Os **sandboxes de preparação** (cópia completa) refletem a configuração e os dados de produção, fornecendo validação final antes da implantação da produção. Os sandboxes de preparação recebem versões antes da produção, habilitando testes semelhantes a produção de procedimentos de implementação, características de desempenho e scripts de migração de dados. Os sandboxes de preparação são atualizados trimestralmente ou antes das versões principais. - Os **sandboxes de treinamento** oferecem ambientes realistas para treinamento e demonstração do usuário sem expor dados reais do cliente. Os sandboxes de treinamento podem conter dados sintetizados ou dados de produção anônimos. Os ambientes de treinamento permanecem estáveis por períodos estendidos para dar suporte a materiais de treinamento e processos de certificação consistentes. Automatize a atualização de sandbox e o carregamento de dados. A atualização manual do sandbox se torna um gargalo que evita testes frequentes com dados semelhantes a produção. Os procedimentos de atualização automatizados combinados com scripts de carregamento de dados habilitam a redefinição de ambiente sob demanda, oferecendo suporte a pipelines de integração contínuos e necessidades de teste manual. Nota: "Sandbox" tem dois significados distintos em uma empresa agente. Os sandboxes acima são ambientes: cópias isoladas de uma organização em que as equipes criam e testam antes que as alterações cheguem à produção. Sandboxar as ações de um agente é diferente. É o limite de tempo de execução que restringe onde e como uma ação autônoma é executada, por meio de permissões com escopo, acesso limitado a objetos e integração e execução controlada, para que o agente não possa ir além do escopo desejado. As duas são complementares: um Developer Sandbox é onde você valida as ações de um agente em relação a dados não de produção, e o sandbox de ação é o que contém essas ações na produção. #### Práticas de implantação segura Mesmo com pipelines automatizados, as implantações têm risco. Práticas de implantação seguras mitigam o risco por meio de validação, monitoramento e execução controlada: - **Validação de implantação:** executa a implementação como execução a seco sem confirmar alterações. A validação captura erros de implementação (dependências ausentes, conflitos de componente, referências inválidas) antes da implementação real. O Salesforce oferece suporte a implantações de validação por meio da IU e da CLI, habilitando a validação em produção durante o horário comercial, mesmo quando a implantação real espera por janelas de manutenção. - **Monitoramento de implantação:** monitora as principais métricas durante e após a implantação. Monitore taxas de erro, métricas de desempenho, taxas de sucesso de fluxo de usuário e consumo de API. Alterações súbitas após a implantação indicam regressão que requer investigação e possível reversão. O monitoramento automatizado compara métricas pré-implementação e pós-implementação, alertando quando o desvio estatístico excede os limites. - **Manuscritos de implementação:** procedimentos de implementação de documentos, incluindo pré-requisitos, etapas de execução, verificações de validação, procedimentos de reversão e plano de comunicação. Os manuais transformam implantações de cerimônias de Knowledge tribais estressantes em procedimentos de rotina que qualquer um pode executar. Os manuais evoluem por meio de retrospectivas de implementação que capturam as lições aprendidas e impedem problemas recorrentes. - **Capacidade de reversão:** fornece um caminho de escape quando as implantações falham. O reversão de metadados do Salesforce exige a reimplantação da versão anterior em vez de comandos de reversão nativos, tornando o controle de versão crítico. Mantenha os pacotes de implementação para cada versão de produção habilitando a reimplantação rápida. Para alterações de dados, mantenha backups pré-implementação que habilitem a restauração. Para alterações de configuração, rastreie valores anteriores na Trilha de auditoria de configuração. Agende implantações durante períodos de baixo tráfego quando o impacto da implantação afetar menos usuários. Implantações de fim de semana e noite minimizam o risco de negócios, mas aumentam a carga operacional. Balance o impacto do usuário em relação à sustentabilidade da equipe. Soluções com práticas de implantação robustas e monitoramento abrangente podem ser implementadas com segurança durante o horário comercial, mas soluções não comprovadas se beneficiam da implantação fora do horário comercial até que a confiança seja criada. #### Gerenciamento de configuração A configuração é metadados que regem o comportamento da solução: configurações da organização, recursos, permissões, integrações e personalização. As alterações de configuração afetam a execução de soluções imediatamente sem implantação de código, tornando o gerenciamento de configuração crucial para a estabilidade operacional. Configuração de versão no controle de código-fonte junto com código. Definições de perfil, atribuições de conjunto de permissões, configurações personalizadas, definições de evento de plataforma, credenciais nomeadas e configurações de site remoto pertencem ao controle de versão. A configuração com controle de versão habilita a automação de implementação, o rastreamento de alteração, a consistência do ambiente e o recurso de reversão. Detectar e remediar o desvio de configuração. Ao longo do tempo, as organizações de produção se desviam da configuração documentada à medida que os administradores fazem alterações diretas, correções rápidas ignoram processos de implementação normais e soluções alternativas não documentadas se acumulam. A comparação automatizada entre a configuração de produção e o controle de versão revela um desvio. Agende a detecção e a remediação de desvio trimestrais para evitar que o débito da configuração se acumule até o ponto em que as implantações se tornam imprevisíveis. Decisões de configuração do documento e sua fundamentação. Os futuros managers precisam entender não apenas o que está configurado, mas também o porquê. Definir padrões organizacionais como Privado para conta, mas Público para contato requer documentação explicando o requisito de negócios que levou a essa decisão. Sem uma fundamentação documentada, alterações futuras correm o risco de violar pressuposições escondidas em processos de negócios. ### Automação e eficiência A automação elimina o trabalho manual repetitivo, reduz o erro humano e permite que as operações sejam dimensionadas sem um crescimento proporcional da população. Para soluções do Salesforce, as oportunidades de automação abrangem recursos de plataforma declarativa, automação programática e procedimentos operacionais. #### Automação de primeira declaração As ferramentas de automação declarativa do Salesforce Flow Builder, Campos de fórmula, Regras de validação, Processos de aprovação permitem que não desenvolvedores implementem lógica de negócios complexa sem código. A automação declarativa oferece vantagens de governança (os administradores podem modificar sem implantações), transparência (dos documentos de design visual em si) e otimização de plataforma (operações declarativas geralmente são executadas com mais eficiência do que código equivalente). - **Flow Builder:** automatiza processos complexos combinando interação do usuário, manipulação de dados, lógica de negócios e integração. Os fluxos tratam de padrões comuns, incluindo criação de registro com pesquisas dependentes, roteamento de aprovação condicional, importações de dados de várias etapas, trabalhos de limpeza agendados e fluxos de trabalho de notificação de erro. Fluxos iniciados automaticamente são executados em alterações de registro, intervalos agendados ou invocação explícita do código. Os fluxos de tela conduzem os usuários por processos de várias etapas com a lógica de ramificação com base na entrada do usuário. Projete fluxos para reutilizabilidade e capacidade de manutenção. Os subfluxos encapsulam padrões comuns (como manipulação de erros ou lógica de bloqueio de registro) que vários fluxos pai reutilizam. Variáveis de fluxo bem nomeadas e descrições explícitas criam lógica de autordocumentação que os futuros manuais entendem. O design de fluxo modular permite testar componentes individuais antes da integração. - **Campos de fórmula:** calcular valores dinamicamente de outros campos sem atualizações de código ou banco de dados. As fórmulas oferecem suporte a cálculos complexos, lógica condicional, aritmética de data e manipulação de texto. Os campos de fórmula funcionam em relatórios, modos de exibição de lista, regras de validação e fluxos, fornecendo cálculos consistentes em diferentes contextos. As fórmulas são executadas de modo eficiente porque não consomem armazenamento de banco de dados e calculam rapidamente durante o acesso ao registro. - **Regras de validação:** impor a qualidade dos dados no momento de salvar. As regras de validação capturam erros de entrada de dados, impõem regras de negócios e impedem transições de estado inválidas. Coloque regras de validação em objetos padrão e personalizados para capturar erros independentemente da fonte de dados: UI, API, Data Loader, integração. Mensagens de erro de regra de validação bem elaboradas orientam os usuários a corrigir problemas, em vez de frustrá-los com mensagens técnicas enigmáticas. - **Processos de aprovação:** encaminhe registros pelas aprovações necessárias antes do avanço do status. Os processos de aprovação implementam hierarquias de autoridade de assinatura, revisões de conformidade, aprovações legais e fluxos de trabalho de consentimento de várias partes. Os processos de aprovação fornecem trilhas de auditoria automaticamente, registrando quem aprovou o que e quando sem desenvolvimento personalizado. #### Padrões de automação programática Embora a automação declarativa trate muitos cenários, requisitos complexos ou restrições de desempenho às vezes exigem automação programática no Apex. Automação eficiente do Apex equilibra poder e flexibilidade com desafios de manutenção e governança. - As **estruturas de acionador** fornecem uma estrutura consistente para lógica de acionador de banco de dados. Estruturas de acionador bem projetadas separam preocupações (quando a lógica é executada, que lógica é executada, como as dependências são ordenadas), habilitam/desabilitam manipuladores individuais sem alterações de código e evitam problemas de recursão por meio do rastreamento de contexto. Estruturas de acionador tornam a automação do Apex mais manejável, impedindo o antipadrão "um grande acionador", em que lógica não relacionada se acumula em monólitos não mantidos. - O **Lotex Apex** processa grandes volumes de dados de forma assíncrona em blocos, respeitando os limites do regulador enquanto executa operações que atingiriam o tempo limite na execução síncrona. Os trabalhos em lote tratam de limpeza de dados, atualizações em massa que ultrapassam limites de objeto, cálculos complexos que exigem várias consultas por registro e operações de migração de dados. Projetar trabalhos em lote para idempotência: executar o mesmo trabalho duas vezes deve produzir o mesmo resultado sem trabalho duplicado ou corrupção. - O **Apex** enfileirável encadeia trabalhos assíncronos por meio de sequências de trabalhos explícitas. Onde os métodos futuros não funcionam, o Apex enfileirável habilita sequências estruturadas em que a conclusão de um trabalho aciona o próximo. Os trabalhos enfileiráveis oferecem suporte à orquestração complexa, incluindo chamadas à API seguidas por processamento de dados, transformações de dados de vários estágios e lógica de repetição de tentativas com fallos exponenciais. - O **Apex agendado** executa trabalhos em intervalos fixos. Os trabalhos agendados lidam com limpeza periódica, sincronização de dados noturna, pesquisas de integração por hora e processamento de fim do dia. Agende trabalhos durante períodos de baixo tráfego e implemente monitoramento para detectar execuções perdidas. Considere se os intervalos agendados realmente atendem às necessidades de negócios ou se o acionamento conduzido por evento responderia mais rapidamente. Projete automação programática para visibilidade operacional. Horas de início/término do registro, contagens de registros processadas, erros encontrados e métricas de desempenho. Quando os trabalhos em lote falham silenciosamente, eles costumam passar despercebidos até que os usuários percebam problemas de dados dias depois. O registro proativo e o alerta transformam falhas silenciosas em incidentes diagnosticáveis. #### Eventos de plataforma para arquitetura conduzida por evento Os Eventos de plataforma habilitam a arquitetura acionada por evento em que os produtores publicam eventos sem conhecer os consumidores e os consumidores assinam eventos sem depender de produtores. A arquitetura acionada por evento desconecta componentes, habilita o processamento assíncrono e dá suporte a padrões de integração em vários idiomas. - **Publicação de evento de plataforma:** notifica os assinantes interessados sobre ocorrências comerciais significativas. O posicionamento do pedido, o processamento do pagamento, a conclusão do cumprimento, a violação do SLA e as condições de erro representam todos os eventos que valem a pena publicar. As cargas úteis de evento incluem contexto suficiente para os assinantes reagirem adequadamente sem consultas adicionais. Publique eventos de acionadores, fluxos, chamadas do Apex ou da API, proporcionando flexibilidade na origem de eventos. - **Assinaturas de evento de plataforma:** reagir a eventos publicados por meio de acionadores, fluxos ou plataformas de integração externas do Apex. Os assinantes processam eventos de maneira assíncrona, o que significa que os editores não aguardam a conclusão do assinante. O processamento conduzido por evento respeita os limites do controlador distribuindo trabalho entre contextos de execução separados em vez de consumir limites em transações síncronas em massa. - **Repetição de evento:** permite que os assinantes processem eventos históricos. Use o ID de reprodução de evento de plataforma para reproduzir eventos de um ponto específico. Os assinantes externos devem gerenciar seu próprio estado de ID de reprodução. Como a entrega é pelo menos uma vez, o processamento de duplicados é possível, lidando com isso na lógica do assinante. Configure a retenção de eventos com base nos requisitos de recuperação do assinante: 72 horas para eventos de plataforma de alto volume e 24 horas para eventos padrão legados são suficientes para recuperação rápida, a retenção mais longa oferece suporte a cenários de recuperação de desastres. Projete eventos para estabilidade. Os esquemas de evento se tornam contratos entre produtores e consumidores. Alterações de esquema exigem coordenação entre várias equipes e sistemas. Adicione novos campos em vez de modificar os campos existentes ao estender eventos. Eventos de versão explicitamente quando alterações de falha se tornam inevitáveis. | Fase | Aspecto | Compromissos | | :---- | :---- | :---- | | **Lean Otimizado** — lógica padrão com automação sem código | Automação declarativa para lógica de negócios. Fluxos, campos de fórmula, regras de validação e processos de aprovação tratam de padrões padrão. Os humanos lidam manualmente com as exceções em execuções. | Mais rápido de criar e alterável sem implantação. Conforme o volume e a complexidade aumentam, a automação apenas declarativa atinge os limites de desempenho e capacidade de manutenção, e a lógica não documentada se acumula mais rapidamente do que pode ser controlada. | | **Otimizada em escala** — Execute trabalhos complexos e de alto volume sem esforço manual | Automação programática e conduzida por evento para o que a declaração não pode suportar. Estruturas de acionador, trabalhos em lote e enfileiráveis seguros em massa e eventos de plataforma desconectam os produtores dos consumidores, cada um criado idempotente e instrumentado. | Lida com trabalho assíncrono de alto volume e de várias etapas que de outra forma consumiria limites ou falha em escala. Exige a engenharia para criá-lo em massa e idempotente e a instrumentação para evitar que falhas silenciosas se ocultem na execução assíncrona. | | **Governação Otimizada** – Controle a automação com confiança em toda a empresa | Automação orquestrada e governada. Contratos de evento estáveis com controle de versão, habilitação controlada do que é executado e padrões de automação consistentes aplicados a uma empresa, todos auditáveis. | Autonomia confiável em escala corporativa com controle provável sobre o que é executado. Contra a coordenação para manter contratos de evento entre equipes e o peso da governança que torna lenta a alteração de qualquer automação compartilhada. | ### Gerenciamento de incidente Incidentes são interrupções ou degradações não planejadas no serviço que exigem resposta para restaurar operações normais. O gerenciamento de incidentes eficaz detecta problemas rapidamente, os encaminha para respondentes qualificados, os resolve de modo eficiente e extrai o aprendizado para evitar recorrência. #### Detecção e resposta de incidentes - **Velocidade de detecção:** determina a duração do impacto do incidente. Quanto mais rápido você detectar problemas, menos danos serão acumulados antes do início da resposta. Os mecanismos de detecção incluem alertas de monitoramento automatizado (de sistemas de observabilidade), relatórios do usuário (pedidos de suporte e escalonamento direto) e monitoramento externo (transações sintéticas e serviços de verificação de tempo de atividade de fora da sua rede). Priorize incidentes por impacto do usuário, em vez de gravidade técnica. Por exemplo, um erro de API que afeta trabalhos em lote interno tem uma urgência diferente de falhas de login que impedem todo o acesso do usuário. A gravidade do incidente orienta o tempo da resposta e os caminhos de escalação: | Nível de gravidade | Descrição | Exemplo | | :---- | :---- | :---- | | Gravidade 1 | Incidentes que impedem funções de negócios críticas, afetam todos ou a maioria dos usuários, causam perda de dados ou apresentam emergências de segurança. Os incidentes de gravidade 1 acionam uma resposta imediata, incluindo notificação executiva, coordenação da sala de guerra e resposta completa até a resolução. | Falha de login completo, detecção de violação de dados ou falha do sistema de receita | | Gravidade 2 | Incidentes que prejudicam funções críticas ou afetam populações de usuários significativas. Os incidentes de gravidade 2 exigem uma resposta rápida, mas não justificam tirar as pessoas do sono ou cancelar todo o outro trabalho. | Pesquise retornando resultados parciais, relatórios atingindo o tempo limite ou falhas de integração com soluções alternativas. | | Gravidade 3 | Incidentes que afetam a funcionalidade limitada ou pequenas populações de usuários. Os incidentes de gravidade 3 recebem atenção no horário comercial. | Usuário único com problemas, problemas estéticos da IU ou pequenas inconsistências de dados. | Estabeleça procedimentos de resposta a incidentes claros, incluindo quem responde, como escalar, qual ritmo de comunicação manter e como coordenar entre equipes. Documente procedimentos em manuais que os engenheiros na chamada podem seguir durante incidentes de alto estresse. Knowledge tribal indocumentado cria atrasos de resposta enquanto as pessoas descobrem quem ligar e quais etapas tomar. #### Chamada e escalação - **Rotação sob chamada:** distribui a carga operacional entre os membros da equipe em vez de queimar alguns heróis que respondem a cada incidente. Os requisitos de cobertura de balanceamento de rotações sob chamada (sempre alguém disponível), equidade (todos compartilham o fardo) e sustentabilidade (pessoas precisam de tempo de recuperação após incidentes intensos). Estruture rotações na chamada com transferências claras e responsabilidades documentadas. A chamada inicial primária lida com a resposta inicial, a chamada secundária fornece escalonamento quando a chamada primária precisa de assistência ou assume o controle se a chamada primária não estiver disponível. Turnos sob chamada devem ter o tamanho certo. Por exemplo, comece com uma semana e não exceda mais de duas semanas. Turnos menores criam uma alternância constante de contexto, enquanto turnos mais longos aumentam o risco de burnout. Agende rotações permitindo planejamento antecipado de obrigações pessoais. - **Caminhos de escalada:** definir quando e como envolver recursos adicionais. Limpar os critérios de escalação evita dois modos de falha: escalonamento prematuro, que desperdiça tempo do engenheiro sênior em problemas que os juniores podem lidar, e escalonamento atrasado, em que os juniores lutam com problemas além de sua experiência enquanto a assistência especializada fica ociosa. Os critérios de escalação geralmente se enquadram em três categorias: acionadores baseados em tempo, como 30 minutos sem progresso; acionadores de complexidade, como um problema que requer conhecimento que não está atualmente em chamada; e acionadores de gravidade, como incidentes de Gravidade 1, que sempre se escalam para liderança. Forneça aos engenheiros sob chamada o acesso, as ferramentas e as informações necessárias. O status na chamada sem acesso de produção cria frustração e estende a duração do incidente enquanto as pessoas aguardam o acesso. Os kits de ferramentas na chamada incluem credenciais de acesso de produção, acesso ao manual de execuções, links do painel de monitoramento, contatos de escalação, procedimentos de suporte ao fornecedor e modelos de comunicação. Compense o dever na chamada de maneira justa. O trabalho sob chamada interrompe o tempo pessoal e cria estresse. As abordagens de compensação incluem remuneração adicional, folga no local ou créditos de rotação reduzindo outras responsabilidades. Sem uma compensação justa, as rotações na chamada criam ressentimento e os engenheiros de qualidade saem para organizações respeitando o equilíbrio entre vida pessoal e profissional. #### Revisões pós-incidente - **Postmortems sem culpa:** extrair o máximo de aprendizado de incidentes sem criar medo que impeça discussão honesta. A cultura impecável reconhece que as pessoas cometem erros em sistemas complexos e se concentra em melhorias do sistema que impedem incidentes futuros, em vez de punir indivíduos por incidentes passados. Realize trabalhos posteriores para todos os incidentes de Gravidade 1 e Gravidade 2 e para qualquer incidente revelando novos padrões ou problemas sistêmicos. O momento pós-mortem é crítico: Realizar a revisão muito cedo corre o risco de informações incompletas, enquanto realizá-la tarde demais corre o risco de memórias esmaecerem. Agende trabalhos posteriores dentro de uma janela razoável (24 a 48 horas) após a resolução do incidente, permitindo tempo para coleta de dados enquanto os detalhes permanecem atualizados. Documentar postmortems na captura de formato consistente: - **Tempo:** Sequência cronológica de eventos da detecção inicial até a resolução. Inclua carimbos de data e hora, ações realizadas, resultados observados e decisões tomadas. A reconstrução da linha do tempo revela a eficácia da resposta e identifica atrasos. - **Causa raiz:** Fraqueza do sistema subjacente que permitiu a ocorrência de incidentes. Ir além da causa próxima (o acionador imediato) para a causa sistêmica (a lacuna de projeto ou processo que fez o acionador consequente). "O engenheiro implantou código ruim" é a causa próxima. "O pipeline de implementação não tem teste automatizado para capturar essa classe de erro" é a causa sistêmica. - **Impacto:** Duração do impacto do usuário, contagem de usuários afetados, impacto de receita, preocupações de integridade de dados e dano à reputação. Impacto quantificado orienta a priorização do trabalho de prevenção: prevenir incidentes com impacto de US$ 100 mil merece mais investimento do que prevenir incidentes de impacto de US$ 1 mil. - **Prevenção:** Itens de ação específicos que impedem a recorrência. Os itens de prevenção efetivos são concretos e incluem ação, designado e conclusão agendada. Por exemplo, adicione o teste de fumaça de integração ao pipeline CI, proprietário: Jane e preencha por: sprint seguinte. Itens de prevenção vazios, como "melhorar o teste", são ignorados porque ninguém sabe que ação realizar. - **Melhoria da detecção:** Como detectar incidentes semelhantes mais rapidamente. Os incidentes descobertos por meio de relatórios de usuários indicam lacunas de monitoramento. Os itens de melhoria podem incluir novos alertas, melhor instrumentação ou monitoramento sintético para caminhos críticos. Compartilhe descobertas pós-mortem amplamente. O aprendizado organizacional requer compartilhamento além da equipe imediata. Postmortems compartilhou Knowledge distribuído em toda a empresa sobre o comportamento do sistema, padrões de falha comuns e procedimentos de resposta eficazes. Os postsortems públicos (publicados externamente) demonstram transparência e ajudam os clientes a entender o compromisso com a qualidade do serviço. | Fase | Aspecto | Compromissos | | :---- | :---- | :---- | | **Lean Otimizado** – Resolva incidentes por meio de uma responsabilidade clara. | Uma pessoa é proprietária da resposta de incidente, trabalhando em manuais de execução para os principais modos de falha. A detecção é orientada pelo usuário e é executada por meio do suporte da plataforma. | Maior carga operacional, sem rotação para a equipe. A recuperação depende da disponibilidade e Knowledge de uma pessoa que cria um único ponto de falha. | | **Escala Otimizada** – Responda de maneira previsível, independentemente de quem está na chamada. | Uma rotação na chamada compartilhada com níveis de gravidade definidos, metas de tempo de resposta por nível, acionadores de escalação documentados e acesso na chamada e ferramentas provisionados antecipadamente. | Resposta previsível desacoplada de qualquer indivíduo, com mecanismos de escalação. Exige que a equipe mantenha a rotação e a disciplina para manter os manuais de execução e o acesso atualizados. | | **Governação Otimizada** – Cumpra metas de recuperação comprometidas e exerça-as. | Recuperação medida em relação a objetos de tempo de recuperação confirmados (RTOs), tratamento de incidentes e comunicação registrados e auditáveis, resposta coordenada em uma empresa e notificação regulatória ou contratual integrada ao procedimento. | Recuperação provável contra compromisso e obrigação atendida sob auditoria. Contra a sobrecarga de coordenação da resposta corporativa e o peso do processo que a governança de incidentes formal adiciona a cada evento. | ### Melhoria contínua A excelência operacional é uma prática contínua que requer investimento contínuo em medição, aprendizado e melhoria. Equipes que tratam operações como uma configuração única se degradam ao longo do tempo à medida que os sistemas se tornam mais complexos e o Knowledge operacional difunde. Equipes que aceitam melhoria contínua ampliam a funcionalidade operacional composta, proporcionando valor crescente com esforço sustentável. #### Métricas operacionais e DORA As métricas DORA, do programa DevOps Research and Assessment (DORA), com base no Relatório de desenvolvimento de software assistido por IA de 2025, fornecem medidas validadas pela pesquisa de entrega de software e desempenho operacional. Equipes com alto desempenho de entrega apresentam resultados significativamente melhores nas seguintes cinco principais métricas: A DORA organiza essas cinco métricas em dois fatores: taxa de transferência e instabilidade. O **throughput** consiste no tempo de processamento de alterações, na frequência de implantação e no tempo de recuperação da implantação com falha. A **Instabilidade** tem as métricas de taxa de falha de alteração restante e de taxa de retrabalho, que mede o desempenho dessas implementações. - **Frequência de implantação:** mede a frequência com que você libera para produção. As equipes com movimento mais rápido são implementadas sob demanda, geralmente várias vezes por dia. A implantação frequente permite um feedback rápido, reduz o risco de implantação por meio de alterações menores e se correlaciona com uma entrega de recursos mais rápida. A baixa frequência de implantação indica uma dor de implantação que as equipes evitam, criando um ciclo vicioso em que uma implantação infrequente torna cada implantação mais arriscada. - **Tempo de processamento para alterações:** mede o tempo do compromisso de código até a implantação de produção. O tempo de processamento de subdia é um forte sinal de entrega de alto desempenho e o tempo de processamento de subhora indica uma capacidade de entrega excepcional. Os tempos de processamento curtos permitem uma resposta rápida às necessidades do usuário, ameaças da concorrência e vulnerabilidades de segurança. Tempos de processamento longos indicam sobrecarga excessiva do processo, automação insuficiente ou disfunção organizacional. - **Alteração da taxa de falha:** mede a porcentagem de implantações que causam incidentes de produção que exigem remediação. As equipes mais confiáveis mantêm essa taxa consistentemente baixa, uma pequena fração de todas as implantações. Uma alta taxa de falha indica testes insuficientes, validação de implementação inadequada ou mudanças precipitadas sem verificações de qualidade adequadas. - **Tempo de recuperação de implementação com falha (FDRT):** mede a rapidez com que você se recupera de uma implantação com falha que requer intervenção imediata. A recuperação em menos de uma hora é um forte sinal de vencimento da entrega. Tempos de recuperação curtos indicam resposta de incidente madura, recursos de reversão eficazes e manuais de execução bem praticados. Tempos de recuperação longos indicam validação de implementação insuficiente, falta de reversão automatizada ou propriedade não clara de incidentes de produção. - **Taxa de retrabalho de implementação:** mede a frequência com que implantações não planejadas ocorrem devido a um incidente de produção. Uma taxa de retrabalho baixa indica versões estáveis e bem testadas que não geram trabalho de remediação posterior. Uma alta taxa de retrabalho indica que os incidentes de produção estão gerando rotineiramente implantações de emergência, sinalizando lacunas em testes pré-produção, validação de versão ou práticas de gerenciamento de mudanças. Meça métricas DORA continuamente e trace tendências ao longo do tempo. As trajetórias de melhoria são mais importantes do que valores absolutos. Uma equipe que está melhorando de implantações mensais para implantações semanais enquanto mantém a qualidade demonstra o progresso. Acompanhe métricas em painéis operacionais visíveis para toda a organização, criando transparência sobre o desempenho operacional e o progresso em relação às metas de melhoria. #### Retrospectivas e revisões - **Retrospectivas de sprint:** extrair o aprendizado do trabalho recente, incluindo incidentes operacionais, desafios de implementação, atrito de processo e dinâmica da equipe. As retrospectivas devem ocorrer regularmente (todos os sprints ou mensalmente) criando um ritmo para reflexão contínua em vez de esperar por crises. Execute retrospectivas usando formatos estruturados que incentivam a participação e resultados acionáveis. Os formatos comuns incluem: - Iniciar/Parar/Continuar – o que devemos começar a fazer, parar de fazer, continuar a fazer? - Mal-satisfeito/Feliz – reflexão emocional sobre experiências recentes - Linha do tempo – reconstruir eventos de sprint e identificar padrões). Converta percepções retrospectivas em itens de ação concretos com proprietários e datas de conclusão. Retrospectivas que geram discussão longa, mas nenhuma ação, desperdiçam tempo e geram cinismo. Retrospectivas efetivas produzem 2-3 melhorias acionáveis por sessão. Acompanhe a conclusão do item de ação em retrospectivas que mantêm as equipes responsáveis pelo acompanhamento. Certifique-se de fazer a rotação dos facilitadores para evitar que uma única pessoa domine a discussão. - **Revisões operacionais:** avalie a integridade operacional agregada por meio de análises de negócios trimestrais ou mensais. As análises operacionais examinam dados de tendência, comparam-se com objetivos, identificam oportunidades de melhoria e alocam o investimento em melhoria. Essas revisões também engajam a liderança, protegendo recursos para trabalho de melhoria operacional que compete com o desenvolvimento de recursos. Inclua métricas operacionais em revisões: - **Disponibilidade:** Real versus alvo, por jornada do usuário e geral - **Desempenho:** Tendências de latência, por percentil e fluxos críticos - **Incidentes:** Contagem por gravidade, tempo médio para detectar, tempo médio para resolver - **Segurança da implementação:** Frequência, taxa de sucesso, frequência de reversão - **Carga operacional:** Páginas sob chamada, intervenções manuais, horário de trabalho As revisões criam responsabilidade pela excelência operacional, em vez de tratar as operações como trabalho em segundo plano invisível que recebe atenção apenas durante as crises. Revisões operacionais regulares sinalizam o compromisso organizacional com operações sustentáveis. #### Revisões de engenharia Os retrospectivos analisam como o trabalho recente foi, e as análises operacionais relatam a saúde agregada da liderança. As análises de engenharia são o ritmo recorrente em que a equipe transforma sinais operacionais em decisões de entrega. Eles ficam entre si, conectando os painéis, tendências de incidentes e orçamentos de erro que o sistema produz aos planos de versão e prioridades de pendências que a equipe se compromete. Executar essa revisão mantém a integridade operacional de propriedade das pessoas que estão fazendo o trabalho, tornando-a uma parte integrada do planejamento, em vez de uma reflexão posterior. - **Planejamento de lançamento:** Trate a prontidão operacional como uma entrada de primeira classe junto com o escopo do recurso, as alterações de sequência para limitar o raio de explosão e retenha as versões quando o orçamento de erro for esgotado. Dessa maneira, a disciplina da implementação e as prioridades de negócios são reconciliadas deliberadamente, não sob pressão de prazo. - **Triagem de pendências:** Coloque o trabalho operacional (por exemplo, itens de ação de incidente, tarefas de prevenção, débito técnico, lacunas de monitoramento) na mesma pendência que o trabalho de recurso para que ele compete pela capacidade. A triagem regular atribui proprietários e prioridade, fechando o loop de trabalhos posteriores a trabalhos confirmados. #### Revisões de prontidão operacional - As **Revisões de prontidão operacional** (ORRs) avaliam se os novos recursos ou sistemas atendem aos requisitos operacionais antes do lançamento da produção. Os ORRs evitam desastres operacionais capturando lacunas operacionais durante o desenvolvimento quando as correções são mais baratas do que a remediação pós-lançamento. Realize ORRs antes do lançamento da produção de novas soluções, principais recursos ou alterações arquitetônicas com implicações operacionais. O momento da ORR é importante: muito cedo e a implementação permanece incompleta, muito tarde e preocupações operacionais parecem bloqueadores de implementação causando pressão para ignorar correções. Estas são as preocupações e perguntas a serem consideradas ao realizar uma ORR: - **Monitoramento e alerta:** Métricas suficientes são instrumentadas? Existem alertas para cenários de falha? Os painéis estão configurados para mostrar o status de saúde? - **Documentação:** Existem manuais para operações comuns? A arquitetura está documentada, permitindo que os respondentes entendam o sistema? Os procedimentos de escalação estão claros? - **Implantação e reversão:** A implantação pode ser executada com confiança? Existe um procedimento de reversão? A implantação foi validada no preparo? - **Desempenho e escalabilidade:** As metas de desempenho foram validadas sob carregamento realista? Há espaço para crescimento? Há riscos de limite do controlador? - **Segurança e conformidade:** As análises de segurança foram concluídas? Os requisitos de auditoria são atendidos? O controle de acesso corresponde aos requisitos? - **Dependências:** Dependências externas são identificadas? Os parceiros de integração têm SLAs? Há um comportamento de fallback para falhas de dependência? Lançamento da produção do gate na conclusão do ORR. As equipes levam as preocupações operacionais a sério quando se tornam requisitos de implantação em vez de esforços recomendáveis. Os portões ORR impedem o acúmulo de débito operacional que torna cada vez mais difícil a excelência operacional futura. #### Loops de feedback e cultura de aprendizado As organizações de aprendizado capturam sistematicamente a experiência operacional e a convertem em práticas aprimoradas. A cultura de aprendizado depende de: segurança psicológica, de modo que as pessoas possam relatar problemas sem medo; medição, de modo que os dados possam revelar padrões; e engajamento, de modo que a liderança aloque tempo para melhoria. - **Segurança psicológica:** permite discussão honesta de problemas, erros e quase erros sem medo de punição. Equipes sem segurança psicológica ocultam problemas até serem catastróficos, impedindo intervenção precoce. Crie segurança psicológica por meio de trabalhos pós-mortemas impecáveis, comemorando a descoberta de problemas e a vulnerabilidade de modelagem de liderança discutindo seus próprios erros. - **Medida:** torna o estado operacional visível. Métricas operacionais, tendências de incidentes, indicadores de DORA e pontuações de satisfação do usuário revelam o desempenho das operações em relação ao desempenho desejado. A medição permite a priorização objetiva do trabalho de melhoria com base no impacto, em vez de reclamações mais altas ou incidentes mais recentes. - **Tempo de melhoria:** reconhece que a excelência operacional requer investimento. Equipes que gastam 100% da capacidade em recursos não têm tempo para melhoria operacional, criando débito técnico e operacional que, por fim, força a resposta à crise. Reserve intencionalmente a capacidade de engenharia para melhoria operacional, redução de débito técnico, investimento em ferramentas e automação. Essa disciplina evita degradação de longo prazo enquanto habilita a velocidade de recurso sustentável. Crie loops de feedback conectando a experiência operacional a decisões de design. Quando os incidentes revelam fraquezas arquitetônicas, priorize melhorias arquitetônicas para evitar incidentes semelhantes. Quando o monitoramento revela uma degradação de desempenho, priorize o trabalho de otimização. Quando falhas de implementação revelarem lacunas de teste, priorize melhorias na cobertura de teste. Os loops de feedback criam ciclos virtuosos em que as operações melhoram continuamente em vez de diminuir gradualmente. | Fase | Aspecto | Compromissos | | :---- | :---- | :---- | | **Lean Otimizado -** Melhore a experiência operacional direta. | Revisão informal. Retrospectivas após incidentes e versões, melhorias rastreadas como pendências, estado operacional avaliado com base em sinais nativos e observação direta. | Na menor sobrecarga, o aprendizado acontece perto do trabalho. A melhoria é reativa e desigual, depende de quem se lembra do que, e a degradação é invisível até que apareça como um incidente. | | **Otimizada em escala -** Melhore com base em tendências medidas. | Melhoria medida. DORA e métricas operacionais mudaram de tendência ao longo do tempo, análises operacionais agendadas em relação a objetivos e um ORR gerando novos lançamentos. | Priorização de objetivo dos dados de tendência e lacunas operacionais capturadas antes do lançamento. Exige a instrumentação para calcular as métricas e o tempo de espera para revisar e agir com base nelas. | | **Governação Otimizada -** Melhore para um padrão comprometido em toda a empresa. | Melhoria governada. Métricas operacionais relatadas à liderança em relação a metas confirmadas, uma alocação de capacidade protegida para trabalho operacional e padrões de melhoria aplicados de maneira consistente em toda a empresa. | Melhorias sustentáveis e responsáveis exigem investimento e compromisso contínuos. | ## Lista de verificação de resumo A Excelência operacional exige projetar soluções para capacidade de observação, implantar por pipelines automatizados, responder de modo eficaz a incidentes e aprender continuamente com a experiência operacional. Revise esta lista de verificação para avaliar sua maturidade operacional: **Observabilidade e monitoramento** - A solução inclui IDs de correlação de captura de registro abrangente para rastreamento distribuído - Monitoramento de evento habilitado e Arquivos de log de evento são exportados para plataforma externa para retenção além dos limites nativos - Proactive Monitoring configurado com limites ajustados para a linha de base da organização - Linhas de base do Centro de escala estabelecidas e revisadas após cada versão - Configurar exportações da Trilha de auditoria para retenção além de 180 dias - Trilha de auditoria de campo habilitada para campos de dados sigilosos e regulados ] - As verificações da Detecção de dados identificam e categorizam dados confidenciais em campos, com descobertas levando à classificação e remediação de conformidade - Verificação de integridade revisada trimestralmente em relação à linha de base de segurança com as descobertas remediadas por prioridade de risco - Processos críticos do usuário instrumentados com marcadores de marco e monitoramento de taxa de sucesso - O monitoramento de integração rastreia a integridade bidirecional de todas as dependências externas - Objetivos de nível de serviço definidos para disponibilidade, latência, taxa de sucesso e taxa de transferência - A arquitetura de alerta inclui níveis de gravidade, contexto acionável e escalonamento claro **Práticas DevOps** - Controle de versão de todos os metadados habilitando compilações reproduíveis da origem - Organizações teste ou sandboxes do desenvolvedor oferecem suporte ao desenvolvimento isolado - As alterações de configuração seguem o mesmo processo de revisão que as alterações de código - A detecção de desvio de configuração é executada trimestralmente com a remediação documentada - A estratégia de sandbox inclui ambientes de desenvolvedor, integração, preparação e treinamento - Atualização de sandbox e carregamento de dados automatizado - O pipeline CI valida cada confirmação com testes automatizados - Ramificação principal protegida exige o sucesso do CI antes da mesclagem - O pipeline de CD é implementado por meio de ambientes com validação progressiva - A validação da implementação é executada antes da implementação de produção - O monitoramento de implementação rastreia as principais métricas durante e após as implementações - Procedimentos de documento de manuais de implementação, validação e reversão - A pirâmide de teste inclui testes de unidade, testes de integração e testes de ponta a ponta - Execução de teste automatizada no pipeline de CI - Revisão de código requer duas aprovações com critérios de revisão explícitos - Solicitações de pull mantidas pequenas (200-400 linhas) para análise aprofundada **Automação e eficiência** - Automação declarativa usada quando aplicável (fluxo, fórmula, validação, aprovações) - Fluxos projetados modularmente com subfluxos reutilizáveis - Estrutura do acionador fornece uma estrutura consistente para automação do Apex - Trabalhos em lote implementam idempotência e registro abrangente - Trabalhos agendados são executados durante períodos de baixo tráfego com monitoramento - Eventos de plataforma habilitam a arquitetura acionada por evento para processamento assíncrono - Esquemas de evento projetados para estabilidade com estratégia de controle de versões - A visibilidade operacional de automação inclui registro, monitoramento e alerta **Gerenciamento de incidentes** - O monitoramento automatizado fornece detecção de incidentes primários - Níveis de gravidade do incidente definidos com requisitos de tempo de resposta claros - Procedimentos de resposta a incidentes documentados em manuais - A rotação na chamada distribui a carga operacional de modo justo entre a equipe - Caminhos de escalação claros com acionadores baseados em tempo e baseados em complexidade - Os engenheiros sob chamada têm acesso, ferramentas e informações necessárias - Débito sob chamada compensado de maneira justa - Pós-mortems inocentes realizados para todos os incidentes de gravidade 1 e 2 - Linha do tempo do documento de postmortems, causa raiz, impacto, melhoria de detecção e ações de prevenção específicas - Descobertas pós-mortem compartilhadas amplamente para aprendizado organizacional **Melhoramento contínuo** - Métricas de DORA rastreadas continuamente (frequência de implementação, tempo de processamento, taxa de falha de alteração, tempo para restaurar, taxa de retrabalho) - Os retrospectivas de sprint ocorrem regularmente com formato estruturado e resultados acionáveis - As análises operacionais avaliam a saúde agregada trimestralmente ou mensalmente - Lançamento da produção do gate de Revisões de prontidão operacional de novos recursos - Segurança psicológica permite discussão honesta de problemas e erros - Capacidade de engenharia deliberadamente reservada para melhoria operacional - Os loops de feedback conectam a experiência operacional a melhorias de design - Excelência operacional vista como responsabilidade de todos, não apenas da equipe de operações

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

# Excelência operacional – Padrões O pilar de Excelência operacional se concentra em automação, práticas de DevOps, capacidade de observação, monitoramento e gerenciamento de incidentes para que as operações funcionem sem problemas e sejam recuperadas rapidamente. Esses padrões transformam os princípios de design do pilar em práticas concretas revisáveis: o que procurar em uma solução, o que é bom e os antipadrões que a minam. ## Princípios de design Esses padrões colocam os princípios de design do pilar de Excelência operacional em prática. Leia-os junto com o [pilar de Excelência Operacional](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence.md) para obter as orientações completas por trás de cada um. - **Evoluir com a capacidade de observação** — Projetar instrumentação, monitoramento e telemetria a partir da versão inicial em vez de adaptá-la posteriormente após o surgimento de problemas. - **Padronizar procedimentos operacionais** – configuração de versão e procedimentos operacionais no controle de origem para que funcionem de forma consistente e reduzam o desvio de configuração. - **Aprenda a cultura DevOps** — quebre silos entre desenvolvimento, operações e equipes de negócios por meio da responsabilidade compartilhada pelos resultados. - **Automação para eficiência** – automatize tarefas operacionais repetitivas para eliminar o trabalho manual, reduzir erros e permitir a escala de operações. - **Aprenda com todos os eventos operacionais** — extraia aprendizado de incidentes, quase-erros e sucessos por meio de pós-mortems inocentes e telemetria operacional. ## Como usar estes padrões Cada categoria combina **padrões** (o que parece bom) com **antipadrões** (o que evitar), organizados para que você possa revisar uma área de solução por área. Comece com o resultado operacional de que você precisa: - **Obter visibilidade do comportamento do sistema?** Use a **observabilidade** para registro, monitoramento, rastreamento, alerta e visibilidade do sistema. - **Eliminação de operações manuais?** Use a **Automação** para automação de processos, infraestrutura como código e remoção de trabalho repetitivo. - **O envio muda com segurança e frequência?** Use o **DevOps** para pipelines CI/CD, controle de versão, automação de teste e estratégias de implementação. - **Preparando-se para detectar e resolver incidentes?** Use o **Gerenciamento de incidente** para detecção, procedimentos de resposta e pós-mortems. - **Está melhorando ao longo do tempo?** Use a **melhoria contínua** para métricas DORA, análises operacionais, análises de prontidão e uma cultura de aprendizagem. - **Agentes operacionais na produção?** Use **Padrões agentes** para gerenciamento de ciclo de vida do agente, automação de implantação e monitoramento operacional. ## Categorias de padrão ### [Padrões agentes](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence-agentic-patterns.md) Padrões de excelência operacional para sistemas agentes, incluindo gerenciamento de ciclo de vida do agente, automação de implantação e monitoramento operacional. ### [Automação](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence-automation-patterns.md) Padrões para automação de processos, infraestrutura como código e eliminação de operações manuais. ### [Melhoramento contínuo](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence-continuous-improvement-patterns.md) Padrões para métricas DORA, revisões retrospectivas e operacionais, análises de prontidão operacional e criação de uma cultura de aprendizagem. ### [DevOps](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence-devops-patterns.md) Padrões para pipelines CI/CD, controle de versão, automação de teste e estratégias de implementação. ### [Gerenciamento de incidentes](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence-incident-patterns.md) Padrões para detecção de incidentes, procedimentos de resposta, trabalhos posteriores e melhoria contínua. ### [Observabilidade](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence-observability-patterns.md) Padrões para registro, monitoramento, rastreamento, alerta e visibilidade do sistema. ## Recursos relacionados - [Pilar de Excelência Operacional](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence.md) — os princípios de design e orientação arquitetônica que esses padrões implementam - [Excelência operacional para a empresa agente](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/agentic-enterprise-operational-excellence.md) – orientação operacional para soluções baseadas em agente - [Framework bem estruturado](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/framework.md) — como a Excelência Operacional se encaixa junto com os outros pilares - [Padrões e Antipadrões](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/patterns-and-anti-patterns.md) — a biblioteca completa de padrões em todos os pilares # Excelência operacional – Padrões agentes Saiba mais sobre a [Excelência Operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) bem-arquitetada → [Excelência Operacional](/docs/architect/pt-br/well-architected/guide/agentic-enterprise-operational-excellence.html) da Agência ## Capacidade de observação do agente **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Rastreamento de sessão | ✅ Use o Modelo de dados de rastreamento de sessão (STDM) nativo para capturar interações do agente em um modelo de dados unificado no Data 360 em vez de criar um sistema de telemetria paralelo, registrando cada conversa como uma hierarquia de rastreamento de sessões, interações (turns) e etapas (UserInputStep, LLMExecutionStep, FunctionStep) | | Agentforce \| Rastreamento de sessão | ✅ Conte com os objetos STDM padrão (AIAgentSession, AIAgentSessionParticipant, AIAgentInteraction, AIAgentInteractionStep, AIAgentInteractionMessage), que capturam ações nativamente como etapas da interação em vez de exigir um registro de ação separado | | Agentforce \| Rastreamento de sessão | ✅ Recupere os detalhes de uso, modelo e prompt do token unindo etapas de interação aos registros de chamada LLM (por meio de referências GenerationId e GenAiGatewayRequest/Response) em vez de armazená-los como campos de sessão personalizados | | Agentforce \| Rastreamento de sessão | ✅ Capture rastreamentos de raciocínio do Mecanismo de raciocínio do Atlas – o rastreamento de sessão registra as etapas do planejador como parte de cada interação – para revelar os processos de decisão do agente e melhorar a capacidade de depuração | | Agentforce \| Configuração do agente | ✅ Registrar detalhes no nível de turno, incluindo entrada do usuário, resposta do agente, explicação de raciocínio, pontuações de confiança, contexto recuperado, ações tentadas e erros encontrados | | Einstein \| Camada Trust | ✅ Ative a trilha de auditoria de IA generativa da Camada de Trust do Einstein (texto de prompt e resposta, versões mascaradas por PII, dados de fundamentação, pontuações de segurança e toxicidade, detalhes do modelo) transmitida ao Data 360, além de Armazenamento e coleta de dados de feedback e IA generativa do Einstein para retenção de longo prazo | | Plataforma \| Objetos personalizados | ✅ Reserve objetos de registro personalizados para exceções deliberadas, como um objeto leve correlacionando o comportamento do agente aos resultados de negócios, em vez de torná-los o substrato de registro principal | | Plataforma \| Painel | ✅ Correlacionar o comportamento do agente aos resultados de negócios, identificar oportunidades de melhoria por meio da análise de padrão e alimentar pipelines de aprendizado contínuo com exemplos rotulados com qualidade | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Objetos personalizados | Criar manualmente objetos transacionais personalizados como o substrato principal de registro de conversas em vez do Modelo de dados de rastreamento de sessão nativo, enfrentando problemas de escala ao armazenar conversas de vários turnos, grandes cargas úteis JSON e rápido crescimento de dados | | Agentforce \| Rastreamento de sessão | Criar um sistema de telemetria paralelo quando o Rastreamento de sessão do Agentforce já captura interações em um modelo de dados unificado no Data 360 | | Agentforce \| Configuração do agente | ⚡️ Registrar apenas as respostas do agente sem capturar entradas, raciocinar rastreamentos, contexto recuperado e ações realizadas | | Einstein \| Camada Trust | Desabilitar a trilha de auditoria da Camada de Trust do Einstein em produção ou não ativar a Coleção e armazenamento de dados de feedback para retenção de longo prazo no Data 360 | | Plataforma \| Monitoramento | ⚡️ Dependendo apenas do sucesso/falha da conversa sem capturar detalhes de uso de token, modelo e prompt por meio das junções de chamada LLM de STDM | ## Monitoramento de desempenho **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Monitoramento | ✅ Medir a latência da resposta em percentis (p50, p95, p99) revelando desempenho típico e experiências de pior caso | | Plataforma \| Monitoramento | ✅ Instrumente cada fase de latência separadamente (inferência de modelo, recuperação de contexto, execução de ação, rede) habilitando a otimização direcionada | | Plataforma \| Monitoramento | ✅ Alerta quando a latência p95 excede limites indicando degradação do desempenho | | Plataforma \| Monitoramento | ✅ Rastreie a distribuição de token (tokens de prompt, tokens de conclusão, tokens totais) por conversa, por agente e por caso de uso | | Plataforma \| Monitoramento | ✅ Detectar conversas atípicas que consomem tokens excessivos sugerindo problemas de prompt ou uso indevido | | Plataforma \| Monitoramento | ✅ Comparar a taxa de transferência atual com os limites de taxa conhecidos ou alerta de linhas de base de capacidade ao se aproximar dos limites | | Plataforma \| Monitoramento | ✅ Calcule as taxas de erro como um percentual do total de solicitações, permitindo a comparação entre agentes e períodos | | Plataforma \| Monitoramento | ✅ Diferenciar entre categorias de erro (erros de modelo, erros de permissão, erros de integração) que exigem respostas diferentes | | Plataforma \| Monitoramento | ✅ Calcule a disponibilidade como a porcentagem de tempo em que os agentes respondem com sucesso a solicitações e rastreiam em relação a SLOs | | Plataforma \| Proactive Monitoring | ✅ Configurar limites Proactive Monitoring com base nos padrões de comportamento do agente de linha de base em vez de aceitar padrões | | Plataforma \| Centro de escala | ✅ Revise os dados do Centro de escala depois de implementar novos agentes ou fazer alterações importantes de prompt validando as expectativas de correspondência de consumo do recurso | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Monitoramento | ⚡️ Medindo apenas a latência média, em vez de percentis, mascarando experiências de usuário de pior caso | | Plataforma \| Monitoramento | ⚡️ Rastrear a latência total sem instrumentar fases individuais (inferência, recuperação, execução de ação) | | Plataforma \| Monitoramento | ⚡️ Tratar todos os erros da mesma maneira em vez de categorizar por tipo (modelo, permissão, integração) para uma resposta adequada | | Plataforma \| Proactive Monitoring | Aceitar limites padrão Proactive Monitoring sem ajustar aos padrões de comportamento do agente de base | | Plataforma \| Centro de escala | ⚡️ Implantar novos agentes ou fazer alterações de prompt sem revisar os dados do Centro de escala para validar o consumo de recursos | | Plataforma \| Monitoramento | ⚡️ Ignorar padrões de consumo de token e não detectar conversas atípicas que consomem 10x tokens típicos | ## Métricas de qualidade e avaliação **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Centro de testes | ✅ Comece com ferramentas nativas de teste e avaliação: manter conjuntos de casos de teste reutilizáveis na central de testes do Agentforce e executar agentes contra eles em lote, verificando se o agente selecionou o tema e a ação esperados e produziu uma resposta aceitável | | Agentforce \| Centro de testes | ✅ Use avaliadores nativos (dimensões de qualidade prontas para uso e a abordagem de LLM-as-judge para pontuar a qualidade da conversa) e crie avaliadores personalizados para critérios específicos da organização, usando conversas representativas para que a avaliação reflita o uso real | | Agentforce \| Centro de testes | ✅ Para perguntas factuais com respostas conhecidas, mantenha as declarações de resposta conhecida como casos de teste repetíveis no Centro de teste; para perguntas de término aberto, adicione revisão humana de conversas de amostra | | Data 360 \| Qualidade de recuperação | ✅ Para agentes baseados em uma base de Knowledge, use a análise de qualidade de recuperação nativa para avaliar a relevância do contexto, a relevância das respostas e a fidelidade (fundamentaridade) das respostas | | Einstein \| Camada Trust | ✅ Conte com a detecção de toxicidade no tempo de execução da Camada de Trust do Einstein como a primeira linha de defesa de proteção, então melhore o monitoramento de segurança por meio de filtragem de conteúdo, amostragem de revisão manual, relatórios do usuário e auditorias de imparcialidade entre grupos demográficos | | Data 360 \| GenAIFeedback | ✅ Capture a satisfação do usuário por meio do feedback do Agentforce que flui para os DMOs GenAIFeedback / GenAIFeedbackDetail no Data 360 (tomil para cima/para baixo, aceitar/rejeitar, editar, comentários verbais) junto com a solicitação de gateway e os dados de geração | | Plataforma \| Analytics | ✅ Combine feedback explícito (pedido antes do escalonamento, após a conversa, pesquisas de acompanhamento) com sinais implícitos (taxas de conclusão, escalonamento, abandono, novas tentativas), correlacionando-se com características da conversa para orientar a priorização da melhoria | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Centro de testes | Construir e executar um equipamento de teste personalizado em vez de começar com os conjuntos de teste reutilizáveis da Central de Testes do Agentforce e avaliadores nativos | | Agentforce \| Centro de testes | ⚡️ Contando apenas com avaliação automatizada sem revisão humana para avaliação de qualidade de respostas de término aberto | | Plataforma \| Monitoramento | ⚡️ Monitorar apenas a precisão sem rastrear dimensões de relevância, segurança e satisfação do usuário | | Data 360 \| GenAIFeedback | ⚡️ Não conseguir coletar qualquer feedback do usuário (explicito ou implícito) sobre a qualidade da resposta do agente quando o feedback do Agentforce já flui para os DMOs de GenAIFeedback | | Agentforce \| Configuração do agente | ⚡️ Ignorar auditorias de imparcialidade avaliando distribuições de resultados entre grupos demográficos | ## Detecção de desvio do modelo **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Configuração do agente | ✅ Estabelecer o desempenho da linha de base imediatamente após a implementação do agente, medindo a precisão, a relevância, a segurança e a satisfação em casos de teste representativos | | Agentforce \| Configuração do agente | ✅ Reavaliar periodicamente em relação aos mesmos casos de teste revelando alterações de desempenho independentemente de turnos de padrão de uso | | Plataforma \| Monitoramento | ✅ Alerta quando as métricas de qualidade ultrapassam limites aceitáveis definidos pela tolerância ao impacto dos negócios | | Plataforma \| Analytics | ✅ Monitorar características de entrada (comprimento da pergunta, distribuição de tópicos, complexidade do idioma, terminologia de domínio) detectando turnos de distribuição significativos | | Plataforma \| Monitoramento | ✅ Monitorar características da resposta (duração média da resposta, taxas de invocação de ação, frequências de escalação, padrões de erro) estabelecendo linhas de base comportamentais | | Plataforma \| Monitoramento | ✅ Configure o acionamento automatizado de alertas quando as métricas de desvio excederem limites acionando investigação e remediação | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | ⚡️ Falha ao estabelecer o desempenho da linha de base após a implantação inicial do agente, tornando o desvio não detectável | | Plataforma \| Monitoramento | Ignorar o desvio de distribuição quando os padrões de entrada do usuário mudam significativamente em relação ao que os agentes foram projetados para lidar | | Plataforma \| Monitoramento | ⚡️ Não monitorar alterações comportamentais (duração da resposta, taxas de ação, frequências de escalação) em relação às linhas de base estabelecidas | | Plataforma \| Monitoramento | ⚡️ Não ter alerta automatizado para métricas de desvio, contando apenas com observação manual para detectar degradação | ## Detecção e alerta de anomalia **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Monitoramento | ✅ Monitore as distribuições de consumo de token detectando conversas atípicas e investigue aquelas que consomem 10x tokens típicos | | Plataforma \| Monitoramento | ✅ Detectar aumentos repentinos nas taxas de falha, novos tipos de erro não na linha de base ou concentrações de erro localizadas que afetam usuários ou agentes específicos | | Plataforma \| Analytics | ✅ Acompanhe o abandono da conversa por estágio da conversa identificando se os usuários abandonam durante a interação inicial, no meio da conversa ou após a conclusão da tarefa | | Plataforma \| Monitoramento | ✅ Encaminhe falhas críticas do agente para engenheiros de chamada imediatamente, degradação de qualidade para equipes do produto durante o horário comercial e pequenas anomalias para resumos diários | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Monitoramento | ⚡️ Tratando todos os alertas com a mesma urgência, causando fadiga de alerta e falhas críticas perdidas | | Plataforma \| Monitoramento | Ignorar anomalias de custo, como picos de consumo de token que podem indicar problemas de prompt, abuso ou problemas de infraestrutura | | Plataforma \| Analytics | ⚡️ Não rastrear as taxas de abandono da conversa ou não analisar o abandono por estágio | | Plataforma \| Monitoramento | ⚡️ Aguardar relatórios do usuário em vez de detectar de modo proativo picos de taxa de erro por meio do monitoramento automatizado | ## Controle de versão de prompt **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Controle de origem | ✅ Armazene modelos de prompts no Git junto com avisos de código de aplicativo tratando como lógica de aplicativo crítica que merece revisão, teste e implantação controlada de código | | Einstein \| Criador de prompts | ✅ Use Criador de prompts para desenvolvimento de prompts iterativo com recursos de histórico de versões e teste, então exporte para controle de versão para pipelines de implementação | | Plataforma \| Controle de origem | ✅ Armazenar configurações (seleção de modelo, temperatura, limites de token, configurações de recuperação, permissões de ação, sinalizadores de recurso) como código que habilita valores específicos do ambiente e detecção de desvio | | Plataforma \| Controle de origem | ✅ Aplicar controle de versões semântico a componentes do agente: principal (interrupção de alterações), secundário (recursos), correção (correções de erros) com números de versão aparecendo em registros | | Plataforma \| Documentação | ✅ Documente o que mudou, por que mudou, qual teste validou a alteração e quais procedimentos de reversão existem para cada solicitação e alteração de configuração | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Einstein \| Criador de prompts | ⚡️ Fazer alterações de prompt sem revisão de código, teste ou processos de implementação controlados | | Plataforma \| Configuração | Armazenar configurações de agente fora do controle de origem em que o desvio não pode ser detectado e as implantações não podem ser automatizadas | | Plataforma \| Documentação | ⚡️ Fazer alterações de prompt sem documentar a racionalidade, os resultados de teste ou os procedimentos de reversão | | Plataforma \| Controle de origem | ⚡️ Falha na aplicação de controle de versões semântico, impossibilitando a correlação de incidentes com implantações específicas | ## Registro de modelo e rastreamento de implementação **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Documentação | ✅ Mantenha um registro de modelo que registra quais versões de modelo são implementadas, incluindo família de modelos, versão específica, estado de ajuste fino, ambiente, data de implementação e equipe responsável | | Plataforma \| Documentação | ✅ Registrar todas as implementações do agente, incluindo versão, ambiente, carimbo de data e hora, usuário de implementação, aprovações obtidas e resultado da implementação | | Plataforma \| Documentação | ✅ Mapeie dependências entre agentes, avisos, bases Knowledge, ações e integrações explicitamente em vez de descobri-las durante incidentes | | Negócios \| Processo | ✅ Estabelecer uma agenda de descontinuação com um período de aviso mínimo com suporte em política comunicado com antecedência suficiente, habilitando migrações planejadas em vez de respostas de emergência a descontinuações forçadas | | Plataforma \| Documentação | ✅ Procedimentos de reversão de documento para cada agente, incluindo versão de destino, etapas de execução, testes de validação e requisitos de notificação | | Plataforma \| Preparação | ✅ Testar procedimentos de reversão em ambientes que não sejam de produção para validar se eles funcionam antes de depender deles durante incidentes de produção | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Documentação | Descobrir dependências entre agentes, avisos e bases de Knowledge apenas durante incidentes, em vez de manter mapas de dependência explícitos | | Negócios \| Processo | ⚡️ Fornecer um aviso de descontinuação insuficiente forçando migrações de emergência em vez de transições planejadas | | Plataforma \| Documentação | ⚡️ Ter procedimentos de reversão não testados que falham quando mais necessário durante incidentes de produção | | Plataforma \| Implantação | ⚡️ Implantar agentes sem registrar versão, ambiente, aprovações ou resultado, perdendo a capacidade de correlacionar incidentes com implantações | ## Treinamento contínuo e adaptação de domínio **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| UI | ✅ Colete feedback explícito (polegar para cima e para baixo, pontuações de qualidade, comentários) e feedback implícito (taxas de conclusão, frequências de escalação, padrões de repetição) sistematicamente | | Data 360 \| Curadoria de dados | ✅ Organize registros de conversa em conjuntos de dados de treinamento filtrando pela qualidade, removendo exemplos problemáticos, garantindo a representatividade e desduplicando | | Data 360 \| Fundamentação | ✅ Adapte os agentes ao vocabulário de domínio, aos processos de negócios e ao Knowledge específico da organização, principalmente por meio do RAG baseado no Data 360 e do ajuste rápido – o caminho de adaptação nativo do Salesforce | | Einstein \| BYOLLM | ✅ Quando a fundamentação e o ajuste de prompts forem insuficientes, faça o ajuste fino de um modelo externamente e conecte-o por meio de BYOLLM, em vez de esperar o ajuste fino generativo na plataforma | | Einstein \| Criador de prompts | ✅ Estabelecer ritmo de revisão de prompts regular examinando conversas recentes, métricas de qualidade e feedback do usuário identificando oportunidades de melhoria | | Einstein \| Criador de prompts | ✅ Implemente alterações de prompt incrementalmente com testes A/B validando melhorias antes da distribuição completa | | Agentforce \| Configuração do agente | ✅ Mantenha conjuntos de teste que abrangem caminhos felizes, casos de extremidade, entradas adversárias e cenários de problemas históricos, expandindo-se continuamente à medida que novos casos de extremidade são descobertos | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Dados | ⚡️ Tentando melhorar sem coleta de feedback sistemática, fazendo suposições de melhoria em vez de dados orientados | | Data 360 \| Curadoria de dados | ⚡️ Usar registros de conversa não selecionados para treinamento, incluindo violações de segurança, erros e exemplos não representativos | | Data 360 \| Fundamentação | ⚡️ Alcançar o ajuste fino externo antes de esgotar a fundamentação RAG e o ajuste de prompt, o caminho nativo que resolve a maioria das necessidades de adaptação de domínio sem um modelo personalizado | | Einstein \| Criador de prompts | ⚡️ Tratar a engenharia de prompts como um exercício único em vez de uma prática contínua ajustada conforme os padrões de uso evoluem | | Agentforce \| Configuração do agente | ⚡️ Ter conjuntos de teste estáticos que nunca se expandem para cobrir novos casos de ponta descobertos em produção | ## Distribuição gradual e teste A/B **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Tipos de metadados personalizados | ✅ Implemente sinalizadores de recurso usando tipos de metadados personalizados ou configurações personalizadas para desacoplar a implantação da versão para alterações de agente de alto risco | | Plataforma \| Conjuntos de permissões | ✅ Implemente implantações Canary liberando alterações de agente para um pequeno subconjunto de usuários primeiro usando conjuntos de permissões que controlam o acesso do agente | | Agentforce \| Configuração do agente | ✅ Monitore a coorte canária medindo intensivamente as taxas de sucesso, a qualidade, as taxas de erro, a latência, o consumo do token e a satisfação e expanda a distribuição apenas quando o canário corresponde ou melhora no grupo de controle que executa a versão do agente anterior | | Plataforma \| Analytics | ✅ Defina critérios de sucesso antes de iniciar testes A/B para evitar resultados ambíguos, alinhados aos objetivos de negócios | | Agentforce \| Configuração do agente | ✅ Implementar testes de campeão e desafiador mantendo a versão comprovada como fallback enquanto compara a versão de desafiador aprimorada | | Negócios \| Processo | ✅ Estabelecer critérios de promoção objetivos, incluindo tamanho mínimo da amostra, limites de qualidade e duração da avaliação antes das decisões de promoção | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | Distribuir alterações de agente para todos os usuários ao mesmo tempo sem testes de canary, maximizando o raio de problemas | | Plataforma \| Implantação | ⚡️ Implementar alterações de agente de alto risco sem sinalizadores de recurso habilitando reversão instantânea sem reimplementação | | Plataforma \| Analytics | Executar testes A/B sem critérios de sucesso predefinidos, levando a resultados ambíguos e decisões ruins | | Plataforma \| Analytics | Executar experiências com tamanho de amostra insuficiente produzindo resultados ruidosos que levam a conclusões incorretas | | Agentforce \| Configuração do agente | ⚡️ Usar sinalizadores de recurso para cada pequena alteração de prompt em vez de reservá-los para alterações de alto risco para agentes essenciais para os negócios | ## Detecção e classificação de incidentes **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Monitoramento | ✅ Detectar falhas do agente por meio de alerta de monitoramento automatizado sobre taxas de erro, degradação da métrica de qualidade, anomalias de custo, aumentos de latência e escalonamentos de usuário | | Plataforma \| Monitoramento | ✅ Suplementar a detecção automatizada com mecanismos de relatório do usuário que permitem a escalação de erros de monitoramento automatizado de problemas | | Negócios \| Processo | ✅ Defina critérios de gravidade de modo objetivo com base no impacto do usuário, no raio de explosão, no risco de integridade dos dados e na urgência da recuperação | | Plataforma \| Documentação | ✅ Documente procedimentos de resposta inicial como manuais executáveis por engenheiros na chamada sem conhecimento aprofundado do agente | | Agentforce \| Configuração do agente | ✅ Inclua na resposta inicial: desabilitar agente com falha (interruptor de circuito), rotear para fallback, coletar diagnósticos, notificar as partes interessadas, iniciar a comunicação de incidentes | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Monitoramento | Confiar em relatórios do usuário como mecanismo de detecção primário em vez de monitoramento automatizado para falhas do agente | | Negócios \| Processo | ⚡️ Usar classificação de gravidade subjetiva que leva a problemas reais de escalonamento inferior ou problemas secundários de escalonamento excessivo | | Plataforma \| Documentação | ⚡️ Não ter manuais, exigindo investigação específica do incidente por engenheiros com profundo conhecimento do agente durante cada incidente | | Negócios \| Processo | ⚡️ Tratar falhas do agente de maneira idêntica às falhas do aplicativo tradicional sem levar em conta alucinações, respostas fora do tópico ou violações de segurança | ## Interruptores de circuito e fallback **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Apex | ✅ Implemente os disruptores de circuito com limite de erro configurável (por exemplo, taxa de erro de 50%), janela de duração (por exemplo, janela dinâmica de 5 minutos) e teste de recuperação (solicitações de avaliação periódica) | | Agentforce \| Configuração do agente | ✅ Projetar hierarquias de fallback: Agente sofisticado principal → Agente de backup mais simples → Respostas frequentes estáticas → Transferência humana | | Plataforma \| Orquestração | ✅ Implemente a lógica de fallback na camada de orquestração, em vez de dentro de agentes individuais, permitindo um comportamento consistente em todo o ecossistema do agente | | Agentforce \| Configuração do agente | ✅ Projetar fluxos de trabalho de transferência humana preservando o contexto da conversa, comunicando o motivo da transferência e roteando para o agente humano adequado com conhecimento relevante | | Plataforma \| Monitoramento | ✅ Monitore as taxas de transferência por tópico, agente e motivo da falha para identificar lacunas de capacidade do agente | | Agentforce \| Configuração do agente | ✅ Quando o raciocínio sofisticado falhar, volte para uma lógica mais simples; quando os dados em tempo real estiverem indisponíveis, operar em dados em cache; quando as integrações falharem, operar no modo somente leitura | | Plataforma \| Orquestração | ✅ Testar caminhos de fallback regularmente, validando se eles funcionam quando necessário | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | ⚡️ Não ter interruptores de circuito, permitindo que agentes com falha afetem repetidamente os usuários enquanto os problemas são resolvidos | | Plataforma \| Orquestração | ⚡️ Implementar a lógica de fallback em agentes individuais, em vez de na camada de orquestração, criando comportamento inconsistente | | Agentforce \| Configuração do agente | ⚡️ Projetar agentes de aprovação/falha binários que funcionam perfeitamente ou falham completamente sem opções de degradação adequadas | | Plataforma \| Orquestração | ⚡️ Nunca teste caminhos de fallback, descobrindo que eles não funcionam apenas durante incidentes reais | | Agentforce \| Configuração do agente | Transferência humana que perde o contexto da conversa forçando os usuários a repetir informações | ## Análise pós-incidente **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Negócios \| Processo | ✅ Realize análises pós-incidente impecáveis com foco em melhorias do sistema em vez de falha individual criando segurança psicológica | | Negócios \| Processo | ✅ Crie uma linha do tempo detalhada de condições iniciais por meio de detecção, investigação, resposta, recuperação e validação com carimbos de data e hora | | Negócios \| Processo | ✅ Use a técnica de detalhamento "Cinco razões" dos sintomas para causas fundamentais em vez de conclusões simplificadas | | Negócios \| Processo | ✅ Analisar fatores relevantes, incluindo lacunas de monitoramento, lacunas de teste, lacunas de documentação, lacunas de automação e lacunas arquitetônicas | | Negócios \| Processo | ✅ Avaliar detecção: qual sinal deve ter detectado o problema anteriormente, qual monitoramento permite uma detecção mais rápida | | Negócios \| Processo | ✅ Especifique itens de ação específicos atribuídos que impedem a recorrência (por exemplo, "adicionar alerta para taxa de erro acima de 5% em 10 minutos - atribuído: Alex – vencimento: 2 semanas") | | Negócios \| Processo | ✅ Acompanhe a conclusão do item de ação em revisões subsequentes garantindo que melhoria contínua realmente ocorra | | Plataforma \| Documentação | ✅ Documentar análises pós-incidente na base de Knowledge compartilhada com marcação que habilita a análise de padrão em vários incidentes | | Negócios \| Processo | ✅ Compartilhe análises pós-incidente largamente além dos respondentes de incidentes imediatos por meio de reuniões de equipe ou sessões de almoço e aprendizado | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Negócios \| Processo | ⚡️ Pós-mortemas focados em culpa que reduzem a segurança psicológica e impedem a avaliação honesta de falhas | | Negócios \| Processo | ⚡️ Conclusões de causa raiz simples ("o agente tinha um bug") em vez de descobertas específicas que permitem uma solução eficaz | | Negócios \| Processo | Itens de ação vazios, como "melhorar o monitoramento", em vez de tarefas específicas atribuídas e com prazo definido | | Negócios \| Processo | Taxas baixas de conclusão de item de ação indicando falha do processo de melhoria contínua | | Negócios \| Processo | ⚡️ Manter aprendizado pós-incidente isolado para respostas imediatas em vez de compartilhar amplamente para aprendizado organizacional | ## Aprovação de implantação **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Negócios \| Processo | ✅ Validar a lista de verificação pré-implementação, incluindo teste, revisão de segurança, validação de conformidade, documentação, configuração de monitoramento e aprovação da parte interessada | | Negócios \| Processo | ✅ Avaliar o risco com base no raio de explosão, na confidencialidade dos dados, na autoridade de ação, nas dependências de integração, na complexidade da recuperação e nas implicações de conformidade | | Negócios \| Processo | ✅ Requisitos de aprovação de escala com base no risco: alto risco requer aprovação executiva, revisão de segurança e distribuição gradual; baixo risco requer revisão por pares e testes padrão | | Plataforma \| Processos de aprovação | ✅ Implementar fluxos de trabalho de aprovação automatizados, rastreados e auditáveis usando processos de aprovação do Salesforce ou ferramentas de implementação externas | | Negócios \| Processo | ✅ Defina procedimentos de desvio de emergência que exigem aprovação executiva, documentação de fundamento e revisão pós-implementação acelerada | | Plataforma \| Monitoramento | ✅ Rastreie implantações de emergência separadamente; a alta frequência de implantação de emergência indica problemas de processo que exigem investigação | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Negócios \| Processo | Aplicar profundidade uniforme de aprovação independentemente do perfil de risco do agente, desperdiçar esforço em agentes de baixo risco ou subavaliando agentes de alto risco | | Negócios \| Processo | ⚡️ Implementar agentes de produção sem validação da lista de verificação pré-implementação de testes, segurança, conformidade e monitoramento | | Plataforma \| Implantação | ⚡️ Não ter procedimentos de desvio de emergência, causando atrasos críticos durante incidentes de produção | | Negócios \| Processo | ⚡️ Frequentemente exigindo implantações de emergência, indicando processos padrão corrompidos em vez de circunstâncias excepcionais | ## Gates de qualidade e teste **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Agentforce \| Configuração do agente | ✅ Características de saída de teste (contém informações obrigatórias, mantém o tom adequado, inclui citações) em vez de texto exato para saídas de agente não deterministas | | Agentforce \| Configuração do agente | ✅ Estabelecer limites mínimos de qualidade (por exemplo, "precisão de 95% no conjunto de testes em espera, nenhuma violação de segurança, auditoria de imparcialidade mostra nenhuma disparidade demográfica superior a 5%") | | Agentforce \| Configuração do agente | ✅ Realize testes de segurança com entradas adversárias, incluindo injeção de prompt, tentativas de jailbreak, escalação de solicitação e solicitações fora do escopo | | Agentforce \| Configuração do agente | ✅ Ter testes de segurança realizados por membros da equipe que não estejam envolvidos no desenvolvimento do agente, fornecendo novas percepções sobre vulnerabilidades | | Plataforma \| Teste de desempenho | ✅ Teste sob carregamento realista, incluindo conversas simultâneas, durações típicas da conversa e volume de uso projetado | | Plataforma \| Segurança | ✅ Valide se os agentes não podem acessar dados não autorizados, realizar ações não autorizadas e que a injeção de prompt não pode escalar privilégios | | Plataforma \| CI/CD | ✅ Integre a verificação de segurança ao pipeline de implementação usando o Salesforce Code Analyzer e ferramentas de segurança de IA especializadas | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Agentforce \| Configuração do agente | ⚡️ Testar agentes para a correspondência exata de texto em saídas não determinísticas em vez de testar características de saída | | Plataforma \| Teste de desempenho | Teste somente com cenários de usuário único, problemas de limite do regulador ausentes, restrições de recurso e gargalos de escalabilidade | | Agentforce \| Configuração do agente | ⚡️ Ignorar testes de segurança ou fazer os desenvolvedores testarem seus próprios agentes sem uma nova perspectiva sobre vulnerabilidades | | Plataforma \| Segurança | ⚡️ Não testar se a injeção de prompt pode escalar os privilégios do agente ou acessar dados não autorizados | | Agentforce \| Configuração do agente | ⚡️ Ter conjuntos de teste estáticos que não representam diversidade de uso real, incluindo diferentes tipos de usuário e complexidades de conversa | ## Gerenciamento de mudanças **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Documentação | ✅ Documente todas as alterações: o que mudou, por quê, qual teste o validou e qual procedimento de reversão existe | | Negócios \| Comunicação | ✅ Notifique todas as partes interessadas (usuários, equipes de operações, suporte, negócios) descrevendo o que está mudando, quando, quais benefícios, quais riscos e quem contatar | | Negócios \| Comunicação | ✅ Estabelecer modelos de comunicação para diferentes tipos de alteração padronizando mensagens e reduzindo a sobrecarga de preparação | | Plataforma \| Monitoramento de evento | ✅ Implantações do agente de tempo durante períodos de uso baixo informadas por dados de Monitoramento de evento mostrando padrões de uso reais | | Negócios \| Processo | ✅ Implementar alterações importantes do agente no início da semana, evitando fins de semana com capacidade reduzida de resposta a incidentes | | Negócios \| Processo | ✅ Estabelecer períodos de congelamento de alteração antes de grandes eventos de negócios (fim do ano fiscal, lançamentos de produtos, campanhas de marketing importantes) | | Negócios \| Processo | ✅ Calendário de congelamento de alteração de documento comunicando anualmente períodos restritos com antecedência suficiente | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Implantação | ⚡️ Implantação durante uso de pico, fechamento de fim de mês, fechamento de fim de trimestre ou eventos comerciais importantes | | Plataforma \| Implantação | ⚡️ Implantação em segundas-feiras (aprimoramento) ou sextas-feiras (equipe reduzida) quando a capacidade de resposta a incidentes estiver limitada | | Negócios \| Processo | ⚡️ Ter alterações excessivas congela a velocidade de melhoria sem redução proporcional do risco | | Negócios \| Comunicação | Implementar alterações de agente sem notificar usuários afetados, equipes de operações, equipes de suporte ou partes interessadas de negócios | | Plataforma \| Documentação | ⚡️ Fazer alterações sem justificar a documentação, criando organizações que descobrem novamente lições em vez de se basearem na experiência | ## Arquitetura de loop de feedback **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| UI | ✅ Implemente a coleta de feedback na interface do usuário da conversa habilitando a resposta imediata enquanto a interação está atualizada em vez de atrasada na coleta | | Plataforma \| Analytics | ✅ Registros de conversas de consulta analisando tipos de pergunta, durações da conversa, taxas de sucesso por tópico e satisfação do usuário por características da conversa | | Plataforma \| Analytics | ✅ Analisar o agrupamento de registros de erro por tipo de erro, usuários afetados, padrões de conversa e distribuição temporal para revelar problemas sistemáticos | | Plataforma \| Analytics | ✅ Priorizar a remoção de erros por frequência e impacto: erros de alta frequência que afetam muitos usuários exigem atenção imediata | | Plataforma \| Monitoramento | ✅ Estabelecer linhas de base de qualidade após a implantação inicial e monitorar a qualidade contínua em relação ao alerta de linhas de base quando as tendências diminuírem | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| UI | Adiar a coleta de feedback (por exemplo, emails de acompanhamento dias depois) reduzindo as taxas de resposta e introduzindo o viés de recall | | Plataforma \| Analytics | ⚡️ Não analisar padrões de uso para determinar se os agentes justificam a complexidade operacional ou se os recursos estão subutilizados | | Plataforma \| Analytics | ⚡️ Tratar todos os erros igualmente, em vez de priorizar por frequência e impacto comercial | | Plataforma \| Monitoramento | ⚡️ Tomar decisões de melhoria sem dados, sem linhas de base de qualidade e monitoramento de tendência | ## Rastreamento de experiências **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Negócios \| Processo | ✅ Forneça uma estrutura de experimentos consistente: hipótese, design experimental, métricas, tamanho da amostra e critérios de sucesso | | Negócios \| Processo | ✅ Documentar experiências antes da execução, evitando interpretação ambígua dos resultados | | Plataforma \| Analytics | ✅ Acompanhe a atribuição da variante nos metadados da conversa habilitando a correlação de resultados por variante | | Plataforma \| Analytics | ✅ Calcule o tamanho da amostra necessário antes de realizar experiências com base no tamanho do efeito esperado, na potência estatística e nas taxas de erro aceitáveis | | Plataforma \| Analytics | ✅ Use a otimização de bandido multifator para alocar dinamicamente mais tráfego a variantes com melhor desempenho, reduzindo o custo da oportunidade | | Plataforma \| Documentação | ✅ Mantenha o catálogo de experiências com variantes testadas, resultados medidos, resultados alcançados e decisões tomadas para evitar o reteste de abordagens com falha | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Negócios \| Processo | Executar experiências sem hipóteses predefinidas e critérios de sucesso que levam a resultados ambíguos | | Plataforma \| Analytics | ⚡️ Usar tamanhos de amostra insuficientes produzindo resultados ruidosos que levam a decisões de melhoria ruins | | Plataforma \| Documentação | ⚡️ Não ter um catálogo de experimentos, fazendo com que as equipes testem novamente abordagens com falha anteriormente e perdem o Knowledge organizacional | | Plataforma \| Analytics | ⚡️ Não rastrear quais usuários receberam quais variantes, impossibilitando a correlação de resultados | # Excelência operacional – Padrões de automação
Saiba mais sobre a [excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) bem projetada → [Automação e eficiência](/docs/architect/pt-br/well-architected/guide/operational-excellence.html#automation-and-efficiency) ## KPIs e métricas **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Painéis | ✅ Todas as métricas relacionadas a KPIs estão incluídas em pelo menos um painel | | Plataforma \| Documentação | ✅ Saídas para cada automação são mensuráveis e temporizadas | | Plataforma \| Documentação | ✅ Partes interessadas responsáveis são listadas para cada KPI | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Painéis | ⚡️ O relatório de KPI não existe ou os painéis estão sem métricas relacionadas a alguns KPIs | | Plataforma \| Documentação | ⚡️ Há KPIs sem partes interessadas responsáveis | | Plataforma \| Documentação | ⚡️ Os KPIs não existem para automações ou têm períodos de tempo imprecisos para medidas | ## Automação declarativa **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Fluxo | ✅ O Flow Builder é usado para automação acionada por registro (substituindo o Criador de processos e as Regras de fluxo de trabalho) | | Plataforma \| Fluxo | ✅ Fluxos acionados por registro com execução antes de salvar são usados para preenchimento de campo antes da criação do registro | | Plataforma \| Fluxo | ✅ Os fluxos lidam com lógica de decisão, loops, chamadas à API, operações DML e orquestração complexa de várias etapas | | Plataforma \| Fluxo | ✅ O controle de transação de fluxo é usado para confirmar alterações intermediárias quando necessário | | Plataforma \| Fluxo | ✅ O tratamento de falhas é implementado para uma boa recuperação de erros em fluxos | | Plataforma \| Fluxo | ✅ Fluxos de tela reativos proporcionam experiências de usuário dinâmicas | | Plataforma \| Fluxo | ✅ Automação declarativa é escolhida quando usuários comerciais ou administradores precisam modificar a lógica sem o envolvimento do desenvolvedor | | Plataforma \| Fluxo | ✅ Variáveis não se referem a valores embutidos em código (para tipos de registro, usuários etc.) | | Plataforma \| Fluxo | ✅ Lógica manual de fluxos para Apex em contextos de grande volume de dados | | Plataforma \| Fluxo | ✅ Os subfluxos são usados para seções de processos que precisam ser reutilizadas em todo o negócio | | Plataforma \| Fluxo | ✅ Todos os fluxos iniciados automaticamente usam elementos de decisão e/ou pausa para avaliar critérios de entrada e evitar loops ou execuções infinitas em grandes volumes de dados | | Plataforma \| Fluxo | ✅ Os usuários são solicitados a fornecer dados apenas quando os dados do sistema existentes não puderem ser usados | | Plataforma \| Fluxo | ✅ Os fluxos são organizados em uma estrutura hierárquica que consiste em um fluxo principal e subfluxos de suporte | | Plataforma \| Fluxo | ✅ Todas as entradas do usuário têm um propósito claro no fluxo | | Plataforma \| Fluxo | ✅ Cada fluxo atende a uma única finalidade específica | | Plataforma \| Fluxo | ✅ Cada etapa realiza uma tarefa granular específica | | Plataforma \| Fluxo | ✅ Todos os fluxos iniciados no contexto do usuário abstraem transações de contexto do sistema para subfluxos, colocadas de modo consistente após o elemento Pausar para criar nova transação | | Plataforma \| Fluxo | ✅ Todos os fluxos acionados por registro têm valores de ordem do acionador preenchidos | | Plataforma \| Fluxo | ✅ Fluxos que envolvem chamadas do sistema externo ou processos de execução longa usam caminhos assíncronos | | Plataforma \| Fluxo | ✅ Sequências complexas de operações de dados relacionadas são criadas com o Orquestrador (em vez de invocar vários subfluxos em um fluxo monolítico) | | Plataforma \| Validação | ✅ A integridade de dados é imposta no nível da plataforma usando regras de validação, regras de duplicados e campos obrigatórios | | Plataforma \| Validação | ✅ Regras de validação impedem a entrada de dados inválidos antes de salvar (mais eficiente do que a validação de acionador) | | Plataforma \| Processos de aprovação | ✅ O roteamento de aprovação de várias etapas lida com caminhos de aprovação paralelos e sequenciais com aprovadores delegados | | Plataforma \| Processos de aprovação | ✅ A arquitetura de aprovação considera cenários de exceção (todos os aprovadores em férias, exigência de negócios urgente ignorando a aprovação normal) | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Fluxo | ⚡️ Criador de processos e regras de fluxo de trabalho usadas para nova automação (o Flow Builder é a direção estratégica) | | Plataforma \| Fluxo | Automação programática usada quando usuários de negócios ou administradores precisam modificar a lógica sem o envolvimento do desenvolvedor | | Plataforma \| Fluxo | Fluxos carecem de tratamento de falha, resultando em má recuperação de erros | | Plataforma \| Fluxo | ⚡️ As variáveis têm valores embutidos em código | | Plataforma \| Fluxo | ⚡️ Os fluxos devem ser desativados manualmente antes do carregamento de dados em massa | | Plataforma \| Fluxo | ⚡️ Partes de um fluxo são repetidas entre fluxos em vez de usar subfluxos | | Plataforma \| Fluxo | Fluxos acionam avisos de "exceção não tratada" | | Plataforma \| Fluxo | ⚡️ Mesmo fluxos simples geralmente causam erros relacionados aos limites do regulador | | Plataforma \| Fluxo | Fluxos exigem entradas adicionais para fornecer contexto | | Plataforma \| Fluxo | Fluxos atendem a várias finalidades | | Plataforma \| Fluxo | Grupos de etapas relacionadas contêm funcionalidade que se sobrepõe a grupos de etapas em outros fluxos | | Plataforma \| Fluxo | ⚡️ Os fluxos solicitam entradas do usuário quando os dados armazenados podem ser usados | | Plataforma \| Fluxo | Fluxos exigem entradas cujos dados não são usados | | Plataforma \| Fluxo | ⚡️ Realizar DML usando a coleção que é gerada do componente de tela (utilizando a configuração "Usar os IDs e todos os valores de campo de um registro ou coleção de registros" ao criar, atualizar ou excluir o elemento quando a coleção é gerada do componente de tela) | | Plataforma \| Fluxo | Fluxos acionados por registro não usam atributos de ordem de acionador ou não usam valores de ordem de acionador de modo consistente | | Plataforma \| Fluxo | ⚡️ Caminhos assíncronos não usados de modo consistente ou de modo algum | | Plataforma \| Fluxo | Fluxos grandes e monolíticos tentam coordenar sequências complexas de operações de dados relacionadas (com ou sem subfluxos) | | Plataforma \| Processos de aprovação | ⚡️ A arquitetura de aprovação não considera cenários de exceção (todos os aprovadores em férias, requisitos de negócios urgentes) | | Plataforma \| Validação | Integridade de dados imposta apenas em acionadores em vez de regras de validação (a validação do acionador é menos eficiente e mais complexa) | ## Automação programática **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Apex | ✅ A estrutura do manipulador do acionador impõe acionador único por objeto, massificação, separação de preocupações e prevenção de execução recursiva | | Plataforma \| Apex | ✅ Acione manipuladores delegados a classes de serviço para lógica de negócios, mantendo uma separação clara das preocupações | | Plataforma \| Apex | ✅ Os acionadores usam proteção contra recursão usando sinalizadores estáticos ou classe de controle de recursão dedicada | | Plataforma \| Apex | ✅ Futuro Apex é usado com moderação, para chamadas ou DML de objeto do sistema | | Plataforma \| Apex | ✅ As invocações assíncronas do Apex usam DML complexo enfileirável para 'corrente' em transações | | Plataforma \| Apex | ✅ O Apex em lote é usado para grandes volumes de dados (processam grandes quantidades de dados com limites de regulador dedicados por bloco) | | Plataforma \| Apex | ✅ Os trabalhos em lote têm o tratamento de erros que registra registros com falha sem interromper toda a execução do lote | | Plataforma \| Apex | ✅ A API em massa é usada apenas quando grandes quantidades de dados precisam ser processadas (APIs SOAP e REST nativas aproveitadas para quantidades menores de dados) | | Plataforma \| Apex | ✅ O Apex enfileirável é usado para orquestração de fluxo de trabalho complexo, chamadas externas com lógica de repetição e processamento que se beneficia de limites assíncronos | | Plataforma \| Apex | ✅ O Apex agendado executa o processamento em agendas fixas para manutenção noturna, relatórios diários, sincronização de integração periódica e regras de negócios baseadas em tempo | | Plataforma \| Padrões de design | ✅ Casos de uso para operações síncronas e assíncronas em automações são descritos claramente como parte dos padrões de design | | Plataforma \| Documentação | ✅ Caminhos de execução planejados e em potencial para automações são descritos claramente | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Apex | ⚡️ Vários acionadores em um objeto com ordem de execução imprevisível e lógica sobreposta | | Plataforma \| Apex | ⚡️ Lógica de negócios integrada diretamente em arquivos de acionador, dificultando o teste | | Plataforma \| Apex | ⚡️ Nenhuma estrutura de manipulador de acionador ou padrões de acionador inconsistentes entre objetos | | Plataforma \| Apex | Os trabalhos do Apex em lote têm um tamanho de escopo muito pequeno (por exemplo, tamanho de escopo = 1) | | Plataforma \| Apex | Apex em lote usado para chamadas externas (grandes volumes de dados do Salesforce enviados para um sistema externo usando o Apex em lote) | | Plataforma \| Apex | Recursos do Apex assíncronos usados arbitrariamente (Métodos futuros e Apex enfileirável usados de forma inconsistente ou intercambiável) | | Plataforma \| Apex | Apex assíncrono raramente usado | | Plataforma \| Apex | Operações de banco de dados não têm lógica clara e consistente para passar a execução para o Apex em lote quando necessário | | Plataforma \| Padrões de design | ⚡️ Casos de uso para operações síncronas e assíncronas não são tratados | | Plataforma \| Documentação | A invocação de automação não está documentada | ## Eventos de plataforma **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Eventos de plataforma | ✅ Os eventos de plataforma são usados para automação conduzida por evento que separa editores dos assinantes | | Plataforma \| Eventos de plataforma | ✅ Os editores não estão cientes dos assinantes e publicam o fire-and-forget | | Plataforma \| Eventos de plataforma | ✅ Vários assinantes reagem de forma independente a eventos por meio de fluxos acionados por evento de plataforma, acionadores do Apex ou integrações externas | | Plataforma \| Eventos de plataforma | ✅ IDs de reprodução são usados para reproduzir eventos perdidos de qualquer ponto na janela de retenção de 72 horas | | Plataforma \| Eventos de plataforma | ✅ Eventos de plataforma habilitam comunicação entre organizações, notificação do sistema externo e orquestração de fluxo de trabalho interno | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Eventos de plataforma | Cópia direta entre editores e assinantes, impedindo a automação composível | | Plataforma \| Eventos de plataforma | A atualização do nível da conta chama diretamente a atualização da oportunidade, a notificação da equipe da conta e a sincronização do armazém de dados em uma transação (o acoplamento rígido exige alterações na lógica da conta sempre que um novo processamento downstream for necessário) | | Plataforma \| Apex | ⚡️ Publicar eventos de plataforma imediatamente usado adhoc (eventos em tempo real usados em vez de Publicar após confirmação, independentemente dos requisitos de pedido de publicação ou riscos de bloqueio de registro) | ## Padrões de desenvolvimento do Apex **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Apex | ✅ As instruções SOQL usam operadores de comparação de lógica positiva (`INCLUDES`, `IN`) como lógica primária ou única | | Plataforma \| Apex | ✅ SOQL evita `= NULL`, `!= NULL` ou usa-os com moderação após operadores de comparação positivos | | Plataforma \| Apex | ✅ SOQL não usa instruções de `LIMIT 1` | | Plataforma \| Apex | ✅ SOQL não usa palavra-chave `ALL ROWS` | | Plataforma \| Apex | ✅ SOQL não aparece em loops | | Plataforma \| Apex | ✅ Critérios de curinga aparecem em SOSL (não SOQL) | | Plataforma \| Apex | ✅ As instruções SOQL evitam comparações de `LIKE` ou comparações parciais de texto | | Plataforma \| Apex | ✅ SOQL é agrupado em blocos de `try-catch` | | Plataforma \| Apex | ✅ Variáveis não se referem a valores embutidos em código (para tipos de registro, usuários etc.) | | Plataforma \| Apex | ✅ Cada classe atende a um único propósito específico | | Plataforma \| Apex | ✅ Cada método realiza uma tarefa granular específica | | Plataforma \| Apex | ✅ Todas as variáveis de entrada têm um propósito claro dentro da classe | | Plataforma \| Apex | ✅ A execução de código requer um número mínimo de recursos | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Apex | As instruções SOQL usam `NOT`, critérios de `NOT IN` como principal ou único operador de comparação (não seletivo) | | Plataforma \| Apex | ⚡️ As instruções SOQL usam palavra-chave `ALL ROWS` (não seletiva) | | Plataforma \| Apex | As instruções SOQL usam `= NULL`, critérios de `!= NULL` como principal ou único operador de comparação (não seletivo) | | Plataforma \| Apex | ⚡️ As variáveis têm valores embutidos em código | | Plataforma \| Apex | ⚡️ SOQL aparece dentro de loops | | Plataforma \| Apex | As instruções SOQL usam critérios de filtro de curinga e `LIKE` com frequência (não seletivo) | | Plataforma \| Apex | ⚡️ SOQL não encapsulado em blocos de `try-catch` | | Plataforma \| Apex | ⚡️ As instruções SOQL usam `LIMIT 1` (não seletivo) | | Plataforma \| Apex | ⚡️ SOSL raramente ou não é usado de modo consistente para critérios de seleção de curinga | | Plataforma \| Apex | ⚡️ As classes têm várias finalidades | | Plataforma \| Apex | Métodos realizam várias tarefas ou métodos realizam tarefas que não estão alinhadas ao propósito declarado da classe da qual fazem parte | | Plataforma \| Apex | As variáveis de entrada não são, na verdade, usadas em métodos | | Plataforma \| Apex | Métodos que recuperam dados desnecessariamente do banco de dados ou de sistemas externos | ## Manipulação de erros **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Apex | ✅ Exceções personalizadas são usadas para criar mensagens de erro avançadas e lógica | | Plataforma \| Apex | ✅ O código engloba todas as etapas de DML, SOQL, chamadas e outros processos críticos em blocos de `try-catch` | | Plataforma \| Apex | ✅ Os métodos de classe de banco de dados podem ser usados exclusivamente para todas as operações de dados (em vez de DML) | | Plataforma \| Apex | ✅ Em contextos assíncronos e em massa, métodos de classe de banco de dados são usados em vez de DML | | Plataforma \| Aura | ✅ JavaScript engloba todas as operações de dados e etapas críticas do processo em blocos de `try-catch` | | Plataforma \| Aura | ✅ Dentro de blocos de `try-catch`, `Error` JavaScript nativo é usado em instruções de tiro (sem uso de `$A.error()`) | | Plataforma \| Aura | ✅ Todas as lógicas de erro recuperáveis aparecem nas instruções de `catch` e fornecem mensagens claras do usuário | | Plataforma \| Fluxo | ✅ Fluxos com operações de dados, chamadas e outra lógica de processamento crítica têm caminhos de falha para todas as ações-chave | | Plataforma \| Fluxo | ✅ Fluxos de tela usam consistentemente conectores de falha para mostrar erros aos usuários | | Plataforma \| Fluxo | ✅ Mensagens de erro personalizadas são configuradas para erros que aparecerão na tela | | Plataforma \| Componentes da Web Lightning (LWC) | ✅ JavaScript engloba todas as operações de dados e etapas críticas do processo em blocos `if ()`/`else if ()` | | Plataforma \| Componentes da Web Lightning (LWC) | ✅ Todas as funções de `@wire` usam propriedades de `data` e `error` fornecidas pela API | | Plataforma \| Componentes da Web Lightning (LWC) | ✅ Todas as instruções `if (error)`/`else if (error)` contêm lógica para processar erros e fornecer mensagens informativas | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Apex | ⚡️ DML, SOQL, chamadas ou outras etapas do processo críticas não colocadas consistentemente em blocos de captura de teste | | Plataforma \| Apex | ⚡️ Nenhum método de classe de banco de dados é usado | | Plataforma \| Apex | ⚡️ Operações de dados feitas exclusivamente com DML | | Plataforma \| Apex | As declarações de `System.debug` aparecem no código de produção (e não são comentadas) | | Plataforma \| Aura | ⚡️ O JavaScript não engloba consistentemente operações de dados e etapas críticas do processo em blocos de `try-catch` | | Plataforma \| Aura | Componentes usam `$A.error()` | | Plataforma \| Aura | ⚡️ Lógica de erro recuperável não aparece consistentemente nas instruções de `catch`, e as mensagens de erro para os usuários não estão claras | | Plataforma \| Fluxo | ⚡️ Os fluxos não usam caminhos de falha de modo consistente ou de modo algum | | Plataforma \| Fluxo | ⚡️ Mensagens de erro personalizadas não usadas, portanto, os usuários veem a mensagem padrão "Uma falha não tratada ocorreu nesse fluxo" | | Plataforma \| Componentes da Web Lightning (LWC) | Funções de `@wire` não usam propriedades de `data` e `error` fornecidas pela API (ou não as usam de forma consistente) | | Plataforma \| Componentes da Web Lightning (LWC) | ⚡️ Se usado, as instruções `if (error)`/`else if (error)` na verdade não contêm lógica para processar erros e fornecer mensagens úteis de erro | | Plataforma \| Componentes da Web Lightning (LWC) | O JavaScript não usa consistentemente blocos `if ()`/`else if ()` com operações de dados ou etapas críticas do processo | # Excelência operacional – Padrões de DevOps
Saiba mais sobre uma [excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) bem arquitetada → [Práticas DevOps](/docs/architect/pt-br/well-architected/guide/operational-excellence.html#devops-practices) ## Desenvolvimento conduzido por origem **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Configuração do controle de versão | ✅ Todos os metadados armazenados no formato de origem Git usando a estrutura de projeto Salesforce DX com .forceignore configurado para excluir arquivos irrelevantes; todos os membros da equipe clonam do repositório central | | Uso da organização teste | ✅ Os desenvolvedores criam organizações teste efetivas da origem para trabalho de recurso, confirmam alterações de volta ao controle de versão e descartam organizações teste após a conclusão do recurso | | Confirmar mensagens | ✅ Cada confirmação inclui uma mensagem clara e concisa explicando o que mudou e por quê; as mensagens seguem a convenção da equipe (por exemplo, "feat:", "fix:", "docs:") | | Rastreamento de alteração | ✅ Cada modificação de metadados capturada no controle de versão com identidade do autor, carimbo de data e hora e dif mostrando alterações exatas | | Processo de revisão de código | ✅ Todas as alterações vinculadas à produção fluem por meio de solicitações de pull que exigem aprovação de revisão antes da mesclagem; a configuração declarativa recebe a mesma análise do código | | Procedimentos de reversão | ✅ Versões anteriores recuperáveis do histórico do Git por meio de operações de checkout ou reversão; a equipe tem procedimentos de reversão documentados testados em não produção | | Trilha de auditoria | ✅ Histórico de alterações concluído preservado no controle de versão com suporte a requisitos de conformidade e investigações de segurança | | Estratégia de ramificação | ✅ Modelo de ramificação do Git consistente (GitFlow, GitHub Flow ou baseado em trunk) adequado ao tamanho da equipe e à frequência de lançamento; documentado e imposto | | Migração baseada em organização | ✅ Transição para o desenvolvimento orientado por origem concluído logo no início do ciclo de vida da solução antes de os hábitos se solidificarem em relação ao desenvolvimento baseado em organização | | Configuração .gitignore | ✅ O repositório exclui arquivos gerados, configurações específicas do usuário e credenciais; inclui apenas os arquivos de origem das equipes que pretendem obter a versão | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Organização como fonte da verdade | ⚡️ O desenvolvimento ocorre diretamente em sandboxes compartilhados com metadados exportados para o controle de versão conforme pensado; organizações e controle de versão divergem, criando falhas de implementação | | .gitignore inadequado | ⚡️ O repositório inclui arquivos gerados, configurações específicas do usuário, binários grandes ou credenciais; aumenta o repositório e arrisca a exposição de segurança | | Mensagens de confirmação vagas | Confirmações como "corrigir bug" ou "atualizações" não fornecem contexto para o que mudou ou por quê; impede investigações de auditoria e manutenção futuras | | Confirmações insuficientes grandes | ⚡️ Os desenvolvedores confirmam grandes conjuntos de alterações semanalmente em vez de pequenas confirmações incrementais várias vezes por dia; difícil de revisar, difícil de isolar falhas | | Confirmar diretamente no principal | ⚡️ Os desenvolvedores enviam alterações diretamente para a agência principal/produção ignorando revisão e validação; elimina portões de qualidade | | Sem estratégia de ramificação | ⚡️ A equipe não tem um modelo de ramificação consistente; os desenvolvedores criam nomes de ramificação arbitrários e padrões de mesclagem; cria confusão e conflitos de mesclagem | | Arquivos binários no Git | ⚡️ Arquivos binários grandes (PDFs, vídeos, arquivos) confirmados no Git aumentando o tamanho do repositório e desacelerando as operações de clonagem | | Confirmação de credenciais | Chaves de API, senhas, credenciais de integração ou tokens de segurança confirmados no controle de versão; cria uma vulnerabilidade de segurança mesmo após a remoção de confirmações posteriores | | Ignorar conflitos de mesclagem | ⚡️ Conflictos de mesclagem resolvidos aceitando uma parte sem análise; perde alterações ou introduz bugs | | Nenhuma verificação de confirmação | ⚡️ A equipe nunca verifica se os metadados confirmados representam de fato as alterações pretendidas; erros de formato de metadados ou alterações indesejadas são ignorados | ## Estratégia de sandbox **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Sandboxes do desenvolvedor | ✅ Desenvolvedores individuais usam sandboxes de Desenvolvedor para trabalho de recursos, teste de unidade e iteração rápida; cada desenvolvedor tem um ambiente dedicado | | Sandboxes Developer Pro | ✅ Equipes que desenvolvem pacotes gerenciados ou exigem limites de armazenamento mais altos usam sandboxes Developer Pro para trabalho colaborativo | | Sandboxes de Cópia parcial | ✅ O teste de integração usa sandboxes de Cópia parcial com amostras de dados representativas (10.000 registros por objeto) configuradas por meio de modelos de dados | | Sandboxes de Cópia completa | ✅ Teste de desempenho, preparação semelhante à produção e validação de migração de dados usam sandboxes de Cópia total contendo dados e ajustes de produção completos | | Controles de confidencialidade de dados | ✅ Acesso ao sandbox de cópia completa restrito a papéis que exigem dados de produção; mascaramento de dados da Shield Platform Encryption aplicado para uso não de produção quando apropriado | | Configuração do ponto de extremidade de integração | ✅ Cada nível de sandbox se conecta a pontos de extremidade de teste correspondentes para integrações externas; as integrações de produção nunca se conectam de sandboxes | | Configuração específica do ambiente | ✅ A arquitetura de integração usa tipos de metadados personalizados ou configurações personalizadas para externalizar URLs de ponto de extremidade, credenciais e sinalizadores de recurso por ambiente | | Automação pós-atualização | ✅ Atualizações de sandbox acionam scripts automatizados do Salesforce CLI restaurando configurações específicas do sandbox, incluindo credenciais de integração, sementeamento de dados de teste, estados de sinalizador de recurso e capacidade de entrega de email | | Atualizar agendamento | ✅ Agenda de atualização de sandbox documentada e comunicada; atualizações planejadas durante períodos de baixa atividade para minimizar interrupções da equipe | | Modelos de dados | ✅ Sandboxes de Cópia parcial usam modelos de dados bem projetados selecionando dados representativos entre objetos mantendo a integridade referencial | | Convenções de nomenclatura | ✅ Os sandboxes seguem uma convenção de nomenclatura clara indicando a finalidade, o proprietário e o ciclo de atualização (por exemplo, "dev-integration-q2", "uat-release-2-4") | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Sandbox de desenvolvimento compartilhado | ⚡️ Todos os desenvolvedores trabalham em um único sandbox compartilhado substituindo as alterações uns dos outros; cria confusão sobre o que é o estado implantável | | Sandboxes obsoletos | Sandboxes não atualizados por meses divergem significativamente da configuração de produção; testes em ambiente não representativo levam a falhas de implementação | | Sem governança de dados em cópia completa | Sandboxes de Cópia completa contendo PII de produção, dados financeiros e dados HIPAA acessíveis a toda a equipe de desenvolvimento sem controles de acesso ou mascaramento de dados | | Integrações de produção do sandbox | ⚡️ Os sandboxes se conectam diretamente a pontos de extremidade de integração de produção criando o risco de transações de teste afetando dados de produção ou sistemas externos | | Configuração pós-atualização manual | As atualizações de sandbox exigem horas de configurações de restauração de reconfiguração manual; a sobrecarga impede a atualização de sandboxes com a frequência necessária | | Sem documentação de sandbox | ⚡️ A equipe não tem documentação sobre propósitos de sandbox, agendas de atualização, conteúdo de dados ou procedimentos de acesso; os desenvolvedores adivinham qual ambiente usar para qual finalidade | | Tipo de ambiente único | ⚡️ A equipe usa apenas um tipo de sandbox (geralmente Developer ou Full Copy) para todos os fins; perde os benefícios da estratégia de sandbox adequada por atividade | | Agrupamento de sandbox | ⚡️ Sandboxes alocados a indivíduos ou projetos e nunca liberados quando não são mais necessários; escassez artificial, apesar das licenças disponíveis | | Dados de teste inadequados | Dados de teste em sandboxes não representam características de dados de produção (volumes, relacionamentos, casos de extremidade); testes em ambientes irrealistas ignoram problemas de produção | ## Pipelines CI/CD **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Estágio de confirmação de origem | ✅ Os desenvolvedores confirmam alterações em ramificações de recursos no Git com mensagens de confirmação claras explicando o contexto e a racionalidade | | Estágio da análise estática | ✅ O Salesforce Code Analyzer verifica o Apex quanto a vulnerabilidades de segurança (Top 10 do OASP), antipadrões de desempenho (SOQL em loops, DML em loops), problemas de qualidade de código (complexidade, duplicação) e riscos de limite do regulador; é executado em segundos fornecendo feedback imediato | | Estágio de teste de unidade | ✅ Testes do Apex executam a validação da lógica de negócios e da conformidade do limite do regulador na organização teste efetiva ou no sandbox de integração dedicado; testes adequadamente isolados são concluídos em menos de 5 minutos | | Estágio de implementação de validação | ✅ Implantação de metadados em sandbox de integração usando o Salesforce CLI com sinalizador --checkonly para testes de execução de implementação somente validação sem confirmação de alterações | | Estágio de teste de integração | ✅ Testes automatizados validam fluxos de trabalho de vários componentes, contratos de integração externos, fluxos de evento de plataforma e cadeias de processamento assíncronas em relação ao ambiente de integração compartilhado com o gerenciamento de dados de teste | | Estágio de verificação de segurança | ✅ Ferramentas de segurança adicionais verificam credenciais embutidas em código, dependências vulneráveis, violações de CRUD/FLS e violações de política de conformidade; descobertas críticas quebram compilações | | Estágio de implantação de UAT | ✅ Alterações que passam todos os portões automatizados para o ambiente de teste de aceitação do usuário para validação de negócios; a implementação pode ser automatizada ou exigir aprovação manual com base no risco de alteração | | Estágio de implantação de produção | ✅ Após a aprovação de UAT, as alterações são implementadas na produção com execução automatizada com um clique, registro abrangente e capacidade de reversão imediata | | Tempo de execução do pipeline | ✅ O pipeline de ponta a ponta é concluído em menos de 15 minutos para alterações típicas que permitem feedback rápido; mais tempo para implantações grandes ou pacotes de teste extensos | | Criar artefatos | ✅ O pipeline preserva pacotes de implementação, resultados de teste, relatórios de verificação de segurança e registros de execução para conformidade e solução de problemas | | Ferramentas de pipeline | ✅ As equipes usam o Salesforce DevOps Center para CI/CD nativo da plataforma ou se integram a plataformas externas (Ações do GitHub, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) | | Notificações de falha | ✅ Falhas de pipeline acionam notificações para autenticar autor e canais relevantes com contexto de diagnóstico que habilita a correção rápida | | Proteção de ramificação | ✅ Ramificações principais/de produção protegidas exigindo aprovação de verificações de CI e revisões antes da mesclagem; confirmações diretas impedidas | | Promoção ambiental | ✅ Alterações fluem pelo caminho de promoção definido (dev → integração → UAT → produção) com validação em cada estágio | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Implantações manuais | Alterações implementadas manualmente por meio de conjuntos de alterações ou comandos do Salesforce CLI com etapas inconsistentes; erros humanos, etapas perdidas, falta de trilha de auditoria | | Nenhuma análise estática | ⚡️ Pipelines ignoram o Salesforce Code Analyzer ou ferramentas semelhantes; vulnerabilidades de segurança, antipadrões de desempenho, problemas de qualidade de código chegam à produção | | Teste insuficiente | ⚡️ O pipeline valida apenas uma cobertura mínima de 75% sem executar testes de integração ou validar os principais fluxos de usuário; as regressões são ignoradas | | Sem verificação de segurança | ⚡️ Os pipelines nunca verificam credenciais embutidas em código, dependências vulneráveis ou violações de CRUD/FLS; problemas de segurança descobertos em revisões de produção ou de segurança | | Execução de pipeline lenta | ⚡️ O pipeline de ponta a ponta leva 45 a 60 minutos, impedindo confirmações frequentes e desacelerando os loops de feedback; os desenvolvedores se comprometem com menos frequência acumulando alterações maiores | | Falhas do pipeline ignoradas | ⚡️ As equipes ignoram ou substituem falhas de pipeline para cumprir prazos; os portões de qualidade se tornam teatro em vez de controles reais | | Sem paridade de ambiente de teste | ⚡️ O CI/CD é validado em um ambiente com configuração, limites ou características de dados diferentes da produção; a aprovação da validação não garante o sucesso da produção | | Funcionalidade de reversão ausente | ⚡️ O pipeline automatiza a implantação, mas não fornece reversão automatizada; a recuperação de uma implantação incorreta requer procedimentos manuais de emergência | | Sem registros de implementação | Implantações executadas sem registro abrangente; a solução de falhas ou a auditoria de implantações se torna difícil | | Teste de tudo ou nada | ⚡️ O pipeline executa todos os testes para cada alteração, não importa o que mudou; um pacote de teste de 30 minutos é executado mesmo para atualizações de documentação | ## Práticas de implantação segura **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Sinalizadores de recurso | ✅ Alterações de alto risco implantadas com recursos desabilitados por trás do tipo de metadados personalizados ou ajustes de configuração personalizada; habilita o teste em produção sem exposição do usuário, distribuição gradual para segmentos, teste A/B e reversão instantânea por meio de alteração de configuração | | Escopo do sinalizador de recurso | ✅ Indicadores de recurso reservados para alterações de alto risco que afetam processos de negócios críticos, operações sensíveis ao desempenho ou novos padrões de integração; nem todos os recursos precisam de indicadores | | Implantações canárias | ✅ Liberação de alterações críticas para os negócios para um pequeno subconjunto de usuários primeiro (5-10% por meio de conjuntos de permissões ou filtragem de atributo de usuário); coorte canária monitorada intensivamente 24-48 horas medindo taxas de sucesso, desempenho e taxas de erro antes de expandir a distribuição | | Janelas de implementação | ✅ Implantações agendadas durante períodos de uso baixo informadas por logs de uso da API de Monitoramento de evento mostrando padrões reais de tráfego; evita uso máximo, fechamento de fim de mês, fechamento de fim de trimestre e eventos comerciais importantes | | Comunicação da implementação | ✅ As partes interessadas recebem notificações antecipadas de janelas de implementação, incluindo duração esperada, funcionalidade afetada e linha do tempo de decisão de reversão | | Procedimentos de reversão | ✅ Procedimentos de reversão documentados e testados para cada tipo de implementação; a equipe pode executar o reversão em menos de 30 minutos quando necessário | | Teste de reversão | ✅ Processos de reversão validados em ambientes que não sejam de produção antes de implantações significativas garantindo a existência da capacidade de recuperação | | Validação da implantação | ✅ Testes de fumaça pós-implementação validam fluxos de usuário críticos, pontos de extremidade de integração e funcionalidade-chave imediatamente após a liberação | | Alteração de coordenação | ✅ Estratégia de implantação coordenada quando as alterações abrangem vários sistemas ou exigem versões sincronizadas entre o Salesforce e plataformas externas | | Monitoramento durante a implantação | ✅ Monitoramento aprimorado ativo durante a janela de implementação e o período de observação pós-implementação (24 a 48 horas) observando picos de taxa de erro, degradação do desempenho ou falhas de fluxo do usuário | | Padrão azul-verde para integrações | ✅ Serviços externos em frente ao Salesforce usam implantações azul-verde mantendo dois ambientes semelhantes a produção, implantando para inativos primeiro, alternando o tráfego após a validação | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Implantações de Big Bang | Versões grandes contendo muitos recursos, refatoramentos e alterações implementados simultaneamente sem distribuição gradual; a falha afeta todos os usuários imediatamente | | Implantações de horário de pico | ⚡️ Versões agendadas durante o horário comercial de pico (meio dia, fim de mês, fim de trimestre) quando o uso é mais alto e o impacto do usuário dos problemas é maximizado | | Sem plano de reversão | As implantações prosseguem sem procedimentos de reversão documentados e testados; quando ocorrem problemas, a equipe trabalha para descobrir a recuperação | | Recurso alterna como pensamento posterior | Sinalizadores de recurso adicionados reativamente quando ocorrem problemas em vez de projetados proativamente para alterações de alto risco; limita as opções de reversão à reversão total da implementação | | Sem validação de implantação | ⚡️ Alterações implementadas na produção sem testes de fumaça pós-implementação; a equipe presume que a implantação foi bem-sucedida e avança; problemas descobertos horas depois pelos usuários | | Procedimentos de reversão não testados | ⚡️ Processos de reversão documentados, mas nunca testados em não produção; durante o incidente real, o procedimento falha ou prova-se inadequado | | Alterações simultâneas de vários sistemas | Alterações coordenadas no Salesforce e em sistemas externos implementadas sem testes de sincronização ou compatibilidade; cria falhas de integração | | Sem aprimoramento de monitoramento | As implantações prosseguem sem monitoramento aprimorado durante a janela de implantação; problemas detectados por meio de reclamações do usuário em vez de alertas proativos | | Implantações de fim de semana | ⚡️ Versões principais implantadas na sexta-feira à noite ou em fins de semana quando a cobertura na chamada é reduzida e a disponibilidade de suporte do fornecedor limitada | ## Estratégia de teste **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Cobertura de teste de unidade | ✅ Cobertura de teste relevante que valida regras de negócios, casos de extremidade, caminhos de erro e abordagem de limite do regulador; excede significativamente 75% do requisito mínimo | | Qualidade do teste de unidade | ✅ Os testes validam a lógica de negócios, não a funcionalidade da plataforma; testes de unidade bem escritos são rápidos (milissegundos), isolados (sem estado compartilhado) e focados (cada teste valida um comportamento) | | Estratégia de testar dados | ✅ Os testes usam métodos @TestSetup para dados de teste comuns; evite consultas SOQL em testes quando possível; use Test.loadData() para carregar recursos estáticos | | Simular dependências externas | ✅ Testes de unidade simulam chamadas externas usando fragmento de teste e injeção de dependência permitindo execução rápida sem solicitações HTTP reais | | Testes de integração | ✅ Valide interações entre acionadores, fluxos, eventos de plataforma, trabalhos em lote e chamadas externas em sandboxes com dados de teste representativos | | Confiabilidade do teste de integração | ✅ Os testes de integração são repetíveis e determinísticos; falhas esporádicas tratadas por meio de mecanismos de sincronização, como IDs de repetição de evento de plataforma e pesquisa de trabalho em lote | | Testes de ponta a ponta | ✅ Testes automatizados do navegador (Selenium, Playwright, Provar) validam jornadas completas do usuário para fluxos críticos para os negócios exercendo o sistema por meio da IU exatamente conforme os usuários interagem | | Foco de teste E2E | ✅ Testes E2E focam caminhos do usuário de maior valor devido à execução mais lenta (minutos por teste) e à maior carga de manutenção resultante de alterações na interface do usuário | | Carregar teste | ✅ Desempenho validado sob cargas de usuário simultâneas e volumes de dados realistas usando serviços de Teste de carregamento do Salesforce ou ferramentas de terceiros; revela problemas de limite do controlador, contenção de bloqueio e degradação de desempenho | | Frequência de carregamento de teste | ✅ Testes de carregamento são executados antes das versões principais e periodicamente (trimestral) para validar o desempenho em 3x a 5x dos volumes de produção atuais | | Pirâmide de teste | ✅ Distribuição de testes equilibrada: muitos testes de unidade (centenas, minutos), menos testes de integração (duzas, minutos), poucos testes E2E (menos de 20 minutos); feedback rápido na base, validação abrangente no topo | | Isolamento de teste | ✅ Os testes não dependem uns dos outros; podem ser executados em qualquer ordem; cada teste deixa o sistema em estado de atualização ou usa @TestSetup para um ponto de partida consistente | | Casos de teste negativos | ✅ Os testes validam o tratamento de erros, a imposição de regras de validação, a imposição de permissões e a degradação adequada sob condições adversas | | Teste de limite do controlador | ✅ Os testes validam especificamente o comportamento se aproximando dos limites do controlador, incluindo limites de consulta SOQL, limites de DML, tempo de CPU, tamanho de heap | | Execução de teste contínuo | ✅ Os testes são executados automaticamente em cada confirmação por meio do pipeline CI/CD; falhas nos testes impedem a implantação em ambientes mais altos | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Testar para cobertura | ⚡️ Testes escritos apenas para atingir a cobertura mínima de 75% sem validar regras de negócios ou casos de ponta; testes que não afirmam nada ou testam caminhos de código triviais | | Testar a funcionalidade da plataforma | Os testes validam se o Salesforce salva registros ou consultas SOQL funcionam em vez de validar a lógica de negócios; desperdiça esforço em garantias de plataforma | | Sem estratégia simulada | ⚡️ Testes de unidade fazem chamadas reais a sistemas externos; os testes são lentos, frágeis em relação à disponibilidade do sistema externo e consomem limites de API | | Falhas de teste esporádicas | ⚡️ Testes são aprovados ou falham de modo imprevisível com base no momento da execução, no estado de dados ou na ordem de execução do teste; as equipes aprendem a ignorar falhas e executar novamente até que os testes sejam aprovados | | Sem teste de integração | Existem apenas testes de unidade; a equipe nunca valida se acionadores, fluxos, eventos de plataforma e trabalhos em lote funcionam corretamente juntos | | Somente teste manual E2E | Fluxos de usuário críticos validados manualmente antes de cada versão; nenhum teste E2E automatizado; regressões descobertas em produção quando o teste manual perde cenários | | Sem teste de carregamento | Desempenho nunca validado sob cargas simultâneas realistas; problemas de limite do controlador, contenção de bloqueio ou degradação de desempenho descobertos na produção | | Testar dependências de dados | Os testes dependem de registros específicos existentes na organização ou presumem uma configuração de usuário específica; interromper quando o sandbox for atualizado ou a configuração mudar | | Nenhum caso de teste negativo | ⚡️ Os testes validam apenas cenários de caminho feliz; nunca testam manipulação de erros, imposição de validação ou verificações de permissão; os modos de falha não são descobertos | | Testes ignorados | ⚡️ Testes com falha não comentados em @isTest e ignorados em vez de corrigidos; o pacote de testes se degrada com o tempo conforme mais testes são ignorados | ## Revisão de código **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Revisar a cobertura | ✅ Todas as alterações vinculadas à produção fluem por revisão de código por meio de solicitações de pull que exigem aprovação antes da mesclagem; inclui Apex, Aura, LWC, Fluxos, regras de validação, conjuntos de permissões, regras de compartilhamento | | Revisar a lista de verificação de critérios | ✅ Lista de verificação explícita que abrange segurança (imposição de CRUD/FLS, validação de entrada), desempenho (massificação, otimização SOQL), conformidade com o limite do regulador (padrões de processamento, prevenção de recursão), capacidade de manutenção (nomeação, documentação, complexidade), cobertura de teste (testes significativos, casos de ponta), consistência arquitetônica (padrões de design, separação de preocupações) | | Revisar limites de tamanho | ✅ Solicitações de pull mantidas abaixo de 400 linhas de alteração relevante permitindo revisão aprofundada; recursos grandes divididos em alterações incrementais menores que podem ser revisadas individualmente e implementadas de modo independente | | Revisar horário | ✅ Revisões concluídas em um dia útil mantendo o impulso de desenvolvimento e fornecendo feedback rápido; revisões atrasadas criam sobrecarga de alternância de contexto | | Verificações pré-visualização automatizadas | ✅ Análise estática, testes de unidade e verificação de segurança são executadas automaticamente antes da análise humana solicitada; verificações automatizadas capturam problemas mecânicos para que os revisores se concentrem no design e na lógica de negócios | | Responsabilidade de revisão distribuída | ✅ Responsabilidade de revisão de código distribuída em toda a equipe, evitando gargalos e compartilhando Knowledge; desenvolvedores júnior revisam código sênior e explicam seu próprio código durante as revisões | | Revisar a qualidade dos comentários | ✅ Os revisores fornecem feedback específico e acionável com raciocínio; distinguir entre alterações necessárias (bloco de problemas) e sugestões (melhorias recomendáveis) | | Revisar a documentação | ✅ As descrições da solicitação de pull explicam o que mudou, por que mudou, quais testes foram feitos e quaisquer considerações especiais de implantação ou procedimentos de reversão | | Revisão de configuração declarativa | ✅ Fluxos, regras de validação e alterações de permissão recebem a mesma rigor de análise do código; a configuração é arquitetônica e merece análise | | Acompanhamento em comentários | ✅ Todos os comentários de revisão tratados antes da mesclagem; perguntas respondidas, alterações implementadas ou raciocínio fornecido para o motivo pelo qual a sugestão não foi adotada | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Sem revisão de código | ⚡️ Alterações confirmadas diretamente na agência de produção sem revisão por pares; elimina o mecanismo de detecção de defeito primário | | Carimbo de borracha | ⚡️ Os revisores aprovam solicitações de pull em segundos sem realmente examinar as alterações; a revisão se torna conformidade com a caixa de seleção em vez de um gate de qualidade | | Lacuna de garrafa de Revisor único | ⚡️ Apenas um desenvolvedor sênior autorizado a revisar o código; cria gargalos e ponto único de falha; Knowledge concentrado em vez de distribuído | | Solicitações de pull em massa | ⚡️ Solicitações de pull contendo milhares de linhas de alterações abrangendo vários recursos; impossível revisar completamente, levando a um exame superficial | | Revisões atrasadas | ⚡️ As solicitações de pull ficam sem revisar por dias ou semanas; os desenvolvedores perdem o contexto e mudam para outro trabalho; os comentários de revisão chegam quando o desenvolvedor mudou de contexto mental | | Sem critérios de revisão | ⚡️ A equipe não tem critérios explícitos para o que os revisores devem examinar; a qualidade da revisão varia muito de acordo com o revisor; alguns revisores se concentram no estilo, outros na lógica, nenhum abrangente | | Revisar sem testar | ⚡️ Revisores aprovam alterações com base apenas na inspeção de código sem puxar ramificação e testar localmente ou validar a passagem de testes automatizados | | Verificações automatizadas ignoradas | ⚡️ Revisores aprovam solicitações de pull apesar de falhas de análise estática, verificações de segurança ou testes de unidade; derrota o propósito dos portões de qualidade automatizados | | Cultura de revisão hostil | As análises se tornam críticas pessoais ou exercícios competitivos em vez de melhorias de qualidade colaborativas; desencoraja a aprendizagem e a segurança psicológica | | Sem revisão declarativa | Fluxos, regras de validação, conjuntos de permissões e regras de compartilhamento são implementados sem revisão enquanto o Apex code é analisado; cria lacunas de qualidade na configuração declarativa | # Excelência operacional para a empresa agente Excelência operacional para a Agência ## Visão geral A excelência operacional para sistemas agentes estende as práticas DevOps tradicionais para lidar com as características exclusivas dos agentes de IA: comportamento não determinístico, raciocínio e memória dependentes do contexto, complexidade da meta e custos de inferência variável. Os aplicativos convencionais seguem caminhos de código previsíveis, mas os agentes geram respostas novas com base no contexto. O monitoramento tradicional rastreia métricas conhecidas, enquanto a capacidade de observação do agente exige entender o raciocínio do modelo de idioma e os padrões de decisão. O teste padrão valida saídas determinísticas, mas a validação do agente avalia a qualidade da resposta em várias dimensões, incluindo precisão, relevância, segurança e imparcialidade. Produtos e sistemas mudam ao longo do tempo, portanto, aplique estes cinco princípios de design para integrar excelência operacional à maneira como você os executa: evoluir com capacidade de observação, padronizar procedimentos operacionais, adotar uma cultura de DevOps, automatizar para eficiência e aprender com todos os eventos operacionais. O principal princípio de excelência operacional, "Evoluir com capacidade de observação", se torna essencial para sistemas agentes porque o comportamento do agente surge de interações complexas entre avisos, contexto recuperado, comportamento de modelo e histórico de conversa, em vez de da execução de código determinístico. Os arquitetos não podem prever cada resposta do agente no momento do design, pois as respostas são moldadas pelo modelo, o aviso e o contexto ativo, portanto, projete para capacidade de observação e proteção. A observabilidade abrangente revela como os agentes realmente se comportam em condições reais. Essa visibilidade permite melhorias orientadas por dados e diagnóstico rápido de problemas quando os agentes produzem saídas inesperadas. "Operações como código" assume novas dimensões para agentes. A infraestrutura como código tradicional se estende para controle de versões de solicitação, gerenciamento de configuração de modelo e automação de implementação do agente. Os procedimentos operacionais do agente lidam com alterações de versão do modelo, evolução de prompt e atualizações da base de Knowledge e operações de implantação e reversão convencionais. "Aprender com todos os eventos operacionais" se torna ainda mais valioso com sistemas agentes. Os incidentes do agente muitas vezes revelam problemas de engenharia de prompt sutis, erros de script e orquestração, lacunas na base de Knowledge ou padrões inesperados de interação do usuário. O recurso Postmortems combinado à análise sistemática da telemetria do agente transforma a experiência operacional em uma funcionalidade organizacional que se compõe ao longo do tempo. ## Arquitetura de capacidade de observação do agente ### Registro de conversas e trilhas de auditoria O registro completo da conversa forma a base da capacidade de observação do agente. Capture cada conversa, incluindo entradas do usuário, respostas do agente, etapas de raciocínio, ações invocadas, dados recuperados e resultados finais. Essa telemetria tem várias finalidades: depuração de incidentes específicos, análise de qualidade em muitas interações, auditoria de conformidade, melhoria de modelo e análise de padrão de uso. Use o modelo de rastreamento de sessão nativo sobre o registro personalizado criado. O Rastreamento de sessão do Agentforce captura dados de interação do agente em um modelo de dados unificado no Data 360, em vez de exigir que você crie um sistema de telemetria paralelo. O Modelo de dados de rastreamento de sessão (STDM) registra a conversa como uma hierarquia de rastreamento. Cada sessão contém interações (turns), cada interação contém etapas (UserInputStep, LLMExecutionStep, FunctionStep) e as etapas contêm mensagens (comunicações do usuário e do agente). O STDM usa objetos padrão do Data 360, como AIAgentSession, AIAgentSessionParticipant, AIAgentInteraction, AIAgentInteractionStep e AIAgentInteractionMessage. As interações têm identificadores de rastreamento distribuído (TelemetryTraceId e TelemetryTraceSpanId) e as etapas têm um identificador de span (TelemetryTraceSpanId), refletindo um modelo de span do estilo OpenTelemetry. Modelar conversas do agente como rastreamentos e expansões é a abordagem padrão do setor para a capacidade de observação do agente, e reutilizar o modelo nativo evita os problemas de escala em que os objetos criados manualmente se encontram: armazenando conversas de vários turnos, grandes cargas úteis JSON e rápido crescimento de dados. A criação de objetos transacionais personalizados para registrar conversas é uma exceção deliberada, por exemplo, um objeto personalizado leve que correlaciona o comportamento do agente aos resultados de negócios e não ao substrato de registro principal. Metadados de sessão e conversa capturam o contexto crítico, incluindo identificadores de sessão e interação, identidade do usuário, identidade do agente, hora de início e hora de término. O STDMalso vincula cada etapa da interação a seus registros de chamada de grande modelo de idioma (LLM) (por meio de referências GenerationId e GenAiGatewayRequest/Response). Detalhes de uso de token, modelo e prompt estão disponíveis por meio dessas junções em vez de armazenadas como campos de sessão. Metadados habilita a filtragem e agregação de conversas para análise de padrão. Os detalhes da interação e do nível da etapa capturam cada turno, incluindo entrada do usuário, resposta do agente, explicação de raciocínio (quando disponível), pontuações de confiança, contexto recuperado, ações tentadas e erros encontrados. O rastreamento em nível de etapa permite uma investigação de incidente detalhada que reconstrui exatamente o que aconteceu em cada ponto da cadeia de raciocínio. As etapas de ação registram todas as ações que um agente realiza, incluindo chamadas à API, modificações de dados, interações do sistema externo e integrações invocadas. Os registros de ação respondem a perguntas como "o que esse agente mudou?" e "Que sistemas esse agente acessou?" Essas respostas dão suporte a investigações de segurança e requisitos de conformidade. O STDM captura ações nativamente como etapas da interação. Rastreamentos de fundamento do Mecanismo de fundamento do Atlas revelam os processos de decisão do agente, ajudando a diagnosticar por que os agentes escolheram ações específicas ou geraram respostas específicas. O Rastreamento de sessão registra as etapas do planejador como parte de cada interação. A profundidade do raciocínio exposto depende do modelo e do planejador, mas, quando disponíveis, esses rastreamentos melhoram drasticamente a capacidade de depuração. A trilha de auditoria de IA generativa da Camada de Trust do Einstein captura cada interação de IA generativa, o texto de prompt e resposta, incluindo versões mascaradas de informações de identificação pessoal (PII), dados de fundamentação recuperados, pontuações de segurança e toxicidade da resposta e detalhes do modelo LLM, todos transmitidos e armazenados no Data 360\. Ative a Coleção e armazenamento de dados de feedback e IA generativa do Einstein para que os dados de auditoria e feedback sejam capturados no Data 360, onde você pode consultá-los e analisá-los com relatórios do Data 360 para retenção de longo prazo. > **Exemplo:** > > Bom: Registros de conversa armazenados em objetos personalizados do Salesforce com campos para entrada do usuário, resposta do agente, ações realizadas, consumo de token e resultado da conversa. O painel mostra as taxas de sucesso da conversa por agente e caso de uso. Melhor: O registro abrangente inclui rastreamentos de raciocínio mostrando o processo de decisão do agente, contexto recuperado mostrando quais informações fundamentam respostas e pontuações de confiança indicando a incerteza. Melhor: A análise de conversa correlaciona o comportamento do agente com os resultados dos negócios, identifica oportunidades de melhoria por meio da análise de padrão e alimenta pipelines de aprendizado contínuo com exemplos rotulados com qualidade. ### Monitoramento de desempenho do agente Monitore o desempenho operacional garantindo que os agentes atendam aos níveis de serviço e operem dentro dos parâmetros esperados. A **latência de resposta** rastreia o tempo de término a término da entrada do usuário à resposta do agente. A latência afeta diretamente a experiência do usuário. Meça a latência em percentis (p50, p95, p99) revelando desempenho típico e experiências de pior caso. Alerta quando a latência p95 excede limites indicando degradação do desempenho. Fatores de latência para agentes incluem tempo de inferência do modelo, duração da recuperação de dados e contexto, execução de ferramentas e ações externas e latência de rede. Instrumente cada fase separadamente habilitando a otimização direcionada quando a latência geral exceder as metas. O **consumo de token** mede os tokens usados por conversa, por agente e por caso de uso. O consumo de token gera custos de inferência e afeta o tempo de resposta (mais tokens exigem mais computação de inferência). Acompanhe a distribuição de token revelando se o uso real corresponde às projeções. Detecte conversas desfavoráveis que consomem tokens excessivos sugerindo problemas de prompt ou uso indevido. As métricas de token incluem tokens de prompt (entrada para o modelo), tokens de conclusão (saída do modelo) e tokens totais (soma de prompt e conclusão). Os tokens de prompt são mais controláveis que os tokens de conclusão. Otimize avisos e contexto recuperado reduzindo o consumo de token de prompt enquanto mantém a qualidade. O **monitoramento de transmissão** rastreia conversas simultâneas, solicitações por segundo e tendências de volume de conversas e pode ajudar na capacidade do projeto e nos requisitos de escala. Compare a taxa de transferência atual com os limites de taxa conhecidos ou alerta de linhas de base de capacidade ao se aproximar dos limites. O rastreamento de **taxa de erro** monitora falhas por tipo, incluindo erros específicos do modelo, falhas de tempo limite, erros negados por permissão e falhas de integração externas. Os padrões de erro revelam problemas sistemáticos que exigem remediação. Calcule as taxas de erro como um percentual do total de solicitações, permitindo a comparação entre agentes e períodos. Diferencie entre categorias de erro que exigem respostas diferentes. Erros específicos do modelo podem exigir ajustes de prompt ou mudar para um modelo melhor. Erros de permissão exigem alterações de configuração de segurança. Os erros de integração exigem investigação do sistema externo ou ativação do disjuntor. O **monitoramento de disponibilidade** mede o tempo de atividade do agente e os períodos de operação bem-sucedidos. Calcule a disponibilidade como a porcentagem de tempo em que os agentes respondem com sucesso às solicitações. Acompanhe a disponibilidade em relação a objetivos de nível de serviço (SLOs), habilitando uma resposta proativa quando a disponibilidade cai abaixo das metas. O **Proactive Monitoring** avalia sua organização quanto a anomalias de plataforma e problemas de utilização de recursos que podem afetar a integridade da infraestrutura do agente. Ele detecta sinais antes que eles sejam escalados para problemas visíveis ao usuário. Use-o para ficar à frente de condições no nível da infraestrutura, como atividade de API incomum ou tendência de consumo de recurso em relação aos limites da plataforma, que podem prejudicar o desempenho do agente. Revise seus sinais em relação à linha de base operacional normal de seus agentes para poder distinguir anomalias acionáveis da variação esperada. ### Métricas de qualidade e avaliação Monitore a qualidade da resposta continuamente, detectando degradação antes que afete os resultados dos negócios. Quando a plataforma oferece ferramentas de avaliação integradas, use-as em vez de processos personalizados ou manuais. Comece com ferramentas nativas de teste e avaliação. A Central de Testes do Agentforce permite que você mantenha conjuntos de casos de teste reutilizáveis e execute agentes contra eles em lote, verificando se o agente selecionou o tópico e a ação esperados e produziu uma resposta aceitável em vez de criar e executar seu próprio arame de teste. Também oferece suporte a avaliadores nativos, incluindo dimensões de qualidade prontas para uso e uma abordagem de LLM-as-judge para pontuar a qualidade da conversa e permite criar avaliadores personalizados para critérios específicos da organização. Use conversas representativas em seus conjuntos de teste para que a avaliação reflita o uso real. A **precisão da resposta** mede se as respostas do agente contêm informações corretas. A avaliação precisa requer declarações de resposta conhecida ou revisão humana. Para perguntas factuais com respostas conhecidas, a avaliação automatizada compara as respostas corretas do agente e as mantém como casos de teste no Centro de teste para avaliação repetível. Para perguntas abertas, os avaliadores humanos avaliam a precisão em conversas de amostra. Acompanhe tendências de precisão ao longo do tempo, revelando se alterações de prompt, atualizações de modelo ou modificações da base do Knowledge melhoram ou reduzem o desempenho. A **relevância da resposta** mede se as respostas do agente abordam adequadamente as perguntas do usuário, mesmo que não sejam perfeitamente precisas. As respostas relevantes entendem a intenção do usuário e fornecem informações úteis mesmo quando uma resposta completa não é possível. Avalie a relevância por meio de avaliadores nativos, quando disponíveis, revisão humana de conversas de amostra e sinais do usuário. Para agentes baseados em uma base de Knowledge, a análise de qualidade de recuperação nativa pode avaliar a relevância do contexto, a relevância das respostas e a fidelidade (fundamentação) das respostas. Os **Guardrails** detectam respostas inseguras, impróprias ou prejudiciais, incluindo viés, conteúdo ofensivo, conselhos perigosos e respostas fora do escopo. A Camada de Trust do Einstein aplica detecção de toxicidade a interações do LLM em tempo de execução, que é sua primeira linha de defesa. Melhore o monitoramento de segurança por meio de filtragem de conteúdo, amostragem de análise manual, mecanismos de relatório do usuário e auditorias de imparcialidade que avaliam as distribuições de resultados entre grupos demográficos. As métricas de **satisfação do usuário** capturam a qualidade da experiência subjetiva. O feedback do Agentforce flui para os modelos de dados de auditoria e feedback de IA generativos do Einstein (GenAIFeedback/GenAIFeedbackDetail no Data 360). Esses modelos capturam sinais explícitos do usuário (tomar o polegar para cima/para baixo, aceitar/rejeitar, editar e comentar verbalmente) de uma origem humana ou do sistema, junto com a solicitação de gateway e os dados de geração.Capture feedback explícito (solicitar antes da escalação, após o fim de uma conversa e por meio de pesquisas de acompanhamento) onde você precisar e combine sinais explícitos e implícitos para uma perspectiva de qualidade abrangente. ### Detecção de desvio do modelo O Salesforce fornece várias superfícies de modelo. O nível generativo fornece os argumentos conversacionais que os agentes executam: Os modelos hospedados pela Agentforce fornecem raciocínio pronto para uso dentro do limite do Salesforce Trust e trazem seus próprios links de LLM (BYOLLM) para LLMs ou provedores externos. O nível preditivo fornece as pontuações estruturadas que os agentes baseiam suas decisões em: O BYOM obtém pontuações preditivas de cópia zero de plataformas hospedadas externamente e os modelos nativos do Einstein produzem pontuação e classificação automatizadas em objetos de CRM. Juntos, essas surpresas permitem que um agente autônomo argumente em linguagem natural enquanto baseia seu fluxo de trabalho em dados estatísticos estruturados. Monitore o desvio do modelo, que indica desempenho degradado ao longo do tempo ou alteração de condições que exigem adaptação. Revise as notas de versão e teste casos de uso críticos em um sandbox antes de cada versão principal ir para a produção. Use a matriz de versão e a janela de visualização de sandbox para detectar problemas de compatibilidade com antecedência. O **desvio de desempenho** ocorre quando a precisão, a relevância ou a segurança do agente diminuem ao longo do tempo. Acompanhe as métricas de qualidade ao longo do tempo, detectando reduções estatisticamente significativas. O desvio de desempenho pode resultar de degradação do modelo, obsolescência da base de Knowledge, desalinhamento de prompt com padrões de uso alterados ou desvio de conceito em que os relacionamentos entre entradas e saídas desejadas evoluem. Estabeleça o desempenho da linha de base imediatamente após a implantação inicial do agente, medindo a precisão, a relevância, a segurança e a satisfação em casos de teste representativos. Reavalie periodicamente em relação aos mesmos casos de teste que revelam alterações de desempenho independentemente de turnos de padrão de uso. Alerte quando as métricas de qualidade ultrapassam limites aceitáveis. Defina limites com base na tolerância de impacto de negócios. Alguns casos de uso toleram degradação de qualidade modesta; outros exigem resposta imediata a qualquer redução. O **desvio de distribuição** ocorre quando os padrões de entrada do usuário mudam significativamente de distribuições de dados de treinamento ou ajuste. O desvio de distribuição degrada o desempenho quando os agentes encontram tipos de entrada que não foram projetados para lidar. Monitore características de entrada, incluindo comprimento da pergunta, distribuição de tópicos, complexidade do idioma e terminologia de domínio, detectando turnos significativos. Compare distribuições de entrada atuais com linhas de base históricas. Grandes turnos de distribuição podem indicar novos casos de uso, alteração do comportamento do usuário ou processo de negócios em evolução. Os turnos de distribuição podem exigir atualizações imediatas, expansão da base do Knowledge ou aprimoramentos de capacidade do agente. O **desvio comportamental** ocorre quando os padrões de resposta do agente mudam inesperadamente. Monitore características da resposta, incluindo duração média da resposta, taxas de invocação de ação, frequências de escalação e padrões de erro. Alterações comportamentais significativas podem indicar problemas de prompt, problemas de modelo ou alterações do sistema subjacentes. Estabeleça linhas de base comportamentais logo na produção, capturando características de operação normais, como padrões de desempenho regulares, uso de ferramentas e caminhos de decisão. Essas linhas de base se tornam a referência em relação à qual a detecção de anomalia posterior é aplicada. Compare o comportamento em andamento com relação às linhas de base, alertando quando os desvios excedem a variação esperada. O **alerta automatizado** permite uma resposta proativa ao desvio. Configure o acionamento de alertas quando as métricas de desvio excederem limites acionando investigação e possível remediação, incluindo refinamento imediato, atualizações da base de Knowledge, expansão do conjunto de testes ou treinamento de modelo BYOM. ### Detecção e alerta de anomalia Detecte automaticamente o comportamento incomum do agente que requer investigação. **Anomalias de custo**, incluindo picos de consumo de token, aumentos de taxa de inferência ou aceleração de custo total. Picos de custo podem indicar problemas de prompt causando geração excessiva de token, abuso ou uso indevido que levam a uso inesperado ou problemas de infraestrutura que causam chamadas redundantes. Monitore as distribuições de consumo de token detectando conversas de desvios. Investigue conversas que consomem 10 vezes a contagem de tokens típica para entender se elas representam casos de extremidade legítimos ou problemas que exigem correção. **Picos de taxa de erro**, incluindo aumentos súbitos nas taxas de falha, novos tipos de erro aparecendo que não existiam na linha de base ou concentrações de erros localizadas que afetam usuários, agentes ou casos de uso específicos. Os picos de erro costumam preceder os problemas de degradação de qualidade que os clientes podem ver. A detecção proativa permite a remediação antes do impacto amplo. **Alterações de padrão de resposta**, incluindo mudanças súbitas na duração da resposta, frequência de invocação de ação ou alterações de taxa de escalação. Alterações de padrão podem indicar problemas de prompt, alterações de comportamento do modelo ou padrões de uso em evolução. O **abandonamento da conversa aumenta** quando os usuários abandonam conversas em taxas mais altas sugerem menor qualidade, maior latência ou lacunas de funcionalidade. Acompanhe o abandono por estágio da conversa identificando se os usuários abandonam durante a interação inicial, no meio da conversa ou após a tentativa de conclusão da tarefa. Os padrões de abandono revelam oportunidades de melhoria específicas. Projete a arquitetura de alerta equilibrando a notificação rápida com a fadiga do alerta. Encaminhe falhas críticas do agente para os engenheiros na chamada imediatamente. Encaminhe avisos de degradação de qualidade para equipes de produto para investigação durante o horário comercial. Agregue anomalias secundárias em resumos diários para análise de tendências. ## Ciclo de vida do agente e operações de aprendizado de máquina ### Controle e gerenciamento de versão de prompt Avisos de controle de versão, configurações e metadados de modelo habilitando reversão, teste A/B e manutenção da trilha de auditoria. Os **modelos de prompts** são avisos reutilizáveis criados no Criador de prompts que definem a meta, as restrições e as diretrizes de marca do agente, além de espaços reservados para dados de fundamentação dinâmica, como detalhes do cliente ou do produto. Armazene modelos de prompt no Git junto com o código do aplicativo, tratando os prompts como lógica de aplicativo crítica que merece a mesma rigor do código. As alterações de prompt passam pela revisão de código, testes e implantação controlada. Use Criador de prompts para desenvolvimento de prompts iterativos com recursos de teste e histórico de versões. Ao usar modelos de prompts como ações do agente, visualize o modelo no Criador de prompts para confirmar que os campos de mesclagem foram resolvidos corretamente. Em seguida, use o Centro de teste para executar testes completos que confirmam que o agente seleciona a ação e gera as saídas corretas. Exporte avisos prontos para produção para o controle de versão criando sincronização entre o desenvolvimento do Criador de prompts e pipelines de implantação controlados por origem. O **gerenciamento de configuração** rastreia a seleção do modelo, as configurações de temperatura, as configurações de recuperação e os sinalizadores de recurso. Armazene configurações como código para que você possa usar valores específicos do ambiente, automatizar implantações e detectar o desvio de configuração. A **versão semântica** se aplica a versões de agente. Versões principais indicam alterações de interrupção, como contratos de entrada/saída modificados ou comportamento significativamente alterado. Versões menores indicam adições ou melhorias de recursos que mantêm a compatibilidade. Versões de patch indicam correções de bugs. A numeração de versão informa o impacto da alteração para as equipes de operações e usuários. Implemente controle de versões semântico para componentes de agente, incluindo modelos de prompt, configurações de agente e bases de Knowledge. Os números de versão nos registros permitem a correlação de incidentes com implantações específicas. A **documentação de alteração** captura a justificação para alterações de prompt, modificações de configuração e atualizações de modelo. Documente o que mudou, por que mudou, quais testes validaram a alteração e quais procedimentos de reversão existem. A documentação de alteração acelera a investigação de incidentes e a transferência de Knowledge. ### Registro de modelo e rastreamento de implementação Mantenha um registro abrangente de versões do modelo, avisos, configurações e histórico de implementação. O **registro de modelo** registra quais versões de modelo são implementadas, incluindo família de modelos, versão específica, estado de ajuste fino, ambiente de implementação (produção, preparação e desenvolvimento), data de implementação e equipe responsável. O registro fornece uma única fonte da verdade para o estado da infraestrutura do agente. O rastreamento de **implementação** registra cada implantação do agente, incluindo versão implantada, ambiente, carimbo de data e hora da implantação, usuário de implantação, aprovações obtidas e resultado da implantação. Use o histórico de implementação para avaliar o impacto quando ocorrerem problemas (por exemplo, "Quais agentes foram implantados antes do início desse incidente?") e dar suporte a relatórios de conformidade. O rastreamento de **dependência** mapeia os relacionamentos entre agentes, avisos, bases de Knowledge, ações e integrações. Quando a base de Knowledge compartilhada é atualizada, o rastreamento de dependência revela quais agentes são afetados. Quando a integração externa muda, o rastreamento de dependência identifica os agentes afetados. Documente as dependências explicitamente em vez de descobri-las durante incidentes. Crie mapas de dependência mantidos por meio de processos de desenvolvimento e implementação. As **políticas de descontinuação** definem os ciclos de vida das versões do modelo, incluindo duração do suporte, linha do tempo de descontinuação e requisitos de migração. Apagar políticas de descontinuação gerencia o débito técnico, impedindo o suporte indefinido a versões de modelo antigas. Estabeleça uma agenda de descontinuação comunicando as linhas do tempo com antecedência suficiente habilitando migrações planejadas em vez de respostas de emergência a descontinuações forçadas. Um período mínimo de aviso com suporte de política e bem comunicado fornece tempo de migração adequado para alterações críticas. Os **procedimentos de reversão** permitem que as equipes se recuperem rapidamente de implantações problemáticas. Documente os procedimentos de reversão para cada agente e inclua o seguinte: - Condições que acionam um reversão - Para qual versão reverter - Como executar o reversão - Quem autoriza e executa o reversão - Quais testes confirmam o sucesso do reversão e quais equipes notificar. Teste os procedimentos de reversão regularmente em ambientes que não sejam de produção para confirmar que eles funcionam antes de você depender deles durante incidentes de produção. Treine com implantações simuladas para que a equipe saiba exatamente o que fazer. Procedimentos de reversão não testados geralmente falham quando mais precisam. ### Treinamento contínuo e adaptação de domínio Mantenha a qualidade dos agentes por meio de treinamento contínuo, ajuste fino e fluxos de trabalho de refinamento. A **coleção de feedback** coleta sistematicamente feedback do usuário, correções de revisão humana, avaliações de qualidade e medições de resultados. O feedback fornece material bruto para melhoria. Sem coleta sistemática, a melhoria se torna adivinhação. Colete feedback explícito por meio de perguntas fazendo perguntas antes do escalonamento, após o fim de uma conversa ou por meio de pesquisas de acompanhamento. Colete feedback implícito por meio de taxas de conclusão, frequências de escalação e padrões de nova tentativa. Combine sinais explícitos e implícitos fornecendo uma perspectiva de qualidade abrangente. A **curadoria de dados** mantém conjuntos de dados de treinamento de alta qualidade por meio de curadoria, revisão de qualidade e verificação de viés. A qualidade dos dados de treinamento determina diretamente a qualidade do modelo. Dados ruins produzem modelos não confiáveis; dados excelentes permitem um desempenho excepcional. Organize registros de conversa em conjuntos de dados de treinamento: - Filtrar pela qualidade – incluindo conversas com alta classificação e resultados bem-sucedidos - Remover exemplos problemáticos, incluindo violações e erros de segurança - Garantir a representatividade – incluindo diversos cenários e casos de extremidade - Desduplicar – remover exemplos quase idênticos **Adapte agentes** ao seu domínio – vocabulário especializado, processos de negócios exclusivos, Knowledge específico da organização – principalmente por meio da geração ampliada por recuperação (RAG) baseada no Data 360 e do ajuste rápido, o caminho nativo do Salesforce. Nenhum modelo generativo é ajustado no Salesforce; você seleciona e configura modelos por meio de modelos de IA e Criador de prompts. Quando a fundamentação for insuficiente, faça o ajuste fino externamente e conecte-se por meio de BYOLLM. O **refinamento de prompts** melhora iterativamente os prompts com base nos dados de desempenho usando o Criador de prompts. A engenharia de prompts é uma prática contínua em vez de um exercício único. Conforme os padrões de uso evoluem, os processos de negócios mudam e as expectativas do usuário mudam, os avisos exigem ajuste para manter o desempenho ideal. Estabeleça um ritmo de revisão de prompts regular examinando conversas recentes, métricas de qualidade e feedback do usuário identificando oportunidades de melhoria. Implemente alterações de prompt incrementalmente com testes A/B validando melhorias antes da distribuição completa. A **automação de avaliação** executa a avaliação da qualidade em conjuntos de testes permanentes, permitindo uma avaliação rápida dos candidatos à melhoria. A avaliação automatizada fornece uma medição objetiva que complementa a avaliação humana subjetiva. Mantenha os conjuntos de testes que cobrem caminhos felizes, casos de ponta, entradas adversárias e cenários de problemas históricos. Defina a automação de teste para executar seus cenários de teste em um ritmo regular. Inclua o monitoramento automatizado de resultados, limites e notificações para alertar os administradores sobre anomalias. Esse teste automatizado é crucial para detectar efeitos adversos de fatores externos, como desvio de modelo. Expanda continuamente os conjuntos de teste à medida que novos casos de ponta aparecem na produção. A automação de teste é essencial, mas também execute verificações manuais periódicas, testes únicos e testes de gorila para garantir que sua implantação agente se mantenha em relação a casos de ponta. ### Distribuição gradual e teste A/B Implemente as alterações do agente gradualmente e monitore a qualidade antes da distribuição completa para limitar o raio de problemas. Quando uma alteração abrange várias áreas – avisos, configuração de modelo, ações, fundamentação, integrações – ela pode reduzir o comportamento de maneiras que os testes não capturaram. Quando isso acontece, a regressão de qualidade resultante raramente aponta para uma única causa-raiz óbvia. Envie pequenas alterações uma por vez para que uma regressão possa ser rastreada até sua origem e libere cada uma para uma parte limitada do tráfego primeiro para conter o impacto enquanto você diagnostica. Os sinalizadores **de recurso** desconectam a implantação da versão implantando agentes com recursos desabilitados atrás da configuração. Implemente sinalizadores de recurso usando lógica ou tipos de metadados personalizados ou configurações personalizadas. Os sinalizadores de recurso permitem o teste no ambiente de produção sem expor recursos aos usuários, distribuições graduais para segmentos de usuário específicos, teste A/B comparando implementações e reversão instantânea desabilitando sinalizadores sem reimplementação. Use sinalizadores de recurso para alterações significativas do agente, em que o raio de explosão de uma falha pode ser grave, como Alterações que afetam agentes críticos para os negócios, Novos padrões de raciocínio com comportamento de produção incerto Integrações com sistemas externos em que os padrões de interação podem ser diferentes dos testes. As alterações do agente de versão das **implementações Canary** para pequenos subconjuntos de usuários primeiro monitoram as taxas de erro, as métricas de qualidade e o desempenho antes da distribuição mais ampla. Use conjuntos de permissões para controlar implantações canárias: restrinja o acesso do agente a um subconjunto de usuários ou filtre dentro da lógica de orquestração com base nos atributos do usuário. Monitore e meça as taxas de sucesso, a qualidade da resposta e o feedback do usuário. Compare métricas canárias com grupos de controle usando a versão anterior do agente. Expanda a distribuição apenas quando o canário demonstrar desempenho equivalente ou aprimorado. O **teste A/B** compara variações de agente para medir a qualidade, o custo e a satisfação do usuário. O teste A/B fornece evidência empírica para decisões de melhoria. Implemente variantes em subconjuntos de usuários selecionados aleatoriamente garantindo a validade estatística. Meça os resultados em várias dimensões (precisão, satisfação, custo e latência) fornecendo uma comparação abrangente. Defina critérios de sucesso e hipótese antes de iniciar testes A/B. Critérios claros impedem resultados ambíguos, em que algumas métricas melhoram enquanto outras diminuem. Os critérios de sucesso devem estar alinhados aos objetivos de negócios (por exemplo, "A Variante B deve corresponder à precisão da Variante A em 2% enquanto reduz o custo em 15%"). Os **teste de campeão-desafio** implementam versões de agente aprimoradas em subconjuntos de tráfego em comparação com versões de campeão atuais. O padrão de líder e desafiador gerencia o risco de melhoria mantendo a versão comprovada como fallback. Se o desafiador tiver um desempenho insuficiente, reverta para o líder sem impacto sobre o usuário. Se o desafiador apresentar um desempenho superior, promova-o para o novo líder. Estabeleça critérios de promoção objetivos, incluindo tamanho mínimo de amostra para validade estatística, limites de qualidade que os desafiadores devem exceder e duração da avaliação antes das decisões de promoção. Documente decisões de promoção criando uma trilha de auditoria de por que as versões do agente mudaram. ## Resposta de incidente para falhas do agente ### Detecção e classificação de incidentes Estabeleça a detecção de incidentes identificando problemas operacionais do agente rapidamente por meio do monitoramento abrangente. Os **modos de falha do agente** diferem das falhas tradicionais do aplicativo. Os modos de falha comuns incluem: - Alucinações – gerando informações plausíveis, mas incorretas - Respostas fora do tópico – intenção do usuário mal compreendida - Consumo de custo excessivo – geração de token de fuga - Falhas de tempo limite – inferência que leva muito tempo - Erros de permissão – tentativa de ações não autorizadas - Falhas de integração – indisponibilidade do sistema externo - Violações de segurança – gerando conteúdo impróprio Detecte falhas por meio de alerta de monitoramento automatizado sobre taxas de erro, degradação da métrica de qualidade, anomalias de custo, aumentos de latência e escalonamentos de usuário. Suplementar com mecanismos de auto-relatório do usuário, incluindo solicitações de feedback e orientações claras sobre como e onde dar feedback, para que você possa corrigir lacunas relatadas na automação. A **classificação de gravidade** encaminha incidentes para responsáveis apropriados com urgência adequada. Incidentes críticos indicam indisponibilidade de produção que afeta muitos usuários, risco de corrupção de dados devido a ações do agente, compromisso de segurança ou violações de segurança que exigem resposta imediata. A alta gravidade indica uma qualidade degradada que afeta agentes críticos para os negócios ou excedentes de custo significativos. A gravidade média indica problemas isolados ou limites se aproximando que exigem investigação durante o horário comercial. A baixa gravidade indica pequenos problemas rastreados fora do processo de gerenciamento de incidentes. Defina critérios de gravidade de modo objetivo com base no impacto do usuário, no raio de explosão, no risco de integridade dos dados e na urgência da recuperação. Critérios objetivos impedem problemas reais de escalonamento insuficiente e problemas secundários de escalonamento excessivo. Mantenha a documentação sobre as descobertas de resolução de incidentes para melhorar continuamente o processo. Os **procedimentos iniciais de resposta** orientam ações imediatas para estabilizar a situação. Os procedimentos incluem: - Desabilitar agente com falha – ativação do disjuntor - Rotear usuários para opções de fallback – transferência humana, agente mais simples, respostas estáticas - Colete informações de diagnóstico – conversas recentes, logs de erros, métricas de recursos - Notificar as partes interessadas – engenheiros na chamada, proprietários do produto, usuários afetados - Iniciar comunicação de incidentes – atualizações de página de status, canais de coordenação interna - Documente os procedimentos de resposta inicial como manuais que permitem uma execução rápida sem exigir investigação específica do incidente. - Os manuais devem ser executáveis por engenheiros na chamada sem conhecimento profundo do agente. ### Padrões de fallback e quebradores de circuito Evite falhas em cascata e mantenha a funcionalidade parcial durante incidentes do agente. O **padrão do disjuntor** desativa automaticamente os agentes com falha, evitando falhas repetidas e impacto do usuário enquanto os problemas são resolvidos. Implemente circuitos que monitoram as taxas de erro e abrem (desabilitando o agente) quando a taxa de erro exceder o limite para um período sustentado. Configure os disjuntores com limite de erro, janela de duração e teste de recuperação. Por exemplo, uma taxa de erro de 50% com uma janela dinâmica de cinco minutos e uma avaliação periódica que solicita o teste da recuperação do agente. Quando o circuito é aberto, as solicitações são roteadas para opções de fallback. Após um período de tempo limite, o circuito muda para um estado de meia abertura, permitindo que as solicitações de avaliação passem. Quando as solicitações de avaliação forem bem-sucedidas de modo consistente, feche o circuito, retomando a operação normal. As **hierarquias de fallback** fornecem uma degradação graciosa quando os agentes primários falham. Projete sequências de fallback tentando opções cada vez mais simples até que uma resposta aceitável seja alcançada. Exemplo de hierarquia de fallback: Agente sofisticado principal → Agente de backup mais simples → Respostas frequentes estáticas → Transferência humana. Implemente a lógica de fallback na camada de orquestração, em vez de dentro dos agentes, habilitando um comportamento consistente em todo o ecossistema do agente. Teste os caminhos de fallback regularmente, validando se eles funcionam quando necessário. A transferência **de pessoas** aumenta para agentes humanos quando os agentes de IA não conseguem lidar com solicitações. Projete fluxos de trabalho de transferência preservando o contexto da conversa, comunicando o motivo da transferência, encaminhando para agentes humanos adequados com conhecimento relevante e rastreando a frequência de transferência revelando oportunidades de melhoria. Monitore as taxas de escalação por tópico, agente e motivo da falha. Taxas mais altas indicam lacunas de capacidade do agente que exigem melhorias imediatas, expansão da base de Knowledge ou refinamento do caso de uso. A **degradação agradável** mantém a funcionalidade parcial durante a operação degradada. Quando o raciocínio sofisticado falha, volte para uma lógica mais simples. Quando os dados em tempo real estiverem indisponíveis, opere em dados em cache. Quando as integrações externas falharem, opere no modo somente leitura. Uma degradação eficiente permite que um sistema continue operando em uma capacidade reduzida em vez de falhar completamente. ### Análise e aprendizado pós-incidente Realize análises pós-incidente impecáveis com foco em melhorias do sistema, em vez de criar falha individual para segurança psicológica para avaliação honesta. A **reconstrução de linha do tempo** cria uma sequência detalhada das condições iniciais por meio do primeiro sinal, detecção, confirmação, investigação, ações de resposta, recuperação e validação. Carimbo de data e hora de cada evento habilitando a análise de duração de cada fase revelando onde a resposta do incidente foi adiada. Inclua o seguinte na linha do tempo: - O que foi implementado recentemente (aventos, configurações, modelos, integrações)? - Quais alterações nos padrões de uso (aumento de tráfego repentino, novos tipos de conversa) foram observadas? - Quais fatores externos contribuíram (degradação de serviço de terceiros, atualizações de plataforma)? - O que tornou a detecção mais lenta do que o ideal? A **identificação da causa raiz** determina a causa técnica direta. Diferencie a causa imediata (tempo limite do modelo) dos fatores relevantes (desenho de prompts que excede os limites de token em padrões de conversa específicos). A análise de causa raiz evita conclusões simplistas ("o agente tinha um bug") em favor de descobertas específicas que resultam em uma solução eficaz. Use a técnica "Cinco razões", detalhando os sintomas para as causas fundamentais. **Exemplo de superfície:** "O agente produziu informações incorretas" → "Por quê? Contexto recuperado continha dados desatualizados" → "Por quê? A base de Knowledge não foi atualizada com as alterações de produto recentes" → "Por quê? Não há nenhum processo para a equipe de produto acionar atualizações da base de Knowledge" → Causa raiz: Fluxo de trabalho ausente conectando versões de produto à manutenção da base Knowledge. Os **fatores contribuintes** revelam condições organizacionais, de processo ou de arquitetura que permitem ou amplificam o impacto do incidente. Fatores comuns incluem lacunas de monitoramento que permitem que os problemas persistam por mais tempo do que o detectado, lacunas de teste que deixam os cenários de falha desconhecidos, lacunas de documentação que desaceleram o diagnóstico rápido, lacunas de automação que forçam etapas de recuperação manual e lacunas arquitetônicas, como pontos únicos de falha ou redundância ausente. A análise de fator contribuinte revela oportunidades de melhoria além da correção da causa raiz imediata. A maioria dos incidentes tem vários fatores contribuintes, cada um amplificando o impacto. A **análise de detecção** examina como o incidente foi detectado e se a detecção poderia ter sido mais rápida. Muitos incidentes de agente são relatados inicialmente pelos usuários em vez do monitoramento automatizado, indicando uma lacuna de monitoramento. Determinar: Qual sinal deveria ter detectado o problema anteriormente? Qual monitoramento permitiria uma detecção mais rápida? Qual critério de alerta teria sido disparado adequadamente? As melhorias na análise de detecção incluem: Adicionar cobertura de monitoramento ausente, ajustar limites de alerta eliminando negativos falsos, aprimorar o contexto de alerta para triagem mais rápida e melhorar painéis para identificação proativa de problemas. A **avaliação da resposta** avalia o que correu bem e o que foi mais lento ou mais difícil do que o necessário. Perguntas de avaliação da resposta: Os manuais eram úteis e precisos? Os caminhos de escalação eram claros e eficazes? Os procedimentos de reversão foram testados e prontos? As ferramentas forneciam as informações de diagnóstico necessárias? A comunicação foi oportuna e eficaz? As melhorias na avaliação de resposta incluem: atualizar manuais com lições aprendidas, esclarecer critérios de escalação, testar procedimentos de reversão regularmente, adicionar ferramentas de diagnóstico e melhorar modelos de comunicação de incidentes. Os **itens de acção** especificam melhorias concretas, atribuídas e temporizadas que impedem a recorrência ou melhoram a resposta futura. Evite itens de ação vazios, como "melhorar o monitoramento", em favor de tarefas específicas, como "adicionar alerta para taxa de erro do agente acima de 5% em uma janela de 10 minutos", atribuído: Alex, vencida: 2 semanas.". Acompanhe a conclusão do item de ação em revisões subsequentes garantindo que a melhoria contínua ocorra. Revise itens de ação abertos de incidentes anteriores durante cada revisão pós-incidente. As baixas taxas de conclusão indicam a falha do processo de melhoria contínua que requer atenção. O **Knowledge sharing** documenta revisões pós-incidente em uma wiki compartilhada, base de conhecimento ou espaço de colaboração com marcação que permite a análise de padrões em vários incidentes. Os retrospectivas de incidentes devem ser pesquisáveis por modo de falha, componentes afetados e período de tempo para permitir que os futuros entrevistados aprendam com incidentes históricos. Compartilhe análises pós-incidente além dos respondentes imediatos do incidente. O aprendizado organizacional requer propagação de informações. Considere apresentar os principais aprendizagens de incidentes em reuniões de equipe ou sessões de almoço e aprendizado que propagem Knowledge e criem capacidade coletiva. ## Governança e aprovação do agente ### Processos de aprovação de implementação Exija aprovação antes de implantar agentes de produção garantindo revisão, avaliação de risco e alinhamento da parte interessada. A **lista de verificação pré-implementação** valida a prontidão, incluindo: - Teste abrangente concluído – funcionalidade, qualidade, segurança, desempenho - Revisão de segurança aprovada – limites de permissão, acesso a dados, autorização de ação - Conformidade validada – requisitos regulatórios, adesão à política - Documentação concluída – manuais, procedimentos de reversão, caminhos de escalação - Monitoramento configurado – métricas de qualidade, taxas de erro, rastreamento de custo - Aprovação da parte interessada obtida – proprietário do produto, segurança, conformidade A lista de verificação fornece critérios de avaliação consistentes entre agentes. Adapte a lista de verificação para perfil de risco do agente variando a profundidade com base na crítica do agente, na confidencialidade dos dados e no nível de autonomia. A **avaliação de riscos** avalia o impacto potencial das falhas do agente, incluindo: - Raio de explosão – quantos usuários foram afetados por falha - Sensibilidade de dados – o que o agente de dados acessa - Autoridade de ação – que modificações o agente pode fazer - Dependências de integração – quais sistemas o agente afeta - Complexidade da recuperação – quão difícil é o reversão - Implicações de conformidade – quais regulamentos se aplicam A avaliação de risco determina os requisitos de aprovação. Agentes de alto risco exigem aprovação executiva, revisão de segurança e distribuição gradual, enquanto agentes de baixo risco podem exigir revisão por pares e testes padrão. Os fluxos de **trabalho de aprovação** encaminham solicitações de implantação por meio de revisores apropriados. Implemente fluxos de trabalho de aprovação usando processos de aprovação do Salesforce ou ferramentas de implementação externas. Automatize, rastreie e audite fluxos de trabalho de aprovação para habilitar relatórios de conformidade e investigação de incidentes. Documente decisões de aprovação, crie uma trilha de auditoria de quem aprovou implantações, quais informações informaram as aprovações, quais condições ou restrições foram aplicadas e quais compromissos de monitoramento foram feitos. Os **procedimentos de desvio de emergência** permitem uma implantação rápida durante incidentes de produção quando os processos normais de aprovação atrasariam as correções críticas. Os procedimentos de emergência devem exigir aprovação executiva, incluir documentação de fundamento e acionar a revisão pós-implementação de validação de alterações de emergência. Acompanhe implantações de emergência separadamente das versões padrão. A frequência de implementação de alta emergência indica problemas de processo que exigem investigação. ### Gates de qualidade e teste Defina os portões de qualidade que os agentes devem passar antes da implementação da produção, impedindo que agentes problemáticos entrem em contato com os usuários. O **teste funcional** valida que os agentes realizam as tarefas pretendidas corretamente em cenários representativos. Teste caminhos satisfeitos que abrangem interações típicas, casos de ponta que abrangem cenários infrequentes, mas válidos, caminhos de erro que testam se os agentes lidam com entradas inválidas com facilidade e condições de limite que verificam se o agente está dentro dos limites de controlador, limites de token e limites de volume de dados. O teste funcional para agentes difere do teste tradicional porque saídas não determinísticas impedem a correspondência exata. Teste as características de saída (contém as informações necessárias, mantém o tom adequado, inclui as citações necessárias) em vez do texto exato. O **teste de qualidade da resposta** avalia a precisão e a relevância da resposta em todos os cenários de teste. O teste de qualidade requer avaliação humana ou conjuntos de dados de verdade fundamental com resultados esperados. Estabeleça limites de qualidade mínimos que os agentes devem cumprir (por exemplo, "precisão de 95% no conjunto de testes em espera, nenhuma violação de segurança, auditoria de imparcialidade mostra nenhuma disparidade demográfica superior a 5%"). Mantenha e expanda conjuntos de teste continuamente conforme novos casos de ponta são descobertos. Os **teste de segurança** validam se os agentes recusam solicitações perigosas, antiéticas ou fora do escopo. Os testes de segurança tentam entradas adversárias, incluindo: - Avisar tentativas de injeção – tentando substituir instruções - Tentativas de jailbreak – tentando contornar restrições de segurança - Solicitar escalação – pedir ações cada vez mais confidenciais - Solicitações fora do escopo – tentando tarefas não autorizadas Atribua testes de segurança a membros da equipe independentes que não estiveram envolvidos na criação do agente. Para agentes de alto risco, traga especialistas da equipe vermelha. O **teste de desempenho** valida as expectativas de latência, taxa de transferência e custo. Teste em carregamento realista, incluindo conversas simultâneas, durações típicas da conversa e volume de uso projetado. O teste de desempenho revela problemas de limite do regulador, restrições de recurso e gargalos de escalabilidade invisíveis em testes de usuário único. Meça o consumo do ambiente de teste durante os testes de desempenho e use-o para projetar necessidades de capacidade de produção. Os **teste de segurança** validam limites de permissão, controles de acesso a dados e autorização de ação. O teste de segurança confirma: agentes não podem acessar dados não autorizados, agentes não podem realizar ações não autorizadas, a injeção de prompt não pode escalar privilégios e o registro de auditoria captura todas as atividades do agente. Integre a varredura de segurança de código estático ao pipeline de implementação usando o Salesforce Code Analyzer, que verifica vulnerabilidades de segurança no Apex, Fluxos, Lightning e Visualforce e pode ser executado em integração/implementação contínua (CI/CD) por meio de sua interface de linha de comando (CLI) ou ação do GitHub. Use testes de segurança de IA/agente especializados para detectar vulnerabilidades de injeção de prompt e riscos de exposição de dados confidenciais, pois essas são ameaças de entrada de LLM em tempo de execução fora do escopo da análise de código estático. ### Disciplina de gerenciamento de mudanças Aplique a disciplina de gerenciamento de mudanças a implantações do agente garantindo que as alterações sejam documentadas, revisadas e comunicadas. A **documentação de alteração** captura: - O que mudou – modificações de prompt, atualizações de configuração, alterações de modelo - Por que essa alteração foi feita – melhoria de qualidade, otimização de custo, correção de bugs - Qual teste validou essa alteração – resultados de teste, pontuações de qualidade, verificações de segurança - Que procedimento de reversão existe A documentação de alteração permite investigação de incidentes, relatórios de conformidade e transferência de Knowledge. Alterações documentadas criam uma organização de aprendizado que se baseia na experiência anterior em vez de descobrir novamente as lições. O **planejamento de comunicação** notifica as partes interessadas sobre alterações de agente, incluindo usuários afetados, equipes de operações, equipes de suporte e partes interessadas de negócios. A comunicação deve descrever: o que está mudando, quando a alteração é implementada, quais benefícios os usuários verão, quais riscos existem e com quem contatar em caso de problemas. Estabeleça modelos de comunicação para diferentes tipos de alteração padronizando mensagens e reduzindo a sobrecarga de preparação da implementação. O cronograma de **implementação** informa implantações do agente durante períodos de uso baixo por dados do Monitoramento de evento que mostram padrões de uso reais. Evite implantações durante uso de pico, fechamento de fim de mês, fechamento de fim de trimestre ou eventos comerciais importantes. Comunique janelas de implementação, incluindo duração esperada e linha do tempo de decisão de reversão. Considere agendar alterações importantes para a semana do início ao meio e evitar implantações de fim da semana para que os problemas possam ser resolvidos com recursos adequados. Priorize o reversão rápida e o monitoramento forte pós-implementação em relação a qualquer regra de calendário fixa. **Mudar janelas e congeladores** protege períodos críticos de funcionamento. Estabeleça períodos de congelamento de alteração antes de grandes eventos de negócios (fim do ano fiscal, lançamentos de produtos e grandes campanhas de marketing) evitando problemas induzidos pela implantação durante períodos de alta participação. Calendário de alteração de documento comunicando anualmente períodos restritos com antecedência suficiente para permitir que as equipes planejem de acordo. Congelamentos excessivos desaceleram a velocidade; congelamentos insuficientes criam risco de negócios. ## Melhoria contínua para agentes ### Arquitetura de loop de feedback Estabeleça loops de feedback conectando a telemetria operacional à melhoria do agente. A **coleção de feedback do usuário** coleta feedback explícito por meio de perguntas ou pesquisas de acompanhamento. Colete feedback implícito por meio de taxas de conclusão, escalação para agentes humanos, novas tentativas de padrões e perguntas de acompanhamento indicando insatisfação. Combine sinais explícitos e implícitos, fornecendo uma perspectiva de qualidade abrangente. Colete feedback em linha, diretamente quando isso acontecer e não mais tarde. A coleta de feedback atrasada reduz as taxas de resposta e introduz um viés de recall. A **análise de uso** expõe padrões reais de conversa, como tópicos, perguntas e tendências recorrentes. Eles testam se a complexidade de um agente ganha sua manutenção, se os recursos não são usados devido à baixa capacidade de descoberta e se o uso real valida as pressuposições de design originais. Registros de conversas de consulta analisando tipos de pergunta, durações da conversa, taxas de sucesso por tópico e satisfação do usuário por características da conversa. A análise de padrão de uso orienta o refinamento rápido, a expansão da base de Knowledge e a priorização de recursos. A **análise de padrão de erro** identifica problemas de qualidade sistemáticos que exigem correção. Analise o agrupamento de registros de erro por tipo de erro, usuários afetados, padrões de conversa e distribuição temporal. Os padrões de erro revelam problemas de prompt, lacunas na base do Knowledge, problemas de integração ou casos de ponta que exigem tratamento. Priorize a remoção de erros por frequência e impacto. Erros de alta frequência que afetam muitos usuários exigem atenção imediata. Erros de baixa frequência podem representar casos de ponta aceitáveis, dependendo do impacto comercial e do custo da remediação. O **monitoramento de tendências de qualidade** rastreia a precisão, a relevância, a segurança e a satisfação ao longo do tempo, detectando a degradação antes que ela se torne grave. Estabeleça linhas de base de qualidade após a implantação inicial do agente. Monitore a qualidade em andamento em relação ao alerta de linha de base quando as tendências ultrapassarem limites aceitáveis. O monitoramento de qualidade revela se alterações de prompt, atualizações de modelo ou modificações de base do Knowledge melhoram ou prejudicam o desempenho permitindo decisões de melhoria orientadas por dados. ### Rastreamento de experiências e teste A/B Acompanhe experiências sistematicamente informando decisões de melhoria com evidências empíricas. A **estrutura de experimentos** fornece uma estrutura consistente para melhorias de teste, incluindo: - Hipótese – qual melhoria é esperada - Design experimental – como as variantes são implementadas - Métricas – quais resultados são medidos - Tamanho da amostra – quantas interações são necessárias para a validade estatística - Critérios de sucesso – quais resultados justificam a promoção Documente experiências antes da execução, evitando interpretação ambígua dos resultados. Critérios de sucesso predefinidos permitem decisões claras de promoção evitando longos debates sobre se os resultados são "bons o bastante". O rastreamento de **variante** registra quais usuários receberam quais variantes ativam a correlação de resultados. Acompanhe a atribuição da variante nos metadados da conversa habilitando a análise de qualidade, custo e satisfação por variante. A **validade estatística** garante que os experimentos sejam executados por tempo suficiente com um tamanho de amostra suficiente para conclusões confiáveis. Calcule o tamanho da amostra necessário antes de realizar experiências com base no tamanho do efeito esperado, nos requisitos estatísticos de potência e nas taxas de erro aceitáveis. Amostras insuficientes produzem resultados ruidosos que levam a decisões ruins. A **otimização de bandidos multiarmas** aloca dinamicamente mais tráfego a variantes com melhor desempenho durante os experimentos. Abordagens de bandidos multiarmas reduzem o custo da oportunidade de experimentação reduzindo a exposição a variantes inferiores enquanto ainda coletam dados suficientes para análise estatística. O **catálogo de experimentos** registra as variantes, os resultados e as decisões de cada experimento. Ele impede as equipes de testar novamente abordagens com falha, espalha aprendizado em toda a organização e cria um registro compartilhado do que realmente funciona. ## Resumo A excelência operacional para sistemas agentes exige estender as práticas DevOps tradicionais para lidar com características de IA exclusivas. A observabilidade abrangente permite entender o comportamento de agentes emergentes. O gerenciamento de ciclo de vida sistemático garante qualidade, segurança e controle de custo. Os procedimentos de resposta a incidentes lidam com modos de falha específicos do agente. A melhoria contínua transforma a experiência operacional em funcionalidade organizacional. Práticas-chave para excelência operacional em sistemas agentes: - Registre conversas concluídas, incluindo entradas, saídas, rastreamentos de raciocínio, ações e resultados. - Monitore a qualidade da resposta continuamente por meio de métricas de precisão, relevância, segurança e satisfação. - Detecte o desvio do modelo e as alterações comportamentais por meio da comparação de linha de base e da detecção de anomalia. - Avisos, configurações e modelos de controle de versão que habilitam o reversão e o teste A/B. - Implemente a distribuição gradual com sinalizadores de recurso e implantações canárias limitando o raio de explosão. - Projete quebradores de circuito e hierarquias de fallback para evitar falhas de agente em cascata. - Realize análises pós-incidente impecáveis com foco em melhorias sistemáticas. - Estabeleça portões de qualidade e processos de aprovação para evitar que agentes problemáticos cheguem à produção. - Crie loops de feedback conectando a telemetria operacional à melhoria do agente. - Rastreie experiências sistematicamente usando evidências empíricas para orientar decisões de aprimoramento. Organizações que investem em excelência operacional para agentes obtêm vantagem competitiva sustentável por meio de recursos de IA confiáveis e de alta qualidade que evoluem continuamente com as necessidades de negócios.

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

# Fairness Fairness ## Visão geral Em arquiteturas do Salesforce, a imparcialidade significa criar soluções que atendam os usuários de maneira justa por meio de interfaces acessíveis, detecção e mitigação de viés, decisões transparentes e governança ética. As previsões do Einstein influenciam os resultados que afetam os clientes e os funcionários, o que significa que os arquitetos devem projetar sistemas que produzam resultados justos em todos os grupos demográficos, ao mesmo tempo que permanecem acessíveis aos usuários com deficiência. O Salesforce fornece recursos de plataforma projetados para a justiça e nos esforçamos para estar em conformidade com a [WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/). Quando usado corretamente, o Salesforce Lightning Design System (SLDS) fornece componentes projetados para suportar essa meta. Vamos analisar em mais detalhes cada componente. - O Shield Platform Encryption protege atributos confidenciais, como dados demográficos, e o Monitoramento de evento fornece as trilhas de auditoria que dão suporte ao tratamento de dados transparentes. - A Camada de Trust do Einstein (ETL) captura uma trilha de auditoria segura para avisos e respostas de IA generativa para fins de monitoramento e conformidade. - O Experience Cloud inclui controles de acessibilidade. - A Trilha de auditoria de campo fornece a retenção de longo prazo do histórico de alteração de dados no nível do campo, que dá suporte à responsabilidade algorítmica quando os dados de decisão de IA são armazenados em campos rastreados. Esses recursos ajudam a reduzir os custos operacionais das práticas de equidade do Salesforce. No Salesforce, a imparcialidade opera em três dimensões para fornecer soluções. O design inclusivo ajuda a tornar os Componentes da Web Lightning (LWC), as páginas do Visualforce e os sites do Experience Cloud totalmente acessíveis, com navegação contínua por teclado, compatibilidade com o leitor de tela e acomodações de design cognitivo. As práticas de imparcialidade de IA ajudam as previsões do Einstein a produzir resultados justos usando detecção de viés, dados de treinamento diversos e monitoramento contínuo. A governança fornece os processos e os controles para manter a equidade conforme os modelos evoluem e os casos de uso se expandem. Negligenciar a imparcialidade cria um risco composto. Os sites do Experience Cloud inacessíveis podem expor as organizações a litígios da [Lei Americana de Pessoas com Deficiência (ADA)](https://www.ada.gov/law-and-regs/) e, para agências federais e seus prestadores de serviço, violações do cumprimento da [seção 508](https://www.section508.gov/). Dependendo da classificação de risco do sistema e das novas leis de responsabilização algorítmica, as previsões com viés do Einstein podem violar os requisitos da [Lei de IA da UE](https://eur-lex.europa.eu/eli/reg/2024/1689/oj). Apenas decisões automatizadas conduzidas por IA com efeitos legais ou semelhantes significativos que carecem de informações significativas sobre a lógica de decisão podem violar os direitos de informação [do artigo 22](https://gdpr-info.eu/art-22-gdpr/) do RGPD e [do artigo 15(1)(h)](https://gdpr-info.eu/art-15-gdpr/). Organizações que se dedicam à justiça tendem a reduzir o prejuízo previsto para os clientes, funcionários e comunidades afetados por seus sistemas. Falhas de imparcialidade podem causar dano material tangível a indivíduos afetados, incluindo prejuízo econômico, oportunidades negadas, sofrimento emocional e reforço da discriminação sistêmica. O alinhamento regulatório tende a seguir a atender bem as pessoas afetadas. ## Princípios de design Use esses princípios para orientar suas decisões arquitetônicas quanto à justiça na plataforma. - **Design para padrões de acessibilidade do Lightning.** Ao criar, use o Lightning Design System e os Componentes da Web Lightning padrão projetados para suportar a acessibilidade WCAG 2.2 AA sempre que possível. Quando você cria com SLDS, está aproveitando uma biblioteca em que a acessibilidade é um princípio essencial do design. Os componentes SLDS são testados quanto à acessibilidade do teclado e compatibilidade com tecnologia assistiva, e muitos incluem uma seção de acessibilidade com dicas do desenvolvedor. Se um componente personalizado for necessário, a implementação explícita de Rich Accessible Internet Applications ([WAI-ARIA](https://www.w3.org/WAI/standards-guidelines/aria/)), HTML semântico e padrões de navegação por teclado devem ser validados por meio de testes de tecnologia assistiva. - **Reduza e monitore o viés com as ferramentas certas para cada tipo de modelo.** Valide saídas de IA para resultados justos em grupos demográficos antes da implantação e continuamente na produção. Para modelos preditivos, capture dados de decisão por meio do Einstein Discovery e de instrumentos personalizados e analise-os no CRM Analytics para medir métricas de imparcialidade; para recursos de IA generativa e Agentforce, use a trilha de auditoria Einstein Trust Layer (ETL) de avisos e respostas. Documente as decisões para cumprir os requisitos de transparência regulatória. - **Leverage Shield Platform Encryption para controles de proteção de dados.** Use o Shield Platform Encryption com esquemas determinísticos para atributos confidenciais que exigem consultas de correspondência exata, ao mesmo tempo que protege dados pessoais. Encaminhe os registros do Monitoramento de evento para um sistema externo de Gerenciamento de eventos e Informações de segurança (SIEM) para dar suporte a trilhas de auditoria comprovadas por adulteração, quando o SIEM impõe a segregação de acesso e armazenamento de gravação única que excede as janelas de retenção nativas do Salesforce para os regulamentos necessários. - **Projete fluxos de trabalho de revisão para previsões de alta participação.** Configure processos de aprovação e mecanismos de revisão no Salesforce Flow para garantir que as previsões do Einstein que afetam decisões consequenciais recebam a revisão humana adequada. Use limites de confiança e regras de negócios para determinar quando as previsões precisam de validação antes de agir. - **Aplicar padrões para toda a organização (OWD) e segurança em nível de campo (FLS) para não discriminação.** Arquite padrões de acesso a dados usando OWD e FLS para restringir o acesso por padrão e conceda apenas o acesso adicional de que cada papel precisa usando regras de compartilhamento. Evite conceder aos perfis acesso excessivo que possa expor atributos confidenciais e permitir a tomada de decisão discriminatória. - **Habilite a agência do usuário por meio do consentimento de plataforma.** Use os recursos de gerenciamento de consentimento no Data 360 ou objetos de consentimento personalizados com a Trilha de auditoria de campo para rastrear o consentimento de IA granular por caso de uso. Permita que os usuários recusem recursos conduzidos por IA e forneçam alternativas humanas (quando possível). ## Qualidade dos dados e equidade representativa As decisões de arquitetura de dados determinam as populações que se tornam visíveis e invisíveis nos sistemas do Salesforce. A baixa qualidade dos dados não é apenas um problema técnico. Ele se torna um problema de imparcialidade quando lacunas de dados sistematicamente desvantagem grupos demográficos específicos. ### Dados ausentes criam populações invisíveis - **Revise os campos obrigatórios para a disponibilidade dos dados.** Quando os campos obrigatórios presumem a disponibilidade de informações que varia entre os dados demográficos, a completude dos dados se torna discriminatória. Os usuários que não conseguem fornecer as informações necessárias ficam invisíveis em sistemas que rejeitam registros incompletos. * Exigir endereços de email exclui populações que não têm acesso à Internet confiável ou endereços de email pessoais. * Exigir números de seguridade social (SSN) dos EUA exclui clientes internacionais e imigrantes recentes que ainda não receberam um SSN. * Exigir endereços ruas exclui pessoas sem-teto e usuários com endereços não tradicionais. - **Auditar justificativas de negócios para campos obrigatórios.** Para cada campo obrigatório, é importante documentar por que as informações são obrigatórias em vez de opcionais. Se os processos puderem funcionar sem determinados dados por meio de abordagens alternativas, torne esses campos opcionais e projete sistemas para lidar com valores ausentes com facilidade. Isso ajuda a garantir que os usuários que não puderem fornecer esses dados não sejam excluídos. ### Arquitetura de campo de nome e viés cultural Campos de nome que seguem convenções de nomenclatura ocidentais (Primeiro nome, Sobrenome) podem excluir culturas com diferentes práticas de nomenclatura. Muitas culturas usam: - Nomes únicos (ou monônimos) sem nomes de família - Sistemas patronímicos em que o sobrenome muda de modo generalizado - Vários nomes ou nomes de família fornecidos - Nomes que mudam com base em eventos da vida ou contexto social - Nomes em que "primeiro" e "último" são distinções culturalmente sem significado Projete a arquitetura de nome usando um único campo de nome completo ou uma estrutura flexível de várias partes que acomode convenções de nomenclatura comuns. Evite fazer pressuposições sobre ordenação de nomes, padrões de herança ou normas culturais. Teste a arquitetura de nomes usando diversos nomes internacionais para garantir que os campos de nome aceitem: - Nomes de palavra única (por exemplo, Sukarno, Cher e Teller) - Nomes longos que excedem os limites de comprimento de campo comum - Nomes com diácritos, apostrofes, hifens e espaços - Nomes com scripts não latinos (por exemplo, árabe, chinês, cirílico e Devanagari) Quando a validação de nome rejeita o nome legítimo de um usuário, ele é rejeitado pelo sistema com base em sua identidade cultural. ### Dados de endereço e viés geográfico Os serviços de validação de endereço geralmente são otimizados para formatos dos EUA e da Europa Ocidental e geralmente não reconhecem: - Formatos de endereço internacional com ordem de campo diferente - Endereços rurais sem nomes de ruas - Endereços militares (por exemplo, APO e FPO) - Caixas de PO e locais de entrega alternativos - Terras tribais com sistemas de endereço exclusivos - Países com scripts não latinos para componentes de endereço Quando as validações de endereço rejeitam formatos de endereço não tradicionais, isso impede a criação de conta, o envio e a entrega de serviços para usuários cujos endereços não correspondem às expectativas do banco de dados de validação. Aqui estão algumas maneiras de projetar validações de endereço pensando em acessibilidade: - Implementar validação de endereço permissiva. - Aceite a entrada de endereço em forma livre quando as validações estruturadas falharem. - Armazene endereços conforme inseridos pelos usuários, em vez de forçar os usuários a fazer correções inválidas. - Use a validação de endereço para aprimoramento de dados e detecção de duplicação, não para validar a formatação de endereço. Em vez de bloquear capturas de dados antecipadamente, crie a verificação de endereço em processos de cumprimento em que a precisão do endereço importa operacionalmente. ### Viés do método de comunicação As pressuposições de acesso universal para canais de comunicação específicos excluem populações com diferentes preferências ou acesso à tecnologia. A comunicação somente por email exclui: - Usuários sem acesso confiável à Internet - Populações mais idosas que estão menos à vontade usando email - Usuários em regiões em que SMS ou aplicativos de mensagens são o método de comunicação principal A comunicação somente por telefone exclui: - Usuários que são surdos e com dificuldade auditiva - Usuários sem acesso telefônico ou que usam telefones compartilhados Projete uma arquitetura de comunicação do Omnichannel que permita aos usuários controlar as preferências de canal. Armazene métodos de comunicação preferenciais em registros de Contato e respeite de modo consistente as preferências em todos os sistemas de comunicação de saída. Forneça uma variedade de alternativas de comunicação em vez de presumir que os métodos de canal único funcionem universalmente. ### Dados demográficos e autoidentificação voluntária Coletar dados demográficos para monitoramento de equidade requer uma arquitetura cuidadosa para evitar o uso incorreto. A coleta e o processamento de dados demográficos dependem da jurisdição e são legalmente restritos (na UE, o [artigo 9](https://gdpr-info.eu/art-9-gdpr/) do RGPD trata-os como dados de categorias especiais que exigem uma base jurídica específica; nos EUA, o monitoramento de viés geralmente depende da autoidentificação voluntária do EEO). Quando há uma base legal, as organizações usam dados demográficos para: - Monitore métricas de imparcialidade estratificadas por grupos protegidos - Detectar viés em sistemas de automação e IA - Demonstrar a conformidade regulatória com os requisitos anti-discriminação A coleta de dados demográficos cria determinados riscos: - Os dados podem ser usados para fins discriminatórios se os controles de acesso falharem - Os usuários podem desconfiar dos métodos de coleta e fornecer dados imprecisos - A coleção pode parecer invasiva ou discriminatória Arquite a autoidentificação voluntária e projete a coleção de dados demográficos usando informações que são: - Explicado claramente com um propósito transparente (por exemplo, monitoramento de equidade ou relatório de conformidade) - Voluntário e inclui uma opção "Preferir não responder" que está sempre disponível - Separado de dados operacionais com FLS rígida para evitar acesso impróprio - Agregado para relatórios e análise e não vinculado a decisões individuais - Monitorado por meio do Monitoramento de evento Shield para auditoria de padrão de acesso É importante documentar em políticas de privacidade exatamente como os dados demográficos serão e não serão usados. Violar a Trust do usuário através do uso de dados não divulgados pode prejudicar gravemente a credibilidade, o que pode ser difícil de recuperar. ### Aprimoramento de dados e viés de terceiros Aprimoramento de dados de terceiros que anexa dados demográficos, firmográficos ou comportamentais a registros do Salesforce pode introduzir um viés por meio de: - inferências imprecisas baseadas em estereótipos - Cobertura incompleta com lacunas correlacionadas às demografias - Algoritmos proprietários que usam propriedades de equidade desconhecidas - Dados adquiridos de registros históricos com viés Antes de implementar serviços de aprimoramento de dados, é importante auditar: - Testes de imparcialidade do fornecedor e práticas de mitigação de viés - Cobertura e precisão dos dados entre grupos demográficos - Inferir metodologias e recursos usados para criar previsões - Restrições de uso de dados contratuais e políticas de retenção Lembre-se de que, quando dados de terceiros entram na sua organização do Salesforce, isso pode afetar decisões, criando um viés introduzido pelo fornecedor que também se reflete como um viés na sua organização. ## Acessibilidade com Lightning e Experience Cloud Em contextos do Salesforce, a acessibilidade se refere à arquitetura de Componentes da Web Lightning, páginas do Visualforce e sites do Experience Cloud que funcionam para usuários com deficiência. Os componentes padrão do Lightning fornecem acessibilidade de linha de base quando usados corretamente; no entanto, o desenvolvimento personalizado e a configuração do Experience Cloud exigem uma implementação explícita de acessibilidade. ### Padrões de acessibilidade do Lightning Design System Os componentes do Lightning Design System são projetados para oferecer suporte à conformidade WCAG 2.2 AA quando usados conforme projetado. O Salesforce busca, mas não certifica, a conformidade total. O desvio dos padrões SLDS ou a criação de componentes personalizados sem consideração de acessibilidade cria barreiras para usuários com deficiência. Componentes da Web Lightning padrão fornecem acessibilidade integrada. Componentes como Lightning, Lightning, Lightning e Lightning incluem automaticamente atributos de ARIA adequados, associações de rótulo, navegação do teclado e gerenciamento de foco. Quando possível, use componentes padrão em vez de criar alternativas personalizadas semelhantes, mas que possam não ter a infraestrutura de acessibilidade adequada. - **Usar HTML semântico em Componentes da Web Lightning personalizados.** Ao criar componentes personalizados, use elementos HTML semânticos (
,