Lea sobre nuestras programaciones de actualizaciones aquí.

Las soluciones resilientes mantienen una alta calidad de servicio incluso cuando se producen fallos. Si el desempeño se degrada o se interrumpe el servicio, la solución se recupera de forma rápida y efectiva.

La resistencia de una solución se basa en dos cualidades clave:

• Dureza: Cuando se producen problemas, la solución los resiste y los soporta.
• Elasticidad: Después de resolver los problemas, la solución vuelve a su estado o forma ideal.

Para diseñar su solución para la resiliencia, debe diseñar para la tenacidad y la elasticidad, garantizando la durabilidad y la recuperación rápida ante cambios planificados y no planificados.

En contextos de tecnología, considere un sistema o una solución como un conjunto de componentes interdependientes que se coordinan para realizar objetivos compartidos. Cada componente tiene el potencial de fallar. Los problemas en esos componentes, desde defectos de código y configuración hasta problemas de red y hardware, pueden causar comportamientos inesperados no deseados. Un sistema demuestra un comportamiento resistente cuando uno o más componentes fallan, pero el sistema general continúa funcionando o vuelve rápidamente a un estado estable.

Para mejorar la resistencia de sus soluciones de Salesforce, recomendamos centrarse en tres hábitos clave.

• Gestión del ciclo de vida de aplicaciones (ALM): cómo gestionan los equipos el software a lo largo de su ciclo de vida, desde la ideación hasta la retirada
• Respuesta ante incidentes: Cómo los equipos identifican, solucionan y evitan problemas que afectan a la disponibilidad o la seguridad de un sistema
• Planificación de continuidad: Cómo planifican los equipos que sus personas y sistemas sigan funcionando cuando los eventos no planificados causan problemas

La gestión del ciclo de vida de aplicaciones (ALM) es una práctica para gestionar software de forma integral a lo largo de su ciclo de vida, desde la creación hasta la retirada. ALM es una piedra angular de la resiliencia del sistema y abarca personas, procesos, herramientas y disciplinas relacionadas con el ciclo de vida de la aplicación. Esas disciplinas incluyen DevOps y metodologías de entrega, observabilidad, estrategias de prueba, gobernanza e CI/CD.

Cuando un negocio practica ALM efectivo, sus equipos reaccionan rápidamente al cambio y sus aplicaciones se mantienen al día con los requisitos de negocio en evolución sin comprometer la estabilidad o la calidad.

Por otro lado, sin ALM saludable, los equipos tienen dificultades en cada etapa del ciclo de vida de la aplicación.

Los síntomas de ALM deficiente incluyen:

• Ciclos de desarrollo lentos y proclives a errores
• Implementaciones intensivas y difíciles
• Problemas o fallos de alta gravedad descubiertos en entornos de producción y posteriores a la evaluación cualitativa
• Agentes de IA que alucinan o se comportan de forma incoherente
• Reversiones frecuentes o implementaciones de soluciones rápidas requeridas para estabilizar versiones

Como ALM afecta a casi todos los aspectos de una solución, establecer prácticas de ALM claras y efectivas para su solución es una parte clave de su trabajo arquitectónico.

Construya mejores prácticas de ALM centrándose en tres áreas clave.

• Gestión de versiones: Planificación, secuenciación, control y migración de cambios a diferentes entornos
• Estrategia medioambiental: Una estrategia para cómo utilizar y gestionar aplicaciones en entornos de destino durante el desarrollo y las pruebas
• Estrategia de señalización: Definición de señales críticas e instrumentación de aplicación utilizada para detectar y remediar fallos en el sistema antes de que se produzca la degradación
• Estrategia de pruebas: Los principios y estándares que guían el modo en que planifica y ejecuta pruebas para medir el éxito de sus aplicaciones durante procesos de ALM

La gestión de versiones implica planificar, secuenciar, controlar y migrar cambios a uno o más entornos. Una única versión es un grupo de cambios planificados que un equipo traslada a un entorno de destino al mismo tiempo.

El lanzamiento de un cambio en un sistema introduce riesgo en él. Si el sistema está en un estado estable antes del cambio, pasa a un nuevo estado, donde también es más vulnerable a riesgos de cambios futuros. Si cualquier cambio futuro desencadena un estado inestable e incontrolado en el sistema, puede causar un incidente crítico. En una arquitectura de soluciones, el diseño para versiones resilientes es más que solo probar cambios individuales. También implica planificar cómo introducir cambios en sus sistemas y sus usuarios de forma segura.

El trabajo que realizan sus equipos depende de información de versión predecible y precisa. En sus procesos de gestión de cambios y habilitación, tenga claro qué cambios pueden pasar a su sistema. En sus procesos de gestión de versiones y habilitación, especifique cómo (y con qué frecuencia) se publican los cambios en su sistema.

Sus partes interesadas de negocio también se preocupan por la información de la versión, especialmente si está relacionada con funciones o soluciones de fallos que solicitan. Para generar Trust en su solución y demostrar valor a sus partes interesadas, establezca programaciones de versiones coherentes y claras y envíe artefactos de versión estables.

Para establecer una gestión de versiones efectiva para Salesforce:

• Alinee estrechamente con la arquitectura y la gobernanza del desarrollo. Asegúrese de que las versiones se planifican con suficiente antelación para alinearse con todos los foros y controles de gobernanza relevantes. Antes de comenzar con el desarrollo, haga que el Consejo de IA revise y apruebe todos los casos de uso de Agentforce priorizados. Obtenga casos de uso de alto riesgo Agentforce revisados por equipos de Uso legal y ético.Utilice listas de comprobación de implementación y documentación para realizar un seguimiento de artefactos de implementación, como nombres de API de agentes Agentforce, frente a actividades de gobernanza.
• No utilice procesos de desarrollo o versión basados en organizaciones. Este paradigma refleja tecnologías más antiguas y limitadas para el desarrollo y la versión. Con Salesforce CLI, los equipos ahora pueden adoptar funciones de versión y desarrollo dirigidas por origen.
• Seleccione el mecanismo de versión más estable posible. Este enfoque logra dos cosas. En primer lugar, minimiza la duración de los plazos de versión y las interrupciones de servicio. En segundo lugar, permite comportamientos de versión altamente controlados y predecibles. Cuanto más estable sea su mecanismo de versión, menos posibilidades tendrá de que las versiones introduzcan cambios que requieran revisiones o reversiones. Si surge un problema imprevisto, los mecanismos de versión estables también crean formas más sencillas para que el personal de asistencia o los administradores del sistema realicen reversiones.

Los mejores mecanismos de versión para su equipo son las opciones más estables para las que su equipo tiene las habilidades requeridas. Estos son los mecanismos de versión recomendados, enumerados en orden de estabilidad. Todos ellos son compatibles entre sí, de modo que utilice varios de ellos en tándem si eso es lo mejor para su compañía.

• Paquetes desbloqueados: Los paquetes desbloqueados son el artefacto de versión más estable. La implementación de cambios instalando un paquete es la forma más rápida y predecible de introducir cambios. Los paquetes utilizan versiones, lo que permite una gestión de cambios sólida y reversiones precisas y pensadas para administradores del sistema. Además, los paquetes requieren una sólida gestión de metadatos, lo que puede ayudarle a identificar dependencias mal gestionadas de forma temprana. También crean artefactos y oportunidades en curso de desarrollo auditables. Consulte Capacidad de empaquetado.
• DevOps Center: DevOps Center permite a los equipos de entrega con conjuntos de habilidades de código bajo o procódigo utilizar el control de origen, trabajar en colaboración en cambios y definir rutas de versión comunes. DevOps Center se integra con el control de origen y permite el control de apuntar y hacer clic de cambios e implementaciones.
• Implementaciones de metadatos y desarrollo dirigido por origen utilizando Salesforce CLI: Si no puede utilizar paquetes, utilice Salesforce CLI para su implementación de metadatos y desarrollo dirigido por origen. No implemente metadatos utilizando el formato package.xml antiguo, que sigue una estructura diferente al formato de origen recomendado. El formato de origen evolucionó para admitir el desarrollo de paquetes, flujos de trabajo de organizaciones borrador y un seguimiento de cambios más granular en entornos sandbox. El formato es más legible, permite más desvinculación de dependencias y tipos de metadatos complejos y le proporciona mucho más control sobre manifiestos de implementación.
• Asigne un nombre a sus versiones. Proporcione a sus versiones identificadores claros para ayudar a sus equipos y partes interesadas a permanecer alineados. En Salesforce, el nombre de cada versión principal comienza por “Primavera”, “Verano” o “Invierno”, seguido del año de la versión (por ejemplo, “Verano ’25). Si aún no tiene una convención de nomenclatura para definir y organizar versiones en su compañía, establezca una y utilícela. El uso de nombres de versión claros facilita mantenerse organizado en cada etapa de la planificación, el desarrollo y la entrega en los sistemas de sus equipos. Utilice sus nombres de versión en su hoja de ruta para comunicar claramente a sus partes interesadas qué cambios se aproximan y cuándo. Utilice sus nombres de versión en su documentación, registros de cambios, descripciones de trabajo, comentarios de código y ramas de control de origen de modo que pueda rastrear y auditar fácilmente sus artefactos de desarrollo.
• Dentro de un manifiesto de versión, gestione dependencias correctamente. Los metadatos de Salesforce tienen dependencias integradas. Una razón común por la que fallan las implementaciones de Salesforce es que las dependencias no están gestionadas correctamente. La selección de un mecanismo de versión estable, como se describió anteriormente, puede ayudar a exponer dependencias mal gestionadas anteriormente en su ciclo de desarrollo. Una de las razones principales por las que los paquetes desbloqueados son el vehículo de versión más estable es su sólida gestión de metadatos, que se requiere para el desarrollo y la creación de paquetes. Si usted o sus equipos de gestión de versiones no comprenden las dependencias integradas entre tipos de metadatos de Salesforce, no podrá detectar combinaciones problemáticas de forma proactiva en sus manifiestos de implementación y versión. Consulte Gestión de dependencias.

Los patrones y antipatrones para ALM muestran el aspecto adecuado y deficiente de la gestión de versiones para una organización de Salesforce. Utilice los patrones para validar sus diseños antes de construir, o para identificar lugares en su sistema que necesitan refactorizarse.

Para obtener más información acerca de las herramientas de Salesforce para la gestión de versiones, consulte Herramientas de Salesforce para Resiliencia.

Salesforce proporciona una variedad de entornos para que los utilice durante los ciclos de prueba y desarrollo de aplicaciones. Una estrategia de entorno efectiva para Salesforce requiere comprender cómo utilizar los entornos y el aspecto de una buena gestión. En ALM, la utilidad de un entorno de desarrollo o prueba depende de su fidelidad y aislamiento de la producción.

Una buena estrategia de entorno proporciona varios beneficios.

• Mayor fidelidad a la producción
• Configuración y derribos de entornos más rápidos
• Más ágil en desarrollo y pruebas
• Seguridad mejorada en sus oportunidades en curso
• Menos ruido y conflictos en las etapas de entrega
• Equipos de desarrollo más felices

Los equipos a menudo tienen dificultades para obtener estos beneficios. Los retos para obtener el máximo de sus entornos de desarrollo y estrategia pueden provenir de varios orígenes. Un origen probable es el tipo de modelo de desarrollo que siguen sus equipos.

En el enfoque de desarrollo basado en organizaciones más antiguo, cada entorno tenía que cumplir varias funciones. Además de estar donde su equipo realiza sus diversos tipos de trabajo, tenía que ser el origen de sus artefactos de versión (es decir, los metadatos que desea implementar en una versión). Debido a que los entornos no eran fáciles de configurar o derribar, a menudo estaban superpoblados y llenos de conflictos de metadatos entre equipos, y no contribuyen con una velocidad o flexibilidad significativas a ALM en general.

El uso de un modelo de desarrollo basado en origen cambia fundamentalmente la relación que tienen los entornos con sus versiones y artefactos de versión. En este modelo, el control de origen es el origen de los metadatos que desea publicar. Los entornos son solo lugares donde sus equipos realizan su trabajo.

Sin embargo, seguir el modelo de desarrollo basado en origen no garantiza por sí solo una buena estrategia de entorno. Incluso con el control de origen, los equipos aún pueden tener dificultades para configurar condiciones para probar integraciones con sistemas externos; configuraciones que dependen de metadatos que no están en el control de origen, como paquetes gestionados o personalizaciones que dependen de datos), etc. En ciertas circunstancias, los retos de un modelo basado en origen son similares a los retos típicos de un modelo basado en organización.

Para desarrollar una estrategia de entorno efectiva:

• Adopte un modelo de desarrollo y versión dirigido por origen. Deje de utilizar modelos de desarrollo basados en organizaciones. Consulte Gestión de versiones.) Debe desenredar sus entornos de lo que implementa en ellos para crear una estrategia de entorno saludable y versiones más saludables.
• Comprenda los tipos de trabajo que admite cada entorno. Los tipos de entorno admitidos por Salesforce tienen diferentes funciones y límites. Cuando diseñe su estrategia de entorno, considere lo que los entornos pueden y no pueden hacer. Asegúrese de que sus equipos realizan su trabajo en un entorno que tenga las funciones que necesitan. Para obtener orientación, consulte esta descripción general de los entornos de desarrollo de Salesforce y sus funciones.

Consulte esta tabla para obtener información acerca de qué funciones y entornos utilizar para varias tareas de desarrollo comunes.

Además, tenga en cuenta que para agentes Agentforce que utilizan funciones como la Biblioteca de datos Einstein, artículos Knowledge y datos no estructurados, las pruebas integrales están limitadas a menos que tenga un sandbox de Data 360. También necesita un entorno sandbox de Data 360 para garantizar condiciones de prueba precisas.

• Desvincule entornos de artefactos de versión. No utilice el desarrollo basado en organizaciones. Trate los entornos como lugares donde se realiza el trabajo durante un tiempo fijo. Considere el estado de los metadatos en un entorno como separado de sus artefactos de versión. Si una parte del código o la configuración se “descifra” en un entorno, debe confirmarse con el control de origen, convirtiéndolo en un artefacto de versión.

  • Los entornos son efímeros. Cree procesos de modo que pueda crearlos y destruirlos lo más rápido posible.
  • Los artefactos perduran. Pertenecen al control de origen.

• Desvincule entornos de rutas de versión. Es común ver rutas de versión obligatorias que requieren la implementación de cambios en entornos específicos. A menudo, este enfoque se implementa para establecer un proxy para validar la madurez de la aplicación o la estabilidad de la versión. Los equipos también pueden utilizarlo para intentar minimizar el número de entornos donde deben configurar una infraestructura de pruebas compleja. En paradigmas basados en origen, tiene mayor flexibilidad en cómo y dónde puede validar y probar cambios.

  • Las etapas de versión se aplican a artefactos de versión, no entornos. No cree un entorno solo con el fin de “recopilar” todos los cambios en una etapa de versión concreta. Para eso está el control de origen, especialmente la bifurcación. Utilice estrategias de bifurcación en el control de origen para organizar qué cambios implementar en qué entornos. Dependiendo del trabajo que necesite realizar, es posible que tenga que implementar todos los metadatos en una versión en un entorno. La bifurcación le permite hacer eso. Con algunas excepciones, cada entorno de desarrollo debe actualizarse o destruirse en cuanto finalice el trabajo relevante. Asegúrese de sincronizar cualquier cambio en metadatos que tenga lugar dentro de un entorno específico (y que desea conservar) con el control de origen.
  • Los entornos son tan útiles como su fidelidad a la producción. Optimice sus flujos de trabajo de configuración de entornos o automatización de modo que pueda derribar o actualizar entornos lo más rápido posible. Considere cualquier configuración que le impida realizar actualizaciones de entorno más rápidas y frecuentes como un riesgo crítico para la resistencia general de sus procesos de ALM. Si tiene trabajo de corrección relacionado, agréguelo a sus planes y asígnele prioridad. Explore cómo puede adoptar unidades modulares acopladas de forma más flexible en su sistema. Permiten a los equipos realizar más tipos de desarrollo en organizaciones borrador y liberan asignaciones de sandbox para otro trabajo. No olvide las funciones que las organizaciones borrador proporcionan para funciones de prueba que no tiene en producción, ya sea porque no adquirió licencias para ellas o las activó.
  • En entornos a los que los usuarios de negocio o usuarios finales pueden acceder, permita a esos usuarios centrarse en lo que les importa. No tenga entornos genéricos no diferenciados donde muchos grupos diferentes de usuarios finales o partes interesadas de negocio intentan realizar trabajo relacionado con ALM. Invite y active partes interesadas específicas en entornos específicos para realizar trabajo específico. Evalúe cuidadosamente cualquier proceso que ponga a los usuarios finales o partes interesadas de negocio en un entorno con más datos de los que admite un entorno sandbox de copia parcial. Asegúrese de que el volumen de datos es necesario para el trabajo que se va a realizar. Planifique sus pruebas de aceptación de usuarios y ciclos de desarrollo de etapa temprana de modo que se produzcan lo más juntos posible. Optimice todas las etapas de prueba para permitir ciclos de iteración y comentarios más rápidos y anteriores para sus equipos de desarrollo y usuarios finales. Consulte Estrategia de pruebas.

• Cree diferentes rutas de versión para diferentes tipos de cambios. No todos los cambios requieren que se completen los mismos tipos de trabajo de ALM en el mismo orden. Tener usuarios finales realizando pruebas de aceptación para cambios menores en componentes backend de un sistema probablemente no sea un buen uso de su tiempo. Sin embargo, la aceptación de usuarios y las pruebas de escala pueden ser tremendamente valiosas durante la etapa inicial de desarrollo de una aplicación móvil. Identifique rutas de lanzamiento para diferentes categorías de cambios, como riesgo alto, riesgo medio y riesgo bajo.

  • Riesgo alto: Los cambios afectan a clientes, socios o todos los usuarios internos. Los cambios afectan a la seguridad o la integración. Los cambios agregan nuevas funciones complejas.
  • Riesgo medio: Los cambios afectan a más de un umbral definido de usuarios internos. Los cambios afectan a modelos de datos, automatización que realiza operaciones de datos o integración.
  • Riesgo bajo: Afecta directamente a menos de un umbral definido de usuarios internos. No incluye cambios en la seguridad, modelos de datos o automatizaciones que implican operaciones de datos o integración.

• No permita que existan entornos superpoblados. La falta de disciplina en la priorización, el ámbito y la secuenciación del trabajo conduce inevitablemente a entornos de desarrollo sobrecargados, con volúmenes de trabajo que son demasiados, demasiados, demasiado diferentes. Los entornos superpoblados crean altos niveles de estrés, ambigüedad y conflicto entre los equipos de desarrollo. También crean ruido en las oportunidades en curso de desarrollo e impiden los esfuerzos de control de calidad. Además de estos efectos negativos, los entornos de desarrollo superpoblados son graves amenazas para el mantenimiento y la seguridad del medio ambiente. Considere la masificación como un síntoma de posibles problemas en sus procesos de ALM. Investigue cualquier problema de causa raíz y resuélvalo. Si aún se enfrenta a aglomeraciones, puede adquirir entornos sandbox adicionales.

La lista de patrones y antipatrones para ALM muestra el aspecto adecuado y deficiente de la gestión del entorno en una organización de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse.

Para obtener más información acerca de herramientas de Salesforce para la gestión del entorno, consulte Herramientas de Salesforce para Resiliencia.

Una estrategia de señalización define las señales críticas y la instrumentación de aplicación necesaria para detectar, diagnosticar y remediar fallos antes de que se degraden en cascada en todo el sistema. La instrumentación efectiva transforma aplicaciones de víctimas pasivas de fallos en participantes activos en su propia resiliencia, capaces de detectar problemas, adaptar su comportamiento y coordinar la degradación elegante cuando sea necesario.

Cuando las aplicaciones implementan instrumentación integral, obtienen la capacidad de autorregularse bajo estrés, comunicar su estado de salud a los operadores y participar en esfuerzos de recuperación coordinados. Estas funciones permiten a los sistemas mantener la calidad del servicio incluso cuando los componentes individuales experimentan dificultades. Por otro lado, sin la instrumentación adecuada, las aplicaciones se convierten en cajas negras que fallan silenciosamente hasta que aparecen síntomas catastróficos. Los equipos reaccionan ante problemas solo después de que los usuarios los reporten, y la solución de problemas se convierte en un ejercicio de arqueología en vez de observación.

• Detecte fallos en la aplicación. Las aplicaciones deben instrumentarse para detectar y responder a patrones de fallo comunes que surgen bajo carga pesada. Considere la saturación de colas. Cuando las colas de mensajes se rellenan más rápido de lo que se pueden procesar, las aplicaciones no instrumentadas continúan aceptando trabajo hasta que se produzcan el agotamiento de la memoria o cascadas de tiempo de espera. Las aplicaciones correctamente instrumentadas monitorean la profundidad de la cola, los índices de rechazo y la latencia de procesamiento, desencadenando respuestas defensivas cuando se superan los umbrales.

• Gestionar eficazmente señales desde fuera de la aplicación: La gestión de señales desde el sistema operativo representa otro punto de instrumentación crítico. Las aplicaciones deben registrar controladores para señales de terminación (SIGTERM, SIGINT) para activar el apagado elegante. Durante el apagado, las aplicaciones equipadas correctamente dejan de aceptar nuevo trabajo, permiten que las solicitudes en vuelo se completen, lavan los buffers, cierran conexiones de forma limpia y cancelan el registro del descubrimiento de servicios. Este apagado orquestado evita la pérdida de datos y permite a los equilibradores de carga redirigir el tráfico sin interrupciones.

• Instrumento para escenarios de fallo complejos: Más allá de estos patrones básicos, las aplicaciones deben instrumentar para modos de fallo más sutiles. La identificación de fallos grises, donde los componentes parecen saludables para algunos observadores mientras fallan para otros, requiere correlacionar señales internas y externas. Una aplicación podría instrumentar su conjunto de conexiones de base de datos para reportar comprobaciones de estado satisfactorias mientras realiza un seguimiento simultáneo de los índices de finalización de transacciones que revelan una degradación progresiva. Las estrategias de instrumentación efectivas cubren múltiples puntos de observación.

  • Las mediciones de negocio realizan un seguimiento de indicadores de éxito específicos de la aplicación, como índices de realización de pedidos o calidad de resultados de búsqueda.
  • Las mediciones del sistema monitorean la utilización de recursos, las distribuciones de latencia y los índices de error.
  • Las sondas sintéticas realizan continuamente rutas críticas para detectar la degradación antes de que los usuarios la encuentren.
  • El rastreo distribuido proporciona visibilidad a nivel de solicitud entre límites de servicio.

Estas señales se exponen a través de interfaces estandarizadas que permiten a los sistemas automatizados y operadores humanos evaluar el estado de la aplicación. La instrumentación en sí se convierte en parte de la estrategia de resiliencia de la aplicación, permitiendo a los disyuntores desencadenarse basándose en índices de error, los escaladores automáticos para responder a profundidades de cola y los operadores para tomar decisiones fundamentadas durante incidentes.

Los patrones y antipatrones para ALM muestran el aspecto de una estrategia de señalización adecuada y deficiente en una organización de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse.

Para obtener más información acerca de herramientas de Salesforce para una estrategia de señalización, consulte Herramientas de Salesforce para Resiliencia.

Una estrategia de prueba es un conjunto de principios rectores y estándares sobre cómo planificar y ejecutar pruebas que miden el éxito y el fallo de las aplicaciones durante los procesos de ALM. Una estrategia de prueba mantiene a todas las partes interesadas que participan en pruebas informadas y alineadas con la prioridad, el propósito y el ámbito de una prueba concreta. También ayuda a los equipos de proyectos a crear planes de prueba efectivos y reflexivos.

Normalmente, los desarrolladores o expertos en pruebas y garantía de calidad participan en la creación y ejecución de pruebas específicas. Una estrategia de prueba ayuda a garantizar que estas personas sepan qué tipos de pruebas se deben realizar para un proyecto concreto y en qué secuencia realizarlas. Una estrategia de prueba también ayuda a garantizar que los equipos tienen lo que necesitan para crear pruebas, planes de prueba y artefactos bien formados (por ejemplo, conjuntos de datos de prueba, dispositivos y simuladores de tráfico o red).

Una estrategia de pruebas efectiva crea una imagen clara de cómo, cuándo, dónde y por qué ejecutar diferentes tipos de pruebas (incluyendo pruebas de unidad, pruebas de interfaz de usuario y pruebas de regresión) en varias combinaciones y condiciones para descubrir cómo se comportará su sistema y cualquier cambio en vuelo. Una estrategia de prueba efectiva produce pruebas que le muestran cuán bien se ajusta un sistema a requisitos no funcionales, como escalabilidad, fiabilidad y capacidad de uso, que pueden ser difíciles de medir a través de un único tipo de prueba.

Para crear estrategias de prueba efectivas para Salesforce:

• Pruebe de forma iterativa, frecuente y automatizada tanto como sea posible. Diseñe e implemente la automatización de pruebas que permite a los equipos ejecutar una variedad de tipos de pruebas en una variedad de cargas de trabajo. Orqueste varias ejecuciones de prueba para que se produzcan automáticamente cuando los cambios entren en control de origen. Este enfoque permite a los equipos identificar y solucionar regresiones de forma proactiva desde el principio. Utilice integración continua/entrega continua (CI/CD) para este esfuerzo si es posible. Si no lo hace, establezca planes de prueba claros que permitan a los equipos ejecutar secuencias de pruebas de forma temprana y frecuente, de manera autoservicio. Para pruebas de agentes Agentforce, confíe en Centro de pruebas para pruebas rigurosas por lotes de agentes de IA con varias entradas para garantizar que funcionan correctamente en diferentes escenarios.
• Reconozca que no todos los cambios requieren cada tipo de prueba. Del mismo modo que una canalización de versión efectiva acomoda rutas para aplicaciones de alto, medio y bajo riesgo, también lo hace una estrategia de prueba efectiva. Defina claramente para los equipos cómo seleccionar y seguir un régimen de pruebas apropiado para aplicaciones con varios tipos de riesgo, casos de uso o complejidad. Consulte Estrategia medioambiental.
• Defina qué pruebas se pueden realizar en diferentes tipos de entorno. La fidelidad a la producción es un componente clave de pruebas precisas, pero significa cosas diferentes para diferentes tipos de pruebas. Por ejemplo, las pruebas de regresión necesitan fidelidad a la producción en términos de metadatos y, en cierta medida, datos. Asegúrese de definir qué tipo de fidelidad a la producción se requiere para un conjunto de pruebas concreto y clasifique claramente qué tipos de entornos pueden admitir las condiciones apropiadas para diferentes pruebas. Para obtener una descripción general de los tipos de trabajo que se alinean con cada tipo de entorno, consulte Estrategia medioambiental.
• Utilice pruebas de resistencia, estrés, desempeño y escala para medir continuamente la madurez de la aplicación. Estas pruebas muestran cuán lista la versión está una aplicación, en relación con las necesidades a nivel de producción. Para nuevas funciones principales, ejecute estas pruebas en varios intervalos en el ciclo de desarrollo de la aplicación. Es un antipatrón considerar estas pruebas como parte de solo una fase o etapa de desarrollo en vez de como parte de tareas en curso. Es más útil para los equipos obtener comentarios sobre el desempeño de la aplicación de forma temprana y frecuente, lo que les ayuda a comprender mejor lo cerca o lejos que está la aplicación de la preparación a nivel de producción. La capacidad de identificar y solucionar mejor problemas antes de que los cambios entren en producción merece la pena por la complejidad adicional de ejecutar pruebas más sofisticadas con frecuencia.
  • Sepa qué pruebas importan. Probablemente tendrá una cantidad fija de tiempo para realizar sus pruebas de escala o desempeño, haciendo que no sea práctico probar cada aspecto de su sistema. No todas las funciones se utilizan por igual, y no todos los cuellos de botella de escala afectarán al negocio por igual. Asegúrese de que sus pruebas de escala están centradas en las partes más utilizadas y valoradas del sistema. Defina y comprenda las oportunidades más importantes para verificar y mejorar la escala y el desempeño en su organización.
  • Sepa el aspecto “suficientemente bueno”. Definir los criterios de éxito para sus pruebas de escala y desempeño es clave. Asegúrese de que usted y sus equipos de desarrollo utilizan los criterios de éxito como indicadores de prueba. Además, asegúrese de que informan sobre los requisitos funcionales que crean los equipos de desarrollo. Normalmente, estos criterios incluyen la compatibilidad con un número específico de usuarios simultáneos con tiempos de respuesta inferiores a un valor acordado y sus objetivos de servicio (SLO). Defina sus criterios de destino clave y luego diseñe pruebas de escala y desempeño que garanticen que se cumplen los criterios.
  • Asegúrese de tener entornos adecuados. Las pruebas de escala y desempeño requieren una fidelidad particular a la producción. Sus conjuntos de datos, datos demográficos de solicitudes, índices de solicitudes y características de carga de trabajo en sus entornos no de producción deben coincidir con lo que ve en producción tanto como sea posible. Para las pruebas de escala, debe utilizar un Sandbox completo. Si su organización no tiene un Sandbox completo para pruebas de escala, no puede ejecutar pruebas de escala adecuadas.
• Asegúrese de que las cargas de trabajo de prueba le ayudan a medir requisitos no funcionales. Recuerde tener en cuenta:
  • Datos de prueba: Se debe realizar todo tipo de pruebas con datos aislados de la producción. En pruebas de unidades Apex, implemente patrones de fábrica para garantizar que el código genera sus propios datos de prueba, aislados de datos de entorno. También puede crear y mantener conjuntos de datos de prueba en una variedad de formatos para probar comportamientos de carga de datos, rellenar entornos de desarrollo con datos para pruebas basadas en la interfaz de usuario y ayudar con pruebas de integración. Todos los datos de prueba, ya se mantengan como un conjunto de datos externalizado o se creen on demand por código de fábrica de datos, deben depurarse de datos confidenciales e identificativos. Debe incluir datos dañados, incompletos y mal formados para admitir comportamientos de prueba de unidad negativos y de límite.
  • Servicios simulados: Para pruebas de integración, puede utilizar servicios simulados para simular respuestas de API. Apex admite una API de código auxiliar para crear marcos de trabajo simulados para su uso en pruebas Apex. Simulación para crear marcos de trabajo simulados que se pueden utilizar en pruebas Apex. Las simulaciones y los stubs pueden ayudar a validar comportamientos de tratamiento de datos de un sistema, con menos dependencia de fábricas de datos complejas o conjuntos de datos de prueba externos. Las simulaciones y los stubs son a veces más apropiados para utilizar en pruebas donde el tráfico similar a producción o los volúmenes de datos no son relevantes.
  • Dispositivos y tecnología de asistencia: Una parte clave de la creación de aplicaciones atractivas y accesibles es garantizar que cumplen las expectativas de los usuarios entre una variedad de dispositivos y con diferentes tipos de tecnologías de asistencia. Las pruebas de capacidad de uso significativas pueden requerir más inversión y diferentes tipos de experiencia para llevarse a cabo de forma efectiva, pero es una parte esencial de saber cuán bien diseñadas estarán sus aplicaciones de cara al usuario cuando se publiquen.
  • Simuladores: Cuando necesita replicar volúmenes similares a producción de solicitudes de usuario, tráfico de API o variaciones en la velocidad de red, es posible que necesite herramientas que simulen estas condiciones. No todas las pruebas necesitan este nivel de inversión. Estas herramientas son a menudo más útiles en pruebas de escalabilidad y desempeño.
  • Pruebas de IA y agentes: Un objetivo principal de las pruebas es reducir las alucinaciones de IA, que son respuestas convincentes que son fabricadas e incorrectas. Asegúrese de que los casos de uso de IA se prueban para resaltar problemas comunes causados por una comprensión incompleta del cliente, datos que faltan, campos con metadatos incompletos y datos desfasados. Utilice el Centro de pruebas para ayudar con la creación de datos de prueba necesarios para dichas pruebas.

La siguiente tabla muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar u objetivo para la corrección.

✨ Descubra más patrones para ALM en el Explorador de patrones y antipatrones.

En ingeniería de seguridad y fiabilidad de sitio (SRE), la respuesta ante incidentes se centra en cómo los equipos identifican y abordan eventos que afectan a la disponibilidad general o la seguridad de un sistema, así como en cómo trabajan los equipos para abordar causas raíz y evitar problemas futuros. La respuesta a incidentes implica los procesos, las herramientas y los comportamientos organizativos requeridos para solucionar problemas en tiempo real y después de que se produzca un problema.

Como arquitecto, es posible que no sea la persona que monitoree las operaciones de su solución en el día a día una vez que entre en funcionamiento. Parte de la arquitectura para la resiliencia es el diseño de funciones de recuperación que permiten a los equipos de asistencia realizar diagnósticos de primer nivel, estabilizar sistemas y entregar de forma efectiva la investigación y la mitigación de causas raíz a equipos de desarrollo o mantenimiento. Es posible que los equipos que asisten directamente a los usuarios en el día a día no tengan una comprensión profunda o experiencia en la arquitectura del sistema. Es esencial que estos equipos tengan las herramientas y los procesos que necesitan para monitorear las operaciones diarias, acceder a la información desde el sistema al diagnosticar un posible incidente y servir como primeros intervinientes efectivos para cualquier problema que afecte a la disponibilidad.

Puede mejorar el grado de respuesta de los equipos a incidentes en sus soluciones de Salesforce centrándose en su tiempo de recuperación, capacidad de triaje y monitoreo y alerta.

Cuando se produce un incidente, la primera prioridad debe ser restaurar los sistemas a un estado operativo estable. A menudo, los negocios piensan que la única forma de recuperarse de un incidente es “solucionar el problema”. Este supuesto es justo en que el análisis de causa raíz preciso y la solución es la forma en que resuelve problemas críticos en un sistema. Sin embargo, “solucionar el problema” durante las primeras etapas de la respuesta a la crisis no es el enfoque más práctico. Dependiendo de la gravedad de un incidente, cada segundo de este y su repercusión podría llevar a una pérdida de ingresos o reputación para el negocio.

A menudo, intentar diagnosticar y solucionar la raíz retrasa los esfuerzos para restaurar un sistema a funcionamiento. Logísticamente, la adopción de un enfoque que solicita a los respondedores de incidentes que aborden las causas profundas ejerce una enorme presión sobre los expertos en la materia (SME) y el personal de asistencia de su compañía. Trabajar para encontrar y solucionar causas raíz durante un incidente requiere que las PYME estén a la espera de cada incidente, lo que puede impedir que el personal de atención al cliente actúe en primera línea. También puede dar como resultado que los equipos publiquen cambios que, a su vez, creen más incidentes. En última instancia, un enfoque de este tipo aumenta los costos, consume ancho de banda entre equipos y lleva a comportamientos en tiempos de crisis que pueden erosionar la Trust del cliente y la reputación de la marca.

El paradigma de gestión de incidentes correcto es priorizar y centrarse en la recuperación como un primer paso. Después de restaurar la estabilidad de un sistema, puede realizar un seguimiento con autopsias irreprochables, investigaciones de incidentes, corrección de causas raíz y actividades similares. Este orden de operaciones permite mejor al personal de respuesta ante incidentes clasificar, diagnosticar y ejecutar tácticas de recuperación, alertando a las PYME relevantes para que ayuden solo cuando sea necesario. También permite a las PYME identificar y solucionar las causas profundas de un incidente con menos presión de un reloj automático.

Para adoptar una mentalidad de recuperación en primer lugar a la respuesta ante incidentes:

• Establezca y alcance objetivos de nivel de servicio SLO. Los SLO son estándares que desarrolla con sus partes interesadas para requisitos no funcionales específicos (NFR) de un sistema, como desempeño o tiempo de disponibilidad. Estos objetivos se miden por indicadores de nivel de servicio (SLI), durante un periodo de tiempo. Sin los SLO, gran parte del trabajo relacionado con la respuesta a incidentes y la solución de problemas complejos puede parecer desorganizado y reactivo, por ejemplo, lo que provoca una acción rápida para “detener este error específico, para este puñado de usuarios que lo reportaron”. Este ciclo es a menudo lo que provoca que los equipos acerquen el análisis de causa raíz a la respuesta ante incidentes, ya que parece que ayudará a detener los comportamientos reactivos. Establecer SLO e SLI es una forma más efectiva de empezar. Para establecer SLO, piense en estas preguntas.
  • ¿Cuáles son los NFR de su sistema para los próximos 1-3 años? Por ejemplo, su NFR puede incluir los tiempos de respuesta, los índices de solicitudes máximos y los usuarios simultáneos que su sistema debe poder admitir.
  • ¿Qué desea que experimenten sus clientes y sus usuarios? Base sus SLO en la respuesta a esta pregunta, que podría ser: “Los usuarios pueden ejecutar reportes rápidamente en Salesforce”.
  • ¿Qué puede medir y durante qué periodo de tiempo debe medirlo? Base sus SLI en la respuesta a esta pregunta. Una SLI que coincida con el ejemplo anterior podría ser “x % de la carga de reportes en n segundos de media, medida en un periodo de 30 días”.
• Defina y estandarice tácticas de recuperación. Las reversiones de cambios y las implementaciones de soluciones pueden ayudar a que un sistema vuelva a funcionar y minimizar la repercusión de un incidente. Tácticas y protocolos de recuperación de documentos que pueden ejecutar los miembros apropiados de sus equipos de asistencia u operaciones. Las tácticas de recuperación varían en función del tipo de incidente. La siguiente tabla muestra un marco general que asigna tipos de incidentes a tácticas de recuperación. Para obtener más información sobre la identificación de puntos de fallo y la definición de estrategias de mitigación, consulte Disponibilidad.

• Defina criterios de salida claros. Utilice sus SLO para determinar cuándo su sistema está fuera del estado de incidente o impacto.
• Defina procesos para revisiones posteriores a incidentes y la solución de causas raíz. Tómese su tiempo para revisar incidentes después de restaurar el servicio. Durante las revisiones, adopte un enfoque post mortem sin culpa. Trabaje con las partes interesadas para centrarse en establecer hechos claros sobre lo que ocurrió y cómo ocurrió, en vez de intentar asignar fallos o culpas a individuos. Utilice diferentes formatos de revisión para examinar formas de solucionar problemas a largo plazo.
  • Una revisión posterior se centra en la respuesta al incidente. Es útil para evaluar si existen los procesos y las tácticas de respuesta apropiados.
  • Un análisis de causa se centra en la causa raíz del incidente. Puede ayudar a identificar cualquier fallo o problema en el diseño e implementación de su sistema que condujo al incidente.
• Practique sus protocolos de recuperación acordados periódicamente. Practique protocolos de recuperación para asegurarse de que todos saben cómo gestionar bien los incidentes. Utilice entornos sandbox y de prueba para proporcionar a los equipos lugares para practicar la simulación y recuperación de incidentes. Practique también sus revisiones posteriores al incidente. Hacer toda esa práctica hace que la recuperación forme parte de su cultura de ingeniería y asistencia.

Los patrones y antipatrones para respuesta ante incidentes muestran el aspecto de la arquitectura para priorizar la recuperación en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse.

Para obtener más información acerca de herramientas de Salesforce para ayudar con el tiempo de recuperación, consulte Herramientas de Salesforce para Resiliencia.

En el contexto de la tecnología, la clasificación implica la asignación de categorías y niveles de gravedad a problemas y solicitudes de asistencia. No importa cuán bien planificada esté su solución, surgirán problemas y solicitudes de asistencia al usuario. Estos problemas pueden deberse a una falta de capacitación suficiente o gestión de cambios, brechas en la interfaz de usuario/UX, comportamientos inesperados del usuario final y problemas urgentes del sistema no detectados por el monitoreo o alerta.

Los equipos de asistencia y operaciones necesitan poder investigar consultas de asistencia de usuarios de forma eficiente y diagnosticarlas rápidamente. Triplicar problemas para filtrar problemas menos graves y detectar rápidamente incidentes críticos del sistema es una competencia clave para estos equipos. La mala clasificación ralentiza todos los niveles de asistencia al usuario, prolonga incidentes críticos y aumenta el riesgo de más interrupciones para sus clientes y su negocio.

Aunque es posible que no esté involucrado en operaciones y asistencia diarias, como arquitecto, es su responsabilidad ayudar a garantizar que su equipo de asistencia y operaciones pueda clasificar problemas de forma efectiva en cualquier solución que cree en Salesforce Platform.

Para permitir a los equipos clasificar problemas de forma efectiva en sus soluciones de Salesforce:

• Asegúrese de que los equipos de asistencia tienen acceso a información útil.
  • Documente su sistema y diseñe patrones. Garantizar la legibilidad y la coherencia en su solución es una parte clave para permitir al personal de asistencia comprender el sistema que es responsable de dar cobertura. En su documentación, considere cómo los equipos encontrarán información acerca de cómo priorizar problemas o incidentes con diferentes partes del sistema. Además, asegúrese de que los equipos pueden obtener rápidamente información técnica sobre tácticas de recuperación basándose en el área de impacto. Proporcione guías de solución de problemas relevantes para problemas comunes de Agentforce, como Clasificación de temas y Selección de acciones, que pueden ayudar a los equipos a clasificar rápidamente problemas relacionados con permisos o configuración.
  • Diseño pensando en depurar. Los equipos de asistencia y los administradores de la organización tendrán que activar la depuración y el diagnóstico para clasificar correctamente problemas de usuarios en varios entornos. Algunos ejemplos de patrones depurativos incluyen aquellos que incorporan mensajes de error personalizados y de registro en rutas de ejecución en todo el sistema. Active equipos de asistencia en enfoques de depuración comunes Agentforce con herramientas como registros de eventos y la vista de razonamiento de Agent Builder.
  • Identifique las PYME y las partes interesadas de incidentes. Cree una lista de pymes o partes interesadas relevantes que deben estar disponibles para respaldar la recuperación de un incidente y que deben participar durante el análisis posterior al incidente.
  • Trata las transferencias cuidadosamente. Garantice la calidad de cada traspaso de solución a equipos de asistencia u operaciones como parte del lanzamiento. Proporcione capacitación para que el personal de asistencia recorra la arquitectura del sistema relevante y simulacros de respuesta ante incidentes. Piense en transferencias posteriores a incidentes, incluyendo cómo los equipos deben documentar información que no está capturada por registros o notas de casos, así como cómo los respondedores de incidentes pueden contribuir a investigaciones de causas raíz o realizar pruebas de aceptación de usuarios para cualquier corrección.
• Si se le consulta, mantenga a todos centrados en la recuperación como la principal preocupación.
  • Responde rápido. Responda rápidamente a cualquier solicitud de asistencia de usuario, notificaciones de monitoreo y alertas que reciba.
  • Ayude a distinguir síntomas de problemas. Trabaje para determinar si hay un incidente del sistema real que se debe solucionar. Intente identificar los componentes con los problemas reales. Ayude a garantizar que se siguen las tácticas de recuperación acordadas para sacar el sistema del estado de incidente rápidamente.
• Para agentes Agentforce admitiendo casos de uso críticos, asegúrese de que existen soluciones viables y relevantes y que se pueden activar con poca antelación como una medida de redundancia. Algunos ejemplos incluyen el cambio a la gestión manual o el redireccionamiento a documentación relevante para su revisión manual.

Los patrones y antipatrones para respuestas ante incidentes muestran el aspecto de la arquitectura para la clasificación efectiva en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse.

Para obtener más información acerca de herramientas de Salesforce para ayudar con el triaje, consulte Herramientas de Salesforce para Resiliencia.

Monitoreo y alerta son términos ampliamente utilizados en ingeniería de fiabilidad de sitios. En el contexto de la resiliencia del sistema, el monitoreo evalúa continuamente el estado actual de un sistema, y la alerta automatiza las notificaciones a las partes interesadas sobre posibles preocupaciones acerca del estado del sistema. El monitoreo y la alerta efectivos son una parte clave para desvincular la escala y el crecimiento de su sistema de la escala y el crecimiento de su personal de asistencia.

Salesforce proporciona una variedad de funciones integradas para monitorear comportamientos en su sistema. Salesforce también ofrece monitoreo de eventos en tiempo real como complemento o como parte de Salesforce Shield. En cualquier solución de Salesforce, los diseños diseñados para el monitoreo y la alerta proporcionan:

• Funciones para la respuesta ante incidentes automatizada
• Información relevante para los usuarios correctos, en el momento correcto
• Información clara para vistas históricas y análisis de tendencias

Para diseñar un monitoreo y alertas efectivos en sus soluciones de Salesforce:

• Haga de la automatización una prioridad. Aunque notificar a los usuarios sobre cambios de estado críticos es una parte crucial para mantener sus sistemas estables y operativos, en una arquitectura ideal, el sistema autocorrige problemas cuando es posible y solo envía alertas para problemas urgentes no recuperables. Incluso sin funciones de autocorrección, la automatización puede hacer que sus alertas y reportes sean más útiles.
  • Comience con lo que Salesforce ya proporciona. Salesforce Platform proporciona registros y API relevantes para que monitoree las operaciones de su solución con respecto a los límites reguladores. Además, la plataforma envía alertas para infracciones de límites reguladores y problemas similares. Utilice estos registros y alertas como la base para explorar formas de automatizar más completamente la recuperación automática del sistema, la creación de reportes de incidentes y alertas. Por ejemplo, puede implementar una automatización que monitoree el registro y luego realice una acción de recuperación cuando se registre un tipo de evento concreto.
  • Clasifique los cambios en el estado del sistema de formas predecibles. Cree categorías específicas con sentido para estados clave sobre los que desea monitorear y crear reportes. Alinee estas categorías con las categorías que define para gestionar el estado en sus componentes de aplicación. Adopte una mentalidad orientada a API para el modo en que gestiona la información de cambios de estado. Los formatos de mensajes coherentes y las categorías de estado simplifican la automatización, la creación de reportes y las alertas.
  • Alinee su lógica de automatización con las otras partes de su sistema. Si creó un tratamiento de errores de automatización adecuado, puede ampliar esos patrones a cómo clasifica los cambios de estado y responder con automatización. Para cambios de estado que se consideran recuperables, puede automatizar comportamientos de reintento. Para cambios de estado que se consideran críticos o fatales, automatice alertas a usuarios.
• Evite crear ruido. Cuando los usuarios reciben demasiadas alertas, especialmente alertas que no requieren realizar ninguna acción, tienden a empezar a desactivar o ignorar todas las alertas. Este escenario socava cualquier esfuerzo para crear alertas útiles. Para definir mejor quién recibe alertas, qué las desencadena y cuándo se desencadenan, considere hacer estas cosas.
  • Cree mapas de partes interesadas. Para asegurarse de que su sistema entrega las alertas correctas a las partes interesadas correctas en el momento correcto, primero identifique y clasifique sus grupos de partes interesadas.
  • Enrute mensajes basándose en privilegios de usuario. Solo envíe alertas a destinatarios que tengan la capacidad y la autoridad de responder. Los usuarios de negocio podrían beneficiarse de alertas sobre problemas que pueden solucionar corrigiendo problemas en registros a los que tienen acceso. Si un problema requiere una respuesta técnica más implicada, las alertas deben dirigirse al personal de asistencia.
  • Deje clara la respuesta esperada. Solo envíe alertas en escenarios que requieren intervención humana. Estructure mensajes para indicar claramente la acción que se espera del destinatario. Si envía una alerta a una parte interesada para su visibilidad, y no se requiere ninguna acción de su parte, déjelo claro en la versión del mensaje que recibe.
  • Haga que las alertas sean oportunas y relevantes. Las alertas que se entregan en respuesta a fallos que se produjeron y que aún necesitan remediarse no son tan útiles como las alertas sobre un posible fallo. Idealmente, se alerta al personal de asistencia en cuanto se producen condiciones problemáticas en el sistema, proporcionando una oportunidad para detectar problemas antes de que puedan tener repercusiones negativas en las operaciones de negocio.

La lista de patrones y antipatrones muestra el aspecto de la arquitectura para un monitoreo y alerta efectivos en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse.

Para obtener más información acerca de las herramientas de Salesforce para el monitoreo y la alerta, consulte Herramientas de Salesforce para Resiliencia.

Esta tabla muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar o dirigir para su corrección.

✨ Descubra más patrones para la respuesta ante incidentes en el Explorador de patrones y antipatrones.

Una clave para la resiliencia del negocio es la planificación de la continuidad, que se centra en cómo permitir que las personas y los sistemas funcionen a través de problemas causados por un evento no planificado. Los planes de continuidad de negocio (BCP) tienen una visión orientada a las personas de cómo mantener los procesos avanzando a través de la crisis. Los aspectos técnicos de la planificación de la continuidad figuran en las partes de recuperación en casos de desastre de un BCP. Consulte Continuidad de tecnología.

Sin planes de continuidad adecuados, su organización podría ahora saber cómo actuar (y por lo tanto no actuar en absoluto) durante una crisis o un fallo del sistema. La planificación de continuidad ineficaz puede tener un impacto catastrófico en clientes, partes interesadas y negocio. Tras un evento adverso, cada momento que pasa sin mantener o recuperar procesos críticos corre el riesgo de sufrir daños financieros, daños a la reputación, la seguridad de los empleados e incluso el cumplimiento normativo.

Puede crear una mejor planificación de continuidad en sus sistemas centrando sus esfuerzos en tres áreas: definir la continuidad de negocio para Salesforce, planificar la continuidad de la tecnología y crear funciones de copia de seguridad y restauración.

Es posible que su compañía ya tenga un BCP establecido. Si es así, asegúrese de que Salesforce está incluido en él. Si su compañía no tiene un BCP, trabaje con sus partes interesadas para crear uno que cubra sus organizaciones de Salesforce.

A menudo se confía en Salesforce para que sea una fuente de verdad para datos de clientes y procesos de negocio esenciales entre muchas divisiones de negocio. Como tal, la función que desempeña Salesforce en un BCP puede diferir de las funciones que desempeñan otros sistemas. Es probable que Salesforce participe en muchas áreas de alta prioridad para la recuperación.

Para crear una planificación de continuidad de negocio relevante para sistemas de Salesforce:

• Aclare prioridades para recuperación. Al igual que con el enfoque general para la respuesta ante incidentes, la recuperación debe ser la primera prioridad para los sistemas en momentos de crisis. Muchos servicios clave de negocio se ejecutan en y con Salesforce. Debe ayudar a las partes interesadas a identificar la prioridad correcta para recuperar varias funciones y capacidades de negocio. Un marco general podría ser:
  • Estabilice la infraestructura de negocio esencial.
  • Estabilice los servicios al cliente.
  • Estabilice los servicios de empleados y socios.
• Tenga en cuenta su ecosistema en sus BCP. Salesforce no es el único sistema en su panorama. Asegúrese de identificar brechas en su BCP alrededor de sistemas que se integran con Salesforce, soluciones instaladas desde proveedores AppExchange y cualquier otro sistema que se conecta a datos o procesos en Salesforce. Si su capacidad de entrega depende de proveedores, pregunte a esos proveedores acerca de sus planes de continuidad. Evalúe sus funciones y planifique cómo mantener sus sistemas disponibles.
• Integre las preocupaciones de BCP en su estrategia de pruebas. Cree planes de prueba para su BCP y llévelos a cabo. Es especialmente importante probar las áreas de su BCP relacionadas con procesos o personas, que a menudo se pasan por alto. Incorpore elementos relevantes de su BCP en su estrategia de prueba de ALM general. Cree y siga una programación de mantenimiento para revisar pruebas y asegurarse de que su plan se mantiene actualizado.

Los patrones y antipatrones para planificación de continuidad muestran el aspecto adecuado y deficiente de la planificación de continuidad en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir, o para identificar lugares en su sistema que necesitan refactorizarse.

Para obtener más información acerca de las herramientas de Salesforce para definir la continuidad del negocio, consulte Herramientas de Salesforce para Resiliencia.

El objetivo de la continuidad de la tecnología es asegurarse de que los problemas con componentes en un sistema no impiden que el negocio mantenga operaciones esenciales. Salesforce prioriza el mantenimiento de nuestros servicios en los niveles más altos de disponibilidad y la provisión de información transparente sobre cualquier problema. Puede ver información en tiempo real sobre el desempeño del sistema de Salesforce y problemas en trust.salesforce.com. Como arquitecto que construye en Salesforce, sus soluciones se benefician de las funciones de fiabilidad, seguridad y desempeño del sitio que Salesforce proporciona en toda la plataforma.

Sin embargo, la continuidad general de sus soluciones de Salesforce va más allá de los servicios integrados que proporciona Salesforce. Desde una perspectiva arquitectónica, la planificación de la continuidad de la tecnología de Salesforce debe comenzar con la formulación y respuesta de preguntas acerca de cómo se ajusta Salesforce a su panorama de negocio más amplio. ¿Qué tipos de sistemas se integran con Salesforce? ¿Cómo dependen los sistemas externos de procesos o información en Salesforce? En sus organizaciones de Salesforce, ¿qué procesos o funciones se basan en soluciones AppExchange? ¿Acceden sus usuarios a Salesforce a través de servicios de identidad externos o SSO?

Para crear una mejor continuidad de la tecnología en sus sistemas de Salesforce:

• Evalúe su infraestructura. La estrategia de solución más común para problemas o interrupciones de la tecnología es crear servicios o sistemas redundantes a los que puede recurrir durante un incidente. En Salesforce, tenemos una arquitectura intencionadamente redundante, lo que significa que mantenemos copias de los sistemas y servicios de nuestros clientes en diferentes ubicaciones físicas. Utilizamos varias técnicas de recuperación de desastres, incluyendo el cambio de sitio, que nos permite dirigir el tráfico de usuarios de un centro de datos a otro si es necesario. Para identificar dónde podría necesitar crear redundancia intencionada, hágase estas preguntas.
  • ¿Qué sucede durante una interrupción del servicio para el servicio [X]? ¿Podemos cambiar de ese servicio a otro?
  • ¿Cuánto tarda en recuperarse [X]? ¿Cuál es el impacto para nuestros clientes? ¿Cuál es el impacto para nuestros socios? ¿Cuál es la repercusión en los equipos internos?
  • ¿Qué hay de las copias de seguridad y su frecuencia? ¿Podrían las copias de seguridad proporcionar los datos necesarios para dar cobertura al negocio?
  • ¿Tenemos dependencias de proveedores? ¿Cuáles son sus planes de BCP?
• Proporcione asistencia operativa. La asistencia operativa consiste en poner los equipos en marcha lo más rápido posible. Piense en cómo su sistema puede gestionar aumentos significativos en requisitos de capacidad y demanda de cambios imprevistos, incluyendo cambios que son de toda la industria, de toda la región o globales. Asegúrese de que su BCP tiene en cuenta los recursos adicionales o los procedimientos de ruptura que Ingeniería de fiabilidad de sitio (SRE) o los equipos de asistencia pueden necesitar para responder a incidentes de forma efectiva. Las preguntas que se deben formular acerca de la asistencia operativa incluyen:
  • En caso de fallo, ¿dispondrían nuestros equipos técnicos de las herramientas que necesitan para continuar trabajando? ¿Hemos simulado una interrupción para validar planes o identificar brechas?
  • Si un desastre está en un área específica, ¿tenemos planes de cobertura para esa área?
  • ¿Son nuestros clientes globales? ¿Funcionan 24/7?
  • ¿Tenemos monitoreo y alerta apropiados para notificar a las personas apropiadas cuando hay fallos?
• Automatice y pruebe sus tácticas de recuperación. Después de solucionar un problema, identifique dónde se produjo y cómo se solucionó. Si puede, basándose en la solución, automatice sus tácticas de recuperación y ajuste cualquier problema de proceso. Muchas compañías programan simulaciones de incidentes para un subconjunto de servicios para probar la resistencia del sistema. Un ejemplo podría ser simular una cuenta de administrador del sistema bloqueada o comprometida, o simular una interrupción o un problema con un proveedor AppExchange. Consulte Respuesta a incidentes.)Las preguntas que hay que formular acerca de cómo las pruebas y la automatización pueden ayudarle a restaurar servicios con mayor rapidez incluyen:
  • ¿Con qué frecuencia programamos y ejecutamos simulaciones de incidentes?
  • ¿Sabemos cuánto tarda en restaurar los servicios a un estado estable?
  • ¿Tenemos procesos de entrega estables?
  • ¿Sabemos dónde podemos automatizar la conmutación por error y la recuperación?

Trate cualquier elemento que surja de sus revisiones posteriores al incidente como sus otros elementos de desarrollo. Agréguelos a sus sistemas de planificación de modo que pueda priorizarlos y trabajar en ellos.

Los patrones y antipatrones para planificación de continuidad muestran el aspecto adecuado y deficiente de la planificación de continuidad de la tecnología en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir, o para identificar lugares en su sistema que necesitan refactorizarse.

Para obtener más información acerca de herramientas de Salesforce para la planificación de la continuidad de la tecnología, consulte Herramientas de Salesforce para Resiliencia.

La restauración de copias de seguridad de datos o metadatos puede ayudar a devolver su organización a su último estado estable conocido. También puede proporcionar un sistema de conmutación por error durante un fallo catastrófico del sistema o una interrupción del servicio. Realizar copias de seguridad de sus datos y metadatos regularmente y almacenar sus copias de seguridad cifradas en una ubicación segura agrega una capa adicional de resistencia a su arquitectura.

Sin estrategias de copia de seguridad y restauración, no puede restaurar versiones limpias de sus datos y metadatos de producción cuando se corrompen maliciosamente, cuando los defectos se abren paso inadvertidamente en producción o cuando un fallo durante una gran carga de datos corrompe los datos de producción. Cualquiera de estos escenarios puede dar como resultado que sus datos de producción críticos de negocio se corrompan o incluso se pierdan de forma permanente. La configuración de la tecnología de copia de seguridad y restauración ofrece una serie de ventajas además de la planificación de continuidad, incluyendo la asistencia con estrategias para mitigar grandes volúmenes de datos y cumplir con políticas de retención relacionadas con el cumplimiento.

Para ayudar a garantizar la continuidad con las estrategias de copia de seguridad y restauración en sus soluciones de Salesforce:

• Empiece. El primer paso para tener una buena estrategia de copia de seguridad y restauración es tener una estrategia en primer lugar. Incluso algo tan sencillo como realizar copias de seguridad nocturnas de todos los datos y metadatos de su organización puede ahorrar a su negocio la pérdida de información o funciones críticas durante un desastre.
• Restrinja el acceso a copias de seguridad. Los administradores del sistema son los únicos usuarios que deben tener acceso a copias de seguridad de sus datos. Esa restricción de acceso evita que un usuario de negocio pueda ver registros en una copia de seguridad que no estaría autorizado a ver en su organización.
• Pruebe su proceso de restauración regularmente. Independientemente de la estrategia de copia de seguridad y restauración que implemente, pruebe su proceso de restauración en un entorno sandbox de copia parcial o completa regularmente para asegurarse de que funcionará correctamente cuando lo necesite.
• Alinee su estrategia de copia de seguridad y restauración con su estrategia de archivo de datos. Determine qué debe suceder en sus copias de seguridad o archivos cuando se archivan o purgan registros de su sistema. Consulte Volumen de datos).

Es posible que necesite una estrategia de copia de seguridad más granular si sus volúmenes de datos son tan grandes que una copia de seguridad completa no tiene tiempo para completarse antes de que comience a ejecutarse la siguiente copia de seguridad. Es posible que también necesite una estrategia de copia de seguridad más granular si los datos de su organización cambian con tanta frecuencia que las actualizaciones son de misión crítica para su organización.

Para hacer que su estrategia de copia de seguridad sea más granular:

• Amplíe el ámbito de sus copias de seguridad a objetos específicos. Esta estrategia implica realizar copias de seguridad de registros desde diferentes objetos en diferentes intervalos de tiempo. Tenga en cuenta que los objetos secundarios deben realizarse copias de seguridad en los mismos intervalos que sus principales para mantener la coherencia de los datos.
• Copias de seguridad parciales de Timebox. Esta estrategia implica diferenciar entre copias de seguridad completas (de todos los datos y metadatos) y copias de seguridad parciales (de solo metadatos y registros que se agregaron o cambiaron desde la última copia de seguridad).

*No deje nunca de realizar copias de seguridad completas. Es importante tener en cuenta que nunca debe eliminar las copias de seguridad completas por completo, incluso si los volúmenes de datos dan como resultado tiempos de ejecución largos. Para grandes volúmenes de datos, planifique copias de seguridad completas regulares pero poco frecuentes (por ejemplo, copias de seguridad semanales). Planifique también copias de seguridad parciales o específicas de objetos más frecuentes (por ejemplo, copias de seguridad nocturnas o copias de seguridad cada X horas). Este enfoque le proporciona la flexibilidad de reconstruir el conjunto de datos más completo y preciso para utilizar en sus procesos de restauración.*

Los patrones y antipatrones para planificación de continuidad muestran el aspecto adecuado y deficiente de las funciones de copia de seguridad y restauración en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir, o para identificar lugares en su sistema que necesitan refactorizarse.

Copia de seguridad y recuperación de Salesforce, una solución integrada de Salesforce que incluye Recuperación propia desde la adquisición Propia, protege datos importantes de pérdidas o daños. Nuestra solución altamente segura, fácil de configurar y siempre disponible garantiza la continuidad del negocio y la resiliencia de los datos, y simplifica el cumplimiento.

Utilice Copia de seguridad y recuperación de Salesforce para evitar la pérdida de datos, recuperarse de incidentes de datos rápidamente y simplificar su estrategia general de gestión de datos. Puede crear políticas de copia de seguridad para datos de alto valor y regulados, y restaurar esos datos con solo unos clics.

Las copias de seguridad diarias automatizadas protegen todos los datos cruciales de su organización, incluyendo metadatos, entornos sandbox, datos de paquetes gestionados, archivos adjuntos y mucho más. Ejecute copias de seguridad con la frecuencia necesaria para cumplir sus objetivos de objetivo de punto de recuperación (RPO) y salvaguardar sus implementaciones. Las copias de seguridad son siempre accesibles y se almacenan de forma segura y conforme. Protección de datos continua también está disponible para datos aún más confidenciales o transaccionales, lo que permite una recuperación más rápida de información crítica que cambia rápidamente.

Detecte actividad de datos inusual, pérdida de datos y corrupción con alertas proactivas que se envían directamente a su email. Reciba alertas en tiempo real para identificar anomalías estadísticas o para crear reglas que le notifiquen de actividad de datos inusual, ayudándole a detectar incidentes más rápido que nunca.

Copia de seguridad y recuperación de Salesforce acelera la recuperación proporcionando visibilidad granular de los cambios, permitiendo la identificación y restauración rápidas de los datos afectados. Herramientas como gráficos visuales resaltan cambios no deseados, mientras que las funciones de recuperación fáciles de utilizar restauran con precisión objetos, campos y registros afectados.

Nuestras herramientas le permiten utilizar copias de seguridad para análisis, auditorías y cumplimiento, ofreciendo datos históricos con capacidad de búsqueda, funciones de búsqueda abiertas para la visibilidad de datos pasados y funciones de exportación para análisis externos o almacenamiento. Esto reutiliza las copias de seguridad sin necesitar API de Salesforce adicionales.

Copia de seguridad y recuperación ofrece una única consola para consolidar todas las copias de seguridad, la gestión, las operaciones y el cumplimiento. Esta consola le permite acceder, gestionar, personalizar y monitorear copias de seguridad para todas sus organizaciones de producción y entornos sandbox. Con él, también puede ejecutar solicitudes de titulares de datos para garantizar el cumplimiento de los datos de copia de seguridad y tener el control completo para personalizar las programaciones de copia de seguridad, la frecuencia y las políticas de retención.

• Mitigue la repercusión de incidentes de datos. Copia de seguridad y recuperación de Salesforce ayuda a mitigar incidentes de datos, como ciberataques o actividad interna o externa maliciosa, permitiendo a los usuarios revertir registros afectados a su estado previo al incidente. La función de exportación de Copia de seguridad y recuperación garantiza el acceso continuo y la capacidad de uso de los datos críticos de los usuarios.
• Evitar pérdida permanente de datos. Los errores humanos siguen siendo la causa principal de pérdida de datos. Backup and& Recover ofrece una solución precisa y rápida a estos errores.
• Cumple con mayor facilidad los requisitos legales y de cumplimiento de datos. Copia de seguridad y recuperación de Salesforce admite el modelo de responsabilidad compartida, lo que permite la función de autoservicio para las olvidaciones masivas o la rectificación de datos en sus datos de copia de seguridad.

Para obtener más información acerca de las herramientas de Salesforce de copia de seguridad y restauración, consulte Herramientas de Salesforce para Resiliencia.

Esta tabla muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar o dirigir para su corrección.

✨ Descubra más patrones para la planificación de continuidad en el Explorador de patrones y antipatrones.

Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra encuesta para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación.