Kurgan-Telecom Ru | Информационные технологии

Обычная HTTP-проверка может показывать, что ИИ-сервис работает, хотя его пользователи уже не получают ответы. Эндпоинт доступен, гейтвей на месте, но до самой модели проверка не доходит.

Привет, Хабр! Меня зовут Михаил Шпаков, я развиваю Statuser — сервис мониторинга доступности сайтов. Раньше я рассказывал, как он появился и что я узнал за год, мониторя 6 500 сайтов.

Недавно мне написал пользователь Statuser. В его продукте модель разбирала обращения клиентов и готовила для операторов черновики ответов. В какой-то момент эта функция перестала работать, хотя обычный HTTP-монитор, настроенный на адрес ИИ-гейтвея, продолжал показывать зелёный статус. О проблеме сообщили операторы поддержки, а не мониторинг.

Причина оказалась простой: провайдер снял выбранную модель с обслуживания, но сам гейтвей продолжал работать. HTTP-монитор проверял его обычным GET-запросом и получал успешный ответ. Запрос на генерацию он не отправлял, поэтому состояние конкретной модели не видел.

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

После этого случая я понял, что не хватает отдельного типа мониторинга. Он должен не просто обращаться к адресу гейтвея, а отправлять настоящий запрос выбранной модели и проверять её ответ. Так в Statuser появился мониторинг ИИ-моделей.

Я Илья, руководитель направления геймификации в PARI. До работы здесь у меня был свой бизнес в рамках холдинга EXCORP.GG: мы делали игровые спецы для EXTREMUM и CS.MONEY. Я устал от того, что каждый спецпроект собирается с нуля, живёт пару недель и умирает.

Поэтому я понял: если склеить разные игровые механики в одну систему, они будут лучше работать вместе и усиливать вовлечение. Тогда я защитил эту идею перед фаундерами и основал LVL.IO — компанию, в которой мы создали такой продукт. Эту идею я показал ex-главе киберспорта PARI Ивану Бураченко — и она легла точно под годовой контракт с BLAST, который компания подписала в 2022-м. 

За облачным CDN у нас стоял Xray с транспортом XHTTP. Пользователи жаловались двумя фразами: «тормозит» и «отваливается насовсем». В августе я померил и увидел, что граница CDN спорадически теряет 2–5 % запросов под параллельной нагрузкой. Версия сходилась идеально: для XHTTP в режиме packet-up потерянный запрос — это дыра в последовательности, а дыра — это разрыв сессии.

Второго сентября я повторил тот же замер на том же стенде. Ноль потерь на 1350 запросах.

Ниже — обе серии, объяснение расхождения и та часть выводов, которая уцелела: четыре ограничения границы, о которые HTTP-туннель спотыкается независимо от того, теряет она что-нибудь или нет.

Что происходит, когда команда оценивает задачу до знакомства с чужим кодом? В нашем случае это приводило к оптимистичным срокам, неожиданным A/B-реализациям, повторным итерациям ТЗ и багам, которые обнаруживались уже на тестировании.

Мы добавили Tech Discovery — раннее исследование кода до финализации требований, дизайна и оценки. В статье расскажу, для каких задач этот процесс окупается, сколько времени занимает, какие результаты должна получить команда и чем наш подход отличается от обычного технического spike.

На выборке из семи задач TTM средних и сложных проектов сместился с диапазона 1,5–3 месяца к 1–2 месяцам, а количество профильных багов на эпик — с 6–12 до 4–9.

За 35 лет работы с программным обеспечением я наблюдал смену поколений антивирусов, эволюцию подходов к обнаружению угроз и бесконечный цикл гонки между авторами вредоносного ПО и разработчиками средств защиты. Однако сама суть проблемы осталась неизменной.

Появляется новый вредоносный файл. Его обнаруживают, анализируют, классифицируют, добавляют в базы или модели обнаружения. Затем появляется модификация, обходящая существующие правила, — и цикл повторяется.

Мне давно было интересно другое: что, если строить детект не вокруг вопроса «знаем ли мы этот файл?», а вокруг вопроса «насколько поведение и структура этого файла характерны для вредоносной программы?»

Так появился экспериментальный проект HAV — Heuristic AntiVirus. Это не коммерческий продукт и не попытка заменить существующие решения. Это исследовательский эксперимент, цель которого — проверить, насколько далеко можно продвинуться в обнаружении вредоносного ПО с помощью статического и динамического анализа, статистики и эвристических моделей. Репозиторий проекта опубликован в открытом доступе.

Шесть дней назад я рассказал здесь про resume2human — программу, которая из резюме делает список вакансий и по каждой находит 1–3 живых человека с именем, ролью и адресом, чтобы написать им напрямую. За неделю в проект уехал 21 коммит в девяти PR, тестов стало 746 вместо 345, и я нарушил ровно половину обещаний, которые дал в том тексте. Внутри: бесплатная ступень поиска личных контактов, которая держится на git вместо платных баз; три бага, из-за которых прогон честно искал не то, что просили; и разбор того, почему покрытие пустого множества равно единице и что это стоило мне в скоринге.

Есть Grafana.

Есть n8n.

Есть Dockge.

Есть несколько внутренних админок и staging-сайтов.

У каждого из них уже есть собственная авторизация. Казалось бы, что ещё нужно?

Но меня долго смущала одна простая вещь: почему форму логина вообще должен видеть весь интернет?

Да, за ней стоит пароль. Возможно, MFA. Возможно, очень хороший механизм аутентификации.

Но сам сервис всё равно торчит наружу. Его можно сканировать, определять по заголовкам и поведению, искать конкретную версию, долбить login endpoint, перебирать известные CVE.

Можно решить вопрос VPN.

Можно поднять Authentik или Authelia.

Можно использовать Cloudflare Access или другой Zero Trust.

Можно добавить Basic Auth перед обычной авторизацией и получить прекрасный UX из двух логинов подряд.

Но для нескольких моих сервисов всё это казалось слишком большим решением для очень маленькой задачи.

Мне хотелось буквально следующего:

Допустим, вы хотите перенести модельку из одной игры в другую.

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

OpenAssetTools / ZoneTool автоматизируют процесс конвертации для Call of Duty

UE Viewer экспортирует данные Unreal в GLTF, PSK, DDS и др.

Мы сегодня рассмотрим альтернативный путь. Как вам идея переписать рантайм целевой игры с нуля и добавить нативную поддержку чужих ассетов? Моя попытка сделать что‑то подобное привела к созданию экспериментального движка IW4L, основой для которого является IW4 (Call of Duty Modern Warfare 2 2009).

В статье расскажу, как в КОРУСе запустили для студентов внутреннюю программу Sales Camp, куда привлекли руководителей из бизнес-направлений в качестве наставников. О причинах запуска, воронке отбора, двухэтапной системе обучения и главном бизнес-эффекте от программы — далее.

В бою игрок должен сражаться. А вместо этого он сказал: «Я отрезаю себе палец и кладу его в чашу, чтобы решить загадку». И тут я понял, что придумать правило на каждый кейс невозможно. Под катом про то, как заставить ИИ-движок соблюдать правила, которые нигде не прописаны.

Qwen3.8-27B в Q4TP занимает около 14,3 GB весов, но при длинном контексте упирается ещё и в KV-кэш. Для 16 full-attention слоёв этой гибридной модели FP16 KV-state растёт на 65 536 байт с каждым токеном: на 64K это около 4 ГиБ только для K/V.

В экспериментальном режиме O(1) рантайм CMF заменяет растущий KV-кэш этих 16 слоёв фиксированным состоянием: четыре sink-токена, точное окно последних 128 токенов и 32 опорных представлений для дальней части. В использованном профиле GPU-state attention составляет 44,1 МиБ, и не увеличивается с длиной контекста.

Я, как технический писатель-аналитик, каждый день делегирую искусственному интеллекту создание текстов, структурирование и генерацию документации. Но иногда модель выдаёт такие глупые логические ошибки, что хочется ̶н̶а̶о̶р̶а̶т̶ь̶ ̶н̶а̶ ̶н̶е̶е̶ ̶ закрыть чат и переписать всё руками.

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

Класс без единого поля занимает 24 байта, с двумя полями int — те же 24, а с тремя — уже 32.

В структуре достаточно поменять местами два поля, и её размер уменьшится с 24 байт до 16, а обход массива ускорится в 1,8 раза.

Когда начинаешь путь в тестировании, теория кажется россыпью терминов. Ошибка, дефект, отказ, верификация, валидация, регрессия, дымовое тестирование, уровни, виды, принципы ISTQB. Каждый термин по отдельности легко найти. Сложнее понять, как они связаны между собой и в какой момент работы нужны. Поэтому я собираю серию содержательных шпаргалок по основам тестирования ПО.

Материал рассчитан на тех, кто только входит в профессию, готовится к собеседованию, возвращается к теории после перерыва или хочет разложить уже знакомые слова по правильным полкам. Внутри есть определения, короткие рабочие ситуации, ловушки и вопросы, которые помогают применить теорию в задаче.

Это первая часть серии. Если формат окажется полезным, продолжу её следующими блоками: тестовая документация, жизненный цикл дефекта, техники тест-дизайна и связь тестирования с процессом разработки. Буду рад содержательным замечаниям: что оказалось понятным, где не хватило примера и какие темы хочется увидеть дальше.

Привет, Хабр! Меня зовут Владимир Заикин. Под руководством Семёна Григорьева @rsdpisuy, я занимаюсь разработкой на ПЛИС в лаборатории YADRO в СПбГУ. Мой рассказ — о том, как мы реализовали общение по PCIe с ПЛИС на плате Sipeed Tang Mega 138K Pro с кристаллом GW5AST-138K от Gowin.

Устройство, реализованное на ПЛИС, должно было принимать данные по PCIe, сохранять их в DDR3 и обрабатывать пользовательской логикой. Чтобы реализовать такую функциональность, мы обратились к примеру взаимодействия с PCIe-контроллером от производителя платы, но тот оказался нерабочим. Пришлось разбираться самим. В итоге мы сделали рабочий стенд: Linux-драйвер, хост-программа на C и аппаратное описание на Verilog. Все это выложили в открытый доступ, чтобы поделиться своим опытом и помочь другим безболезненно разобраться с этой проблемой.

У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru.

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

На старте аналитического проекта список показателей обычно уже существует. Он находится в техническом задании, таблице заказчика, старых отчётах или переписке. В нём могут быть знакомые названия: количество пользователей, доля выполнения, среднее значение, динамика по подразделениям.

Кажется, что этого достаточно, чтобы подключить данные и начать собирать дашборд. Проблема обнаруживается позже, когда участники проекта по-разному понимают один и тот же показатель. Для одного активный пользователь - любой открывший приложение, для другого - успешно авторизовавшийся, для третьего - совершивший целевое действие. Формула появляется только после того, как одна из трактовок незаметно побеждает остальные.

В проектах с BI-отчётностью я работал с показателями, которые собирались из внутренних систем, общей базы, API и ручных выгрузок. При проектировании аналитики мобильного приложения похожая задача возникла ещё до накопления данных: нужно было определить активность, возвращаемость, использование экранов, ключевые действия и ошибки. В обоих случаях название показателя было лишь началом работы.

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

Я решил проверить, способен ли MAX Desktop обнаружить VPN, если VPN-клиента в Windows вообще нет. В моей сети Split Routing выполняет роутер Keenetic: часть трафика идёт напрямую, а часть — через OpenConnect-туннель на удалённый VPS.

Во время эксперимента я фиксировал действия MAX с помощью Process Monitor, TCPView и Wireshark, а трафик на стороне VPN-сервера — через tcpdump. Проверил, какие системные параметры читает MAX, куда подключается и появляются ли признаки целенаправленного поиска VPN-маршрута.

Задача просмотра сетевого трафика интересна тем, что позволяет увидеть, что фактически передаётся между двумя хостами, и разобраться, что происходит внутри сетевого соединения, которое в обычной ситуации выглядит как «чёрный ящик».