راهاندازی مودل برای یک مدرسه با چند صد دانشآموز و راهاندازی آن برای دانشگاه، از نظر ابزار یکی است ولی از نظر مهندسی دو کار متفاوت. در دانشگاه، تعداد درسهای موازی، همزمانی کلاسهای زنده، آزمونهای همزمان و حساسیت گزارشهای حضور و نمره باعث میشود «کار کردن» بهتنهایی کافی نباشد؛ سامانه باید قابل پیشبینی، قابل پایش و قابل رشد باشد.
LMS دانشگاه با LMS مدرسه چه فرقی دارد؟
- همزمانی بالاتر: زمانبندی کلاسها و آزمونها باعث میشود در چند بازه مشخص هفته، ترافیک چند برابر شود.
- کلاس زنده چندگانه: دهها کلاس همزمان با ضبط، روی یک سرور تنها معمولاً به گلوگاه میرسد.
- الزام گزارشپذیری: حضور و غیاب، سابقه ورود و گزارشهای قابل ممیزی برای مدیر آموزش و گروهها ضروری است.
- ساختار سازمانی: دانشکده، گروه، استاد، دستیار آموزشی و دانشجو؛ یعنی نقشها و دسترسیها دقیقتر تعریف میشوند.
پیش از هر چیز: برآورد کاربران و الگوی استفاده
سه عدد را از معاونت آموزشی بگیرید؛ بدون آنها هر طراحی سرور حدسی است:
- تعداد کل کاربران فعال (دانشجو، استاد، کارمند).
- بیشینهٔ کاربران همزمان در سایت (معمولاً ساعات اوج کلاس یا آزمون).
- بیشینهٔ کلاسهای زندهٔ همزمان و اندازهٔ بزرگترین کلاس.
عدد دوم بار سرور مودل را تعیین میکند و عدد سوم بار سرور کلاس زنده را. این دو را جدا از هم محاسبه کنید، چون روی سرورهای متفاوت اجرا میشوند. برای جزئیات بیشتر درباره برآورد کلاس زنده به ظرفیت سرور بیگبلوباتن مراجعه کنید.
معماری پیشنهادی: وب، پایگاهداده، فایل و کلاس زنده
برای مقیاس دانشگاهی، جداسازی نقشها بهجای یک سرور «همهکاره»، هم پایداری را بالا میبرد و هم عیبیابی را ساده میکند:
- سرور وب/اپلیکیشن با PHP-FPM و کش (مثلاً Redis یا Memcached) برای نشستها و کش برنامه.
- سرور پایگاهداده مستقل یا با منابع اختصاصی، با پشتیبانگیری منظم.
- ذخیرهسازی moodledata سریع و دارای پشتیبان، چون هر فایل بارگذاریشده و ضبط در آن میماند.
- سرور(های) کلاس زنده کاملاً جدا از سرور مودل.
- کرون سیستمی برای کارهای زمانبندیشده؛ بدون آن، همگامسازی ضبطها و اعلانها دچار تأخیر میشود.
راهنمای مقیاسپذیری و کارایی مودل جزئیات تنظیمات کش و پایگاهداده را توضیح داده است.
کلاس زنده در مقیاس دانشگاه
وقتی کلاسهای همزمان زیاد میشود، دو راه معمول وجود دارد:
- چند سرور بیگبلوباتن در یک مودل. با ماژول بیگبلوباتن چندسروری تا ۶ سرور تعریف میشود، مدرس هنگام ساخت کلاس سرور را انتخاب میکند و مدیر در گزارش سرورها میبیند هر سرور چقدر پر است. اگر کلاسی به سرور دیگر منتقل شود، ضبطهای قبلی همچنان از همان سرور قبلی پخش میشوند.
- سرویس مدیریتشده کلاس مجازی. اسکایروم با یک وبسرویس به مودل وصل میشود و نگهداری سرور کلاس را از دوش شما برمیدارد؛ در عوض سقفها و اعتبار سرویس مطرح است که داشبورد مدیر آن را نشان میدهد.
مقایسهٔ دقیق این دو انتخاب در مقالهٔ اسکایروم یا بیگبلوباتن؟ آمده است. اگر چند سرور دارید، مانیتورینگ زندهٔ سرورها نیز دید لحظهای مدیر را کامل میکند.
ثبتنام، هویت و گزارشگیری
- ورود و ثبتنام: در دانشگاههایی که کاربر از سامانه آموزش وارد میشود، ایجاد خودکار حساب یا همگامسازی کاربران اهمیت دارد. برای ثبتنام آزاد، ثبتنام با پیامک هزینهٔ پیامک را با سقفهای قابلتنظیم کنترل میکند.
- حضور و غیاب: حتماً قبل از ترم مشخص کنید «حضور» به چه معناست (ورود به کلاس، ماندن در کلاس، یا پاسخگویی) و گزارشها را بر همان اساس بخوانید. جزئیات در حضور و غیاب آنلاین در مودل.
- دسترسیها: نقشهای سفارشی برای مدیر گروه و دستیار آموزشی تعریف کنید، بهجای اینکه به همه «مدیر سایت» بدهید.
چکلیست اجرا در شش مرحله
- نیازسنجی: سه عدد برآورد و فهرست فرایندهای آموزشی که باید آنلاین شوند.
- طراحی زیرساخت: تفکیک سرورها، شبکه، دامنه و گواهی SSL، سیاست پشتیبانگیری.
- نصب و بومیسازی: فارسیسازی، تقویم شمسی، قالب و افزونهها (راهنمای فارسیسازی).
- پایلوت: یک دانشکده یا چند درس منتخب برای یک ترم یا چند هفته.
- آموزش استادان و دستیاران: قبل از شروع، نه بعد از اولین مشکل (برنامهٔ آموزش مدرسان).
- گسترش و پایش: افزودن دانشکدهها، پایش بار سرور و بازبینی دورهای امنیت (چکلیست امنیت).
برای دانشگاه یا مؤسسهٔ خود پیشنهاد فنی و زمانبندی میخواهید؟ صفحهٔ راهکار LMS برای دانشگاهها را ببینید یا درخواست مشاوره ثبت کنید.