تجربه مهاجرت تدریجی از سیستم Legacy به سیستم جدید، مرد میدان می خواهد

با توجه به اینکه این روزها درگیر کاری مشابه هستیم، تصمیم گرفتم از تجربه ای که بدست آوردم بنویسم.

مطلب خودم را از آخر به اول شروع می کنم

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

با این مقدمه میریم سراغ اصل موضوع

در مهندسی نرم افزار به سیستم قدیمی یا سیستمی که سالهاست در حال کار است و هنوز استفاده می شود معمولا سیستم لگیسی میگن.

کار واقعی توسعه سیستم، با تبدیل و پیاده‌سازی آن به پایان می‌رسد. هدف اصلی جایگزینی سیستم موجود با سیستم جدید و حذف سیستم موجود یا همان سیستم قدیم از کار روزانه است.

سیستم لگیسی موجود به شدت به کسب و کار وابسته است ترکیبی از چندین معماری قدیمی می باشد که DB DRIVEN طراحی شده و قرار است این سیستم با معماری جدید مبتنی بر مایکروسرویس بازنویسی و در نهایت جایگزین بشود.

بنابراین صورت مسئله را اینطور تعریف می کنم، روش های جایگزین سیستم جدید با سیستم لگیسی چطور انجام می شود و چه چالش های روبروی ما قرار می گیرد؟

برای جایگزینی سیستم قدیم با جدید معمولاً روش‌های مختلفی وجود داره که در ضمن هر کدام دارای مزایا و معایب مربوط به خودشان می‌باشند و انتخاب یکی از روش‌ ها بستگی به نظر طراح سیستم و استفاده‌کنندگان سیستم در رسیدن به اهدافشان دارد، ضمن آنکه میزان سطح ریسکی که یک سیستم می‌تواند تحمل کند، در انتخاب یک روش پیاده‌سازی اهمیت دارد.

1.روش ناگهانی

در این روش سیستم قدیم یکباره کنار گذاشته می‌شود و سیستم جدید با سیستم قدیم یا لگیسی جایگزین می‌شود. جهت جلوگیری از وقفه در کار سیستم جاری و عدم کارکرد آن در هنگام جایگزینی سیستم قدیم به سیستم جدید، معمولاً پیاده‌سازی و تبدیل در ساعت‌های غیر کاری و در زمان‌های تعطیل صورت می‌گیرد.

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

طبیعتا روش ناگهانی برای سیستم های اینترپرایز خیلی پیشنهاد نمی شود، عملا هم به نظر غیرممکن میاد.

2.روش موازی

سیستم قدیم و جدید می‌توانند به شکل موازی کار کنند تا نتیجه کار هر دو با هم مقایسه شود و در صورت کارکرد موفقیت آمیز سیستم جدید در یک دوره مشخص بتوان آن را جایگزین سیستم موجود کرد. معمولاً تصمیم‌گیری و تعیین زمان استفاده از سیستم جدید به جای قدیم بر اساس تجزیه و تحلیل از چگونگی کارکرد دو سیستم است.

با توجه به کارکرد موازی دو سیستم، هزینه بالاست ولی در عوض استفاده‌کننده حداکثر امنیت را به دست می‌آورد و مطمئن از کارکرد سیستم جدید می شود. استفاده کننده مجبور است یک کار را دوباره انجام بدهد، ولی به دلیل کارکرد موازی دو سیستم ریسک پذیری سیستم پایین است، اگر سیستم جدید نتواند وظایف خود را به خوبی انجام بدهد، می توان از همان سیستم قدیم استفاده کرد. بزرگترین مشکل این روش هم مشخصه دیگه، کاربر مجبور کنیم از هر دو سیستم استفاده کند، البته این خود آبستن یک اشتباه است، زیرا سیستم جدید با سیستمی مقایسه می شود که خودش به دلایلی نمی تواند کارش را به خوبی انجام بدهد.

3.روش مرحله به مرحله یا تدریجی

در این روش بعضی از مراحل توسط سیستم قدیم و بعضی دیگر توسط سیستم جدید انجام می‌گیرد و به صورت تدریجی جای مراحل یکدیگر عوض می‌شود و به تدریج و به شکل مرحله به مرحله سیستم جدید جایگزین سیستم فعلی می‌شود.

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

در حال حاضر ما داریم از روش تدریجی استفاده می کنیم، قاعدتا نباید به همین راحتی باشه. چالش های که در مسیر جایگزینی یک سسیتم جدید با قدیم مواجه می شویم:

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

2. از طرف دیگر، تیم توسعه و پشتیبانی تقریبا از روز اول زیر فشار قرار می‌گیرد، چون هم باید سیستم قدیمی را پایدار نگه داره، هم سیستم جدید رو توسعه بدهند و هم بخشی از تحلیل سیستم legacy را انجام دهد.
   در عمل، توسعه‌دهنده‌ های ارشد یا با تجربه تر ناگزیر وارد فاز تحلیل هم باید بشوند، چون مستقیما با محدودیت‌ها، وابستگی‌ها و رفتارهای سیستم قدیمی درگیر هستند.

3. وقتی سیستم جدید زیربار می رود، بخشی از فرآیندها روی سیستم جدید انجام می‌شود، اما داده‌ها همچنان از طریق سیستم قدیمی وارد می‌شوند. که نیاز به سینک و یکپارچه‌سازی داده‌ها بین دو سیستم را ایجاد می‌کند.
   اما حفظ یکپارچگی داده‌ها به همین سادگی نیست.
   داده‌هایی که از سیستم قدیم وارد می‌شوند، ممکن است با مدل کسب و کاری یا محدودیت‌های سیستم جدید سازگار نباشند و باعث ناسازگاری یا رفتارهای پیش‌بینی‌ نشده بشوند.

4. هرچه تعداد کاربران و حجم درخواست‌های دو سیستم به هم نزدیک‌تر شود، فشار روی تیم دیتابیس بیشتر خواهد شد.در این مرحله، تیم باید همزمان consistency، همگام‌سازی داده‌ها، performance و وابستگی‌های بین دو سیستم را مدیریت کند. به نظر من این فشار تا زمانی ادامه پیدا می‌کند که سهم ترافیک سیستم جدید به اندازه‌ای برسد که بتوان بخشی از بار سیستم legacy را حذف کرد یا دست‌کم تراکنش‌های آن را کاهش داد. (خدا داند)

5. نگهداری همزمان دو سیستم، هزینه و فشار عملیاتی قابل‌ توجهی ایجاد می‌کند. مدیران، تیم های فنی، زیرساخت، دیتابیس.

6. از یک نقطه به بعد، تیم توسعه عملا دیگر نمی‌تواند همزمان زیر بار توسعه سیستم جدید و پشتیبانی کامل سیستم قدیمی باقی بماند.

7. سیستم جدید به‌مرور زیر بار واقعی خواهد رفت و طبیعتا رفتارهایی از خود نشان می‌دهد که در محیط تست یا staging قابل مشاهده نبوده. بنابراین باید انتظار تغییرات مداوم، باز طراحی بعضی بخش‌ها و حتی بازنگری در برخی تصمیم‌های اولیه را داشت.خدا به خیر کند.

8. از طرف دیگر، تیم توسعه و پشتیبانی تقریبا از روز اول زیر فشار قرار می‌گیرد چون هم باید سیستم قدیمی را پایدار نگه داره، هم سیستم جدید را توسعه بده و هم بخشی از تحلیل و کشف رفتارهای سیستم legacy را انجام بده.

فشارهای پنهای زیاد دیگر هم وجود دارد، مقایسه دو سیستم توسط ذینفعان( کسانی که هزینه را تقبل می کنن)، گاها سبب می شود این فکر ایجاد می شود که چرا اصلا سیستم جدید را راه اندازی کردیم.

هزینه ها بالا رفته، دو یا چند سیستم زنده اند، ولی هنوز ارزش سیستم جدید برای ذینفعان کاملا ملموس نشده.

مرحله بازنگری

مرحله بازنگری به طور رسمی جزئی از توسعه سیستم نیست. هدف این مرحله بازنگری بر کار توسعه سیستمی است که به تازگی به انجام رسیده است. این مرحله شامل دو فعالیت است:

اول: بازنگری کوتاه که بلافاصله پس از مرحله پیاده‌سازی صورت می‌گیرد. هدف این بخش کمک به تیم توسعه برای انجام پروژه‌های آینده است. مدیر پروژه و اعضای تیم، پروژه، سیستم جدید را که اخیراً ایجاد شده مجدداً مرور کرده تا احتمالاً تغییری را که مورد نیاز است، شناسایی کرده تا باعث بهبود سیستم در آینده شود.

دوم: بازنگری پس از کارکرد که پس از گذشت چند ماه بعد از اتمام سیستم جدید، آن را ارزیابی می‌کنند. هدف از این ارزیابی این است که مشخص شود فعالیت و کارکرد آن در این مدت چگونه و به چه نحوی بوده است و تا چه حدی توانسته فایده یا احتمالاً زیان داشته باشد. در نتیجه این فعالیت، احتمالاً پیشنهادهایی در جهت استفاده بهتر از سیستم ارائه می‌شود.

در نهایت، شاید مهم‌ترین نکته این باشه که اساسا مهاجرت(چه سیستمی چه شخصی) از یک سیستم legacy، صرفاً یک پروژه فنی نیست، یک تغییر بزرگ عملیاتی و سازمانیه که فشار آن فقط روی یک تیم یا چند توسعه‌ دهنده باقی نمی‌ ماند.
در چنین شرایطی، نقش مدیران فقط تصمیم‌گیری یا پیگیری زمان‌بندی پروژه نیست. حمایت واقعی از تیم فنی، چه از نظر مادی و چه از نظر معنوی، بخشی از الزامات عبور موفق از این مسیر است.

بدون اغراق، مهاجرت تدریجی یک سیستم بزرگ، کار سخت و فرسایشی‌ است.

در حال تکمیل...