Resiliencia y Seguridad en Despliegues
Resumen
Las cosas se romperán. La postura no es "prevenir todo fallo" sino fallar poco, recuperarse rápido y aprender cada vez. La fiabilidad no es la ausencia de fallos; es el radio de explosión acotado y el tiempo de recuperación corto cuando el fallo llega.
Seguridad en Despliegues — Cada Despliegue Reversible y Expuesto Progresivamente
- El artefacto es inmutable y se promociona, no se reconstruye. Una imagen, construida una vez en CI e identificada por su digest de contenido, se mueve vista previo → staging → producción sin cambios. Reconstruir por entorno significa desplegar algo que nunca probaste.
- Las etiquetas son punteros mutables; el digest es la identidad. Una etiqueta puede sobrescribirse y apuntar silenciosamente a otro lugar. Un digest de contenido no puede. Cada entorno registra el digest que validó, y producción ejecuta solo un digest que un entorno inferior validó — así, "lo exacto que probamos" es una propiedad que el pipeline impone, no una disciplina que alguien deba recordar.
- Una decisión humana precede a producción. Para un mantenedor único esto es una pausa deliberada y un registro de auditoría, no una separación de funciones. Di cuál es; no lo sobredimensiones.
- La versión en ejecución se inyecta en tiempo de despliegue, nunca se hornea en la imagen. Una versión horneada como argumento de construcción fuerza una reconstrucción para marcar un lanzamiento, y la reconstrucción es exactamente lo que la promoción existe para evitar.
- Cuando la infraestructura vive en su propio repositorio, coordínala mediante expandir/contraer. La infraestructura se expande primero (aditiva, compatible hacia atrás), la aplicación consume la nueva capacidad en un despliegue posterior, y la infraestructura se contrae solo cuando ningún artefacto en vivo depende de la forma anterior — la misma disciplina que un cambio de esquema (ver
zero-downtime-migrations). El invariante: nunca envíes un artefacto de aplicación que requiera un cambio de infraestructura aún no activo. Cumpliendo esto, cada repositorio es independientemente reversible, lo que hace que la reversión sea manejable cuando ambos están desincronizados. - Avanzar solo cuando puedas retroceder. Existe una ruta de reversión y se prueba antes de que se envíe un cambio riesgoso. "¿Cómo deshacemos esto?" se responde en el plan, no durante el incidente.
- Reversión es redesplegar el digest previamente bueno. Ese digest todavía está en el registro y sigue siendo inmutable, por lo que revertir es promoción inversa — nunca una reconstrucción, y nunca una reconstrucción "como era".
- Exposición progresiva. Las nuevas versiones llegan a los usuarios gradualmente (despliegue controlado por salud, canario donde sea compatible), por lo que un lanzamiento malo daña a una fracción, no a todos.
- Los cambios de esquema están desacoplados de los despliegues de código y siguen expandir/contraer (ver
zero-downtime-migrations). Un despliegue nunca debe requerir una migración destructiva simultánea. - Una lista de verificación previa al despliegue controla producción: observabilidad en su lugar, reversión verificada, migraciones seguras para expansión, SLOs no rotos.
Respuesta a Incidentes — El Fracaso es una Entrada de Aprendizaje
- Clasifica por gravedad y responde proporcionalmente; ten un camino conocido para involucrar a las personas adecuadas.
- Autopsias sin culpa para cada incidente visible para el usuario. Cronología escrita, causas contribuyentes (sistémicas, no personales), elementos de acción concretos. La pregunta es "¿qué parte del sistema permitió que esto sucediera?", nunca "¿quién la cagó?".
- Los elementos de acción se rastrean, no se olvidan — fluyen hacia el documento de Consideraciones Futuras (ver
recording-decisions) y se convierten en trabajo real. - El presupuesto de errores gobierna. Cuando se agota la fiabilidad, el trabajo de fiabilidad supera a las funciones hasta que el presupuesto se recupera.
Referencia Rápida
| Antes de un despliegue riesgoso | Confirmar |
|---|---|
| Artefacto | Construido una vez en CI; promocionado por digest; el mismo que staging validó |
| Puerta | Una decisión humana registrada antes de producción |
| Reversión | La ruta existe y está probada |
| Exposición | Gradual/canario, no todo a la vez |
| Esquema | Seguro para expansión, desacoplado del despliegue de código |
| Observabilidad | ¿Puedes ver si algo va mal? |
Cuándo escalar esto
Los proyectos locales o previos al lanzamiento escriben estas reglas ahora, se activan en los primeros usuarios reales. Las propiedades son portátiles — construir una vez, promocionar lo probado, decidir antes de producción, poder revertir — pero los mecanismos no lo son: una promoción por digest tiene sentido en un host de contenedores y es en gran medida irrelevante para un sitio estático, y una plataforma gestionada puede proporcionar entornos de vista previa y reversión instantánea de forma gratuita. Nombra el mecanismo en la habilidad de entrega del proyecto; mantén la propiedad aquí. Mecanismos de pila (sondas de k8s, canary, entornos por PR): cloud-delivery-aks.
Razonamiento completo: Artículo XII de la constitución, empaquetado en engineering-constitution/references/engineering-constitution.md.