🔥 Находим инциденты еще до их появления — с помощью ИИ-мониторинга
Если у вас сотни сервисов и тысячи метрик, классический мониторинг начинает требовать все больше ручной настройки: пороги приходится регулярно пересматривать, алерты ведут себя по-разному в зависимости от нагрузки, и часть сигналов либо теряется, либо становится избыточной.
В Sage Observability мы сделали Anomaly Analyzer — слой над метриками, который вместо статических порогов использует статистику и ML. Он учится нормальному поведению системы и сигналит, когда метрика начинает отклоняться — еще до того, как это превращается в инцидент.
Что внутри:
↗️ Онлайн-анализ временных рядов.
↗️ Детектция аномалий без ручной настройки порогов.
↗️ Уведомления в почту.
↗️ Интеграция с Sage и внешними источниками.
Если хотите посмотреть, как это работает на практике, — приходите на вебинар 23 апреля. Разберем настройки Anomaly Analyzer и ответим на технические вопросы.
Такая проблема решается паттерном Transactional Outbox. Он помогает гарантированно отправить сообщение в Kafka, RabbitMQ или другой брокер, если основная операция в БД прошла успешно.
Мы сделали библиотеку, которая реализует этот паттерн для PostgreSQL и добавляет поверх него Kafka-подобную модель: топики, партиции, consumer group, offset.
В карточках рассказываем, как устроены producer и consumer, почему производительность не зависит от числа непрочитанных сообщений и как мы избегаем блокировок строк.
🕵️ Как один день в Австралии чуть не сжег нам процессор
Наш сервис продаж для юридических лиц работал шесть лет без нареканий и ошибок. Обычный бэкенд, который держит 30 RPS, обрабатывает миллион джобов в день и ест 125ms CPU. В начале года нам нужно было перевести его с NoSQL на PostgreSQL, и спустя час после деплоя прилетел алерт: CPU вырос в 10 раз. Поды начали перезапускаться, а у нас начался долгий траблшутинг.
😎 В карточках наш разработчик Антон Пронькин поделился, как мы заметили проблемы с CPU, на что выделялись гигабайты памяти, почему откат не помог, как ловили баг с помощью дампов и профайлера и при чем тут Австралия. А еще больше подробностей и графиков — на Хабре.
↗️ Как мы планируем маршруты для тысяч представителей каждый день
Представьте, что вам нужно распределить 5 представителей для встречи с клиентами. Нужно учесть их географию, график работы, навыки, категории встречи и кучу других параметров. А если таких представителей уже не 5, а 10 тысяч?
🔍 Мы в платформе доставок Т-Банка построили систему автопланирования, которая ежедневно распределяет встречи между представителями. В карточках рассказываем, как работает ее алгоритм, зачем нужны констрейнты и как оцениваем качество результата.
Бронируем последний летний слот в вашем календаре, чтобы встретиться на JVM Day
Мы уже вовсю готовим большую конференцию для всех, кто работает с JVM-технологиями. Она пройдет 29 августа в штаб-квартире Т-Банка в Москве.
В этом году вы можете выбрать один из трех форматов участия:
→ Спикер — выступить с докладом.
→ Стендист — представить ИТ-решение, которое создает ваша компания.
→ Участник — послушать доклады и обсудить рабочие вопросы с коллегами.
🔵 Если хотите рассказать о рабочих кейсах, новых подходах и необычных практиках — жмите на синюю кнопку. Всем спикерам мы поможем упаковать опыт в сильный доклад, подберем формат и проведем ревью материала.
🔴 Если хотите показать потенциальным пользователям ИТ-решение, над которым вы работаете — жмите на красную кнопку. Для всех, кто пройдет отбор, мы организуем демозону под компанию до трех человек со всем необходимым.
🟢 А если хотите на JVM Day в качестве участника — жмите на зеленую кнопку.
А это наша доставка поехала тестировать MVP. Среди грузовиков есть особенный — с историей, как мы выстроили работу над сервисом между 100 сотрудниками и госрегулятором.
Попробуйте его найти и кликнуть, чтобы прочитать наш кейс.