Procedimientos de implementación seguros
A veces, una versión no cumple las expectativas. A pesar de usar los procedimientos recomendados y pasar todos los niveles de calidad, en ocasiones surgen incidencias que producen una implementación de producción que causa problemas imprevistos a los usuarios. Para minimizar y mitigar el impacto de estos problemas, se recomienda a los equipos de DevOps adoptar una estrategia de exposición progresiva que equilibre la exposición de una versión determinada con su rendimiento demostrado. A medida que se demuestra la efectividad de una versión en la fase de producción, estará disponible para niveles de audiencias más amplias hasta que todos los usuarios la usen. Los equipos pueden usar procedimientos de implementación seguros para maximizar la calidad y la velocidad de las versiones en producción.
Controlar la exposición a los clientes
Los equipos de DevOps pueden hacer uso de diversos procedimientos para controlar la exposición de actualizaciones a los clientes. Históricamente, las pruebas A/B han sido una opción popular entre los equipos que buscan ver cómo funcionan las distintas versiones de un servicio o una interfaz de usuario con respecto a los objetivos fijados. Las pruebas A/B también son relativamente fáciles de usar, ya que los cambios suelen ser menores y, a menudo, solo comparan versiones diferentes en el aspecto de un servicio orientado al cliente.
Implementación segura a través de anillos
A medida que las plataformas crecen, la escala de la infraestructura y las necesidades de la audiencia también tienden a crecer. Esto crea una demanda de un modelo de implementación que compensa los riesgos asociados a una nueva implementación con las ventajas de las actualizaciones que promete. La idea general es que una versión determinada debe exponerse primero solo a un pequeño grupo de usuarios con la mayor tolerancia al riesgo. Luego, si la versión funciona según lo previsto, se puede exponer a un grupo más amplio de usuarios. Si no hay ningún problema, el proceso puede continuar en grupos más amplios de usuarios o anillos, hasta que todos usen la nueva versión. Con las plataformas de entrega continua modernas, como GitHub Actions y Azure Pipelines, la creación de un proceso de implementación con anillos es algo accesible para los equipos de DevOps de cualquier tamaño.
Marcas de característica
A veces, es necesario implementar cierta funcionalidad como parte de una versión, pero no se expone de forma inicial a los usuarios. En estos casos, marcas de funciones ofrecen una solución en la que la funcionalidad se puede habilitar a través de cambios de configuración en función del entorno, el anillo o cualquier otra implementación específica.
Participación del usuario
De forma similar a las marcas de funciones, la participación del usuario es una manera de limitar la exposición. En este modelo, una función determinada se habilita en la versión, pero no se activa para un usuario a menos que lo desee específicamente. La decisión de tolerancia al riesgo pasa a los usuarios para que puedan decidir la rapidez con la que desean aceptar determinadas actualizaciones.
Normalmente, se emplean varios procedimientos a la vez. Por ejemplo, un equipo puede tener una función experimental destinada a un caso práctico muy específico. Como es arriesgado, la implementarán en el primer anillo para que los usuarios internos la prueben. Sin embargo, aunque las funciones están en el código, alguien debe incluir la marca de funciones en una implementación específica dentro del anillo para que la función se exponga a través de la interfaz de usuario. Incluso en ese caso, la marca de función solo puede exponer la opción para que un usuario se decida a usar la nueva función. Cualquier persona que no esté en el anillo, en esa implementación o no sea participante no se expondrá a la función. Aunque se trata de un ejemplo bastante rebuscado, sirve para ilustrar la flexibilidad y la viabilidad de la exposición progresiva.
Problemas comunes con los que los equipos se encuentran al principio
A medida que los equipos avanzan en un procedimiento más ágil de DevOps, pueden detectar los mismos problemas que otros que han migrado de entregas monolíticas tradicionales. Los equipos solían implementar una vez cada pocos meses porque tienen una mentalidad que apuesta por la estabilización. Esperan que cada implementación introduzca un cambio sustancial en el servicio y que haya problemas imprevistos.
Las cargas son demasiado grandes
Los servicios que se implementan cada pocos meses suelen llenarse de muchos cambios. Esto aumenta la probabilidad de que salgan problemas de inmediato y también dificulta la solución de estos por la cantidad de elementos nuevos. Al pasar a entregas más frecuentes, las diferencias en lo que se implementa se vuelven más pequeñas, lo que permite realizar pruebas más dirigidas y facilitar la depuración.
Sin aislamiento de servicios
Los sistemas monolíticos escalan tradicionalmente mediante la mejora del hardware en el que se implementan. Sin embargo, cuando algo va mal con la instancia, esto da lugar a que a todos tengan problemas. Una solución sencilla consiste en añadir varias instancias para que pueda equilibrar la carga de los usuarios. Sin embargo, esto puede necesitar elementos de arquitectura importantes, ya que muchos sistemas heredados no están creados para ser de varias instancias. Además, es posible que se haga necesario asignar recursos duplicados significativos para la funcionalidad que se pueda consolidar mejor en otro lugar.
A medida que se añaden nuevas funciones, investigue si haya alguna arquitectura de microservicios que pueda ayudarle a operar y escalar gracias a un mejor aislamiento del servicio.
Los procesos manuales llevan a error
Cuando un equipo solo implementa varias veces al año, la automatización de las entregas puede parecer algo que no merezca la pena. Como consecuencia, muchos procesos de implementación se administran de forma manual. Esto requiere una cantidad significativa de tiempo y esfuerzo y tiende a que se produzcan errores humanos. Solo hay que automatizar las tareas de compilación e implementación más comunes para reducir el tiempo malgastado y los errores no forzados.
Los equipos también pueden usar la infraestructura como código para tener un mejor control sobre los entornos de implementación. Esto elimina la necesidad de enviar solicitudes al equipo de operaciones para realizar cambios manuales a medida que se introducen nuevas funciones o dependencias en varios entornos de implementación.
Solo el equipo de operaciones puede realizar implementaciones
Algunas organizaciones tienen directrices y políticas que exigen que el personal de operaciones inicie y administre todas las implementaciones. Aunque puede haber habido buenas razones para eso en el pasado, un proceso ágil de DevOps se beneficia enormemente cuando el equipo de desarrollo puede iniciar y controlar las implementaciones. Las plataformas de entrega modernas ofrecen un control pormenorizado sobre quién puede iniciar las implementaciones y quién puede acceder a los registros de estado y a otra información de diagnóstico, asegurando de que las personas adecuadas tengan la información adecuada lo antes posible.
Las implementaciones incorrectas prosiguen y no pueden revertirse
A veces, una implementación no funciona correctamente y los equipos necesitan resolverla. Sin embargo, cuando los procesos son manuales y el acceso a la información es lento y limitado, puede ser difícil revertir a una implementación en curso anterior. Afortunadamente, hay varias herramientas y procedimientos que reducen el riesgo de las implementaciones con errores.
Principios básicos
Los equipos que buscan adoptar procedimientos de implementación seguros deben establecer algunos principios básicos para reforzar la labor.
Uniformidad
Las mismas herramientas que se usan para implementar en producción deben usarse en entornos de desarrollo y pruebas. Si hay problemas, como los que a menudo surgen de nuevas versiones de dependencias o herramientas, deben detectarse debidamente antes de que el código esté a punto de publicarse en producción.
Atención a los indicadores de calidad
Demasiados equipos caen en la trampa habitual de no preocuparse realmente por los indicadores de calidad. Con el tiempo, se pueden dar cuenta de que escriben pruebas o toman tareas de calidad solo para cambiar de una advertencia amarilla a una aprobación verde. Los indicadores de calidad son realmente importantes, ya que son el pulso de un proyecto. Se debe realizar un seguimiento constante diario de las señales de calidad que se usan para aprobar las implementaciones.
Las implementaciones deben incluir un tiempo de inactividad cero
Aunque no es vital que todos los servicios estén siempre disponibles, los equipos deben afrontar las fases de entrega y operaciones de DevOps con la idea de que pueden y deben implementar versiones nuevas sin que sea necesario quitarlas. Las herramientas modernas de infraestructura y procesos son lo suficientemente avanzadas, porque ya es posible que prácticamente cualquier equipo tenga como objetivo un tiempo de actividad del 100 %.
Las implementaciones deben realizarse durante el horario laboral
Si un equipo trabaja con la mentalidad de que las implementaciones requieren un tiempo de inactividad cero, no importará en qué momento se inserta una implementación. Además, resulta ventajoso insertar implementaciones durante las horas de trabajo, especialmente a horas tempranas del día y a principios de semana. Si algo va mal, se debe rastrear lo antes posible como para controlar el radio de explosión. Además, todos los usuarios estarán trabajando y centrados en subsanar los problemas.
Implementación basada en anillos
Los equipos que usan procedimientos de versiones bien desarrollados de DevOps están en la posición para asumir la implementación basada en anillos. En este modelo, las nuevas funciones se implementan primero para los clientes dispuestos a aceptar el máximo riesgo. A medida que se va mostrando la implementación, la audiencia se amplía para incluir a más usuarios hasta que todos la usen.
Un modelo de anillos de ejemplo
Un modelo de implementación de anillo típico está diseñado para detectar problemas lo antes posible a través de la segmentación cuidadosa de los usuarios y la infraestructura. En el ejemplo siguiente se muestra cómo usa los anillos un equipo principal de Microsoft.
| En anillo | Propósito | Usuarios | Centro de datos |
|---|---|---|---|
| 0 | Busca la mayoría de errores que afectan al usuario introducidos por la implementación | De uso solo interno con alta tolerancia a riesgos y errores | Centro-oeste de EE. UU. |
| 1 | Áreas que el equipo no prueba exhaustivamente | Clientes que usan gran parte del producto | Un pequeño centro de datos |
| 2 | Problemas relacionados con la escala | Cuentas públicas, preferentemente gratuitas con un grupo diverso de funciones | Un centro de datos mediano o grande |
| 3 | Problemas de escalado en cuentas internas y problemas de ámbito internacional | Cuentas internas grandes y clientes europeos | Centro de datos interno y centro de datos europeo |
| 4 | Unidades de escalado restantes | Todos los demás | Todos los destinos de implementación |
Permitir tiempo de simulación mediante “bake”
El término tiempo de simulación mediante “bake” hace referencia a la cantidad de tiempo que se permite que se ejecute una implementación antes de ampliarse y pasar al siguiente anillo. Algunos problemas pueden tardar horas o más en empezar a reflejar indicios por lo que la versión debe estar en uso durante un espacio de tiempo adecuado antes de que se considere lista.
En general, un día de 24 horas debe ser suficiente tiempo para la mayoría de casos para exponer errores latentes. Sin embargo, este período debe incluir un plazo de uso máximo, que abarca un día laborable completo, para los servicios más demandantes durante las horas laborables.
Acelerar revisiones
Una incidencia de sitio activo (LSI) se produce cuando un error tiene un impacto grave en la producción. Las LSI requieren la creación de una revisión, que es una actualización fuera de banda diseñada para solucionar un problema de alta prioridad.
Si un error es Sev 0, el tipo de error más grave, la revisión se puede implementar directamente en la unidad de escalado afectada lo antes posible. Aunque es fundamental que la corrección no empeore las cosas, los errores de esta gravedad se consideran tan perjudiciales que deben solucionarse inmediatamente.
Los errores clasificados como Sev 1 deben implementarse a través del anillo 0, pero luego se pueden implementar en las unidades de escalado afectadas tan pronto como se apruebe.
Las revisiones de errores con una gravedad inferior deben implementarse a través de todos los anillos según lo previsto.
Puntos clave
El propósito de cada equipo es entregar las actualizaciones rápidamente y con la mayor calidad posible. Con los procedimientos adecuados, la entrega puede ser una parte productiva y carente de obstáculos del ciclo de DevOps.
- Implemente con frecuencia.
- Mantenga un buen ritmo a lo largo del sprint.
- Use herramientas de implementación acordes en la fases de desarrollo, pruebas y producción.
- Use una plataforma de entrega continua que permita la automatización y la autorización.
- Siga procedimientos de implementación seguros.
Pasos siguientes
Descubra cómo las marcas de funciones ayudan a controlar la exposición de nuevas funciones a los usuarios.