Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 5
Я бы включил режим максимальной паранойи.
Если пакеты от монитора не приходят в течении более чем полутора периодов, нужно бежать, орать, бить тревогу.

Если гуй не может допинговаться до бека в течении одной секунды — правильно, бежать-орать, выть сиреной

Если параметр резко скакнул — алярм.

Если бэк не видит свежих апдейтов в постгресе — алярм.

Если из сетевых интерфейсов полезли ошибки — алярм.

Если формат пакета нарушен — то же самое.

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

Какая-то стремная цепочка. Широковещательные UDP пакеты поверх Ethernet как я понимаю — нет никаких гарантий что из-за коллизий пакет дойдёт вовремя, потом Go с GC, потом PostgreSQL у которого нет никаких жестких гарантий на время записи и наконец JavaScript с GC. Понятно что обычно все доходит и отображается вовремя, но как в такой сложной системе доказать что с момента обнаружения проблемы прибором у кровати больного до показа оповещения в дежурной комнате пройдёт точно не более X секунд?


По-моему дорогая цена у существующих систем, о чем сказано в начале статьи, оправдана.

Что то вы загнули про три дня, тут работы на три недели

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.