Запрос получил 202, автотест прошёл, а через несколько дней выясняется, что часть операций так и не завершилась успешно. Такая ситуация возникает, когда проверяется только ответ HTTP‑обработчика, а сама асинхронная цепочка остаётся без контроля. Разберём, как построить тест для API с polling: от запуска операции и проверки статуса до валидации итогового результата и безопасного повторного запроса.
Представьте, что в вашу команду взяли уверенного миддла. Но ему не дали доступ к трекеру, не показали базу знаний, а про архитектурные решения рассказали один раз на онбординге. Его изредка просят что‑нибудь погуглить, иногда поручают небольшую фичу в отрыве от контекста большой картины, а потом ругают за плохое понимание задачи и принятых в компании процессов.
Вот так примерно я вижу внедрение нейронок в процессы разработки. Под катом — про то, какие грабли возникают при внедрении агентской разработки в процессы вне зависимости от размера команды и компании и что я наработал и подглядел у других за годы парного программирования с компьютерами.
Сбор кодового покрытия для небольшого проекта обычно не вызывает особых сложностей: собрали код с поддержкой coverage, запустили тесты и получили отчёт. Но когда речь идёт о целой операционной системе с тысячами компонентов и тестов, процесс становится значительно сложнее.
В статье разберём, как организован сбор покрытия в ОС «Нейтрино»: от сборки компонентов и получения файлов .gcno и .gcda до формирования трассировочных файлов и объединения результатов из различных CI/CD‑конвейеров. Также рассмотрим особенности формирования итоговых отчётов и расскажем, почему в дальнейшем планируется переход с lcov на gcovr.
Можно ли научить детектор атак, ни разу не показав ему настоящую атаку?
Звучит как противоречие. Если хочешь, чтобы нейросеть находила боковое движение, ей вроде бы надо показать боковое движение. Я сделал наоборот: сгенерировал целую корпоративную сеть с её историей входов, устроил в этом выдуманном мире нападение и обучил на нём сети. Ни одной настоящей строки в обучении. Весь мир описан конфигом на 135 строк, каждая сеть весит четыре тысячи параметров и учится за секунды на ноутбуке; лучший результат дали шесть таких сетей, обученных на шести разных выдуманных мирах.
Потом я выпустил их на настоящие данные: журналы аутентификации Лос-Аламосской лаборатории, 1.65 миллиарда событий, с размеченными учениями красной команды.
И это сработало. Сети выстраивают 3.6 миллиона окон по подозрительности, и в верхних двадцати трёх строках списка стоят шестнадцать настоящих атак и семь ложных тревог: аналитику остаётся открыть эти строки. Пороговому счётчику, чтобы добраться до шестнадцатой атаки на тех же данных, нужно сто шестьдесят одна тысяча ложных тревог. По AUC синтетика вошла в диапазон исследовательских работ, обученных на настоящих размеченных данных, хотя сравнивать их в лоб нельзя, и я объясню почему.
Чуда всё равно не случилось. Зато случилось другое: я дважды написал красивый вывод и дважды забрал его назад, когда эксперимент его опроверг. И нашёл петлю, ради которой вообще стоит писать генератор: ошибка детектора показывает конкретную машину, ты понимаешь, какого явления нет в твоём выдуманном мире, дописываешь две строки конфига, и ошибка исчезает.
Тестирование API часто сводится к одному: отправить запрос и убедиться, что сервер ответил 200. На собеседовании этого хватает на пару минут, а в проде именно здесь всплывает то, чего статус-код не ловит: чужой заказ в ответе, молчаливый 500 вместо ошибки валидации, товар, который не списался со склада.
Разберём 20 базовых проверок, которые отличают QA, тестирующего API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы — на одном сквозном сценарии, с примерами на curl и в Postman. Начинающий выстроит последовательность, опытный сверится и поймёт, куда расширять набор тестов.
Всем привет. На связи Сергей Игнатенко, основатель ИИ-платформы VibePilot. Мы сделали свой бенчмарк моделей ИИ на реальных задачах: сметы, договоры, многостраничный Excel. 1 198 задач, 22 сбоя, 1,8%. Считается, что суверенные модели слишком слабы для агентов. Внутри жёсткого конвейера Алиса делает смету с разделами за 19 секунд и обгоняет Qwen3-235B в четыре раза.
Всё началось со странной потери скорости решения задач.
Сначала я думал, что это чисто субъективное наблюдение. Проекты развиваются, документация растёт, архитектурных связей становится больше. Значит, AI-агенту нужно прочитать больше файлов, удержать больше решений и проверить больше зависимостей. Контекст растёт — время выполнения задач тоже растёт. Вроде бы всё логично.
Насчёт лимитов я особо не переживал. Подход моей AI-команды позволяет параллельно работать над несколькими крупными проектами на подписке Claude Code стоимостью 100 долларов. Команда разделена на роли, у каждой роли собственная рабочая область, задачи декомпозируются, а большие исследования можно выносить в отдельные сессии. Система была рассчитана именно на то, чтобы не складывать весь проект в голову одному агенту.
Но затем мой AI-архитектор продукта дважды ушёл в сжатие контекста.
Он работал на Opus с контекстным окном в один миллион токенов.
Первый раз можно списать на случайность. Второй — уже закономерность.
И вот тогда стало понятно: мы имеем дело не просто с тем, что «большие задачи выполняются дольше». Внутри рабочего процесса есть механизм, который незаметно съедает контекст, время или оба ресурса сразу.
Началось расследование.
Тогда я ещё не знал, что системная проблема всей AI-команды началась, скорее всего, с одной моей ошибки в терминале.
Привет, Хабр! Меня зовут Елена Бабенко, я QA lead в одной из продуктовых команд Pangolin в Сбертехе. Мы разрабатываем СУБД, процесс это сложный и интересный, ведь помимо теории программирования и тестирования нам нужно разбираться и в работе PostgreSQL. Но здесь я хочу рассказать не про ежедневные задачи тестирования, а про релизы и роль выпускающего QA-инженера (обычно эту роль у нас берёт на себя один из QA‑лидов). Эта статья будет интересна тестировщикам, которые работают с крупными продуктами, чьи релизы занимают не час, а обычно пару недель.
СУБД Pangolin — один из таких больших продуктов, и примерно четыре раза в год у нас случается релиз. В каждую версию входят новые фичи, багфиксы, иногда — рефакторинг и другие улучшалки. В общем, большое количество нового кода. Конечно, каждая отдельная задача уже протестирована, но перед выходом в эксплуатацию необходимо стабилизировать уже всю сборку как цельный продукт.
От релиза к релизу мы улучшаем наши процессы и ускоряем разработку. У нас есть много Quality Gates для проверки — помимо стандартных юнитов, мы запускаем регрессы в различных вариациях (состояние сборки по умолчанию, кастомные комбинации, например с разными типами лицензий), обновления с предыдущих версий (здесь же и откаты), совместимость с разными ОС и другое.
Для многих запуск всех проверок — это муторная и неинтересная работа, которая ещё и занимает порядочно времени. А ведь потом надо все эти проверки сверить, проанализировать падения тестов, разобраться с багами (если такие будут), починить флакающие тесты... И в конце концов запустить это всё ещё раз для финального сбора отчётов.
Один SVG: при 640 пикселях QR не читается, при 320 читается. Разбираю, как локатор принял часть подписи за угол кода, почему удаление букв возвращало чтение и как удалось оставить подпись на месте. С контрольными опытами и исходниками.
Недавно я обновил свою видеокарту до RTX-5060-TI 16GB. Получив новую карту я решил исследовать, что можно на ней запустить из нейросетей. Традиционно пишут, что нормальные ИИ модели начинаются с rtx3090 и выше, что ниже 24GB VRAM жизни нет. В этой статье я постараюсь развеять этот миф.
Я делаю систему, которая собирает черновики производственных инструкций. В ней есть детектор опасных формулировок — и он исправно срабатывал на фразе «убедиться, что в зоне движения нет людей». То есть на правиле техники безопасности, как на его нарушении.
Починил и задумался: а остальные шестьдесят проверок качества что-нибудь измеряют? Написал инструмент, который портит документы изнутри схемы и смотрит, какие проверки реагируют. Тридцать не реагируют ни на что.
Дальше оказалось, что этот инструмент сам имел слепую зону, его отчёт считал не проверки, а строки, которые они печатают, а пороги из конфига в код не попадали. Семь уровней, и на каждом одно: проверка выглядит рабочей и не работает.
За облачным CDN у нас стоял Xray с транспортом XHTTP. Пользователи жаловались двумя фразами: «тормозит» и «отваливается насовсем». В августе я померил и увидел, что граница CDN спорадически теряет 2–5 % запросов под параллельной нагрузкой. Версия сходилась идеально: для XHTTP в режиме packet-up потерянный запрос — это дыра в последовательности, а дыра — это разрыв сессии.
Второго сентября я повторил тот же замер на том же стенде. Ноль потерь на 1350 запросах.
Ниже — обе серии, объяснение расхождения и та часть выводов, которая уцелела: четыре ограничения границы, о которые HTTP-туннель спотыкается независимо от того, теряет она что-нибудь или нет.
Привет, Хабр! Меня зовут Владимир Заикин. Под руководством Семёна Григорьева @rsdpisuy, я занимаюсь разработкой на ПЛИС в лаборатории YADRO в СПбГУ. Мой рассказ — о том, как мы реализовали общение по PCIe с ПЛИС на плате Sipeed Tang Mega 138K Pro с кристаллом GW5AST-138K от Gowin.
Устройство, реализованное на ПЛИС, должно было принимать данные по PCIe, сохранять их в DDR3 и обрабатывать пользовательской логикой. Чтобы реализовать такую функциональность, мы обратились к примеру взаимодействия с PCIe-контроллером от производителя платы, но тот оказался нерабочим. Пришлось разбираться самим. В итоге мы сделали рабочий стенд: Linux-драйвер, хост-программа на C и аппаратное описание на Verilog. Все это выложили в открытый доступ, чтобы поделиться своим опытом и помочь другим безболезненно разобраться с этой проблемой.
Что делать, когда есть вполне стандартная задача, но популярные инструменты не могут ее решить? Правильно, время - изобретать свой велосипед.
Задача состоит в следующем: есть некие параметры, часть из которых может быть объединена в каскады, нужно вычислить покрытие параметров, при этом учитывать, что если есть тесты на каскад, в котором присутствует параметр, то параметр считается покрытым.
Видим, что нам необходимо проверять на покрытие именно сущности, а не ветвление, сценарии или код, как это делают, допустим, coverage.py или pytest-cov
Применение WAF (Web Application Firewall, межсетевой экран уровня приложения) в современном Вебе — стандартная и обязательная практика. В руках злоумышленников — большое количество профессиональных и, главное, доступных инструментов анализа защищенности и взлома. Приходится ответственно подходить к выбору WAF, понимать, где его правильно разместить и как грамотно настроить.
Сегодня мы познакомимся с решением Coraza, развернем его в инфраструктуре Selectel, а также разберем, как писать свои правила для выявления вредоносных запросов. Интересно будет всем, кто так или иначе вовлечен в защиту общедоступных ресурсов.
Раньше утечка данных была в первую очередь репутационной проблемой. Информация разошлась, несколько дней её обсуждали в телеграм-каналах, компания объяснилась — и постепенно история забывалась. Штраф тоже редко становился серьёзной проблемой: 60 тысяч рублей — примерно стоимость корпоратива для отдела.
Модель вернула не все записи, валидатор отбросил пригодные данные, ручная очередь спрятала подходящие вакансии. Разбираю три места, где мой конвейер терял полезные результаты, и проверки, которые помогли это обнаружить.
Когда агент в проде ошибается, спор идёт по кругу: модель тупит, промпт кривой, API виноват. Свежая работа Scale AI даёт отказам адрес — ребро между компонентами и сторону вины. Оказывается, «виновата модель» почти никогда не значит «чинить дообучением»: разбираю таксономию из 41 режима, каталог-выжимку и четыре своих отказа с числами — ни один не закрыт сменой модели.
Breaking change в REST API часто обнаруживают слишком поздно — уже на интеграционном стенде. Разберём, какие риски можно поймать раньше, где помогают OpenAPI и consumer contracts и почему зелёные проверки ещё не гарантируют совместимость со старым клиентом.
В данном тексте я выполнил обзор одного широко известного и очень распространенного мультиметра модели XDM1241.
При тестировании электронных плат часто надо делать множество однообразных измерений напряжений. Например для проверки линейности ADC пинов на автомобильных ECU. Чтобы исключить человеческий фактор надо автоматизировать данную задачу.
В этом тексте я показал как опрашивать мультиметр по последовательному порту без использования лицевого HMI.
