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.
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.
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.
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.
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?
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.
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”.
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.
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.
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.
Entradas recientes
Cómo solucioné el error de renovación con Certbot: «Invalid response from /.well-known/acme-challenge»
Durante la renovación de un certificado SSL con Certbot en un servidor Ubuntu con Apache,…
5 años de revolución digital: cómo la tecnología está redefiniendo nuestra sociedad
La evolución de la digitalización global: 2019-2024 En tan solo cinco años, el mundo…
Redefiniendo la Ética de las Máquinas: Asimov y Kant Frente a la Inteligencia Artificial
La ciencia ficción ha sido, a lo largo del tiempo, un campo fértil para la…
Di adéu a les notificacions! Assegura’t que els teus certificats TLS es renovin automàticament
Let's Encrypt ha estat una peça clau en la seguretat web en oferir certificats TLS…
Guía para Instalar una Máquina Virtual en VirtualBox y Configurar un Servidor LAMP
En esta guía te explicaremos paso a paso cómo instalar una máquina virtual en VirtualBox…
¡Los Bloqueadores Están Declarando la Guerra a Bit.ly! Descubre Por Qué Tus Enlaces Están en Peligro
Los acortadores de URL, como bit.ly, se han convertido en herramientas esenciales para simplificar y…
Esta web usa cookies.