یک توسعهدهنده ارشد فولاستک برنده جایزه در مورد اینکه چگونه تیمهای مهندسی میتوانند پلتفرمهای قدیمی را مدرن کنند، سیستمهای سازمانی را برای بارهای کاری سنگین مقیاسپذیر کنند و معماریهای انعطافپذیر را بدون از دست دادن سرعت توسعه ارائه دهند.
همانطور که سازمانها تحول دیجیتال را تسریع میکنند، بسیاری از تیمهای مهندسی در حال کشف این موضوع هستند که بزرگترین مانع آنها زیرساخت قدیمی است که هنوز به آن وابستهاند. طبق گزارش Pegasystems، 68٪ از تصمیمگیرندگان فناوری اطلاعات سازمانی میگویند پلتفرمها و برنامههای قدیمی مانع از پذیرش کامل فناوریهای مدرن توسط سازمانهایشان میشوند. برای درک بهتر اینکه چگونه تیمهای مهندسی میتوانند در عمل بر این چالشها غلبه کنند، با عبدالعزیز عبدالخالیموف، یک توسعهدهنده ارشد فولاستک برنده جایزه با بیش از یک دهه تجربه در تبدیل سیستمهای شکننده فنی به پلتفرمهای مقیاسپذیر و انعطافپذیر، گفتگو کردیم.
عبدالعزیز روشهایی برای مدرنسازی سیستمهای قدیمی برنامهریزی منابع سازمانی (ERP) و مالی در شرکت SoftClub با تبدیل آنها به میکروسرویسهای ماژولار ایجاد کرد. در Barso LLC، او یک پلتفرم سازمانی ابری بومی را توسعه داد که بیش از 100,000 کاربر را پشتیبانی میکند. او همچنین استقرار یک پلتفرم یادگیری ملی مبتنی بر Moodle را در ازبکستان رهبری کرد که دانشجویان و معلمان را قادر ساخت تا از طریق سیستمی که نیاز به عملکرد پایدار، انتشارات قابل اعتماد و تکرار سریع اما ایمن داشت، به صورت آنلاین کار کنند. در گفتگوی ما با عبدالخالیموف، درباره آنچه برای مدرنسازی پلتفرمهای قدیمی لازم است، چگونگی مقیاسپذیری سیستمهای سازمانی توسط تیمهای مهندسی بدون به خطر انداختن قابلیت اطمینان و قابلیت نگهداری سیستم، و اینکه چرا نظم معماری اغلب بیشتر از انتخاب فناوری اهمیت دارد، بحث کردیم.
عبدالعزیز، امروزه بسیاری از شرکتها تحت فشار هستند تا سیستمهای اصلی را مدرن کنند. از دیدگاه شما، بزرگترین اشتباهی که تیمها هنگام شروع مدرنسازی یک پلتفرم قدیمی مرتکب میشوند چیست؟
بزرگترین اشتباه این است که به مدرنسازی به عنوان یک ارتقای فناوری به جای یک تصمیم معماری حیاتی کسبوکار نگاه میشود. بسیاری از تیمها با این ایده شروع میکنند که به سادگی نیاز دارند از یک مونولیت به میکروسرویسها، یا از زیرساخت محلی به کانتینرها منتقل شوند، بدون اینکه ابتدا درک کنند که نقاط درد عملیاتی واقعی کجاست.
در عمل، سیستمهای قدیمی معمولاً قبل از اینکه در مقیاس شکست بخورند، در برابر تغییر شکست میخورند. مسئله اغلب این نیست که پلتفرم نمیتواند اجرا شود، بلکه این است که هر ویژگی جدید، رفع اشکال یا یکپارچهسازی کندتر، پرخطرتر و سختتر برای آزمایش میشود. اگر یک تیم مدرنسازی را تنها با تمرکز بر ابزارها شروع کند، ممکن است در نهایت همان مشکلات را به شکل توزیعشدهتر بازسازی کند.
نقطه شروع بهتر این است که مشخص شود سیستم فعلی در کجا بیشترین اصطکاک را ایجاد میکند: گلوگاههای انتشار، ماژولهای محکم به هم متصل، وابستگیهای ناپایدار، یا نواحی که عملکرد و قابلیت نگهداری از قبل در تضاد هستند. وقتی این نقاط فشار روشن شدند، مدرنسازی منظمتر میشود. دیگر یک تلاش مهاجرت مبهم نیست و به یک توالی از تصمیمات مهندسی هدفمند تبدیل میشود.
شما در اوایل حرفه خود در چالش دادههای باز رتبه اول را کسب کردید و در چالش بهترین نرمافزار رتبه برتر را دریافت کردید. این تجربیات چگونه شیوه رویکرد شما به مسائل مهندسی در مقیاس بزرگ را شکل داد؟
رقابت در آن مرحله از شغلم به من کمک کرد تا عادت تفکر فراتر از یک راهحل فنی سریع را ایجاد کنم. یاد گرفتم که نگاه کنم چگونه یک راهحل با افزایش پیچیدگی، وابستگی افراد بیشتر به آن، و نیاز سیستم به تکامل مداوم، پایدار میماند. این دیدگاه در کار حرفهای با من ماند. به جای تمرکز بر آنچه مد روز است، ابتدا نگاه میکنم که آیا یک سیستم به وضوح ساختاریافته است، آیا میتواند بدون اصطکاک مداوم پشتیبانی شود، و آیا با افزایش تقاضاها قابل اعتماد باقی خواهد ماند.
در شرکت SoftClub، شما روی مدرنسازی سازمانی کار کردید و به مهاجرت سیستمهای قدیمی ERP، مالی و منابع انسانی به میکروسرویسهای ماژولار کمک کردید. کار شما منجر به برنامههای سازمانی مقیاسپذیرتر، بهبود قابلیت نگهداری و پذیرش گستردهتر رایانش ابری شد. چگونه تعیین میکنید که آیا یک مونولیت هنوز باید به تدریج بازسازی شود؟
آن تجربه به من آموخت که تصمیم به این بستگی دارد که آیا سیستم موجود هنوز میتواند به ماژولهای معنادار بدون شکستن منطق کسبوکار تقسیم شود. چالش اصلی معمولاً تنها سن نیست. بلکه تراکم وابستگیهایی است که در طول زمان ایجاد شدهاند.
اگر سیستم هنوز به شما اجازه میدهد نواحی عملکردی را جدا کنید، رابطها بین آنها را پایدار کنید، و یک بخش را بدون مزاحمت مداوم بقیه بهبود دهید، پس بازسازی تدریجی معمولاً مسیر قویتر است. این رویکرد به ویژه زمانی مفید است که پلتفرم برای کسبوکار حیاتی است و نمیتواند ریسک تحویل جایگزینی همه چیز به یکباره را تحمل کند. بازنویسی کامل زمانی واقعبینانهتر میشود که معماری دیگر از مرزهای واضح پشتیبانی نکند، وقتی یک تغییر به طور پیوسته در نواحی نامرتبط گسترش مییابد، و زمانی که قابلیت نگهداری حتی پس از بهبودهای هدفمند همچنان کاهش مییابد. در آن وضعیت، سیستم دیگر به مدرنسازی به عنوان یک توالی از مراحل کنترلشده پاسخ نمیدهد.
بنابراین آزمون واقعی این نیست که آیا مونولیت قدیمی است. بلکه این است که آیا هنوز کنترل ساختاری کافی را به تیم مهندسی میدهد تا مقیاسپذیری و قابلیت نگهداری را در بخشها بهبود دهد. اگر آن کنترل هنوز وجود دارد، بازسازی کار میکند. اگر از بین رفته است، بازنویسی تصمیم بلندمدت امنتر میشود.
به عنوان یک توسعهدهنده ارشد فولاستک در Barso LLC، شما به ساخت یک پلتفرم سازمانی ابری بومی کمک کردید که عملکرد سیستم را 40٪ بهبود بخشید. بر اساس آن تجربه، کدام عوامل کشنده عملکرد خاموش را در یک محیط Spring Boot بیشتر مشاهده میکنید؟
بسیاری از مشکلات عملکرد توسط الگوریتمها ایجاد نمیشوند بلکه توسط تصمیمات معماری ایجاد میشوند.
یک مشکل رایج عملیات مسدودسازی پنهان است. یک سرویس ممکن است ناهمزمان به نظر برسد اما همچنان به تماسهای مسدودشده پایگاه داده یا APIهای خارجی متکی باشد. تحت ترافیک سنگین، این تماسها استخرهای رشته را مصرف میکنند و باعث تأخیرهای پیوسته میشوند. مشکل مکرر دیگر ارتباط بیش از حد بین سرویس است. میکروسرویسها گاهی اوقات بیش از حد پرحرف میشوند، با چندین تماس همزمان در داخل یک درخواست کاربر. حتی یک تاخیر کوچک در هر تماس به سرعت تجمع مییابد. الگوهای دسترسی به پایگاه داده نیز اهمیت دارند. کوئریهای ناکارآمد، فهرستهای از دست رفته، یا استفاده بیش از حد از ORM میتوانند گلوگاههایی ایجاد کنند که فقط تحت بار تولید ظاهر میشوند. در نهایت، قابلیت مشاهده اغلب دست کم گرفته میشود. بدون معیارها و ردیابی مناسب، تیمها برای شناسایی اینکه کدام مؤلفه واقعاً باعث کاهش عملکرد میشود، دچار مشکل میشوند. مهندسی عملکرد با دید شروع میشود.
شما یک معماری رویداد محور با استفاده از Apache Kafka و RabbitMQ توسعه دادید تا از پلتفرمی که بیش از 100,000 کاربر فعال را پشتیبانی میکند، حمایت کنید و مقیاسپذیری، تحمل خطا و قابلیت اطمینان سیستم را بهبود بخشید. از تجربه شما، در چه شرایطی معماری رویداد محور واقعاً انعطافپذیری و مقیاسپذیری را تقویت میکند؟
سیستمهای رویداد محور زمانی قدرتمند هستند که سرویسها باید به صورت منفصل باقی بمانند و در عین حال اطلاعات حیاتی را مبادله کنند. برای مثال، اگر چندین زیرسیستم به یک رویداد، مانند یک تراکنش مالی یا فعالیت کاربر، وابسته باشند، انتشار آن رویداد به یک کارگزار پیام به هر سرویس اجازه میدهد آن را به طور مستقل پردازش کند. این وابستگیهای مستقیم بین سیستمها را کاهش میدهد.
مزیت دیگر انعطافپذیری است. اگر یک سرویس پاییندستی به طور موقت در دسترس نباشد، پیامها میتوانند در صف قرار بگیرند و بعداً بدون از دست دادن داده پردازش شوند. با این حال، معماری رویداد نباید به صورت کورکورانه پذیرفته شود. برای گردشهای کاری که نیاز به ثبات فوری یا منطق ساده درخواست-پاسخ دارند، ارتباط همزمان میتواند واضحتر و آسانتر برای نگهداری باشد. هدف به حداکثر رساندن تعداد فناوریها در مجموعه نیست، بلکه استفاده از الگوهای ناهمزمان در جایی است که واقعاً تحمل خطا و مقیاسپذیری را بهبود میبخشند.
شما استقرار یک پلتفرم یادگیری الکترونیکی مبتنی بر Moodle را در سراسر ازبکستان رهبری کردید که دانشگاهها را قادر ساخت به تدریس از راه دور ادامه دهند و شناخت وزارت آموزش عالی را به دست آورید. وقتی یک پلتفرم ناگهان نیاز به خدمترسانی به تعداد زیادی از دانشآموزان و معلمان دارد، تیمهای مهندسی چگونه سرعت را با قابلیت اطمینان متعادل میکنند؟
چنین شرایطی تیمها را وادار میکند که ثبات و دسترسی را بالاتر از معماری کامل اولویتبندی کنند.
یک اصل کلیدی تمرکز بر مسیر حیاتی کاربر است. برای یک پلتفرم آموزشی، این به معنای ورود به سیستم، دسترسی به دوره و ارتباط بین دانشآموزان و معلمان است. ویژگیهای ثانویه در صورت لزوم میتوانند به تعویق بیفتند. زیرساخت نیز اولویت میشود. مقیاسبندی سریع نیاز به متعادلسازی بار قابل اعتماد، بهینهسازی پایگاه داده و نظارت دقیق برای تشخیص زودهنگام خرابیها دارد.
درس دیگر این است که ارتباط واضح در داخل تیم مهندسی به اندازه خود کد مهم میشود. وقتی چرخههای استقرار تسریع میشوند، هماهنگی به جلوگیری از تغییرات متضاد که میتوانند سیستم را بیثبات کنند، کمک میکند. در محیطهای پرفشار، مهندسی به محافظ اصلی در برابر هرج و مرج تبدیل میشود.
در طول حرفه خود، شما روی مدرنسازی سیستمهای سازمانی، ساخت پلتفرمهای ابری بومی و پشتیبانی از برنامههای با بار بالا کار کردهاید. بر اساس آن پیشرفت، اصطلاح توسعهدهنده فولاستک اکنون واقعاً چه معنایی دارد؟
آنچه قبلاً کسی را توصیف میکرد که کد سمت کلاینت و سمت سرور را مدیریت میکرد، اکنون بسیار بیشتر را پوشش میدهد. این نقش به طور فزایندهای شامل دیدن چگونگی عملکرد یک محصول از ابتدا تا انتها است، از رفتار رابط و منطق برنامه تا گردشهای کاری انتشار، دید سیستم و عملکرد پس از راهاندازی. یک مهندس قوی در این فضا تنها به کدنویسی محدود نمیشود. آنها همچنین باید محیطهای ابری، خطوط لوله تحویل، رفتار زمان اجرا و جنبه عملیاتی نرمافزار را درک کنند. این شغل وسیعتر و بیشتر به چگونگی عملکرد فناوری در شرایط واقعی کسبوکار متصل شده است.
پس از کار روی پلتفرمهای سازمانی که بهبود عملکرد قابل اندازهگیری را ارائه دادند و عملیات در مقیاس بزرگ را پشتیبانی کردند، چه مشاوره عملی به مدیران ارشد فناوری (CTO) و رهبران مهندسی در مورد اولین تصمیمات مدرنسازی قبل از اینکه یک برنامه تحول خیلی بزرگ یا خیلی پرخطر شود، ارائه میدهید؟
اول، قبل از تغییرات معماری بزرگ روی قابلیت مشاهده سرمایهگذاری کنید. معیارها، لاگها و ردیابی واضح به تیمها کمک میکند درک کنند که سیستم فعلی چگونه رفتار میکند و بهبودها در کجا بیشتر مورد نیاز است.
دوم، گردش کار استقرار را زود بازطراحی کنید. خطوط لوله CI/CD قابل اعتماد آزمایش سریعتر را امکانپذیر میکنند و ترس از تغییر را کاهش میدهند.
سوم، مرزهای سرویس مناسب را بر اساس دامنههای کسبوکار به جای ماژولهای فنی شناسایی کنید. مالکیت واضح سیستمها را آسانتر برای نگهداری و مقیاس میکند.
وقتی آن پایهها وجود داشته باشد، مدرنسازی به یک فرآیند ساختاریافته به جای یک جهش پرخطر تبدیل میشود.
