Mejores Prácticas de Gestión de Cambios
Las DDL de alto riesgo requieren guardas automatizadas de tiempo de espera de bloqueo. Utiliza esta lista en la revisión de PR de migraciones y en los paquetes de CAB.
Cómo Usar Esta Lista
- Adjunta la finalización de la lista de verificación a cada ticket de cambio de alto riesgo.
- Aplica tiempos de espera de bloqueo en las callbacks de Flyway o en el pre-sql de Liquibase, no de memoria.
- Ensaya el rollback en staging con recuentos de filas a escala de producción.
- Revisa las migraciones fallidas mensualmente; convierte los patrones en reglas de linting.
A - Clasificación
- Cada script tiene un nivel de riesgo (bajo/medio/alto/digno de severidad). No hay DDL sin etiquetar en la rama principal.
- Los cambios de alto riesgo requieren un revisor DBA nombrado. No solo una aprobación genérica de plataforma.
- Radio de impacto documentado. Se listan tablas, servicios y recuentos de filas aproximados.
- Ampliar/contraer el valor predeterminado para cambios disruptivos. Evita reescrituras en un solo paso en tablas grandes.
B - Guardas de Seguridad
-
lock_timeoutestablecido en cada sesión de migración. Cinco segundos es un valor predeterminado común para OLTP. -
statement_timeoutestablecido para DDL por lotes. Evita migraciones colgadas durante la noche. -
CREATE INDEXusaCONCURRENTLYen tablas de producción. Envuelto fuera de las transacciones. - Las claves foráneas se añaden primero como
NOT VALID. Valida en una ventana separada después de la limpieza de datos. - Alerta de índice inválido activada.
pg_index.indisvalid = falsenotifica al equipo de guardia.
C - Ventanas y Comunicación
- DDL de alto riesgo solo en ventanas de mantenimiento. Con página de estado y responsable del rollback.
- Congelar despliegues competidores durante la ventana. Un objetivo por ventana.
- Latencia de replicación monitorizada durante el backfill. SLO de latencia de bytes en el primario.
- El lenguaje del cliente comunica el impacto visible para el usuario. No "mantenimiento breve".
D - Rollback y Aprendizaje
- Sección de rollback en el ticket: reversión de la aplicación + contrato de esquema. Se indica explícitamente el avance solo hacia adelante.
- Ruta de PITR documentada para DML catastrófico. Se nombra el objetivo de tiempo y el responsable.
- Consultas de verificación post-cambio en el runbook. No
psqlad hoc después del hecho. - Post-mortem de migración fallida dentro de los cinco días. Actualiza callbacks y plantillas.
Preguntas Frecuentes
¿Qué valor de `lock_timeout` es estándar?
3-10s para OLTP; más tiempo solo en tablas de lotes con aprobación explícita de ventana.
¿Debería Liquibase ejecutarse en una sola transacción?
Desactivar para CREATE INDEX CONCURRENTLY y algunos patrones de ALTER según la documentación del proveedor.
¿Cómo aplicamos los niveles en CI?
Linting de encabezados de migración, requerir CODEOWNERS en db/migrate, bloquear despliegues de alto riesgo los viernes por política.
¿Las vistas y funciones tienen menor riesgo?
CREATE OR REPLACE puede romper dependientes; clasificar como medio a menos que sea puramente aditivo.
¿Quién es el propietario del calendario de cambios?
El equipo de DBA o plataforma con visibilidad del producto en las fechas de bloqueo.
¿Las extensiones necesitan CAB?
Sí, al instalar en producción o al actualizar versiones principales de pgvector/PostGIS.
¿Cómo manejar las migraciones de hotfix?
Las mismas guardas; la aprobación acelerada no omite lock_timeout.
¿Qué pasa con los esquemas multi-tenant?
Despliegue por tenant o ventanas conscientes de los shards; documentar el radio de impacto por tenant.
¿Puede el SQL generado por IA omitir la revisión?
Nunca. El DDL generado todavía necesita clasificación humana de nivel y prueba de bloqueo en staging.
¿Qué debería leer a continuación?
Consulta Conceptos Básicos de Gestión de Cambios para ver ejemplos de niveles.
Relacionado
- Conceptos Básicos de Gestión de Cambios - matriz de niveles y ejemplos
- Ventanas de Mantenimiento - programación y comunicaciones
- Rollback para Migraciones Fallidas - rutas inversas
- Reglas de Seguridad de Migración - política del equipo
- DDL sin tiempo de inactividad - técnicas en línea
Versiones de la pila: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.