Алмаз Саляхов

1 сентября 2026

Контекст для LLM собирает агент, а не сама модель

В пайплайне есть LLM-модель, и контекст она получает от агента. Агент отвечает тем, что дёргает API-инструменты компании. Дальше LLM-модель генерирует текст-ответ.

flowchart LR
    A[Агент] --> B[API-инструменты компании]
    B --> C[Контекст]
    C --> D[LLM-модель]
    D --> E[Текст-ответ]

29 августа 2026

Стенд, где баг заранее спрятан на известном слое

Собрал учебную песочницу для отработки локализации по слоям: кнопка → JavaScript → HTTP → API → БД → ответ → UI. Одиннадцать смоделированных отказов — от JS-ошибки до отправки запроса и «тихого» игнора успешного ответа до отката транзакции и ответа 201 без реальной записи. Отдельно — случаи, где клик вообще не долетает до обработчика: прозрачный слой поверх кнопки, disabled, снятый removeEventListener. Смысл упражнения — не читать код заранее, а по фактам из DevTools и БД находить последний исправный и первый неисправный слой.

22 июля 2026

Лимит на тысячу, спрятанный в фоновой функции

Массовая загрузка данных в колоночное хранилище падала после тысячи с лишним вызовов с жалобой на «слишком много файлов в таблице». Причиной оказался жёстко прошитый лимит внутри фоновой процедуры согласования каталога, а не объём данных. Отдельная находка на пути к воспроизведению: сценарий работает только вне транзакционного блока — в цикле внутри транзакции движок отказывается работать сам, и баг за этим прячется. Лимит убрали.

21 июля 2026

Матрица классов данных против «потыкать руками»

Конвертор строкового представления в колоночное проверял систематической матрицей из одиннадцати классов данных вместо выборочных проб. Нашлось шесть дефектов преобразования типов: NULL в текстовой колонке, несовпадение длины у numeric, время без часового пояса, интервал, а также расхождение содержимого после добавления и после удаления колонки. Все шесть лежали в тех сочетаниях, до которых выборочная проверка не доходит.

20 июля 2026

Данные не пропали: как это доказать, а не заверить

На стороне заказчика из более чем четырёх тысяч файлов на дашборде стало видно меньше половины, и версия была одна — данные удалились. Свёл три независимых счёта: записи в каталоге, файлы физически на диске и осиротевшие файлы во временной папке. Сумма сошлась без остатка — значит двигалось зеркало, а склад не тронут. Попутно из журнала операций выяснилось, что больше половины транзакций обрывались: сервер регулярно уходил в нехватку памяти. Рекомендация была остановить ручную пересборку базы, пока причина не устранена.

9 июля 2026

Честный отрицательный результат тоже результат

Планировщик, по жалобе, не переставлял порядок соединения таблиц, и разница между двумя написаниями одного запроса доходила до 3,5 раза — 1,27 с против 0,36 с на ста миллионах строк. На упрощённом синтетическом тесте той же версии баг не воспроизвёлся: планировщик сам ставил селективный джойн первым. Так и записал — на простом кейсе не подтверждается, на сложном воспроизводится. Заключение без этой оговорки было бы красивее и бесполезнее.

Дефект в DuckDB #23729

8 июля 2026

Два терабайта из хранилища ради пяти колонок

Запрос с оконной функцией и ROLLUP выполнялся сорок пять минут и вычитывал из объектного хранилища около двух терабайт — примерно полтора миллиона запросов на чтение, — хотя ему требовалось пять колонок из семидесяти шести. Минимальный репродюсер на одном parquet-файле показал разницу планов: при прямом чтении движок берёт только нужные пять колонок, а через представление с приведением типов читает все семьдесят шесть. Сравнение двух планов — самый дешёвый способ показать разработчику, где именно теряется оптимизация.

24 июня 2026

Пайплайн юнит-тестов там, где его не было

У открытого расширения апстрим собирал только релизные бинарники — прогона модульных тестов в закрытом контуре не существовало. Построил его с нуля: сборка отладочной конфигурации, прогон тестов, разбиение на восемь параллельных чанков. Быстрый режим на merge request — около 422 тестов примерно за четверть часа, полный ночной прогон со «медленными» тестами по расписанию. Один нестабильный тест исключил не наугад, а после разбора конкретного падения. Добавил уведомления о результате в командный чат и написал к ним инструкцию для нового сотрудника — пайплайн полезен ровно настолько, насколько им пользуются другие.

20 мая 2026

Искал баг с регистром имени, нашёл падение сервера

Заказчик сообщил об ошибке при создании таблицы с заглавными буквами в имени и добавлении в неё файлов из объектного хранилища. Развернул виртуальную машину с S3-совместимым хранилищем и собрал воспроизводимый сценарий. На нём сервер стабильно падал с переполнением стека и уходил в автоматическое восстановление по журналу — дважды подряд на одном и том же вызове. Заявленная проблема с регистром оказалась внешним симптомом гораздо более серьёзного дефекта.

1 июня 2025

Бэкап в объектное хранилище с шифрованием, стенд целиком в контейнерах

Собрал воспроизводимое окружение для проверки резервного копирования распределённой СУБД: кластер из нескольких узлов с автоматическим переключением, S3-совместимое хранилище с TLS и отдельным сервисом шифрования ключей, метрики. Отработал полный цикл — создание хранилища бэкапов, полная копия, намеренное разрушение данных, восстановление на точку во времени в отдельный каталог и проверка результата поднятым рядом экземпляром СУБД. Заодно развёл для себя логические и физические бэкапы: первые переносимы, вторые дают восстановление на момент времени.

1 сентября 2023

Семнадцать тысяч регрессионных сценариев на контур

Сервис подсказки и нормализации почтовых адресов проверялся не выборкой кейсов, а данными: по регрессионному пакету примерно в 17,6 тысячи сценариев на каждый из двух контуров — подсказку и валидацию, — где сценарий это один реальный адрес и проверка, что ответ не «уплыл» после обновления индекса. Ручных функциональных кейсов поверх этого — около 1,3 тысячи. Плюс профили нагрузки в трёх режимах: постоянная, плавно нарастающая и ступенчатая по конкурентности; один из прогонов — 90 запросов в секунду в течение пятнадцати минут, 232 тысячи замеров.