Оказалось, решение, безопасное для одной платформы, сломало приложение на другой.
Все потому, что мобильный SRE отличается от классического и в нем нельзя полагаться на привычные практики: нет ни отката, ни новых логов задним числом, ни полного контроля над средой.
В карточках рассказываем, как мы перестраиваем наблюдаемость, адаптируем SRE‑подходы под мобильный банкинг и что же произошло после того, как мы сломали iOS, спасая Android. А подробнее о том, как работает команда, читайте на Хабре.
⚡️ Как YAML-файл на 4 КБ съел у нас 2 ГБ оперативки
Мы мигрировали статические конфигурации из базы данных в файлы. Переезжали постепенно, файл за файлом. Когда добавили очередной YAML на 4 КБ, интеграционные тесты на пайплайне упали. Локально все работало, на продовых ресурсах тоже, но на раннере тестов приложение падало с OOM.
Мы провели расследование с профайлингом, нашли экспоненциальный рост памяти и исправили все одной строкой.
В карточках — как мы это делали, почему метод расширения из StackExchange.Utils оказался опасным и на что обращать внимание при работе с конфигурациями в .NET. А больше деталей с графиками и кодом — на Хабре.
🔥 Как мы разогнали workflow-движок от 20 до 100 процессов в секунду
Вокруг Zeebe существует немало стереотипов: медленный, сложный в настройке, нестабильный. Мы решили проверить это на практике. Для PoC использовали Camunda 8.5 и 8.6, протестировали движок в разных конфигурациях и выяснили, сколько он реально вывозит.
Начали с 20 процессов в секунду на минимальной конфигурации. Закончили стабильными 100 Pi/s. По пути наступали на грабли с партициями, дисками, воркерами и каскадными сбоями.
↗️ В карточках рассказываем, как устроена архитектура Zeebe, почему одна партиция не утилизирует CPU, как диск уровня silver убивает производительность и как настроить воркеры для увеличения пропускной способности движка. А подробнее читайте на Хабре.
✨ Как за один вечер обучить ML-модель на кросс-доменных данных
Многие компании хранят петабайты данных о своих клиентах — историю просмотров, кликов, покупок, касаний с рекламой и коммуникациями. Но, чтобы выжимать максимум из этих данных, нужно качественно моделировать все источники, описывающие одного пользователя.
Мы сделали Perseus — open-source-фреймворк, который объединяет данные из разных источников в одну последовательность событий о пользователе и обучает трансформерные модели под широкий класс ML-задач.
В карточках рассказываем, как устроен фреймворк, какие архитектуры поддерживает, какие задачи закрывает и почему кросс-доменность дает прирост качества.