Compartir vía

Recomendaciones para diseñar una estrategia de mitigación de errores de implementación

  • Artículo

Se aplica a esta recomendación de lista de comprobación de excelencia operativa del marco de trabajo bien diseñado de Azure:

OE:12 Implemente una estrategia de mitigación de errores de implementación que solucione problemas inesperados de implementación media con recuperación rápida. Combine varios enfoques, como la reversión, la deshabilitación de características o el uso de las funcionalidades nativas del patrón de implementación.

En esta guía se describen las recomendaciones para diseñar una estrategia estandarizada para controlar eficazmente los errores de implementación. Al igual que otros problemas de carga de trabajo, los errores de implementación son una parte inevitable de un ciclo de vida de la carga de trabajo. Con esta mentalidad, puede ser proactivo teniendo una estrategia intencionada bien diseñada para tratar los errores de implementación. Esta estrategia permite que el equipo de cargas de trabajo mitigue eficazmente los errores con el menor impacto posible en los usuarios finales.

La ausencia de este plan puede dar lugar a respuestas caóticas y potencialmente perjudiciales a los problemas, lo que puede afectar significativamente a la cohesión del equipo y la organización, la confianza del cliente y las finanzas.

Estrategias de diseño principales

En ocasiones, a pesar de la madurez de las prácticas de desarrollo, se producen problemas de implementación. El uso de prácticas de implementación seguras y el funcionamiento de una sólida cadena de suministro de cargas de trabajo puede ayudarle a minimizar la frecuencia de las implementaciones con errores. Pero también debe diseñar una estrategia estandarizada para controlar las implementaciones con errores cuando se producen.

Cuando se usa un modelo de implementación de exposición progresiva como práctica estándar:

  • Tiene la base adecuada para minimizar los efectos en los clientes o usuarios internos cuando se produce un error en las implementaciones.
  • Puede mitigar los problemas de forma eficaz.

Una estrategia de mitigación de errores de implementación se compone de cinco fases generales:

  1. Detección: para responder a una implementación con errores, primero debe detectar el error. La detección puede tener varias formas, como las pruebas de humo con errores, los problemas notificados por el usuario o las alertas que genera la plataforma de supervisión.

  2. Decisión: debe decidir cuál es la mejor estrategia de mitigación para el tipo de error específico.

  3. Mitigación: realiza la acción de mitigación identificada. La mitigación puede adoptar la forma de una reserva, reversión, puesta al día o el uso de una configuración en tiempo de ejecución para omitir la función infractora.

  4. Comunicación: las partes interesadas y los usuarios finales afectados deben tener en cuenta el estado a medida que detecte y trabaje a través del problema según lo requiera el plan de respuesta de emergencia.

  5. Postmortem: las postmortems sin culpa proporcionan oportunidades para que el equipo de carga de trabajo identifique áreas para mejorar y cree planes para aplicar aprendizajes.

En las secciones siguientes se proporcionan recomendaciones detalladas para estas fases. En estas secciones se supone que detecta un problema después de implementar los cambios en uno o varios grupos de usuarios o sistemas, pero antes de actualizar todos los grupos del plan de implementación.

Diseñar mecanismos de detección de errores

Para identificar rápidamente problemas con las implementaciones, necesita prácticas sólidas de pruebas y observabilidad en relación con las implementaciones. Para ayudar a detectar anomalías rápidamente, puede complementar la supervisión y las alertas de la carga de trabajo siguiendo estos pasos:

  • Use una herramienta de administración del rendimiento de la aplicación.
  • Habilite el registro a través de la instrumentación.

Las pruebas de humo y otras pruebas de calidad deben realizarse en cada fase del lanzamiento. Las pruebas correctas de un grupo de implementación no deben influir en las decisiones para probarlas en grupos posteriores.

Puede implementar la telemetría que correlaciona los problemas del usuario con una fase de implementación. A continuación, puede identificar rápidamente con qué grupo de lanzamiento está asociado un usuario determinado. Este enfoque es especialmente importante para las implementaciones de exposición progresiva, ya que es posible que tenga varias configuraciones que se ejecutan en la base de usuarios en cualquier momento dado de la implementación.

Debe estar listo para responder a los problemas notificados por el usuario inmediatamente. Siempre que sea práctico, implemente la fase de implementación durante el horario laboral, cuando tenga disponible un equipo de soporte técnico completo. Asegúrese de que el personal de soporte técnico está entrenado sobre cómo escalar los problemas de implementación para el enrutamiento adecuado. Las escalaciones deben alinearse con el plan de respuesta de emergencia de carga de trabajo.

Decidir la estrategia de mitigación

Decidir una estrategia de mitigación adecuada para un problema de implementación determinado implica tener en cuenta muchos factores, entre los que se incluyen:

  • Tipo de modelo de exposición progresiva que se usa. Por ejemplo, puede usar un modelo azul-verde o un modelo controlado.

    Si usa un modelo azul-verde, revertir es más práctico que revertir. Puede cambiar fácilmente el tráfico a la pila que ejecuta la configuración que no se actualiza. A continuación, puede corregir el problema en el entorno problemático e intentar la implementación de nuevo en un momento adecuado.

  • Los métodos que tiene a su disposición para omitir el problema. Algunos ejemplos incluyen el uso de marcas de características, variables de entorno o cualquier otro tipo de propiedad de configuración en tiempo de ejecución que pueda activar y desactivar.

    A veces, puede omitir fácilmente un problema desactivando una marca de característica o alternando una configuración. En este caso, es posible que pueda:

    • Continúe con el lanzamiento.
    • Evite retroceder.
    • Revierte mientras corrige el código infractor.

  • 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 implementación de una corrección activa es la opción adecuada para determinados escenarios.

  • Nivel de importancia para la carga de trabajo afectada.

    Las cargas de trabajo críticas para la empresa siempre deben implementarse en paralelo, como en un modelo azul-verde, para lograr implementaciones sin tiempo de inactividad. Como resultado, revertir es la estrategia de mitigación preferible para estos tipos de cargas de trabajo.

  • Tipo de infraestructura que usa la carga de trabajo: mutable o inmutable.

    Si la carga de trabajo está diseñada para usar una infraestructura mutable, la puesta al día puede tener sentido, ya que implica actualizar la infraestructura en su lugar. Por el contrario, revertir o revertir puede tener sentido cuando se usa una infraestructura inmutable.

Independientemente de las opciones que tome, debe incluir las aprobaciones adecuadas en el proceso de toma de decisiones y codificarlas en el árbol de decisiones.

Implementación de la estrategia de mitigación

  • Reversión: en un escenario de reversión, revierte los sistemas actualizados al último estado de configuración correcto conocido.

    Es importante que todo el equipo de cargas de trabajo acepte el significado del último bien conocido. Esta expresión hace referencia al último estado de la carga de trabajo que estaba en buen estado antes de comenzar la implementación, que no es necesariamente la versión anterior de la aplicación.

    La revierte puede ser compleja, especialmente cuando se relaciona con los cambios de datos. Los cambios de esquema pueden hacer que se revierte el riesgo. Implementarlos de forma segura puede requerir un planeamiento considerable. Como recomendación general, las actualizaciones de esquema deben ser sumables. No deben ser cambios de reemplazo: los registros no deben reemplazarse por registros nuevos. En su lugar, los registros más antiguos deben estar en desuso y deben coexistir con nuevos registros hasta que sea seguro quitar los registros en desuso.

  • Reserva: en un escenario de reserva, los sistemas actualizados se quitan del enrutamiento del tráfico de producción. Todo el tráfico se dirige a la pila que no se actualiza. Esta estrategia de bajo riesgo proporciona una manera de solucionar los problemas del código sin introducir más interrupciones.

    Con las implementaciones controladas, es posible que la recuperación no sea sencilla o incluso posible, en función de la infraestructura y el diseño de la aplicación. Si necesita realizar el escalado para controlar la carga en los sistemas que no se actualizan, realice ese escalado antes de revertir.

  • Omitir la función ofendida: 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 el lanzamiento es la estrategia adecuada para un problema determinado.

    Debe comprender claramente el inconveniente de omitir la función y debe poder comunicar esa compensación 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 funcionar en un estado degradado. También deben ponderar esa determinación con respecto a su estimación del tiempo necesario para corregir el código infractor e implementarlo.

  • Implementación de emergencia (corrección activa): si puede solucionar el problema a mitad del lanzamiento, una corrección frecuente podría ser la estrategia de mitigación más práctica.

    Al igual que cualquier otro código, las correcciones frecuentes deben pasar por los procedimientos de implementación seguros. Pero con una corrección activa, la escala de tiempo se acelera considerablemente. Debe usar una estrategia de promoción de código en todos los entornos. También debe comprobar el código de corrección activa en todas las puertas de calidad. Pero es posible que tenga que acortar drásticamente los tiempos de elaboración y es posible que tenga que 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. La automatización de las pruebas de control de calidad en un alto grado ayuda a hacer que las pruebas sean eficaces en estos escenarios.

Desventajas:

  • La posibilidad de revertir normalmente significa que necesita suficiente capacidad de infraestructura para controlar dos versiones de la configuración de la carga de trabajo al mismo tiempo. Los equipos de carga de trabajo también deben poder admitir dos versiones en producción al mismo tiempo.
  • La posibilidad de revertir eficazmente podría implicar refactorización de elementos de la carga de trabajo. Por ejemplo, puede que tenga que desacoplar funciones o cambiar el modelo de datos.

Estandarizar las actualizaciones de estado durante un incidente

Es importante tener responsabilidades de comunicación claramente definidas para ayudar a minimizar el caos durante los incidentes. Estas responsabilidades deben establecer cómo interactúa el equipo de carga de trabajo con los equipos de soporte técnico, las partes interesadas y el personal del equipo de respuesta de emergencia, como el administrador de respuesta de emergencia.

Normalice la cadencia que sigue el equipo de 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 cargas de trabajo necesita comunicarse directamente con los usuarios finales, aclare el tipo de información y el nivel de detalle que son adecuados para compartir con los usuarios. Comunique también al equipo de carga de trabajo cualquier otro requisito que se aplique a estos casos.

Realización de postmortems de incidentes

Postmortems debe seguir todas las implementaciones con errores, sin excepción. Cada implementación con errores es una oportunidad para aprender. Postmortems puede ayudarle a identificar debilidades en los procesos de implementación y desarrollo. También puede identificar errores de configuración en la infraestructura, entre muchas otras posibilidades.

Los postmortems siempre deben ser culpables para que las personas implicadas en el incidente se sientan seguras cuando comparten sus perspectivas sobre lo que se puede mejorar. Los líderes postmortem deben seguir los planes para implementar las mejoras que se han identificado y agregar estos planes al trabajo pendiente de carga de trabajo.

Operacionalización de procesos de mitigación

Asegúrese de que la canalización de implementación puede aceptar versiones distintas como parámetros para que pueda implementar fácilmente configuraciones de última calidad conocidas.

Mantenga la coherencia con los planos de administración y datos a medida que revierte o revierte hacia delante. Las claves, los secretos, los datos de estado de la base de datos y las configuraciones que son específicos de los recursos y las directivas deben estar en el ámbito y tener en cuenta. Por ejemplo, preste atención al diseño del escalado de la infraestructura en la última implementación correcta conocida. Determine si necesita ajustar esa configuración al volver a implementar el código.

Se prefieren cambios pequeños y frecuentes con poca frecuencia y cambios grandes para que la diferencia entre las implementaciones nuevas y las últimas que se conocen sean pequeñas.

Realice un análisis del modo de error (FMA) en las canalizaciones de integración continua y entrega continua (CI/CD) para ayudar a identificar problemas que pueden complicar las mitigaciones. Al igual que la carga de trabajo en su conjunto, las canalizaciones se pueden analizar para identificar áreas que podrían ser problemáticas al intentar un tipo de mitigación determinado.

Use la funcionalidad de reversión automatizada con criterio:

  • Algunas herramientas de CI/CD, como Azure DevOps, tienen funcionalidad de reversión automática integrada. Considere la posibilidad de usar esta funcionalidad si proporciona un valor tangible para usted.
  • Debe adoptar la funcionalidad de reversión automática solo después de probar la canalización de forma exhaustiva y periódica. Asegúrese de que la canalización es lo suficientemente madura para introducir problemas adicionales si se desencadena una reversión automática.
  • Debe confiar en que la automatización solo implementa los cambios necesarios y que se desencadena solo cuando sea necesario. Diseñe cuidadosamente los desencadenadores para cumplir estos requisitos.

Use funcionalidades proporcionadas por la plataforma durante las reversiones. Por ejemplo, las copias de seguridad y las restauraciones a un momento dado pueden ayudar con las reversiones de almacenamiento y de datos. O bien, si usa máquinas virtuales (VM) para hospedar la aplicación, puede resultar útil restaurar el entorno a un punto de control inmediatamente antes de un incidente.

Pruebe con frecuencia toda la estrategia de mitigación de errores de implementación. Al igual que los planes de respuesta de emergencia y los planes de recuperación ante desastres, el plan de error de implementación solo se realiza correctamente si el equipo está entrenado en él y lo practica con regularidad. La ingeniería de caos y las pruebas de inyección de errores pueden ser técnicas eficaces para probar la estrategia de mitigación de la implementación.

Compensación: los miembros del equipo de soporte técnico deben ser capaces de realizar sus tareas normales y también apoyar emergencias. Es posible que tenga que aumentar el número de cabezas para ayudar a garantizar que el equipo de soporte técnico esté correctamente entrenado y pueda llevar a cabo todas las tareas necesarias. Pruebe las implementaciones exhaustivamente al implementar en entornos de desarrollo inferiores. Esta práctica le ayuda a detectar errores y configuraciones incorrectas antes de llegar a producción.

Facilitación de Azure

  • Azure Pipelines proporciona servicios de compilación y versión para admitir CI/CD de las aplicaciones.

  • Azure Test Plans es una solución de administración de pruebas basada en explorador que es fácil de usar. Esta solución ofrece funcionalidades necesarias para pruebas manuales planeadas, pruebas de aceptación de usuarios y pruebas exploratorias. Azure Test Plans también proporciona una manera de recopilar comentarios de las partes interesadas.

  • Azure Monitor es una solución de supervisión completa para recopilar, analizar y responder a los datos de supervisión de los entornos locales y en la nube. El monitor incluye una plataforma de alertas sólida. Puede configurar ese sistema para las notificaciones automáticas y otras acciones, como el escalado automático y otros mecanismos de recuperación automática.

  • Application Insights es una extensión de Monitor que proporciona características de supervisión del rendimiento de aplicaciones (APM).

  • Azure Logic Apps es una plataforma basada en la nube para ejecutar flujos de trabajo automatizados que integran aplicaciones, datos, servicios y sistemas. Puede usar Logic Apps para crear una nueva versión de la aplicación cada vez que se realice una actualización. Azure mantiene un historial de las versiones y puede revertir o promover cualquier versión anterior.

  • Muchos servicios de base de datos de Azure proporcionan funcionalidad de restauración a un momento dado que puede ayudarle cuando necesite revertir:

  • La versión preliminar de Azure Chaos Studio es un servicio administrado que usa ingeniería de caos para ayudarle a medir, comprender y mejorar la resistencia de las aplicaciones y servicios en la nube.

Lista de comprobación de excelencia operativa

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de excelencia operativa