Все потоки

Код в моих проектах пишут агенты, Codex и Grok, и они же пишут к нему тесты. За последние месяцы набралась коллекция зелёных тестов, которые ничего не проверяли: тест на подделку подписи, проходящий без сравнения HMAC, лимиты, которые вызывали только их собственные тесты, отчёты «all pass» с заглушённым кодом возврата. Разбираю, где это ловится и как у меня устроена приёмка.

Как‑то я захотел кошелёк Monero с нормальным веб‑интерфейсом, но без компромиссов по ключам: чтобы он работал на моей машине, ходил в мой узел и не притворялся кастодиальным сервисом. Писать криптографию самому — плохая идея, поэтому вся работа с ключами осталась за официальным monero-wallet-rpc, а на мне была «всего лишь» оболочка: бэкенд, интерфейс и куча инфраструктурной логики, которая внезапно оказалась самой интересной частью задачи.

Пароль от хостинга — в личных сообщениях. SSH‑ключ — в архиве на рабочем столе, который никто не чистил года три. Токен от CRM — в закреплённом сообщении в Telegram, которое уже никто не читает. Знакомо? У нас было ровно так, пока я не сел и не разобрался, что с этим делать.

Это не очередной «как поднять Vaultwarden за 10 минут» — таких гайдов хватает в вики проекта. Это история про то, что происходит после команды docker compose up: VPN‑периметр вместо открытого порта, самоподписанный CA, который красиво работает на десктопах и разваливается на Android, DNS-01 challenge с собственным хуком для acme.sh под провайдера, которого нет в официальном списке, бэкап в два независимых конца и восстановление, протестированное заранее, а не в момент паники.

Если вы технарь — здесь рабочие конфиги, а не псевдокод: Caddy, docker‑compose, скрипт под acme.sh ретеншен бэкапов без магии. Если интегратор на Bitrix — готовая структура коллекций и прав под клиентские проекты, роли Dev/Marketing/Infra, чек‑лист на нового клиента. Если тимлид — регламент, который реально прижился в команде, а не умер через неделю, как очередная табличка в Notion.

Отдельный мотивбыл личный: давно хотелось не просто читать про self‑hosted‑подход бигтеха к секретам, а руками собрать что‑то похожее у себя — без DevOps‑отдела и без бюджета на энтерпрайз‑решения — и посмотреть, где ручной, но осознанный self‑hosted реально ломается, а где отрабатывает не хуже платного SaaS.

Перевод

Предисловие переводчика

По жизни и по работе (сначала в Wyse, потом в Dell, а теперь в Getmobit) я занимаюсь уже давным-давно тонкими клиентами, VDI, терминальными серверами и всем, что с этими «темами» связано. В этой ситуации свойства разных протоколов удаленного доступа откладываются в голове крепче «Устава внутренней службы». Однако, жизнь меняется и «Уставы» постоянно нужно обновлять, особенно в ситуации, когда нам всем приходится сталкивать с «заново изобретенными» ОС, приложениями, VDI, ВКС и так далее. Просматривая инет в поисках новостей по протоколам, я наткнулся на цикл статей Артура Оглоза, сравнивающих текущие версии протоколов с неожиданной (для меня во всяком случае) стороны – с архитектурной.

Думаю, многие читали «сборники» типа “VDI smack down”, где фактически сравнивались матрицы фич протоколов (типа есть\нет H.264\multimedia redirection\Zoom optimization…). Это несомненно было полезно при выборе того или иного решения, но не давало представления о реальной жизни, скажем, присутствующей в матрицах фич разных протоколов функции оптимизации одной и той же ВКС.

С другой стороны, холиварные статьи типа «Blast vs PCoIP» раскрывали внутреннюю кухню протоколов, но в основном были ориентированы на негативные стороны конкурента, что в общем-то путало и пугало всех подряд и не позволяло видеть объективную картину.

Чем меня привлекли именно эти статьи, так это ясной прослеживаемостью принятых архитектурных решений на качество user experience и потолок возможностей, обусловленный архитектурой. И для каждого, кто тесно связан с темой VDI, эти статьи прозрачно намекают на абсолютную необходимость внедрения технологий сегодняшнего дня, а не только воспроизведением идей последних 15-20 лет, ну, и раскрытием «коварных намерений гиперскейлеров» в разработке ПО😊

Привет, Хабр! Я Алена Караваева, в Positive Technologies возглавляю направление защиты конечных устройств от целевых атак. Мое главное детище это — MaxPatrol EDR, который входит в MaxPatrol Endpoint Security, комплексное решение для защиты конечных точек, рабочих станций и серверов.

Моя работа во многом похожа на работу других «продактов»: стратегия, роадмап, бэклог, запросы клиентов, споры с разработкой, технический долг, приоритизация и вечный вопрос «а что мы точно успеем занести в следующий релиз?». Но есть одна существенная разница. Создавая средство защиты, лично я не мыслю категориями «фичи» и «релиз», а четко понимаю, что любое мое решение в роадмапе (стратегическое, функциональное или архитектурное) влияет на жизнеспособность компаний — либо внесет вклад в усиление их брони, либо станет причиной бреши, через которую их могут взломать хакеры. За неправильной настройкой может стоять остановленный бизнес-процесс. За пропущенной угрозой — скомпрометированная инфраструктура. За неудачным обновлением — рабочие станции, на которых внезапно перестало работать то, без чего компания не может нормально функционировать.

Поэтому я давно перестала смотреть на роадмап только как на список фич. Для меня это, скорее, карта того, как мы усиливаем киберустойчивость клиента и какой риск берем на себя, когда принимаем каждое продуктовое решение. Поэтому мой главный вызов в работе — внутренний: гарантировать с помощью MaxPatrol Endpoint Security такой уровень киберустойчивости любой компании, чтобы, как говорится, ночью спать спокойно.

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

Как упростить управление целым парком из 800+ экземпляров СУБД на базе PostgreSQL? Можно доработать postgres_exporter, чтобы настроить получение метрик под себя. А если ещё проще? Мониторить связкой Grafana, Prometheus и кастомизированным postgres_exporter, а данные получать через ИИ‑отчёт, который будет агрегировать данные Prometheus через прямые PromQL‑запросы.

Но если и этого мало, то можно вообще поручить ИИ‑агенту типовые тикеты вроде очистки места на диске и плановой остановки БД.

Меня зовут Станислав Епишин, я из команды «R4C.Support.Всадники апокалипсиса» в СберТехе. Я уже писал, как мы дорабатывали postgres_exporter → pangolin_exporter, исправляя баг в расчёте длительности транзакций, и как внедряли связку Prometheus + Pipeliner + TaskTracker + GigaChat для автоматического создания тикетов.

В этой статье расскажу про R&D‑исследование для небольшой команды DBA, в котором мы тестировали гипотезу: получится ли собрать автономного агента, который сам будет обрабатывать тикеты: очищать дисковое пространство, выполнять VACUUM/ANALYZE и планировать остановки БД?

Здесь я описал инструкцию по созданию агента (с полным кодом и пояснениями) и развёрнутый реальный пример про автономный VACUUM/ANALYZE с обнаружением аномалий через LLM. Также покажу, как организовать ленту событий для мониторинга работы агента, и детально разберу, где и как в проекте используется LLM.

Еженедельная планёрка, восемь человек, обычная переговорная. Через 15 минут датчик показывает 800 ppm CO₂. Через 30 минут — 1000 ppm. К концу часа люди выходят из комнаты и до обеда ползают по офису как вялые мухи. Все считают, что это «просто тяжёлое совещание».

Это не тяжёлое совещание. Это вентиляция, которая спроектирована по всем нормам и правилам — и работает в одном и том же режиме независимо от того, что происходит в помещении. Два человека, двенадцать, никого — ей всё равно. Как кондиционер в маршрутке: один режим на всех, и тот выбрал водитель. Регулировка в такой системе не предусмотрена в принципе. И никакое приложение, никакой дашборд и никакая «система умного офиса» этого не починят.

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

Друзья, команда техподдержки РТК-Сервис стартовала серию разборов рамановских и гибридных усилителей разных поколений и производителей. Рассмотрим основные технические и прочие характеристики от популярных отечественных и западных вендоров.

Если хотите освежить память, что за зверь такой Раман, вам сюда.

А мы начнем с российского DWDM-оборудования Т8.

Почему мы решили рассказать про цифровой рубль

С 1 сентября 2026 года крупные розничные сети с выручкой более 120 млн рублей обязаны предоставлять покупателям возможность расплатиться новым способом – цифровым рублем.

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

Поэтому мы решили рассказать о нашем опыте работы с цифровым рублем. Ведь на данный момент этот опыт есть только у нас и наших коллег из крупного ретейла. 

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

10 июня 2026 года CISA выпустила директиву BOD 26-04 Prioritizing Security Updates Based on Risk. Новый документ отменяет BOD 19-02 и BOD 22-01 — директиву, которая с 2021 года задавала для федеральных агентств США единые календарные сроки устранения уязвимостей из каталога Known Exploited Vulnerabilities, KEV. Вместо плоского дедлайна новая модель предлагает определять срок по риску конкретного актива.

Для приоритизации CISA учитывает четыре обстоятельства: доступен ли актив публично, есть ли уязвимость в KEV, можно ли автоматизировать её эксплуатацию и к какому техническому эффекту приводит атака. Таблица сроков, как указывает сама CISA, построена с опорой на SSVC. В наиболее срочном случае уязвимость нужно устранить в течение трёх дней и провести первичный forensic triage; в наименее срочном исправление допускается при очередном плановом обновлении системы.

Наиболее неудобный объект для такого подхода — AI-платформа. В её разных слоях слово «устранить» означает принципиально разные действия. В веб-API это может быть обычный патч; в цепочке ML-зависимостей — мажорное обновление фреймворка; в GPU-рантайме — обновление драйвера или прошивки с окном простоя; в инференс-движке — ожидание решения от мейнтейнера либо замена компонента. Для весов модели патча в привычном смысле может не быть вовсе.

Поэтому одинаковый CVSS не означает одинаковый приоритет, срок и способ обработки. В этой статье восемь публичных CVE из типового AI-стека проходят через дерево решений: для каждой записи разберём доступность актива, признаки эксплуатации, автоматизируемость атаки, технический эффект и реальный путь к устранению. Также покажем, как получить пороги для принятия решений из опубликованных данных FIRST.

Материал рассчитан на AppSec- и DevSecOps-инженеров, которые ведут бэклог уязвимостей платформы, и на тимлидов, у которых релиз зависит от открытых security-тикетов. Руководителям ИБ будет полезен отдельный раздел о требованиях ФСТЭК. Подход применим и к обычной инфраструктуре без GPU и моделей: в таком случае меняется набор активов, но не логика приоритизации.

Иногда LLMки путаются в языке, на котором они отвечают. Ты задаёшь вопрос на английском, а тебе в ответ прилетает простыня на китайском.
Почему бы не помочь им забыть про языки, в которых мы не заинтересованы?

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

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

Теперь представим: архитектор описывает эти регистры в каком-нибудь markdown, инженер, глядя на них, пишет Verilog имплементацию, а разработчик драйвера вручную создает заголовочные файлы на C. Если повезет, все эти компоненты будут соответствовать друг другу. Но только один раз. Решить проблему соответствия способен язык SystemRDL.

Сто ловушек в одном рассказе, LLM-судья с ключом ответов и баллы, которые считает код. Так устроен бенчмарк художественного перевода, который теперь встроен в опенсурсный конвейер BookTrans. В статье — зачем он понадобился, и как на нём выступили флагманы Anthropic, OpenAI и Google против китайских моделей. И ответ на главный вопрос: можно ли сэкономить, используя китайские модели, не потеряв в качестве.

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

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

Показываем на трёх реальных примерах, как это сделать и на что обратить внимание, чтобы цифры на выходе не разъехались с тем, что было на фото.

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

Как я отдал агенту четыре репозитория и увидел то, что в коде не видно в принципе.

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

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

Двенадцать рабочих дней ИИ-агента на живом b2b-портале: обмен с 1С по расписанию, настоящие менеджеры, боевые заказы. Четыре тихие поломки обмена, которые он разобрал (ноль из 1С вместо цены, концевой пробел в номере заказа, двойная ночная выгрузка, несобравшаяся витрина), и четыре места, где агенту нельзя верить на слово. Про поломки интереснее не починка, а то, как их вообще заметили: половину задач ему никто не приносил. Про ошибки наоборот, они повторяются, и под каждую пришлось ставить свою страховку.