مهاجرت امن فیچر فلگ‌ها بدون کابوس کات‌اوور
خلاصهٔ کامل‌تر
به گفتهٔ نویسنده، مهاجرت فیچر فلگ‌ها یه مشکل بدنامیه؛ هر کی قبلاً از پسش براومده، یه داستان از یه کات‌اوور بد و یکی‌دو تا پست‌مورتم برات تعریف می‌کنه. ولی این بدنامی بیشترش نابه‌جاست: خطرها واقعی‌ان، اما شناخته‌شده و به‌راحتی قابل‌کنترل. درست‌درآوردن مهاجرت به یه عملیات هماهنگ بزرگ نیاز نداره، فقط باید بدونی چی می‌تونه اشتباه بشه و از اول دورش رو خط بکشی.
نویسنده میگه توی یه سازمان بزرگ، جایگزینی یه SDK قدیمی که هزاران نقطهٔ فراخوانی رو در بر می‌گیره کار تکراری‌ایه، ولی با ابزار توسعهٔ agentic تو چند روز انجام میشه. مشکل سخت‌تر خودِ ریسکه، نه حجم کار؛ و سه چالش فنی داره: برابری منطق ارزیابی بین دو سیستم (فیچر فلگ فقط کلید روشن/خاموش نیست و منطق پیچیده مثل رول‌اوت درصدی و سگمنت کاربر رو کد می‌کنه)، هم‌گام‌سازی پیکربندی (چون طی مهاجرت هنوز دارن فلگا رو تو سیستم قدیمی عوض می‌کنن) و اطمینان از امنیت کات‌اوور (چون فلگا اغلب تو مسیرهای بحرانی مثل پرداخت می‌شینن).
یه توصیهٔ کلیدی که اولش خلاف‌شهود به‌نظر می‌رسه اینه: اجرای هم‌زمان دو سیستم فیچر فلگ امنه و تو خیلی سازمانا هم رایجه. شاید یه‌کم آزاردهنده باشه، ولی خطرناک نیست. فایده‌ش اینه که مهاجرت به‌جای یه کات‌اوور ناگهانیِ پرخطر، به‌طور طبیعی تو چند هفته اتفاق می‌افته.
نویسنده پیشنهاد می‌ده کار رو با یه آدیت شروع کنی و فلگا رو دسته‌بندی کنی: فلگای زامبی (که ماه‌هاست به رول‌اوت ۱۰۰٪ رسیدن و باید حذف بشن — بدهی فنی رو مهاجرت نده)، فلگای کوتاه‌عمر (آزمایش‌ها و رول‌اوتای موقت) و فلگای بلندعمر (کیل‌سوییچ‌ها و گیت‌های دائمی که نیاز به برنامه‌ریزی دقیق دارن).
بعدش استراتژی سه‌فازه‌ست: اول همین حالا قانون بذار که هر فلگ جدید فقط تو سیستم تازه ساخته بشه (بدون مهاجرت چیزی، فقط دیگه به سیستم قدیمی اضافه نکن)؛ دوم فلگای کوتاه‌عمر رو با یه سیاست حذف (مثلاً یه قانون سفت ۶ تا ۸ هفته‌ای) بازنشسته کن که خودشون از سیستم قدیمی محو می‌شن؛ و سوم برای کات‌اوورِ فلگای بلندعمر باقی‌مونده برنامه بریز و اول از همه بپرس آیا این فلگ هنوز لازمه یا نه.
برای تأیید برابری منطق قبل از کات‌اوور، نویسنده دو راه پیشنهاد می‌ده. راه اول یه تابع wrapperه که هر بار هر دو سیستم رو ارزیابی می‌کنه، هر مغایرتی رو لاگ می‌کنه و جواب سیستم قدیمی رو به‌عنوان مرجع برمی‌گردونه (ارزیابی سیستم جدید هم به‌صورت async اجرا میشه تا تأخیر اضافه نکنه). راه دوم شادو‌مود با OpenFeatureست؛ یه پروژهٔ CNCF که یه API مستقل از فروشنده برای فیچر فلگ می‌ده. با ComparisonStrategy هر دو provider رو رو هر ارزیابی می‌سنجی و موقع اختلاف یه هندلر می‌خوره، بدون هیچ تأثیری روی کاربر؛ و بعد از تأیید برابری، FirstMatchStrategy کات‌اوور واقعی رو فعال می‌کنه.
هر دو راه یه جریان از رویدادهای عدم‌تطابق تولید می‌کنن که فقط وقتی به‌درد می‌خوره که یکی داشته باشتش و روش عمل کنه. نویسنده توصیه می‌کنه این متریکا رو به یه داشبورد بفرستی که به تفکیک اسم فلگ و سرویس، کل ارزیابی‌ها در برابر عدم‌تطابق‌ها، روند نرخ عدم‌تطابق و زمان اولین/آخرین مشاهده رو دنبال کنه؛ فلگی که چند روز روی ترافیک واقعی صفر مونده، آمادهٔ کات‌اووره. قبل از سوییچ هر فلگ هم بهتره پیکربندیش رو ۲۴ تا ۴۸ ساعت فریز کنی.
نکات کلیدی:
- اجرای موازی دو سیستم فیچر فلگ امنه و مهاجرت رو تدریجی و کم‌خطر می‌کنه
- اول فلگا رو آدیت و دسته‌بندی کن: زامبی، کوتاه‌عمر، بلندعمر
- فلگای جدید فقط تو سیستم تازه ساخته بشن؛ فلگای کوتاه‌عمر با سیاست حذف بازنشسته می‌شن
- برابری منطق رو قبل از کات‌اوور با wrapper یا شادو‌مود OpenFeature بسنج
- نرخ عدم‌تطابق رو تو داشبورد دنبال کن؛ صفرِ چندروزه یعنی آمادهٔ سوییچ
