🎙 А сейчас передаем слово нашему старшему QA-инженеру Ане Зайцевой, чтобы узнать, как Tihon помогает ее команде.
Если хотите узнать больше о жизни, задачах, инструментах наших инженеров по обеспечению качества — подписывайтесь на канал Желтый QA. Там Аня и коллеги делятся кейсами, рассказывают про технологии тестирования, надежность и качество продуктов.
🔍 Как мы сделали QA-ассистента, который сам выбирает инструменты под задачу
QA-инженеры тратят часы на то, чтобы собрать контекст по задаче: открыть Jira, найти связанные MR, прочитать комментарии, проверить тест-кейсы в Allure, залезть в Wiki за документацией. А еще написать чек-лист или подготовиться к «Трем Амиго».
Мы создали ИИ-ассистента Tihon, который делает все это сам. Он построен на нашей LLM, развернут внутри контура банка и работает с Jira, GitLab, Wiki и Allure.
✨ В карточках рассказываем, какие тулы у него есть, как его настраивать и какие сценарии уже работают.
🔥 Находим инциденты еще до их появления — с помощью ИИ-мониторинга
Если у вас сотни сервисов и тысячи метрик, классический мониторинг начинает требовать все больше ручной настройки: пороги приходится регулярно пересматривать, алерты ведут себя по-разному в зависимости от нагрузки, и часть сигналов либо теряется, либо становится избыточной.
В 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 тысяч?
🔍 Мы в платформе доставок Т-Банка построили систему автопланирования, которая ежедневно распределяет встречи между представителями. В карточках рассказываем, как работает ее алгоритм, зачем нужны констрейнты и как оцениваем качество результата.