43 тривоги за шість днів. Хто відчинить двері до укриття?
Пацієнт прийшов на обстеження. Щоб дістатися кабінету, він пройшов через два корпуси, піднявся на поверх, минув кілька дверей з електронними замками — його провели, він не запам’ятовував дорогу.
О 09:50 лунає тривога.
Укриття — на території. Але найкоротший шлях до нього лежить не там, звідки людина прийшла. І на цьому шляху стоять ті самі двері, які щойно відчинялися карткою супроводу.Це не гіпотетична ситуація. Це звичайний ранок у київській міській лікарні, де ми розгорнули систему автоматичного відчинення маршрутів евакуації. У приймальні — люди, у коридорах — відвідувачі, які вперше в цій будівлі
Головне завдання під час тривоги
Коли лунає сигнал, у будівлі вирішується одне-єдине завдання: за мінімальний час вивести людей до укриття найкоротшим шляхом.
Усе інше в цей момент другорядне. Не має значення, хто яким входом зайшов і чия картка що відчиняє, — має значення, скільки хвилин людина йтиме до укриття і чи не впреться вона дорогою в зачинені двері.
Маршрут евакуації працює зі швидкістю найповільнішої своєї ланки. Один електронний замок, який не відчинився, перетворює найкоротший шлях на найдовший: люди розвертаються, шукають обхід, створюють затор — і замість трьох хвилин витрачають десять.
Тому шлях до укриття має відчинятися повністю й одночасно — усі двері маршруту, в усіх корпусах, за секунди після сигналу. Не по черзі, не в міру того, як хтось до них дійде.
Саме це завдання й вирішує система.
Скільки це коштує в реальних цифрах
Ми зняли статистику тривог за шість днів, з 17 до 22 вересня 2026 року, з логів системи на об’єкті.
Скільки це коштує в реальних цифрах
Ми зняли статистику тривог за шість днів, з 17 до 22 вересня 2026 року, з логів системи на об’єкті.
| Показник | Значення |
| Тривог за 6 днів | 43 |
| У середньому на добу | 7,5 |
| Максимум за добу | 11 (20 вересня) |
| Загальний час під тривогою | 37 годин 14 хвилин |
| Частка часу під тривогою | 27 % |
| Нічних тривог (22:00–06:00) | 15 — понад третина |
| Найкоротша тривога | 2 хвилини |
| Найдовша тривога | 5 годин 30 хвилин |
Як працює рішення
Систему побудовано з п’яти сервісів. Три з них — у ланцюжку команди, два наглядають за рештою.
1. Сервіс спостереження за тривогами
Основне джерело — офіційний реєстр тривог api.ukrainealarm.com. Додаткові джерела задаються конфігурацією з пріоритетами.
Логіка навмисно асиметрична:
- тривогу піднімає будь-яке джерело — краще відчинити зайвий раз, ніж не відчинити вчасно;
- відбій у штатному режимі дає тільки основне джерело — повертати двері в зачинений стан за неперевіреним сигналом небезпечно;
- якщо не відповів жоден канал, система переходить у стан «невідомо» і не надсилає дверям жодної команди. Вона нічого не робить наосліп;
- якщо основне джерело недоступне тривалий час, право на відбій переходить до резервних — інакше двері залишалися б відчиненими нескінченно.
2. Сповіщення персоналу й команда дверям
Сигнал іде до охорони й адміністрації в Telegram: джерело, перелік дверей маршруту, стан кожного замка. Відбій — окремим повідомленням.
Через цей самий канал проходить і команда дверима — персонал одразу бачить не тільки те, що тривога почалася, а й те, що саме відчинилося.
Але бот не є обов’язковою ланкою аварійного шляху. Якщо він недоступний — збій Telegram, проблеми з мережею, зупинка сервісу — сервіс тривог надсилає команду шлюзу напряму. Двері відчиняться, навіть коли сповіщення не дійде до жодного телефону.
3. Шлюз до обладнання
Шлюз розмовляє з контролерами мовою виробника й приховує її від решти системи. На цьому об’єкті — шість контролерів Hikvision серії DS-K280x, для яких HTTP API не передбачено, тож шлюз працює через SDK виробника.
Для верхнього рівня це неважливо: він надсилає «відчинити двері №5», а не «виконати виклик SDK». Тому склад об’єкта — кількість дверей, моделі контролерів, виробник — задається конфігурацією, а не переписуванням коду.
Кожна команда перевіряється на виконання. Якщо контролер не відповів або повернув помилку, це не «напевно спрацювало» — це зафіксований збій, про який одразу дізнається охорона.
4. Панель моніторингу
Три попередні сервіси відповідають на питання «що робити під час тривоги». Четвертий відповідає на питання, яке ставить кожен технічний керівник: а якщо сама система впаде — хто про це дізнається?
Панель моніторингу показує стан усіх сервісів у реальному часі: чи живий кожен із них, скільки пам’яті споживає, чи є зв’язок із контролерами дверей, чи відповідає джерело сигналу тривоги.
Головне — вона не чекає, поки хтось зайде й подивиться. Про зупинку будь-якого сервісу відповідальні дізнаються одразу, а не під час наступної тривоги.
5. Сторож служб
Панель моніторингу відповідає на питання «хто дізнається про збій». Залишається наступне: хто його усуне о третій ночі?
П’ятий сервіс стежить за роботою решти й автоматично перезапускає зупинену службу. Збій живлення, оновлення Windows, нестача пам’яті, аварійне завершення процесу — служба піднімається сама, без дзвінка інженеру й без очікування ранку.
Це прибирає з ланцюжка найненадійнішу ланку: людину, яка має вночі побачити повідомлення, доїхати або підключитися й запустити сервіс вручну.
Три рівні захисту від відмови
Найнебезпечніший сценарій для будь-якої системи безпеки — не гучна аварія, а тиха зупинка. Система перестала працювати тиждень тому, всі впевнені, що вона на місці, а виявляється це під час тривоги.
Проти цього сценарію працюють три рівні:
| Рівень | Що робить |
|---|---|
| Сторож служб | піднімає службу, що впала, автоматично |
| Панель моніторингу | показує, що це сталося, і сповіщає відповідальних |
| Щоранкова перевірка | щодня підтверджує, що все обладнання на зв’язку |
Щоранкова перевірка готовності
Справна система і система, готова спрацювати просто зараз, — це різні речі. Контролер може втратити мережу, зависнути після перепаду живлення, вийти з ладу вночі — і дізнатися про це під час тривоги буде пізно.
Тому щоранку за розкладом система сама перевіряє кожен контролер: чи є зв’язок, чи відповідає він на команди, у якому стані замки.
Результат перевірки надходить відповідальним повідомленням — з переліком контролерів і станом кожного. Якщо все справне, це коротке підтвердження. Якщо ні — конкретна назва дверей, з якими проблема, і час її виявлення.
Так у відповідального щоранку є однозначна відповідь на питання «чи готові ми до сьогоднішньої тривоги», а не припущення, що все працює, бо вчора працювало.
Окремий інженерний наслідок: система не опитує контролери постійно. Постійне опитування навантажує обладнання й мережу без користі. Перевірка робиться раз на добу планово, а під час тривоги кожна команда все одно перевіряється на виконання — тож стан обладнання завжди відомий саме тоді, коли це має значення.
Результат шести днів роботи
602 команди з 602 виконано й підтверджено контролерами.
- жодного втручання охорони вручну;
- жодного хибного відчинення;
- жодної пропущеної тривоги й жодного пропущеного відбою;
- усі п’ять сервісів відпрацювали шість діб без зупинок;
- щоранкова перевірка контролерів — шість із шести, усе обладнання справне.
Охоронець за ці шість днів не зробив жодного обходу корпусів заради дверей. Він бачив у телефоні, що маршрут відчинено, і займався людьми.
Журнал, який не можна переписати
Окреме питання, яке ставлять керівники закладів: чим потім доводити, що система відпрацювала?
Усі події — сигнал, рішення, команда, підтвердження, відбій, щоранкова перевірка, перезапуск служби — пишуться в журнал із ланцюжком хешів. Запис заднім числом неможливо змінити непомітно: будь-яка правка розриває ланцюжок.
Якщо після влучання буде розслідування, у керівника закладу є не пояснення, а документ із точним часом кожної дії.
Відповідь на головне заперечення
«Якщо двері відчинені — до будівлі зайде хто завгодно?»
Відчиняються не всі двері, а тільки ті, що лежать на маршрутах до укриття. Периметр і зони обмеженого доступу працюють у штатному режимі. Після відбою система автоматично повертає всі двері у звичайний стан — і це теж записано в журналі, з часом і підтвердженням.
Система не замінює охорону. Вона знімає з неї ту частину роботи, яку людина виконати не може.
Що потрібно для впровадження
- наявні контролери СКУД — Hikvision, Dahua або інші (підтримка виробника додається окремим модулем);
- сервер або ПК під Windows усередині мережі об’єкта;
- визначені маршрути до укриття — які двері мають відчинятися;
- 1–2 дні на розгортання й налаштування.
Система працює всередині мережі об’єкта. Зовнішній канал потрібен лише для отримання сигналу тривоги.