مهاجرت تدریجی: جایگزینی سیستم قدیمی بدون توقف کار
ایده ساده است: بهجای اینکه دو سال روی سامانهٔ جدید کار کنید و در یک شب همهچیز را جابهجا کنید، یک لایه جلوی سامانهٔ قدیمی میگذارید و بخشها را یکییکی به سمت جدید میبرید. سامانهٔ قدیمی تمام این مدت کار میکند و کاربر متوجه نمیشود که کدام بخش را کدام سامانه جواب میدهد.
اسمش از گیاهی گرفته شده که دور درخت میپیچد و کمکم جایش را میگیرد.
قطعهٔ اصلی: لایهٔ مسیریاب
بین کاربر و سامانهها یک لایه مینشیند که تصمیم میگیرد هر درخواست به قدیمی برود یا به جدید. اگر سامانهٔ شما تحت وب است، این میتواند به سادگی چند قاعده در وب سرور باشد؛ اگر پیچیدهتر است، یک دروازهٔ API.
مهم این است که این لایه از روز اول بنشیند، حتی وقتی هنوز صد درصد ترافیک به قدیمی میرود. سه دلیل:
اضافهکردنش وقتی نیمی از سیستم جابهجا شده، بهمراتب سختتر است.
از همان ابتدا امکان برگشت میدهد — یک قاعده را عوض میکنید و ترافیک به قدیمی برمیگردد.
و اجازه میدهد ابتدا بخش کوچکی از کاربران را ببرید، نه همه را.
کدام بخش را اول ببرید
وسوسه این است که از سختترین بخش شروع کنید، چون بیشترین درد آنجاست. تجربهٔ ما عکسش را میگوید.
بخش اول را طوری انتخاب کنید که مستقل باشد و کمترین وابستگی به بقیه داشته باشد. هدف این مرحله اثبات مسیر است، نه حل بزرگترین مشکل: میخواهید بدانید لایهٔ مسیریاب کار میکند، احراز هویت بین دو سامانه درست است، و داده همگام میماند.
بعد از آن، بخشی را ببرید که بیشترین تغییرات کسبوکاری را میگیرد. اینجاست که سود واقعی است: از آن به بعد، تغییرات در سامانهٔ جدید انجام میشوند که سریع است.
بخشهایی که سالهاست دست نخوردهاند و کار میکنند، آخر صفاند. بعضیشان هم شاید هرگز منتقل نشوند و مشکلی نداشته باشد.
احراز هویت، اولین چیزی که باید حل شود
کاربری که بین دو سامانه جابهجا میشود نباید دو بار وارد شود. این را باید قبل از انتقال اولین بخش حل کنید، نه بعدش.
سه راه، به ترتیب تمیزی: ورود یکپارچه که هر دو سامانه از آن استفاده کنند؛ نشست مشترک بین دو سامانه؛ یا در بدترین حالت، انتقال نشست از قدیمی به جدید در لحظهٔ عبور.
اگر سامانهٔ قدیمی نمیتواند با هیچکدام کار کند، همین یک قلم میتواند کل مسیر تدریجی را غیرممکن کند — و بهتر است در هفتهٔ اول بدانید تا در ماه ششم.
داده مشترک، سختترین بخش
اینجاست که این الگو ساده به نظر میرسد و نیست.
تا وقتی هر دو سامانه زندهاند، هر دو به دادهٔ مشترک نیاز دارند — مشتری، محصول، سفارش. سه حالت وجود دارد:
یک پایگاه داده، دو سامانه. سادهترین برای شروع و بدترین برای پایان: سامانهٔ جدید به ساختار دادهٔ قدیمی زنجیر میشود و همان چیزی که میخواستید از آن فرار کنید را به ارث میبرد.
دو پایگاه داده با همگامسازی. انعطاف بیشتر و مسئلهٔ همگامسازی. باید بدانید هر داده صاحبش کیست؛ اگر دو طرف بتوانند یک رکورد را عوض کنند، تعارض حتمی است.
تقسیم بر اساس حوزه. هر بخش که منتقل میشود، دادهاش را هم با خودش میبرد و از آن به بعد صاحبش سامانهٔ جدید است. تمیزترین و نیازمند اینکه مرزهای داده روشن باشند.
قاعدهای که در هر سه صدق میکند: برای هر جدول یا موجودیت، دقیقاً یک صاحب. اگر این را رعایت نکنید، شش ماه بعد وقتتان صرف پیدا کردن این میشود که کدام سامانه عدد را خراب کرده.
چطور بفهمید جواب داده
سه چیز را از ابتدا اندازه بگیرید:
سهم ترافیکی که به سامانهٔ جدید میرود. عددی که باید بالا برود و اگر چند ماه ثابت مانده، پروژه گیر کرده.
تعداد بخشهایی که کاملاً منتقل شدهاند — یعنی کد قدیمیشان حذف شده. این نکته مهم است: تا وقتی کد قدیمی پاک نشده، شما دو سامانه نگه میدارید و هزینهٔ هر دو را میدهید.
و زمان انجام یک تغییر کسبوکاری معمول. دلیل اصلی کل پروژه همین است و اگر بعد از یک سال بهتر نشده، مسیر را اشتباه رفتهاید.
دام اصلی
بزرگترین خطر این الگو، شکست نیست. نیمهکاره ماندن است.
چند بخش منتقل میشود، فشار کسبوکار میآید، تیم به کارهای دیگر میرود، و سازمان با دو سامانهٔ نیمهفعال میماند که هر دو باید نگهداری شوند و هیچکس نمیداند منطق فلان قاعده کجاست. این وضعیت از نقطهٔ شروع بدتر است.
دو چیز جلویش را میگیرد: از ابتدا مشخص کنید کدام بخشها هرگز منتقل نمیشوند تا «تمامشدن» تعریف داشته باشد؛ و بعد از انتقال هر بخش، کد قدیمیاش را همان اسپرینت حذف کنید. کدی که «فعلاً بماند شاید لازم شود» تا ابد میماند.
اگر تصمیم بین این مسیر و بازنویسی کامل هنوز باز است، نوسازی نرمافزار قدیمی چهار گزینهٔ روی میز را مقایسه کرده است.