Все потоки

Как получить готовый план по оптимизации лагающего сайта с помощью аудита фронтенда

Привет! Я Рома Игнатович, лид фронтенд-разработки в Далее. Обычно задача «ускорить сайт» без конкретики превращается в перебор гипотез вслепую. PageSpeed тут не спасет, потому что он показывает только симптомы — например, низкую скорость загрузки, нестабильную вёрстку, задержку кликов, — но не причины. За одинаковыми цифрами может стоять что угодно, от тяжёлых картинок до медленного бэкенда. Поэтому вместо точечных проверок я использую аудит фронтенда — он сразу сужает область поиска и помогает быстро составить план по доработкам.

Как проходит аудит

Смотреть можно без доступа к коду, во вкладке Performance в DevTools. Берём ключевой сценарий (например, флоу покупки) и записываем performance trace: скролл, клики, переходы, ввод — ищем долгие таски, блокировки потока, просадки анимаций. Параллельно смотрим Network waterfall (какие запросы блокируют остальные), рантайм и три метрики Web Vitals: LCP, TTFB, CLS. Для мультирегиональных продуктов пригодится WebPageTest — показывает поведение сайта из разных точек и с разным качеством соединения.

Проверять стоит не только на мощной машине: CPU throttling (4–6x) имитирует медленное устройство и вскрывает лаги, а network throttling на 3G/4G показывает, насколько критичны тяжёлые изображения и порядок загрузки. Сценарии прогоняем дважды — в норме и с throttling; если с throttling сайт деградирует критично, это уже не техдолг, а прямые потери конверсии.

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

Типичные проблемы и варианты их решений

Загрузка и контент:

• весь код в одном бандле → браузер грузит и парсит всё сразу, плюс изображения по 20–30 МБ. Фикс: разбить на смысловые чанки, грузить по страницам и сценариям;

• устаревшие форматы вместо WebP/AVIF, нет адаптивных размеров (srcset), грузятся элементы за пределами вьюпорта. Фикс: современные форматы + lazy loading;

• высокий TTFB значит, что тормозит бэкенд, высокий LCP может быть где угодно. Фикс: проверяем бэкенд, настраиваем отправку первичного запроса при монтировании страницы.

Интерфейс и рендеринг:

• расчёт анимаций на CPU вместо GPU, свойства вроде width/height/top/left вместо transform — браузер пересчитывает layout. Фикс: transform/opacity, но без перебора с will-change;

• main thread перегружен синхронными операциями и тяжёлыми вычислениями. Фикс: распределять задачи параллельно, выносить тяжёлые операции из основного потока;

• layout shift — не зарезервировано место под контент, не заданы размеры изображений и блоков. Фикс: фиксировать размеры заранее, skeleton-заглушки.

От аудита к бэклогу

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

• интерфейс подвисает при открытии карточки → долгие JS-задачи → разбить выполнение;

• анимация лагает → расчёты идут на CPU → перевести на GPU через transform;

• страница долго грузится → тяжёлые изображения → оптимизировать формат и размер.

У любой оптимизации — измеримая цель: например, LCP < 2.5 с, CLS < 0.1, снижение веса страницы на 30–40% и т. п.

Из действий собираю план: задачи ранжирую по эффекту и затраченным ресурсам — в приоритете то, что влияет на ключевые сценарии, конверсию и быстро чинится.

В итоге получается приоритизированный план с обоснованными гипотезами и задачами на доработку, который потом проверяется повторно — тестированием, бизнес-командой или новым техническим анализом.

Подробнее обо всех этапах пишу в большой статье на Workspace: читать здесь.

Вышел 9-й номер журнала Paged Out (#8 выпустили в июне), который включает в себя различные материалы на тему этичного хакинга и информационной безопасности. Издание публикуется в формате: 1 страница — 1 статья. Все остальные Paged Out выпуски можно скачать с сайта проекта.

Как реализовать семантический поиск для RAG-архитектуры в PostgreSQL без усложнения инфраструктуры?

Ситуация: вы разрабатываете чат-бота для техподдержки на базе RAG-архитектуры. Используете PostgreSQL как хранилище знаний и делаете поиск по текстовым полям, но качество ответов нестабильное: система плохо справляется с синонимами, профессиональным сленгом и переформулировками запросов. Обязательно ли внедрять отдельную векторную базу данных, или можно реализовать семантический поиск прямо в PostgreSQL? Возможна ли простая проверка продуктовой гипотезы без усложнения архитектуры?

Да, семантический поиск в RAG-сценариях можно реализовать прямо в PostgreSQL без выделенной векторной базы данных (ClickHouse, Opensearch, Qdrant, Milvus и т. д). 

Для этого используется PostgreSQL + расширение pgvector, которое добавляет поддержку хранения эмбеддингов (векторов) и поиск по расстоянию до ближайших соседей (KNN) прямо внутри SQL-движка. Разберем, как это работает на практике.

В RAG-пайплайне текст документов и запрос пользователя преобразуются в векторные представления. PostgreSQL хранит эти векторы в таблице и позволяет выполнять поиск по смысловой близости, а не по точному совпадению слов.

Для этой задачи будем использовать pgvector — это расширение к PostgreSQL, которое добавляет тип данных vector и операторы поиска по расстоянию до ближайших соседей (KNN).

Поддерживаются три основные метрики сравнения векторов:

• L2 (евклидово расстояние) — классическое расстояние между двумя точками в многомерном пространстве. Хорошо работает, если векторы не нормализованы и распределение значений относительно равномерное.

• Cosine similarity (косинусное сходство). В отличие от предыдущей метрики измеряет не абсолютное расстояние, а угол между двумя векторами. Подходит для текстовых эмбеддингов, где важна направленность, а не масштаб. Требует нормализации векторов.

• Inner product (внутреннее произведение) — скалярное произведение двух векторов. Может использоваться как прокси для оценки «сходства» при обучении моделей и в задачах ранжирования.

Допустим, мы получаем на наш запрос именно такой вектор от модели OpenAI. Для хранения создаем таблицу с типом VECTOR:

CREATE TABLE items (
 id SERIAL PRIMARY KEY,
 title TEXT,
 embedding VECTOR(1536)
);

Добавим данные для нескольких векторов разных объектов:

INSERT INTO items (title, embedding) VALUES
 ('PostgreSQL embeddings', '[0.10, -0.80, 0.45]'),
 ('Neural image processing', '[0.42, 0.18, -0.35]'),
 ('Sound pattern matching', '[-0.20, 0.70, 0.60]'),
 ('Document clustering', '[0.09, -0.79, 0.48]');

Теперь сравним их попарно и отсортируем по расстоянию:

SELECT
  a.title AS title_a,
  b.title AS title_b,
  a.embedding <-> b.embedding AS distance
FROM items a
JOIN items b ON a.id < b.id
ORDER BY distance;

Оператор <-> здесь вычисляет расстояние между двумя векторами. Таким образом, мы можем оценивать степень семантической близости любых объектов, представленных векторами. Какая именно метрика используется, зависит от операторного класса, заданного при создании индекса.

В подобных RAG-сценариях нет необходимости сразу вводить отдельный класс инфраструктуры типа векторная БД. Семантический поиск можно реализовать эволюционно поверх существующего PostgreSQL.

А если вы не хотите самостоятельно заниматься настройкой индексов, тюнингом памяти и производительности, а также обновлением версии PostgreSQL, то воспользуйтесь DBaaS от Selectel. Мы предоставим вам кластер PostgreSQL с преднастроенными расширениями, готовый к эксплуатации под нагрузкой. Это позволит сосредоточиться на RAG-логике и качестве поиска, а не на инфраструктурной оптимизации.

Почему я перестал удалять пользователей сразу

Раньше логика удаления у меня была максимально простой:

DELETE FROM users
WHERE subscription_end < NOW();

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

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

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

Поделитесь, кто как делает? используете отложенное удаление, soft delete или сразу выполняете операцию, если условие выполнено?

Случайность в биологии

Представляю статью в виде препринта. Вначале небольшое описание, затем ссылки.

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

В отличие от физики в биологии появляется новое и трудно определимое понятие случайности, не связанное с теорией вероятности. В этой статье представлены три сюжета, связанные с этим обстоятельством. Я начну со взглядов Чарлза Дарвина и Томаса Гексли, которые считали возможным совместить детерминизм с естественным отбором в биологической эволюции. В 19-м веке теория вероятности начала проникновение в физику в молекулярно-кинетической теории. Тем не менее, в целом физики были убеждены в детерминизме законов физики и у биологов не было особого выбора.

Следующие два сюжета раскрывают взгляды на случай как удачу Жака Моно и Стивена Гулда. Вначале рассмотрена борьба Жака Моно с термодинамиками-анимистами Ильей Пригожиным и Манфредом Эйгеном, которые рассматривали случайность как закономер­ность. Затем рассмотрен мысленный эксперимент Стивена Гулда, который должен был показать роль случая как удачи в макроэволюции, и противоположный взгляд сторонника конвергентной эволюции Саймона Морриса. В последнем разделе обсуждается возможное компромиссное решение.

ResearchGate или PREPRINTS.RU

Команда Cursor представила исходный код проекта minisqlite. Это реализация СУБД SQLite на языке Rust и успешно проходящая официальный набор тестов sqllogictest от проекта SQLite.

Проект minisqlite подготовлен в ходе эксперимента по проверке эффективности работы ИИ‑моделей GPT-5.5, Grok 4.5, Opus 4.8 и Fable 5, по воссозданию SQLite только на основе официального 835-страничного руководства, без доступа к оригинальному коду, интернету, наборам тестов и исполняемому файлу SQLite. Основная идея эксперимента — использование подробной спецификации в качестве промпта для создания сложного продукта.

Представленная реализация minisqlite основывается на результатах, полученных при использовании ИИ‑модели Opus 4.8.

Проект minisqlite включает около 200 тыс, строк кода на Rust, не содержащего unsafe‑блоков в коде библиотеки. Библиотека может открывать файлы, созданные в оригинальном sqlite3, и записывать файлы, которые можно прочитать в sqlite3. Реализация охватывает диалект SQL от SQLite, поддержку транзакций, 90 встроенных функций, планировщик запросов, движок выполнения запросов и движок хранения, совместимый с дисковым форматом SQLite 3. Из внешних зависимостей в minisqlite задействован только пакет elsa, с использованием которого реализован страничный кэш.

Представлен открытый конвертер book‑to‑skill для ИИ‑агентов. Проект анализирует книги и документы в PDF, EPUB, DOCX, Markdown, считывает текст, собирает конспекты глав, словарь, паттерны и шпаргалку, а затем превращает это в skill. Инстурмент экономит токены — получается в 24–51 раз меньше затрат, чем если просто закинуть нейросети целую книгу.

Эксперт «Диасофт» примет участие в круглом столе IT-World «Почему хорошие системы плохо работают вместе?»

6 августа 2026 года в 16:00 IT-World проведет круглый стол «Почему хорошие системы плохо работают вместе?». В нем примет участие Дмитрий Гаврин, заместитель директора департамента «Цифровые решения» и один из авторов блога компании «Диасофт» (Как 30 лет боли в интеграции привели нас к собственной платформе)

О чем будут говорить спикеры:           

• Почему интеграции остаются одной из самых болезненных зон корпоративного ИТ-ландшафта?

• Что чаще ломает взаимодействие систем - слабые API, разные модели данных, отсутствие владельца процесса или спешка внедрения?

• Как оценивать API-зрелость решения до покупки: документация, версионирование, песочница, ограничения, поддержка изменений?

• Как меняется ответственность поставщика ИТ-решения, если его продукт становится частью большого корпоративного контура?

• Что должно происходить с интеграциями при обновлении продукта, смене версии или доработке соседней системы?

• Почему единые справочники и мастер-данные остаются проблемой даже там, где уже есть MDM, НСИ или корпоративная шина?

• Где проходит граница между быстрой автоматизацией и архитектурным долгом, который потом мешает масштабировать решение?

• Какие требования к интеграциям, API, данным и поддержке стоит включать в ТЗ, договор и критерии выбора поставщика?

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

Регистрация по ссылке: https://www.it-world.ru/events/or8fe6s830gwswk4o4ks4c0wcw0goos.html

Две недели назад я получил $5 000 кредитов Azure по программе Microsoft for Startups и за четырнадцать дней я сжёг из них $2 100 на одной настройке, которую “забыл” вернуть обратно. В разработке PhotoMentor у меня работают три модели с закреплёнными ролями: GPT как CPO и исполнитель, Kimi K2.7-Code как red team – обе на Azure – и Claude как ревьюер, на моей собственной подписке. Когда я проектировал биллинг для Android, я осознанно выкрутил ризонинг на максимум по всей цепочке. Уверен, что это было правильное решение и с т.з. архитектурной прочности, и собственной психологической уверенности. Биллинг – это деньги, конфликты владения, повторная выдача прав. Тут нужна была щепотка паранойи. Но вот потом я его не вернул. Строго говоря, я не забыл, а попал в ловушку той самой психологической уверенности. Плюс спросил, и модель заверила меня, что такая глубина оправдана. Ну, возможно она в 9 из 10 так и скажет. У модели, оптимизирующей качество вывода, нет строки расходов под мой burn rate и нет представления о том, что подписка ревьюера упирается в лимит через час, и вместо релиза я сижу и жду сброса квоты. Поэтому давай, берсерк, закидывайся стимуляторами и жги. Что максимальный ризонинг купил мне на обычной, обратимой работе: — процедуру maintenance drain на staging-окружении, которым пользуется ровно один человек – я; — retry-механику такой основательности, что в одном тесте кнопку «Повторить» пришлось нажать семь раз, потому что безобидное событие blocked в IndexedDB трактовалось как фатальная ошибка; — итерации усиления runbook, каждая честно лучше предыдущей и ни одна из них не несущая. Правило, которое стоило написать в первый день: Максимальный ризонинг – для необратимого. Production-миграции, удаление данных, подписание релиза, финальный аудит. Всё обратимое – средний уровень и короткий цикл: реализация → тест → проверка. Неограниченные токены не делают мышление бесплатным. Они просто переносят его стоимость туда, куда ты не смотришь: в календарь, в лимиты и в терпение. Девять часов назад я отправил наконец Android-релиз PhotoMentor на проверку в Google Play. Жду.

С 29 июля по 5 августа на Бирже Инфостарта появились новые задачи по доработке и интеграции 1С. В подборке — обмены между конфигурациями, настройка УНФ и БП, интеграции с внешними системами и консультации.

Новые заказы

• Необходимо интегрировать для 1С Управление торговлей версия 10.3 обмен остатками 

• Закрытие прошлых периодов в УНФ 3.0 

• Платная консультация «Бюджетирование (планирование доходов и расходов, БДДС), заявки на оплату для БП 3.0» 

• 1с форес разыскиваю модуль 

• (Комиссия) Обработка, чтобы выгрузить из УТ ПоступлениеТоваровОтХранителя и загрузить в БП как ВозвратТоваровОтПокупателя 

• Доработка «Себестоимость онлайн. УТ 11.5» 

• Исправить ошибки обмена 1с Бухгалтерия и 1с УТ 11

• Комплексная настройка 1С:УНФ во Фреше: очистка CRM, интеграция 4-х ТК, Честный Знак и синхронизация с БП 

• Интеграция 1С с АС ЭТРАН 

• Платная консультация «Интеграция 1С с АС ЭТРАН в режиме АСУ-АСУ: что нужно знать до старта проекта» 

• Интеграция и настройка ЭТрН (Электронных транспортных накладных) в 1С под ключ. 

• Адаптировать расширения в 1С:УНФ 8. Управление предприятием общепита, редакция 3.0 (3.0.13.278) 

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

Перейти на Биржу заказов

Как проверить VDS до покупки: ядра, память, диск?
Слово VDS не закреплено ни за одной технологией. У одного это машина KVM, у другого контейнер, у третьего просто тариф подороже с пометкой dedicated. За одинаковой строкой характеристик стоят разные модели распределения ресурсов, и утренний тест дает результат, который вечером не повторится.

Что стоит выяснить до тестов? KVM запускает гостя с собственным ядром на аппаратной виртуализации, OpenVZ и LXC делят ядро хоста. Распространенное заблуждение: KVM якобы исключает оверкоммит. Не исключает, провайдер назначает машинам больше vCPU и памяти, чем есть на хосте. Отсюда вопросы к тарифу. Закреплены ли vCPU за физическими процессорами. Зарезервирована ли память. Есть ли лимит IOPS и что при его превышении. Слова dedicated, isolated и NVMe без этих ответов не значат ничего.

Ядра. Под dedicated понимают физическое ядро, закрепленное за машиной. Pinning эксклюзивности не дает: на тот же процессор оператор может посадить чужие vCPU. Проверяется это наблюдением.

mpstat -P ALL 1 60

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

cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/cpu.stat

200000 100000
nr_throttled 1843
throttled_usec 21904331

Ненулевой nr_throttled означает, что режет лимит, а не сосед. В виртуальной машине таких значений не будет. Дальше sysbench в один поток и на всех ядрах, одна версия утилиты и один cpu-max-prime на кандидатах.

sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 --time=60 run

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

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

free -m && swapon --show
stress-ng --vm 1 --vm-bytes 70% --vm-keep --timeout 10m --metrics-brief

Тест гоняйте на пустой машине и параллельно смотрите vmstat. Использование swap само по себе ни о чем не говорит, оно зависит от настроек гостя. Тревожат устойчивые si и so при умеренной нагрузке и падение MemAvailable. Если процесс исчез раньше срока, ответ в журнале ядра.

journalctl -k --since "-15 min" | grep -Ei "oom-kill|killed process"

Диск. Лимит в 20000 IOPS без размера блока, соотношения чтения и записи и глубины очереди это просто число. Те же 20000 при iodepth 32 ничего не обещают при iodepth 1, а именно так работает приложение, ждущее ответа на запрос. Файл сначала заполняют целиком, иначе чтение из пустых областей завысит результат.

fio --name=randrw --filename=/var/tmp/fio.test --size=4G \
    --rw=randrw --rwmixread=70 --bs=4k --direct=1 --ioengine=libaio \
    --iodepth=1 --time_based --runtime=120 --refill_buffers=1 \
    --group_reporting --percentile_list=50:95:99:99.9

Затем тот же вызов с iodepth 32 и проверка в разделе IO depths, достигнута ли глубина. Сохраняйте IOPS и процентили clat, а не среднее. Один прогон шумного соседа не покажет, нужны три в разные часы. Растущий p99 при стабильной медиане это и есть нестабильность.

Как сравнивать? Не складывайте IOPS, миллисекунды и баллы в один рейтинг. Сначала отсеките тарифы, не проходящие пороги приложения, потом расставьте веса: базе важнее p99 диска, агенту сборки процессор, медиасервису исходящая полоса. Для каждого прогона сохраняйте дату, локацию, образ, версии утилит и команду.

Универсального первого места нет. Есть тариф, проходящий ваши пороги трижды подряд в разное время суток.

Почему «прошли обучение по ИИ» и «трансформировались» — это разные вещи

За последний год почти каждая компания среднего и крупного размера так или иначе прошла через «программу по ИИ»: закупили лицензии на Copilot/GigaChat/что-то ещё, провели серию тренингов, отчитались перед руководством цифрой охвата — «80% сотрудников обучены».

И почти в каждой такой компании через полгода-год возникает один и тот же вопрос от руководства: «А почему мы не видим эффекта на процессы?»

Вы задумывались о том, какие причины могут способствовать тому, чтобы так происходило? Коротко о причинах:

Проблема прокси-метрик:

1. Когда руководство оценивает прогресс ИИ-трансформации, оно почти всегда смотрит на прокси-показатели:

- куплены ли лицензии на инструменты;

- проведён ли тренинг;

- какой процент сотрудников этот тренинг прошёл.

Все три метрики измеримы, легко ложатся в отчёт для совета директоров — и при этом ничего не говорят о том, изменилось ли фактическое поведение людей в работе.

2.      HR и T&D-функции попадают в ту же ловушку с другой стороны: они отчитываются охватом обучения и NPS тренинга. Обе метрики хорошо описывают процесс обучения, но не описывают его результат.

Аналогия, которая обычно заходит: это как измерять уровень фитнеса по количеству купленных абонементов в спортзал.

Чтобы измерять не процесс, а результат, нужна шкала, построенная на поведенческих индикаторах, а не на самооценке сотрудника («оцените по шкале от 1 до 5, насколько уверенно вы используете ИИ» — это почти всегда бесполезный вопрос, люди систематически завышают самооценку в подобных опросах).

Это не оценочная шкала «плохой/хороший сотрудник», а диагностический инструмент: точка, откуда стоит начинать конкретную работу с конкретным человеком или отделом.

Так почему один тренинг не двигает всех одинаково? Как определить уровень ИИ-зрелости компании? По какой метрике и как оценивать?

На эти и другие вопросы команда «Авандок» ГК «КОРУС Консалтинг» ответит на открытом вебинаре «Пять уровней ИИ-зрелости сотрудников: диагностика, типовые барьеры, роли в ИИ-трансформации» 11 августа в 14:00 (Мск)

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

Для MacBook вышло открытое приложение Himekuri, которое позволяет переворачивать календарь на рабочем столе. Бумага на календаре мнётся, рвётся и улетает вниз экрана. Причём вернуть ее обратно уже нельзя. Закрепить проект можно на рабочем столе, поверх всех окон или использовать как обычное приложение.

Полтора года пентестов Active Directory сводились к одному и тому же неудобству: для аудита нужен PingCastle (только Windows, только скоринг, ничего не проверяет на практике), для графа путей атаки — BloodHound плюс отдельный коллектор (SharpHound или RustHound-CE), а для реальной эксплуатации — Impacket на Python со всем шлейфом зависимостей. Три инструмента, три экосистемы, и ни один не даёт честного ответа на вопрос "эта уязвимость реально эксплуатируется в этом домене прямо сейчас, или только теоретически светится в отчёте".

Я решил закрыть это одним инструментом — adhammer.

Что внутри

adhammer — это Rust-тулкит для AD security assessment, который совмещает три слоя:

1. Аудит в стиле PingCastle — сканирует домен, скорит находки по severity, размечает MITRE ATT&CK тегами.

2. Граф путей атаки в стиле BloodHound — строит и визуализирует attack paths до Domain Admin.

3. Валидация с реальным PoC — вот это ключевое отличие. Guided-режим проходит по каждой находке и предлагает: "провалидировать и получить PoC?". Если да — запускает реальную атаку и помечает finding как "validated" только если получен настоящий артефакт — хеш $krb5tgs$/$krb5asrep$, реплицированный секрет krbtgt, реально выпущенный сертификат. Если атака не удалась — честно "attempted", а не тихо пропускается.

Почему Rust, а не поверх Impacket

Изначально пробовал строить поверх существующих Python-библиотек — уперся в то, что тащить весь стек зависимостей ради одного бинарника, который должен без проблем компилироваться и запускаться и с Kali, и с Windows-хоста внутри AD-сети, неудобно и хрупко.

Поэтому пришлось написать протокольный стек с нуля: DCE/RPC, NTLM, SMB2, Kerberos — практически "impacket для Rust", которого в экосистеме ещё не было. Результат — один статический бинарник без рантайм-зависимостей, кросс-компилируется под Linux и Windows.

Что дальше

Инструмент build как security research, соседствует с раскрытым в MSRC 0-day в ядре Windows. Сейчас думаю над тем, чтобы вынести протокольный стек в отдельные переиспользуемые crates — уже начал переписку с мейнтейнерами sspi-rs и RustHound-CE на предмет пересечения усилий.

Код и write-up: github.com/icedracon/adhammer

Использование — только на системах, где есть явная авторизация. SECURITY.md в репозитории описывает это подробно.

Буду рад issues, PR и просто фидбеку от тех, кто занимается AD security на практике.

"Лиды плохие": почему этот спор невозможно выиграть

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

Причём, мало продаж - собственник идёт в отдел маркетинга с вопросами, мы показываем проблему в отделе продаж и тишина. Как с этим бороться, вообще не понимаю. Такое ощущение, что в СНГ вообще не умеют выстраивать отделы продаж.

И это я говорю о начальном этапе обработки квалификаторами, дальше ещё больнее. Квалификаторы отквалили, отдел маркетинга видит процент квала 30-35% и понимает, что трафик ок, а далее продаж нет либо мало, спрашивают с меня, отдел продаж орёт, что лиды плохие, но квалификаторы квалят и я-то вижу другую картину. Остаётся вопрос к РОПу: а как так составляли регламент для квалификаторов, что процент квала норм, а по факту все лиды г**но. И снова тишина.

Представлен открытый проект skales — ИИ‑агент, который запустится даже на слабом ПК:

• работает как обычное приложение в Windows, macOS и Linux;

• агент получает доступ к файлам, браузеру, почте и календарю;

• умеет выполнять сложные задачи в фоновом режиме;

• можно запланировать любую таску по таймеру;

• своя встроенная память для важного контекста;

• при этом команды отправлять можно даже со смартфона — агент выполнит их на ПК;

• можно тестировать на бесплатном пробном режиме, подключить API или локальную модель.

unreal‑assets‑to‑glb

Это небольшой pip пакет, позволяющий вам конвертировать ресурсы unreal engine времени редактирования (не сборки игры) в модели формата glb.

особенности:

• интерфейс cli с поддержкой команды help

• поддерживает предварительный просмотр уровней (umap)

• фильтрация ассетов для экспорта только определенных моделей

• кэширование текстур для ускорения экспорта в будущем (если несколько раз выполняете экспорт)

• извлечение текстур базового цвета / альбедо, а также других текстур путем сохранения в формате png

• базовая поддержка сеток без анимации или костей без автоматического масштабирования с коэффициентом 100 к 1

В видео я показываю, как модель отображается в другом игровом движке после импорта конвертированных uasset-файлов

главное преимущество: вообще не требуется устанавливать UE

исходный код: https://github.com/Prikalel/unreal-assets-to-glb. пакет pip: https://pypi.org/project/unreal-assets-to-glb/

сгенерированные файлы могут быть легко импортированы в другие движки, такие как godot / unity и т.д.

в настоящее время поддерживаются 2 версии UE engine: 5.5 и 4.27.2

вы также можете заметить, что некоторые материалы в тестовой сцене частично затемнены - это связано с тем, что пакет не позволяет вам правильно экспортировать все настройки материалов / все настройки шейдеров (ограничения перечислены на странице github, это освещение, положение камеры и другие параметры, но базовое извлечение 3d-сетки работает идеально).

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

Лицензия GPL-3.0

Ежедневные заметки

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

В Obsidian для ведения ежедневных заметок пригодятся следующие плагины:

• Daily notes — позволяет одной кнопкой или сочетанием клавиш создать ежедневную заметку на сегодня.

• Periodic Notes — расширенная версия предыдущего плагина, умеющая помимо ежедневных создавать недельные, месячные, квартальные и годовые заметки.

• Calendar — простой календарик для быстрой навигации по ежедевным заметкам.

Ведёте ли вы ежедневник? Бумажный или электронный? Если второй, в какой программе? Чтоб обычно фиксируете в течение дня?

Ваши скиллы возможно написаны под модель, которой уже нет

Anthropic удалила больше 80% системного промпта из Claude Code, и качество на их тестах не упало. Пересказывать статью не буду, интереснее, что из этого следует, если вы сами пишете агентов и скиллы.

1. Половина ваших правил — заплатки на провалы прошлых версий. «Не начинай с общих фраз», «не используй конструкцию X» — вы это добавляли, потому что модель так делала. Перестала делать, и правило работает вхолостую, а иногда против вас: запрет отнимает у сильной модели право решать по ситуации. Что сделать: пройти по скиллам и рядом с каждым правилом поставить дату и ошибку, из-за которой оно появилось. Где ошибку не вспомнить или ей больше полугода — кандидат на удаление.

2. Резать вслепую нельзя, а мерить нечем. У Anthropic были свои прогоны: удалили кусок промпта, прогнали набор задач, сравнили результат. Поэтому они и могли уверенно сказать «сняли 80%, качество то же». У нас так не выходит. Меняем скилл, смотрим на два поста и решаем, что стало лучше. А на третьем оказывается, что модель перестала расставлять ссылки, просто в первых двух ссылок и не было.

3. Конфликтуют не правила, а источники правил. Редстандарт, скилл канала, CLAUDE.md, бриф — четыре места, где написано про тон. Модель разгребает противоречие вместо работы. Решение не в сокращении, а в иерархии: тон и позиция живут только в скилле канала, фактура и грабли — только в CLAUDE.md, задача выпуска — только в брифе. Правило встретилось дважды — одно вхождение удаляется, а не уточняется.

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

5. Архитектура скиллов важнее их содержания. Один SKILL.md на девятьсот строк грузится целиком: пишете пост в телеграм — модель попутно читает правила для лендингов. Лишнее разбавляет нужное, а трогать такой файл страшно, поэтому его проще дополнить, чем разобрать. Разложите по уровням: верхний решает, что за задача и куда идти дальше; профиль канала держит тон и рубрикатор только для себя; редкие рубрики подгружаются по надобности. Тогда правки перестают быть страшными: меняете один канал и точно знаете, что остальные не задели.

Что переносится на другие модели

Не переносится цифра. 80% — результат конкретной связки: их обвязка, их модели, их тесты на коде. Для GPT, Gemini или локальных моделей такого замера у вас нет.

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

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

И главное

Спор о длине промптов маскирует настоящую проблему: у нас нет способа отличить улучшение от ухудшения. Пока его нет, любое решение — резать или не резать — принимается на ощущениях. Вопрос не в том, сколько правил у вас в скиллах, а в том, знаете ли вы, какие из них хоть на что-то влияют. А это уже content ops. 😎

Раньше в канале.

От пилота к прибыли: как ИИ перестает быть экспериментом

ИИ в бизнесе часто выглядит эффектно на старте, но далеко не каждый пилот доходит до продакшена. В интервью «Эксперту» Роман Стятюгин, директор по ИИ-продуктам VK Tech, объяснил, на каких этапах компании теряют результат и что важно заложить еще до запуска.

1️⃣Сначала — цель, потом — пилот
Если не задать сроки, бюджет и метрики, пилот легко превращается в бесконечные доработки. Проект нужно сразу переводить из R&D в инженерную задачу с понятным бизнес-результатом.

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

3️⃣ Модель — это не вся система
Языковая модель сама по себе не автоматизирует предприятие. Решает вся обвязка: интеграции, инструменты, безопасность, наблюдаемость и доступы.

4️⃣ Безопасность — не финальный этап, а основа проекта
Чем выше автономность агента, тем важнее контроль его действий. Агенту нужно предоставлять доступ только к тем системам, интеграциям и функциям, которые необходимы для конкретной задачи.

5️⃣ Экономика проекта
Агент может работать эффективнее сотрудника, но обходиться дороже. Поэтому перед внедрением нужно сопоставить стоимость решения с тем, как оно влияет на скорость, качество и объем работы.

🔜 Полный текст интервью Романа читайте здесь.

📬 Мы в МАХ