СЛ

Вот на этом сыпятся 90% самописных хелпдесков! Они просто считают NOW() - CreatedAt. А нужно отдельное поле Paused_Duration, которое аккумулирует время, пока статус "Waiting for Client", и вычитать его из общего SLA.

SLA-таймер можно сделать через вычисляемое поле (текущее время минус время создания + триггеры). А вот омниканальность... Почту прикрутить легко, но с Telegram-ботом придется повозиться с вебхуками.

Понравилась формулировка, что миграция данных - это 20% успеха, а остальное - перевод людей и процессов. Это ровно то, о чем обычно молчат интеграторы, которые продают «перенос в отечественный стек», а потом бизнес сам разгребает падающую выручку и хаос в заявках.

Смешно читать комменты в духе «мы просто живём с Copilot’ом и все ок». Этот праздник обычно продолжается до первой галлюцинированной зависимости в проде.
ИИшка - это такой джун, который пишет идеальный на вид код, иногда с несуществующими пакетами и бесконечными уязвимостями, и при этом никогда не признается, что что-то придумал.

Если компания уже «застряла» в куче точечных интеграций, с чего реалистично начать переход, чтобы не сломать работающие процессы?

Интересно, что вы выбрали именно Kafka в примере. Для событийной модели это, конечно, де факто стандарт, но любопытно было бы увидеть сравнение с очередями попроще

Это проблема не вайбкодинга, а безграмотности. Любой инструмент опасен в руках неподготовленного человека. Обычный разработчик тоже может написать дырявый код. Причем не реже, чем ИИ)))

Как в предлагаемом подходе решается задача разделения контуров АСУ ТП и корпоративной ИТ‑среды: используется ли DMZ, «data diode», отдельный брокер сообщений или ESB‑шлюз между сегментами?