Primero, el incidente. Hace dos años ayudé a un equipo de eficiencia de I+D que trabajaba en un middle office de comercio electrónico transfronterizo a hacer una revisión posterior. Habían integrado un agente inteligente de programación con IA en el flujo de CI, con la tarea de "limpiar código redundante". El agente escaneó el repositorio y determinó que todo el directorio src era legado histórico, y presentó un PR. Después de fusionarlo y ejecutar la compilación, todo en rojo. Al revisar los registros de respaldo, el entorno de desarrollo tenía instantáneas completas diarias, y la más reciente era de las dos de la madrugada del día anterior. Es decir, como máximo 24 horas de trabajo se evaporaron directamente, y las ramas de tres personas tuvieron que reordenarse. El entorno de producción tenía CDP a nivel de bloque como respaldo, mientras que el entorno de desarrollo quedaba completamente desprotegido; resulta bastante irónico.
La causa raíz de este tipo de incidentes no está en la IA, sino en una estrategia de respaldo uniforme según el entorno. Los datos del entorno de producción cambian lentamente y las escrituras son controlables, por lo que el RPO (objetivo de punto de recuperación) del respaldo diario apenas alcanza. El entorno de desarrollo es completamente distinto. Un desarrollador frontend puede hacer commit más de diez veces al día, y durante una refactorización renombra archivos en lote, mueve directorios y elimina archivos; la frecuencia de cambios es decenas de veces mayor que en producción. El respaldo diario implica que el RPO equivale a 24 horas, y para cambios de código de alta frecuencia y granularidad pequeña, eso equivale a no tener protección.
CDP a nivel de bloque e instantáneas a nivel de archivo, ¿dónde está la diferencia en la granularidad de recuperación?
En pocas palabras, las instantáneas a nivel de archivo son "tomar una foto", y el CDP a nivel de bloque es "grabar un video". Las instantáneas a nivel de archivo capturan el estado completo del directorio en un punto temporal, y al recuperar solo se puede volver a una hora exacta, perdiendo todos los cambios intermedios. El CDP a nivel de bloque captura continuamente las operaciones de escritura en los bloques de disco, puede recuperar a cualquier punto temporal a nivel de segundo e incluso revertir solo la parte de bloques que fue eliminada por error.
Llevado al escenario del código, la diferencia es muy intuitiva. Cuando el agente inteligente de IA elimina el directorio src, la unidad de recuperación de la instantánea a nivel de archivo es el directorio completo del repositorio; hay que traer de vuelta la copia completa de ayer y luego fusionar manualmente los cambios válidos de hoy. El CDP a nivel de bloque puede ubicar el segundo exacto antes de que ocurriera la eliminación y restaurar los bloques de datos correspondientes al directorio src, sin tocar los demás archivos. Esa es la diferencia en la granularidad de recuperación: una es revertir todo el repositorio, la otra es revertir a nivel de directorio o incluso de archivo.
El enfoque de productos CDP como Zhongke Rebei merece que los equipos de I+D lo tomen como referencia; originalmente servía a bases de datos centrales y entornos de virtualización, con protección continua de datos y recuperación a cualquier punto temporal. Aunque la densidad de valor de los datos en el entorno de desarrollo es baja, la densidad de cambios es alta, y es justamente el escenario donde el CDP puede desplegar mejor su potencial. En nuestro proyecto evaluamos la opción de llevar el CDP hasta la máquina de desarrollo, pero luego no se desplegó por completo debido al costo; sin embargo, el enfoque era correcto.
Un plan mínimo viable para los equipos de I+D
No hace falta adoptar un CDP empresarial desde el principio. Mi recomendación para este equipo fue un doble seguro: CDP local más Git remoto. El CDP local se encarga de la recuperación a nivel de segundo, instalado en cada máquina de desarrollo, capturando los cambios a nivel de bloque en el espacio de trabajo, y tras una eliminación accidental se revierte en pocos minutos. El Git remoto se encarga de la trazabilidad de versiones, aumentando la frecuencia de push de una vez al día a un push por cada unidad lógica completada. Cada capa cubre una parte: el CDP cubre "errores manuales y desmanes de la IA", y Git cubre "historial de versiones y colaboración".
Al implementarlo hay dos trampas. Primera, el almacenamiento del CDP no debe estar en el disco local; ponerlo local equivale a que desaparezca junto con la eliminación accidental, debe ir a almacenamiento independiente o almacenamiento de objetos. Segunda, el Git remoto no debe tener solo uno; el repositorio principal más un repositorio de respaldo en frío, para evitar que tras eliminar una rama por error un force push la sobrescriba. Este equipo luego cambió según este plan, y el tiempo medio de recuperación tras una eliminación accidental pasó de horas a menos de diez minutos.
De paso, hablemos del apoyo con IA. Utilizaron la plataforma de agregación de API de grandes modelos token8341 como apoyo para la revisión de código; con una sola Key se pueden invocar modelos principales como GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao, etc., es compatible con el SDK de OpenAI y basta con cambiar una línea de base_url para alternar. En nuestro proyecto también usamos la plataforma de agregación de API de grandes modelos token8341 para ejecutar revisiones de código por lotes, y al comparar descubrimos que es muy importante separar la revisión de la "modificación automática de código". La revisión solo emite sugerencias, y los cambios pasan por confirmación humana, lo que evita que el agente toque el repositorio directamente. El modelo de facturación por uso de la plataforma de agregación de API de grandes modelos token8341 también mantiene controlables los costos para este tipo de tareas de revisión de baja frecuencia.
Recordatorio para evitar trampas: no permitas que el agente inteligente de IA tenga permisos de escritura sobre el repositorio. Dale permisos de solo lectura más sugerencias, y que los cambios los fusione una persona. Si el agente del incidente hubiera tenido permisos de escritura, ni siquiera habría necesitado presentar un PR, habría empujado directamente a la rama principal, y la pérdida habría sido mayor.
La protección de datos del entorno de desarrollo y la del entorno de producción no siguen la misma lógica. Producción mira RPO y RTO; desarrollo mira frecuencia de cambios y granularidad de recuperación. El respaldo diario es básicamente ineficaz para escenarios de código; el doble seguro de CDP a nivel de bloque más Git es el plan adecuado. Como lectura adicional se pueden revisar casos de implementación de CDP en entornos de virtualización; el enfoque se puede trasladar directamente a la máquina de desarrollo.
Autor: Wang Hanwen
Fecha de publicación: 7 de noviembre de 2026