Moodle: лицензия бесплатна, бюджет всё равно уходит на людей и хостинг

MAATRIX

«Moodle бесплатен» — фраза, с которой начинается почти каждое обсуждение перехода школы, вуза или корпоративного учебного центра на self-hosted LMS. И это правда: лицензия GPL не требует ни рубля ни за установку, ни за число курсов или студентов. Но команда, выбравшая Moodle из-за нулевой цены лицензии, обычно упирается в первый реальный счёт не в день установки, а в момент, когда систему нужно вывести под настоящую нагрузку — сессию, поток одновременных экзаменов, набор нового курса на тысячу человек. Разберём, из чего складывается стоимость владения self-hosted Moodle и почему «бесплатно» здесь не значит «дёшево».

Что в Moodle действительно бесплатно, а что нет

Ядро Moodle, тема Boost и большинство плагинов из каталога moodle.org распространяются под GPL — код можно скачать, поставить на любое число серверов и не платить за это никому. Это закрывает статью расходов, которая у коммерческих LMS растёт вместе с числом пользователей: лицензионный платёж отсутствует как класс.

Но лицензия — это код, а не работающая система. Чтобы Moodle реально обслуживал студентов, нужны ещё как минимум пять компонентов, за каждый из которых так или иначе платите вы:

• Сервер — VPS под веб-приложение, базу данных, кэш и очередь фоновых задач.
• Администрирование — обновления, патчи безопасности, бэкапы, мониторинг перед сессией и экзаменами.
• Кастомизация — брендированная тема, нужные плагины, интеграции (деканат, 1С, SSO).
• Техподдержка — помощь преподавателям в настройке курсов и студентам при входе.
• Масштабирование под пики — экзаменационная сессия создаёт нагрузку в разы выше обычного дня, и сервер должен её выдержать именно в этот момент, а не «в среднем по году».

Ни один пункт не указан в разделе «стоимость» на moodle.org, потому что формально это не часть продукта. Но именно они определяют, во что реально обойдётся своя LMS через полгода эксплуатации.

Сервер и стек: сколько ресурсов нужно под реальную нагрузку

Moodle — PHP-приложение (Apache или Nginx с PHP-FPM) поверх реляционной базы, чаще всего MySQL/MariaDB или PostgreSQL, с обязательным cron-заданием раз в минуту и рекомендуемым кэшем на Redis или Memcached для сессий и данных приложения. На небольшой инсталляции — школа или один факультет, несколько сотен активных студентов — хватает скромного VPS: 2 ядра CPU и 4 ГБ RAM для связки Moodle плюс база уже дают рабочую конфигурацию вне пиковых периодов.

Проблема в том, что «вне пиковых периодов» — это не про экзаменационную сессию. Одновременный тест с таймером, который проходят сотни студентов в одном окне, создаёт нагрузку другого характера: множество параллельных сессий, активная запись в базу при каждом сохранении ответа, и — если тема или плагин написаны неаккуратно — блокировки на уровне таблиц. Обычной дневной нагрузки сервер не замечает, а десятиминутный всплеск на старте экзамена укладывает интерфейс в состояние «крутится и не отвечает».

Ориентировочные уровни (зависят от числа одновременных тестов и настроек кэша — считайте отправной точкой, а не гарантией):

Общие принципы подбора конфигурации под пиковую, а не среднюю нагрузку разобраны в материале как рассчитать конфигурацию сервера под нагрузку — Moodle стоит проектировать именно так: не «сколько нужно в обычный день», а «сколько нужно в день зачёта».

Отдельная деталь, которую часто упускают при установке: cron должен запускаться действительно каждую минуту, иначе уведомления, отложенные задачи и синхронизация с внешними каталогами (LDAP, календарь) начинают отставать незаметно для администратора, но заметно для пользователей.

Администрирование: обновления и безопасность как постоянный процесс

Moodle выпускает крупные версии по собственному циклу, и каждая тянет за собой минимальные требования к версии PHP и СУБД — актуальную таблицу совместимости стоит сверять напрямую в официальной документации перед каждым апгрейдом, она меняется от релиза к релизу. Обновление минорной версии обычно проходит гладко, но мажорное — почти всегда требует тестового прогона на staging-копии перед применением на боевой системе, особенно с сторонними плагинами и кастомной темой.

Помимо версий платформы есть поток security-уведомлений: разработчики Moodle публикуют бюллетени об уязвимостях в ядре и плагинах, и следить за ними — не разовая задача, а подписка, которую кто-то должен регулярно проверять и оперативно накатывать патчи, особенно если через LMS проходят персональные данные студентов.

Резервное копирование в Moodle работает на двух независимых уровнях, и оба нужны одновременно: бэкап курсов средствами самого Moodle (формат .mbz, восстанавливает или переносит отдельный курс, но не спасает от отказа сервера) и бэкап инфраструктуры — полная копия базы, файлового хранилища moodledata и конфигурации, без которой восстановление после аварии превращается в установку с нуля.

Типовая задача в crontab для регулярного бэкапа базы данных (планировщик бэкапов курсов настраивается отдельно, в админ-панели):

0 3 * * * mysqldump -u moodle_user -p'***' moodle_db | gzip > /backups/moodle-db-$(date +\%F).sql.gz

Время, которое администратор тратит на весь этот цикл — обновления, патчи, бэкапы, разбор инцидентов — не разовое, а регулярное, и именно оно чаще всего недооценивается при расчёте бюджета на переход с коммерческой LMS. Как оценить стоимость часа такой работы и когда выгоднее нанять внешнего специалиста на почасовую ставку, разобрано в материале сколько стоит час админа и когда дешевле доплатить.

Темы и плагины: экосистема бесплатна, разработка под вашу задачу — нет

Каталог plugins.moodle.org — одна из сильных сторон Moodle: тысячи готовых расширений под самые разные задачи, от интеграции с видеоконференциями до дополнительных типов вопросов в тестах. Установка большинства из них бесплатна и занимает несколько минут через админ-панель.

Но у этой свободы есть обратная сторона, которую стоит проверять до установки, а не после инцидента:

• Совместимость с версией ядра. Не все плагины обновляются синхронно с релизами Moodle — часть перестаёт поддерживаться авторами, и после апгрейда платформы такой плагин либо ломается, либо тянет за собой непатченные уязвимости.
• Качество кода. Каталог модерируется, но не гарантирует production-уровня качества каждого плагина — тяжёлые запросы к базе в плохо написанном плагине способны просадить производительность всей системы.
• Совмещение нескольких плагинов. Конфликты между расширениями, которые по отдельности работают нормально, всплывают только при реальном использовании — тестировать связку стоит на staging-копии, а не на боевой системе.

Кастомизация темы — отдельная статья расходов. Официальная тема Boost построена на Mustache-шаблонах и SCSS, и смена логотипа с цветом укладывается в стандартные настройки. А вот полноценный брендинг — свой макет кабинета, изменённая навигация, адаптация под доступность — это уже разработка дочерней темы силами подрядчика или штатного разработчика, знакомого с Mustache и API тем Moodle.

Отдельно стоят интеграции: синхронизация с деканатом или HR-системой, вход через корпоративный SSO (SAML, LDAP), выгрузка оценок во внешнюю систему учёта. Часть закрывается готовыми плагинами аутентификации, но нетиповая интеграция почти всегда требует написания кода под API Moodle — это уже часы разработчика, а не бесплатная часть проекта.

Техподдержка для преподавателей и студентов — скрытая статья расходов

У коммерческих LMS обычно есть линия поддержки, которую пользователь получает вместе с подпиской: вопрос про настройку теста или сброс пароля студенту решает служба поддержки вендора. У self-hosted Moodle этой линии нет по умолчанию — её создаёте вы, и нагрузка на неё распределена крайне неравномерно во времени.

Основные типы обращений, с которыми реально сталкиваются администраторы Moodle:

• Преподаватели, впервые настраивающие курс. Банк вопросов, шкалы оценивания, условия доступа к материалам — интерфейс мощный, но не всегда интуитивный для человека без технического бэкграунда, и обучение занимает время до того, как преподаватель станет самостоятельным.
• Студенты в момент входа на экзамен. Забытый пароль, проблема с браузером, вопрос «не сохранился ли ответ» — если поток из сотен студентов заходит в одно окно, даже небольшой процент обращений превращается в очередь тикетов ровно тогда, когда меньше всего времени на разбор.
• Разбор спорных ситуаций после теста. Логи попыток и таймстемпы сохранения ответов против недобросовестной попытки — это требует уметь читать логи Moodle на уровне отдельной попытки, а не только «сервер жив».

Эта нагрузка плохо ложится на одного человека: администрирование сервера требует спокойного планового времени, а поддержка пользователей в пиковые дни — наоборот, готовности реагировать мгновенно. В командах с растущим числом курсов эти роли обычно разделяют: один отвечает за инфраструктуру, другой — за первую линию поддержки, хотя бы в периоды сессий.

Moodle или Open edX: не путайте два разных инструмента

Оба продукта — open source и оба относятся к LMS, поэтому их периодически сравнивают напрямую, хотя решают они разные задачи.

Moodle — традиционная LMS для школ, вузов и корпоративного обучения: курсы, банки вопросов, тесты, журнал оценок, работа с группами и потоками. Архитектура — классическое монолитное PHP-приложение на одном сервере или паре серверов за балансировщиком, и этого достаточно даже для крупного вуза с десятками тысяч студентов при правильной инфраструктуре под пиковую нагрузку сессии.

Open edX проектировался под другую задачу — массовые открытые онлайн-курсы (MOOC) с публичным набором на десятки и сотни тысяч слушателей одновременно, видео как основной формат подачи материала и темпом прохождения, не привязанным к семестрам. Архитектурно это набор взаимодействующих сервисов, а не монолит, и его развёртывание и администрирование требует заметно больше инфраструктурной экспертизы, чем у Moodle — зато он рассчитан на сценарии, для которых Moodle не проектировался изначально.

Если ваша задача — учебный процесс конкретной школы, вуза или компании с привычной механикой курсов, групп и оценок, Moodle почти всегда проще внедрить и дешевле содержать. Если задача — публичная платформа массовых открытых курсов на очень большую и разнородную аудиторию, стоит отдельно оценивать Open edX, понимая, что инфраструктурный и административный бюджет там ощутимо выше.

Считаем TCO: свой Moodle против облачных альтернатив, и когда он оправдан

Сведём статьи расходов в одну таблицу, сравнивая self-hosted Moodle на своём VPS с двумя альтернативами: официальным облачным Moodle (MoodleCloud) и типовой коммерческой SaaS LMS.

Экономия на лицензии у self-hosted варианта реальна и растёт вместе с числом студентов — на десятках тысяч пользователей разница с подпиской может быть существенной. Но она компенсируется временем на все остальные строки таблицы, и это время не разовое, а постоянное. Порог, после которого свой Moodle становится выгоднее облачных альтернатив, у каждой организации свой — зависит от числа студентов, стоимости часа администратора и того, насколько критична гибкость кастомизации. Общей цифры «с какого объёма это окупается» не существует, считайте на своих данных. Общая логика того, где у бесплатного open source прячется реальный ценник, разобрана в материале сколько стоит бесплатный open source: где прячется его ценник.

Самостоятельный хостинг Moodle имеет смысл, если совпадает несколько условий одновременно:

• Большое и растущее число студентов, на котором разница с облачной подпиской ощутима в деньгах, а не только в теории.
• Нужна глубокая кастомизация — своя тема, нетиповые интеграции, специфичные плагины, которых нет у облачных провайдеров.
• Есть кому этим заниматься — штатный администратор с опытом PHP-инфраструктуры или подрядчик на регулярной основе, а не «настроим один раз и забудем».
• Требования к хранению данных студентов делают хранение на стороннем облаке нежелательным или требующим отдельных договорных гарантий — актуально для учреждений, работающих с персональными данными несовершеннолетних, где вопрос законного размещения таких данных стоит прорабатывать заранее, а не постфактум.

И, напротив, стоит остаться на MoodleCloud или коммерческой SaaS LMS, если технической экспертизы под рукой нет, число студентов небольшое и стабильное, а перебои в период сессии критичнее разницы в подписке — брать на себя ответственность за пиковую нагрузку экзаменов без готовности её обслуживать рискованнее, чем кажется на этапе выбора платформы.

Частые вопросы