Главная / Кейсы / Муниципальная платформа обучения безопасности

Образование / сайт + платформа курсов

Городская платформа обучения безопасности

Единая городская точка входа в обучение безопасности: обучение, аттестация и учёт в одном контуре.

Предыстория

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

Управлению образования нужна единая точка входа, чтобы рассылать курсы и видеть, как они внедрены в школах.

Нужно учитывать и сетевые условия школ — требовать от каждой школы расширения канала нельзя.

Решение

Поставлена муниципальная платформа обучения безопасности: курсы, онлайн-оценка, записи об обучении и статистические отчёты.

Курсы классифицируются по ступени обучения и теме; школы могут выбирать обязательные и факультативные курсы.

Записи об обучении автоматически собираются в личное дело и прослеживаются между учебными годами.

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

Технический состав

В таблице ниже — технические элементы проекта, по ним клиент может проверить всё самостоятельно.

Технологический стек

ФронтендСерверный рендеринг Next.js

МодульОбучение по курсам · Онлайн-тестирование · Учёт обучения · Отчётность

ПроизводительностьСерверный рендеринг, работает при слабой сети

СтатистикаМногоуровневая детализация по району / школе / классу

Результаты

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

Используемые компетенции

Обсудить похожий сценарий

01 / Ограничения

В каких ограничениях выполнялся проект

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

Эти ограничения напрямую определяют облик решения: каждая проблема в разделе «Ключевые сложности» ниже вызвана одним из них.

Четыре вида ограничений

ОбъёмЕдиная точка входа для всех школ города — от городских районов до посёлков.

АккаунтУчётные записи учеников и учителей должны интегрироваться с существующей системой учёта учащихся; дублировать их нельзя.

ИспользованиеПики использования приходятся на начало учебного года и Месяц безопасности: мгновенная нагрузка в десятки раз выше обычной.

УдержаниеЗаписи об обучении должны храниться между учебными годами, а не обнуляться ежегодно.

02 / Ключевые сложности

Что действительно тормозит

Это не «мы очень старались», а «как выглядела проблема, как мы её решили и какой ценой».

Как аккаунты интегрируются с системой учёта учащихся

Если заводить отдельные учётные записи, переводы, выпуски и приём новичков пришлось бы вести вручную — сотни школ просто не охватить.

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

Пик нагрузки в начале учебного года не выдерживается

В первую неделю первого семестра платформа заметно тормозила в часы пиковых входов.

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

Как хранить записи за несколько учебных лет

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

Как решили: организовали данные по человеку, а не по учебному году — одна основная запись на учащегося, а данные по годам прикреплены к ней. Архивирование только помечает, но не удаляет, а при запросе запись раскрывается по необходимости.

03 / Переиспользуемые решения

Что можно напрямую перенять в других проектах

Этот раздел — для коллег по отрасли. Если вы делаете нечто подобное, эти пункты избавят вас от лишних обходных путей.

Основной источник данных — система учёта учащихся

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

Заблаговременное выделение ресурсов к пиковым нагрузкам

Нагрузка на образовательные платформы импульсная: если рассчитывать на среднюю, система обязательно упадёт.

Данные по человеку, а не по учебному году

Запросы за несколько учебных лет — очень частая потребность, поэтому модель данных с самого начала должна строиться вокруг человека.

04 / Разбор итогов

Если бы делали заново

Рассказывать только об успехах — неискренне. Этот раздел о том, где мы ошиблись или опоздали.

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

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

Адаптацию под мобильные сделали поздно. Дизайн был рассчитан на ПК, но многие учащиеся пользуются телефонами, поэтому позже добавили мобильную версию.

← Все кейсы На главную