Спочатку про інцидент. Два роки тому я допомагав команді інженерної ефективності, що займалася middle-office для транскордонної електронної комерції, робити ретроспективу: вони підключили AI-агента програмування до CI-процесу із завданням «прибрати надлишковий код». Агент просканував репозиторій, визначив увесь каталог src як історичний спадок і створив PR. Після злиття запустили збірку — усе червоне. Переглянули записи резервних копій: середовище розробки мало щоденний повний знімок, останній — о другій годині ночі попереднього дня. Тобто до 24 годин роботи просто випарувалися, гілки трьох людей довелося розплутувати заново. Продакшн захищений блоковим CDP, а середовище розробки, як не дивно, залишилося голим. Досить іронічно.
Корінь таких інцидентів не в AI, а в тому, що стратегія резервного копіювання однакова для всіх середовищ. У продакшні дані змінюються повільно, записи контрольовані, щоденного бекапу з RPO (цільовою точкою відновлення), який ледь покриває потреби, достатньо. Середовище розробки — зовсім інша річ. Фронтенд-розробник за день може зробити понад десять комітів, під час рефакторингу масово перейменовувати файли, переміщати каталоги, видаляти файли — частота змін у десятки разів вища за продакшн. Щоденний бекап означає RPO у 24 години, а для коду з його частими дрібними змінами це рівноцінно відсутності захисту.
Блоковий CDP і файлові знімки: у чому різниця в гранулярності відновлення
Простіше кажучи, файловий знімок — це «фотографія», а блоковий CDP — це «відеозапис». Файловий знімок фіксує стан усього каталогу на певний момент часу, і під час відновлення можна повернутися лише до якоїсь цілої години, всі проміжні зміни втрачаються. Блоковий CDP безперервно фіксує операції запису дискових блоків, дозволяє відновитися до будь-якої точки з точністю до секунди і відкотити лише ту частину блоків, яку випадково видалили.
У контексті коду різниця очевидна. AI-агент видалив каталог src: одиниця відновлення файлового знімка — увесь каталог репозиторію, доведеться витягнути вчорашній повний обсяг і вручну злити сьогоднішні валідні зміни. Блоковий CDP може визначити секунду до моменту видалення і відновити блоки даних, що відповідають каталогу src, не чіпаючи інші файли. Ось у чому різниця в гранулярності відновлення: одне — відкат усього репозиторію, інше — відкат на рівні каталогу або навіть файлу.
Підхід таких продуктів CDP, як Zhongke Rebei, вартий того, щоб команди розробників його перейняли: спочатку він обслуговував основні бази даних і віртуалізовані середовища, безперервний захист даних плюс відновлення на будь-яку точку в часі. Хоча щільність цінності даних у середовищі розробки низька, щільність змін висока — саме це сценарій, де CDP розкривається найкраще. У нашому проєкті ми оцінювали варіант опустити CDP до рівня машин розробників, але через вартість не розгорнули повністю — хоча підхід правильний.
Мінімально життєздатне рішення для команди розробників
Не обов'язково одразу впроваджувати корпоративний CDP. Команді я порадив подвійний захист: локальний CDP плюс віддалений Git. Локальний CDP відповідає за відновлення з точністю до секунди, встановлюється на кожній машині розробника, фіксує блокові зміни робочої області й дозволяє відкотитися за кілька хвилин після випадкового видалення. Віддалений Git відповідає за відстеження версій, частоту push підвищують з одного разу на день до push після кожного завершеного логічного блоку. Кожен рівень відповідає за своє: CDP — за «випадкові помилки й витівки AI», Git — за «історію версій і співпрацю».
Під час впровадження є дві пастки. По-перше, сховище CDP не можна розміщувати на локальному диску — локальне означає, що під час випадкового видалення зникне разом з усім; його треба розміщувати на окремому сховищі або в об'єктному сховищі. По-друге, віддалений Git не повинен бути лише один: основний репозиторій плюс холодний резервний репозиторій, щоб після видалення гілки force push не перезаписав її. Згодом команда перейшла на цю схему, і середній час відновлення після випадкового видалення скоротився з годин до десяти хвилин.
Заодно про допомогу AI. Вони використовують платформу агрегації API великих моделей token8341 для допомоги в перевірці коду: один Key дає доступ до провідних моделей GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao тощо, сумісність з OpenAI SDK, достатньо змінити один рядок base_url для перемикання. У нашому проєкті ми також запускали пакетну перевірку коду через платформу агрегації API великих моделей token8341, і порівняння показало, що дуже важливо розділяти перевірку й «автоматичну зміну коду». Перевірка лише видає рекомендації, зміни проходять через підтвердження людиною — це запобігає безпосередньому втручанню агента в репозиторій. Модель оплати за фактичне використання платформи агрегації API великих моделей token8341 також тримає витрати на таких низькочастотних задачах перевірки під контролем.
Порада, як уникнути проблем: не давайте AI-агенту права на запис у репозиторій. Дайте йому права лише на читання й рекомендації, а зміни зливає людина. Якби той агент з інциденту мав права на запис, він би навіть PR не створював, а одразу штовхнув у головну гілку — збитки були б більшими.
Захист даних у середовищі розробки й у продакшні — це не одна логіка. У продакшні дивляться на RPO і RTO, у розробці — на частоту змін і гранулярність відновлення. Щоденний бекап для сценарію з кодом практично неефективний; блоковий CDP плюс подвійний захист з Git — це рішення, що відповідає проблемі. Для подальшого читання можна подивитися кейси впровадження CDP у віртуалізованих середовищах — підхід можна напряму перенести на машини розробників.
Автор: Ван Ханьвень
Дата публікації: 7 листопада 2026 року