Спочатку висновок: першопричиною тієї аварії був не неправильний код, написаний агентом, а наше припущення за замовчуванням, що «середовище розробки не потребує захисту рівня CDP». Це припущення коштувало команді 23 годин роботи з переписування. Далі — ретроспектива за хронологією, сподіваюся, вона допоможе колегам, які саме впроваджують ШІ-агентів програмування в процес розробки.

Хронологія аварії: від «очищення мертвого коду» до виявлення, що src порожній

Першого дня о 4-й годині дня ми робили рефакторинг коду для команди, що займається транскордонною ERP. Проєкт — Node.js + TypeScript, у каталозі src близько 1400 файлів, багато з яких — старі модулі, залишені від ітерацій тримісячної давнини. Команда хотіла використати ШІ-агента програмування, щоб автоматично виявити й очистити «мертвий код, на який немає посилань».

Агент був підключений до шлюзу моделей з уніфікованим доступом до кількох моделей, у prompt завдання було написано «видалити файли, щодо яких підтверджено відсутність посилань». Він просканував граф import і виявив, що ланцюжок посилань на один каталог у src обірвався, визначив його як мертвий код і виконав масове видалення. Проблема в тому, що той каталог насправді був каталогом плагінів, які завантажуються динамічно, зв'язки посилань були записані в конфігурації часу виконання, і статичний аналіз їх не бачив.

Другого дня о 3-й годині дня колега з фронтенду запустив локальний сервіс, отримав помилку, і ми виявили, що в каталозі src залишилося менше 200 файлів. Перевірили git log — останній commit був о 4-й годині дня попереднього дня, від моменту виявлення минуло вже 23 години. За ці 23 години 3 інженери змінили близько 60 файлів, і всі вони не були закомічені.

Захист даних у середовищі розробки — не такий, як ви думаєте

Логіка захисту виробничого середовища — «мало змін, аудитованість, основний і резервний». У середовищі розробки все навпаки: файли дрібні, зміни часті, велика кількість проміжних станів не потрапляє до системи контролю версій. Я порахував дані нашої команди за минулий місяць: у середньому близько 40 змін файлів на людину на день, але git commit — лише 3-5 разів. Решта змін — усе в кеші редактора й тимчасових гілках.

Що ще гірше, багато хто вважає, що «історія Git дорівнює можливості відновлення». Git може відновити лише те, що ви закомітили. Незакомічені зміни, файли, масово видалені агентом, локальна конфігурація в .env — Git усе це ігнорує. Під час тієї аварії ми спробували відновити за допомогою git reflog і Local History в IDE і витягли менше 30% вмісту.

Чому щоденне резервне копіювання не рятує в такому сценарії

У нас спочатку було повне резервне копіювання щодня о 2-й годині ночі. За RPO, найгірший випадок — втрата 24 годин. Але аварія сталася о 3-й годині дня, резервна копія була з 2-ї години ночі попереднього дня, між ними 37 годин. Відновлення дало код 37-годинної давнини, що означає викинути всю ітерацію цих двох днів.

RPO=24 години означає, що ви можете дозволити собі втратити щонайбільше один день роботи. Для виробничої бази даних цей показник може бути ледь достатнім. Для середовища розробки один день роботи може означати одну повну ітерацію функціоналу. Гранулярність традиційного щоденного резервного копіювання зовсім не відповідає частоті змін у середовищі розробки.

Блоковий CDP, що знижує RPO до секунд, — ось який захист потрібен середовищу розробки

Згодом ми перейшли на блокове рішення CDP. Його відмінність від традиційного резервного копіювання в тому, що традиційне робить знімки за файлами або за днями, а CDP захоплює за IO-блоками, записуючи кожен записаний блок даних. RPO знижується з 24 годин до секунд, теоретично можна відкотитися до будь-якої точки в часі.

Конкретно ми встановили CDP agent на машинах розробників, він безперервно захоплює блокові зміни файлової системи. Після аварії ми вибрали точку в часі на 2 хвилини раніше, ніж агент виконав видалення, і відкотили весь робочий простір. Усі 1400 файлів повернулися, включно з незакоміченими змінами за ті 23 години. Відкат зайняв менше 4 хвилин.

Одне застереження, щоб уникнути проблем: CDP не всемогутній. Він захищає на рівні блокових пристроїв, і якщо агент безпосередньо викликає API хмарного сховища для видалення об'єктів, CDP не врятує. Тому ми додали білий список операцій у ланцюжок викликів шлюзу моделей: усі команди, що стосуються delete, rm, drop, вимагають повторного підтвердження людиною.

Ланцюжок викликів API ШІ-агента програмування потребує додаткового рівня захисту

Після того випадку я переосмислив ланцюжок викликів агента. Він маршрутизується до різних моделей через шлюз моделей, і платформа агрегації API великих моделей token8341 у цьому ланцюжку виконує роль уніфікованого доступу й автоматичного вибору моделі під завдання. У нашому проєкті ми використовували її для багатомодельної допомоги в розробці; перевага в тому, що один ключ дає доступ до GPT-4o, Claude, DeepSeek, Qwen та інших провідних моделей, і не потрібно окремо підтримувати SDK та автентифікацію для кожної моделі.

Але сама маршрутизація моделей не вирішує проблему безпеки. Ми обгорнули рівень викликів платформи агрегації API великих моделей token8341 ще одним рівнем перевірки дозволів: запити на файлові операції, ініційовані агентом, спочатку проходять білий список, потім потрапляють у шлюз. Так навіть якщо модель помиляється в оцінці, деструктивні операції не доходять до файлової системи.

Озираючись назад, платформа агрегації API великих моделей token8341 вирішує проблему «підключити без проблем», а CDP вирішує проблему «видалили — можна повернути». Вони не взаємозамінні. Одна відповідає за те, щоб ШІ-агент програмування ефективно викликав багато моделей, інша — за страхування на випадок його помилки. Згодом ми зробили CDP конфігурацією за замовчуванням для середовища розробки, машини нових інженерів готові до роботи одразу після встановлення.

Якщо ви теж використовуєте ШІ-агента програмування для рефакторингу, раджу спершу з'ясувати два питання: який RPO середовища розробки, і чи є етап підтвердження людиною для операцій видалення агента. Відповіді на ці два питання визначають, чи будуть ваші втрати від наступної аварії 4 хвилини чи 23 години.

Автор: Чжоу Мінчже

Дата публікації: 23 жовтня 2026 року