Обычно мои проекты начинаются с вопроса: «Почему человек до сих пор делает это руками?»

С GorAlert вопрос оказался немного серьёзнее.

Есть официальное сообщение об угрозе. Сотрудник должен его увидеть, правильно интерпретировать, запустить необходимые системы оповещения, проверить их работу, а после отбоя выполнить обратный сценарий.

Задача GorAlert — сократить эту цепочку и человеческий фактор.

GorAlert — локальный сервис автоматизации оповещения и реакции на чрезвычайные события.

Источник событий

Официальными источниками сообщений об угрозах для системы являются Telegram и MAX главы Сочи Андрея Прошунина. Важно: GorAlert не прогнозирует угрозы и сам не принимает решение о наличии опасности. Он реагирует только на информацию, опубликованную в официальных источниках.

Архитектурно логика выглядит примерно так:

Official Source → Parser → Event Engine → State Machine → Scenario → Notification Systems

Почему это не просто Telegram-бот

На первый взгляд всё просто: увидели сообщение → включили оповещение Но в реальной эксплуатации появляются вопросы. Что делать с повторной публикацией? Что произойдёт после перезапуска сервера во время действующей тревоги? Как не запустить один сценарий несколько раз? Что делать, если один из компонентов временно недоступен? Как гарантированно завершить активный сценарий после официальной отмены?

Поэтому в основе GorAlert находится машина состояний, а не набор простых if.

Условно: NORMAL → ALERT → CANCEL → NORMAL Система понимает, какое событие уже было обработано и в каком состоянии находится сейчас.

Что внутри

Backend написан на Python и работает на Linux. Проект разделён на несколько независимых компонентов: — получение событий из официальных источников; — анализ и классификация сообщений; — хранение текущего состояния; — движок сценариев; — локальное звуковое оповещение; — интеграция с корпоративной телефонией; — контроль повторных действий; — журналирование; — web-панель оператора. Такое разделение позволяет менять отдельные части системы, не переписывая проект целиком. Если в дальнейшем появится новый официальный источник или дополнительный способ оповещения, его можно подключить отдельным модулем.

Интеграция с телефонией

Одна из интересных частей проекта — взаимодействие с существующей телефонной инфраструктурой. После определённого события GorAlert может автоматически запускать заранее подготовленный сценарий информирования. При этом важно не просто отправить команду, а понимать результат её выполнения.

Условно цепочка выглядит так: GorAlert → телефония → абонент → результат

Web-панель

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

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

Отказоустойчивость

Большая часть работы оказалась именно здесь. Если внешний источник временно недоступен — весь сервис не должен падать. После перезапуска GorAlert должен корректно восстановить работу. Повторно полученное событие не должно запускать одинаковые действия бесконечно. А после официальной отмены активный сценарий должен корректно завершиться.

В итоге GorAlert получился не «ботом, который читает Telegram», а небольшим event-driven сервисом: официальное сообщение → событие → изменение состояния → выполнение сценария → контроль результата → журналирование. Человек при этом остаётся в контуре управления и может вмешаться вручную. Именно этого я и хотел добиться: не заставлять программу самостоятельно решать, существует ли опасность, а убрать рутинные действия между официальным сообщением и выполнением заранее определённого сценария.

Так Python, Linux, телефония, web-интерфейс и автоматизация постепенно превратились в GorAlert