Por qué no debes aplicar cambios los viernes (ni justo antes de vacaciones, ni al terminar la jornada)



Lecciones reales para desarrolladores y mantenedores que quieren dormir tranquilos


Introducción

Los filósofos dicen que no se puede predecir el futuro.
Los programadores decimos: “mejor no tocar nada en viernes”.

Y no es miedo irracional. Es experiencia. Porque si algo ha quedado claro en el mundo de la ingeniería de software, es que ciertos momentos están malditos para hacer cambios en producción.
Sí, ya sabes cuáles: viernes por la tarde, justo antes de las vacaciones, al cerrar el sprint, con la mochila ya al hombro.

Este post es un homenaje a esas decisiones impulsivas que acabaron en caos, con ejemplos reales que demuestran que aplicar cambios en el momento equivocado es una tradición milenaria del desastre digital.

Aquí tienes 10 razones para dejar ese deploy para otro día… con sus respectivos recordatorios históricos.


1. El viernes por la tarde

La semana ha sido larga. El cerebro pide cerrar todo. Y justo ahí, decides hacer un pequeño cambio.
Error clásico.

💥 Caso real: Knight Capital (2012)
Actualización parcial en sus sistemas de trading. Algunas máquinas ejecutaban código viejo. Resultado: compras y ventas erráticas en bucle durante 45 minutos.
Pérdida: $440 millones. Fin de la empresa.


2. Justo antes de irte del trabajo

“Hago esto rápido y me voy”.
No lo harás. Vas a quedarte. Y vas a sufrir.

💥 Caso real: GitLab (2017)
Un admin intentó arreglar una réplica antes de irse. Ejecutó mal un comando de limpieza:
borró la base de datos de producción.
18 horas de restauración, sin backups útiles.


3. Antes de vacaciones

El instinto de dejar “todo listo” es comprensible. Pero lo que dejas puede explotar mientras tú estás en modo avión.

💥 Caso real: Slack (2021)
Un cambio mal ejecutado justo antes de fin de año causó un problema con su DNS interno. Resultado: caída general de Slack el 4 de enero.
Bienvenido al año nuevo.


4. Antes de un puente o festivo largo

Si algo sale mal, ¿quién estará para solucionarlo? Spoiler: nadie.

💥 Caso real: OVH (2021)
Cambios en el sistema de alimentación se hicieron antes de festivo. Incendio en el datacenter.
No fue solo mala suerte. Fue timing desastroso.


5. Cuando el equipo de soporte no está

Aplicar cambios sin red de seguridad es jugar a ser héroe. Pero nadie aplaude cuando todo cae.

💥 Caso real: Facebook (2021)
Un cambio en el sistema de BGP dejó a Facebook, WhatsApp e Instagram fuera de internet.
Lo peor: nadie podía acceder físicamente a los servidores para arreglarlo.


6. Cuando estás cansado

Los errores tontos florecen cuando estás agotado.
¿Seguro que esa línea no borra más de lo que debería?

💥 Caso real: Amazon S3 (2017)
Un ingeniero cansado ejecutó un script de mantenimiento y eliminó un sistema crítico.
Caída masiva de servicios, dashboards y aplicaciones.
Hasta el panel de estado dejó de funcionar.


7. Sin rollback o backup

Cambiar sin poder volver atrás es como saltar sin paracaídas. Pero con logs.

💥 Caso real: Pixar (Toy Story 2)
Un comando mal lanzado borró casi toda la película. ¿Backups? No funcionaban.
Se salvó porque una directora tenía una copia local para trabajar desde casa.


8. Sin revisión ni segunda opinión

El “yo lo reviso luego” es el primer paso hacia el “quién rompió esto”.

💥 Caso real: Equifax (2017)
Un parche crítico no se aplicó porque se omitió la revisión. Resultado: robo de datos de 147 millones de personas.
Costó millones… y reputación.


9. Subestimando el cambio

No hay cambios “menores” en producción. Solo sorpresas mayores.

💥 Caso real: Azure DevOps (2019)
Un pequeño cambio en la CDN provocó fallos en la distribución global. Se cayeron pipelines, builds y accesos.
Días después, aún descubrían efectos colaterales.


10. Por tachar un ticket antes del finde

Ese impulso de cerrar tareas puede más que la lógica. Y entonces… boom.

💥 Caso real: todos los desarrolladores, en algún momento
Cambio menor, último commit del día, todo parece bien… hasta que empieza a fallar el login de usuarios, o los datos aparecen cruzados.


Conclusión: el empirismo salva vidas (y servidores)

Como dijo Hume, no podemos predecir el futuro. Pero si todos los viernes terminas con un incidente, quizás, solo quizás, debas dejar de hacer deploy los viernes.

Elige bien tus batallas. Cambia en horario laboral, con café, con equipo, con rollback.
El resto del tiempo, no es ingeniería. Es ruleta rusa digital.


Autor: Óscar Lastera Sánchez, y su fiel ayudante que nunca duerme (ni hace deploys en viernes): ChatGPT.