Онлайн-школа выросла до 300 уроков: когда пора съезжать с чужой платформы

MAATRIX

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

Почему платформа дорожает быстрее, чем растёт польза от неё

Готовые платформы для онлайн-школ почти всегда считают тариф не за «доступ к системе», а за объём: число активных учеников, гигабайты видео, количество уроков или потоков, иногда — процент с продаж курсов. Это логично с точки зрения платформы: чем больше вы храните и продаёт, тем больше нагрузки на её инфраструктуру. Но для школы это означает, что рост — который вроде бы должен приносить больше денег — одновременно тянет за собой рост расходов на инструмент, причём не линейно, а часто ступенчато: перешли границу в 200 активных учеников — переехали на следующий тарифный план, который дороже не на 10%, а сразу в полтора раза.

Проблема в том, что структура затрат у платформы и у собственного сервера принципиально разная. У платформы расходы школы растут вместе с масштабом. У сервера — нет: аренда VPS или выделенной машины стоит одну и ту же сумму в месяц независимо от того, 300 у вас уроков или 600, 500 учеников или 5000 (в разумных пределах, пока хватает ресурсов конкретной конфигурации). Это классическая экономика «переменные издержки против постоянных»: на старте переменные издержки платформы ниже, потому что вы платите только за то, чем реально пользуетесь. Но кривая расходов платформы растёт вместе с масштабом, а кривая расходов сервера — почти горизонтальная линия. Где-то они пересекаются, и после этой точки свой сервер обходится дешевле.

Число «300 уроков» в заголовке — не магический порог, а иллюстрация масштаба, при котором эта точка обычно уже пройдена. У кого-то она наступает раньше, при 100 уроках и активном сообществе учеников с большим трафиком видео. У кого-то — позже, если школа продаёт немного, но дорого, и объём контента растёт медленнее числа учеников. Смотреть нужно не на количество уроков само по себе, а на то, как ведёт себя ваш конкретный счёт от платформы месяц к месяцу.

Что именно тянет тариф вверх на масштабе

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

Видео. Уроки — это в первую очередь видео, а видео — это гигабайты. Курс из 300 уроков в приличном качестве (даже не 4K, обычный 1080p с нормальным битрейтом) — это уже сотни гигабайт исходников и ещё больше после того, как платформа сделает несколько версий под разные скорости соединения. Хранение и раздача видео — самая тяжёлая по трафику часть инфраструктуры школы, и именно за неё платформы обычно берут больше всего.

Активные ученики. Многие платформы считают тариф не по общему числу зарегистрированных, а по тем, кто заходит в систему за расчётный период. Растущая школа с потоками, марафонами и постоянным набором новых учеников почти всегда упирается именно в этот лимит быстрее, чем ожидает владелец.

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

Интеграции и автоматизация. Рассылки по ученикам, вебхуки в CRM, автоматические напоминания о дедлайнах — на многих платформах это отдельные надстройки с отдельной оплатой, которые на старте казались опцией «на будущее», а на масштабе становятся необходимостью.

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

Как посчитать свою точку перехода

Прежде чем переезжать, стоит на бумаге (или в таблице) сравнить не абстрактные «сервер дешевле», а конкретно свои цифры за последние три-четыре месяца.

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

Дальше прикиньте стоимость своей инфраструктуры на тот же объём контента и нагрузки: сервер под LMS и базу данных, отдельное хранилище под видео (или объектное хранилище S3-совместимого типа), трафик на раздачу видео ученикам, и время администратора или подрядчика на поддержку — это тоже расход, его нельзя обнулять просто потому, что раньше эту работу делала платформа бесплатно для вас.

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

Что нужно поднять на своём сервере вместо платформы

Переход не сводится к «арендовать VPS и залить файлы» — платформа для онлайн-школы закрывает сразу несколько функций, и на своей стороне их нужно собрать из компонентов.

Система управления обучением (LMS). Есть зрелые open-source варианты — Moodle, Open edX, Chamilo — с курсами, тестами, прогрессом учеников, ролями преподавателя и куратора. Moodle разворачивается контейнером без экзотики:

version: "3.8"
services:
  moodle-db:
    image: mariadb:11
    environment:
      MYSQL_ROOT_PASSWORD: change_me
      MYSQL_DATABASE: moodle
      MYSQL_USER: moodle
      MYSQL_PASSWORD: change_me_too
    volumes:
      - moodle_db:/var/lib/mysql

  moodle:
    image: bitnami/moodle:latest
    depends_on:
      - moodle-db
    environment:
      MOODLE_DATABASE_HOST: moodle-db
      MOODLE_DATABASE_NAME: moodle
      MOODLE_DATABASE_USER: moodle
      MOODLE_DATABASE_PASSWORD: change_me_too
    ports:
      - "8080:8080"
    volumes:
      - moodle_data:/bitnami/moodledata

volumes:
  moodle_db:
  moodle_data:

Это отправная точка, не готовый к продакшену конфиг — пароли нужно вынести в .env или секреты, а перед боевым запуском добавить обратный прокси с TLS.

Хранение и раздача видео. Хранить исходники можно прямо на диске сервера или в объектном S3-совместимом хранилище — второй вариант удобнее, если видео много и вы хотите разделить вычислительный сервер (LMS, база) и хранилище. Раздавать лучше не прямыми ссылками на файлы, а через сервис с ограниченным доступом: подписанные временные URL, чтобы ссылка на урок не гуляла по чатам вечно. Простой пример проверки подписи на уровне nginx с модулем secure_link:

location /videos/ {
    secure_link $arg_token,$arg_expires;
    secure_link_md5 "$secure_link_expires$uri secret_key_here";

    if ($secure_link = "") { return 403; }
    if ($secure_link = "0") { return 410; }

    root /data/lessons;
}

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

Хранилище материалов и файлов для кураторов. Помимо самой LMS, школе обычно нужно общее пространство для методичек, шаблонов, записей эфиров — тут хорошо ложится Nextcloud поверх того же сервера или соседней машины.

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

#!/bin/bash
DATE=$(date +%F)
mysqldump -u moodle -p'change_me_too' moodle | gzip > /backups/moodle-db-$DATE.sql.gz
tar czf /backups/moodledata-$DATE.tar.gz /bitnami/moodledata
find /backups -mtime +14 -delete

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

План переезда без потери учеников

Переезд онлайн-школы — это не только про технику, но и про то, чтобы действующие ученики не заметили сбоя посреди курса.

1. Поднимите новый сервер параллельно со старой платформой. Разверните LMS, залейте тестовый курс, проверьте видео, тесты, прогресс — всё это должно работать до того, как вы тронете боевые данные.
2. Выгрузите данные с платформы заранее. Экспорт курсов, видео, базы учеников и их прогресса — обычно доступен через панель платформы или её API. Уточните формат заранее: часть платформ отдаёт прогресс учеников не полностью или требует ручного запроса поддержке, и это может занять дни, а не часы.
3. Мигрируйте контент и проверьте на тестовых аккаунтах. Залейте видео, соберите структуру курсов, создайте несколько тестовых учеников и пройдите урок от начала до конца — включая оплату, если она тоже переезжает на свою сторону.
4. Запустите период параллельной работы. Одна-две недели, когда старая платформа ещё доступна для текущих потоков, а новые ученики уже идут на свой сервер. Это снижает риск и даёт время заметить нестыковки.
5. Переключите точки входа. Домен, ссылки в рассылках, кнопки на лендинге — переводите постепенно, начиная с наименее чувствительных к простою потоков.
6. Держите план отката. Пока не пройдёт хотя бы один полный поток на новой инфраструктуре, экспорт со старой платформы не удаляйте — это ваша страховка.

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

Ограничения: что своя инфраструктура не решает сама по себе

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

Готовые платформы часто включают встроенные инструменты приёма оплат, антипиратскую защиту видео (водяные знаки, привязку к устройству), готовую аналитику по воронке продаж и поддержку 24/7. На своём сервере всё это либо собирается из отдельных сервисов и библиотек, либо требует, чтобы кто-то в команде школы взял на себя администрирование — обновления LMS, мониторинг, реакцию на инциденты. Это не разовая работа, а постоянная, и её стоимость нужно закладывать в расчёт точки перехода из третьего раздела, а не считать нулевой только потому, что раньше её незаметно делала платформа.

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

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