Розробка порталу навчального закладу: де ламається логіка
Портал навчального закладу майже ніколи не збирають із нуля. Розробка порталу навчального закладу частіше йде поверх того, що вже працює: розклад живе в одному сервісі, оцінки — у журналі викладача, особистий кабінет учня тягне дані з облікової системи.
Поки навантаження невелике, розбіжності непомітні, а до початку навчального року з'ясовується, що той самий студент у трьох системах — це три різні записи.
Найболючіша точка — публікація оцінок. Викладачі закривають відомості одного вечора, і портал отримує сотні одночасних запитів на перерахунок середнього балу та оновлення стрічки.
Якщо розрахунок іде в момент запиту, а не за розкладом, розклад і оцінки онлайн перестають відкриватися — рівно тоді, коли вони потрібні найбільше, а навантаження в період сесії добиває те, що залишилося.
Окрема історія — звітність. Зведення з успішності, відвідуваності та навантаження викладачів зазвичай збирають вручну: вивантаження в таблиці, зведення за групами, звірка дублікатів. У школи та закладу вищої освіти формати різні, тому той самий звіт готують заново кожного семестру.
Корінь у цього один: портал будували під конкретний навчальний рік, без фіксованих контрактів на обмін даними та без розділення читання й запису. Інтеграції робили прямими запитами до чужої бази, і будь-яка зміна структури ламає особистий кабінет.
Розбираємо, як це закривається на рівні архітектури: які контракти даних фіксуємо до старту, де ставимо кеш і чергу, щоб сесія проходила без відмов.
Що змінюється після переробки: навантаження, строки, відмови
Пікові дні передбачувані: старт семестру, публікація розкладу, сесія, прийом документів. До переробки ядра портал у ці години відповідав із затримкою, а частина запитів обривалася — заходити доводилося повторно. Окрема біда — власна авторизація в кожному модулі: збій одного сервісу вибивав користувача з інших.
Після переробки вхід став єдиним: один профіль, одна сесія, одна точка перевірки прав. Сесія не прив'язана до конкретного модуля, тому збій сервісу більше не розриває доступ до інших.
Важкі вибірки — розклад, відомості, списки груп — обчислюються заздалегідь і віддаються з підготовленого подання, а не перезбираються на кожен запит.
Ручні операції скоротилися в конкретних місцях: зарахування на курс, формування груп, вивантаження відомостей і довідок. Раніше співробітник звіряв дані між системами вручну; тепер портал проводить операцію цілком і фіксує її в журналі.
Пішов і клас відмов, пов'язаних із розсинхронізацією: коли оцінка в одному модулі вже змінена, а в іншому видно стару. Єдине джерело даних і явні правила оновлення прибрали ці розбіжності — скарги «у мене неправильні дані» перестали бути регулярними.
У вимірюваних величинах: доступність сервісу в пікові дні виходить на цільовий рівень, час відгуку під навантаженням залишається рівним, частка операцій, які співробітники закривають вручну, падає в рази. Це не одноразова акція, а нова база для нових модулів.
Варіанти реалізації: готова платформа, доопрацювання, власна збірка
Три шляхи обирають за одним критерієм: наскільки система збігається з вашим регламентом — хто веде розклад, хто має право змінювати оцінку, як пов'язані ролі учня, викладача, батька й адміністратора. Саме на цих зв'язках проявляється різниця, а не на демонстрації інтерфейсу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готова платформа для школи з налаштуванням | Типовий навчальний процес, запуск потрібен у стислий строк | Власні правила атестації та форми звітності підлаштовуються під логіку продукту, а не навпаки |
| Доопрацювання наявного порталу | Дані, ролі та історія вже в системі, потрібно наростити функції без переїзду | Багато залежить від якості попереднього коду та наявності документації: частина часу йде на розбір накопиченого |
| Розробка з нуля | Нестандартний регламент, власні обміни із зовнішніми системами та особливі сценарії доступу | Пізніше виходить перша робоча версія, вищі вимоги до постановки завдань і узгодження ролей |
Змішаний сценарій теж робочий: ядро залишається на готовій платформі, а особистий кабінет, звітність або прийом документів робимо окремим модулем і пов'язуємо з ним обмінами.
Перед вибором дивимося, що віддає поточна база: вивантаження оцінок, склад ролей, історію змін — без цього будь-який варіант упирається в ручне перенесення даних.
Як відбувається впровадження: від аудиту до передачі адміністраторам
Впровадження порталу навчального закладу відбувається етапами, і порядок тут не формальність: кожен наступний крок спирається на артефакти попереднього.
Без інвентаризації даних нема чого проєктувати, без схеми не можна налаштовувати ролі й права, а без перевірки під реальним навантаженням не можна передавати систему адміністраторам. Нижче — послідовність, за якою ми ведемо роботи, з точками контролю на кожному переході.
- Обстеження й аудит поточної системи. Знімаємо карту сервісів: як сьогодні збираються розклад, відомості, особові справи, звідки вивантажуються звіти, які операції тримаються на ручній роботі в таблицях.
- Проєктування схеми даних. Єдина модель для учнів, викладачів, груп, дисциплін, оцінок і документів, правила зв'язків і успадкування ролей. Фіксуємо, що переносимо як є, що перезбираємо, що йде в архів.
- План робіт і міграція даних. Етапи перенесення узгоджуємо до старту: звіряємо кількість записів і контрольні зрізи до й після, щоб розбіжності знаходилися на тестовому контурі, а не в перший день занять.
- Налаштування середовища. Тестовий і робочий контури, розмежування доступів за ролями, розклад резервного копіювання та перевірений порядок відкатів.
- Перевірка під навантаженням. Прогоняємо пікові сценарії — масовий вхід на початку семестру, одночасне вивантаження відомостей, роботу з документами. Знайдені вузькі місця усуваємо до запуску.
- Передача адміністраторам. Передаємо документацію, регламенти оновлення й відновлення, проводимо навчання співробітників на їхніх же завданнях.
- Супровід після запуску. Перший період навчання ведемо в посиленому режимі: стежимо за помилками, строками відгуку та коректністю звітів.
Роботи закриваються за критеріями приймання: користувач входить і бачить свої дані, відомості збігаються з перенесеними, адміністратор навчального закладу самостійно заводить групу й публікує розклад без нашої допомоги.
Що залишається у замовника: схеми, доступи, регламенти
Портал передається не «як є», а з комплектом, за яким ваша команда або інший підрядник зможе працювати автономно. Усе, що описано нижче, лежить у передавальній папці проєкту й розібрано з вашими фахівцями на окремій зустрічі — без усних домовленостей «на словах».
- Схема інтеграцій: які зовнішні системи пов'язані з порталом (електронний щоденник або деканат, платіжний шлюз, каталог програм, поштові розсилки), у якому напрямку йдуть дані та що відбувається при недоступності зовнішнього сервісу.
- Ролі й доступи: матриця «роль — розділ — дія» для студента, викладача, куратора, методиста й адміністратора; окремо — що доступно без авторизації та як видаються підвищені права.
- Документація порталу: опис модулів, структура бази, призначення фонових завдань (нагадування, вивантаження, перерахунок залікових одиниць), точки розширення під нові напрями навчання.
- Регламенти підтримки: рівні звернень, час реакції та відновлення, порядок оновлень, вікна планових робіт і правила узгодження змін.
- Інструкції для адміністраторів: як відкрити навчальний рік, завантажити групи й розклад, видати доступи, вивантажити звіти та відкликати права співробітників, які пішли.
- Інструкції для викладачів: публікація матеріалів, перевірка завдань, робота з відомістю та зворотний зв'язок зі студентом.
- Резервне копіювання: розклад копій, строк зберігання, перевірка відновлення та порядок відкату при збої.
- Доступи до інфраструктури: домен, сервери, реєстри образів і журнали — оформлені на вас, без прив'язки до наших облікових записів.
Перші тижні після запуску залишаємося на зв'язку за регламентом, а далі портал живе силами вашої команди. Якщо знадобиться доопрацювання — обговоримо завдання й повернемося з оцінкою та планом.
Кейс: дванадцять тисяч одночасних входів у день публікації
Що було до переробки
Портал тримав звичайний навчальний день, але не витримував момент публікації результатів сесії: у перші хвилини після оголошення 12 000 студентів заходили одночасно.
Кожен вхід відкривав особистий кабінет із повною вибіркою оцінок і залікової книжки — сховище відповідало на важкі запити, черга з'єднань зростала, і на четвертій тисячі входів портал починав видавати помилку. Відновлення займало до сорока хвилин, а підтримка отримувала кілька сотень звернень за вечір.
Що змінили
Розділили читання й запис: сторінка кабінету збирається з кешу, який прогрівається заздалегідь, а нова оцінка йде в чергу й застосовується без блокування читання.
Важкі вибірки замінили посторінковими, кількість одночасних з'єднань до сховища обмежили окремим пулом, а вхід у пік перестав запускати синхронізацію.
Moodle залишили джерелом курсів і оцінок, але обмін із ним відбувається за розкладом, а не в момент, коли студент відкриває кабінет.
Що стало після
Відгук першої сторінки кабінету в пік тримається в межах частки секунди, 12 000 одночасних входів проходять без відмов.
Клас відмов «помилка в момент публікації» усунуто: навіть при десятикратному сплеску запису портал залишається доступним, а деградація зводиться до затримки оновлення оцінки на хвилину.
Що робити, якщо система вже розгорнута й працює
Це штатний сценарій, а не аварійний: система вже розгорнута, нею користуються щодня, але на піках прийому та сесії вона гальмує й обростає ручними обходами — дані правлять напряму в базі, звіти збирають у таблицях. Уже розгорнута система — не привід переписувати все одразу.
Перший крок — зафіксувати фактичний стан: схему розгортання, точки інтеграції з навчальними системами, список місць, де процес іде в обхід порталу, і з яких причин це з'явилося.
Поки нічого не змінюємо — вмикаємо спостережуваність і збираємо базову лінію: час відгуку на піку, частку помилок, найважчі запити, частоту ручних правок.
Без цієї бази покращення недоказове, а з нею з'являється критерій приймання — порівняння до й після на одних і тих самих сценаріях.
Далі йде поетапна переробка за вузлами, а не за всім застосунком. Починаємо з того, що частіше падає або потребує втручання людини, решта продовжує працювати як є.
Конфігурацію виводимо в систему контролю версій, перевірне середовище повторює бойове — розгортання перестає бути «з пам'яті» й стає відтворюваним.
Робота без зупинки занять тримається на двох правилах: релізи виходять у вікна низького навантаження, а зміни схеми даних ідуть у два кроки — спочатку додаємо нове, старий код продовжує працювати, потім перемикаємо читання й прибираємо зайве.
Попередній реліз тримаємо готовим до повернення, тому відкат займає хвилини, а не ніч відновлення з архіву.
Старі модулі міняємо по одному, зберігаючи адреси сторінок, права доступу та звичні сценарії: для викладачів і студентів портал залишається тим самим, змінюється лише поведінка під навантаженням. Так розвиток порталу йде паралельно з експлуатацією, а не замість неї.
Технічні сумніви: інтеграції, навантаження, міграція даних
Технічні сумніви рідко стосуються зовнішнього вигляду порталу — вони про те, як він зростеться з уже працюючими системами й що буде з накопиченими даними. Розбираємо чотири питання, які задають до старту, і те, як ми знімаємо кожне з них перевіркою на копії контуру замовника.
Як портал зв'яжеться з журналом успішності?
Через програмний інтерфейс журналу, а якщо його немає — регулярним вивантаженням за розкладом. Розклад, оцінки та домашні завдання читаються в один бік: єдине джерело правди залишається журнал, портал не породжує дублікатів.
Розсинхрон ловимо за часом зміни запису — перемагає пізніша. При недоступності журналу портал працює на останніх отриманих даних і наздоганяє чергу, коли зв'язок повернувся.
Чи можна перенести оцінки й особові справи зі старої системи або таблиць?
Так, разовим перенесенням: вивантажуємо дані, приводимо до цільової схеми й прогоняємо на копії. Оцінки минулих періодів лягають архівом зі збереженням дати, предмета й викладача.
Перед перемиканням звіряємо кількість записів і контрольні суми за кожним учнем — розбіжності розбираємо до, а не після запуску.
Як захищені дані учнів?
Розмежування за ролями, мінімальні права за замовчуванням, шифрування під час передачі й зберігання, журнал доступу до персональних даних. Для звітів і вивантажень дані знеособлюються, у зовнішню аналітику персональні відомості не потрапляють.
Хто і що побачить: як влаштовані права доступу?
Рольова модель із прив'язкою до класу й групи: учень бачить свої завдання, батько — лише свою дитину, викладач — свої предмети, адміністратор керує складом. Видача прав іде через адміністратора й фіксується в журналі аудиту — видно, хто відкрив доступ і коли.
Обговоримо завдання: що потрібно для оцінки та плану робіт
Точність оцінки проєкту порталу тримається на вхідних даних: чим конкретніші ролі, сценарії та зовнішні системи, тим менше припущень у складі робіт і плані етапів.
Нижче — мінімум, який варто проговорити або надіслати, щоб ми повернулися з оцінкою, схемою зв'язків і графіком із контрольними точками.
- Ролі та сценарії доступу: абітурієнт, студент, викладач, методист, адміністратор — хто що бачить, що редагує, які дані доступні лише для читання.
- Склад розділів і типи контенту: особисті кабінети, розклад, навчальні плани, відомості, документи, новини та оголошення; чи потрібен пошук і історія версій матеріалів.
- Зовнішні системи: чинний облік успішності, бібліотечний каталог, платіжний модуль, єдиний вхід за обліковим записом закладу — які дають обмін даними, а які залишаються осторонь.
- Пікові навантаження: скільки людей одночасно заходять у приймальну кампанію та сесію і який час відгуку вважаємо прийнятним.
- Міграція та архів: звідки переносимо дані (таблиці, старі сайти), у якому форматі, який обсяг і чи потрібен доступ до минулих навчальних років.
- Доступи й зберігання: робота з даними неповнолітніх, журнал дій, строки зберігання, хто в закладі відповідає за узгодження.
- Обмеження: дати приймальної кампанії та навчального року, внутрішній регламент закупівлі, хто ухвалює рішення на стороні замовника.
За цими вхідними даними ми збираємо склад робіт за блоками, схему зв'язків із зовнішніми системами та план етапів із контрольними точками.
Частину даних можна уточнити по ходу — тоді в плані окремо позначаємо рішення, які ухвалюються після короткого прототипу одного-двох розділів.
