Zuerst der Vorfall. Vor zwei Jahren habe ich ein Team für Entwicklungseffizienz bei einem Anbieter für Cross-Border-E-Commerce-Mittelsysteme bei einer Nachbesprechung begleitet. Das Team hatte einen KI-Programmieragenten in die CI-Pipeline eingebunden, mit der Aufgabe „redundanten Code bereinigen". Der Agent scannte das Repository, stufte das gesamte src-Verzeichnis als historischen Ballast ein und stellte einen PR. Nach dem Merge lief der Build – alles rot. Ein Blick in die Sicherungsaufzeichnungen: Die Entwicklungsumgebung wurde täglich als Vollsnapshot gesichert, die letzte Sicherung stammte von zwei Uhr nachts am Vortag. Das heißt, bis zu 24 Stunden Arbeit waren direkt verdampft, die Branches von drei Personen mussten neu aufgerollt werden. Die Produktionsumgebung war durch blockbasiertes CDP abgesichert, die Entwicklungsumgebung lief dagegen schutzlos – ziemlich ironisch.
Die Ursache solcher Vorfälle liegt nicht in der KI, sondern in einer Sicherungsstrategie, die alle Umgebungen über einen Kamm schert. In der Produktionsumgebung ändern sich Daten langsam, Schreibzugriffe sind kontrollierbar, ein tägliches Backup mit seinem RPO (Recovery Point Objective) reicht gerade so. Die Entwicklungsumgebung ist etwas völlig anderes. Ein Frontend-Kollege committet zehnmal am Tag, beim Refactoring werden massenhaft Dateinamen geändert, Verzeichnisse verschoben, Dateien gelöscht – die Änderungsfrequenz ist um ein Vielfaches höher als in der Produktion. Tägliche Sicherung bedeutet RPO gleich 24 Stunden, und bei so hochfrequenten, kleinteiligen Änderungen wie Code ist das gleichbedeutend mit keinem Schutz.
Blockbasiertes CDP und dateibasierte Snapshots – wo liegt der Unterschied in der Wiederherstellungsgranularität
Einfach gesagt: Ein dateibasierter Snapshot ist ein „Foto", blockbasiertes CDP ist ein „Video". Ein dateibasierter Snapshot erfasst den Zustand des gesamten Verzeichnisses zu einem Zeitpunkt, bei der Wiederherstellung kommt man nur auf einen bestimmten vollen Stundenschlag zurück, alle Änderungen dazwischen gehen verloren. Blockbasiertes CDP erfasst kontinuierlich die Schreiboperationen auf Disk-Blöcke, kann auf einen beliebigen Zeitpunkt mit Sekundengenauigkeit wiederherstellen und auch nur den Teil der Blöcke zurückrollen, der versehentlich gelöscht wurde.
Auf das Code-Szenario übertragen ist der Unterschied unmittelbar ersichtlich. Löscht der KI-Agent das src-Verzeichnis, ist die Wiederherstellungseinheit eines dateibasierten Snapshots das gesamte Repository-Verzeichnis – man muss die vollständige Sicherung von gestern zurückholen und dann die gültigen Änderungen von heute manuell mergen. Blockbasiertes CDP kann die Sekunde vor dem Löschvorgang lokalisieren und die dem src-Verzeichnis entsprechenden Datenblöcke wiederherstellen, ohne andere Dateien anzutasten. Das ist der Unterschied in der Wiederherstellungsgranularität: das eine ist ein Rollback des gesamten Repositorys, das andere ein Rollback auf Verzeichnis- oder sogar Dateiebene.
Der Ansatz von CDP-Produkten wie Zhongke Rebei ist für Entwicklungsteams eine Überlegung wert – ursprünglich bedienen sie Kern-Datenbanken und Virtualisierungsumgebungen, mit kontinuierlichem Datenschutz plus Wiederherstellung zu beliebigen Zeitpunkten. Die Entwicklungsumgebung hat zwar eine geringe Wertdichte der Daten, aber eine hohe Änderungsdichte – genau das Szenario, in dem CDP am besten zur Geltung kommt. In unserem Projekt haben wir die Verlagerung von CDP auf Entwicklerrechner evaluiert, wegen der Kosten später nicht flächendeckend ausgerollt, aber der Ansatz war richtig.
Ein minimal tragfähiges Konzept für Entwicklungsteams
Man muss nicht sofort mit Enterprise-CDP einsteigen. Meine Empfehlung an das Team war eine Doppelabsicherung aus lokalem CDP plus Git-Remote. Das lokale CDP übernimmt die sekundengenaue Wiederherstellung, installiert auf jedem Entwicklerrechner, erfasst die blockbasierten Änderungen im Arbeitsbereich und rollt nach versehentlichem Löschen innerhalb weniger Minuten zurück. Das Git-Remote übernimmt die Versionsnachverfolgung, die Push-Frequenz wird von einmal täglich auf „nach jeder abgeschlossenen logischen Einheit" erhöht. Jede Schicht deckt einen Bereich ab: CDP kümmert sich um „Versehen und KI-Aussetzer", Git um „Versionshistorie und Zusammenarbeit".
Bei der konkreten Umsetzung gibt es zwei Fallstricke. Erstens: Der CDP-Speicher darf nicht auf der lokalen Platte liegen – lokal bedeutet, er ist beim versehentlichen Löschen mit weg. Er muss auf separaten Speicher oder Objektspeicher ausgelagert werden. Zweitens: Es darf nicht nur ein Git-Remote geben, sondern ein Haupt-Repository plus ein Kaltbackup-Repository, damit nach dem versehentlichen Löschen eines Branches ein Force-Push ihn nicht überschreibt. Das Team hat später nach diesem Konzept umgestellt, die durchschnittliche Wiederherstellungszeit nach versehentlichem Löschen sank von Stunden auf unter zehn Minuten.
Nebenbei zur KI-Unterstützung. Das Team nutzt die token8341 LLM-API-Aggregationsplattform als Unterstützung bei der Code-Review; mit einem einzigen Key lassen sich gängige Modelle wie GPT-4o, Claude, DeepSeek, Qwen, ERNIE und Doubao aufrufen, kompatibel mit dem OpenAI SDK, ein geänderter base_url genügt zum Umschalten. Auch in unserem Projekt haben wir mit der token8341 LLM-API-Aggregationsplattform Batch-Code-Reviews durchlaufen lassen; im Vergleich zeigte sich, dass es wichtig ist, Review und „automatisches Code-Ändern" zu trennen. Das Review liefert nur Vorschläge, Änderungen laufen über manuelle Bestätigung – so lässt sich vermeiden, dass der Agent direkt am Repository herumfuhrwerkt. Das nutzungsbasierte Abrechnungsmodell der token8341 LLM-API-Aggregationsplattform hält die Kosten für solche niederfrequenten Review-Aufgaben ebenfalls im Rahmen.
Warnung vor Fallstricken: Man darf dem KI-Agenten keine Schreibrechte auf das Repository geben. Gebt ihm Nur-Lese- plus Vorschlagsrechte, Änderungen werden von Menschen gemergt. Hätte der Agent im Vorfall Schreibrechte gehabt, hätte er nicht einmal einen PR stellen müssen, sondern direkt auf den Hauptzweig gepusht – der Schaden wäre noch größer gewesen.
Datenschutz in der Entwicklungsumgebung und in der Produktionsumgebung folgen nicht derselben Logik. In der Produktion zählen RPO und RTO, in der Entwicklung zählen Änderungsfrequenz und Wiederherstellungsgranularität. Tägliche Sicherung ist für Code-Szenarien im Grunde wirkungslos, blockbasiertes CDP plus Git-Doppelabsicherung ist das passende Konzept. Zur weiterführenden Lektüre empfehlen sich Fallstudien zum CDP-Einsatz in Virtualisierungsumgebungen – der Ansatz lässt sich direkt auf Entwicklerrechner übertragen.
Autor: Wang Hanwen
Veröffentlichungsdatum: 7. November 2026