Инженерная задача
Нужны единый CLI, понятные статусы WAN/DNS/MAIN, журнал инцидентов и уведомления в Telegram. При этом отказ Telegram, health-движка или управляющего интерфейса не должен прерывать интернет.
Назад к проектам
CUDY Home Gateway
Control plane для домашнего роутера на OpenWrt: наблюдение за WAN, DNS, сетевыми сервисами и состоянием системных компонентов без вмешательства в основной поток трафика.
- Устройство
- CUDY TR3000 / OpenWrt
- Направление
- System Engineering · Observability
- Статус
- 0.5.0-dev; v1.0.0 не принята
PROBLEM & CONSTRAINTS
Мониторинг не должен становиться причиной сетевой аварии.
Домашний шлюз управляет критичными сетевыми процессами. Диагностика и удалённый интерфейс полезны только при сохранении их независимости от маршрутизации.
Ограничения среды
- BusyBox/OpenWrt: ограниченные память, зависимости и средства диагностики.
- PassWall2/Xray, DNS, nftables и Tailscale остаются независимым data plane.
- Никакого универсального удалённого shell или автопереключения MAIN.
- Подтверждённые тесты на хосте не подменяют испытания на реальном роутере.
ARCHITECTURE
Control plane отделён от data plane.
Status/Health собирают наблюдения; Incident Engine применяет debounce/hysteresis; Projection формирует события; persistent queue отделяет инцидент от отправки сообщения. Действия управления проходят отдельный ограниченный путь.
- control ≠ data plane
- debounce / hysteresis
- persistent journal
- delivery ≠ exactly-once
INCIDENT LIFECYCLE
Оповещение возникает после подтверждения изменения состояния.
Наблюдение не равно инциденту: кратковременный сбой проверки не должен немедленно превращаться в тревогу.
Наблюдение
Health Core нормализует WAN, DNS, MAIN и дополнительные сервисы до OK, DEGRADED, DOWN, UNKNOWN или MAINTENANCE; учитывает свежесть внешних проверок.
Подтверждение
Incident Engine открывает DEGRADED/DOWN после трёх последовательных наблюдений; восстановление OK требует двух наблюдений.
Фиксация события
OPEN, STATE_CHANGED или RECOVERED попадают в persistent journal и могут быть восстановлены после перезапуска.
Проекция и очередь
Инцидент преобразуется в отдельную запись уведомления. Очередь хранит pending/inflight/terminal receipts и поддерживает повторную обработку.
Доставка и разбор
Notification adapter учитывает retry, backoff, 429 и неопределённость доставки. LIVE-приёмка транспорта на устройстве остаётся отдельным этапом.
ENGINEERING DECISIONS
Fail-closed важнее зрелищной автоматизации.
Главные решения сформированы условиями реального устройства и ограничениями безопасного удалённого управления.
Отделить наблюдение от маршрутизации
Telegram и health-слой не участвуют в принятии решений об основном трафике. Отказ control plane не должен менять data plane.
Не смешивать probe и incident
Debounce, hysteresis и состояния UNKNOWN/MAINTENANCE помогают отличать краткий сбой проверки от устойчивого инцидента.
Явно принять at-least-once
Telegram sendMessage не поддерживает ключ идемпотентности. После неопределённого ответа возможен дубль; система не обещает exactly-once.
Запретить универсальный shell
Управляющий интерфейс ограничен заранее описанными командами. Опасные действия требуют отдельного подтверждения и не входят в read-only сценарии.
EVIDENCE & VALIDATION
Автоматические проверки есть; полный LIVE gate ещё открыт.
Матрица ACCEPTANCE.md разделяет проверенные в изоляции контракты и работу текущего кода на реальном OpenWrt. Это не стабильный релиз v1.0.0.
В roadmap задокументированы проверки ранних версий на CUDY; они не подтверждают работу всех изменений текущего HEAD.
Для уведомлений, инцидентов и контроля состояний задокументированы автоматические проверки, включая сбои и восстановление.
Нужны подтверждения реальной отправки, перезагрузки, persistence и сценариев восстановления на устройстве.
Документы и доказательства
LIMITATIONS
Отделяем готовый код от неподтверждённой эксплуатации.
Проект не объявляется законченным production-продуктом: приёмка 0.5 и последующих этапов содержит открытые условия.
Нет гарантии exactly-once Telegram delivery
Потеря ответа Telegram после принятия сообщения может привести к повторной доставке, несмотря на durable receipts.
Полная LIVE-приёмка актуального HEAD
OpenWrt TLS/SOCKS, worker/reboot, persistent queue, sysupgrade и recovery должны проверяться на устройстве отдельно.
Safe Actions и MAIN transaction
0.7 реализует часть контрактов с disabled-by-default и не имеет полной LIVE-приёмки; 0.8 в публичной документации ограничен read-only planner.
Стабильный релиз v1.0.0
Необходимы закрытые критические gates, длительное наблюдение и подтверждённый recovery drill.
TAKEAWAYS
Проект показывает инженерную работу с неопределённостью.
Ценность кейса в разделении ответственности, явном описании состояний и доказательств, а не в количестве команд Telegram или обещании полной автоматизации.
- Наблюдение за системой должно быть безопасным по отношению к обслуживаемому трафику.
- Incident lifecycle и notification delivery имеют разные гарантии и отдельные контуры ошибок.
- PASS из изолированного теста нельзя выдавать за успешную приёмку на реальном устройстве.
SOURCE & EVIDENCE
Архитектура, границы и приёмка доступны публично.
В репозитории находятся README, архитектура, инженерные решения, документация инцидентов, уведомлений и открытая матрица ACCEPTANCE.