Контекст
Огляд проєкту
Ми спроєктували й побудували централізовану операційну платформу для управління аеропортовими процесами — від реєстрації рейсів і координації наземних служб до моніторингу всього аеропортового стану в реальному часі.
Система замінила розрізнені інструменти диспетчеризації єдиним операційним контуром, де всі служби бачать єдиний стан і діють за спільними правилами.
У обсяг проєкту увійшло:
- Управління розкладом рейсів і статусами в реальному часі
- Координація наземних служб: призначення ресурсів і черги обслуговування
- Операційна панель диспетчера з повним станом аеропорту
- Інтеграція з зовнішніми системами і датчиками
- Звітність і аналітика по операційних показниках
В аеропортових операціях немає можливості для «уточню і повернусь» — система повинна давати правду зараз.
Поставка
Як ми поставляли
Чітка відповідальність, обсяг робіт, стек і структура команди — щоб це читалося як реальна поставка, а не концепт на слайдах.
Наша роль
Draxon вів наскрізну продуктову інженерію операційної веб-платформи: discovery з командами сервісів, моделювання процесів, API й прав, UX дашбордів і релізи. Клієнт зберіг доменні правила та SLA; ми — технічна поставка, тести, staging і продакшен-запуски з планами відкату.
Обсяг робіт
- Централізована модель запитів і задач із чіткою відповідальністю, пріоритетами та «старінням» для керівників.
- Робочі простори за ролями — не generic CRM-профілі на операціях.
- Операційні дашборди для черг, пропускної здатності та винятків.
- Адмін-налаштування команд, черг і маршрутизації без деплою коду.
- Інтеграції для ідентичності та зовнішніх систем; експорт для звітів.
- Нефункціональна база: навантаження, структуровані логи, пайплайни staging → production.
Технології
- Angular + TypeScriptМодульний SPA з lazy routes для операційних UI.
- Node.js / REST APIsКонтракти, валідація та версіонування сервісів.
- PostgreSQLРеляційне ядро задач, призначень і аудиту.
- RedisКоординація, rate limiting і фонові задачі.
- Docker + CI/CDПовторювані збірки та smoke-перевірки перед промоцією.
Участь команди
- Draxon: delivery lead, senior full-stack, QA на права та процеси.
- Клієнт: операційне керівництво; IT для SSO та хостингу.
- Каденція: тижневі релізи; підтримка навколо cutover.
Обмеження
Операційний виклик
Операційна складність аеропорту виросла за обсягом рейсів і кількістю задіяних служб — координація на рівні телефонних дзвінків і таблиць більше не спрацьовувала.
Проблеми виявлялися так:
- Інформація про рейси розподілена між кількома несинхронізованими системами
- Наземні служби дізнавалися про зміни із затримкою, що призводило до черг
- Диспетчер не мав єдиної панелі — доводилося зводити дані вручну
- Відсутність аудиту рішень і хронології подій по рейсу
- Звітність по ключових показниках готувалася вручну по завершенні зміни
Кожна хвилина затримки в координації — це ланцюгова реакція по всьому аеропортовому розкладу.
Принципи
Стратегічний підхід
Єдина операційна правда — для всіх служб, у реальному часі, без ручного зведення. Архітектура під надійність і час відгуку в критичних сценаріях.
Ключові принципи:
- Єдине джерело стану рейсу й наземних операцій
- Push-оновлення для всіх задіяних служб без затримки
- Проєктування під крайні сценарії: збій рейсу, аварійна ситуація
- Рольова архітектура: диспетчер, служби, керівництво — різні поверхні
- Аудит кожного операційного рішення з хронологією
Надійна операційна система — та, що поводиться однаково під піковим навантаженням і в звичайний день.
Вплив
Результати
Після запуску платформа кардинально змінила якість оперативної координації:
- Скорочення затримок координації між службами завдяки push-оновленням
- Диспетчер бачить повний стан аеропорту в єдиній панелі
- Операційні рішення мають аудитний слід і хронологію подій
- Звітність по змінах формується автоматично, не вручну
- Платформа масштабується під зростання обсягу рейсів без переписування ядра
Питання
