DEV Community: Pedro J. Manrique

La copia de seguridad funcionaba; la restauración no

Pedro J. Manrique — Mon, 26 Oct 2026 08:45:35 +0000

Ver un archivo nuevo cada noche da mucha tranquilidad, hasta que hay que recuperar algo.

Imaginad un servicio que guarda copias de su base de datos a las 2:00. El panel muestra treinta días de ejecuciones correctas. Un martes a las 9:14 alguien borra por error una tabla de pedidos. El equipo descarga la copia del día anterior y descubre dos problemas: la clave para descifrarla pertenece a una cuenta desactivada y el procedimiento de restauración presupone una versión del programa que ya no usan. A las 11:00 sigue habiendo copias. No hay servicio recuperado.

La tarea automática había terminado bien. La capacidad de volver a funcionar nunca se había comprobado.

Yo haría una restauración periódica en un entorno aislado, mediría cuánto tarda y verificaría algunos datos reales del resultado. También dejaría la clave accesible para un segundo responsable. La métrica importante no es cuántas copias existen, sino si alguien puede recuperar el servicio dentro del tiempo prometido.

En reglasnoescritas.com se habla mucho de estos temas, no de una forma superficial, sino en profundidad y aportando conocimiento real aplicable. Emails cortos, de un tema diferente cada día, de esos que dices -esto me suena XD-

¿Cuándo fue la última vez que probasteis una restauración completa y no solo que el backup terminó en verde?

La cola procesaba pedidos. Nadie miraba los que no salían

Pedro J. Manrique — Sat, 24 Oct 2026 13:03:24 +0000

Un sistema puede enseñar actividad constante mientras acumula trabajo detenido.

Imaginad una tienda que mueve la confirmación de pedidos a una cola. El panel muestra cientos de mensajes procesados cada hora. El viernes a las 16:42 un formato inesperado hace fallar una tarea. Tras varios reintentos, el mensaje acaba en la cola de errores. El resto sigue funcionando y todas las gráficas de actividad están verdes. El lunes hay catorce clientes con el pago confirmado y sin correo de pedido.

El equipo había decidido vigilar cuántos mensajes entraban y salían. Nadie había acordado quién revisaría los fallidos, cuánto tiempo podían esperar ni cómo devolverlos al flujo después de corregir la causa.

Yo pondría una alerta por antigüedad y número de mensajes en la cola de errores, una persona responsable y un procedimiento de reenvío seguro. También comprobaría que repetir una tarea no duplica el pedido. Una cola no elimina las excepciones: solo las guarda en otro sitio hasta que alguien se hace cargo.

¿Qué métrica os dio tranquilidad mientras el problema real crecía fuera del panel principal?

El despliegue pasó todas las pruebas y falló al primer cliente

Pedro J. Manrique — Wed, 21 Oct 2026 08:11:19 +0000

Un cambio puede funcionar perfectamente en pruebas y fallar en el primer minuto de trabajo real.

Imaginad un equipo que despliega una nueva API un viernes a las 18:10. El entorno de pruebas devuelve 200 en todas las rutas. El lunes, a las 9:04, el primer cliente intenta confirmar un pedido y recibe un 403. Otros clientes pueden consultar el catálogo, así que durante unos minutos parece un problema aislado. A las 9:19 ya hay once pedidos pendientes.

La ruta funcionaba. Lo que faltaba era un permiso que el usuario de pruebas tenía desde hacía meses y las cuentas reales no. Nadie había escrito esa condición en el cambio ni la había incluido en la lista de comprobación.

Yo probaría el flujo de extremo a extremo con una cuenta del tipo que lo usará después del despliegue. También dejaría anotados los permisos, las dependencias y el camino de vuelta si algo falla. Que una respuesta sea 200 en un entorno cómodo no significa que el trabajo del cliente pueda completarse.

¿Qué condición invisible os ha roto alguna vez un despliegue que parecía aprobado?

El test pasó porque nadie probó el camino de vuelta

Pedro J. Manrique — Mon, 19 Oct 2026 08:50:35 +0000

El botón funcionaba. El problema empezaba después.

Imaginad una aplicación en la que un usuario cambia su correo. El equipo prueba que el formulario guarda el nuevo valor y muestra un aviso verde. A las 17:28 del viernes se despliega. El lunes llegan las primeras incidencias: el enlace de confirmación se envió al correo antiguo, al que varios usuarios ya no tienen acceso. El cambio se guardó, pero nadie puede terminarlo.

La prueba cubrió la acción visible. No cubrió cómo se recupera una persona cuando el flujo falla a mitad.

Antes de marcar una historia como terminada, preguntaría tres cosas: qué pasa si se interrumpe, cómo vuelve el usuario al estado anterior y quién puede resolverlo sin tocar la base de datos. Esas respuestas pertenecen al alcance del desarrollo, aunque no aparezcan en la pantalla principal.

¿Qué camino de recuperación habéis descubierto demasiado tarde en producción?

El endpoint devolvía 200 y nadie podía terminar la compra

Pedro J. Manrique — Fri, 16 Oct 2026 10:47:04 +0000

Un despliegue puede pasar todas las comprobaciones y fallar donde más importa.

Imaginad una tienda con un checkout nuevo. El jueves a las 18:40, CI termina en verde. Los tests cubren el endpoint de pago: petición válida, respuesta 200 y registro creado. El equipo cierra la tarea.

El viernes a las 9:12 llegan las primeras quejas. En escritorio, la compra funciona. En un móvil con pantalla pequeña, el botón final queda tapado por el aviso de cookies. Quien no había aceptado ese aviso no puede pulsar «Pagar». El servidor responde perfectamente a una petición que muchos usuarios nunca consiguen enviar.

A las 10:05 soporte tiene siete tickets y desarrollo sigue viendo una API sana. El dato que faltaba no estaba en la monitorización del backend: era la diferencia entre «el servicio responde» y «una persona completa la operación».

Para una función crítica, el criterio de aceptación debería incluir al menos un recorrido real desde la pantalla que usa el cliente, en los tamaños y estados más comunes. También conviene medir intentos iniciados frente a operaciones terminadas, no solo errores HTTP.

¿Qué comprobación os ha descubierto más fallos así: un test end to end, una sesión con usuarios o comparar el embudo antes y después del despliegue?

El despliegue salió bien hasta que alguien pidió repetirlo

Pedro J. Manrique — Thu, 15 Oct 2026 12:41:15 +0000

Un jueves a las 18:14 el equipo publica una versión sin errores. Las pruebas pasan, la web responde y el cliente felicita a quien hizo el despliegue. El viernes hay que repetirlo en otro entorno. Esa persona no está.

El comando está en el historial de su terminal. La variable que activó una función se añadió a mano. La cuenta que tiene permiso para publicar pertenece a alguien que ya cambió de proyecto. Nadie sabe si repetir exactamente los pasos sería seguro.

El problema no es que falte documentación perfecta. Es que una operación crítica quedó reducida a la memoria de una persona.

Un registro útil puede ser breve: versión exacta, requisitos previos, variables necesarias, quién autoriza, pasos para comprobar el resultado y cómo volver atrás. Si otra persona puede seguirlo sin llamar al autor, el despliegue deja de ser un truco personal y se convierte en una capacidad del equipo.

¿Qué dato suele faltar en vuestros procedimientos justo cuando toca intervenir de verdad?