در دنیای مهندسی نرم‌افزار، مهاجرت سیستم‌های تولیدی همیشه چالش‌برانگیز است. اما شرکت Datadog با ترکیب قدرت هوش مصنوعی و رویکرد تست‌محور، یک مهاجرت جسورانه را به سرانجام رساند. آرنولد واکیم، مهندس Datadog، در مقاله‌ای به اشتراک گذاشت که چگونه با استفاده از Claude و Cursor، یک سیستم حیاتی را از پایگاه داده‌ای قدیمی به معماری جدید منتقل کردند و عملکرد را به طرز چشمگیری بهبود بخشیدند.

مشکل: محدودیت‌های پایگاه داده KV

نسخه اولیه Stream Router، یک API برای مدیریت مسیریابی در خط لوله معیارها، بر اساس مدل کلید-مقدار (KV) ساخته شده بود. با رشد جدول مسیریابی، پایگاه داده KV با محدودیت‌های اندازه تراکنش مواجه شد و عملیات‌های سنگین تا ۴۵ دقیقه زمان می‌بردند. دلیل اصلی، هزاران رفت و برگشت متوالی (round trips) بود. در این مدل، کد مجبور بود روابط بین موجودیت‌ها را بازسازی کند و عملاً نقش یک پایگاه داده رابطه‌ای را درون فرآیند بازی کند.

راه‌حل: طراحی مجدد طرحواره و استفاده از AI

مهندسان Datadog ابتدا طرحواره (schema) را بازطراحی کردند تا روابط بین موجودیت‌ها را به طور طبیعی منعکس کند و به کلیدهای خارجی (foreign keys) اجازه دهند منطق پیچیده را جایگزین کنند. سپس برای بازنویسی کل پایگاه کد از مدل قدیم به جدید، به سراغ هوش مصنوعی رفتند. آنها از Claude و Cursor برای تسریع یک فرآیند بازآرایی سیستماتیک و مبتنی بر آزمون استفاده کردند. به گفته واکیم: آنها به طور خودمختار کد تولید نمی‌کردند: برای هر متد، پیاده‌سازی قدیمی، طرحواره جدید و یک آزمون ناموفق ارائه می‌کردیم. مدل‌ها یک گذر اولیه تولید می‌کردند و آزمون‌ها به ما می‌گفتند که آیا درست است یا خیر.

سه عنصر کلیدی موفقیت

واکیم سه عامل اصلی را برای امکان‌پذیر شدن این مهاجرت برمی‌شمارد:

  • مدولاریت قوی کد: Stream Router جدید همان API را روی PostgreSQL به جای FoundationDB پیاده‌سازی کرد بدون نیاز به تغییر در جای دیگر.
  • مجموعه آزمون جامع: این آزمون‌ها به عنوان معیار واضح قبولی/شکست برای هر تغییر تولید شده توسط AI عمل می‌کردند.
  • زیرساخت موازی: دو نمونه مستقل از Stream Router به صورت همزمان اجرا می‌شدند و درخواست‌های یکسان را مدیریت می‌کردند. کلاینت‌ها از طریق feature flags بین آنها هدایت می‌شدند. یک سرویس اعتبارسنج اختصاصی به طور مداوم پاسخ‌ها را مقایسه می‌کرد و در صورت انحراف فوری هشدار می‌داد.

فرآیند مهاجرت در سه فاز

  1. فاز اول – توصیف هدف: با استفاده از Claude، هدف هر تابع کلیدی توصیف شد.
  2. فاز دوم – رفع آزمون‌ها: promptهای متمرکز با ارائه رفتار مورد انتظار و بافت مرحله قبل، آزمون‌های ناموفق را رفع کردند.
  3. فاز سوم – استقرار آبی/سبز: Stream Router جدید مبتنی بر PostgreSQL و نسخه قدیمی مبتنی بر FoundationDB به صورت موازی اجرا و مقایسه شدند.

نتایج شگفت‌انگیز

پس از مهاجرت، زمان عملیات‌ها از ۴۵ دقیقه به حدود ۱ ثانیه کاهش یافت. تأخیرها (latencies) از صدها میلی‌ثانیه به چند میلی‌ثانیه رسید. ذخیره‌سازی داده تا ۴۰ برابر کوچک‌تر شد و DuckDB نیز به بهبود کارایی پرس‌وجو کمک کرد. استفاده از CPU و حافظه کاهش یافت و هزینه‌های پایگاه داده ۹۰٪ کاهش یافت.

درس‌های آموخته شده: محدودیت‌های AI

واکیم به چند نقطه ضعف نیز اشاره می‌کند: بهینه‌سازی‌های خاص مانند batching، ترفندهای UNNEST و جداول عبارات مشترک (CTEs) نیاز به ورودی انسانی داشتند. پرس‌وجوهای AI نتایج درست اما با رفت و برگشت‌های زیاد تولید می‌کردند. همچنین مصرف بالای توکن به دلیل تغذیه کامل خروجی آزمون‌ها چالش‌برانگیز بود. با این حال، وقتی الگوها به مدل نشان داده شد، توانست آنها را در متدهای بعدی تکرار کند.

در نهایت، کلید موفقیت در قدرت مجموعه آزمون بود که تعیین می‌کرد چقدر می‌توان به کد تولید شده توسط هوش مصنوعی اعتماد کرد. این رویکرد نشان می‌دهد که توسعه تست‌محور (TDD) و AI می‌توانند دست در دست هم، مهاجرت‌های پیچیده را ممکن سازند.