Lea sobre nuestras programaciones de actualización aquí.

Las soluciones resilientes mantienen una alta calidad de servicio incluso cuando se producen fallos. Si el rendimiento 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 soporta y los soporta.
• Elasticidad: Una vez resueltos 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 un comportamiento inesperado no deseado. Un sistema demuestra un comportamiento resiliente 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 jubilación
• Respuesta a incidentes: Cómo identifican, solucionan y evitan los equipos problemas que afectan a la disponibilidad o 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

Gestión del ciclo de vida de aplicaciones (ALM) es una práctica para gestionar software de forma holística 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 un ALM efectivo, sus equipos reaccionan rápidamente al cambio y sus aplicaciones se mantienen al día con los requisitos comerciales en evolución sin comprometer la estabilidad o la calidad.

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

Los síntomas de ALM deficiente incluyen:

• Ciclos de desarrollo lentos y propensos a errores
• Implementaciones intensivas y difíciles
• Problemas o fallos de alta gravedad detectados en entornos de producción y posteriores al control de calidad
• 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 toca 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.

Cree 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 de entorno: 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 dentro del sistema antes de que se produzca la degradación
• Estrategia de prueba: Los principios y estándares que guían la forma en que planifica y ejecuta pruebas para medir el éxito de sus aplicaciones durante los 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 mueve a un entorno de destino al mismo tiempo.

La publicación de un cambio en un sistema introduce riesgo para é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 provocar un incidente crítico. En una arquitectura de soluciones, el diseño para versiones resistentes es algo más que 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 comerciales también se preocupan por la información de versión, especialmente si está relacionada con funciones o soluciones de errores 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:

• Alinear 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 priorizados de Agentforce. 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 versión o desarrollo basados en organización. 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 desarrollo y versión dirigidas por el 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 probabilidades 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 liberació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 empresa.

• Paquetes desbloqueados: Los paquetes desbloqueados son el artefacto de versión más estable. Implementar 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 fáciles de administrar por el sistema. Además, los paquetes requieren una gestión de metadatos sólida, lo que puede ayudarle a identificar dependencias mal gestionadas de forma temprana. También crean oportunidades en curso y artefactos 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 pro có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 anterior, 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 organización 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 los manifiestos de implementación.
• Asigne un nombre a sus versiones. Proporcione a sus versiones identificadores claros para ayudar 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 empresa, 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.
• En un manifiesto de versión, gestione dependencias bien. Los metadatos de Salesforce tienen dependencias integradas. Una razón común por la que las implementaciones de Salesforce fallan es que las dependencias no se gestionan correctamente. La selección de un mecanismo de versión estable, como se describe 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 de forma proactiva combinaciones problemáticas 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 ser refactorizados.

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 utilice durante los ciclos de desarrollo y prueba 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
• Configuraciones 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 durante las etapas de entrega
• Equipos de desarrollo más felices

Los equipos a menudo luchan por obtener estos beneficios. Los retos para sacar el máximo provecho de sus entornos de desarrollo y estrategia pueden proceder de varias fuentes. 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 necesitaba cumplir varias funciones. Además de estar donde su equipo realiza sus diversos tipos de trabajo, necesitaba 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 eliminar, a menudo estaban abarrotados y llenos de conflictos de metadatos entre equipos, y no contribuyen de forma significativa a la velocidad o flexibilidad de 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 el 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 compatibles con 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 de Einstein, artículos Knowledge y datos no estructurados, las pruebas integrales están limitadas a menos que tenga un entorno 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 desarrollo basado en organización. Trate los entornos como lugares donde se produce trabajo durante un tiempo fijo. Considere el estado de los metadatos en un entorno como separado de sus artefactos de versión. Si un código o 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 que los cambios se implementen 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 propósito 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 los metadatos que tenga lugar en un entorno específico (y que desee conservar) con el control de origen.
  • Los entornos son tan útiles como su fidelidad a la producción. Optimice los flujos de trabajo o la automatización de la configuración de su entorno de modo que pueda eliminar 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 reparació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 otros trabajos. 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 comerciales o usuarios finales pueden acceder, permita que esos usuarios se centren en lo que les importa. No tenga entornos genéricos no diferenciados donde muchos grupos diferentes de usuarios finales o partes interesadas comerciales 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 comerciales 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 cerca 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 del usuario 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 alto riesgo, 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 los modelos de datos, la automatización que realiza operaciones de datos o la 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, el hacinamiento en los entornos de desarrollo constituye una grave amenaza 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 enfrenta hacinamiento, 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 crear o para identificar áreas de su sistema que necesitan ser refactorizadas.

Para obtener más información acerca de las 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 las 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 a los problemas solo después de que los usuarios los informen, 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 producen cascadas de agotamiento de memoria o tiempo de espera. Las aplicaciones correctamente instrumentadas supervisan 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 correctamente equipadas dejan de aceptar nuevo trabajo, permiten que se completen las solicitudes en vuelo, lavan los buffers, cierran las conexiones de forma limpia y cancelan el registro de descubrimiento de servicio. 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 crean capas de múltiples puntos de observación.

  • Las mediciones comerciales 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 supervisan la utilización de recursos, las distribuciones de latencia y los índices de error.
  • Las sondas sintéticas realizan continuamente trayectorias 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 tanto a los sistemas automatizados como a los 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 que los disyuntores se desencadenen basándose en índices de error, que los escaladores automáticos respondan a profundidades de cola y que los operadores tomen 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 crear o para identificar áreas de su sistema que necesitan ser refactorizadas.

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 fracaso 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 alcance 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 prueba efectiva crea una imagen clara de cómo, cuándo, dónde y por qué ejecutar diferentes tipos de prueba (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 facilidad 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 por medios automatizados tanto como sea posible. Diseñe e implemente la automatización de pruebas que permite a los equipos ejecutar una variedad de tipos de prueba en una variedad de cargas de trabajo. Orqueste varias ejecuciones de prueba para que se produzcan automáticamente cuando los cambios entren en el 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 forma de 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 específico 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, rendimiento y escala para medir continuamente la madurez de la aplicación. Estas pruebas muestran cuán lista está la versión de una aplicación, en relación con las necesidades a nivel de producción. Para funciones nuevas importantes, 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 rendimiento 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 añadida 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 rendimiento, haciendo que no sea práctico probar cada faceta 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 se centran 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 rendimiento en su organización.
  • Sepa cómo es “suficientemente bueno”. Definir los criterios de éxito para sus pruebas de escala y rendimiento es fundamental. 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 admitir un número específico de usuarios simultáneos con tiempos de respuesta inferiores a un valor acordado y sus objetivos de servicio. Defina sus criterios de objetivo clave y luego diseñe pruebas de escala y rendimiento que garanticen que se cumplen los criterios.
  • Asegúrese de tener entornos adecuados. Las pruebas de escala y rendimiento 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 que no son 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 considerar:
  • Datos de prueba: Todo tipo de prueba debe producirse con datos aislados de producción. En pruebas de unidad Apex, implemente patrones de fábrica de datos 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 creados bajo demanda por código de fábrica de datos, deben depurarse con datos confidenciales e identificativos. Debe incluir datos dañados, incompletos y defectuosos para admitir comportamientos negativos y de prueba de unidad de límite.
  • Servicios simulados: Para pruebas de integración, puede utilizar servicios simulados para simular respuestas de API. Apex admite una API Stub para crear marcos de trabajo de simulación para su uso en pruebas Apex. Burlar para crear marcos de trabajo de burla que se pueden utilizar en pruebas Apex. Los simulacros y adaptadores pueden ayudar a validar comportamientos de gestión de datos de un sistema, con menos dependencia de fábricas de datos complejas o conjuntos de datos de prueba externos. Los simulacros y los adaptadores 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 interesantes y accesibles es garantizar que cumplen las expectativas de los usuarios en 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 arquitectadas 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 rendimiento.
  • AI y pruebas de 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 o dirigir para su solució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 a 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 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 supervise las operaciones de su solución en el día a día una vez que se ponga en marcha. 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 comprendan a fondo la arquitectura del sistema ni tengan experiencia en ella. Es esencial que estos equipos tengan las herramientas y los procesos que necesitan para supervisar las operaciones diarias, acceder a la información desde el sistema al diagnosticar un posible incidente y servir como primeros en responder de forma efectiva para cualquier problema que afecte a la disponibilidad.

Puede mejorar la respuesta de los equipos a incidentes en sus soluciones de Salesforce centrándose en su tiempo de recuperación, capacidad de triaje y supervisión 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 preciso de la causa raíz 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 impacto podría llevar a una pérdida de ingresos o reputación para el negocio.

A menudo, intentar diagnosticar y tratar la raíz causa retrasos en los esfuerzos para restaurar el funcionamiento de un sistema. Logísticamente, la adopción de un enfoque que solicite a los respondedores de incidentes que aborden las causas raíz ejerce una enorme presión sobre los expertos en la materia (PYME) y el personal de asistencia de su empresa. Trabajar para encontrar y solucionar las causas fundamentales durante un incidente requiere que las PYME estén a la espera de cada incidente, lo que puede impedir que el personal de asistencia de primera línea y de cara al cliente tome medidas. 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 costes, consume ancho de banda entre equipos y conduce a comportamientos en tiempos de crisis que pueden erosionar la Customer Trust 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 sin culpa, investigaciones de incidentes, remediación de causas raíz y actividades similares. Este orden de operaciones permite mejor al personal de respuesta a incidentes clasificar, diagnosticar y ejecutar tácticas de recuperación, alertando a las PYME relevantes para que presten asistencia 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 de tic tac.

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

• Establecer y alcanzar 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 rendimiento 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 de incidentes, ya que parece que ayudará a detener los comportamientos reactivos. Establecer SLO y 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 pico 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 informes 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 informes en n segundos de media, medida durante un periodo de 30 días”.
• Defina y estandarice tácticas de recuperación. Las implementaciones de soluciones y reversiones de cambios 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 basándose en el 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 culpa o culpa 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 raíz 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 de incidentes y la recuperación. Practique también sus revisiones posteriores a incidentes. Hacer toda esa práctica hace que la recuperación sea parte de su cultura de ingeniería y asistencia.

Los patrones y antipatrones para respuestas ante incidentes muestran el aspecto de la arquitectura para dar prioridad a la recuperación en una solución de Salesforce. Utilícelos para validar sus diseños antes de crear o para identificar áreas de su sistema que necesitan ser refactorizadas.

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, el triaje implica la asignación de categorías y niveles de gravedad a problemas y solicitudes de asistencia. Independientemente de lo bien planificada que esté su solución, surgirán problemas y solicitudes de asistencia al usuario. Estos problemas pueden deberse a una falta de formació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 la supervisión 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. Un mal triaje ralentiza todos los niveles de asistencia al usuario, prolonga incidentes críticos y aumenta el riesgo de nuevas interrupciones para sus clientes y su negocio.

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

Para permitir a los equipos clasificar de forma efectiva problemas 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. Asegúrese también de que los equipos puedan 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 los equipos a detectar rápidamente problemas relacionados con permisos o configuración.
  • Diseño pensando en depurar. Los equipos de asistencia y administradores de la organización tendrán que activar la depuración y el diagnóstico para detectar 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 comunes de depuración Agentforce con herramientas como registros de eventos y la vista de razonamiento de Agent Builder.
  • Identificar PYMES y partes interesadas incidentes. Cree una lista de pymes o partes interesadas relevantes que deben estar disponibles para dar cobertura a 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 formación al personal de asistencia para que camine por la arquitectura del sistema relevante y simulacros de respuesta a incidentes. Piense en las 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 solució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, notificación de supervisión y alerta que reciba.
  • Ayude a distinguir los síntomas de los problemas. Trabaje para determinar si hay un incidente real del sistema 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 los agentes Agentforce que admiten casos de uso críticos, asegúrese de que existen soluciones viables y relevantes que se pueden activar con poca antelación como 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 un triaje efectivo en una solución de Salesforce. Utilícelos para validar sus diseños antes de crear o para identificar áreas de su sistema que necesitan ser refactorizadas.

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

Supervisión y alerta son términos ampliamente utilizados en ingeniería de fiabilidad de sitio. En el contexto de la resiliencia del sistema, la supervisión 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. La supervisión y alerta efectivas es 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 supervisar comportamientos en su sistema. Salesforce también ofrece supervisión 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 la supervisión y alerta proporcionan:

• Funciones para la respuesta automatizada ante incidentes
• 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 una supervisión y alerta efectivas 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 creación de informes sean más útiles.
  • Comience con lo que Salesforce ya proporciona. Salesforce Platform proporciona registros y API relevantes para que supervise las operaciones de su solución con respecto a los límites reguladores. Además, la plataforma envía alertas para infracciones de límite regulador y problemas similares. Utilice estos registros y alertas como base para explorar formas de automatizar más completamente la recuperación automática del sistema, los informes de incidentes y las alertas. Por ejemplo, puede implementar una automatización que supervise el registro y luego realice una acción de recuperación cuando se registre un tipo de evento concreto.
  • Clasifique los cambios al estado del sistema de formas predecibles. Cree categorías específicas y significativas para estados clave sobre los que desea supervisar e informar. Alinee estas categorías con las categorías que defina 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 cambio de estado. Los formatos de mensajes y categorías de estado coherentes simplifican la automatización, la creación de informes y las alertas.
  • Alinee su lógica de automatización con las otras partes de su sistema. Si creó una gestión de errores de automatización adecuada, puede ampliar esos patrones a cómo clasificar 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 delimitar 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 basados en privilegios de usuario. Solo envíe alertas a destinatarios que tengan la capacidad y la autoridad para responder. Los usuarios comerciales 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 apoyo.
  • Deje clara la respuesta esperada. Solo envíe alertas en escenarios que requieren intervención humana. Estructurar 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 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 comerciales.

La lista de patrones y antipatrones muestra el aspecto de la arquitectura para una supervisión y alerta efectivas en una solución de Salesforce. Utilícelos para validar sus diseños antes de crear o para identificar áreas de su sistema que necesitan ser refactorizadas.

Para obtener más información acerca de las herramientas de Salesforce para la supervisión y 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 solución.

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

Una clave para la resiliencia comercial 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 comercial (BCP) adoptan una visión orientada a las personas de cómo mantener los procesos avanzando en 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 tecnológica.

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 se arriesga a daños financieros, daños a la reputación, seguridad de los empleados e incluso cumplimiento normativo.

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

Es posible que su empresa ya tenga un BCP en vigor. Si lo hace, asegúrese de que Salesforce está incluido en él. Si su empresa 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 ser una fuente de verdad para datos de clientes y procesos comerciales esenciales en muchas divisiones comerciales. 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 comercial relevante para sistemas de Salesforce:

• Aclare las prioridades de 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 para el negocio se ejecutan en Salesforce y con Salesforce. Debe ayudar a las partes interesadas a identificar la prioridad correcta para recuperar varias funciones y funciones comerciales. Un marco general podría ser:
  • Estabilice la infraestructura comercial 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 los 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 a 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 crear o para identificar lugares en su sistema que necesitan ser refactorizados.

Para obtener más información acerca de las herramientas de Salesforce para definir la continuidad comercial, 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 da prioridad a mantener nuestros servicios en los niveles más altos de disponibilidad y proporcionar información transparente sobre cualquier problema. Puede ver información en tiempo real sobre el rendimiento 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 rendimiento 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 empresarial más grande. ¿Qué tipos de sistemas se integran con Salesforce? ¿Cómo dependen los sistemas externos de los procesos o la 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 tecnológica en sus sistemas de Salesforce:

• Evalúe su infraestructura. La estrategia de solución más común para fallos o cortes de 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 de 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 en marcha equipos lo más rápido posible. Piense en cómo su sistema puede gestionar aumentos significativos en requisitos de capacidad y demanda de cambios no anticipados, 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 procedimientos de ruptura que Ingeniería de fiabilidad de sitio (SRE) o equipos de asistencia pueden necesitar para responder a incidentes de forma efectiva. Las preguntas que se pueden formular acerca del soporte operativo incluyen:
  • En caso de fallo, ¿tendrían nuestros equipos técnicos las herramientas que necesitan para continuar trabajando? ¿Hemos simulado un fallo de funcionamiento 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 un seguimiento 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 empresas programan simulaciones de incidentes para un subconjunto de servicios para probar la resiliencia del sistema. Un ejemplo podría ser simular una cuenta de administrador del sistema bloqueada o comprometida, o simular un fallo o problema con un proveedor AppExchange. Consulte Respuesta a incidentes.)Las preguntas que se deben 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 crear o para identificar lugares en su sistema que necesitan ser refactorizados.

Para obtener más información acerca de las 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 están dañados maliciosamente, cuando los defectos se abren paso inadvertidamente en producción o cuando un fallo durante una gran carga de datos daña los datos de producción. Cualquiera de estos escenarios puede dar como resultado que sus datos de producción críticos para el 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 salvar su negocio de perder información o funciones críticas durante un desastre.
• Restringir 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 comercial 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 completa o parcial 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 ocurrir 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 fundamentales para su organización.

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

• Ámbito de sus copias de seguridad en 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 largos tiempos de ejecución. 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 para 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 crear o para identificar lugares en su sistema que necesitan ser refactorizados.

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 comercial 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 que sea 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, permitiendo 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 correo electrónico. 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 con mayor rapidez 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 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 necesidad de API de Salesforce adicionales.

Copia de seguridad y recuperación ofrece una única consola para consolidar todas las copias de seguridad, gestión, operaciones y cumplimiento. Esta consola le permite acceder, gestionar, personalizar y supervisar 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 control completo para personalizar las políticas de programación, frecuencia y retención de copias de seguridad.

• 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. El error humano sigue siendo la principal causa de pérdida de datos. Backup and& Recover ofrece una solución precisa y rápida a estos errores.
• Cumplir más fácilmente los requisitos legales y de cumplimiento de datos. Copia de seguridad y recuperación de Salesforce admite el modelo de responsabilidad compartida, activando la función de autoservicio para los olvidos masivos 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 para copias 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 solució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 y díganos qué le gustaría ver a continuación.