Recomendaciones para prácticas de implementación seguras

  • Artículo

Se aplica a esta recomendación de lista de comprobación de excelencia operativa de Azure Well-Architected Framework:

OE:11 Defina claramente los procedimientos de implementación seguros de la carga de trabajo. Resalte los ideales de los métodos de liberación pequeños, incrementales y de calidad. Use patrones de implementación modernos y técnicas de exposición progresivas para controlar el riesgo. Tenga en cuenta las implementaciones rutinarias y las implementaciones de emergencia, o revisiones.

En esta guía se describen las recomendaciones para usar prácticas de implementación seguras (SDP). Los procedimientos y los procesos de implementación seguros definen cómo realizar e implementar cambios de forma segura en la carga de trabajo. La implementación de SDP requiere que piense en las implementaciones mediante el objetivo de administrar el riesgo. Puede minimizar el riesgo de error humano en las implementaciones y limitar los efectos de las implementaciones problemáticas en los usuarios mediante la implementación de SDP.

Estrategias de diseño principales

Hay cuatro directrices importantes que se deben tener en cuenta al implementar prácticas de implementación seguras:

  • Seguridad y coherencia: todos los cambios en la carga de trabajo de producción son inherentemente peligrosos y deben realizarse con un enfoque en la seguridad y la coherencia.

  • Exposición progresiva: puede minimizar el radio de explosión potencial de los problemas causados por la implementación mediante la adopción de un modelo de implementación de exposición progresiva.

  • Modelos de estado: las implementaciones deben pasar comprobaciones de estado antes de que pueda comenzar cada fase de exposición progresiva.

  • Detección de problemas: cuando se detectan problemas, la implementación se debe detener inmediatamente y iniciar la recuperación.

En las secciones siguientes se proporcionan recomendaciones detalladas sobre cada uno de estos puntos.

Seguridad y coherencia

Tanto si va a implementar una actualización en el código de la aplicación, la infraestructura como código (IaC), la marca de características o una actualización de configuración, está introduciendo riesgos para la carga de trabajo. No hay implementaciones de bajo riesgo en producción. Cada implementación debe seguir un patrón estándar y debe automatizarse para aplicar la coherencia y minimizar el riesgo de error humano. Es fundamental que las canalizaciones de implementación y cadena de suministro de cargas de trabajo sean confiables, seguras y tengan estándares de implementación claramente definidos. Trate cada implementación como un riesgo posible y somete cada implementación al mismo nivel de administración de riesgos. A pesar de los riesgos, debe seguir implementando cambios regulares en la carga de trabajo. Si no se implementan actualizaciones periódicas, se presentan otros riesgos, como las vulnerabilidades de seguridad que se deben abordar a través de las implementaciones. Para obtener más información, consulte Recomendaciones para diseñar una cadena de suministro de desarrollo de cargas de trabajo.

Las implementaciones pequeñas frecuentes son preferibles a implementaciones de gran tamaño poco frecuentes. Los pequeños cambios son más fáciles de resolver cuando surgen problemas y las implementaciones frecuentes ayudan al equipo a crear confianza en el proceso de implementación. También es importante que aprenda de producción revisando los procesos de carga de trabajo cuando encuentre una anomalía durante la implementación. Es posible que encuentre puntos débiles en el diseño de la infraestructura o el lanzamiento. Cuando se producen problemas durante las implementaciones, asegúrese de que las postmortems sin culpa forman parte del proceso de SDP para capturar lecciones sobre el incidente.

Implementación de exposición progresiva

Cuando se producen problemas de implementación, el objetivo es detectarlos lo antes posible para minimizar el efecto en los usuarios finales. Implemente un modelo de implementación gradual, también conocido como modelo de exposición progresiva, para lograr este objetivo. Las implementaciones controladas son un ejemplo común de exposición progresiva. En este modelo de implementación, un pequeño grupo de usuarios internos o externos reciben primero la nueva característica. Después de que el primer grupo ejecute la nueva versión sin problema, la característica se implementa en grupos sucesivamente más grandes hasta que todo el rellenado de usuarios ejecute la nueva versión. Las marcas de características se suelen usar para habilitar la nueva versión para los usuarios de destino en implementaciones controladas.

Otro modelo de implementación común es un enfoque azul-verde. En este modelo, se implementan dos conjuntos o grupos idénticos de infraestructura de carga de trabajo. Ambos grupos pueden controlar una carga de producción completa. El primer grupo (azul) ejecuta la versión actual de la implementación donde todos los usuarios llegan. El segundo grupo (verde) se actualiza con la nueva característica y se prueba internamente. Después de las pruebas internas, un subconjunto del tráfico de producción se enruta desde el grupo azul al grupo verde. Al igual que las implementaciones controladas, el lanzamiento es progresivo a medida que cambia más tráfico al grupo verde en oleadas de lanzamiento sucesivamente más grandes. Después de finalizar el lanzamiento, el grupo de actualizaciones se convierte en el grupo azul y el grupo verde está listo para la siguiente implementación. Los dos grupos se separan lógicamente entre sí para protegerse de errores de funcionamiento. Puede implementar una variación del modelo azul-verde en una carga de trabajo que use el patrón de diseño De stamps de implementación mediante la implementación en una marca a la vez.

En ambos modelos, el tiempo entre cada fase del lanzamiento debe ser lo suficientemente largo como para permitirle supervisar las métricas de estado de la carga de trabajo. Debe proporcionar un amplio tiempo de elaboración, tiempo entre los grupos de lanzamiento, para ayudar a garantizar que los usuarios de diferentes regiones o usuarios que realizan diferentes tareas tengan tiempo para usar la carga de trabajo en su capacidad normal. Los tiempos de elaboración deben medirse en horas y días en lugar de minutos. Los tiempos de elaboración también deben aumentar para cada grupo de lanzamiento para que pueda tener en cuenta diferentes zonas horarias y patrones de uso durante el transcurso del día.

Modelos de mantenimiento

Desarrolle un modelo de mantenimiento sólido como parte de su plataforma de observabilidad y estrategias de confiabilidad. El modelo de mantenimiento debe proporcionar visibilidad detallada sobre los componentes y el estado general de la carga de trabajo. Durante un lanzamiento, si recibe una alerta sobre un cambio de estado relacionado con un usuario final, el lanzamiento debe detenerse inmediatamente y se debe realizar una investigación sobre la causa de la alerta para ayudar a determinar el siguiente curso de acción. Si no hay ningún problema notificado por los usuarios finales y todos los indicadores de salud permanecen verdes a lo largo del tiempo de elaboración, el lanzamiento debe continuar. Asegúrese de incluir métricas de uso en el modelo de estado para ayudar a garantizar que la falta de problemas notificados por el usuario y las señales de mantenimiento negativas no ocultan un problema. Para obtener más información, consulte Creación de un modelo de mantenimiento.

Detección de problemas

Cuando la implementación provoca un problema en uno de los grupos de lanzamiento, el lanzamiento debe detenerse inmediatamente. Se debe realizar una investigación sobre la causa del problema y la gravedad de los efectos en cuanto se reciba la alerta. La recuperación del problema puede incluir:

  • Para revertir la implementación, deshace los cambios realizados en la implementación y vuelva a la última configuración de trabajo conocida.

  • Para avanzar la implementación, solucione el problema en medio del lanzamiento. Puede solucionar los problemas del lanzamiento medio aplicando una revisión o minimizando el problema.

  • Implementación de una nueva infraestructura mediante la última configuración de trabajo conocida.

Revertir los cambios, especialmente la base de datos, el esquema u otros cambios de componente con estado, pueden ser complejos. Las directrices de SDP deben proporcionar instrucciones claras sobre cómo tratar los cambios de datos según el diseño del patrimonio de datos para la carga de trabajo. De forma similar, la puesta al día debe controlarse cuidadosamente para asegurarse de que SDP no se descuide y que la revisión u otros esfuerzos minimizados se realicen de forma segura.

Recomendaciones generales de SDP

  • Implemente el control de versiones en los artefactos de compilación para asegurarse de que puede revertirlo y revertirlo cuando sea necesario.

  • Use un flujo de versión o una estructura de bifurcación basada en troncos, que exige la colaboración estrechamente sincronizada en el equipo de desarrollo, en lugar de una estructura de bifurcación basada en entornos o Gitflow.

  • Automatice tanto el SDP como sea posible. Para obtener instrucciones detalladas sobre la automatización de procesos de integración continua e integración continua de aplicaciones y entrega continua (CI/CD), consulte Recomendaciones para implementar la automatización.

  • Use prácticas de CI para integrar periódicamente los cambios de código en los repositorios. Las prácticas de CI pueden ayudarle a identificar conflictos de integración y reducir la probabilidad de combinaciones de gran tamaño y de riesgo. Para obtener más información, consulte la Guía de integración continua.

  • Use marcas de características para habilitar o deshabilitar de forma selectiva nuevas características o cambios en producción. Las marcas de características pueden ayudarle a controlar la exposición del nuevo código y revertir rápidamente la implementación si surgen problemas.

  • Implemente cambios en entornos de ensayo que reflejen el entorno de producción. Los entornos de práctica permiten probar los cambios en una configuración controlada antes de realizar la implementación en el entorno activo.

  • Establezca comprobaciones previas a la implementación, incluida la revisión de código, los exámenes de seguridad y las comprobaciones de cumplimiento, para ayudar a garantizar que los cambios son seguros para la implementación.

  • Implemente disyuntores para detener automáticamente el tráfico a un servicio que experimenta problemas. Si lo hace, puede ayudar a evitar una mayor degradación del sistema.

Protocolos SDP de emergencia

Establezca protocolos prescriptivos que definan cómo se puede ajustar el SDP para una revisión o para problemas de emergencia, como una vulneración de seguridad o una exposición a vulnerabilidades. Por ejemplo, los protocolos SDP de emergencia pueden incluir:

  • Aceleración de fase de promoción y aprobación.

  • Pruebas de humo e aceleración de pruebas de integración.

  • Reducción del tiempo de elaboración.

En algunos casos, la emergencia podría limitar las puertas de calidad y pruebas, pero las puertas deben ejecutarse lo más rápido posible como un ejercicio fuera de banda. Asegúrese de definir quién puede aprobar la aceleración de SDP en una emergencia y los criterios que se deben cumplir para que se apruebe la aceleración. Alinee los protocolos SDP de emergencia con su plan de respuesta de emergencia para ayudar a garantizar que todas las emergencias se controlen según los mismos protocolos.

Consideraciones

La creación y el mantenimiento de prácticas de implementación seguras es compleja. Su éxito en la implementación completa de estándares sólidos depende de la madurez de sus prácticas en muchas áreas de desarrollo de software. El uso de automatización, solo IaC para los cambios de infraestructura, la coherencia en las estrategias de bifurcación, el uso de marcas de características y muchas otras prácticas pueden ayudar a garantizar una implementación segura. Use esta guía para optimizar la carga de trabajo e informar a los planes de mejora a medida que evolucionan las prácticas.

Facilitación de Azure

  • Azure Pipelines y Acciones de GitHub admiten implementaciones de varias fases mediante puertas de aprobación, lo que puede ayudarle a diseñar la implementación de exposición progresiva para implementaciones.

  • Use Azure App Service ranuras de ensayo para intercambiar fácilmente entre versiones de código. Las ranuras de ensayo son útiles para las pruebas en entornos de ensayo y se pueden usar para implementaciones azul-verde.

  • Almacene y administre las marcas de características de la aplicación web en Azure App Configuration. Con este servicio, puede crear, cambiar e implementar características en un plano de administración unificado.

  • Implemente aplicaciones de carga de trabajo en la máquina virtual mediante aplicaciones de máquina virtual.

  • Use equilibradores de carga de Azure para implementar estrategias de implementación y exponer el estado de las aplicaciones de carga de trabajo mediante recursos nativos.

  • Use la extensión Estado de la aplicación para informar sobre el estado de la aplicación desde dentro de una instancia del conjunto de escalado de máquinas virtuales. Los sondeos de extensión en un punto de conexión de aplicación local y actualizan el estado de mantenimiento en función de las respuestas TCP/HTTP(S) recibidas de la aplicación.

  • Use Azure 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 versiones de aplicación y puede revertir o promover a cualquier versión anterior.

  • Muchos servicios de Azure Database proporcionan funcionalidad de restauración a un momento dado que puede ayudarle a revertir. Entre los servicios que admiten la restauración a un momento dado se incluyen:

Ejemplo

Consulte la guía de arquitectura de clústeres de Azure Kubernetes Service (AKS) azul-verde para ver un ejemplo de cómo usar este modelo de implementación.

Lista de comprobación de excelencia operativa

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de excelencia operativa