Recuperación ante fallos

Qué es

La recuperación ante fallos es historial de versiones más reversión instantánea para tu aplicación en producción. Cada cambio que haces se guarda como un punto de restauración, así que si una edición rompe algo, vuelves a la última versión que funcionaba con un solo clic. Lo que queda protegido es la aplicación en marcha sobre tu dominio, no solo un borrador en el editor.

Por qué importa

Un sistema de negocio está activo a todas horas —entran pedidos, los clientes inician sesión, se procesan pagos—, así que la caída provocada por un mal cambio cuesta dinero y confianza de verdad. Poder deshacer al instante significa que puedes seguir mejorando la aplicación sin apostar todo el negocio en cada edición. La seguridad es lo que hace que iterar sobre un sistema en marcha sea sensato.

Cómo funciona en ybuild

ybuild toma una instantánea de tu aplicación en cada cambio y conserva el historial completo detrás de la versión en marcha. Si algo se rompe, reviertes a un punto que sabías que funcionaba y tu dominio vuelve a servir la aplicación operativa en cuestión de segundos, sin copias de seguridad que restaurar a mano. Como ybuild aloja la aplicación, la recuperación es un clic, no un ticket de soporte.

Qué captura realmente un punto de restauración

Una reversión vale tanto como lo que guarda. La versión ingenua de "deshacer" conserva una copia del front-end y nada más, lo cual es inútil para una aplicación real, porque un sistema de negocio son cuatro cosas funcionando juntas: el front-end que ven tus clientes, la lógica de backend que procesa un pedido o una reserva, el esquema de base de datos que da forma a tus registros y las reglas de autenticación que deciden quién puede iniciar sesión. Revierte una de ellas sin las demás y obtienes el peor tipo de avería: una pantalla que carga bien pero que apunta a un backend que ya no coincide, lanzando errores justo en la acción que un cliente está intentando completar.

Por eso un punto de restauración de ybuild versiona toda la pila como una sola unidad. Cada vez que cambias la aplicación, la plataforma captura una instantánea coherente —front-end, backend, esquema y autenticación juntos—, de modo que la versión a la que reviertes es un sistema que de verdad funcionaba, no un conjunto de piezas descuadradas. Cuando restauras, ybuild no reconstruye nada desde cero; mantiene en pie la versión anterior que funcionaba y vuelve a apuntar tu dominio hacia ella. La recuperación es un cambio de puntero, y por eso se siente instantánea en lugar de tardar los minutos u horas de un redespliegue completo. Es la misma idea que usan las grandes plataformas en la nube cuando mantienen vivas dos versiones de una aplicación y revierten girando un balanceador de carga en lugar de volver a desplegar; ybuild simplemente lo hace de forma automática, en tu propio dominio, sin que tú configures nada.

Construir tu propio botón de deshacer frente a tenerlo en ybuild

Hacer esto por tu cuenta es un proyecto de ingeniería de verdad. La manera tradicional de hacer cambios en producción de forma segura implica etiquetar cada compilación en el control de versiones para poder identificar una que sepas que funciona, mantener un entorno de preproducción que imite la producción lo bastante bien como para confiar en él, adoptar un despliegue azul-verde o canary para que una reversión sea un cambio de configuración en vez de una carrera contrarreloj y —la parte que hunde a la gente sin hacer ruido— mantener los scripts de reversión de las migraciones de base de datos sincronizados con el código, además de copias de seguridad que de verdad hayas probado a restaurar. Una copia de seguridad que nunca has restaurado no es una copia de seguridad; es una suposición.

Hay un modo de fallo aún más desagradable por debajo de todo esto: la propia reversión puede fallar. Si un despliegue roto ya migró tu base de datos a una forma que el código antiguo no sabe leer, revertir solo el código te deja varado entre versiones. Hacer esto bien es exactamente lo que separa a los equipos fuertes de los débiles. La investigación DORA de Google, la medida más citada de la industria sobre la entrega de software, halla que los equipos de élite se recuperan de un fallo en producción en menos de una hora, mientras que los de bajo rendimiento tardan mucho más, y que los equipos más rápidos son también los más estables, no los más imprudentes. La pega es el coste: a medida que los objetivos de recuperación se vuelven más exigentes, la infraestructura para alcanzarlos suele encarecerse, y por eso las configuraciones serias de recuperación continua han estado históricamente fuera del alcance de un fundador en solitario o de un pequeño negocio.

En ybuild nada de eso es tuyo, ni para construirlo ni para pagarlo aparte. La plataforma versiona toda la pila en cada cambio, mantiene calientes las versiones anteriores que funcionaban para que una reversión sea un cambio de puntero en lugar de una reconstrucción, y expone todo ello como un único clic. Obtienes un comportamiento de recuperación de nivel élite sobre la aplicación que describiste en lenguaje corriente —funcionando en ybuild, servida en tu propio dominio— sin montar entornos de preproducción, escribir reversiones de migraciones ni probar copias de seguridad a mano.

Los casos límite y qué significan para un negocio en marcha

Las preguntas que más importan son las que tratan sobre tus datos. Cuando reviertes una función rota, ¿qué pasa con los pedidos que entraron mientras estaba rota? La respuesta correcta, y aquella para la que ybuild está hecho, es que una reversión devuelve la lógica y la estructura de la aplicación a una versión que funcionaba mientras los registros en vivo de tu base de datos gestionada siguen acumulándose, de modo que deshacer una mala edición arregla la aplicación sin borrar los clientes, las reservas o los pagos que llegaron mientras tanto. Esa distinción lo es todo: estás revirtiendo la aplicación, no borrando el negocio.

Vale la pena saber dónde se detienen las copias de seguridad corrientes, porque explica por qué el historial de versiones es una herramienta distinta. Atlassian, que opera productos en la nube para empresas enormes, afirma sin rodeos que sus copias de seguridad de infraestructura no se usan para revertir cambios destructivos iniciados por el cliente —un script que sobrescribe, un proyecto borrado— y que sus objetivos de recuperación apuntan a caídas imprevistas, no a tus propios errores. Dicho de otro modo, una copia de seguridad de infraestructura protege el centro de datos; no te da un deshacer limpio para un cambio que hiciste a propósito y resultó estar mal. Ese deshacer es exactamente lo que ofrece un punto de restauración por cada cambio, y por eso ybuild conserva un historial de versiones etiquetado que puedes recorrer para encontrar el último punto bueno en vez de adivinar una marca de tiempo.

Para un negocio en marcha, esto se entiende mejor con los dos términos que usa la planificación de recuperación ante desastres: cuánto tiempo puedes estar caído (tu tiempo de recuperación) y cuánto puedes permitirte perder (tu punto de recuperación). En una aplicación de reservas o de pago, eso no son abstracciones: cada minuto sin conexión es ingreso que se va y confianza que se erosiona en tiempo real. La reversión instantánea de un clic empuja ambas cifras hacia cero. Pero la recompensa más profunda es de comportamiento. Cuando deshacer es realmente instantáneo, dejas de tener miedo de tocar la aplicación. Publicas la mejora, pruebas el campo nuevo, cambias el flujo, porque el coste de equivocarte es un clic, no un fin de semana perdido. Un negocio cuyo dueño no tiene miedo de mejorarlo es un negocio que sigue mejorando, y eso es lo que de verdad te compra una red de seguridad real bajo un sistema en marcha en tu propio dominio.

Preguntas frecuentes

Si revierto, ¿pierdo los pedidos y los clientes que entraron desde entonces?

No. Una reversión devuelve la lógica y la estructura de tu aplicación a la última versión que funcionaba, mientras los registros en vivo de tu base de datos gestionada siguen acumulándose. Deshacer una función rota arregla la aplicación sin borrar los pedidos, las reservas o los pagos que llegaron mientras estaba rota.

¿Hasta cuándo puedo retroceder?

ybuild conserva el historial de versiones completo de tu aplicación detrás de la versión en marcha, así que puedes restaurar cualquier punto de restauración anterior que funcionara, no solo el más reciente. Cada cambio es su propio punto etiquetado, de modo que puedes encontrar el último momento bueno exacto en vez de adivinar una marca de tiempo.

¿Qué tan rápida es la recuperación? ¿Lo notarán siquiera los clientes?

Es casi instantánea. ybuild mantiene caliente la versión anterior que funcionaba y revierte apuntando tu dominio hacia ella, así que es un cambio de puntero y no una reconstrucción. Tu sitio vuelve a servir la aplicación operativa en cuestión de segundos, en lugar de los minutos u horas que llevaría un redespliegue manual o la restauración de una copia de seguridad.

¿No es esto simplemente una copia de seguridad?

Está relacionado, pero es más potente. Las copias de seguridad protegen tus datos; el historial de versiones más la reversión protegen toda la aplicación: front-end, backend, esquema y autenticación juntos. Incluso las grandes plataformas señalan que las copias de seguridad de infraestructura no deshacen un cambio que hiciste a propósito y resultó estar mal. Los puntos de restauración por cada cambio de ybuild están hechos exactamente para ese deshacer.

¿Puedo deshacer un solo mal cambio sin tirar todo lo demás?

Sí. Como ybuild guarda un punto de restauración en cada cambio, reviertes al último punto que sabías que funcionaba y no a alguna versión lejana. Te recuperas justo hasta el momento anterior a que las cosas se rompieran, conservando todo el buen trabajo que vino antes.