Меня зовут Алексей Тиньков, я занимаюсь тестированием производительности уже 8 лет. В первой статье цикла хочу поделиться своим опытом организации процесса нагрузочного тестирования (НТ), рассказать о том, как правильно думать о тестировании производительности и чем оно принципиально отличается от привычного функционального тестирования.

Однажды в проде контейнеры одного из сервисов начали падать по OutOfMemory. Контейнерам было выделено по 4 ГБ оперативной памяти, нагрузка была вполне обычной: десятки страниц в секунду.

Расследование показало, что проблема была в JSON-конфиге.

Схема была стандартная. В базе данных хранился JSON. При запросе приложение доставало его из базы, выполняло дополнительную обработку — заполнение вычисляемых полей, обогащение справочниками — и сохраняло результат в Redis. Подавляющее большинство пользователей запрашивало один и тот же JSON и ходило за ним в Redis.

Из-за ошибки в обработке закэшированный JSON распухал до десятков мегабайт. В кэш писались не только нужные поля, но и вложенные коллекции, история изменений, сериализованные справочники.

Казалось бы, если мы запрашиваем один и тот же JSON, размер не должен так критично влиять.

Но всё оказалось интереснее…

Хабр, и снова здравствуй) На связи Алексей Боровиков, архитектор Astra Cloud. Тут такое дело, мы выкатили мажорный релиз нашей облачной платформы. Работа была проделана колоссальная, я не буду писать все изменения, иначе это будет не статья, а книга. Поэтому решил сфокусироваться на одном компоненте и рассказать, как мы его сделали и почему. Речь идет про IAM — Identity and Access Management. Он отвечает на главные вопросы облачной безопасности: кто, что сделал и имел ли на это право. Итаааак…

Каждая вторая статья про «алгоритм Threads 2026» держится на цифрах, которых никто не показывает. Я решила посчитать сама и заодно проверить, переживут ли выводы тест на случайность.

200 аккаунтов русскоязычных маркетологов, 16 724 поста. После чистки осталось 4 848 профессиональных постов от 103 авторов. Метод — нормализация внутри автора плюс перестановочный тест. На четырёх признаках из двенадцати это переворачивает знак эффекта относительно наивного подсчёта.

Результат неприятный: три самых частых приёма у маркетологов работают в минус, а приём с самым сильным плюсом встречается всего в 6% постов.

Дальше — сбор данных, метод с кодом и точными p-value, результаты и раздел про ограничения, которых тут хватает.

Threads принадлежит компании Meta, которая признана в России экстремистской организацией и её деятельность запрещена.

Добавили потоков, а программа стала медленнее? Причина может скрываться в ложном разделении кеш‑линий: потоки работают с разными переменными, но процессор всё равно заставляет ядра конкурировать за один участок памяти.

Разберём, как воспроизвести такую просадку, найти её через perf c2c и исправить без лишнего раздувания структур.

Когда речь заходит об оптимизации запросов в PostgreSQL, разработчики, как правило, сосредотачиваются на времени выполнения: индексы, планы запросов, настройки памяти и так далее. Время планирования остаётся в тени. А зря! Планировщик работает перед каждым выполнением запроса. Для OLTP-нагрузки с короткими транзакциями накладные расходы на планирование могут составлять значительную долю от общего времени ответа. Для запросов с большими IN-списками и высоким statistics_target планирование может занимать сотни миллисекунд, тогда как само выполнение укладывается в миллисекунды. Именно поэтому ускорение планировщика не менее важно, чем ускорение выполнения. Эта статья - о том, как мы нашли и устранили одну из таких скрытых проблем.

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

МЫ уже 15+ лет организуем масштабные ит-конференции – DUMP, PYCON, RUSTCON. А в прошлом году дебютировала наша новая конференция для разработчиков golang –  Let's GoConf. За это время через нас прошли сотни заявок, и одна вещь повторяется из года в год: сильные инженеры часто присылают слабые заявки, а средние на первый взгляд идеи иногда превращаются в отличные доклады.

Почему так происходит?

Перед вами шестая и заключительная часть (а вот первая, вторая, третья, четвёртая и пятая) серии статей, посвящённых информационным технологиям в авиаперевозках. Сегодня мы поговорим об изменениях, происходящих в этой сфере. Системы, построенные на базе стандарта NDC, вот уже 14 лет пытаются вытеснить традиционные GDS. Этого до сих пор, в полной мере, не произошло. У такого положения дел есть определённые политико-экономические причины. Здесь же автор расскажет о том, что он, благодаря инциденту с птицей, узнал о системах, которые вот уже много лет пытаются заменить.

Стоимость привлечения клиента стремительно растет: Gо данным E-Promo Group, за первый квартал 2026 года цена клика увеличилась на 3%, а стоимость целевого действия — на 26%. Одновременно меняется поведение пользователей: они дольше принимают решения и совершают меньше импульсивных покупок. В таких условиях таргетинг, который ищет клиента только в момент горячего спроса, охватывает узкий и дорогой срез аудитории. 

В этой статье разбираем, как расширить охват за счет изучения жизненного пути и смежных покупок пользователя, и как это реализовано в кабинете Авито Рекламы.

12–14 ноября 2026 года в Санкт-Петербурге пройдет INFOSTART A&PM EVENT 2026 - конференция для аналитиков, руководителей проектов, владельцев продуктов и специалистов, работающих с проектами и продуктами на платформе 1С.

Сайт конференции уже открыт. На нем опубликованы программа, тематические секции, состав модераторов и варианты участия.

Если в кластере больше пяти Helm-релизов, рано или поздно появляется скрипт. Сначала десять строк с helm upgrade --install, потом sleep 30 между базой и приложением, потом sops ▎ -d values.yml | helm -f -, потом ветка if [ “$ENV” = prod ]. В какой-то момент никто не может сказать, что именно он раскатит на проде, пока он это не сделает.

▎ nelmwave заменяет этот скрипт одним манифестом

Cuddli стал №1 среди дейтинг-приложений для гиков, собрал более 100 000 пользователей, помог создать тысячи пар, а пользователи настолько любили сервис, что сами раздавали его стикеры и рекламировали приложение на фестивалях.

А потом закрылся.

Всем привет! Меня зовут Муса. Наша команда занимается витринами данных по товарному учёту.

Каждый день мы доставляем около 10 млрд записей в разных форматах. На этих данных строится различная аналитика, связанная с товарными запасами и движениями экземпляров. Перед нами встала задача: пять раз в день обогащать выгрузку из миллиардов экземплярных остатков дополнительными атрибутами для построения различного рода аналитики. История этих атрибутов уже измерялась десятками миллиардов записей.

Первое решение выглядело просто: положить данные в ClickHouse и сделать JOIN. Но одна выгрузка считалась около 12 часов, а нам нужно было укладываться в десятки минут.

В статье расскажу, про то, как мы смогли сократить время обработки примерно до 33 минут, про ключевой подход при работе с большими объёмами данных, а также попытаюсь донести важность локальности данных на примере реальной задачи.

Вокруг агентных автоматизаций разворачивается нешуточная битва. Евангелисты обещают, что ИИ-агенты вот-вот заменят все и всех, скептики интересуются реальными сценариями таких автоматизаций, ROI и прочей конкретикой (но обычно не получают ответов). 

Мы сами получаем много вопросов о практическом применении агентной автоматизации в бизнесе, и в этой статье расскажем, как сейчас обстоят дела и куда все движется.

В логах запуска нашего стенда давно живёт строка Failed SDO download 0x6060 (-22). Мы её лечили всерьёз — пока не заметили, что та же строка печатается и в успешных запусках. Подтверждение на полевой шине приходит почти всегда, а значит куда меньше, чем кажется. Под катом — четыре ступени «принял» на живых замерах: почему сброс ошибки с честным ack её не снимает; как электронный редуктор не увидеть замером, который сам через него идёт; и сколько стоит спросить привод по SDO — 32 мс на параметр, полный паспорт около десяти секунд.

Приветики, меня зовут Пётр и я продуктовый аналитик с коммерческим опытом в ПА около 12 лет. В моей работе глобально задачи делятся на 3 типа — разметка событий, аб‑тесты и продуктовые рисерчи.

Про разметку я уже писал тут https://habr.com/ru/articles/785320/

Под аб‑тесты мы с корешами собрали коммерческий воркспейс. Было тут: https://habr.com/ru/articles/1064034/

А вот продуктовые рисерчи это отдельный пласт задач, которые включают в себя всякие оценки релизов, изучение какого‑то элемента или флоу/микроворонки, поиск аномалий и куча всего такого, что не ложится в разметку и тестирование.

Последние месяцы я довольно активно разрабатываю собственный AI SaaS-проект. Причём активность в случае AI-разработки имеет немного другой смысл, чем раньше. Когда значительную часть работы выполняют AI-агенты, скорость появления изменений резко возрастает. Агент создал изменения, открыл PR, другой агент или workflow проверил результат, если что-то не прошло, то новая итерация.

И довольно быстро я обнаружил неожиданное ограничение этой модели разработки. Если честно я ожидал и боялся упереться в токены LLM. Были небольшие опасения в производительности моего ноутбука. И даже сложность оркестрации не стала блокером.

Я упёрся в GitHub Actions квоту.

Некоторое время назад понадобилось массово определять, в какой версии КОМПАС был создан файл без установки самой программы. Задача возникла при обработке большой базы чертежей и моделей (.cdw, .spw, .frw, .m3d, .a3d), так как для каталога неплохо было бы понимать минимальную версию программы, в которой файл ещё открывается.

В процессе выяснилось, что у КОМПАС-файлов два принципиально разных контейнера, один из них бинарный и для него нет никакого официального описания формата.