Вы правы — DNS-мониторинг сам по себе не определяет, какая запись "правильная" или "задумана админом". Его задача — показать, что именно изменилось и когда это произошло, чтобы такие случаи можно было быстрее диагностировать
В приведённом в начале статьи кейсе это как раз могло бы помочь: администратор не знал, что старые MX-записи остались в зоне, и получил бы уведомление об изменении DNS-записей
Согласен, что проверка "действительно ли работает почтовый сервер" решается на другом уровне — и Statuser это тоже делает, но уже в рамках SMTP-проверок (для тех, кто их включает)
Идея с интеграцией с управляющими панелями DNS интересная — я тоже задумывался о таком варианте, особенно для случаев, когда нужно различать запланированные и незапланированные изменения. Пока собираю фидбек и думаю, как реализовать это аккуратно, чтобы не усложнять простые сценарии
Спасибо! Всё делаю на Next.js + shadcn/ui, с кастомной обвязкой под свои кейсы
Админку писал с нуля, без шаблона — вдохновляюсь интерфейсами Vercel и иногда заглядываю на Dribbble. Формы — через react‑hook‑form + zod, состояния — Zustand
Реализация авторизации самописная на NestJS. Использую http‑only куки и пару access + refresh токенов. Поддержана двухфакторка — есть TOTP и коды на емейл и в Телеграм, а ещё можно войти через Passkey
1. Эталонные скриншоты можно генерировать локально, а ещё у нас добавлена кнопка прямо в интерфейс отчёта после прогона, чтобы при необходимости сразу автоматизированно обновить референсы, её часто используем
2. Автоматизация создания задач не используется — мы просматриваем изменения вручную и заводим тикеты по ситуации
3. Прогоны тестов идут на проде (по расписанию, при релизе и вручную), на стейдже (при доставке и вручную) и на деве (вручную)
4. Тесты хранятся в отдельных репах, но они связаны с репами сервисов через пайплайны в GitLab
Для скриншотных тестов используем встроенные фичи Playwright. Фиксируем размеры, ждём загрузку нужных элементов, сравниваем только важные области — в итоге всё довольно стабильно. Иногда бывают небольшие сдвиги на 1–2 пикселя из-за особенностей самого Playwright, но это случается редко и обычно не мешает
Связка blackbox + Prometheus + Grafana действительно мощная, но требует времени на установку, настройку, поддержку и не решает прикладные задачи вроде статус-страниц, уведомлений в Telegram/email или скриншотов
Я запускал Statuser как решение «из коробки» — для тех, кто хочет мониторинг за пару минут и без DevOps-головной боли
А про фреймворк — да, похоже, я прошёл этот этап :) Только хочется, чтобы польза была не только для себя)
Я разделил Next.js и NestJS как два отдельных сервиса: фронт работает как полноценный SSR-приложение на Next.js, а NestJS — это API и бэкенд-логика, которые общаются по HTTP
Как устроена связка:
Коммуникация через обычный REST (Axios с фронта)
Общий код — немного: только DTO, типы, enum и валидационные схемы, сейчас их никак не шарю, просто копирую, потому что так проще, чем делать шаренный пакет
Темная/светлая тема живёт исключительно на фронте. Управляется через next-theme, переключается на клиенте и прокидывается в className на html-теге. NestJS об этом ничего не знает и не должен — они не связаны в рамках одной транзакции
Авторизация — по JWT-токену с кукой (HttpOnly), который фронт получает после логина и кладёт в запросы на NestJS
Сильно зависит от задачи, для чата технической поддержки дефолтно можно выставить что-то такое:
temperature: 0.6
presence_penalty: 0.5
frequency_penalty: 0.5
А дальше уже начинать их крутить и искать оптимальный вариант под конкретный кейс, но полностью избавиться от галлюцинаций в версии 3.5 вряд ли получится)
Для модели 3.5 способов борьбы с галлюцинациями не так много (фактически 2):
1. Системный промт
2. Регуляция доп параметров, в первую очередь temperature, presence_penalty, frequency_penalty
Методом проб и ошибок подобрали подходящее нам сочетание параметров, плюс продолжаем смотреть за корректностью ответов и регулировать параметры модели и промт
Мы предупреждаем пользователей, что наш ИИ-ассистент может ошибаться и не следует ему безоглядно доверять)
Сейчас думаем над ручным управлением контекстом, но это пока на ранней стадии проработки ?
Спасибо за комментарий 🙌
Вы правы — DNS-мониторинг сам по себе не определяет, какая запись "правильная" или "задумана админом". Его задача — показать, что именно изменилось и когда это произошло, чтобы такие случаи можно было быстрее диагностировать
В приведённом в начале статьи кейсе это как раз могло бы помочь: администратор не знал, что старые MX-записи остались в зоне, и получил бы уведомление об изменении DNS-записей
Согласен, что проверка "действительно ли работает почтовый сервер" решается на другом уровне — и Statuser это тоже делает, но уже в рамках SMTP-проверок (для тех, кто их включает)
Идея с интеграцией с управляющими панелями DNS интересная — я тоже задумывался о таком варианте, особенно для случаев, когда нужно различать запланированные и незапланированные изменения. Пока собираю фидбек и думаю, как реализовать это аккуратно, чтобы не усложнять простые сценарии
Спасибо! Всё делаю на Next.js + shadcn/ui, с кастомной обвязкой под свои кейсы
Админку писал с нуля, без шаблона — вдохновляюсь интерфейсами Vercel и иногда заглядываю на Dribbble. Формы — через react‑hook‑form + zod, состояния — Zustand
Реализация авторизации самописная на NestJS. Использую http‑only куки и пару access + refresh токенов. Поддержана двухфакторка — есть TOTP и коды на емейл и в Телеграм, а ещё можно войти через Passkey
Привет 🤚
1. Эталонные скриншоты можно генерировать локально, а ещё у нас добавлена кнопка прямо в интерфейс отчёта после прогона, чтобы при необходимости сразу автоматизированно обновить референсы, её часто используем
2. Автоматизация создания задач не используется — мы просматриваем изменения вручную и заводим тикеты по ситуации
3. Прогоны тестов идут на проде (по расписанию, при релизе и вручную), на стейдже (при доставке и вручную) и на деве (вручную)
4. Тесты хранятся в отдельных репах, но они связаны с репами сервисов через пайплайны в GitLab
Для скриншотных тестов используем встроенные фичи Playwright. Фиксируем размеры, ждём загрузку нужных элементов, сравниваем только важные области — в итоге всё довольно стабильно. Иногда бывают небольшие сдвиги на 1–2 пикселя из-за особенностей самого Playwright, но это случается редко и обычно не мешает
Связка blackbox + Prometheus + Grafana действительно мощная, но требует времени на установку, настройку, поддержку и не решает прикладные задачи вроде статус-страниц, уведомлений в Telegram/email или скриншотов
Я запускал Statuser как решение «из коробки» — для тех, кто хочет мониторинг за пару минут и без DevOps-головной боли
А про фреймворк — да, похоже, я прошёл этот этап :) Только хочется, чтобы польза была не только для себя)
Да, UptimeKuma и Gatus классные. Буду рад фидбеку!
Спасибо! Рад, что статья вдохновила 🙌
Спасибо за ваш фидбек 😊
Привет!
Я разделил Next.js и NestJS как два отдельных сервиса: фронт работает как полноценный SSR-приложение на Next.js, а NestJS — это API и бэкенд-логика, которые общаются по HTTP
Как устроена связка:
Коммуникация через обычный REST (Axios с фронта)
Общий код — немного: только DTO, типы, enum и валидационные схемы, сейчас их никак не шарю, просто копирую, потому что так проще, чем делать шаренный пакет
Темная/светлая тема живёт исключительно на фронте. Управляется через next-theme, переключается на клиенте и прокидывается в className на html-теге. NestJS об этом ничего не знает и не должен — они не связаны в рамках одной транзакции
Авторизация — по JWT-токену с кукой (HttpOnly), который фронт получает после логина и кладёт в запросы на NestJS
Задержался с ответом, простите ?
Сильно зависит от задачи, для чата технической поддержки дефолтно можно выставить что-то такое:
temperature: 0.6
presence_penalty: 0.5
frequency_penalty: 0.5
А дальше уже начинать их крутить и искать оптимальный вариант под конкретный кейс, но полностью избавиться от галлюцинаций в версии 3.5 вряд ли получится)
Для модели 3.5 способов борьбы с галлюцинациями не так много (фактически 2):
1. Системный промт
2. Регуляция доп параметров, в первую очередь temperature, presence_penalty, frequency_penalty
Методом проб и ошибок подобрали подходящее нам сочетание параметров, плюс продолжаем смотреть за корректностью ответов и регулировать параметры модели и промт
Мы предупреждаем пользователей, что наш ИИ-ассистент может ошибаться и не следует ему безоглядно доверять)
Сейчас думаем над ручным управлением контекстом, но это пока на ранней стадии проработки ?