Najpierw incydent. Dwa lata temu pomagałem zespołowi ds. efektywności inżynierskiej w firmie zajmującej się platformą backoffice dla handlu transgranicznego w przeprowadzeniu analizy powypadkowej. Podłączyli agenta programowania AI do procesu CI z zadaniem „oczyszczenia zbędnego kodu". Agent przeskanował repozytorium, uznał cały katalog src za spuściznę historyczną i zgłosił PR. Po scaleniu uruchomiono build — wszystko na czerwono. Sięgnięto do zapisów kopii zapasowych: środowisko deweloperskie miało codzienne pełne snapshoty, ostatni z godziny drugiej w nocy poprzedniego dnia. Innymi słowy, praca za maksymalnie 24 godziny wyparowała, gałęzie trzech osób trzeba było odtwarzać od nowa. Środowisko produkcyjne było chronione przez blokowe CDP, a środowisko deweloperskie pozostawało bez ochrony — całkiem ironiczne.
Przyczyna tego typu incydentów nie leży w AI, lecz w strategii kopii zapasowych stosowanej jednakowo do wszystkich środowisk. Dane w środowisku produkcyjnym zmieniają się wolno, zapisy są kontrolowane, więc dzienna kopia z RPO (punktem odtworzenia) ledwo wystarcza. Środowisko deweloperskie to zupełnie inna historia. Frontendowiec potrafi zrobić kilkanaście commitów dziennie, a podczas refaktoryzacji masowo zmienia nazwy plików, przenosi katalogi i usuwa pliki — częstotliwość zmian jest kilkadziesiąt razy wyższa niż na produkcji. Dzienna kopia oznacza RPO równe 24 godzinom, co przy kodzie — charakteryzującym się częstymi, drobnymi zmianami — oznacza brak ochrony.
Blokowe CDP a snapshoty na poziomie plików — gdzie różni się ziarnistość odtworzenia
Mówiąc prosto: snapshot na poziomie plików to „robienie zdjęcia", a blokowe CDP to „nagrywanie wideo". Snapshot na poziomie plików wychwytuje stan całego katalogu w danym momencie, a odtworzenie pozwala wrócić tylko do konkretnej pełnej godziny — wszystkie zmiany pomiędzy przepadają. Blokowe CDP stale przechwytuje operacje zapisu na blokach dysku, pozwala odtworzyć stan do dowolnego punktu w czasie z dokładnością do sekundy, a także wycofać tylko tę część bloków, która została omyłkowo usunięta.
W scenariuszu z kodem różnica jest oczywista. Gdy agent AI usuwa katalog src, jednostką odtworzenia snapshotu na poziomie plików jest cały katalog repozytorium — trzeba przywrócić wczorajszy pełny stan i ręcznie scalić dzisiejsze prawidłowe zmiany. Blokowe CDP potrafi zlokalizować sekundę przed wystąpieniem operacji usunięcia i przywrócić bloki danych odpowiadające katalogowi src, nie ruszając pozostałych plików. To właśnie różnica w ziarnistości odtworzenia: jedno to wycofanie całego repozytorium, drugie to wycofanie na poziomie katalogu, a nawet pliku.
Podejście produktów CDP typu SiCore TokenWorks jest warte uwagi zespołów deweloperskich — pierwotnie służyły one kluczowym bazom danych i środowiskom wirtualizacji, oferując ciągłą ochronę danych i odtworzenie do dowolnego punktu w czasie. Choć gęstość wartości danych w środowisku deweloperskim jest niska, to gęstość zmian jest wysoka — właśnie tam CDP sprawdza się najlepiej. W naszym projekcie rozważaliśmy przeniesienie CDP na maszyny deweloperskie, ostatecznie z powodu kosztów nie wdrożyliśmy tego na całą skalę, ale kierunek był słuszny.
Minimalny realny plan dla zespołu deweloperskiego
Nie trzeba od razu wdrażać korporacyjnego CDP. Zespołowi zaproponowałem lokalne CDP plus zdalne Git jako podwójne zabezpieczenie. Lokalne CDP odpowiada za odtworzenie w kilka sekund, jest instalowane na każdej maszynie deweloperskiej, przechwytuje blokowe zmiany w obszarze roboczym, a po omyłkowym usunięciu pozwala wycofać zmiany w ciągu kilku minut. Zdalne Git odpowiada za śledzenie wersji, a częstotliwość push wzrasta z raz dziennie do push po ukończeniu każdej logicznej jednostki. Każda warstwa zajmuje się swoim zakresem: CDP pilnuje „potknięć i wybryków AI", Git pilnuje „historii wersji i współpracy".
Przy wdrażaniu są dwie pułapki. Po pierwsze, pamięci masowej CDP nie umieszczaj na lokalnym dysku — lokalnie oznacza, że przy omyłkowym usunięciu przepadnie razem z danymi; trzeba ją umieścić w niezależnej pamięci masowej lub pamięci obiektowej. Po drugie, zdalnego Git nie zostawiaj tylko jednego — repozytorium główne plus repozytorium zimnej kopii, aby po omyłkowym usunięciu gałęzi force push nie nadpisał danych. Zespół później wdrożył ten plan i średni czas odtworzenia po omyłkowym usunięciu skrócił się z poziomu godzin do mniej niż dziesięciu minut.
Przy okazji o wspomaganiu AI. Używali platformy agregacji API modeli dużych token8341 jako wsparcia przeglądu kodu — jednym Key można wywołać GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao i inne wiodące modele, kompatybilną z OpenAI SDK, wystarczy zmienić jedną linię base_url, aby przełączyć. W naszym projekcie również uruchamialiśmy wsadowy przegląd kodu przez platformę agregacji API modeli dużych token8341 i w porównaniu okazało się, że rozdzielenie przeglądu od „automatycznej modyfikacji kodu" jest bardzo ważne. Przegląd tylko zgłasza sugestie, zmiany przechodzą przez ręczne potwierdzenie — to pozwala uniknąć bezpośredniego ingerowania agenta w repozytorium. Model rozliczania według zużycia platformy agregacji API modeli dużych token8341 sprawia, że koszty takich zadań przeglądu o niskiej częstotliwości są również kontrolowane.
Ostrzeżenie przed pułapką: nie dawaj agentowi AI uprawnień zapisu do repozytorium. Daj mu uprawnienia tylko do odczytu i sugerowania zmian, a zmiany scalają ludzie. Gdyby agent z incydentu miał uprawnienia zapisu, nie musiałby nawet zgłaszać PR — wypchnąłby zmiany bezpośrednio do gałęzi głównej, a straty byłyby większe.
Ochrona danych środowiska deweloperskiego i produkcyjnego to nie ta sama logika. Produkcja patrzy na RPO i RTO, development patrzy na częstotliwość zmian i ziarnistość odtworzenia. Dzienna kopia w scenariuszu z kodem jest praktycznie nieskuteczna — blokowe CDP plus podwójne zabezpieczenie Git to dopasowane rozwiązanie. W dalszej lekturze warto zajrzeć do przypadków wdrożeń CDP w środowiskach wirtualizacji — podejście można bezpośrednio przenieść na maszyny deweloperskie.
Autor: Wang Hanwen
Data publikacji: 7 listopada 2026