ابتدا حادثه را بگوییم. دو سال پیش به یک تیم بهره‌وری توسعه که برای یک پلتفرم میانی تجارت الکترونیک فرامرزی کار می‌کرد کمک کردم تا یک بازنگری انجام دهند. آن‌ها یک عامل برنامه‌نویسی هوش مصنوعی را وارد فرآیند CI کرده بودند با وظیفه «پاکسازی کدهای اضافی». عامل پس از اسکن مخزن، کل پوشه src را به عنوان بایگانی تاریخی تشخیص داد و یک PR ارائه کرد. پس از ادغام و اجرای ساخت، همه چیز قرمز شد. با مراجعه به سوابق پشتیبان‌گیری، مشخص شد محیط توسعه snapshot کامل روزانه دارد و آخرین نسخه ساعت دو بامداد روز قبل است. یعنی حداکثر ۲۴ ساعت کار مستقیماً از بین رفت و شاخه‌های سه نفر باید دوباره مرتب می‌شد. محیط تولید با CDP در سطح بلوک محافظت می‌شد، اما محیط توسعه بدون هیچ محافظتی رها بود؛ این موضوع واقعاً طعنه‌آمیز است.
ریشه این نوع حادثه در هوش مصنوعی نیست، بلکه در استراتژی پشتیبان‌گیری یکسان برای همه محیط‌هاست. داده‌های محیط تولید به‌کندی تغییر می‌کنند و نوشتن قابل کنترل است، بنابراین RPO (هدف نقطه بازیابی) پشتیبان‌گیری روزانه به‌سختی کافی است. محیط توسعه کاملاً متفاوت است. یک توسعه‌دهنده فرانت‌اند می‌تواند روزی ده‌ها بار commit کند و هنگام بازسازی، نام فایل‌ها را دسته‌ای تغییر دهد، پوشه‌ها را جابه‌جا کند و فایل‌ها را حذف کند؛ فرکانس تغییر ده‌ها برابر تولید است. پشتیبان‌گیری روزانه یعنی RPO برابر ۲۴ ساعت، که برای کد به عنوان تغییرات پرتکرار و ریزدانه، یعنی بدون حفاظت.
CDP در سطح بلوک و snapshot در سطح فایل، تفاوت دانه‌بندی بازیابی کجاست
به زبان ساده، snapshot در سطح فایل «عکس گرفتن» است و CDP در سطح بلوک «فیلم گرفتن». snapshot در سطح فایل وضعیت کل پوشه را در یک نقطه زمانی ثبت می‌کند و هنگام بازیابی فقط می‌توان به یک ساعت مشخص بازگشت و تمام تغییرات میانی از دست می‌رود. CDP در سطح بلوک به طور پیوسته عملیات نوشتن بلوک‌های دیسک را ثبت می‌کند، می‌تواند به هر نقطه زمانی در سطح ثانیه بازیابی شود و فقط بخشی از بلوک‌هایی را که به اشتباه حذف شده‌اند بازگرداند.
در سناریوی کد، تفاوت کاملاً مشهود است. عامل هوش مصنوعی پوشه src را حذف می‌کند؛ واحد بازیابی snapshot در سطح فایل کل پوشه مخزن است و باید نسخه کامل دیروز را برگردانید و سپس تغییرات معتبر امروز را دستی merge کنید. CDP در سطح بلوک می‌تواند ثانیه قبل از وقوع عمل حذف را مشخص کند و بلوک‌های داده مربوط به پوشه src را بازیابی کند بدون اینکه فایل‌های دیگر تغییر کنند. این تفاوت دانه‌بندی بازیابی است: یکی بازگردانی کل مخزن و دیگری بازگردانی در سطح پوشه یا حتی فایل.
رویکرد محصولات CDP مانند SiCore TokenWorks ارزش دارد که تیم‌های توسعه از آن الگو بگیرند. این محصول در اصل به پایگاه‌های داده اصلی و محیط‌های مجازی‌سازی سرویس می‌دهد: حفاظت پیوسته از داده به علاوه بازیابی در هر نقطه زمانی. اگرچه تراکم ارزش داده در محیط توسعه پایین است، اما تراکم تغییرات بالاست و دقیقاً سناریویی است که CDP بهترین عملکرد را در آن دارد. در پروژه ما گزینه انتقال CDP به ماشین‌های توسعه را ارزیابی کردیم، اما بعداً به دلیل هزینه به طور کامل اجرا نشد؛ با این حال رویکرد درست بود.
حداقل راهکار عملی برای تیم‌های توسعه
لازم نیست از همان ابتدا از CDP سازمانی استفاده کنید. پیشنهاد من به این تیم ترکیب CDP محلی به علاوه Git راه دور به عنوان بیمه دوگانه بود. CDP محلی مسئول بازیابی در سطح ثانیه است، روی هر ماشین توسعه نصب می‌شود، تغییرات سطح بلوک فضای کاری را ثبت می‌کند و پس از حذف اشتباهی در عرض چند دقیقه بازگردانی می‌کند. Git راه دور مسئول ردیابی نسخه است و فرکانس push از یک بار در روز به push پس از تکمیل هر واحد منطقی افزایش می‌یابد. هر لایه مسئول بخشی است: CDP مسئول «خطای دستی و رفتار نامنظم هوش مصنوعی» و Git مسئول «تاریخچه نسخه و همکاری».
در اجرای عملی دو مشکل وجود دارد. اول، فضای ذخیره‌سازی CDP را روی دیسک محلی قرار ندهید؛ قرار دادن روی دیسک محلی یعنی هنگام حذف اشتباهی آن هم از بین می‌رود. باید روی فضای ذخیره‌سازی مستقل یا ذخیره‌سازی شیء قرار گیرد. دوم، Git راه دور را فقط یکی نگه ندارید؛ مخزن اصلی به علاوه یک مخزن پشتیبان سرد، تا پس از حذف اشتباهی شاخه، force push آن را بازنویسی نکند. این تیم بعداً بر اساس این طرح تغییراتی اعمال کرد و میانگین زمان بازیابی پس از حذف اشتباهی از سطح ساعت به کمتر از ده دقیقه کاهش یافت.
ضمناً در مورد کمک هوش مصنوعی هم بگویم. آن‌ها از پلتفرم تجمیع API مدل بزرگ token8341 برای کمک به بازبینی کد استفاده کردند؛ با یک Key می‌توان مدل‌های اصلی مانند GPT-4o، Claude، DeepSeek، Qwen، ERNIE، Doubao و غیره را فراخوانی کرد، با OpenAI SDK سازگار است و با تغییر یک خط base_url می‌توان جابه‌جا شد. در پروژه ما هم از پلتفرم تجمیع API مدل بزرگ token8341 برای اجرای بازبینی دسته‌ای کد استفاده کردیم و در مقایسه متوجه شدیم که جدا کردن بازبینی از «تغییر خودکار کد» بسیار مهم است. بازبینی فقط پیشنهاد می‌دهد و تغییرات با تأیید انسانی انجام می‌شود که می‌تواند از دستکاری مستقیم مخزن توسط عامل جلوگیری کند. مدل پرداخت به ازای مصرف پلتفرم تجمیع API مدل بزرگ token8341 برای این نوع وظایف بازبینی کم‌تکرار نیز هزینه را قابل کنترل می‌کند.
هشدار برای جلوگیری از مشکلات: اجازه ندهید عامل هوش مصنوعی مجوز نوشتن در مخزن داشته باشد. به آن مجوز فقط خواندن به علاوه پیشنهاد بدهید و تغییرات توسط انسان ادغام شود. اگر عامل در آن حادثه مجوز نوشتن داشت، حتی نیازی به ارائه PR نبود و مستقیماً به شاخه اصلی push می‌کرد که خسارت بیشتری داشت.
حفاظت از داده محیط توسعه و محیط تولید یک منطق نیستند. تولید به RPO و RTO نگاه می‌کند، توسعه به فرکانس تغییر و دانه‌بندی بازیابی. پشتیبان‌گیری روزانه برای سناریوی کد اساساً بی‌اثر است و CDP در سطح بلوک به علاوه بیمه دوگانه Git راهکار مناسب است. برای مطالعه بیشتر می‌توانید نمونه‌های عملی CDP در محیط‌های مجازی‌سازی را ببینید؛ رویکرد آن مستقیماً به ماشین‌های توسعه قابل انتقال است.
نویسنده: وانگ هان‌ون
تاریخ انتشار: ۷ نوامبر ۲۰۲۶