Recomendaciones para diseñar una estrategia de mitigación de errores de implementación
Se aplica a esta recomendación de lista de comprobación de excelencia operativa de buena arquitectura de Power Platform:
| OE:11 | Implemente una estrategia de mitigación de errores de implementación que aborde los problemas inesperados a mitad del despliegue con una rápida recuperación. Combine varios enfoques, como revertir, deshabilitar características o usar las capacidades nativas de su patrón de implementación. |
|---|
Esta guía describe las recomendaciones para diseñar una estrategia estandarizada para gestionar eficazmente los errores de implementación. Al igual que otros problemas de carga de trabajo, los errores de implementación son una parte inevitable del ciclo de vida de una carga de trabajo. Con esta mentalidad, puede ser proactivo con una estrategia intencional y bien diseñada para abordar errores de implementación. Esta estrategia permite a su equipo de carga de trabajo mitigar eficazmente los errores con el menor impacto posible en los usuarios.
La ausencia de un plan de este tipo puede generar respuestas caóticas y potencialmente perjudiciales a los problemas, lo que puede afectar significativamente a la cohesión de la organización y del equipo, la confianza del cliente y las finanzas.
Estrategias clave de diseño
En ocasiones, a pesar de la madurez de sus prácticas de desarrollo, ocurren problemas de implementación. Utilizar prácticas de implementación seguras y operar una cadena de suministro de carga de trabajo sólida puede ayudarlo a minimizar la frecuencia de las implementaciones fallidas. También debe diseñar una estrategia estandarizada para controlar las implementaciones fallidas cuando se produzcan.
Una estrategia de mitigación de errores de implementación se compone de cinco fases amplias:
- Detección: para responder a una implementación fallida, primero debe detectar el error. La detección puede adoptar varias formas, como pruebas de humo fallidas, informes de usuarios o alertas que genera su plataforma de monitoreo.
- Decisión: debe decidir cuál es la mejor estrategia de mitigación para el tipo de error específico.
- Mitigación: debe realizar la acción de mitigación identificada. La mitigación puede tomar la forma de retroceso, reversión o avance.
- Comunicación: Las partes interesadas y los usuarios afectados deben conocer el estado a medida que detecta y trabaja en el problema, según lo requiere su plan de respuesta a emergencias.
- Análisis postmortem: los análisis postmortem sin culpabilidad brindan al equipo encargado de la carga de trabajo la oportunidad de identificar áreas de mejora y crear planes para aplicar lo aprendido.
En las siguientes secciones se proporcionan recomendaciones detalladas para estas fases.
duplicados
Para identificar rápidamente los problemas con las implementaciones, necesita prácticas sólidas de prueba y supervisión que se relacionen con las implementaciones. Para ayudar a detectar anomalías rápidamente, puede complementar la supervisión y las alertas de su carga de trabajo mediante el uso de una herramienta de administración del rendimiento de las aplicaciones y el registro a través de la instrumentación.
Se deben realizar pruebas de humo y otras pruebas de calidad en cada fase de su implementación. Las pruebas correctas en un grupo de implementación no deberían influir en las decisiones de realizar pruebas en grupos posteriores.
Puede implementar telemetría que correlacione los problemas de los usuarios con una fase de implementación. Luego podrá identificar rápidamente a qué grupo de implementación está asociado un usuario en particular. Este enfoque es especialmente importante para implementaciones de exposición progresiva, porque es posible que tenga varias configuraciones ejecutándose en su base de usuarios en cualquier punto dado de la implementación.
Deberá estar preparado para responder inmediatamente a los problemas notificados por los usuarios. Siempre que sea práctico, implemente su fase de implementación en horario laboral, cuando tenga un equipo de soporte completo disponible. Asegúrese de que el personal de soporte esté capacitado sobre cómo escalar los problemas de implementación para un enrutamiento adecuado. Las remisiones a una instancia superior deben alinearse con su plan de respuesta a emergencias de cargas de trabajo.
Decisión
Decidir sobre una estrategia de mitigación adecuada para un problema de implementación implica considerar factores como:
El tipo de modelo de exposición progresiva que utiliza. Por ejemplo, podría utilizar un modelo azul-verde o un modelo de valor controlado. Si utiliza un modelo azul-verde, el retroceso es más práctico que la reversión. Puede desviar fácilmente el tráfico a la pila que ejecuta la configuración que no está actualizada. A continuación puede solucionar el error en el entorno problemático e intentar la implementación nuevamente en el momento adecuado.
Los métodos que tiene a su disposición para solucionar el problema. Los ejemplos incluyen el uso de marcas de característica, variables de entorno o cualquier otro tipo de propiedad de configuración de tiempo de ejecución que pueda activar y desactivar. A veces puede evitar fácilmente un problema desactivando una marca de característica o cambiando un ajuste. En este caso, podría:
- Continuar con el despliegue.
- Evitar el retroceso.
- Realice reversión mientras corrige el código infractor.
El nivel de esfuerzo necesario para implementar una corrección en el código. Si el nivel de esfuerzo para corregir el código es bajo, la puesta al día mediante la implementación de un parche rápido es la opción correcta para determinados escenarios.
El nivel de gravedad de la carga de trabajo afectada. Las cargas de trabajo críticas para el negocio siempre deben implementarse en paralelo, como en un modelo azul-verde, para lograr implementaciones sin tiempo de inactividad. Por ello, el retroceso es la estrategia de mitigación preferible para este tipo de cargas de trabajo.
Mitigación
Estas son algunas de las estrategias de mitigación comunes:
Reversión: en un escenario de reversión, se devuelven los sistemas actualizados al último estado de configuración válido conocido.
Es importante que todo el equipo de trabajo esté de acuerdo sobre el significado de «última válido conocido». Esta expresión hace referencia al último estado de la carga de trabajo que estaba en buen estado antes de que comenzara la implementación, que no es necesariamente la versión anterior de la aplicación.
La reversión puede ser compleja, especialmente en lo que se refiere a cambios de datos. Los cambios de esquema pueden hacer que la reversión sea arriesgada. Implementarlos de manera segura puede requerir una planificación considerable. Como recomendación general, las actualizaciones de esquemas deben ser aditivas. Los registros no deben reemplazarse por registros nuevos. Por el contrario, los registros más antiguos deben quedar en desuso y coexistir con registros nuevos hasta que sea seguro eliminar los obsoletos.
Alternativa: en un escenario de alternativa, los sistemas actualizados se eliminan del enrutamiento del tráfico de producción. Todo el tráfico se dirige a la pila que no está actualizada. Esta estrategia de bajo riesgo le proporciona una manera de abordar los problemas de su código sin introducir más interrupciones.
Con las implementaciones de valor controlado, el retroceso puede no ser sencillo o incluso posible, según la infraestructura y el diseño de la aplicación. Si necesita realizar escalado para gestionar la carga en sistemas que no están actualizados, reálicelo antes de retroceder.
Omitir la función problemática: si puede omitir el problema mediante marcas de características u otro tipo de propiedad de configuración en tiempo de ejecución, puede decidir que continuar con la implementación es la estrategia adecuada para un problema.
Debe comprender claramente la desventaja que supone evitar la función y debería poder comunicar ese compromiso a las partes interesadas. Las partes interesadas deben aprobar el plan de avance. Las partes interesadas deben determinar el período de tiempo tolerable para operar en un estado degradado. También deben sopesar esa determinación con su estimación del tiempo necesario para corregir el código infractor e implementarlo.
Implementación de emergencia (revisión): si puede abordar el problema a mitad de la implementación, una revisión podría ser la estrategia de mitigación más práctica.
Al igual que cualquier otro código, las revisiones deben pasar por sus prácticas de implementación seguras. Pero con una revisión, la línea de tiempo se acelera considerablemente. Debe utilizar una estrategia de promoción de código en todos sus entornos. También debe verificar el código de revisión en todas las puertas de calidad. Pero es posible que deba acortar drásticamente los tiempos de integración y modificar las pruebas para acelerarlas. Asegúrese de que puede ejecutar pruebas completas en el código actualizado lo antes posible después de la implementación. Automatizar en alto grado las pruebas de control de calidad ayuda a que las pruebas sean eficientes en estos escenarios.
Comunicación
Es importante definir claramente las responsabilidades de comunicación para ayudar a minimizar el caos durante los incidentes. Estas responsabilidades deben establecer cómo el equipo de la carga de trabajo interactúa con los equipos de soporte, las partes interesadas y el personal del equipo de respuesta a emergencias, como el administrador de respuesta a emergencias.
Estandarice la cadencia que sigue el equipo de la carga de trabajo para proporcionar actualizaciones de estado. Asegúrese de que las partes interesadas conozcan este estándar para que sepan cuándo esperar actualizaciones.
Si el equipo de la carga de trabajo necesita comunicarse directamente con los usuarios, aclare el tipo de información y el nivel de detalle que son apropiados para compartir. Comunique también al equipo de carga de trabajo cualquier otro requisito que aplique a estos casos.
Autopsia
Se deben realizar evaluaciones postmortem a todos las implementaciones fallidas, sin excepción. Cada implementación fallida es una oportunidad para aprender. Los análisis retrospectivos pueden ayudarlo a identificar debilidades en sus procesos de implementación y desarrollo, así como configuraciones incorrectas en su infraestructura.
Las autopsias siempre deben ser sin culpa para que las personas involucradas en el incidente se sientan seguras cuando compartan sus perspectivas sobre lo que se puede mejorar. Los responsables de los análisis deben hacer un seguimiento de los planes de aplicación de las mejoras identificadas y agregarlos a la carga de trabajo pendiente.
Consideraciones y recomendaciones generales
Asegúrese de que su canalización de implementación pueda aceptar distintas versiones como parámetros para poder implementar fácilmente las últimas configuraciones válidas conocidas.
Mantenga la coherencia con los planos de administración y de datos a medida que retrocede o avanza. Las claves, los secretos, los datos del estado de la base de datos y las configuraciones específicas de los recursos y las directivas deben estar dentro del ámbito y tenerse en cuenta. Por ejemplo, preste atención al diseño del escalado de su infraestructura en su última implementación válida conocida. Determine si necesita ajustar esa configuración cuando vuelva a implementar su código.
Prefiera los cambios pequeños y frecuentes en lugar de los cambios grandes e infrecuentes para que la diferencia entre las implementaciones nuevas y las últimas que se conocen sea pequeña.
Realice un análisis del modo de error (FMA) en sus procedimientos de integración continua y entrega continua (CI/CD) para ayudar a identificar problemas que pueden complicar los esfuerzos de mitigación. Al igual que con la carga de trabajo en su conjunto, los procesos se pueden analizar para identificar áreas que podrían ser problemáticas al intentar un tipo de mitigación determinado.
Utilice la función de reversión automática con prudencia:
- Algunas herramientas de CI/CD como Azure DevOps tienen incorporada una función de reversión automática. Considere utilizar esta funcionalidad si le proporciona un valor tangible.
- Debe adoptar la funcionalidad de reversión automática solo después de probar su canalización de manera exhaustiva y regular. Asegúrese de que su canalización sea lo suficientemente madura como para introducir problemas adicionales si se desencadena una reversión automática.
- Debe confiar en que la automatización implementa solo los cambios necesarios y que se desencadena solo cuando es necesario. Diseñe sus desencadenadores cuidadosamente para cumplir estos requisitos.
Utilice las capacidades proporcionadas por la plataforma durante las reversiones. Por ejemplo, las copias de seguridad y la restauración a un momento dado pueden ayudar con las reversiones de datos y almacenamiento. O bien, si usa máquinas virtuales para hospedar la aplicación, puede ser útil restaurar el entorno en un punto de control inmediatamente antes de un incidente.
Pruebe con frecuencia toda su estrategia de mitigación de errores de implementación. Al igual que los planes de respuesta a emergencias y los planes de recuperación ante desastres, su plan de errores de implementación solo tiene éxito si su equipo está capacitado y lo practica con regularidad. La ingeniería del caos y las pruebas de inyección de errores pueden ser técnicas efectivas para probar su estrategia de mitigación de implementación.
Facilitación de Power Platform
Las canalizaciones de Power Platform tienen el objetivo de democratizar la administración del ciclo de vida de la aplicación (ALM) para clientes de Power Platform y Dynamics 365 incorporando en el servicio capacidades de automatización de ALM y de integración continua y entrega continua (CI/CD).
Las Microsoft Power Platform Build Tools para Azure DevOps pueden utilizarse para automatizar tareas comunes de compilación y de implementación relacionadas con aplicaciones creadas en Power Platform.
Las Acciones de GitHub para Power Platform permiten a los desarrolladores crear flujos de trabajo de ciclo de vida de desarrollo de software automatizados. Con las Acciones de GitHub para Microsoft Power Platform, puede crear flujos de trabajo en su repositorio para crear, probar, empaquetar, lanzar e implementar aplicaciones, automatizar tareas y administrar bots y otros componentes integrados en Microsoft Power Platform.
ALM Accelerator es una herramienta de código abierto que consta de un conjunto de aplicaciones, scripts y canalizaciones diseñados para automatizar el proceso de integración continua/entrega continua.
Automatización de pruebas con Azure Pipelines
Utilice el kit Power CAT Copilot Studio para configurar agentes y pruebas. Ejecute pruebas individuales en las API de Copilot Studio (Direct Line) y evalúe las respuestas del agente frente a los resultados esperados.
Las variables de entorno de las soluciones almacenan las claves y los valores de los parámetros, que luego sirven como entrada para otros objetos de la aplicación. Separar los parámetros de los objetos consumidores le permite cambiar los valores dentro del mismo entorno o cuando migra soluciones a otros entornos.
Los entornos de Power Platform proporcionan una funcionalidad de restauración a un momento dado que puede ayudarle a revertir.
Power Platform se integra con Application Insights, que es parte del ecosistema de Azure Monitor. Use esta integración para:
Recibir telemetría sobre los diagnósticos y el rendimiento capturados por la plataforma Dataverse en Application Insights. Puede suscribirse para recibir telemetría sobre las operaciones que realizan las aplicaciones en su base de datos de Dataverse y dentro de las aplicaciones basadas en modelo. Esta telemetría proporciona información que puede utilizar para diagnosticar y solucionar problemas relacionados con errores y rendimiento.
Conecte sus aplicaciones de lienzo a Application Insights. Puede utilizar estos análisis para diagnosticar problemas y comprender qué hacen los usuarios con sus aplicaciones. Puede recopilar información para ayudarlo a tomar mejores decisiones comerciales y mejorar la calidad de sus aplicaciones.
Configure la telemetría de Power Automate para que fluya hacia Application Insights; por ejemplo, para supervisar las ejecuciones de flujos de nube y crear alertas de errores de ejecución de flujos de nube.
Capture datos de telemetría de su agente Microsoft Copilot Studio para usarlos en Azure Application Insights. Puede usar esta telemetría para supervisar los mensajes registrados y los eventos enviados desde y hacia el agente, los temas que se desencadenarán durante las conversaciones de los usuarios y los eventos de telemetría personalizados que se pueden enviar desde los temas.
Lista de comprobación de la excelencia operativa
Consulte el conjunto completo de recomendaciones.