Procedimientos operativos para cargas de trabajo críticas en Azure

Las operaciones confiables y eficaces deben basarse en los principios de automatización siempre que sea posible y la configuración como código. Este enfoque requiere una inversión sustancial en ingeniería en procesos de DevOps. Las canalizaciones automatizadas se usan para implementar artefactos de código de aplicación e infraestructura. Las ventajas de este enfoque incluyen resultados operativos coherentes y precisos con procedimientos operativos manuales mínimos.

En este área de diseño se explora cómo implementar procedimientos operativos eficaces y coherentes.

Importante

Este artículo forma parte de la serie de cargas de trabajo críticas de Azure Well-Architected Framework . Si no está familiarizado con esta serie, se recomienda empezar con ¿Qué es una carga de trabajo crítica?.

Procesos de DevOps

DevOps combina procesos operativos y de desarrollo y equipos en una sola función de ingeniería. Abarca todo el ciclo de vida de la aplicación y usa herramientas de automatización y DevOps para realizar operaciones de implementación de una manera rápida, eficaz y confiable. Los procesos de DevOps admiten y mantienen la integración continua y la entrega continua (CI/CD) a la vez que fomentan una cultura de mejora continua.

El equipo de DevOps para una aplicación crítica debe ser responsable de estas tareas:

• Creación y administración de recursos de aplicación e infraestructura a través de la automatización de CI/CD.
• Supervisión y observabilidad de aplicaciones.
• Control de acceso basado en rol (RBAC) de Azure y administración de identidades para los componentes de la aplicación.
• Administración de red para los componentes de la aplicación.
• Administración de costos para los recursos de la aplicación.

DevSecOps amplía el modelo de DevOps mediante la integración de la supervisión de seguridad, las auditorías de aplicaciones y el control de calidad con el desarrollo y las operaciones durante todo el ciclo de vida de la aplicación. Los equipos de DevOps son necesarios para escenarios altamente regulados y sensibles a la seguridad para garantizar que la seguridad se incorpore a lo largo del ciclo de vida de desarrollo en lugar de en una fase o puerta de lanzamiento específica.

Consideraciones de diseño

• Proceso de lanzamiento y actualización. Evite los procesos manuales para cualquier cambio en los componentes de la aplicación o en la infraestructura subyacente. Los procesos manuales pueden dar lugar a resultados incoherentes.

• Dependencias de los equipos de TI centrales. Los procesos de DevOps pueden ser difíciles de aplicar cuando hay dependencias difíciles en funciones centralizadas porque estas dependencias impiden las operaciones de un extremo a otro.

• Administración de identidades y acceso. Los equipos de DevOps pueden considerar roles RBAC de Azure pormenorizados para diversas funciones técnicas, como AppDataOps para la administración de bases de datos. Aplique un modelo de confianza cero en los roles de DevOps.

Recomendaciones de diseño

• Defina las opciones de configuración y las actualizaciones como código. Aplique la administración de cambios a través del código para habilitar procesos coherentes de versión y actualización, incluidas tareas como la rotación de claves o secretos y la administración de permisos. Use procesos de actualización administradas por canalización, como ejecuciones de canalización programadas, en lugar de mecanismos de actualización automática integrados.

• No use procesos centrales ni canalizaciones de aprovisionamiento para la creación de instancias ni la administración de recursos de la aplicación. Al hacerlo, se presentan dependencias de aplicaciones externas y vectores de riesgo adicionales, como los asociados a escenarios de vecino ruidosos.

  Si necesita usar procesos de aprovisionamiento centralizados, asegúrese de que los requisitos de disponibilidad de las dependencias estén totalmente alineados con los requisitos críticos. Los equipos centrales deben proporcionar transparencia para que se logre la operacionalización holística de la aplicación de un extremo a otro.

• Dedique una proporción de capacidad de ingeniería durante cada sprint a impulsar mejoras fundamentales de la plataforma y reforzar la confiabilidad. Se recomienda asignar un 20-40 por ciento de capacidad a estas mejoras.

• Desarrolle criterios de ingeniería comunes, arquitecturas de referencia y bibliotecas que estén alineadas con los principios básicos de diseño. Aplique una configuración de línea base coherente para la confiabilidad, la seguridad y las operaciones a través de un enfoque controlado por directivas que use Azure Policy.

  También puede usar los criterios de ingeniería comunes y los artefactos asociados, como las directivas de Azure y los recursos de Terraform para patrones de diseño comunes, en otras cargas de trabajo dentro del ecosistema de aplicaciones más amplio de la organización.

• Aplique un modelo de confianza cero en entornos de aplicación críticos. Use tecnologías como Microsoft Entra Privileged Identity Management para garantizar que las operaciones sean coherentes y se produzcan solo a través de procesos de CI/CD o procedimientos operativos automatizados.

  Los miembros del equipo no deben tener acceso de escritura permanente a ningún entorno. Es posible que desee realizar excepciones en entornos de desarrollo para permitir pruebas y depuraciones más fáciles.

• Defina procesos de emergencia para el acceso Just-In-Time a entornos de producción. Asegúrese de que existen cuentas de emergencia en caso de problemas graves con el proveedor de autenticación.

• Considere la posibilidad de usar AIOps para mejorar continuamente los procedimientos operativos y desencadenadores.

Operaciones de aplicaciones

Las recomendaciones de diseño y plataforma de la aplicación influyen en los procedimientos operativos. También hay funcionalidades operativas proporcionadas por varios servicios de Azure, especialmente para alta disponibilidad y recuperación.

Consideraciones de diseño

• Operaciones integradas de servicios de Azure. Los servicios de Azure proporcionan funcionalidades de plataforma integradas (habilitadas de forma predeterminada) y configurables, como la redundancia zonal y la replicación geográfica. La confiabilidad de una aplicación depende de estas operaciones. Algunas funcionalidades configurables conllevan un costo adicional, como la configuración de implementación de varias escrituras para Azure Cosmos DB. Evite crear soluciones personalizadas a menos que necesite absolutamente.

• Tiempo de acceso operativo y ejecución. La mayoría de las operaciones necesarias se exponen y son accesibles a través de la API de Azure Resource Manager o el Azure Portal. Sin embargo, ciertas operaciones requieren ayuda de ingenieros de soporte técnico. Por ejemplo, una restauración a partir de una copia de seguridad periódica de una base de datos de Azure Cosmos DB o la recuperación de un recurso eliminado solo se puede realizar mediante Soporte técnico de Azure ingenieros a través de un caso de soporte técnico. Esta dependencia puede afectar al tiempo de inactividad de la aplicación. En el caso de los recursos sin estado, se recomienda volver a implementar en lugar de esperar a que los ingenieros de soporte técnico intenten recuperar los recursos eliminados.

• Aplicación de directivas. Azure Policy proporciona un marco para aplicar y auditar las líneas base de seguridad y confiabilidad para garantizar el cumplimiento de criterios de ingeniería comunes para aplicaciones críticas. Más concretamente, Azure Policy forma una parte clave del plano de control de Azure Resource Manager, complementando RBAC mediante la restricción de las acciones que los usuarios autorizados pueden realizar. Puede usar Azure Policy para aplicar convenciones de seguridad y confiabilidad vitales en todos los servicios de la plataforma.

• Modificación y eliminación de recursos. Puede bloquear los recursos de Azure para evitar que se modifiquen o eliminen. Sin embargo, los bloqueos presentan sobrecarga de administración en las canalizaciones de implementación. Para la mayoría de los recursos, se recomienda un proceso RBAC sólido con restricciones estrictas en lugar de bloqueos de recursos.

Recomendaciones de diseño

• Automatización de procedimientos de conmutación por error. Para un modelo activo o activo, use un modelo de mantenimiento y operaciones de escalado automatizadas para asegurarse de que no se requiere ninguna intervención de conmutación por error. Para un modelo activo/pasivo, asegúrese de que los procedimientos de conmutación por error se automatizan o al menos se codifican en canalizaciones.

• Priorice el uso del escalado automático nativo de Azure para los servicios que lo admiten. En el caso de los servicios que no admiten el escalado automático nativo, use procesos operativos automatizados para escalar los servicios. Use unidades de escalado con varios servicios para lograr escalabilidad.

• Use funcionalidades nativas de la plataforma para la copia de seguridad y restauración, lo que garantiza que están alineados con los requisitos de retención de datos y RTO/RPO. Defina una estrategia para la retención de copias de seguridad a largo plazo según sea necesario.

• Use funcionalidades integradas para la administración y renovación de certificados SSL, como las proporcionadas por Azure Front Door.

• En el caso de los equipos externos, establezca un proceso de recuperación para los recursos que requieren ayuda. Por ejemplo, si la plataforma de datos se modifica o elimina incorrectamente, los métodos de recuperación deben entenderse correctamente y un proceso de recuperación debe estar en vigor. De forma similar, establezca procedimientos para administrar imágenes de contenedor retiradas en el registro.

• Practique las operaciones de recuperación de antemano, en los datos y los recursos que no son de producción, como parte de los preparativos de continuidad empresarial estándar.

• Identifique alertas críticas y defina los sistemas y audiencias de destino. Defina canales claros para llegar a las partes interesadas adecuadas. Envíe solo alertas accionables para evitar ruido blanco y evitar que las partes interesadas operativas ignoren las alertas y falten información importante. Implemente la mejora continua para optimizar las alertas y eliminar el ruido blanco observado.

• Aplique la gobernanza controlada por directivas y Azure Policy para garantizar el uso adecuado de las funcionalidades operativas y una línea de base de configuración confiable en todos los servicios de aplicaciones.

• Evite el uso de bloqueos de recursos en recursos regionales efímeros. En su lugar, confíe en el uso adecuado de las canalizaciones de RBAC y CI/CD para controlar las actualizaciones operativas. Puede aplicar bloqueos de recursos para evitar la eliminación de recursos globales de larga duración.

Administración de actualizaciones

El diseño crítico respalda firmemente el principio de los recursos de aplicación sin estado efímeros. Si aplica este principio, normalmente puede realizar una actualización mediante una nueva implementación y canalizaciones de entrega estándar.

Consideraciones de diseño

• Alineación con las hojas de ruta de Azure. Alinee la carga de trabajo con las hojas de ruta de Azure para que los recursos de plataforma y las dependencias en tiempo de ejecución se actualicen periódicamente.

• Detección automática de actualizaciones. Configure los procesos para supervisar y detectar automáticamente las actualizaciones. Use herramientas como GitHub Dependabot.

• Pruebas y validación. Pruebe y valide nuevas versiones de paquetes, componentes y dependencias en un contexto de producción antes de cualquier versión. Las nuevas versiones pueden contener cambios importantes.

• Dependencias en tiempo de ejecución. Trate las dependencias en tiempo de ejecución como haría con cualquier otro cambio en la aplicación. Las versiones anteriores podrían presentar vulnerabilidades de seguridad y podrían tener un efecto negativo en el rendimiento. Supervise el entorno de tiempo de ejecución de la aplicación y manténgalo actualizado.

• Higiene de componentes y limpieza. Retirar o quitar recursos que no se usan. Por ejemplo, supervise los registros de contenedor y elimine las versiones de imagen antiguas que no está usando.

Recomendaciones de diseño

• Supervise estos recursos y manténgalos actualizados:

  • Plataforma de hospedaje de aplicaciones. Por ejemplo, debe actualizar periódicamente la versión de Kubernetes en Azure Kubernetes Service (AKS), especialmente si no se mantiene la compatibilidad con versiones anteriores. También debe actualizar los componentes que se ejecutan en Kubernetes, como cert-manager y CSI de Azure Key Vault, y alinearlos con la versión de Kubernetes en AKS.
  • Bibliotecas externas y SDK (.NET, Java, Python).
  • Proveedores de Terraform.

• Evite cambios operativos manuales en los componentes de actualización. Considere el uso de cambios manuales solo en situaciones de emergencia. Asegúrese de que tiene un proceso para volver a conciliar los cambios manuales en el repositorio de origen para evitar el desfase y la periodicidad del problema.

• Establezca un procedimiento automatizado para quitar versiones anteriores de imágenes de Azure Container Registry.

Administración de secretos

Las expiraciones de clave, secreto y certificado son una causa común de la interrupción de la aplicación. La administración de secretos para una aplicación crítica debe proporcionar la seguridad necesaria y ofrecer un nivel adecuado de disponibilidad para alinearse con los requisitos de confiabilidad máxima. Debe realizar la rotación de claves, secretos y certificados de forma periódica mediante un servicio administrado o como parte de la administración de actualizaciones y aplicar procesos para los cambios de código y configuración.

Muchos servicios de Azure admiten la autenticación Microsoft Entra en lugar de confiar en cadenas de conexión o claves. El uso de Microsoft Entra id. reduce considerablemente la sobrecarga operativa. Si usa una solución de administración de secretos, debe integrarse con otros servicios, admitir redundancia zonal y regional y proporcionar integración con Microsoft Entra id. de autenticación y autorización. Key Vault proporciona estas características.

Consideraciones de diseño

Hay tres enfoques comunes para la administración de secretos. Cada enfoque lee los secretos del almacén de secretos e los inserta en la aplicación en un momento diferente.

• Recuperación en tiempo de implementación. La ventaja de este enfoque es que la solución de administración de secretos solo debe estar disponible en el momento de la implementación porque no hay dependencias directas después de ese tiempo. Entre los ejemplos se incluyen la inserción de secretos como variables de entorno en una implementación de Kubernetes o en un secreto de Kubernetes.

  Solo la entidad de servicio de implementación debe poder acceder a secretos, lo que simplifica los permisos de RBAC en el sistema de administración de secretos.

  Sin embargo, hay desventajas en este enfoque. Presenta la complejidad de RBAC en las herramientas de DevOps con respecto al control del acceso a la entidad de servicio y en la aplicación con respecto a la protección de secretos recuperados. Además, las ventajas de seguridad de la solución de administración de secretos no se aplican porque este enfoque solo se basa en el control de acceso en la plataforma de aplicaciones.

  Para implementar actualizaciones o rotación de secretos, debe realizar una reimplementación completa.

• Recuperación de inicio de la aplicación. En este enfoque, los secretos se recuperan e insertan en el inicio de la aplicación. La ventaja es que puede actualizar o rotar fácilmente los secretos. No es necesario almacenar secretos en la plataforma de aplicaciones. Se requiere un reinicio de la aplicación para capturar el valor más reciente.

  Entre las opciones de almacenamiento comunes se incluyen el proveedor de Azure Key Vault para el controlador CSI del almacén de secretos y akv2k8s. También hay disponible una solución nativa de Azure, Key Vault configuración de la aplicación a la que se hace referencia.

  Una desventaja de este enfoque es que crea una dependencia en tiempo de ejecución en la solución de administración de secretos. Si la solución de administración de secretos experimenta una interrupción, es posible que los componentes de la aplicación que ya se ejecuten puedan seguir atendiendo las solicitudes. Es probable que se produzca un error en cualquier operación de reinicio o escalado horizontal.

• Recuperación en tiempo de ejecución. Recuperar secretos en tiempo de ejecución desde dentro de la propia aplicación es el enfoque más seguro porque incluso la plataforma de aplicaciones nunca tiene acceso a los secretos. La aplicación debe autenticarse en el sistema de administración de secretos.

  Sin embargo, para este enfoque, los componentes de la aplicación requieren una dependencia directa y una conexión con el sistema de administración de secretos. Esto hace que sea más difícil probar componentes individualmente y normalmente requiere el uso de un SDK.

Recomendaciones de diseño

• Cuando sea posible, use Microsoft Entra autenticación para conectarse a servicios en lugar de usar cadenas de conexión o claves. Use este método de autenticación junto con las identidades administradas de Azure, por lo que no es necesario almacenar secretos en la plataforma de aplicaciones.

• Aproveche la configuración de expiración en Key Vault y configure las alertas para las próximas expiraciones. Realice todas las actualizaciones de clave, secreto y certificado mediante el proceso de versión estándar.

• Implemente Key Vault instancias como parte de una marca regional para mitigar el posible efecto de un error en una sola marca de implementación. Use una instancia independiente para los recursos globales. Para obtener información sobre esos recursos, consulte el patrón de arquitectura típico para cargas de trabajo críticas.

• Para evitar la necesidad de administrar credenciales de entidad de servicio o claves de API, use identidades administradas en lugar de entidades de servicio para acceder a Key Vault siempre que sea posible.

• Implemente patrones de codificación para asegurarse de que los secretos se vuelven a recuperar cuando se produce un error de autorización en tiempo de ejecución.

• Aplique un proceso de rotación de claves totalmente automatizado que se ejecute periódicamente dentro de la solución.

• Use la notificación de expiración cercana a la clave en Azure Key Vault para obtener alertas sobre las próximas expiraciones.

Consideraciones específicas de IaaS al usar máquinas virtuales

Si necesita usar máquinas virtuales IaaS, algunos de los procedimientos y procedimientos descritos anteriormente en este documento pueden diferir. El uso de máquinas virtuales proporciona más flexibilidad en las opciones de configuración, los sistemas operativos, el acceso al controlador, el acceso al sistema operativo de bajo nivel y los tipos de software que puede instalar. Las desventajas son los costos operativos aumentados y la responsabilidad de las tareas que normalmente realizan el proveedor de nube cuando se usan servicios PaaS.

Consideraciones de diseño

• Las máquinas virtuales individuales no proporcionan alta disponibilidad, redundancia de zona ni redundancia geográfica.
• Las máquinas virtuales individuales no se actualizan automáticamente después de implementarlas. Por ejemplo, un SQL Server implementado SQL Server 2019 en Windows Server 2019, no se actualizará automáticamente a una versión más reciente.
• Los servicios que se ejecutan en una máquina virtual necesitan un tratamiento especial y herramientas adicionales si desea implementarlos y configurarlos a través de la infraestructura como código.
• Azure actualiza periódicamente su plataforma. Estas actualizaciones pueden requerir reinicios de máquina virtual. Novedades que requieren un reinicio normalmente se anuncian con antelación. Consulte Mantenimiento de máquinas virtuales en Azure y Control de notificaciones de mantenimiento planeado.

Recomendaciones de diseño

• Evite las operaciones manuales en las máquinas virtuales e implemente los procesos adecuados para implementar e implementar los cambios.

  • Automatice el aprovisionamiento de recursos de Azure mediante soluciones de infraestructura como código, como plantillas de Azure Resource Manager (ARM), Bicep, Terraform u otras soluciones.

• Asegúrese de que los procesos operativos para la implementación de máquinas virtuales, actualizaciones y copias de seguridad y recuperación están en vigor y probados correctamente. Para probar la resistencia, inserte errores en la aplicación, anote los errores y mitigue esos errores.

• Asegúrese de que las estrategias están en vigor para revertir al último estado correcto conocido si una versión más reciente no funciona correctamente.

• Cree copias de seguridad frecuentes para cargas de trabajo con estado, asegúrese de que las tareas de copia de seguridad funcionen de forma eficaz e implementen alertas para los procesos de copia de seguridad con errores.

• Supervise las máquinas virtuales y detecte errores. Los datos sin procesar para la supervisión pueden provenir de una variedad de orígenes. Analice las causas de los problemas.

• Asegúrese de que las copias de seguridad programadas se ejecutan según lo previsto y que las copias de seguridad periódicas se crean según sea necesario. Puede usar el Centro de copia de seguridad para obtener información.

• Priorice el uso de Virtual Machine Scale Sets en lugar de máquinas virtuales para habilitar funcionalidades como la escala, la escalabilidad automática y la redundancia de zona.

• Priorice el uso de imágenes estándar de Azure Marketplace en lugar de imágenes personalizadas que deben mantenerse.

• Use Azure VM Image Builder u otras herramientas para automatizar procesos de compilación y mantenimiento para imágenes personalizadas según sea necesario.

Además de estas recomendaciones específicas, aplique los procedimientos recomendados para los procedimientos operativos para escenarios de aplicaciones críticas según corresponda.

Paso siguiente

Revise el patrón de arquitectura para escenarios de aplicaciones críticas:

Patrón de arquitectura