Recomendaciones para prácticas de implementación seguras

  • 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: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 progresiva 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 procesos y procedimientos 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 a través del 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 debe 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 arriesgados 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 mantenimiento: 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.

Garantizar la seguridad y la coherencia de las implementaciones

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 la 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 vulnerabilidades de seguridad que deben abordarse a través de 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 poco frecuentes de gran tamaño. 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.

Adopción de un modelo 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 recibe 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 llegan todos los usuarios. El segundo grupo (verde) se actualiza con la nueva característica y se prueba internamente. Después de las pruebas internas, se enruta un subconjunto del tráfico de producción desde el grupo azul al grupo verde. Al igual que las implementaciones controladas, el lanzamiento es progresivo a medida que se desplaza más tráfico al grupo verde en oleadas de lanzamiento sucesivamente más grandes. Una vez finalizada la implementación, el grupo de actualizaciones se convierte en el grupo azul y el grupo verde está listo para la siguiente implementación. Los dos grupos están separados 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 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 mantenimiento de la carga de trabajo. Debe proporcionar suficiente tiempo de elaboración, tiempo entre grupos de implementación, 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.

Desarrollo de modelos de estado de carga de trabajo sólidos

Desarrolle un modelo de mantenimiento sólido como parte de la plataforma de observabilidad y las 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 estado permanecen verdes durante el 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 estado negativas no ocultan un problema. Para obtener más información, consulte Creación de un modelo de mantenimiento.

Implementación de mecanismos de detección de errores

Cuando la implementación provoca un problema en uno de los grupos de lanzamientos, el lanzamiento debe detenerse inmediatamente. Una investigación sobre la causa del problema y la gravedad de los efectos debe realizarse tan pronto como se reciba la alerta. La recuperación del problema puede incluir:

  • Revertir la implementación al deshacer los cambios realizados en la implementación y revertir a la última configuración de trabajo conocida.

  • Para avanzar la implementación, solucione el problema en medio del lanzamiento. Puede solucionar problemas a mitad de la implementación 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 con estado, pueden ser complejos. Las instrucciones 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. Del mismo modo, la puesta al día debe controlarse cuidadosamente para asegurarse de que SDP no se descuide y que la revisión u otros esfuerzos de minimización se realicen de forma segura.

Establecimiento de protocolos para implementaciones de emergencia

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

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

  • Automatice tanto su SDP como sea posible. Para obtener instrucciones detalladas sobre cómo automatizar la integración continua de IaC y los procesos de entrega continua (CI/CD), consulte Recomendaciones para implementar la automatización.

  • Use las 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 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 código nuevo 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 sean seguros para su 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 deben cumplirse 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 sus 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 el lanzamiento de exposición progresiva para implementaciones.

  • Use App de Azure ranuras de ensayo del servicio 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 las implementaciones azul-verde.

  • Almacene y administre las marcas de características de la aplicación web en App de Azure Configuración. 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 Application Health para informar sobre el estado de la aplicación desde dentro de una instancia del conjunto de escalado de máquinas virtuales. La extensión, de la que se hace un sondeo en un punto de conexión de la aplicación local, actualiza 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. Los servicios que admiten la restauración a un momento dado 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