Розробка порталу дитячого садка: де ламається доступ
Типова картина: портал запущено, особистий кабінет батьків працює, фотографії з ранків викладаються — а фактичний доступ до них видається не роллю в системі, а посиланням у чаті групи.
Закриті альбоми груп при цьому залишаються відкритими за фактом. Посилання не прив’язане до облікового запису батька, живе безстроково й іде далі разом з історією листування; відкликати його після надсилання не можна, а журнал, хто саме завантажив знімки, не ведеться. Через сезон такі альбоми знаходяться у відкритому пошуку.
Розмежування прав вихователя в саморобних рішеннях зводиться до одного набору для всіх: педагог однієї групи бачить альбоми й дані чужих, звільнений працівник зберігає доступ до ручної зміни пароля, ролі адміністратора й педагога не розділені.
Вихователь, який веде документацію, попутно отримує права на архів закладу — це вже не незручність, а клас інцидентів.
Зберігання персональних даних дітей зазвичай винесено за контрольований контур: заяви, довідки та медичні картки лежать у таблицях на особистих акаунтах, згоди батьків — на папері без зв’язку із записом у базі. Сам доступ до документів закладу роздається тим самим способом — файлом за прямим посиланням.
Підсумок: система формально є, а керованими залишаються тільки вітрина — права, строки життя посилань і контур зберігання живуть окремо від неї.
Розбираємо, як це закривається в розробці порталу дитячого садка: доступ видається роллю та групою, посилання має строк і відкликається, а персональні дані дітей зберігаються в одному контурі з журналом звернень.
Ефект впровадження: публікація, навантаження, ручні операції
Матеріали групи раніше проходили через адміністратора: зібрати знімки з телефона вихователя, перейменувати, завантажити, видати права кожному батькові.
Тепер публікацію робить сам вихователь із панелі — альбом на 30–40 фотографій іде в закритий розділ за 2–3 хвилини, включно зі стисненням і розміткою за правами доступу.
Частка ручних операцій у адміністратора падає з основної частини робочого дня до поодиноких винятків. Сповіщення про нові матеріали розсилаються за списком групи автоматично, доступ батьків відкривається під час першого входу за запрошенням.
Вручну залишаються тільки нестандартні випадки — переведення дитини до іншої групи, повторне видавання доступу.
Ранковий пік, коли стрічку та альбоми одночасно відкривають кілька сотень батьків, раніше був точкою відмови: один застосунок не тримав з’єднання, і частина батьків замість фотографій отримувала сторінку з помилкою.
Тепер застосунок запускається кількома екземплярами за балансувальником, а розсилання сповіщень потрапляє в чергу — повільний поштовий шлюз більше не блокує видачу сторінок.
Альбоми дітей — особлива категорія даних, тому доступ будується на сертифікованих засобах захисту (КриптоПро) і розмежуванні прав на рівні окремих записів, а не лише на вході до кабінету.
Клас відмов «портал недоступний у час пік» перестав відтворюватися: навантаження розподіляється, публікація не залежить від адміністратора, а сповіщення доходять без ручного розсилання.
Порівняння варіантів: готове рішення, модуль, сервіс
Розвилка проста: типове готове рішення для дитячого садка, модуль особистих кабінетів поверх працюючого сайту або окремий сервіс для закладу.
Різниця не в наборі кнопок — вона в тому, наскільки близько ваші процеси збігаються із закладеними, хто відповідає за зберігання персональних даних дітей і батьків та наскільки оборотним є рішення, якщо воно перестане підходити.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готове рішення для дитячого садка | Батьки й вихователі працюють за типовим сценарієм, потрібен швидкий запуск, власної команди підтримки немає | Обмеження типової системи: фіксований набір форм і звітів, власні правила для закритих альбомів; нестандартний сценарій закривається лише доопрацюванням у постачальника |
| Модуль особистих кабінетів поверх наявного сайту | Сайт уже наповнений і працює, дизайн та адресу змінювати не планується | Кабінети успадковують шаблон і права доступу сайту: зв’язка «дитина — батько — група — методист» і розмежування файлів налаштовуються обмежено |
| Окремий сервіс для закладу | Потрібні власні правила ролей, закриті альбоми за групами, обмін даними з обліковою системою садка | Більше роботи на старті: власна інфраструктура, окремий контур персональних даних, зв’язка із сайтом та обліковими даними |
Окремо перевіряємо перенесення даних у разі зміни рішення: список груп, картки дітей, згоди на обробку персональних даних і файли альбомів мають вивантажуватися у відкритих форматах, без ручного перенабирання.
Якщо експорт доступний лише «через підтримку постачальника» — це і є головне обмеження варіанта, і його видно ще на етапі вибору.
Етапи роботи: від обстеження до передавання в експлуатацію
Портал дитячого садка відрізняється від звичайного сайту: майже весь контент — персональні дані дітей, а склад ролей змінюється щороку. Ідемо не від макета, а від моделі доступу, вимоги 152-ФЗ перевіряємо на кожному кроці. Нижче — послідовність роботи.
- Обстеження ролей і груп. Фіксуємо ролі — батько та другий з батьків, вихователь, методист, завідувач, адміністратор — і для кожної список розділів та допустимих дій. Окремо промовляємо переходи: приймання до групи, переведення, випуск, тимчасовий доступ родича.
- Схема даних порталу. Пов’язуємо картку дитини, групу, обліковий запис батька, альбом і згоду на зйомку. Схема задає правила заздалегідь: під час переведення дитини доступ переїжджає разом із нею, а не правиться адміністратором вручну.
- Налаштування закритих розділів. Права перевіряємо на серверному боці за кожним записом, а не приховуванням кнопок у браузері. Альбом віддається лише батькам дітей цієї групи, пряме посилання на файл не працює в обхід порталу.
- Перевірка під навантаженням. Проганяємо пікові сценарії: масовий вхід батьків уранці, публікацію альбому на кілька сотень знімків, розсилання сповіщень. Дивимося час відгуку й поведінку за одночасних запитів.
- Передавання в експлуатацію. Віддаємо адміністраторам інструкції з видавання та відкликання доступів, налаштування резервного копіювання й журнал дій працівників, регламент на випадок звільнення або зміни вихователя.
Що залишається в замовника: конфігурація, схеми, регламенти
Після запуску порталу все, що забезпечує його роботу, залишається в замовника — не в листуванні й не в голові підрядника. Початковий код, конфігурації середовищ і документацію передаємо у ваш акаунт, доступи оформлюємо на сам заклад. Нижче — що саме входить до пакета.
- Початковий код і конфігурації: збірка, параметри середовищ, міграції бази — копія порталу піднімається без нашої участі.
- Схема ролей і прав із матрицею доступу: батько, вихователь, завідувач, адміністратор — хто що бачить і яку дію може виконати.
- Політики доступу до закритих альбомів: яка група що бачить, хто публікує, як доступ відкликається під час переведення дитини до іншого садка.
- Інструкція адміністратора порталу: заведення груп і облікових записів, публікація альбомів, скидання доступу, розбір журналу дій.
- Регламент обробки персональних даних: склад даних дітей і батьків, строки зберігання, порядок видалення на вимогу, відповідальний усередині закладу.
- Пакет документів для 152-ФЗ: згоди, політика конфіденційності, повідомлення до наглядового органу, шаблони відповідей на запити батьків.
- Пам’ятка для вихователів на одну сторінку: як завантажувати фотографії та які відомості не можна викладати в загальний доступ.
Документацію ведемо разом із кодом: у разі зміни прав або появи нового розділу інструкція оновлюється в тому самому релізі. Через рік портал не виявиться «нічийним» — новий адміністратор або інший підрядник розбереться за переданими схемами.
Кейс: прибрали ручне видавання доступів і обдзвін батьків
Дитячий садок на 12 груп вів фотозвіти в месенджері: адміністратор вручну звіряла, хто з батьків має право бачити альбом, і щодо кожного нового батька писала в чат.
На звірку йшла частина робочого дня, а доступ переживав відрахування дитини — звідси й спірні ситуації з фотографіями чужих дітей.
Що змінили
Портал зібрали на 1С-Битрикс з окремим захищеним сховищем файлів. Права успадковуються від ролі та групи: батько бачить лише свій альбом, вихователь — лише свої групи, завідувач — усе.
Згода на обробку даних оформлюється в кабінеті з відміткою часу, а кожне відкриття альбому потрапляє в журнал.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Звернення щодо доступу | 30–40 на місяць, вручну через чат | 1–2 на місяць, решта — самостійно в кабінеті |
| Публікація альбому групи | 1–2 дні на звірку списків | 15 хвилин: завантажили й відкрили потрібній групі |
| Помилки під час видавання прав | 6–8 за квартал: чужий батько в альбомі, відрахований із доступом | 0 за квартал — право видає роль, а не людина |
| Збір згод | паперові бланки в папці | електронна згода з відміткою часу |
Під час відрахування доступ знімається перемиканням ролі, а не листом у чат: відкат займає хвилину й підтверджується журналом. За квартал після запуску не було жодного випадку, коли альбом побачив батько з іншої групи.
Що робити, якщо в садка вже є сайт і хмарний диск?
Сайт і хмарний диск уже працюють — питання не в тому, щоб їх переписати, а в тому, де проходить межа між публічною частиною та закритим контуром.
Сторінки, розклад і документи залишаються на сайті; альбоми, дані дітей і листування з батьками переходять до кабінету, куди не можна потрапити за одним посиланням.
З хмари переносимо структуру альбомів, прив’язку до груп і самі файли — пакетним вивантаженням через програмний інтерфейс сховища.
Права доступу при цьому збираємо заново: режим «у кого є посилання» в новий контур не переноситься, замість нього роль батька жорстко пов’язується з дитиною та її групою.
Інтеграція з наявним сайтом будується на єдиному вході: батько авторизується один раз, сесія спільна, другий логін і пароль не потрібні. Кнопка входу й кабінет вбудовуються в поточний дизайн, адреси сторінок і позиції в пошуку зберігаються.
Окремо фіксуємо провідну систему для кожного типу даних: склад дітей, груп і працівників ведеться в одному місці, альбоми живуть лише в порталі, а на сайті залишається вітрина без копій. Інакше дублювання даних розійдеться вже після першої правки, і батько бачить застарілу версію.
Міграція відбувається без зупинки роботи: новий контур наповнюється паралельно з хмарою, пілот запускаємо на одній групі, звіряємо повноту альбомів і доступів, потім підключаємо решту.
Старе сховище переводимо в режим лише для читання й закриваємо після контрольного періоду — відкат вкладається в години.
Питання щодо доступів, зберігання даних і навантаження
Права описуємо не списком посад, а матрицею «об’єкт × роль»: альбом групи, картка дитини, оголошення, вивантаження документів. Вихователь бачить лише свою групу, батько — лише свою дитину, а публікація фотографії потребує окремого дозволу, і кожна така дія потрапляє в журнал.
Дані дітей — чутлива категорія, тому поля розділені за рівнями: ідентифікація, контакти, медичні позначки. Зберігаємо в захищеному контурі, доступ пишемо в незмінний журнал, строк зберігання задаємо політикою — після його спливу запис видаляється разом із пов’язаними файлами.
Що як частина батьків відмовиться від особистого кабінету?
Портал працює у двох режимах. Вихователь публікує матеріали в закритому альбомі, а батькові без кабінету вони передаються звичним способом — друк, стенд, персональне повідомлення через вихователя. Відмова фіксується в картці, і система більше не надсилає запрошення та нагадування.
Чи витримає портал пікові дні?
Пік — ранок і вечір, плюс дні запису до гуртків і ранків, коли одночасно заходять сотні батьків. Альбоми віддаємо з кешу, фотографії — через окреме сховище зі стисненими прев’ю, а важкі завдання на кшталт масового розсилання й збирання архіву виносимо в чергу. Профіль навантаження знімаємо заздалегідь за логами реального садка.
Чи можна розмістити портал на своїх серверах?
Так. Розгортаємо у вашому контурі, якщо дані не повинні залишати інфраструктуру садка або керуючої компанії. Резервні копії йдуть за розкладом, відновлення перевіряємо на тестовому стенді, оновлення ставимо з можливістю відкату до попередньої версії.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб оцінка порталу спиралася на обсяг, а не на здогадки, для старту достатньо кількох вступних. Опишіть, хто користуватиметься системою і які ролі потрібні — батько, вихователь, адміністратор, методист, — і які розділи особистого кабінету закриті, а які видно всім.
Окремо важливо, як сьогодні влаштована робота зі згодами на обробку персональних даних дітей і хто наповнюватиме альбоми груп.
- Перелік ролей: що кожна бачить, що може змінювати, кому доступ закритий.
- Склад розділів першої версії: особистий кабінет, закриті альбоми, оголошення, документи, заявки — і що переносимо на наступний етап.
- Як зараз видаються, зберігаються та відкликаються згоди на обробку персональних даних.
- Хто адмініструє портал і як швидко закривається доступ, коли працівник іде.
- Чи є чинний сайт і домен, куди планується розміщувати дані та резервні копії.
- Орієнтир за строками запуску — наприклад, до початку навчального сезону.
Далі ми розбираємо вступні та повертаємося з планом: складом робіт за етапами, схемою ролей і прав доступу, порядком роботи з персональними даними та закритими альбомами, строками й точками, де потрібні ваші рішення.
Якщо частина відповідей поки не готова — частину уточнимо в розмові та зафіксуємо в плані. Опишіть задачу — повернемося з оцінкою та складом робіт.
