TeacherFlow

Промышленная эксплуатация

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

Текущая версия TeacherFlow — рабочий MVP на выделенной инфраструктуре с HTTPS, мониторингом готовности сервиса и автоматическим контролем качества генерации при обновлениях. Ниже — что это значит для школы и партнёра и что планируется для устойчивой эксплуатации и роста нагрузки.

Текущее состояние

  • Веб-приложение: teacherflow.ru
  • API: api.teacherflow.ru
  • Публичные раздачи: share.teacherflow.ru
  • Асинхронная генерация с ограничением одновременных обращений к языковой модели
  • Защита от повторного запуска одного и того же комплекта (идемпотентность запросов)
  • Бюджет времени на один комплект генерации, чтобы интерфейс не «зависал» бесконечно
  • Эталонный набор как обязательный контроль перед релизом

Это достаточно для пилота 1–2 школ и демонстрации кейса. Для десятков школ и сотен параллельных генераций нужны шаги из следующих разделов.

Масштабируемость и надёжность

Уже заложено:

  1. Очередь генерации в фоне — учитель видит статус, а не блокирующее окно.
  2. Лимит параллельных запросов к GigaChat — защита от перегрузки провайдера.
  3. Повторные запросы с теми же параметрами не создают дубликатов комплектов.

План при росте нагрузки:

  1. Горизонтальное масштабирование API и при необходимости выделенная очередь задач.
  2. Redis (или аналог) — общие rate limits между воркерами, кэш результата анализа эталона; в MVP лимиты in-process, данные генерации в PostgreSQL.
  3. Кэширование разбора эталона при повторной генерации вариантов к тому же заданию.
  4. Пакетные проверки и шаблоны для типовых числовых задач — снижение времени и стоимости.
  5. Нагрузочное тестирование: десятки учителей, параллельные генерации, мониторинг задержек модели.

Цель — чтобы пиковая нагрузка (например, вечер перед контрольной) не приводила к отказам и непредсказуемым таймаутам.

Безопасность и данные

Уже в базе:

  1. Вход по JWT, HTTPS на всех публичных доменах.
  2. Секреты (ключи API, пароли БД) только в защищённом окружении сервера и CI, не в открытом коде.
  3. Минимизация персональных данных в MVP: в классе хранится отображаемое имя, которое вводит учитель; нет обязательных полей «ФИО по паспорту», телефонов родителей, адресов.
  4. Correlation ID в запросах — для разбора инцидентов по логам.

Перед массовым школьным пилотом:

  1. Оформленная политика обработки данных и соответствие требованиям к работе с несовершеннолетними (в т.ч. 152-ФЗ) — согласование с юристами и школой.
  2. Сроки хранения классов, назначений и логов; процедура удаления по запросу.
  3. Регулярный аудит зависимостей и ротация ключей доступа к модели.
  4. Регламент реагирования на инциденты (сбой модели, утечка, недоступность).

Подробнее о границах продукта для заказчика — в разделе Границы и честные ожидания.

Качество и сопровождение

  1. Эталонный набор и антипримеры — обязательный gate на каждом релизе, меняющем генерацию или проверки.
  2. Расширение эталонного набора перед обещанием «того же качества» на новый класс или предмет.
  3. Runbook для команды: что делать при деградации GigaChat, как включить упрощённый режим, как сообщить школе.
  4. Статус-страница или канал для администратора школы при плановых работах.

Методика качества — в статье Методология контроля сложности.

Организационный контур

  1. Пилот 1–2 школы → сбор метрик и обратной связи → доработки → расширение.
  2. Согласование с методистами — особенно перед этапами диагностики и дозадач (см. План развития).
  3. Документация для администратора — развёртывание, резервное копирование БД, восстановление (для self-hosted или выделенного инстанса партнёра).
  4. Интеграции (экосистема СберОбразования, электронный журнал, экспорт в привычные форматы) — после подтверждённой ценности в пилоте, не как условие первого запуска.

API для партнёров

REST API на api.teacherflow.ru позволяет в перспективе встраивать генерацию и назначение в другие платформы. Для пилота достаточно веб-интерфейса; интеграционные проекты — с отдельным техническим согласованием и SLA.

Доступ к API и схема — в статье Ресурсы и доступ.

Что обсудить перед подписанием пилота

  • Кто в школе ответственный за ввод имён в класс (и в каком виде — псевдонимы допустимы).
  • Нужен ли только генератор или также сценарий раздачи и ключей.
  • Ожидания по хранению данных и срокам.
  • Метрики успеха пилота (время, доля принятых без правок, опрос учителя).
  • Контакт для эскалации при сбоях.

Эти пункты согласуются до старта, без обещаний, не подкреплённых измерением.