Llevamos varias semanas dedicando los viernes a hablar de metodología, hemos visto Six Sigma, ITIL, Agile, Lean y hasta procesos DevOps. Hoy no vamos a hablar de ningún procedimiento en concreto sino de buenas prácticas generales a la hora de gestionar un cambio. En resumen, hacer las cosas con sentido común.
Decir “vamos a cambiar algo en producción” nunca debería sonar como “crucemos los dedos y a ver qué pasa”. Y sin embargo, más veces de las que nos gusta admitir, ese es exactamente el procedimiento. Porque claro, todo empieza con buena intención: una mejora de rendimiento, una corrección pequeña, “solo un índice” (maldita frase). Pero luego llega el drama, el monitor rojo, el jefe preguntando y el log lleno de errores que no deberían estar ahí.
En este artículo vamos a hablar de cómo gestionar el cambio en sistemas de bases de datos sin que acabe en desastre. O al menos, sin que tengamos que tomar antiinflamatorios a puñados. Porque cambiar en producción es inevitable. Lo que no debería serlo es sufrir cada vez como si estuviéramos lanzando un cohete a Marte con una escoba.
Antes del cambio: sospecha, planifica y valida
La gestión del cambio empieza mucho antes del cambio. Empieza con la duda. Si alguien te dice que es un cambio trivial, deberías activar inmediatamente el protocolo de escepticismo técnico. Los “solo era un índice” son los nuevos “yo controlo”.
Antes de tocar nada, necesitamos entender qué cambia, por qué y qué puede romperse. Parece obvio, pero demasiadas veces se ejecuta sin tener esto claro. Haz preguntas. ¿A qué objetos afecta? ¿Qué procesos dependen de esto? ¿Qué pasa si el cambio no se aplica bien? ¿Hay rollback?
Una vez identificados los riesgos, toca planificar. Y eso incluye mucho más que escribir el script. Hay que definir ventanas, implicar a los equipos afectados, coordinar timings y sobre todo, preparar el entorno. Tener backups recientes, estadísticas actualizadas, y entornos de prueba que sean de verdad representativos (no una base de 50 MB donde todo va rápido porque no hay nada).
En este paso, valida todo lo que puedas antes del cambio. Ensaya el script. Simula el rollback. Comprueba el rendimiento. Documenta las dependencias. Y si no tienes claro cómo validar algo, ya tienes un indicio de que el cambio es más peligroso de lo que parecía.
Durante el cambio: foco, trazabilidad y sangre fría
El momento del cambio no es para improvisar. Es para ejecutar con precisión quirúrgica. Nada de “ah, ya que estamos, meto esto también”. No. Eso no es una ventana de mantenimiento, eso es un ataque a la estabilidad del sistema.
Durante el cambio hay que asegurarse de que todo esté monitorizado. Logs activos, ejecución paso a paso si procede, y alguien siguiendo cada resultado. Si algo tarda más de lo esperado, se para, se revisa y se decide. No se reza, no se ignora. Se actúa.
La trazabilidad es crítica. Ejecuta los scripts con logging detallado. Si algo falla, hay que saber exactamente en qué punto estábamos. Nada de copiar/pegar desde un bloc de notas con modificaciones “on the fly”. Si hay que adaptar algo, se documenta, se explica y se versiona. Lo contrario es una receta para la amnesia operativa.
Y sobre todo, mantén la sangre fría. No importa lo mucho que presionen. Si algo no va bien, se detiene y se evalúa. Porque más vale un rollback a tiempo que una explicación al día siguiente con café y cara de insomnio.
Después del cambio: valida, comunica y documenta (sin convertirte en notario)
Una vez aplicado el cambio, viene la parte que más se salta: la validación post-despliegue. Porque claro, como no ha explotado nada, parece que ya hemos terminado. Error. Muchas veces, los efectos secundarios no se notan hasta que los jobs nocturnos empiezan a gritar.
Valida el sistema. Comprueba rendimiento, bloqueos, integridad. Ejecuta consultas clave. Mira los logs. Pregunta a los usuarios si todo responde como debería. Y si algo parece raro, investígalo. Porque si lo dejas pasar, mañana puede ser peor.
Después viene la documentación. No, no hace falta escribir una novela. Pero sí registrar qué cambió, por qué, cómo, cuándo, quién lo aprobó y qué efectos tuvo. ¿Es burocrático? Sí. ¿Es útil cuando en seis meses alguien pregunta qué demonios pasó ese día? También.
Y sobre todo, hazlo accesible. Nada de carpetas perdidas con nombres tipo “scripts_nuevos_OK_def_3_final.sql”. Usa sistemas de control de cambios, añade comentarios claros y deja constancia de las lecciones aprendidas. Documentar no es ser notario. Es dejar herramientas para no tropezar dos veces con el mismo script.
Y, por cierto, si todo fue bien… agradece al equipo, recoge feedback y ajusta el proceso. La gestión del cambio no es un evento. Es una práctica continua.
Cómo sobrevivir al “pero si solo era un índice”
La frase maldita. Todos la hemos oído. Y todos hemos visto lo que puede hacer un índice mal colocado: planes de ejecución destrozados, consultas que pasaban en milisegundos ahora eternas, deadlocks nuevos como setas. Porque no, un índice no es “solo” un índice. Es una reescritura de cómo el motor piensa. Y el motor, cuando se confunde, no avisa: simplemente arrastra al sistema al abismo.
¿Cómo se sobrevive a esto? Primero, aprendiendo a no confiar en los cambios “pequeños”. Segundo, aplicando buenas prácticas: revisando planes de ejecución, analizando estadísticas, usando INCLUDE, cuidando el orden de las columnas y verificando los efectos reales. Tercero, no dejando que nadie toque índices en producción sin una revisión decente. Da igual si es el desarrollador senior o el jefe de arquitectura. Todos cometemos errores.
Y por último, con monitorización y rollback. Si tras aplicar un índice todo empieza a ir peor, hay que poder volver atrás rápido. No hay gloria en mantener cambios dañinos solo porque “ya están puestos”. El ego no arregla el rendimiento.
Conclusión
Gestionar el cambio en producción no debería ser una ruleta rusa disfrazada de mejora. Exige preparación, criterio y procesos claros. Antes del cambio, duda y planifica. Durante el cambio, ejecuta con precisión. Después del cambio, valida y aprende.
Y si algo falla, no escondas el error. Documenta, comparte y ajusta. Porque los sistemas viven de la mejora continua, no del miedo al cambio. Eso sí: hagamos las cosas con cabeza. Con backups, con monitorización, y con la certeza de que cada “pequeño cambio” puede tener un impacto brutal.
Cambiar no tiene que doler. Pero si duele, al menos que haya ibuprofeno… y logs detallados.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
