اگر در بخش فناوری اطلاعات یک دانشگاه کار کرده باشید یا در ایام امتحانات پای سیستم نشسته باشید، احتمالاً این صحنه برایتان تکراری و آشناست: ساعت ۹:۰۰ صبح روز اول امتحانات پایان‌ترم است. چند هزار دانشجو دقیقاً در همان لحظه صفحه آزمون را باز می‌کنند. چند ثانیه لودینگ مداوم، سپس صفحه سفید و بعد از آن نمایش خطای معروف 502 Bad Gateway یا Connection Timeout. تلفن‌های مرکز فاوا بی‌وقفه به صدا درمی‌آیند، اساتید بلاتکلیف می‌مانند و گروه‌های دانشجویی پر از استرس و اعتراض می‌شود.
این بحران یک اتفاق غیرمنتظره یا باگ تصادفی نیست؛ بلکه نتیجه نادیده گرفتن چند اصل ساده اما حیاتی در مهندسی نرم‌افزار و معماری زیرساخت سامانه‌های آموزشی (LMS) است.
در ادامه، ۳ دلیل فنی اصلی این اختلالات و معیارهای یک معماری تاب‌آور را بررسی می‌کنیم.
ترافیک دانشگاه در طول ترم خطی و آرام است، اما در ایام امتحانات به شکل ضربتی منفجر می‌شود. بسیاری از دانشگاه‌ها به دلیل توجیه اقتصادی، به سراغ پلتفرم‌های ابری عمومی یا اشتراکی (SaaS) می‌روند.
در این ساختارها، منابع پردازنده (CPU) و رم میان چندین مجموعه تقسیم می‌شود. وقتی هزاران کاربر در یک ثانیه روی دکمه شروع آزمون یا ثبت پاسخ کلیک می‌کنند، کوئری‌های سنگین به دیتابیس سرازیر می‌شوند. اگر سیستم فاقد مکانیزم توزیع بار (Load Balancing) باشد، دیتابیس دچار قفل‌شدگی متقابل (Deadlock) شده و پردازنده به سقف ۱۰۰ درصدی می‌رسد؛ پیامد این زنجیره، کرش کامل سرویس است.
در بسیاری از سیستم‌های معمولی و نسخه‌های بهینه‌نشده، با هر پاسخ دانشجو، یک درخواست مستقیم برای نوشتن روی دیتابیس اجرا می‌شود. تصور کنید ۴ هزار دانشجو در یک آزمون ۴۰ سؤالی شرکت کنند؛ در کمتر از نیم ساعت ۱۶۰ هزار تراکنش متمرکز به سرور تحمیل می‌شود.
یک ساختار مهندسی‌شده به‌جای اتصال مستقیم هر درخواست به دیتابیس، از معماری صف‌بندی (Queueing) و کش لایه‌ای استفاده می‌کند. در این الگو، پاسخ‌ها ابتدا در لایه حافظه موقت مهار و تجمیع شده و سپس با یک جریان کنترل‌شده در پایگاه داده ثبت می‌شوند. همین اصلاح به ظاهر ساده، مصرف CPU را تا ۴۰ درصد کاهش می‌دهد و پایداری آزمون را حفظ می‌کند.
یکی از دلایل اختلال در روزهای آزمون، عدم تطابق داده‌های آموزشی با سامانه جامع دانشگاهی (مانند گلستان) است. جابه‌جایی دستی فایل‌های حجیم اکسل برای انتقال لیست دروس و مشخصات دانشجویان، علاوه بر احتمال خطای انسانی در ثبت کدهای هویتی، فشار پردازشی بالایی هنگام ایمپورت به سرور تحمیل می‌کند.
استفاده از وب‌سرویس‌های مستقیم و زمان‌بندی‌شده (RESTful API) بین سامانه آزمون و سیستم جامع آموزشی، انتقال داده‌ها را به جای عملیات حجیم و ناگهانی، به تبادلات سبک و خودکار در کسری از ثانیه تبدیل می‌کند و احتمال خطای Timeout را برطرف می‌سازد.
در مقیاس دانشگاهی، نگهداری سوابق امتحانی بر روی سرورهای اشتراکی یا ابری خارجی ریسک حاکمیت داده و وابستگی به اینترنت بین‌الملل را بالا می‌برد. استقرار محلی سامانه روی سرورهای داخلی سازمان، تضمین می‌کند که حتی در صورت بروز هرگونه اختلال در شبکه جهانی اینترنت، آزمون‌ها بدون وقفه روی بستر شبکه داخلی (اینترانت) به کار خود ادامه دهند.
«من گزینه را انتخاب کردم ولی ثبت نشد» یا «اینترنتم قطع شد»؛ این‌ها پرتکرارترین اعتراضات پس از هر امتحان آنلاین هستند.
در یک سیستم ارزیابی استاندارد، داده‌ها باید فراتر از صرفاً ساعت ورود و خروج ثبت شوند. سیستم لاگ‌گیری دقیق باید لحظه دقیق هر کلیک، زمان جابه‌جایی میان سؤالات، ذخیره‌سازی خودکار (Auto-Save) و نوسانات کیفیت اتصال کاربر را با دقت ثانیه ثبت کند. این شفافیت فنی باعث می‌شود تیم آموزش بتواند بر مبنای فکت و دیتای مستند درباره اعتراضات تصمیم بگیرد، نه حدس و گمان.
کلام آخر: پایداری یک سامانه دانشگاهی در روز امتحان، صرفاً با ارتقای سخت‌افزار یا خرید سرورهای گران‌قیمت حل نمی‌شود؛ بلکه نیازمند معماری نرم‌افزاری بهینه، مکانیزم مهار صف، ارتباط ماشینی داده‌ها و استقرار اختصاصی است. وقتی پای ارزیابی هزاران دانشجو در میان است، زیرساخت فناوری دیگر یک ابزار جانبی نیست، بلکه شالوده اعتبار آموزش به شمار می‌رود.
