Leia sobre nossas agendas de atualização aqui.

As soluções resilientes mantêm uma alta qualidade de serviço mesmo quando ocorrem falhas. Se o desempenho for reduzido ou o serviço for interrompido, a solução será recuperada de modo rápido e eficaz.

A resiliência de uma solução se baseia em duas principais qualidades:

• Rigidez: Quando ocorrem problemas, a solução resiste e os suporta.
• Elasticidade: Depois que os problemas são resolvidos, a solução volta ao seu estado ou formato ideal.

Para arquitetar sua solução para resiliência, você deve projetar para tenacidade e elasticidade, garantindo durabilidade e recuperação rápida face a alterações planejadas e não planejadas.

Em contextos de tecnologia, considere um sistema ou solução como uma coleção de componentes interdependentes que se coordenam para realizar metas compartilhadas. Cada componente tem o potencial de falha. Problemas nesses componentes, de defeitos de código e configuração a problemas de rede e hardware, podem causar comportamento inesperado e indesejado. Um sistema demonstra um comportamento resiliente quando um ou mais componentes falham, mas o sistema geral continua funcionando ou retorna rapidamente a um estado estável.

Para melhorar a resiliência de suas soluções do Salesforce, recomendamos focar três hábitos importantes.

• Gerenciamento de ciclo de vida do aplicativo (ALM) – Como as equipes gerenciam o software ao longo de seu ciclo de vida, desde a criação até a aposentadoria
• Resposta a incidentes – Como as equipes identificam, solucionam e impedem problemas que afetam a disponibilidade ou a segurança de um sistema
• Planejamento de continuidade – Como as equipes planejam que suas pessoas e sistemas continuem funcionando quando eventos não planejados causam problemas

O Gerenciamento de ciclo de vida do aplicativo (ALM) é uma prática para gerenciar de modo holístico o software ao longo de seu ciclo de vida, da criação até a descontinuação. O ALM é uma pedra angular da resiliência do sistema e engloba pessoas, processos, ferramentas e disciplinas relacionadas ao ciclo de vida do aplicativo. Essas disciplinas incluem DevOps e metodologias de entrega, capacidade de observação, estratégias de teste, governança e CI/CD.

Quando uma empresa pratica um ALM eficaz, suas equipes reagem rapidamente às mudanças e seus aplicativos acompanham os requisitos de negócios em evolução sem comprometer a estabilidade ou a qualidade.

Por outro lado, sem um ALM saudável, as equipes têm dificuldade em cada estágio do ciclo de vida do aplicativo.

Os sintomas de um ALM ruim incluem:

• Ciclos de desenvolvimento lentos e sujeitos a erros
• Implantações intensivas e difíceis
• Problemas de alta gravidade ou bugs descobertos em ambientes de produção e pós-QA
• Agentes de IA que alucinam ou se comportam de modo inconsistente
• Implantações frequentes de reversões ou correções rápidas necessárias para estabilizar as versões

Como o ALM afeta quase todos os aspectos de uma solução, estabelecer práticas de ALM claras e eficazes para sua solução é uma parte essencial do seu trabalho de arquitetura.

Crie práticas do ALM melhores focando três áreas importantes.

• Gerenciamento de lançamento – Planejar, sequenciar, controlar e migrar alterações para diferentes ambientes
• Estratégia ambiental – Uma estratégia para como usar e gerenciar aplicativos em ambientes de destino durante o desenvolvimento e testes
• Estratégia de sinalização – Definição de sinais críticos e instrumentação de aplicação usada para detectar e remediar falhas no sistema antes da degradação ocorrer
• Estratégia de teste – Os princípios e padrões que orientam como você planeja e executa testes para avaliar o sucesso de suas aplicações durante os processos do ALM

O gerenciamento de versão envolve planejamento, sequenciamento, controle e migração de alterações para um ou mais ambientes. Uma única versão é um grupo de alterações planejadas que uma equipe move para um ambiente de destino ao mesmo tempo.

Liberar uma alteração em um sistema introduz risco a ela. Se o sistema estiver em um estado estável antes da alteração, ele passará para um novo estado, em que também estará mais vulnerável a riscos de alterações futuras. Se qualquer alteração futura acionar um estado não controlado e instável no sistema, isso poderá causar um incidente crítico. Em uma arquitetura de soluções, projetar para versões resilientes é mais do que apenas testar alterações individuais de maneira eficaz. Também envolve planejar como introduzir alterações em seus sistemas e seus usuários com segurança.

O trabalho que suas equipes fazem depende de informações de versão previsíveis e precisas. Em seus processos de gerenciamento e habilitação de mudanças, seja claro quais alterações podem ser transferidas para seu sistema. Em seus processos de gerenciamento e habilitação de versão, especifique como e com que frequência as alterações são liberadas para seu sistema.

As partes interessadas também se preocupam com as informações da versão, especialmente se estiverem relacionadas a recursos ou correções de bug que solicitam. Para criar Trust em sua solução e demonstrar valor para suas partes interessadas, estabeleça agendas de lançamento consistentes e claras e envie artefatos de lançamento estáveis.

Para estabelecer um gerenciamento de versão eficaz para o Salesforce:

• Alinhar-se com a governança de arquitetura e desenvolvimento. Garanta que as versões sejam planejadas com antecedência para estarem alinhadas a todos os fóruns e controles de governança relevantes. Antes de começar o desenvolvimento, obtenha todos os casos de uso do Agentforce priorizados revisados e aprovados pelo Conselho de IA. Obtenha casos de uso do Agentforce de alto risco revisados por equipes de uso legal e ético.Use listas de verificação e documentação de implementação para rastrear artefatos de implementação, como nomes de API do agente do Agentforce, em relação a atividades de governança.
• Não use processos de desenvolvimento ou versão baseados em organização. Esse paradigma reflete tecnologias mais antigas e limitadas para desenvolvimento e liberação. Com o Salesforce CLI, as equipes agora podem adotar recursos de desenvolvimento e liberação orientados por código-fonte.
• Escolha o mecanismo de liberação mais estável possível. Essa abordagem realiza duas coisas. Primeiro, ele minimiza a duração das janelas de versão e interrupções de serviço. Em segundo lugar, ele permite comportamentos de versão altamente controlados e previsíveis. Quanto mais estável for o mecanismo de liberação, menor será a probabilidade de que as versões introduzam alterações que exigem correções rápidas ou reversões. Caso ocorra um problema imprevisto, os mecanismos de versão estáveis também criam maneiras mais simples para que a equipe de suporte ou os administradores do sistema realizem reversões.

Os melhores mecanismos de liberação para sua equipe são as opções mais estáveis para as quais sua equipe tem as habilidades necessárias. Estes são os mecanismos de liberação recomendados, listados em ordem de estabilidade. Todos eles são compatíveis entre si, portanto, use vários deles juntos se isso for melhor para sua empresa.

• Pacotes desbloqueados – Os pacotes desbloqueados são o artefato de versão mais estável. Implantar alterações instalando um pacote é a maneira mais rápida e mais previsível de introduzir alterações. Os pacotes usam controle de versões, que permite gerenciamento de alteração robusto e reversões refinadas adequadas ao administrador do sistema. E os pacotes exigem gerenciamento de metadados forte, o que pode ajudá-lo a identificar dependências mal gerenciadas mais cedo. Eles também criam pipelines de desenvolvimento e artefatos auditáveis. Consulte Pacotabilidade.
• DevOps Center – O DevOps Center permite que equipes de entrega com conjuntos de habilidades de código reduzido ou pro-código usem o controle de origem, trabalhem de modo colaborativo em alterações e definam caminhos de liberação comuns. O DevOps Center integra-se ao controle de origem e permite o controle de apontar e clicar em alterações e implantações.
• Implantações de metadados e desenvolvimento conduzidos por origem usando o Salesforce CLI – Se você não puder usar pacotes, use o Salesforce CLI para seu desenvolvimento conduzido por origem e implantação de metadados. Não implemente metadados usando o formato package.xml mais antigo, que segue uma estrutura diferente do formato de origem recomendado. O formato de origem evoluiu para dar suporte ao desenvolvimento de pacotes, fluxos de trabalho de organização teste e rastreamento de alteração mais granular em sandboxes. O formato é mais legível, permite mais desacoplamento de tipos e dependências de metadados complexos e oferece muito mais controle sobre os manifestos de implementação.
• Nomeie suas versões. Dê a suas versões identificadores claros para ajudar suas equipes e partes interessadas a se manterem alinhadas. No Salesforce, o nome de cada versão principal começa com "Spring", "Summer" ou "Winter" seguido pelo ano da versão (por exemplo, "Summer '25"). Se você ainda não tiver uma convenção de nomenclatura para definir e organizar versões em sua empresa, estabeleça uma e use-a. Usar nomes de versão claros facilita a manutenção da organização em todos os estágios de planejamento, desenvolvimento e entrega em todos os sistemas de suas equipes. Use seus nomes de versão em seu roteiro para comunicar claramente às suas partes interessadas quais mudanças estão chegando e quando. Use seus nomes de versão em sua documentação, registros de alteração, descrições de trabalho, comentários de código e ramificações do controle de origem para que você possa rastrear e auditar facilmente seus artefatos de desenvolvimento.
• Em um manifesto de versão, gerencie dependências bem. Os metadados do Salesforce têm dependências integradas. Um motivo comum para que as implantações do Salesforce falhem é que as dependências não são gerenciadas adequadamente. Escolher um mecanismo de versão estável, conforme descrito anteriormente, pode ajudar a expor dependências mal gerenciadas mais cedo em seu ciclo de desenvolvimento. Um dos principais motivos pelos quais os pacotes desbloqueados são o veículo de versão mais estável é seu gerenciamento de metadados forte, que é necessário para o desenvolvimento e a criação de pacotes. Se você ou suas equipes de gerenciamento de versão não entenderem as dependências integradas entre os tipos de metadados do Salesforce, não será possível detectar proativamente combinações problemáticas em seus manifestos de implementação e versão. Consulte Gerenciamento de dependência.

Os padrões e antipadrões para ALM mostram como é o gerenciamento de versão adequado e ruim para uma organização do Salesforce. Use os padrões para validar seus designs antes de criar ou para identificar locais em seu sistema que precisam ser refatorados.

Para aprender mais sobre ferramentas do Salesforce para gerenciamento de versão, consulte Salesforce Tools for Resiliency.

O Salesforce oferece uma variedade de ambiente para você usar durante os ciclos de desenvolvimento e teste de aplicativos. Uma estratégia de ambiente eficaz para o Salesforce exige entender como usar os ambientes e qual é a aparência de um bom gerenciamento. No ALM, a utilidade de um ambiente de desenvolvimento ou teste depende de sua fidelidade e isolamento da produção.

Uma boa estratégia de ambiente oferece vários benefícios.

• Maior fidelidade à produção
• Configurações e reduções de ambiente mais rápidas
• Mais ágil no desenvolvimento e nos testes
• Segurança aprimorada em todo o pipeline
• Menos ruído e conflito em todos os estágios de entrega
• Equipes de desenvolvimento mais felizes

As equipes costumam ter dificuldade para realizar esses benefícios. Os desafios para aproveitar ao máximo seus ambientes de desenvolvimento e estratégia podem vir de várias fontes. Uma origem provável é o tipo de modelo de desenvolvimento que suas equipes seguem.

Na abordagem de desenvolvimento mais antiga baseada em organização, cada ambiente precisava atender a várias funções. Além de ser o local em que sua equipe realiza seus vários tipos de trabalho, ela precisava ser a origem para seus artefatos de versão (ou seja, os metadados que você queria implementar em uma versão). Como os ambientes não eram fáceis de configurar ou desmontar, eles costumavam estar sobrecarregados e cheios de conflitos de metadados entre equipes, e não contribuíam com velocidade ou flexibilidade significativas para o ALM em geral.

Usar um modelo de desenvolvimento baseado em origem muda fundamentalmente o relacionamento que os ambientes têm com suas versões e artefatos de versão. Nesse modelo, o controle de origem é a origem dos metadados que você deseja liberar. Ambientes são apenas locais em que suas equipes trabalham.

No entanto, seguir o modelo de desenvolvimento baseado em origem não apenas garante uma boa estratégia de ambiente. Mesmo com o controle de origem, as equipes ainda podem lutar para configurar condições para testar integrações com sistemas externos; configurações que dependem de metadados que não estão no controle de origem, como pacotes gerenciados ou personalizações que dependem de dados), e assim por diante. Em determinadas circunstâncias, os desafios de um modelo baseado em origem são semelhantes aos desafios típicos de um modelo baseado em organização.

Para desenvolver uma estratégia de ambiente eficaz:

• Adote um modelo de desenvolvimento e liberação orientado por origem. Pare de usar modelos de desenvolvimento baseados em organização. Consulte Gerenciamento de versão.) Você deve remover seus ambientes do que você implementa para eles para criar uma estratégia de ambiente saudável e versões mais saudáveis.
• Entenda os tipos de trabalho que cada ambiente suporta. Os tipos de ambiente compatíveis com o Salesforce têm diferentes recursos e limites. Ao projetar sua estratégia de ambiente, considere o que os ambientes podem e não podem fazer. Certifique-se de que suas equipes trabalhem em um ambiente que tenha as funcionalidades necessárias. Para orientação, consulte esta visão geral dos ambientes de desenvolvimento do Salesforce e seus recursos.

Consulte esta tabela para saber quais recursos e ambientes usar para várias tarefas de desenvolvimento comuns.

Além disso, para agentes Agentforce que usam recursos como a Biblioteca de dados do Einstein, artigos do Knowledge e dados não estruturados, os testes abrangentes são limitados, a menos que você tenha um sandbox do Data 360. Você também precisa de um sandbox do Data 360 para garantir condições de teste precisas.

• Desacoplar ambientes de artefatos de liberação. Não use desenvolvimento baseado em organização. Trate ambientes como locais em que o trabalho acontece por um período fixo. Considere o estado dos metadados em um ambiente como separado de seus artefatos de versão. Se um código ou ajuste for "descoberto" em um ambiente, ele deverá estar comprometido com o controle de origem, tornando-o um artefato de versão.

  • Os ambientes são efêmeros. Crie processos para que você possa criá-los e destruí-los o mais rapidamente possível.
  • Os artefatos duram. Eles pertencem ao controle de origem.

• Desacoplar ambientes dos caminhos de liberação. É comum ver caminhos de versão obrigatórios que exigem que as alterações sejam implementadas em ambientes específicos. Geralmente, essa abordagem é implementada para estabelecer um proxy para validar a maturidade do aplicativo ou a estabilidade da versão. As equipes também podem usá-lo para tentar minimizar o número de ambientes em que precisam configurar uma infraestrutura de teste complexa. Em paradigmas baseados em origem, você tem mais flexibilidade em como e onde validar e testar alterações.

  • Os estágios de liberação se aplicam a artefatos de liberação, não a ambientes. Não crie um ambiente apenas com a finalidade de "recolher" todas as alterações em um estágio de versão específico. É para isso que o controle de origem, especialmente a ramificação, serve. Use estratégias de ramificação no controle de código-fonte para organizar quais alterações implementar em quais ambientes. Dependendo do trabalho necessário, talvez seja necessário implementar todos os metadados em uma versão em um ambiente. A ramificação permite fazer isso. Com algumas exceções, todos os ambientes de desenvolvimento devem ser atualizados ou destruídos assim que o trabalho relevante for concluído. Certifique-se de sincronizar quaisquer alterações nos metadados que ocorram em um ambiente específico, e que você deseja manter, com o controle de origem.
  • Os ambientes são tão úteis quanto sua fidelidade à produção. Otimize os fluxos de trabalho ou a automação de configuração de ambiente para que você possa desfazer ou atualizar os ambientes o mais rapidamente possível. Considere qualquer configuração que impeça que você realize atualizações de ambiente mais rápidas e frequentes como um risco crítico para a resiliência geral de seus processos do ALM. Se você tiver um trabalho de remediação relacionado, adicione-o aos seus planos e priorize-o. Explore como adotar unidades modulares mais soltas em seu sistema. Eles permitem que as equipes realizem mais tipos de desenvolvimento em organizações teste e liberam alocações de sandbox para outro trabalho. Não se esqueça dos recursos que as organizações teste fornecem para testar recursos que você não tem em produção, seja porque você não adquiriu licenças para elas ou não as habilitou.
  • Em ambientes que usuários de negócios ou usuários finais podem acessar, permita que esses usuários se concentrem no que é importante para eles. Não tenha ambientes genéricos e não diferenciados em que muitos grupos diferentes de usuários finais ou partes interessadas da empresa tentem realizar trabalhos relacionados ao ALM. Convide e ative partes interessadas específicas em ambientes específicos para realizar trabalhos específicos. Avalie cuidadosamente qualquer processo que coloque os usuários finais ou as partes interessadas da empresa em um ambiente com mais dados do que um sandbox de Cópia parcial pode suportar. Certifique-se de que o volume de dados seja necessário para o trabalho a ser feito. Planeje os testes de aceitação do usuário e os ciclos de desenvolvimento de estágio inicial para que ocorram o mais próximo possível. Otimize todos os estágios de teste para permitir ciclos de iteração e feedback mais rápidos e anteriores para suas equipes de desenvolvimento e usuários finais. Consulte estratégia de teste.

• Criar caminhos de versão diferentes para diferentes tipos de alterações. Nem todas as alterações exigem que os mesmos tipos de trabalho do ALM sejam concluídos na mesma ordem. Fazer com que os usuários finais realizem testes de aceitação para pequenas alterações em componentes de back-end de um sistema provavelmente não é um bom uso do tempo deles. No entanto, a aceitação do usuário e o teste de escala podem ser extremamente valiosos durante o desenvolvimento inicial de um aplicativo móvel. Identifique caminhos de versão para diferentes categorias de alterações, como alto risco, médio risco e baixo risco.

  • Alto risco: As alterações afetam clientes, parceiros ou todos os usuários internos. As alterações afetam a segurança ou a integração. As alterações adicionam uma funcionalidade nova e complexa.
  • Risco médio: As alterações afetam mais do que um limite definido de usuários internos. As alterações afetam modelos de dados, automação que realiza operações de dados ou integração.
  • Baixo risco: Afeta diretamente menos que um limite definido de usuários internos. Não inclui alterações de segurança, modelos de dados ou automações envolvendo operações de dados ou integração.

• Não permita que ambientes sobrecarregados existam. Uma falta de disciplina na priorização, definição de escopo e sequenciamento de trabalho inevitavelmente leva a ambientes de desenvolvimento sobrecarregados, com volumes de trabalho excessivos, muitos, muito diferentes. Ambientes sobrecarregados criam altos níveis de estresse, ambiguidade e conflito entre as equipes de desenvolvimento. Eles também criam ruído em pipelines de desenvolvimento e impedem os esforços de controle de qualidade. Além desses impactos negativos, ambientes de desenvolvimento sobrecarregados são ameaças graves à manutenção e à segurança do ambiente. Considere a sobrecarga como um sintoma de possíveis problemas em seus processos do ALM. Investigue quaisquer problemas de causa-raiz e solucione-os. Se você ainda enfrentar a sobrecarga, você pode comprar sandboxes adicionais.

A lista de padrões e antipadrões para ALM mostra como é o gerenciamento de ambiente adequado e ruim em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas.

Para aprender mais sobre ferramentas do Salesforce para gerenciamento de ambiente, consulte Salesforce Tools for Resilience.

Uma estratégia de sinalização define os sinais críticos e a instrumentação de aplicativo necessários para detectar, diagnosticar e remediar falhas antes que elas entrem em cascata para degradação em todo o sistema. A instrumentação eficaz transforma aplicativos de vítimas passivas de falha em participantes ativos em sua própria resiliência, capazes de detectar problemas, adaptar seu comportamento e coordenar uma degradação agradável quando necessário.

Quando os aplicativos implementam uma instrumentação abrangente, eles obtêm a capacidade de se autorregular sob estresse, comunicar seu status de saúde aos operadores e participar de esforços de recuperação coordenados. Esses recursos permitem que os sistemas mantenham a qualidade do serviço mesmo quando componentes individuais sofrem problemas. Por outro lado, sem a instrumentação adequada, os aplicativos se tornam caixas negras que falham silenciosamente até que sintomas catastróficos apareçam. As equipes reagem a problemas apenas depois que os usuários os relatam, e a solução de problemas se torna um exercício em arqueologia, em vez de observação.

• Detecte falhas no aplicativo. Os aplicativos devem se instrumentar para detectar e responder a padrões de falha comuns que surgem sob carga pesada. Considere a saturação da fila. Quando as filas de mensagens são preenchidas mais rapidamente do que podem ser processadas, os aplicativos não instrumentados continuam aceitando o trabalho até que ocorram escassez de memória ou cascata de tempo limite. Os aplicativos instrumentados adequadamente monitoram a profundidade da fila, as taxas de rejeição e a latência de processamento, acionando respostas defensivas quando os limites são excedidos.

• Gerenciar eficazmente os sinais de fora da aplicação: O tratamento de sinais do sistema operacional representa outro ponto crítico de instrumentação. Os aplicativos devem registrar manipuladores para sinais de encerramento (SIGTERM, SIGINT) para habilitar o desligamento fácil. Durante o desligamento, os aplicativos devidamente instrumentados param de aceitar o novo trabalho, permitem que as solicitações em andamento sejam concluídas, esvaziam as margens, fecham as conexões de forma limpa e cancelam o registro da descoberta de serviço. Esse desativação orquestrada impede a perda de dados e permite que os balanceadores de carga redirecionem o tráfego sem interrupção.

• Instrumento para cenários de falha complexos: Além desses padrões básicos, os aplicativos devem instrumentar modos de falha mais sutis. Identificar falhas cinza, em que os componentes parecem saudáveis para alguns observadores enquanto falham para outros, exige correlação de sinais internos e externos. Um aplicativo pode instrumentar seu pool de conexão de banco de dados para relatar verificações de saúde bem-sucedidas enquanto acompanha simultaneamente as taxas de conclusão da transação que revelam degradação crescente. Estratégias de instrumentação efetivas estratificam vários pontos de observação.

  • As métricas de negócios rastreiam indicadores de sucesso específicos do aplicativo, como taxas de conclusão de pedidos ou qualidade dos resultados da pesquisa.
  • As métricas do sistema monitoram a utilização do recurso, as distribuições de latência e as taxas de erro.
  • As sondas sintéticas exercem continuamente caminhos críticos para detectar degradação antes que os usuários a encontrem.
  • O rastreamento distribuído fornece visibilidade em nível de solicitação entre limites de serviço.

Esses sinais são expostos por meio de interfaces padronizadas que permitem que sistemas automatizados e operadores humanos avaliem a integridade do aplicativo. A própria instrumentação torna-se parte da estratégia de resiliência da aplicação, permitindo que os disjuntores funcionem com base nas taxas de erro, os escaladores automáticos respondam às profundidades da fila e os operadores tomem decisões informadas durante incidentes.

Os padrões e antipadrões para ALM mostram a aparência de uma estratégia de sinalização adequada e ruim em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas.

Para aprender mais sobre ferramentas do Salesforce para uma estratégia de sinalização, consulte Salesforce Tools for Resilience.

Uma estratégia de teste é um conjunto de princípios e padrões orientadores para como planejar e executar testes que medem o sucesso e a falha de solicitações durante processos do ALM. Uma estratégia de teste mantém cada parte interessada envolvida no teste informada e alinhada à prioridade, ao propósito e ao escopo de um determinado teste. Também ajuda as equipes de projeto a criar planos de teste eficientes e fundamentados.

Geralmente, desenvolvedores ou especialistas em garantia de qualidade e teste estão envolvidos na criação e execução de testes específicos. Uma estratégia de teste ajuda a garantir que esses indivíduos saibam quais tipos de testes devem ser realizados para um determinado projeto e em que sequência realizá-los. Uma estratégia de teste também ajuda a garantir que as equipes tenham o que precisam para criar testes, planos de teste e artefatos bem formados (por exemplo, conjuntos de dados de teste, dispositivos e simuladores de tráfego ou rede).

Uma estratégia de teste eficaz cria uma visão clara de como, quando, onde e por que executar diferentes tipos de teste, incluindo testes de unidade, testes de interface do usuário e testes de regressão, em várias combinações e condições para descobrir como seu sistema e quaisquer alterações no voo se comportarão. Uma estratégia de teste eficaz produz testes que mostram a conformidade de um sistema com requisitos não funcionais, como escalabilidade, confiabilidade e usabilidade, que podem ser difíceis de medir por meio de um único tipo de teste.

Para criar estratégias de teste eficazes para o Salesforce:

• Teste iterativamente, com frequência e por meios automatizados o máximo possível. Projete e implemente a automação de teste que permite que as equipes executem uma variedade de tipos de teste com base em uma variedade de cargas de trabalho. Orquestre várias execuções de teste para que aconteçam automaticamente quando as alterações entram no controle de origem. Essa abordagem permite que as equipes identifiquem e lidem com regressões proativamente logo no início. Use integração contínua/entrega contínua (CI/CD) para esse esforço, se possível. Caso contrário, estabeleça planos de teste claros que permitam que as equipes executem sequências de testes com antecedência e frequência, de modo de autoatendimento. Para testes de agentes Agentforce, confie no Centro de testes para testes em lote rigorosos de agentes de IA com várias entradas para garantir que funcionem corretamente em diferentes cenários.
• Reconheça que nem toda mudança requer todo tipo de teste. Assim como um pipeline de versão eficaz acomoda caminhos para aplicativos de alto, médio e baixo risco, uma estratégia de teste eficaz também. Especifique claramente para as equipes como selecionar e seguir um regime de teste adequado para aplicativos com vários tipos de risco, casos de uso ou complexidade. Consulte Estratégia ambiental.
• Defina quais testes podem ser realizados em diferentes tipos de ambiente. A fidelidade à produção é um componente essencial de testes precisos, mas significa coisas diferentes para diferentes tipos de testes. Por exemplo, o teste de regressão precisa de fidelidade à produção em termos de metadados e, até certo ponto, dados. Defina qual tipo de fidelidade à produção é necessária para um determinado conjunto de testes e classifique claramente quais tipos de ambientes podem suportar as condições adequadas para diferentes testes. Para obter uma visão geral dos tipos de trabalho alinhados a cada tipo de ambiente, consulte Estratégia ambiental.
• Use testes de resistência, esforço, desempenho e escala para medir continuamente a maturidade da aplicação. Esses testes mostram como uma solicitação está pronta para liberação em relação às necessidades no nível de produção. Para novos recursos importantes, execute esses testes a vários intervalos no ciclo de desenvolvimento do aplicativo. É antipadrão considerar esses testes como parte de apenas uma única fase ou estágio de desenvolvimento, em vez de como parte de tarefas em andamento. É mais útil para as equipes obterem feedback sobre o desempenho do aplicativo com antecedência e frequência, o que os ajuda a entender melhor o quão perto ou longe o aplicativo está do nível de produção. A capacidade de identificar e lidar melhor com problemas antes de as alterações entrarem em produção vale muito a complexidade adicional de executar testes mais sofisticados com frequência.
  • Sabe quais testes importam. Você provavelmente terá uma quantidade fixa de tempo para realizar seus testes de escala ou desempenho, tornando imprático testar cada faceta do seu sistema. Nem todos os recursos são usados igualmente e nem todos os gargalos de escala afetarão os negócios igualmente. Garanta que seus testes de escala estejam focados nas partes mais usadas e mais valiosas do sistema. Defina e entenda as oportunidades mais importantes para verificar e melhorar a escala e o desempenho em sua organização.
  • Saiba como “bem o bastante” parece. Definir os critérios de sucesso para seus testes de escala e desempenho é crucial. Você e suas equipes de desenvolvimento devem usar os critérios de sucesso como referências de teste. Além disso, certifique-se de que eles informem os requisitos funcionais para os quais as equipes de desenvolvimento se baseiam. Geralmente, esses critérios incluem dar suporte a um número específico de usuários simultâneos com tempos de resposta inferiores a um valor acordado e seus objetivos de nível de serviço (SLOs). Defina seus principais critérios de meta e projete testes de escala e desempenho que garantem que os critérios sejam atendidos.
  • Verifique-se de que você tem ambientes adequados. Os testes de escala e desempenho exigem uma fidelidade específica à produção. Seus conjuntos de dados, demografia da solicitação, taxas de solicitação e características da carga de trabalho em ambientes que não sejam de produção devem corresponder ao máximo possível ao que você vê na produção. Para testes de escala, você deve usar um Sandbox completo. Se sua organização não tiver um Sandbox completo para testes de escala, você não poderá executar testes de escala adequados.
• As cargas de trabalho de teste ajudam a medir requisitos não funcionais. Lembre-se de considerar:
  • Dados de teste-Todos os tipos de teste devem ocorrer em relação aos dados isolados da produção. Em testes de unidade do Apex, implemente padrões de fábrica de dados para garantir que o código gere seus próprios dados de teste, isolados dos dados do ambiente. Você também pode criar e manter conjuntos de dados de teste em vários formatos para testar comportamentos de carga de dados, preencher ambientes de desenvolvimento com dados para testes baseados em interface do usuário e ajudar com testes de integração. Todos os dados de teste, sejam eles mantidos como um conjunto de dados externalizado ou criados sob demanda pelo código de fábrica de dados, devem ser removidos de dados confidenciais e de identificação. Deve incluir dados corrompidos, incompletos e malformados para dar suporte a comportamentos de teste de unidade negativos e de limite.
  • Serviços de simulador e fragmento de código – Para testes de integração, você pode usar os serviços de simulador e fragmento de código para simular respostas da API. O Apex oferece suporte a uma API Stub para criar estruturas de simulação para uso em testes do Apex. Mocking para criar estruturas de simulação que podem ser usadas em testes do Apex. Silencios e fragmento de código podem ajudar a validar os comportamentos de processamento de dados de um sistema, com menos dependência de fábricas de dados complexas ou conjuntos de dados de teste externos. Os mutirões e os fragmento de código às vezes são mais adequados para serem usados em testes em que o tráfego semelhante à produção ou os volumes de dados não são relevantes.
  • Dispositivos e tecnologia assistiva – Uma parte essencial da criação de aplicativos interessantes e acessíveis é garantir que eles atendam às expectativas dos usuários em vários dispositivos e com diferentes tipos de tecnologias assistivas. Testes de usabilidade significativos podem exigir mais investimento e diferentes tipos de conhecimento para serem executados de modo eficaz, mas é uma parte essencial de saber como seus aplicativos voltados para o usuário serão arquitetados quando forem lançados.
  • Simuladores: quando você precisa replicar volumes semelhantes à produção de solicitações de usuário, tráfego de API ou variações de velocidade de rede, pode precisar de ferramentas que simulem essas condições. Nem todos os testes precisam desse nível de investimento. Essas ferramentas costumam ser mais úteis em testes de escalabilidade e desempenho.
  • Teste de IA e Agente – Um objetivo primordial do teste é reduzir alucinações de IA, que são respostas convincentes que são fabricadas e incorretas. Certifique-se de que os casos de uso de IA sejam testados para destacar problemas comuns causados por uma compreensão incompleta do cliente, dados ausentes, campos com metadados incompletos e dados desatualizados. Use o Centro de teste para ajudar a criar os dados de teste necessários para esses testes.

A tabela a seguir mostra uma seleção de padrões para procurar ou criar em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para ALM no Padrão & Anti-Padrão Explorador.

Na engenharia de segurança e confiabilidade do site (SRE), a resposta a incidentes é focada em como as equipes identificam e lidam com eventos que afetam a disponibilidade geral ou a segurança de um sistema, bem como como como as equipes trabalham para lidar com causas-raiz e prevenir problemas futuros. A resposta de incidente envolve os processos, ferramentas e comportamentos organizacionais necessários para lidar com problemas em tempo real e após um problema ocorrer.

Como arquiteto, talvez você não seja a pessoa que monitora as operações da sua solução no dia a dia após a ativação. Parte da arquitetura para resiliência é projetar recursos de recuperação que permitem que as equipes de suporte realizem diagnóstico de primeiro nível, estabilizem os sistemas e passem de modo eficaz a investigação e a mitigação da causa raiz para as equipes de desenvolvimento ou manutenção. Equipes que oferecem suporte direto a usuários no dia a dia podem não ter uma compreensão profunda ou conhecimento sobre a arquitetura do sistema. É essencial que essas equipes tenham as ferramentas e os processos necessários para monitorar operações diárias, acessar informações do sistema ao diagnosticar um possível incidente e servir como primeiros respondentes eficazes para quaisquer problemas que afetem a disponibilidade.

Você pode melhorar a forma como as equipes respondem a incidentes em suas soluções do Salesforce focando seu tempo de recuperação, a capacidade de triagem e o monitoramento e alerta.

Quando ocorre um incidente, a primeira prioridade deve ser restaurar os sistemas a um estado operacional estável. Geralmente, as empresas acham que a única maneira de se recuperar de um incidente é "corrigir o problema". Essa pressuposição é justa, pois a análise e a remediação da causa raiz precisas são como você resolve problemas críticos em um sistema. No entanto, "corrigir o problema" durante os primeiros estágios da resposta à crise não é a abordagem mais prática. Dependendo da gravidade de um incidente, cada segundo dele e seu impacto podem levar a uma perda de receita ou reputação para o negócio.

Geralmente, tentar diagnosticar e lidar com as causas raiz atrasam os esforços para restaurar o funcionamento do sistema. Logisticamente, adotar uma abordagem que solicita que os responsáveis a incidentes lidem com as causas-raiz coloca uma enorme pressão sobre os especialistas no assunto (SMEs) e a equipe de suporte em sua empresa. Trabalhar para encontrar e corrigir as causas-raiz durante um incidente exige que as PME estejam atentas a cada incidente, o que pode impedir a equipe de suporte da linha de frente e voltada para o cliente de agir. Também pode resultar em equipes liberando alterações que, por sua vez, criam mais incidentes. Em última análise, essa abordagem aumenta os custos, consome largura de banda entre as equipes e leva a comportamentos em tempos de crise que podem erodir o Trust do cliente e a reputação da marca.

O paradigma de gerenciamento de incidentes certo é priorizar e focar a recuperação como uma primeira etapa. Depois que um sistema é restaurado para a estabilidade, você pode acompanhar com tarefas pós-mortem, investigações de incidentes, remediação da causa raiz e atividades semelhantes. Essa ordem de operações permite que a equipe de resposta a incidentes faça triagem, diagnostique e execute táticas de recuperação, alertando as PME relevantes para ajudar apenas quando necessário. Também permite que as PME identifiquem e corrijam as causas-raiz de um incidente com menos pressão de um relógio.

Para adotar uma mentalidade de recuperação em primeiro lugar para resposta a incidentes:

• Estabelecer e atingir SLOs de objetivos de nível de serviço. SLOs são padrões que você desenvolve com suas partes interessadas para requisitos não funcionais (NFR) específicos de um sistema, como desempenho ou tempo de atividade. Esses objetivos são medidos por indicadores de nível de serviço (SLIs) ao longo de um período de tempo. Sem SLOs, grande parte do trabalho em torno da resposta a incidentes e solução de problemas complexos pode parecer desorganizada e reativa, por exemplo, solicitando uma ação rápida para "parar esse erro específico, para este punhado de usuários que o relataram". Esse ciclo costuma fazer com que as equipes enviem a análise de causa raiz mais perto da resposta ao incidente, pois parece que isso vai ajudar a impedir os comportamentos reativos. A criação de SLOs e SLIs é uma maneira mais eficaz de começar. Para estabelecer SLOs, pense nestas perguntas.
  • Qual é o NFR do seu sistema para os próximos 1 a 3 anos? Por exemplo, sua NFR pode incluir os tempos de resposta, as taxas de solicitação de pico e os usuários simultâneos que seu sistema deve suportar.
  • O que você quer que seus clientes e seus usuários experimentem? Baseie seus SLOs na resposta a essa pergunta, que pode ser "Os usuários podem executar relatórios rapidamente no Salesforce".
  • O que você pode medir e por quanto tempo deve medir? Baseie seus SLIs na resposta a esta pergunta. Um SLI que corresponda ao exemplo anterior pode ser "x% dos relatórios são carregados em média em _n_s, medidos em um período de 30 dias".
• Defina e padronize as táticas de recuperação. Alterar reversões e implementações alternativas pode ajudar a tornar um sistema funcional novamente e minimizar o impacto de um incidente. Documente táticas e protocolos de recuperação que podem ser executados pelos membros apropriados de suas equipes de suporte ou operações. As táticas de recuperação diferem conforme o tipo de incidente. A próxima tabela mostra uma estrutura geral que mapeia tipos de incidentes para táticas de recuperação. Para obter mais informações sobre a identificação de pontos de falha e a definição de estratégias de mitigação, consulte Disponibilidade.

• Defina critérios de saída claros. Use seus SLOs para determinar quando seu sistema está fora do status de incidente ou impacto.
• Definir processos para revisões pós-incidente e remediação da causa raiz. Reserve tempo para revisar incidentes após a restauração do serviço. Durante as revisões, tome uma abordagem pós-mortem impecável. Trabalhar com as partes interessadas para se concentrar em estabelecer fatos claros sobre o que ocorreu e como ocorreu, em vez de tentar atribuir culpa ou culpa a indivíduos. Use diferentes formatos de revisão para examinar maneiras de lidar com problemas em longo prazo.
  • Uma revisão pós-ação centra-se na resposta ao incidente. É útil para avaliar se os processos e táticas de resposta adequados estão em vigor.
  • Uma análise raiz da causa se concentra na causa raiz do incidente. Ele pode ajudar a identificar quaisquer bugs ou problemas no design e na implementação do seu sistema que levaram ao incidente.
• Pratique seus protocolos de recuperação acordados periodicamente. Pratique protocolos de recuperação para garantir que todos saibam como lidar bem com incidentes. Use sandboxes e ambientes de teste para dar às equipes lugares para praticar a simulação e a recuperação de incidentes. Também pratique suas análises pós-incidente. Fazer toda essa prática torna a recuperação parte da sua cultura de engenharia e suporte.

Os padrões e antipadrões para resposta a incidentes mostram como é a arquitetura para priorizar a recuperação em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas.

Para aprender mais sobre ferramentas do Salesforce para ajudar com o tempo de recuperação, consulte Salesforce Tools for Resiliency.

No contexto da tecnologia, a triagem envolve atribuir categorias e níveis de gravidade a problemas e solicitações de suporte. Não importa o quão bem planejada seja sua solução, surgirão problemas e solicitações de suporte ao usuário. Esses problemas podem resultar da falta de treinamento ou gerenciamento de mudanças adequado, lacunas na IU/UX, comportamentos inesperados do usuário final e problemas de sistema urgentes que não são capturados pelo monitoramento ou alerta.

As equipes de suporte e operações precisam poder investigar consultas de suporte do usuário de maneira eficiente e diagnosticá-las rapidamente. A triagem de problemas para filtrar preocupações menos graves e detectar rapidamente incidentes críticos do sistema é uma competência essencial para essas equipes. Uma triagem deficiente desacelera todos os níveis de suporte ao usuário, prolonga incidentes críticos e aumenta o risco de interrupções adicionais para seus clientes e seus negócios.

Embora você possa não estar envolvido em operações e suporte diários, como um arquiteto, é sua responsabilidade ajudar a garantir que suas equipes de suporte e operações possam fazer a triagem eficaz de problemas em qualquer solução criada na Salesforce Platform.

Para permitir que as equipes façam a triagem eficaz de problemas em suas soluções do Salesforce:

• Garantir que as equipes de suporte tenham acesso a informações úteis.
  • Documente seu sistema e padrões de design. Garantir a legibilidade e a consistência da sua solução é uma parte essencial para que a equipe de suporte entenda o sistema que é responsável por apoiar. Na sua documentação, considere como as equipes encontrarão informações sobre como priorizar problemas ou incidentes com diferentes partes do sistema. Além disso, garanta que as equipes possam rapidamente obter informações técnicas sobre táticas de recuperação com base na área de impacto. Forneça guias de solução de problemas relevantes para problemas comuns do Agentforce, como Classificação de tópico e Seleção de ação, que podem ajudar as equipes a solucionar rapidamente problemas relacionados a permissões ou configuração.
  • Design com depuração em mente. Equipes de suporte e administradores da organização precisarão habilitar a depuração e o diagnóstico para fazer a triagem correta de problemas do usuário em vários ambientes. Exemplos de padrões compatíveis com a depuração incluem aqueles que incorporam registros e mensagens de erro personalizadas em caminhos de execução em todo o sistema. Habilite equipes de suporte em abordagens comuns de depuração do Agentforce com ferramentas como logs de eventos e a visualização de raciocínio do Agent Builder.
  • Identificar PME e partes interessadas incidentes. Crie uma lista de PME ou partes interessadas relevantes que devem estar disponíveis para dar suporte à recuperação de um incidente e que devem estar envolvidas na análise pós-incidente.
  • Tratar transgressões com cuidado. Garanta a qualidade de cada transferência de solução para equipes de suporte ou operações como parte da ativação. Forneça treinamento para a equipe de suporte para percorrer a arquitetura do sistema relevante e simulando os exercícios de resposta a incidentes. Pense em transferências pós-incidente, incluindo como as equipes devem documentar informações que não são capturadas por registros ou notas de caso, bem como como os responsáveis ao incidente podem contribuir para investigações de causa raiz ou realizar testes de aceitação do usuário para quaisquer remédios.
• Se você for consultado, mantenha todos focados na recuperação como a principal preocupação.
  • Responda rápido. Responda rapidamente a todas as solicitações de suporte ao usuário, notificações de monitoramento e alertas que você receber.
  • Ajuda a distinguir sintomas de problemas. Trabalhe para determinar se há um incidente real do sistema que precisa ser resolvido. Tente identificar os componentes com os problemas reais. Ajude a garantir que as tácticas de recuperação acordadas sejam seguidas para remover o sistema do status de incidente rapidamente.
• Para agentes da Agentforce que oferecem suporte a casos de uso críticos, garanta que existam soluções alternativas viáveis e relevantes que possam ser ativadas com um breve aviso como uma medida de redundância. Os exemplos incluem alternar para manipulação manual ou redirecionar para documentações relevantes para revisão manual.

Os padrões e antipadrões para resposta a incidentes mostram como é a arquitetura para triagem eficaz em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas.

Para saber mais sobre ferramentas do Salesforce para ajudar na triagem, consulte Salesforce Tools for Resilience.

Monitoramento e alerta são termos amplamente usados na engenharia de confiabilidade do local. No contexto da resiliência do sistema, o monitoramento avalia continuamente o estado atual de um sistema e o alerta automatiza notificações às partes interessadas sobre possíveis preocupações sobre o estado do sistema. O monitoramento e o alerta eficazes são uma parte essencial para desconectar a escala e o crescimento do seu sistema da escala e do crescimento da equipe de suporte.

O Salesforce oferece uma variedade de recursos integrados para monitorar comportamentos em seu sistema. O Salesforce também oferece o monitoramento de evento em tempo real como um complemento ou como parte do Salesforce Shield. Em qualquer solução do Salesforce, os designs criados para monitoramento e alerta fornecem:

• Recursos para resposta de incidente automatizada
• Informações relevantes para os usuários certos, na hora certa
• Informações claras para visualizações históricas e análise de tendências

Para arquitetar o monitoramento e o alerta efetivos em suas soluções do Salesforce:

• Faça da automação uma prioridade. Embora a notificação dos usuários sobre alterações de estado críticas seja uma parte crucial para manter seus sistemas estáveis e operacionais, em uma arquitetura ideal, o sistema corrige automaticamente os problemas quando possível e envia alertas apenas para problemas urgentes e não recuperáveis. Mesmo sem recursos de auto-correção, a automação pode tornar seu alerta e relatório mais úteis.
  • Comece com o que o Salesforce já fornece. A Salesforce Platform fornece logs e APIs relevantes para que você monitore as operações da sua solução em relação aos limites do regulador. Além disso, a plataforma envia alertas para violações de limite do controlador e problemas semelhantes. Use esses registros e alertas como a base para explorar maneiras de automatizar totalmente a auto-recuperação do sistema, os relatórios de incidentes e os alertas. Por exemplo, você pode implementar automação que monitora o registro e, em seguida, executa uma ação de recuperação quando um determinado tipo de evento é registrado.
  • Classifique as alterações no estado do sistema de maneiras previsíveis. Crie categorias específicas e relevantes para os principais estados que você deseja monitorar e relatar. Alinhe essas categorias com as categorias que você define para gerenciar o estado em seus componentes de aplicativo. Adote uma mentalidade orientada à API para como você lida com as informações de alteração de estado. Formatos de mensagem consistentes e categorias de estado simplificam a automação, os relatórios e os alertas.
  • Alinhe sua lógica de automação com as outras partes do sistema. Se você tiver criado o tratamento de erros de automação adequado, poderá estender esses padrões para como classificar alterações de estado e responder com automação. Para alterações de estado consideradas recuperáveis, você pode automatizar os novos comportamentos de tentativa. Para alterações de estado consideradas críticas ou fatais, automatize alertas aos usuários.
• Evite criar barulho. Quando os usuários recebem muitos alertas, especialmente alertas que não exigem nenhuma ação, eles tendem a começar a desabilitar ou ignorar todos os alertas. Esse cenário prejudica todos os esforços para criar alertas útiles. Para definir melhor o escopo de quem recebe alertas, o que os aciona e quando eles são acionados, considere fazer estes itens.
  • Criar mapas das partes interessadas. Para garantir que seu sistema forneça os alertas certos às partes interessadas certas no momento certo, primeiro identifique e classifique seus grupos de partes interessadas.
  • Rotear mensagens com base nos privilégios do usuário. Envie alertas apenas a destinatários que tenham capacidade e autoridade para responder. Os usuários de negócios podem se beneficiar de alertas sobre problemas que podem corrigir corrigindo problemas em registros aos quais têm acesso. Se um problema exigir uma resposta técnica mais envolvente, os alertas deverão ser direcionados para a equipe de suporte.
  • Deixe a resposta esperada clara. Envie alertas apenas em cenários que exigem intervenção humana. Estruture mensagens para indicar claramente a ação esperada do destinatário. Se você enviar um alerta para a visibilidade de uma parte interessada e nenhuma ação for necessária, deixe isso claro na versão da mensagem que ela receberá.
  • Faça alertas oportunos e relevantes. Alertas que são entregues em resposta a falhas que ocorreram e ainda precisam ser remediados) não são tão úteis quanto alertas sobre uma falha potencial. Idealmente, a equipe de suporte é alertada assim que ocorrem condições problemáticas no sistema, proporcionando uma oportunidade para classificar problemas antes que eles possam ter impactos negativos nas operações de negócios.

A lista de padrões e antipadrões mostra como é a arquitetura para monitoramento e alerta eficaz em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas.

Para aprender mais sobre ferramentas do Salesforce para monitoramento e alerta, consulte Salesforce Tools for Resilience.

Esta tabela mostra uma seleção de padrões para procurar ou criar em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para resposta a incidentes no Padrão e Explorador antipadrão.

Uma chave para a resiliência dos negócios é o planejamento de continuidade, que se concentra em como permitir que pessoas e sistemas funcionem por meio de problemas causados por um evento não planejado. Os planos de continuidade de negócios (BCPs) têm uma visão orientada a pessoas de como manter os processos avançando durante a crise. Os aspectos técnicos do planejamento de continuidade estão contidos nas partes de recuperação de desastres de um CCO. Consulte Continuidade da tecnologia.

Sem planos de continuidade adequados, sua organização agora pode saber como agir e, portanto, não agir de modo algum durante uma crise ou falha do sistema. O planejamento de continuidade ineficaz pode ter um impacto catastrófico sobre clientes, partes interessadas e negócios. Após um evento adverso, cada momento que passa sem manter ou recuperar processos críticos corre o risco de prejuízo financeiro, prejuízo à reputação, segurança dos funcionários e até mesmo conformidade regulatória.

Você pode integrar um melhor planejamento de continuidade em seus sistemas focando seus esforços em três áreas: definir a continuidade de negócios para o Salesforce, planejar a continuidade da tecnologia e criar recursos de backup e restauração.

Sua empresa já pode ter um CCO em vigor. Se tiver, certifique-se de que o Salesforce esteja incluído nele. Se sua empresa não tiver um BCP, trabalhe com suas partes interessadas para criar um que abranja suas organizações do Salesforce.

O Salesforce costuma ser confiável como fonte da verdade para dados do cliente e processos comerciais essenciais em muitas divisões de negócios. Assim, o papel que o Salesforce desempenha em um BCP pode ser diferente dos papéis que outros sistemas desempenham. É provável que a Salesforce esteja envolvida em muitas áreas de alta prioridade para recuperação.

Para criar um plano de continuidade de negócios relevante para sistemas do Salesforce:

• Esclareça as prioridades para recuperação. Como acontece com a abordagem geral para a resposta a incidentes, a recuperação deve ser a primeira prioridade dos sistemas em momentos de crise. Muitos serviços essenciais para os negócios são executados com o Salesforce. Você deve ajudar as partes interessadas a identificar a prioridade correta para recuperar várias funções e recursos de negócios. Uma estrutura geral pode ser:
  • Estabilize a infraestrutura de negócios essencial.
  • Estabilizar os serviços ao cliente.
  • Estabilizar serviços de funcionários e parceiros.
• Considere seu ecossistema em seus BCPs. O Salesforce não é o único sistema em seu panorama. Identifique lacunas em seu CCO em torno de sistemas que se integram ao Salesforce, soluções instaladas de fornecedores do AppExchange e quaisquer outros sistemas que se conectem a dados ou processos no Salesforce. Se sua capacidade de entrega depender dos fornecedores, pergunte a esses fornecedores sobre seus planos de continuidade. Avalie seus recursos e planeje como manter seus sistemas disponíveis.
• Integrar preocupações do BCP em sua estratégia de teste. Crie planos de teste para seu CCO e realize-os. É especialmente importante testar as áreas do seu CCO relacionadas a processos ou pessoas, que costumam ser ignoradas. Incorpore itens relevantes do seu CCO em sua estratégia de teste geral do ALM. Crie e siga uma agenda de manutenção para revisar os testes e garantir que seu plano fique atualizado.

Os padrões e antipadrões para o planejamento de continuidade mostram como é o planejamento de continuidade adequado e ruim em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar locais em seu sistema que precisam ser refatorados.

Para aprender mais sobre ferramentas do Salesforce para definir a continuidade dos negócios, consulte Salesforce Tools for Resilience.

A meta da continuidade da tecnologia é garantir que problemas com componentes em um sistema não impeçam a empresa de manter operações essenciais. A Salesforce prioriza manter nossos serviços nos níveis mais altos de disponibilidade e fornecer informações transparentes sobre quaisquer problemas. Você pode ver informações em tempo real sobre o desempenho do sistema Salesforce e problemas em trust.salesforce.com. Como um arquiteto criando no Salesforce, suas soluções se beneficiam das funcionalidades de confiabilidade, segurança e desempenho do site que o Salesforce fornece em toda a plataforma.

No entanto, a continuidade geral de suas soluções do Salesforce vai além dos serviços integrados que o Salesforce fornece. De uma perspectiva arquitetônica, o planejamento de continuidade de tecnologia do Salesforce precisa começar fazendo e respondendo perguntas sobre como o Salesforce se encaixa em seu panorama corporativo maior. Quais tipos de sistemas se integram ao Salesforce? Como os sistemas externos dependem de processos ou informações no Salesforce? Em suas organizações do Salesforce, quais processos ou funcionalidades dependem das soluções do AppExchange? Seus usuários acessam o Salesforce por meio de serviços de identidade ou SSO de terceiros?

Para criar uma melhor continuidade de tecnologia em seus sistemas do Salesforce:

• Avaliar sua infraestrutura. A estratégia de remediação mais comum para falhas ou problemas de tecnologia é criar serviços ou sistemas redundantes aos quais você pode voltar durante um incidente. No Salesforce, temos uma arquitetura intencionalmente redundante, o que significa que mantemos cópias dos sistemas e serviços de nossos clientes em diferentes locais físicos. Usamos várias técnicas de recuperação de desastres, incluindo a alternância do site, que nos permite direcionar o tráfego do usuário de um data center para outro, se necessário. Para identificar onde você pode precisar criar redundância intencional, faça estas perguntas a você mesmo.
  • O que acontece durante uma interrupção de serviço para o serviço [X]? Podemos mudar desse serviço para outro?
  • Quanto tempo leva para recuperar [X]? Qual é o impacto para nossos clientes? Qual é o impacto para nossos parceiros? Qual é o impacto para as equipes internas?
  • E quanto a backups e sua frequência? Os backups podem fornecer os dados necessários para dar suporte aos negócios?
  • Nós dependemos de fornecedores? Quais são os planos de CCO?
• Fornecer apoio operacional. O suporte operacional é fazer as equipes voltarem a funcionar o mais rápido possível. Pense em como seu sistema pode lidar com aumentos significativos nos requisitos de capacidade e demanda de alterações inesperadas, incluindo alterações do setor, da região ou globais. Certifique-se de que seu CCO considere os recursos adicionais ou os procedimentos de vidro quebrado de que a Engenharia de confiabilidade do site (SRE) ou as equipes de suporte podem precisar para responder a incidentes de modo eficaz. As perguntas sobre suporte operacional incluem:
  • Em uma interrupção, nossas equipes técnicas teriam as ferramentas necessárias para continuarem trabalhando? Simulamos uma interrupção para validar planos ou identificar lacunas?
  • Se um desastre ocorrer em uma área específica, temos planos de cobertura para essa área?
  • Nossos clientes são globais? Eles operam 24 horas por dia, 7 dias por semana?
  • Temos um monitoramento e alerta adequados para notificar as pessoas apropriadas quando há falhas?
• Automate e teste suas táticas de recuperação. Depois que um problema for remediado, identifique onde ele ocorreu e como ele foi corrigido. Se possível, com base na remediação, automatize suas táticas de recuperação e ajuste quaisquer problemas do processo. Muitas empresas agendam simulações de incidentes para um subconjunto de serviços para testar a resiliência do sistema. Um exemplo poderia ser simular uma conta de administrador do sistema sendo bloqueada ou comprometida, ou simular uma interrupção ou problema com um provedor do AppExchange. Consulte Resposta a incidentes.)As perguntas sobre como o teste e a automação podem ajudá-lo a restaurar serviços mais rapidamente incluem:
  • Com que frequência agendamos e executamos simulações de incidentes?
  • Sabemos quanto tempo leva para restaurar os serviços a um estado estável?
  • Temos processos de entrega estáveis em vigor?
  • Sabemos onde automatizar o failover e a recuperação?

Trate qualquer item que venha de suas análises pós-incidente como seus outros itens de desenvolvimento. Adicione-os aos seus sistemas de planejamento para que você possa priorizá-los e trabalhar com eles.

Os padrões e antipadrões para planejamento de continuidade mostram como é o planejamento de continuidade de tecnologia adequado e ruim em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar locais em seu sistema que precisam ser refatorados.

Para aprender mais sobre ferramentas do Salesforce para planejamento de continuidade de tecnologia, consulte Salesforce Tools for Resilience.

A restauração de cópias de backup de dados ou metadados pode ajudar a retornar sua organização ao último estado estável conhecido. Ele também pode fornecer um sistema de failover durante uma falha catastrófica do sistema ou interrupção de serviço. Fazer backup regular de seus dados e metadados e armazenar suas cópias criptografadas em backup em um local seguro adiciona uma camada adicional de resiliência à sua arquitetura.

Sem estratégias de backup e restauração, não é possível restaurar versões limpas de seus metadados e dados de produção quando eles forem corrompidos de modo mal-intencionado, quando defeitos entrarem inadvertidamente em produção ou quando uma falha durante um grande carregamento de dados corromper os dados de produção. Qualquer um desses cenários pode resultar em seus dados de produção críticos para os negócios serem corrompidos ou até mesmo perdidos permanentemente. A configuração da tecnologia de backup e restauração oferece várias vantagens além do planejamento de continuidade, incluindo ajudar com estratégias para mitigar grandes volumes de dados e cumprir políticas de retenção relacionadas à conformidade.

Para ajudar a garantir a continuidade com estratégias de backup e restauração em suas soluções do Salesforce:

• Comece. A primeira etapa para ter uma boa estratégia de backup e restauração é ter uma estratégia em primeiro lugar. Mesmo algo tão simples como fazer backups noturnos de todos os dados e metadados da sua organização pode evitar que sua empresa perca informações ou funcionalidades essenciais durante um desastre.
• Restrinja o acesso a backups. Os administradores do sistema são os únicos usuários que devem ter acesso a cópias de segurança dos seus dados. Essa restrição de acesso impede que um usuário comercial possa visualizar registros em uma cópia de backup que não teria autorização para visualizar na sua organização.
• Teste seu processo de restauração regularmente. Independentemente da estratégia de backup e restauração implementada, teste seu processo de restauração em um sandbox de Cópia total ou parcial regularmente para ter certeza de que ele funcionará corretamente quando você precisar.
• Alinhe sua estratégia de backup e restauração com sua estratégia de arquivamento de dados. Determine o que deve acontecer em seus backups ou arquivos quando os registros são arquivados ou removidos do seu sistema. Consulte Volume de dados).

Talvez você precise de uma estratégia de backup mais granular se seus volumes de dados forem tão grandes que um backup completo não tenha tempo para ser concluído antes da execução do próximo backup. Talvez você também precise de uma estratégia de backup mais granular se os dados da sua organização mudarem com tanta frequência que as atualizações sejam essenciais para a sua organização.

Para tornar sua estratégia de backup mais granular:

• Especifique seus backups para objetos específicos. Essa estratégia envolve fazer backup de registros de diferentes objetos em intervalos de tempo diferentes. Lembre-se de que os objetos filho devem fazer backup nos mesmos intervalos que seus pais para manter a consistência dos dados.
• Backups parciais de caixa de tempo. Essa estratégia envolve a diferenciação entre backups completos (de todos os dados e metadados) e backups parciais (de apenas metadados e registros que foram adicionados ou alterados desde o último backup).

*Nunca pare de realizar backups completos. É importante observar que você nunca deve eliminar backups completos completamente, mesmo que os volumes de dados resultem em tempos de execução longos. Para grandes volumes de dados, planeje backups completos regulares, mas infrequentes (por exemplo, backups semanais). Planeje também backups parciais ou específicos de objeto mais frequentes (por exemplo, backups noturnos ou backups a cada X horas). Essa abordagem oferece flexibilidade para reconstruir o conjunto de dados mais completo e preciso para usar em seus processos de restauração.*

Os padrões e antipadrões para planejamento de continuidade mostram a aparência dos recursos de backup e restauração adequados e ruins em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar locais em seu sistema que precisam ser refatorados.

O Backup e recuperação do Salesforce, uma solução integrada do Salesforce que inclui a Recuperação própria da aquisição própria, protege dados importantes contra perda ou corrupção. Nossa solução altamente segura, fácil de configurar e sempre disponível garante a continuidade dos negócios e a resiliência dos dados e simplifica a conformidade.

Use o Backup e recuperação do Salesforce para evitar perda de dados, recuperar de incidentes de dados rapidamente e simplificar sua estratégia geral de gerenciamento de dados. Você pode criar políticas de backup para dados de alto valor e regulados e restaurar esses dados com apenas alguns cliques.

Os backups diários automatizados protegem todos os dados cruciais da sua organização, incluindo metadados, sandboxes, dados de pacote gerenciado, anexos de arquivo e muito mais. Execute backups com a frequência necessária para atender às metas do seu objetivo de ponto de recuperação (RPO) e proteger suas implantações. Os backups sempre estão acessíveis e armazenados de forma segura e em conformidade. A Proteção de dados contínua também está disponível para dados ainda mais confidenciais ou transacionais, permitindo uma recuperação mais rápida de informações críticas que mudam rapidamente.

Detecte atividades de dados incomuns, perda de dados e corrupção com alertas proativos enviados diretamente para seu email. Receba alertas em tempo real para identificar desvios estatísticos ou criar regras que o notificam sobre atividades de dados incomuns, ajudando você a detectar incidentes com mais rapidez do que nunca.

O Backup e recuperação do Salesforce acelera a recuperação fornecendo visibilidade granular das alterações, permitindo a rápida identificação e restauração dos dados afetados. Ferramentas como gráficos visuais destacam alterações indesejadas, enquanto recursos de recuperação fáceis de usar restauram objetos, campos e registros afetados com precisão.

Nossas ferramentas permitem que você use backups para análise, auditorias e conformidade, oferecendo dados históricos pesquisáveis, funcionalidade de pesquisa aberta para a visibilidade de dados anteriores e recursos de exportação para análise externa ou armazenamento. Isso reutilizará os backups sem precisar de APIs adicionais do Salesforce.

O Backup e Recuperação oferece um único console para consolidar todos os backups, gerenciamento, operações e conformidade. Esse console permite que você acesse, gerencie, personalize e monitore backups para todas as suas organizações de produção e sandboxes. Com ele, você também pode executar solicitações de sujeito de dados para garantir a conformidade dos dados de backup e ter controle total para personalizar agendas de backup, frequência e políticas de retenção.

• Minimizar o impacto de incidentes de dados. O Backup e recuperação do Salesforce ajuda a mitigar incidentes de dados, como ataques cibernéticos ou atividades internas ou externas mal-intencionadas, permitindo que os usuários revertirem os registros afetados para o estado anterior ao incidente. A funcionalidade de exportação do Backup e Recover garante o acesso contínuo e a usabilidade dos dados críticos dos usuários.
• Prevenir perda permanente de dados. O erro humano continua sendo a principal causa de perda de dados. O Backup and& Recover oferece uma solução precisa e rápida para esses erros.
• Satisfazer mais facilmente os requisitos legais e de conformidade de dados. O Backup e recuperação do Salesforce dão suporte ao modelo de responsabilidade compartilhada, habilitando a funcionalidade de autoatendimento para o esquecimento em massa ou a correção de dados em seus dados de backup.

Para aprender mais sobre ferramentas do Salesforce para backup e restauração, consulte Salesforce Tools for Resiliency.

Esta tabela mostra uma seleção de padrões para procurar ou criar em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para planejamento de continuidade no Padrão & Anti-Padrão Explorador.

Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa pesquisa para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida.