Despliegues sin tiempo de inactividad: el patrón que la mayoría de los equipos hace mal

La mayoría de los equipos tratan el despliegue sin tiempo de inactividad como una función de Kubernetes que se activa, no como una estrategia que se diseña. Las actualizaciones progresivas (rolling updates) por sí solas no te protegen de una mala versión — simplemente distribuyen el daño a lo largo de una ventana de despliegue.

Los despliegues canary, donde un pequeño porcentaje del tráfico llega a la nueva versión antes de un lanzamiento completo, detectan muchos más problemas que el cambio blue-green por sí solo — pero solo si estás observando las métricas correctas. La tasa de errores y la latencia no son suficientes; las métricas de negocio, como la finalización del checkout, a menudo revelan regresiones que las métricas técnicas pasan por alto por completo.

La parte más pasada por alto es la ruta de reversión (rollback). Si revertir una versión toma más tiempo que arreglarla hacia adelante, tu equipo siempre elegirá arreglar hacia adelante bajo presión — y así es como los problemas menores se convierten en incidentes mayores. Practica tu rollback antes de necesitarlo.