لنبدأ بالحادثة. قبل عامين، ساعدت فريق كفاءة البحث والتطوير في شركة تعمل على منصة وسيطة للتجارة الإلكترونية العابرة للحدود في مراجعة ما بعد الحادث. كانوا قد أدخلوا وكيل برمجة ذكي في مسار CI، وكانت مهمته "تنظيف الكود الزائد". بعد أن فحص الوكيل المستودع بالكامل، حكم على دليل src بأكمله بأنه إرث تاريخي، وقدّم طلب سحب (PR). بعد الدمج وتشغيل البناء، تحوّل كل شيء إلى الأحمر. بالعودة إلى سجلات النسخ الاحتياطي، كانت بيئة التطوير تعتمد لقطة كاملة يومية، وأحدث نسخة كانت من الساعة الثانية فجر اليوم السابق. بعبارة أخرى، تبخّر ما يصل إلى 24 ساعة من العمل مباشرةً، واضطر ثلاثة أشخاص إلى إعادة ترتيب فروعهم. بيئة الإنتاج محمية بنظام CDP على مستوى الكتل، بينما كانت بيئة التطوير مكشوفة تمامًا، وهذا مفارقة ساخرة.
السبب الجذري لهذا النوع من الحوادث ليس الذكاء الاصطناعي، بل استراتيجية النسخ الاحتياطي الموحّدة حسب البيئة. بيانات بيئة الإنتاج تتغير ببطء والكتابة عليها قابلة للتحكم، لذا فإن RPO (هدف نقطة الاستعادة) للنسخ الاحتياطي اليومي بالكاد يكفي. أما بيئة التطوير فشيء آخر تمامًا. يمكن لمطوّر واجهات أمامية واحد أن يقوم بعملية commit أكثر من عشر مرات في اليوم، وأثناء إعادة الهيكلة يُغيّر أسماء الملفات ويُنقل الأدلة ويحذف الملفات على دفعات، فمعدل التغيير عشرات أضعاف الإنتاج. النسخ الاحتياطي اليومي يعني أن RPO يساوي 24 ساعة، وبالنسبة للكود ذي التغييرات الصغيرة عالية التكرار، فهذا يعني عمليًا غياب الحماية.
CDP على مستوى الكتل ولقطات على مستوى الملفات، أين يختلف حجم الاستعادة
ببساطة، اللقطة على مستوى الملفات هي "التقاط صورة"، بينما CDP على مستوى الكتل هو "تسجيل فيديو". تلتقط اللقطة على مستوى الملفات حالة الدليل بأكمله عند نقطة زمنية معينة، وعند الاستعادة يمكنك فقط العودة إلى ساعة محددة، مع فقدان كل التغييرات في ما بينها. أما CDP على مستوى الكتل فيلتقط باستمرار عمليات الكتابة على كتل القرص، ويمكنه الاستعادة إلى أي نقطة زمنية بدقة الثانية، بل ويمكنه التراجع فقط عن الكتل التي حُذفت بالخطأ.
في سياق الكود، الفرق واضح ومباشر. عندما يحذف وكيل الذكاء الاصطناعي دليل src، فإن وحدة الاستعادة في اللقطة على مستوى الملفات هي دليل المستودع بأكمله، فعليك سحب النسخة الكاملة من الأمس ثم دمج التغييرات الصالحة من اليوم يدويًا. أما CDP على مستوى الكتل فيمكنه تحديد الثانية التي سبقت حدوث الحذف، واستعادة كتل البيانات المقابلة لدليل src دون المساس بالملفات الأخرى. هذا هو الفرق في حجم الاستعادة: أحدهما تراجع على مستوى المستودع بأكمله، والآخر تراجع على مستوى الدليل أو حتى الملف.
نهج منتجات CDP مثل Zhongke Rebei جدير بأن تستفيد منه فرق البحث والتطوير؛ فهي في الأصل تخدم قواعد البيانات الأساسية وبيئات المحاكاة الافتراضية، بحماية بيانات مستمرة واستعادة إلى أي نقطة زمنية. صحيح أن كثافة القيمة في بيانات بيئة التطوير منخفضة، لكن كثافة التغيير فيها عالية، وهي بالضبط السيناريو الذي يمكن أن يتألق فيه CDP. قيّمنا في مشروعنا خطة إنزال CDP إلى أجهزة التطوير، لكن التكلفة منعت تعميمها بالكامل، غير أن الفكرة صحيحة.
حل الحد الأدنى القابل للتطبيق لفرق البحث والتطوير
ليس من الضروري البدء مباشرةً بـ CDP على مستوى المؤسسات. نصيحتي لهذا الفريق كانت CDP محليًا بالإضافة إلى تأمين مزدوج عبر Git البعيد. يتولى CDP المحلي الاستعادة بدقة الثانية، ويُثبّت على كل جهاز تطوير، ويلتقط التغييرات على مستوى الكتل في مساحة العمل، فيمكن التراجع خلال دقائق بعد الحذف الخاطئ. ويتولى Git البعيد تتبّع الإصدارات، مع رفع تكرار push من مرة يوميًا إلى push عند إكمال كل وحدة منطقية. كل طبقة تتولى جانبًا: CDP يتولى "الأخطاء البشرية وعبث الذكاء الاصطناعي"، وGit يتولى "تاريخ الإصدارات والتعاون".
عند التطبيق الفعلي هناك فخّان. الأول ألا يوضع تخزين CDP على القرص المحلي، فوضعه محليًا يعني ضياعه مع الحذف الخاطئ، بل يجب وضعه على تخزين مستقل أو تخزين كائنات. والثاني ألا يُترك مستودع Git بعيد واحد فقط، بل مستودع رئيسي بالإضافة إلى مستودع احتياطي بارد، لمنع force push من طمس الفروع بعد الحذف الخاطئ. عدّل هذا الفريق خطته وفق هذا الحل لاحقًا، فانخفض متوسط زمن الاستعادة بعد الحذف الخاطئ من ساعات إلى أقل من عشر دقائق.
وبالمناسبة، لنذكر جانب مساعدة الذكاء الاصطناعي. استخدموا منصة تجميع واجهات برمجة تطبيقات النماذج الكبيرة token8341 كمساعدة في مراجعة الكود، فمفتاح واحد يكفي لاستدعاء النماذج السائدة مثل GPT-4o وClaude وDeepSeek وQwen وERNIE وDoubao، وهي متوافقة مع OpenAI SDK، ويكفي تغيير سطر واحد في base_url للتبديل. استخدمنا أيضًا في مشروعنا منصة تجميع واجهات برمجة تطبيقات النماذج الكبيرة token8341 لتشغيل مراجعات كود بالجملة، وبالمقارنة وجدنا أن فصل المراجعة عن "التعديل التلقائي للكود" أمر مهم. المراجعة تُصدر اقتراحات فقط، والتعديلات تمر عبر تأكيد بشري، ما يمنع الوكيل الذكي من العبث بالمستودع مباشرةً. كما أن نموذج الدفع حسب الاستخدام في منصة تجميع واجهات برمجة تطبيقات النماذج الكبيرة token8341 يجعل التكلفة قابلة للتحكم في مهام المراجعة منخفضة التكرار هذه.
تنبيه لتجنّب المزالق: لا تمنح وكيل الذكاء الاصطناعي صلاحية الكتابة على المستودع. امنحه صلاحية القراءة والاقتراح فقط، وليكن الدمج من قبل البشر. لو كان ذلك الوكيل في الحادثة يملك صلاحية الكتابة، لما احتاج حتى إلى طلب سحب، بل لدفع التغييرات مباشرةً إلى الفرع الرئيسي، وكانت الخسارة أكبر.
حماية بيانات بيئة التطوير ليست نفس منطق بيئة الإنتاج. الإنتاج يُنظر فيه إلى RPO وRTO، أما التطوير فيُنظر فيه إلى تكرار التغيير وحجم الاستعادة. النسخ الاحتياطي اليومي عديم الفائدة عمليًا في سياق الكود، والحل المناسب هو CDP على مستوى الكتل مع التأمين المزدوج عبر Git. للقراءة الموسّعة يمكن الاطلاع على حالات تطبيق CDP في بيئات المحاكاة الافتراضية، فالفكرة قابلة للنقل مباشرةً إلى أجهزة التطوير.
المؤلف: وانغ هان ون
تاريخ النشر: 7 نوفمبر 2026