شوق یادگیری و راه اندازی کسب و کار دیجیتال دارید؟ تشنه آموزش و اجرای سریع ایده‌هایتان هستید؟ همین حالا تماس بگیرید.
این پست روایت کننده، تجربه واقعی و عملی مهاجرت یک پلتفرم اعتباری-بانکی، بر مبنای تکنولوژی‌های جاوا و خانواده اوراکل می‌باشد. یادداشت‌هایی از این دست برای مهاجرت‌های بعدی خیلی راهگشا است و هم‌چنین می‌توان، تسهیل‌گر برای تصمیم‌گیران، حوزه فنی و نرم‌افزار باشد.
تدوین این پست، بر اساس تجربه واقعی نویسنده، صورت گرفته است
پوستر اصلی این پست، متعلق به انیمیشن toy story می‌باشد، که در آن روایت ماجراهای جالب و بعضا بغض آور شخصیت‌های انیمیشن را بازگو می‌کند. مهم‌ترین علت انتخاب این پوستر، اشاره به تلخی‌ها و شیرینی‌های فرآیند مهاجرت و هم چنین، سریالی بودن، این مطلب می‌باشد، زیرا قصد بر این است که به عنوان مسولیت اجتماعی، تمام مهاجرت‌های نرم افزاری صورت گرفته در تجربه کاری نویسنده را در قالب چند مطلب مجزا، با همین عنوان ارائه شود
چرا مهاجرت؟
در پروژه‌ای که کمتر از چندماه از تولید آن گذشته چرا لازم است مهاجرت صورت پذیرد؟ این از اصلی‌ترین سوالات هر مهاجرت است که باید در ابتدا پاسخ منطقی به آن داده شود. در صورتی که پاسخ این سؤال بدون منطق باشد، بدانید و آگاه باشید، که به زودی در باتلاقی سخت فرو خواهید رفت که شاید، تلاش و تقلا برای بیرون آمدن از آن، بیهوده باشد.
برای عملیاتی شدن، محصولات نرم افزاری، معمولا یک فاز در نظر گرفته می‌شود، که در آن همه چیز با حداقلی‌ترین قابلیت‌ها (minimum requirement) منتشر شود و به آن MVP گفته می‌شود. MVP پروژه تولید شده توسط یک شرکت نرم افزاری بود، که با اینکه شریک راهبردی کسب و کار ما بود و از آن فراتر حتی رابطه هلدینگی داشتیم، با این حال از ارائه source های پروژه خودداری می‌کرد و حتی الگوریتم‌های شکل گرفته و پیاده‌سازی شده را، با سختی و تقلای بسیار، به صورت کلامی و غیر مستند ارائه می‌کرد.
علاوه بر عدم ارائه منابع لازم، برخی از تکنولوژی‌های مورد استفاده، قدیمی و بروز نبودند و حتی خود سازنده MVP، اذعان به نیاز به بازنویسی آن می‌کرد. خروجی‌های MVP، عبارت بودند از:
- اپلیکیشن backend که با معماری monolithic، به تمامی کلاینت‌ها و سرویس‌های third-party خدمات می‌داد
- اپلیکیشن kyc احراز هویت و اعتبارسنجی مشتریان نهایی
- پنل دسترسی برای شراکای زینفع و مدیریت اجرایی
- اپلیکیشن pos دستگاه‌های کارت خوان
اوضاع کسب و کار در حال مهاجرت
در فضای واقعی، MVP منتشر شده، برای وزیر وقت اقتصاد و دارایی، رونمایی شده و به گفته وزیر، این پروژه، رویای ایشان را عملی کرده بود. این رونمایی که در حضور مدیرعامل بانک و مدیرعامل هلدینگ یادشده، صورت گرفته بود، حساسیت‌های مهاجرت را، دوچندان کرده بود. علاوه بر این روزانه stack holder های بیشتری، درگیر پلتفرم می‌شدند و MVP طراحی شده، کلا برای این مدل مقیاس طراحی نشده بود.
یکی از دغدقه‌های دائمی هر مهاجرت، نحوه انتقال داده، مشتریان و سفارشاتی است، که در پلتفرم قدیمی وجود دارد. مساله جدیدی که مطرح می‌شد، بنا به رشد روزافزون، کسب و کار، به MVP هر روز قابلیت جدیدی افزوده می‌شد و علیرغم، درک استراتژیک مدیران کسب و کار، مبنی بر اینکه افزودن قابلیت جدید، در این مقطع، همانند سم است، لکن به جهت جلوگیری از اخلال در همه‌گیرسازی، پلتفرم بخش‌های جدید، هم‌چنان اضافه می‌شد.
تیم توسعه جدید نرم افزار
برای تولید یک پلتفرم، نیاز به تیم سازی و جذب افراد است. هرقدر ابعاد پروژه بزرگتر، این تیم سازی باید گسترده‌تر صورت پذیرد. بعد از انتشار آگهی و دعوت به همکاری، اولین نفرات جذب شده، یک برنامه نویس Frontend و یک برنامه نویس Backendو یک نیروی کنترل کیفیت محصول Quality Assurance بودند، که هسته اولیه تیم فنی را تشکیل دادند.
یک تیم طراحی مشتمل بر سه طراح و یک مدیرمحصول، از دو ماه قبل تر وجود داشتند و بخشی از فرآیندها را در حال پیاده‌سازی و کشف بودند.
اولین چالش تیم جدید انتخاب تکنولوژی‌های مورد استفاده بود و در این مسیر از فرآیند software selection solution استفاده شد. در این فرآیند شما مزایا و معایب تکنولوژی‌ها را بر اساس، نیاز کسب و کار دسته‌بندی می‌کنید و در نهایت بهترین و سریع‌ترین گزینه را به منظور پیاده‌سازی انتخاب می‌کنید.
چالش بعدی، هماهنگ کردن تیمی بود، که سابقه همکاری، با هم نداشتند و بعضا، به درک مشترکی از محصول نرسیده بودند. این مساله باعث می‌شد تا محصول بازتولید شده، در بعضی موارد، هماهنگ با mvp نباشد و علاوه بر این مساله QA را با پیچیدگی مواجه می‌کرد.
چالش دیگر، عدم کارکرد صحیح MVP در برخی موارد و نیاز به بهبود، در نسخه اول بود. به عنوان مثال، بحث فعال‌سازی اعتبار و کارت، در پیاده‌سازی MVP، کاملا متفاوت با آنچه بود که برای نسخه اولیه، بازنویسی شده، در نظر گرفته شده بود.
تفاوت‌های تکنولوژیک
MVP پیاده‌سازی شده در موارد زیادی، دارای تکنولوژی قدیمی‌تر بود. این قدمت تکنولوژیک سبب می‌شد تا رفتار نرم افزاری متفاوتی در قیاس با تکنولوژی بروزتر داشته باشد.
| نسخه اولیه | نسخه MVP |
| Java 17 | Java 8 |
| Spring boot 3.3 | Spring Boot 2 |
| Database Postgresql 15 | Database Oracle 17 G |
| Docker | Tomcat Application Server |
| Next.Js | React.js |
| Android Pos Kotlin Jepack Compose | Android Pos Kotlin MVVM |
شاید این موضوع یک مقدار عجیب باشد که در سال ۲۰۲۴، استفاده از تکنولوژی‌های مربوط به حدود ۱۰سال پیش صورت گرفته ولی در نسخه MVP همان طور که انتظار می‌رود، هیچ وسواسی در انتخاب تکنولوژی، صورت نگرفته است
مهاجرت داده‌ای
یکی از حساس‌ترین بخش‌های مربوط به هر پروژه مهاجرت انتقال، داده‌های کاربران و موارد وابسته، برای کارکرد پلتفرم است. در این جابه جایی یا مهاجرت قرار بود، حدود 4000 داده کاربران و حدود 6000 تراکنش همین کاربران، جابه جا شود، علاوه بر این حدود 20 گیگابایت حجم فایل‌های مربوط به این کاربران، بود که اسناد و مدارک اسکن شده ایشان، را شامل می‌شد.
برای انجام این انتقال، پروژه‌ای جدید ایجاد گردید، که همزمان به دو پایگاه داده اوراکل و postgresql دسترسی داشت. مهم‌ترین نقش این پروژه تبدیل داده‌های موجود در اوراکل متناظر با ساختار، جدید و پایگاه داده postgresql بود. این جا به جایی به علت ندانستن، نحوه کارکرد دیتابیس اسبق، تا حدی درگیر کشف و شهود بود. به عبارت دیگر ما باید روی MVP شبیه‌سازی فرآیندهای گوناگون را انجام میدادم و نحوه ذخیره‌سازی را متوجه می‌شدیم. اما این تمام ماجرا نبود. در داده‌های ذخیره شده، انواع anormally و داده‌های کثیف موجود بود، به نحوی که مانده اعتبار و خرج کرد کاربران در حدود 250 مورد، با یکدیگر، قابل سازگاری نبود و تسویه نمی‌شد. موضوع دیگر که در این جابه‌جایی داده وجود داشت، از آنجا که در MVP برخی قابلیت به تدریج اضافه شده بودند و بعضا به صورت کامل پیاده‌سازی نشده بودند، نقص از جنس قابلیت، نیز در داده‌ها مشهود بود.
این متناظرسازی داده‌ها دشوارترین و پرچالش‌ترین بخش مهاجرت داده‌ای بود.
مانورهای عملیاتی مهاجرت
قبل از هرگونه انتقال نیاز است تا فرآیند، شبیه‌سازی شود. این شبیه‌سازی در اکثر موارد باعث پیشگیری، در خیلی از خطاها خواهد شد و از غافل‌گیری تیم فنی و اعضای آن جلوگیری می‌کند در هفته منتهی به جابه‌جایی به طور روزانه، عملیان فراخوانی و بارگذاری داده‌ها انجام می‌شد و این عملیات که به طور میانگین ۴ ساعت، به طول می انجامید، از ساعت ۸ شب شروع و در حدود بامداد به اتمام می‌رسید و نتیجه در روز بعد کاری قابل ارزیابی بود. مهم‌ترین بخش این مانورها، حفظ آمادگی و رفع خطاهای ایجاد شده، برای مهاجرت بود. در این مرحله باید مانند دونده دوی ماراتن، بیشتر از اینکه به سرعت فکر کرد، به استقامت اندیشید.
در هربار اجرای پروژه مهاجرت، یک سری مشکل ریز و درشت، کشف و اصلاح می‌شد تا اینکه در آخرین روز همه داده‌ها، با همکاران کنترل کیفیت و محصول چک شد و مورد تایید قرار گرفت.
تعویق به موقع
روز پنجشنبه منتهی به مهاجرت، مصادف شده بود، با ابتدای ماه شمسی و به درخواست یکی از ذینفعان، به علت حجم بالای کار ایشان، روز مهاجرت به تاریخ یک هفته بعد، موکول شد تا ایشان بتواند، کارهای خود را با راحتی و بدون اختلال انجام دهد.
روز موعود
بعد از حدود ۲۰ روز تلاش با محوریت مهاجرت و تلاش ۴ ماهه برای تیم‌سازی و بازنویسی و جایگزینی، بالاخره روز موعود فرا رسید، قرار شد در ساعت ۱۶:۳۰ روز پنجشنبه که کم‌بارترین زمان، به لحاظ تراکنش و مراجعه کاربران پلتفرم بود، این مهاجرت شروع شود. در همان ساعت اولیه تنظیمات مربوط به جابه‌جایی آدرس دامنه و سرور انجام شده بود و به کاربران و ذینفعان پلتفرم اطلاع رسانی شده بود که اختلال در سیستم وجود خواهد داشت. اجرای نهایی پروژه مهاجرت در این ساعت شروع شد و کلیه زیرساخت‌هایی که تا این لحظه به صورت تستی، در مدار قرار داشتند، به صورت عملیاتی مورد بهره برداری قرار گرفتند
در تصویر فوق هستی کوچولو به عنوان نیروی کمکی به تیم ما اضافه شدند و باعث بهبود کلیه فرآیندهای مهاجرت شدند
سناریوی جایگزین
به منظور کم ریسک کردن تمامی مهاجرت‌ها، معمولا یک سناریوی جایگزین یا اصطلاحا plan b در نظر گرفته می‌شود. در موضوع مهاجرت ما قرار شد، در صورت ناموفق بودن مهاجرت و یا عدم تطبیق پذیری، ذینفعان، سرورهای MVP هم چنان روشن بماند و با بازگشت به آن‌ها، سناریوی مهاجرت، لغو شود
لحظه به لحظه با مهاجرت
ساعت ۱۶:۳۰ جابه‌جایی به طور رسمی شروع شد. نکته جالب این بود که همکاران مدیریت، مالی، مارکتینگ و عملیات، نیز شانه‌به‌شانه در کنار تیم‌های فنی و محصول بودند و نقش حمایتی خود را، به طرز دلگرم کننده‌ای ایفا می‌کردند. تا ساعت ۲۲:۰۰ جابه‌جایی داده‌ای به طول انجامید. بعد از جابه جایی داده‌ای مشخص شد، بخشی از داده‌ها، با اینکه به صورت درست منتقل شدند، در محیط‌های مختلف، به لحاظ نمایش دچار اختلال هستند، رفع این اختلال‌ها تا بامداد به طول انجامید.
مرحله بعد از مهاجرت تست، پنل‌های مربوط به ذینفعان بود، که این انجام این موضوع تا حدود ساعت ۱:۳۰ بامداد طول کشید.
در ساعت ۲:۰۰ بامداد تست دستگاه‌های پوز شروع شد و قرار بود که به ازای هر شرکت ذینفع، یک دستگاه پوز آن شرکت، مورد تست و تراکنش قرار بگیرد، این تست با توجه به تعدد شرکت‌ها، تا ساعت ۵:۱۰ به طول انجامید.
در نهایت با جمع بندی تمام سناریوهای ممکن به نظر می‌رسید که مهاجرت با موفقیت نهایی شده و به پایان رسیده است.
روز پایان جنگ
در چند روز اول بعد از مهاجرت، مشکلات مختلفی از قبیل عدم سازگاری ذینفعان، با نسخ وب سرور و tls و ... شناسایی شد. لازم به ذکر است که این مشکلات با فرض بروز بودن سیستم ذینفعان، قابل شناسایی نبود. برای حل این مشکلات تقریبا سه روزی درگیر بودیم و در نهایت ذینفعان نیز، با سیستم جدید انطباق پذیری پیدا کردند و پرونده این مهاجرت به پایان رسید.
درباره نام سپیدان
سپیدان نامی است، یادآور رنگ سپید مظهر پاکی و همین طور شهری است برف خیز، از توابع استان فارس که در اکثر اوقات سال پوشیده از برف می‌باشد و از این جهت واسطه خیر و برکت به سایر شهرها نیز می‌باشد.
دیدگاه‌ها
افزودن دیدگاه جدید