Откуда берётся план

Итоги H1 2026 мы разобрали отдельно. Если коротко: регуляторная нагрузка выросла сильнее, чем рассчитывали; AI-автоматизация прошла через первые реальные провалы в проде и стала интереснее от этого, а не скучнее; инфраструктурный долг копился тихо, пока все смотрели на AI.

Теперь H2. Три направления.

Инфраструктура: переход на рельсы

Первое направление - это то, что откладывали с начала года.

Kubernetes-дистрибутивы. После обзора отечественных дистрибутивов в июле стало понятно, что несколько проектов у нас висят на самосборных кластерах без внятной истории обновлений. Во втором полугодии закрываем этот хвост: переводим на сертифицированные дистрибутивы там, где есть требования КИИ, и договариваемся с командами о более ясной политике апгрейдов там, где требований нет, но риск накопленных уязвимостей тот же.

Observability до конца. Полгода назад мы писали про зрелость observability-стека. Честный вывод: метрики и трейсы у нас в порядке, логи - сильно хуже. Часть сервисов пишет в stdout без структуры, часть - в файлы с нестандартным форматом. OpenTelemetry Collector уже развёрнут, но покрытие источников неполное. Цель H2: все production-сервисы в structured logging, все источники в Collector. Это не glamorous, но без этого observability - просто красивый дашборд.

Бэкапы и air gap. Veeam v13 развернули в марте, но политику air gap полностью не отработали. Надо закрыть: настроить расписание изолированных резервных копий, проверить процедуру восстановления (не на словах, а живым тестом), задокументировать. Звучит как операционная рутина - и так и есть, но именно такая рутина потом спасает, когда звонят в три ночи.

AI-агенты: масштабирование без потери контроля

Второе направление - сложнее, потому что здесь нет устоявшихся ответов.

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

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

На H2 приоритеты такие:

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

Оценка перед расширением. Прежде чем расширять агента на новый сценарий - письменная оценка рисков. Не большой документ, но фиксированный чеклист: что может пойти не так, есть ли ограничение на действия агента в этом сценарии, кто будет мониторить.

RAG-пайплайны под ревизию. Итоги RAG в проде показали: качество retrieval деградирует, если не следить за актуальностью корпуса. Часть наших пайплайнов работает на документах, которые обновлялись в последний раз полгода назад. Это надо чинить системно, а не точечно.

Регуляторика: дедлайны, которые уже видны

Третье направление - самое предсказуемое, потому что регулятор расписание не меняет.

КИИ: осенний цикл проверок. По наблюдениям коллег и публичным данным ФСТЭК, осень традиционно активна по плановым проверкам. Новые требования ФСТЭК по НДС вступили в силу, и первые вопросы на проверках по ним уже фиксируются. Наша задача до конца августа: пройти по чеклисту со всеми заказчиками, у которых запланированы проверки в Q3-Q4.

ПДн: изменения 152-ФЗ. Июльский разбор изменений - это хорошая база. Но между «прочитали» и «внедрили» - дистанция. У нескольких заказчиков обработка ПДн организована по старым схемам, и новые требования к трансграничной передаче и уведомлениям об утечках требуют изменений в процессах, а не только в документах.

SBOM и supply chain. Требования ФСТЭК по SBOM были введены в начале года. Полгода прошло - у части заказчиков SBOM формально генерируется, но не используется и не проверяется. Если инспектор попросит показать, как SBOM применяется в процессе обновления ПО - ответить будет нечего. Это разрыв, который надо закрывать.

Как мы приоритизируем

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

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

Три наблюдения. Ни одно из них не было очевидным в январе.

Первое: отечественный стек перестал быть «временным»

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

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

Что произошло на практике. Astra Linux SE 2.x и РЕД ОС 9.x закрыли достаточно производственных кейсов, чтобы эксплуатирующие команды перестали относиться к ним как к «нестандартному» варианту. Kubernetes в дистрибуции Deckhouse или аналогах - работает. PostgreSQL 18 с сертификацией для КИИ - используется в проде без постоянного оглядывания на совместимость. Это не означает, что всё идеально и проблем нет. Проблемы есть - особенно в нишевом прикладном ПО и в сетевом оборудовании. Но базовый инфраструктурный слой перестал быть источником экзистенциального беспокойства.

Мы это чувствуем по характеру вопросов на пресейлах. Раньше первый час уходил на «а точно ли оно работает». Сейчас - на «как правильно строить» и «как мигрировать».

Второе: AI-агенты дошли до первого уровня NOC

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

Детали мы разбирали отдельно: примерно треть Tier-1 инцидентов закрывается без участия человека. Здесь хочется сказать о другом - об изменении отношения к теме внутри клиентских команд.

Было. В начале года типичная реакция на предложение «агент будет что-то делать сам» - осторожная, граничащая с отказом. Не потому что технически непонятно, а потому что «ответственность непонятна». Кто виноват, если агент перезапустил не тот под? Это реальный вопрос, не демагогия.

Стало. Те же команды через полгода задают другой вопрос: «почему агент не делает X автономно, нам кажется, это тоже можно доверить». Это разворот. Доверие к агентам строилось медленно - через прозрачные логи, через то, что агент всегда объясняет что сделал и почему, через то, что ни одного серьёзного инцидента по вине агента не было.

Одновременно сформировалось понимание, что первый уровень - это не вся NOC-автоматизация. Tier-2 и выше требует другого уровня рассуждений и другого контроля. Пока агенты работают там, где паттерн повторяемый, а действие обратимо. Это правильная граница.

Третье: регуляторная нагрузка выросла, но стала предсказуемой

Если кто-то ожидал, что после волны 2024-2025 регуляторика слегка расслабится - нет. По объёму требований первое полугодие 2026 не легче. Новые методрекомендации ФСТЭК по КИИ, изменения в 152-ФЗ, активизация проверок по СБОМ - это реальная нагрузка на команды.

Но произошло кое-что важное: нагрузка стала предсказуемой.

Чем отличается предсказуемая нагрузка от непредсказуемой. Год назад интерпретация требований была лотереей. Разные регуляторы, разные проверяющие, разные акценты - компании тратили огромный ресурс не на выполнение, а на угадывание. Сейчас паттерны выровнялись. ФСТЭК опубликовал обезличенную статистику нарушений за H1 - мы её разбирали в июне. ГосСОПКА 2.0 имеет задокументированный API. Реестровые требования по ПДн устоялись настолько, что превратились в чеклист, а не в загадку.

Практически это выглядит так: у нас появились внутренние шаблоны для типовых сценариев - объект КИИ третьей категории, оператор ПДн с выгрузкой в реестр, аудит по 239-му приказу. Шаблон - это не замена анализа, это отправная точка, которая сокращает время работы вдвое и снижает риск что-то пропустить. В прошлом году таких шаблонов у нас не было, потому что не было достаточной повторяемости.

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

Что дальше

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

Одна вещь остаётся без ответа, и мы за ней следим: как масштабируется доверие к AI-агентам в командах, где меньше технической культуры. Опыт, о котором мы пишем, накоплен в достаточно зрелых командах. Там, где инженерная база слабее - другая картина. Границы автономии агентов определяет в том числе зрелость команды, которая их эксплуатирует. Это интересный и до конца не решённый вопрос.

Мы посмотрели три провайдера, которые сейчас публично заявляют IL-2 аттестат и продают managed-сервисы поверх него: Selectel, SberCloud (платформа SberCloud Advanced) и VK Cloud. Яндекс Cloud здесь не рассматриваем - у него другая история с сертификацией, отдельный разговор.

Managed Kubernetes: у кого что

Selectel. Managed Kubernetes у Selectel работает поверх их собственной платформы виртуализации, сертификат IL-2 распространяется на инфраструктурный слой. Control plane управляется провайдером, worker-ноды живут в проекте клиента. Версии Kubernetes поддерживаются с задержкой примерно в один минорный релиз от upstream - на момент написания доступна 1.34, 1.35 в testing. Это приемлемо для большинства production-нагрузок.

Что работает хорошо: node pools с автоскейлингом, интеграция с их же load balancer и object storage, сносная документация по network policy. Что вызывает вопросы: отсутствие встроенного managed etcd-бэкапа на стороне провайдера (клиент должен настраивать сам или использовать Velero), и довольно скромный набор admission webhook'ов из коробки. Для команд, привыкших к Deckhouse или OpenShift, это ощущается как «почти голый k8s».

SberCloud Advanced. Здесь ситуация интереснее. SberCloud развивает Kubernetes-сервис на базе собственного дистрибутива, достаточно близкого к vanilla, но с добавленными модулями под их экосистему. IL-2 аттестат здесь охватывает всё - и control plane, и данные клиентов на инфраструктуре провайдера, что важно при обработке данных КИИ.

Опыт работы с control plane у SberCloud заметно богаче: встроенный etcd-бэкап с политиками ретенции, policy enforcement через OPA Gatekeeper из коробки, интеграция с их IAM для RBAC. Но есть и обратная сторона: цикл поддержки версий длиннее, обновление кластера - процедура с участием саппорта, не всегда автоматизированная. Мы столкнулись с ситуацией, когда минорное обновление заняло несколько дней согласований вместо ожидаемого rolling update.

VK Cloud. Managed Kubernetes в VK Cloud - продукт с наиболее долгой историей среди трёх, и это чувствуется. API стабильный, документация по edge cases довольно подробная, есть нормальный terraform-провайдер с покрытием большей части ресурсов. Поддержка IL-2 появилась через выделенный сегмент инфраструктуры - не все регионы, уточнять при заказе.

Из минусов: автоскейлинг node pool работает, но порой с задержкой, которую мы бы назвали «задумчивой» - от срабатывания метрики до появления новой ноды проходит больше времени, чем хотелось бы для нагрузки с резкими пиками. И интеграция с их managed PostgreSQL через network policy требует ручной настройки там, где ожидаешь автоматики.

Managed PostgreSQL: зрелость разная

Это, пожалуй, самая показательная часть, потому что managed PostgreSQL - более простой продукт, чем Kubernetes, и по его состоянию хорошо видна зрелость operational-процессов провайдера в целом.

Selectel предлагает PostgreSQL до версии 16 (17 в бете). Failover автоматический через Patroni, время переключения в наших тестах - около 20-30 секунд, что для большинства приложений терпимо при наличии retry-логики. Есть point-in-time recovery с хранением WAL до 7 дней. Мониторинг - стандартный набор метрик через их же панель, интеграция с внешним Prometheus требует настройки экспортёра вручную.

SberCloud. PostgreSQL 15 и 16 в production, 17 заявлен. Managed-сервис построен на Patroni с их собственной обёрткой. Примечательно, что SberCloud - один из немногих, кто явно описывает, как проходит failover в сценарии потери connection с мастером, включая поведение при split-brain. Это признак того, что операционная команда провайдера реально с этим разбиралась, а не просто задеплоила Patroni по туториалу. PITR есть, период хранения WAL конфигурируется. Из неудобного: параметры кластера меняются через тикет в саппорт для части настроек, нет полноценного API для изменения postgresql.conf на лету.

VK Cloud. PostgreSQL здесь живёт в рамках их DBaaS-платформы, которая поддерживает несколько СУБД. Версии 15, 16 и 17. PITR работает. Есть API для управления кластером, terraform-ресурсы покрывают основное. Читаемые реплики создаются через API без привлечения саппорта - казалось бы, базово, но у конкурентов это не всегда так. Из нареканий: мониторинг bloat и autovacuum-метрики не попадают в стандартный набор дашбордов, приходится добирать через pgstat* вручную.

Что это значит на практике

Если собрать в одну таблицу без украшений:

• Selectel - хорошая база, понятная модель, IL-2 на инфраструктуре. Для команд, которые готовы сами операционировать нюансы Kubernetes и не боятся настроить мониторинг PostgreSQL - рабочий вариант. Не для тех, кто хочет максимум managed из коробки.
• SberCloud Advanced - наиболее enterprise-ориентированный из трёх. IL-2 охватывает больше слоёв, operational-практики PostgreSQL выглядят серьёзнее. Плата за это - меньше автоматизации самообслуживания, больше взаимодействия с саппортом.
• VK Cloud - самый зрелый продуктово, наиболее удобный API и terraform-покрытие. IL-2 через выделенный сегмент, что нужно учитывать при планировании. Для команд с развитой IaC-культурой подходит лучше всего.

Мы занимаемся настройкой и сопровождением managed-инфраструктуры на всех трёх платформах - выбор провайдера обычно не абстрактный, а продиктован тем, какие сервисы клиент уже использует и насколько критично самообслуживание через API. Если коротко: в 2026 году IL-2 облака перестали быть синонимом «возьмём VM и всё поднимем сами», но до «закрыли глаза и задеплоили» ещё есть дистанция.

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

Что изменилось по существу

Поправки не переписывают 152-ФЗ целиком - они уточняют несколько блоков, которые давно вызывали вопросы.

Биометрия обособлена жёстче. Ранее биометрические ПДн были специальной категорией с повышенными требованиями, но граница между «обычным» фото в личном деле и биометрией, обрабатываемой для идентификации, была размытой. Теперь закон прямо разграничивает: биометрические данные, используемые для установления личности субъекта, - отдельный режим с отдельными требованиями к ИС, согласию и хранению. Фото в паспортных данных сотрудника и шаблон лица в системе контроля доступа - разные категории с разным правовым основанием.

Согласие на биометрию - только письменное и отзываемое с техническим механизмом. Устная форма и галочка в интерфейсе больше не работают. Оператор обязан обеспечить субъекту возможность отозвать согласие, причём это должно быть реализовано технически: отзыв - не просто запись в журнале, а реальное прекращение обработки и удаление биометрического шаблона в разумный срок. Что такое «разумный срок» - поправки определяют как не более 30 дней.

Локализация биометрических данных. Биометрические шаблоны (не исходные изображения, а именно шаблоны для идентификации) должны храниться исключительно на территории РФ. Для большинства российских операторов это и так было очевидно, но поправки закрывают сценарий, когда шаблоны вычислялись в облачном API иностранного вендора и кэшировались за рубежом.

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

Где это бьёт больнее всего

В HR это пропускные системы с распознаванием лиц - их внедряли активно в 2023-2024 годах. Типичная архитектура: камера на входе, локальный сервер или облачный API для вычисления шаблона, СКУД, которая получает результат идентификации. Проблемы обычно в нескольких местах.

• Форма согласия. В большинстве случаев согласие на биометрию было вшито в трудовой договор или общее согласие на обработку ПДн - без явного указания на биометрию как отдельную категорию. Это нужно переделывать.
• Механизм отзыва. СКУД не умеет «удалить шаблон по запросу сотрудника» - это не функционал, который закладывается по умолчанию. Нужна доработка или замена.
• Обработчик шаблонов. Если API для идентификации - сторонний сервис (а таких много), нужно проверить, где он хранит шаблоны и есть ли договор поручения с явным указанием на биометрию.

В финтехе похожая история с удалённой верификацией клиентов при открытии счёта или оформлении кредита. Там биометрические данные часто передаются в Единую биометрическую систему (ЕБС/ГБД) или в сервисы банков-партнёров. Новый порядок требует пересмотра оснований для каждого из этих потоков.

Что нужно пересмотреть в ИС

Мы сейчас идём по этому чеклисту с несколькими заказчиками - для понимания масштаба задачи.

Инвентаризация систем с биометрией. Не документация - реальный опрос ИТ: где вычисляются шаблоны, где хранятся, куда передаются результаты. Часто оказывается, что шаблоны оседают в нескольких местах сразу: на локальном сервере СКУД, в логах API и в базе самого сервиса идентификации.

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

Технический механизм удаления шаблонов. Это самая трудоёмкая часть. Нужно не просто помечать запись как «отозванную» - нужно реальное удаление биометрического шаблона из всех мест хранения. Если СКУД или система верификации не умеют этого делать по API - либо доработка, либо замена вендора.

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

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

Что пока остаётся неясным

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

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

В апреле мы описывали как строили lakehouse на ClickHouse + MinIO + Iceberg и сколько вспомогательного кода пришлось написать, чтобы всё работало. Одна из главных болей - ClickHouse умел читать Iceberg-таблицы, но не умел делать это в режиме полноценного federated query: нельзя было объединить данные из нативной ClickHouse-таблицы и Iceberg-таблицы в одном запросе без предварительного ETL или materialised view. Точнее, технически JOIN работал, но partition pruning на стороне Iceberg отваливался, и запрос читал всё подряд.

Что изменилось в 26.5

Поддержка Iceberg стала полноценной внешней таблицей. В 26.5 движок IcebergS3 получил нормальный pushdown предикатов, включая сложные фильтры по партиционированным полям. Теперь ClickHouse смотрит на Iceberg-манифесты и partition summary прежде чем идти за файлами, и транслирует WHERE-условия в pruning на уровне Iceberg partition spec. Включая bucket() и truncate() трансформации - как раз то, на чём мы спотыкались раньше.

Query cache стал умнее в сценариях с внешними таблицами. До 26.5 query cache работал только для запросов полностью к нативным MergeTree-таблицам - логично, потому что для внешних источников кеш рисковал отдавать устаревшие данные без предупреждения. В 26.5 добавили TTL-based invalidation привязанный к snapshot ID Iceberg-таблицы: кеш хранит вместе с результатом snapshot, при котором он был получен, и инвалидирует запись при появлении нового snapshot. Не универсальное решение - оно работает только там, где ClickHouse видит Iceberg-метаданные, но для нашего сценария это именно то, что нужно.

Что тестировали

На нашем аналитическом кластере живут две категории данных: горячие - нативные ClickHouse MergeTree-таблицы с данными за последние 90 дней, и холодные - исторический архив в Iceberg/MinIO с полной историей за несколько лет. До 26.5 запросы «дай мне тренд за 2 года» шли в два шага: сначала выгрузка из Iceberg через отдельный pipeline, потом JOIN уже внутри ClickHouse с нативными данными. Это или ручной ETL, или сложный orchestration.

После обновления на 26.5 написали тестовый запрос который напрямую объединяет нативную таблицу с Iceberg-внешней:

SELECT
    toStartOfMonth(event_time) AS month,
    sum(amount) AS total
FROM native_events
UNION ALL
SELECT
    toStartOfMonth(event_time) AS month,
    sum(amount) AS total
FROM iceberg_s3('...', 'events')
WHERE event_time < toDate('2026-01-01')
GROUP BY month
ORDER BY month

Partition pruning. На запросе с конкретным диапазоном дат ClickHouse теперь реально читает только нужные Iceberg-партиции. На нашей тестовой таблице с партицией по месяцам и запросом за год - сканирует 12 файловых групп вместо всего архива. Раньше читал всё. Разница в прочитанных байтах из MinIO - кратная.

Overhead на первый запрос. Новый pushdown требует парсинга Iceberg-манифестов до начала чтения данных. На больших таблицах с тысячами snapshot-файлов это добавляет заметную задержку перед началом streaming результата. На нашей таблице с ~800 manifest entries это около 1-2 секунд дополнительно к первому запросу. Для интерактивного BI это граница приемлемого; для пакетных запросов - не проблема совсем.

Query cache на Iceberg. Включили с TTL в 5 минут. При повторных запросах к одному snapshot - кеш работает и отдаёт результат мгновенно. При появлении нового snapshot в Iceberg-таблице (у нас compaction запускается раз в 30 минут) - кеш инвалидируется автоматически. Раньше мы городили свой инвалидатор поверх application-layer кеша. Теперь это из коробки.

Что стало ненужным

Помним, что в апреле написали schema-sync daemon для автоматической синхронизации схемы между Iceberg и ClickHouse? В 26.5 добавили REFRESH PERIODICALLY опцию для внешних Iceberg-таблиц - движок сам опрашивает catalog по расписанию и подхватывает новые колонки. Daemon мы ещё не выключили (хочется понаблюдать поведение в разных ситуациях), но по всей видимости это убираемый компонент.

Осторожность, которую не стоит отбрасывать

Federated query между нативным ClickHouse и Iceberg теперь работает удобно, но несколько вещей надо держать в голове.

Первое - network cost. Каждый query к Iceberg-данным в MinIO - это трафик между ClickHouse-нодами и object storage. Даже с pruning это реальная нагрузка на сеть. При высокой конкурентности запросов у нас начинает проявляться contention на сетевом интерфейсе storage-ноды.

Второе - catalog latency. Если Iceberg catalog (у нас REST catalog на PostgreSQL) недоступен или медленный - весь запрос ждёт. Это новая точка зависимости, которой не было при работе только с нативными таблицами.

Третье - snapshot consistency. JOIN между нативной таблицей (данные на момент запроса) и Iceberg-таблицей (данные на момент последнего snapshot) - это разные временные срезы. Для большинства аналитических сценариев это нормально, но надо понимать, что пишешь запрос, который по природе eventually consistent.

Где мы сейчас

Обновление выглядит убедительно для наших сценариев. ETL-pipeline который гонял данные из Iceberg в staging-таблицу перед JOIN - планируем убрать. Это уменьшит и сложность, и latency для запросов типа «вся история».

Query cache на Iceberg включаем в продуктиве - это прямой выигрыш для BI-дашбордов которые читают исторические данные за фиксированный период.

Schema-sync daemon оставляем под наблюдением ещё несколько недель.

Про остальное в 26.5 (новые функции для работы с временными рядами, изменения в replicated DDL) - пишите если интересно, можем разобрать отдельно.

Если строите аналитическую платформу с lakehouse-архитектурой - DWH/BI-проекты это как раз та область, где мы работаем с такими стеками в продуктиве.

Оказался прав достаточно часто, чтобы следующий вопрос стал неизбежным: а что если дать ему кнопки?

С марта этого года у нас в проде работает агент, который не только диагностирует, но и реагирует. Сейчас примерно треть Tier-1 инцидентов закрывается без участия дежурного - агент обнаружил, отработал, записал в тикет. Рассказываем, как мы дошли до такой конфигурации и где пришлось провести жёсткие границы.

Что такое Tier-1 в нашем контексте

Для начала - что мы называем Tier-1, чтобы не было иллюзий. Это не «простые» инциденты в смысле «не страшные». Это инциденты с понятным и повторяемым паттерном: симптом хорошо распознаётся, причина известна, действие стандартное. Накопленная база показала, что таких у нас около 40% от общего потока - и это неплохой материал для автоматизации.

Конкретные примеры из того, что сейчас делает агент:

• Перезапуск подов с OOMKill. Pod упал по OOM, это видно из событий Kubernetes. Агент проверяет, что это не системный под, не база данных, не stateful-компонент без graceful shutdown, и перезапускает. Если в течение 10 минут под падает снова - эскалирует.
• Очистка накопившихся очередей. Несколько сервисов у клиента генерируют «мусорные» сообщения при определённых условиях - это известная история, задокументированная в runbook. Агент сам чистит очереди по заданному паттерну.
• Перераспределение дискового пространства. Если заполнение раздела пересекает порог, агент проверяет стандартные места скопления мусора (logs, tmp, старые снапшоты) и чистит то, что помечено как безопасное для удаления. С явным лимитом: трогает только файлы старше 7 дней из заранее согласованного списка директорий.

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

Как мы определяли границы автономии

Самый сложный вопрос проекта - не технический. Технически несложно дать агенту kubectl exec или доступ к Kafka API. Сложно решить, для каких классов действий этот доступ допустим.

Мы пришли к трём критериям, которые определяют, идёт ли действие в автономный список или требует подтверждения:

Первый - обратимость. Действие должно быть обратимым без потери данных. Перезапуск пода - обратимо. Удаление файла логов - обратимо (файл воссоздаётся). Масштабирование деплоя вниз в прайм-тайм - нет, потому что пользователи уже получают деградацию и откат не мгновенный.

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

Третий - предсказуемость результата. Агент должен уметь сформулировать ожидаемый результат своего действия и проверить его через заданное время. Перезапустил под - через 3 минуты проверяет статус. Если не Ready - эскалирует. Это важно: без проверки результата автоматизация превращается в «выстрелил и забыл», что хуже ручной работы.

Всё, что не проходит хотя бы один критерий, идёт на подтверждение к дежурному. Агент присылает сообщение: «Вот что вижу, вот что предлагаю сделать, подтвердите.» Дежурный отвечает одной кнопкой. Или не отвечает - тогда через 5 минут агент отправляет повторный запрос и звонит.

Где потребовали человеческого подтверждения

Несколько случаев, которые казались автоматизируемыми, но оказались нет.

Деградация базы данных. Любое изменение, которое касается PostgreSQL или Redis в продуктиве, идёт только через подтверждение. Не потому что агент не может выполнить команду - потому что у баз данных слишком много состояния, которое агент не видит. Незафиксированные транзакции, репликационный лаг, блокировки - всё это влияет на то, что «безобидный» рестарт может сделать на практике.

Инциденты с внешними зависимостями. Если агент видит, что проблема с высокой вероятностью не на нашей стороне - сетевой провайдер, сторонний API, - он не делает ничего автоматически. Ни «лечебного» перезапуска сервиса, ни других действий, которые создают шум без пользы.

Паттерны с низким confidence. Есть пороговое значение уверенности диагноза. Если агент не может сопоставить симптом с известным паттерном выше порога - он сразу идёт к дежурному, не пытаясь применить «похожий» runbook.

Инженерная честность про 35%

Цифра 35% закрытых Tier-1 без участия человека звучит хорошо. Но важен контекст.

Первый месяц после запуска - примерно 20%, потому что список автономных действий был маленьким и агент часто перестраховывался. Мы итеративно разбирали каждый случай, где агент попросил подтверждение, и часть из них переносили в автономный режим - но только после явного обсуждения с клиентом. Сейчас 35%, и мы не торопимся поднимать эту цифру. Цель не максимизировать автономию, а держать её в зоне, где дежурный уверен, что агент не делает глупостей за его спиной.

Был один случай, который укрепил нас в консервативном подходе. Агент автономно почистил tmp-директорию на сервере приложений, потому что она соответствовала всем критериям безопасного удаления. Оказалось, что один из разработчиков положил туда временный файл с ручными миграционными данными, которые ждали применения. Файл был правильно назван, лежал в правильном месте, был достаточно старым. Данные потеряли. Восстановили из памяти разработчика за пару часов, но это была неприятная история.

После этого мы добавили четвёртый критерий к автономным действиям: файловые операции требуют явного согласованного списка - не директорий, а конкретных паттернов файлов. Это замедляет onboarding нового клиента, но убирает класс сюрпризов.

Где мы сейчас

Мониторинг трассировок дал нам метрику, которую сейчас смотрим отдельно: процент инцидентов, где агент эскалировал, но дежурный после разбора не применял никаких действий. Это «ложные эскалации» - агент перестраховался там, где мог справиться сам. Сейчас эта цифра около 15% от всех эскалаций. Работаем над тем, чтобы снизить её, но медленно и осторожно.

Следующий вопрос, который у нас открыт: как автоматизировать не отдельные действия, а цепочки. Сейчас агент делает одно атомарное действие и проверяет результат. Иногда нужно сделать несколько вещей подряд - например, почистить очередь, перезапустить воркер и проверить метрики. Это сложнее по логике подтверждений: если шаг 2 из 3 требует подтверждения, а шаг 1 уже выполнен - что делать? Такие сценарии в автономный режим не переводим. Накапливаем прецеденты.

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

Мы занимаемся аудитом КИИ, поэтому сразу пошли разбираться, что это значит на практике в Kubernetes.

Что требует документ

Ключевое требование звучит так: машинное TLS-взаимодействие компонентов внутри объекта КИИ должно обеспечиваться сертификатами, выданными ЦС, входящим в реестр НДЦ ФСТЭК, либо созданным на основе сертифицированного СКЗИ с отечественными алгоритмами.

Под «машинным взаимодействием» документ понимает в том числе: взаимодействие между микросервисами, компонентами оркестратора, агентами мониторинга, базами данных - то есть весь service-to-service трафик, который в Kubernetes закрывают через mTLS.

Let's Encrypt и коммерческие зарубежные ЦС для этого класса применений выбывают явно. Собственный внутренний CA на OpenSSL с RSA - тоже вопрос, потому что ФСТЭК ориентирует на ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012.

Откуда растёт задача

У нескольких наших заказчиков внутренние сервисы в Kubernetes исторически работали с self-signed сертификатами RSA-2048, выданными локальным CA на основе OpenSSL. Это работало - никто особо не думал о PKI внутри кластера, cert-manager раскатывал ротацию, операторы не беспокоились.

После январских методрекомендаций криптографическая часть формально оставалась в серой зоне: требования к алгоритмам были, но чёткой нормы про ЦС для машинного TLS не было. Теперь она есть.

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

Как это выглядит в Kubernetes

Разберём архитектуру внутреннего CA на отечественных алгоритмах для кластера.

Корневой CA на ГОСТ. Для создания корневого CA нужна реализация ГОСТ Р 34.10-2012 на эллиптических кривых. Из доступных инструментов - КриптоПро CSP с набором утилит командной строки: csptest, certutil. Альтернатива - OpenSSL с движком gost (пакет openssl-gost-engine), сборки которого есть в РедОС 9.x и Astra Linux SE 2.x. КриптоПро даёт сертифицированное СКЗИ, что закрывает требование о сертификации. openssl-gost-engine - нет, поэтому для строгого исполнения требований НДЦ он не подходит.

Промежуточный CA для кластера. Практика здесь стандартная: root CA держать офлайн или в аппаратном HSM, для кластера выпускать отдельный intermediate CA с ограниченным сроком действия. Это снижает радиус поражения при компрометации кластерного компонента.

cert-manager и ГОСТ. Это место наибольшего трения. cert-manager умеет работать с внешними issuer через CustomResourceDefinition и spec.issuerRef.kind: Issuer. Есть два подхода:

• Vault PKI Secrets Engine - HashiCorp Vault поддерживает внешние PKCS#11-провайдеры; при подключении КриптоПро через PKCS#11-интерфейс Vault может подписывать сертификаты ГОСТ-ключом. cert-manager взаимодействует с Vault через стандартный Vault Issuer. Это рабочая схема, но требует Vault в кластере или рядом с ним.
• Самописный external issuer - cert-manager имеет спецификацию External Issuer, позволяющую написать отдельный контроллер, который обрабатывает CertificateRequest и подписывает их любым бэкендом. Несколько команд уже публиковали такие реализации для КриптоПро CSP.

На практике мы сейчас смотрим в сторону Vault PKI - он даёт аудит-лог выдачи сертификатов, что само по себе полезно для КИИ. Для кластеров поменьше external issuer с прямым вызовом CSP - проще в операционном плане.

Что делать с сервисными mesh. Если в кластере работает Istio или аналог с mTLS, там своя CA (istiod). Istio поддерживает подключение внешнего CA через pluggedInCerts - нужно переключить на тот же intermediate CA. Это требует перезапуска sidecar-ов, планируем это как отдельное окно.

Что не решается быстро

Есть несколько вещей, которые мы видим как реальные сложности на ближайшие месяцы.

Ротация существующих сертификатов. В продуктивных кластерах за годы накапливается много сертификатов: ingress-контроллеры, webhooks, etcd, kubelet. Полная миграция на ГОСТ - это ротация всего этого стека, причём координированно. Один неучтённый webhook с истёкшим старым сертификатом может положить API-сервер в самый неудобный момент.

Доверие клиентов. Корневой ГОСТ-сертификат нужно добавить в trust store на всех узлах кластера, во все контейнеры, которые делают TLS-соединения, и в те внешние системы, которые обращаются к сервисам кластера. Это не автоматизируется за один день.

Инструментарий разработчиков. Если команда использует curl, wget, клиентские SDK - они должны поддерживать ГОСТ. Большинство стандартных linux-утилит на дистрибутивах с поддержкой ГОСТ работают корректно, но это нужно проверять для каждого компонента.

Сроки по документу

Требования вступают в силу для объектов первой категории через шесть месяцев с даты публикации, для второй и третьей - через двенадцать. Это даёт время на подготовку, но с учётом того, что нужно пройти выбор инструментария, пилот, документирование и согласование изменений в ОРД - откладывать на последний месяц не стоит.

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

Главный вывод коротко: мы слишком долго смотрели не туда. Полгода мы занимались моделями - выбирали, сравнивали, тестировали. А узким местом всё это время был retrieval.

Как мы это поняли

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

Картина оказалась однозначной: в 38 случаях из 50 правильный документ в базе был. Ретривер его не достал. Не потому что модель слабая - потому что в топ-5 retrieved чанков нужного куска не было.

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

Переход на гибридный поиск

До этого момента мы использовали pgvector с косинусным поиском по плотным эмбеддингам. Работало, но с характерной проблемой: точные термины, артикулы, названия процессов - всё это семантический поиск теряет, если нет похожих по смыслу соседей в пространстве векторов. «ИТС-442» и «инструкция по техническому обслуживанию узла 442» в векторном пространстве далеко друг от друга, хотя это один и тот же документ.

Решение, к которому мы пришли - гибридный поиск: плотный эмбеддинг-поиск через pgvector плюс разреженный BM25 через отдельный индекс, финальный rerank по score от обоих методов. Схема не новая, но вопрос был в том, насколько это оправдано для наших объёмов.

Оправдалось. На тестовом наборе из 200 вопросов recall@5 (доля случаев, когда нужный документ попал в топ-5) вырос с примерно 60% до примерно 80%. Точные цифры зависят от конкретной базы, но направление было одинаковым на двух клиентах, где мы это тестировали.

Что сложно в этом переходе:

• Поддерживать два индекса. BM25 и векторный индекс нужно держать консистентными при обновлении документов. Это не катастрофа, но лишняя точка, за которой нужно следить.
• Scoring не складывается напрямую. Нормализация score-ов от BM25 и косинусного поиска - отдельная задача. Мы используем reciprocal rank fusion, это работает предсказуемо.
• BM25 требует качественного текста. Если документы плохо написаны или содержат много OCR-мусора - разреженный индекс только мешает. Пришлось улучшить пайплайн предобработки документов.

Что с моделями

После того как retrieval наладили - да, качество генерации тоже имеет значение. Но разница между моделями на хорошо отретриверованном контексте значительно меньше, чем мы ожидали. У нас работают инсталляции на GigaChat API и на локальных моделях (Qwen2.5 в нескольких вариантах размера), и при хорошем retrieval разница в итоговом качестве ответа - рабочая, но не кардинальная.

Там, где модель реально решает - это «нечёткие» вопросы, где пользователь формулирует неточно или смешивает несколько тем. Но это скорее задача query expansion на входе в ретривер, чем задача мощности генеративной модели.

Для КИИ-клиентов вариант с облачными API не работает по контрактным причинам - это не изменилось. Локальный инференс остаётся единственным путём.

Что сейчас в работе

Мониторинг на уровне span-ов дал нам метрику, которую теперь смотрим отдельно: доля запросов, где score лучшего retrieved документа ниже порога. Это ранний сигнал, что какая-то категория вопросов плохо покрыта базой знаний - не потому что модель плохая, а потому что документа нет или он написан так, что ни один из индексов его не находит.

Параллельно тестируем reranker-модель поверх гибридного поиска - дополнительный проход, который переранжирует топ-15 кандидатов перед подачей в генерацию. На синтетических тестах это даёт ещё один заметный прирост recall, но у нас нет достаточной production-статистики, чтобы говорить уверенно.

Где мы стоим

RAG в корпоративном проде работает. Не без усилий, не «запустил и забыл», но работает. Основная часть усилий уходит не на модели и не на инфраструктуру - она уходит на качество данных и качество retrieval. Это скучнее, чем обсуждать GPT-5 против локальных моделей, но это честная картина.

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

Что несёт Kubernetes 1.35 коротко

Если вы читали апрельский разбор, напомним ключевые моменты. In-place pod resizing перешёл в graduated: API финальный, feature gate включён по умолчанию, изменение CPU requests применяется без рестарта контейнера. Scheduler получил стабилизированный QueueingHint API и исправленный PreScore - плагины теперь работают на полном списке feasible-нод, а не на выборке. Для большинства кластеров второе проходит незаметно, но для нагрузок с кастомными scheduler-плагинами или активным VPA - заметно.

Важный момент из апрельского тестирования, который подтвердился в production: in-place resize для уменьшения memory requests по-прежнему уходит в Deferred у части нод. Не баг, поведение задокументировано, но нужно закладывать в операционные процедуры.

Deckhouse 1.72: что добавилось поверх 1.35

Deckhouse 1.72 - это не просто «bumped version Kubernetes». Вместе с 1.35 в релиз вошло несколько изменений платформы.

node-manager получил поддержку in-place resize в NodeGroup-политиках. Теперь можно задать стратегию resize на уровне NodeGroup: updateMode: InPlaceOrRecreate для подов, которые допускают in-place, и updateMode: Recreate для тех, которые нет. Раньше это нужно было настраивать в VPA-объектах индивидуально. Выглядит незначительно, но для большого кластера с несколькими типами нагрузок - ощутимое упрощение.

Модуль vertical-pod-autoscaler обновлён и теперь по умолчанию выставляет updateMode: InPlaceOrRecreate для новых VPA-объектов. Если у вас уже есть VPA-объекты без явного updateMode - при обновлении до 1.72 они получат этот режим. На кластере клиента это привело к одному небольшому сюрпризу: несколько подов с VPA начали получать in-place resize вместо eviction, и операционная команда клиента удивилась, увидев новый статус в kubectl get pods. Не проблема, но стоит предупреждать заранее.

Сетевой модуль cni-Cilium обновлён до версии с поддержкой scheduler-events от QueueingHint. Это связано с изменениями в scheduler из 1.35: Cilium теперь корректно сигнализирует scheduler, когда сетевой ресурс освободился, вместо того чтобы ждать следующего цикла. На практике это уменьшает задержку между освобождением пода и началом нового scheduling.

Сам процесс обновления на Deckhouse

Обновление кластера с Deckhouse 1.71 до 1.72 заняло около двух часов на кластере из 14 нод. Плановое обслуживание мы закладывали на четыре часа - осталось время.

Deckhouse обновляется через DeckhouseRelease объект в канале stable. Появился новый release - мы прочитали release notes, убедились, что нет несовместимостей с нашими кастомными ресурсами, подтвердили обновление. Дальше Deckhouse сам катит ноды в порядке, который мы задали в NodeGroup: сначала одна control-plane нода, потом остальные по одной с проверкой ready-состояния.

Manual steps для этого обновления:

• Проверить VPA-объекты перед обновлением: если updateMode явно не задан, он будет изменён на InPlaceOrRecreate. Мы прошлись по всем VPA и явно выставили режим там, где хотели сохранить прежнее поведение (eviction).
• Проверить кастомные scheduler-плагины, если есть. У нас их нет, но у одного из клиентов был DeploymentTopologyPolicy от стороннего оператора - проверили совместимость с изменённым PreScore.
• Предупредить операционную команду об изменении видимого поведения VPA-подов.

По сути три пункта. Для managed-кластеров с Deckhouse это стандартный ритуал перед каждым крупным обновлением.

ROSA: то же самое, но иначе

На втором кластере с ROSA процесс обновления до 1.35 выглядит по-другому структурно, хотя итог тот же.

ROSA использует канальную модель: stable, testing, candidate. Kubernetes 1.35 появился в testing раньше, в stable вышел несколько дней назад. Обновление применяется через rosectl cluster update --version 1.35 или через веб-консоль. Платформа сама управляет rolling update нод, но детальность контроля меньше: нельзя задать порядок обновления нод так же гибко, как в Deckhouse через NodeGroup-стратегии.

Manual steps для ROSA оказалось больше:

• VPA в ROSA не обновляется автоматически вместе с кластером. Нужно отдельно обновить VPA Operator через OperatorHub или helm-чарт. В Deckhouse это часть платформы и версионируется вместе.
• Feature gate InPlacePodVerticalScaling в ROSA включён, но настройка updateMode для VPA по умолчанию не меняется - нужно делать вручную, если хочешь перейти на in-place.
• Scheduler-плагины в ROSA работают через стандартный механизм Kubernetes, без дополнительной абстракции. После обновления до 1.35 убедились, что QueueingHint в кастомных плагинах реализован корректно - у одного плагина обнаружился пропущенный метод, который раньше не мешал, а теперь вызывает предупреждения.
• Проверить OperatorHub-операторы на совместимость с 1.35 API - это обязательный шаг, который в Deckhouse частично закрывается модулем compatibility-check.

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

Итог сравнения

Оба дистрибутива дали отечественный managed Kubernetes в production. Graduated in-place resize работает на обоих. По опыту этого обновления разница в ощущениях такая: Deckhouse автоматизирует больше нюансов платформы - VPA, CNI, совместимость - и требует меньше явных ручных шагов. ROSA даёт чуть больше прозрачности через стандартные Kubernetes-примитивы, но и чуть больше ответственности за согласованность компонентов.

Для команд, у которых операционные процедуры уже выстроены под один из дистрибутивов, это не повод переходить. Но для новых проектов разница в объёме manual steps - аргумент, который стоит учитывать.

In-place resize в production пока работает только для CPU: memory случай с Deferred встретился и здесь, на containerd 1.7 с cgroup v2. Будем держать это в виду при следующих VPA-политиках.

Плохая новость: первые три месяца мы потратили на то, чтобы признать, что governance-модель, которую спроектировали на старте, не работает. И переделали её почти с нуля.

Что было на старте

В апреле мы описывали первые результаты - Backstage с плагинами под Gitflic и Harbor, Software Templates, сокращение онбординга нового сервиса с трёх дней до двух часов. Всё это правда. Только речь тогда шла о 8-10 командах, которые онбордились в контролируемом режиме.

Когда число команд перевалило за 15 и мы открыли регистрацию для всех - посыпалось.

Первая проблема была ожидаемой: Templates не покрывали реальное разнообразие. У нас было три шаблона (Spring, FastAPI, фронтенд), а команды приходили с Go-сервисами, с легаси на PHP, с кастомными воркерами. Кто-то начинал адаптировать ближайший Template под свои нужды - и создавал сервис, который формально существовал в portal, но реально выходил за рамки любых автоматических политик.

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

Провал governance-модели версии 1.0

Начальная модель выглядела разумно: есть платформенная команда (мы), есть команды-потребители. Платформенная команда пишет Templates и поддерживает portal, команды-потребители используют. Классика.

Проблема в том, что мы не договорились о нескольких вещах.

Первое - кто принимает запросы на новые Templates. Когда пришли первые пять команд с запросами «нам нужен шаблон для X» - мы взяли их в бэклог. Когда пришли ещё двадцать - бэклог превратился в очередь на полтора месяца вперёд. Команды начали делать Templates сами, без ревью, без стандартов. В portal появились шаблоны, которые создавали Kubernetes-namespace без NetworkPolicy. Один шаблон генерировал Harbor robot account с правами на весь реестр, а не на один проект.

Второе - кто отвечает за деградацию. Когда у команды не получалось что-то сделать через portal - она шла к нам. Мы разбирались, находили баг или неочевидное поведение, чинили. Но при 40 командах этот поток стал съедать треть времени платформенной команды. Без SLA, без тикетной системы, просто «в личку написали».

Третье - как обновлять платформу без поломки того, что уже работает. Мы обновили Backstage с 1.26 до 1.28 в феврале. Три плагина перестали работать, потому что сменился API. Семь команд обнаружили это в момент, когда им нужно было создать новый сервис.

Governance-модель версии 2.0

Переделка заняла март и апрель. Вот что изменилось.

Platform-as-a-product со своим бэклогом и SLA. Теперь это официально продукт внутри компании, у него есть product owner из платформенной команды, публичный бэклог и два типа запросов: «баг» (SLA 2 рабочих дня) и «новый Template» (SLA 2 спринта). Это не ускорило обработку запросов - зато убрало ожидание неизвестности и обиды «вы нас игнорируете».

Контрибьюторская модель для Templates. Команды могут писать свои Templates, но через PR в платформенный репозиторий с обязательным ревью от платформенной команды. Чеклист ревью формализован: NetworkPolicy, ресурсные лимиты, robot account с минимальными правами, catalog-info.yaml. Templates без прохождения чеклиста в portal не попадают. Да, это медленнее, чем «залить самому». Зато мы знаем, что в portal нет шаблонов, которые создают дыры в безопасности.

Changelog с уведомлениями об обновлениях. Перед любым обновлением Backstage или плагинов - тестирование на staging-инстансе portal, список потенциально затронутых команд, уведомление в Mattermost за неделю. Это очевидно, но нам понадобилось один раз поломать прод, чтобы сделать это правилом.

Откуда взялись 6 часов

Цикл commit-to-prod стал 6 часов не потому, что portal волшебным образом ускорил деплой. Он ускорился по другой причине: платформа убрала ручные ожидания из пути.

Раньше выглядело так: разработчик создаёт PR - ждёт, пока кто-то вручную настроит pipeline в CI-системе - pipeline отрабатывает - ждёт, пока DevOps-инженер проверит манифесты - деплой идёт в прод. Ожидания на ручных шагах суммировались в 2-3 дня при любой загрузке команды.

Сейчас: PR создан - platform-pipeline запускается автоматически через Templates-сгенерированную конфигурацию - GitOps-контроллер видит изменение и деплоит - прод. GitOps-подход, который мы описывали раньше, здесь является несущей конструкцией: без автоматической синхронизации состояния fleet-репозитория скорость бы не появилась.

Шесть часов - это в среднем, включая время прохождения CI (тесты, сборка образа, сканирование). Для критических фиксов с fast-track путём - 1.5-2 часа.

Где до сих пор больно

Нет смысла делать вид, что всё хорошо.

• Observability платформы - мы знаем, что portal живой, но не знаем детально, какие Templates используются чаще, где пользователи застревают, сколько попыток создания заканчивается ошибкой. Backstage не даёт это из коробки, плагин аналитики мы ещё не написали.
• Стоимость владения - поддержка portal сейчас занимает примерно 40% времени одного инженера. Это приемлемо при 40 командах, но нелинейно вырастет при 80.
• Синхронизация с реальностью - если команда сделала что-то вне portal (а такое бывает), reconciliation между реальным состоянием и тем, что видит Catalog, до сих пор частично ручной процесс.

Platform Engineering как функция не заканчивается запуском portal. Она, скорее, только начинается, когда portal запущен и к нему пришли реальные пользователи. Первые полгода - это в основном обнаружение того, что не учли при проектировании.

Что изменилось в хранилище

TimescaleDB backend в Zabbix был и раньше, но работал как надстройка: Zabbix писал в PostgreSQL, TimescaleDB превращал таблицы в гипертаблицы через расширение. В 8.0 интеграция глубже - Zabbix теперь умеет управлять партициями напрямую, не полагаясь на автоматику TimescaleDB. Это даёт контроль над политиками хранения на уровне конкретных item-групп: метрики ядра хоста держим 90 дней с полным разрешением, агрегаты по приложениям - год, детальные системные метрики - 30 дней. Раньше такую гранулярность приходилось делать через костыли в retention-политиках или заводить отдельные хосты.

Производительность записи тоже ощутимо выросла. На нашем тестовом кластере (около 40 000 item-ов, среднее значение раз в минуту) TimescaleDB backend в 8.0 показывает примерно на треть меньше latency при вставке по сравнению с нашей текущей версией 7.2. Это не маркетинговый замер - просто pgbench поверх Zabbix history table до и после.

Anomaly detection: как оно устроено

Zabbix 8.0 добавляет новый тип item - anomaly detection item. Он не собирает метрику сам по себе, а получает базовую метрику как источник и обучает локальную модель на её истории. Никаких внешних вызовов нет - модель живёт на том же Zabbix-сервере, обучение происходит через встроенный Python-worker.

Схема обучения прямолинейная. Zabbix берёт исторические данные за указанный период (по умолчанию 8 недель), разбивает их по дням недели и часам суток, строит базовый профиль нормального поведения с доверительными интервалами. Алгоритм - вариация seasonal decomposition с добавкой, которую авторы называют adaptive smoothing: модель адаптируется к медленному дрейфу базовой линии, не реагируя на долгосрочные тренды как на аномалии.

Триггер на аномалию задаётся как отклонение от предсказанного диапазона более чем на N сигма в течение M минут. Это точно те же параметры, что вы бы выставляли вручную, - разница в том, что «нормальный диапазон» теперь рассчитывается из реальной истории, а не из головы.

Что это меняет на практике

Мы посмотрели на наш пул алертов за последние три месяца и прикинули, сколько триггеров можно было бы заменить anomaly detection item-ами.

Грубая оценка: около 60% триггеров по CPU, памяти, latency и disk I/O у нас заданы статическими порогами типа «CPU > 85% 5 минут» или «response time > 2 секунды». Это работает, но требует ручной настройки под каждый хост - то, что нормально для веб-сервера под нагрузкой, будет ложным алертом на аналитическом сервере, который честно ест CPU по расписанию. Anomaly detection закрывает ровно эту проблему: порог для каждого хоста выводится из его собственной истории.

Остальные 40% - это специфические триггеры: конкретные процессы упали, размер очереди превысил N сообщений, репликация отстала больше чем на M секунд. Там аномалии не помогут - нужны точные пороги или структурные проверки.

Как обучить модель на реальных данных

Несколько замечаний из тестовой эксплуатации:

• Период обучения важен. 8 недель - разумный минимум для сервисов с недельной цикличностью. Если у вас есть месячный цикл (финансовые системы, отчётность), ставьте 12-16 недель, иначе модель не увидит паттерн и будет биться об него каждый месяц.

• История до обучения должна быть чистой. Если в период обучения были инциденты с высокой нагрузкой - модель включит их в «нормальный» диапазон. Zabbix позволяет исключить период из обучения через API, и это надо использовать осознанно, а не забыть про эту возможность.

• Adaptive smoothing и плановые изменения. Если вы добавили новый сервис или выкатили релиз с изменённой нагрузкой - модель адаптируется, но это займёт несколько дней. В этот период чувствительность лучше снизить вручную через параметр sensitivity в item-настройках.

• Zabbix Python worker - отдельный процесс. Он запускается рядом с Zabbix server и потребляет ресурсы пропорционально количеству anomaly detection item-ов. На нашем кластере с 200 такими item-ами это около 300 МБ RAM и пара процентов CPU в фоне. Не страшно, но посчитайте до масштабирования.

Что не нравится уже сейчас

Интерфейс настройки модели в веб-GUI сырой. Можно задать период обучения и sensitivity - и почти всё. Посмотреть, на каких данных модель обучена, что она считает аномальным диапазоном для конкретного часа в конкретный день недели - нельзя. Это жирная дыра в observability самого мониторинга. Объяснять клиенту «почему сработал алерт» при наличии anomaly detection item становится сложнее: был порог 85% - понятно. Теперь «модель решила, что это аномалия» - объяснение, с которым не все готовы работать.

Zabbix API в 8.0 добавил endpoint для выгрузки предсказанных baseline-значений - но это JSON с цифрами, без какой-либо визуализации в стандартном GUI. Мы уже сделали дашборд в Grafana через этот API, который показывает предсказанный диапазон поверх реальной метрики. Работает, но это дополнительная работа, которую хотелось бы видеть из коробки.

Подключение для managed-клиентов планируем на следующий месяц - сначала на нескольких пилотных хостах. Посмотрим, как anomaly detection ведёт себя на инфраструктуре, которая не была в тестовой выборке.

На практике мы сейчас ведём именно такой проект - крупный промышленный холдинг, несколько бизнес-единиц, исторически разрозненные данные. Задача: выстроить data mesh поверх отечественного стека без иностранных SaaS-каталогов и без единого централизованного хранилища, которое всех и замедляло.

Как устроена архитектура

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

Поверх этого - единый каталог данных. Мы взяли OpenMetadata (self-hosted, лицензия Apache 2.0), интегрировали с каждым ClickHouse-кластером через коннекторы и сделали из него точку входа: где что лежит, кто владелец, какие данные готовы к межменному потреблению.

Data contract - ключевое понятие в этой схеме. Каждый домен публикует не просто таблицы, а явные контракты: какие поля, какие типы, какой SLA обновления, какая гарантия качества. Контракт описывается в YAML, версионируется в git, регистрируется в каталоге. Потребитель подписывается на конкретную версию контракта и получает уведомление при breaking change.

Domain A (CRM)         Domain B (Production)      Domain C (Logistics)
  ClickHouse-A           ClickHouse-B               ClickHouse-C
  + data contracts       + data contracts            + data contracts
        |                       |                          |
        +-------------- OpenMetadata Catalog -------------+
                                |
                      Cross-domain consumers
                      (BI, ML, reporting)

Где ломается федерация

Вот где начинается настоящий разговор.

Первое - cross-domain запросы. ClickHouse умеет делать распределённые запросы через движок Distributed и remote-функции. Но это работает нормально, когда кластеры находятся в одной сети с предсказуемой задержкой. У нашего заказчика домены физически в разных ЦОД-ах (историческое наследие). Remote-запрос из кластера логистики в кластер CRM для join-а даёт latency, с которой BI-инструменты просто не справляются интерактивно. Решение, к которому мы пришли: для межденного потребления домен публикует не живую таблицу, а реплицированный «data product» - периодически обновляемую агрегированную копию для внешних потребителей. Живой федерации нет, зато есть предсказуемость.

Второе - governance без диктатора. В классическом монолитном DWH есть центральная команда, которая говорит «эта колонка называется так, этот тип вот такой, дедупликация по этому ключу». В data mesh этого человека нет по дизайну. У нас довольно быстро выяснилось, что два домена независимо завели сущность «клиент» с несовместимыми идентификаторами. Домен CRM использует внутренний UUID, домен биллинга - ИНН. Джойнить их сложно, и это не проблема инструментов - это организационная проблема, которую инструменты не решают.

Мы ввели уровень «federated governance»: небольшой совет из владельцев доменов, который собирается раз в две недели и согласует общие справочники и master-сущности. Без принуждения, но с явным реестром «что должно быть одинаковым». Работает с переменным успехом - зависит от того, насколько заняты участники.

Третье - observability данных. Когда у тебя один DWH, ты видишь всё в одном месте. Когда восемь кластеров - мониторинг качества данных надо строить отдельно. OpenMetadata умеет запускать data quality checks через своё UI, но интеграция с ClickHouse по части column-level lineage работает не идеально: lineage строится по SQL-запросам, которые OpenMetadata перехватывает через query log, и на сложных CTE иногда теряет часть рёбер графа. Мы дополнили это ручной разметкой критичных пайплайнов.

Четвёртое - версионирование контрактов на практике. В теории: вышла новая версия контракта, потребители получили уведомление, мигрировали. На практике: потребитель - это тоже команда со своим спринтом и бэклогом. Breaking change в контракте домена производства завис на две недели, потому что команда BI-отчётности была занята другим. Контракт v2 вышел, но отчёты работали на v1-таблицах, пока кто-то не заметил расхождение. Помогло бы автоматическое тестирование на стороне потребителя - сейчас это добавляем.

Что работает без оговорок

ClickHouse как база для domain-owned хранилища - хорошее решение. Команды разворачивают кластер через Helm-чарты, управляют самостоятельно, релизный цикл у каждого домена свой. После того как мы написали базовые runbook-и и настроили мониторинг через VictoriaMetrics, нагрузка на центральную инфра-команду по этим кластерам невысокая.

OpenMetadata как каталог - функционально достаточен, хотя UX в некоторых местах требует привыкания. Главное, что он self-hosted, поддерживает LDAP-аутентификацию и не тянет данные наружу - для заказчиков с требованиями по суверенитету данных это не опция, а требование.

Где мы сейчас

Два домена из восьми полностью перешли на data mesh модель с опубликованными контрактами. Остальные в процессе - у кого-то технический долг в пайплайнах, у кого-то просто нет ресурса сесть и описать контракт на существующие данные. Второе, по нашим наблюдениям, встречается чаще первого.

Data mesh - это больше про организацию, чем про инструменты. Инструменты мы подобрали достаточно быстро. Убедить команды взять на себя ответственность за качество данных - это отдельная работа, которая в проектный план не всегда помещается честно.

Если работаете с похожей задачей - распределёнными данными по нескольким доменам и нужен порядок без монолитного DWH - в рамках DWH/BI-проектов мы помогаем выстроить как архитектуру, так и governance-процессы вокруг неё.

Почему Harbor без политик - не защита

Harbor стоит у большинства наших клиентов уже несколько лет - его выбирали ещё когда GitLab Container Registry казался избыточным. Но стоит - не значит работает как защита. Типичная картина при аудите: образы пушатся, лежат, никто их не сканирует, политик блокировки нет. Это просто файловый сервер с красивым интерфейсом.

Harbor 2.x умеет встраивать Trivy как внутренний сканер - включается в настройках за несколько кликов. После включения каждый новый образ при пуше автоматически уходит на сканирование. Дальше настраивается политика: образы с критическими уязвимостями без доступного фикса блокируются при pull. Важный нюанс, который сначала вызывает вопросы у команд: образ попадает в реестр, но не становится доступным для pull, пока сканирование не завершилось. Первый раз это выглядит как баг. Надо объяснять заранее.

Для КИИ-контекста отдельно интересен режим сканирования на наличие вредоносных компонентов - Trivy проверяет базы Trivy Advisory DB и GHSA. Это не закрывает zero-day, но known-malicious компоненты из последних supply chain инцидентов ловит нормально. Мы проверяли на реальных кейсах из нашего мартовского разбора.

Gitflic CI: как интегрировали Cosign

С подписью образов через Cosign в Gitflic CI есть одна особенность, которую нужно учитывать: Gitflic не поддерживает OIDC keyless signing так же нативно, как GitLab через id_tokens (OIDC). Пришлось идти через классический вариант - пара ключей, ключ в CI-переменной.

Схема stage в пайплайне:

scan-image:
  stage: security
  image: registry.internal/devtools/trivy:0.52
  needs: [build]
  script:
    - trivy image
        --severity CRITICAL,HIGH
        --exit-code 1
        --ignore-unfixed
        ${HARBOR_HOST}/${CI_PROJECT_PATH}:${CI_COMMIT_SHA}
  only:
    - main
    - /^release\/.*/

sign-image:
  stage: security
  image: registry.internal/devtools/cosign:2.4
  needs: [scan-image]
  script:
    - echo "${COSIGN_PRIVATE_KEY}" | cosign sign --key /dev/stdin
        ${HARBOR_HOST}/${CI_PROJECT_PATH}:${CI_COMMIT_SHA}
  only:
    - main
    - /^release\/.*/

needs: [scan-image] здесь принципиален: подпись ставится только после успешного прохождения scan. Если Trivy вернул exit code 1 - sign-image не запустится, образ не будет подписан, и дальнейшие попытки задеплоить его в Kubernetes упрутся в Kyverno-политику.

Cosign хранит подписи в Harbor как OCI-артефакты рядом с образом - никакого отдельного хранилища не нужно. Harbor 2.x поддерживает это нативно.

Kyverno-политика закрывает последний рубеж: в namespace production и staging запрещены Pod-ы с образами без валидной Cosign-подписи от нашего internal CA. Dev-namespace намеренно оставляем без принудительной верификации - разработчики собирают образы локально, блокировать dev болезненно и контрпродуктивно.

Проблема legacy-образов без тегов

Это то, что неожиданно съело больше всего времени. У каждого клиента в Harbor накопился слой образов, которые пушились годами без нормальной политики тегирования: latest, безымянные слои от промежуточных сборок, артефакты полузабытых проектов. Trivy их не сканировал никогда.

Проблема в том, что часть этих образов всё ещё используется. Не активно, но используется - в batch-задачах, в legacy-скриптах деплоя, в cron-контейнерах, которые «всегда так работали». Тупо заблокировать их нельзя: завалишь какой-нибудь ночной процесс и узнаешь об этом утром от заказчика.

Мы выработали такой подход:

• Инвентаризация через Harbor API - скрипт обходит все репозитории, собирает образы старше 180 дней без тегов кроме latest, смотрит дату последнего pull. Образы, которые не тянули больше года, выносим в отдельный список «кандидаты на архив».
• Форсированное сканирование - для образов с активными pulls (даже раз в квартал) запускаем Trivy принудительно через Harbor API: POST /api/v2.0/repositories/{repo}/artifacts/{digest}/scan. Это не блокирует образ, но даёт нам отчёт по уязвимостям.
• Постепенная блокировка - образы с критическими CVE, которые реально тянутся в продакшн, выносим на отдельные переговоры с командой клиента: либо обновляете базовый образ, либо мы фиксируем это как accepted risk с обоснованием для аудитора ФСТЭК.

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

Что получается в итоге

Полный пайплайн для нового образа выглядит так: сборка - Trivy-скан (блокирующий для main/release) - Cosign-подпись - пуш в Harbor - Kyverno в Kubernetes. Образ, который не прошёл хотя бы одну ступень, до production не доберётся.

Для legacy-образов пока компромисс: сканируем принудительно, документируем риски, постепенно вытесняем самые проблемные. Полный закрытый контур - это процесс на несколько месяцев, а не спринт.

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

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

Инкрементальные чекпоинты: полгода спустя

В январе мы писали, что «зубья» на latency исчезли. Это подтверждается. Более того - на одном из контуров с очень интенсивной записью (несколько тысяч транзакций в секунду, смесь INSERT и UPDATE) эффект оказался ещё заметнее, чем казалось на трёхмесячном горизонте.

Интересное наблюдение: равномерность I/O дала вторичный эффект - стала лучше работать утилизация дискового кеша ОС. Раньше пики checkpoint-а буквально вымывали page cache, особенно на серверах с умеренным объёмом RAM. После перехода паттерн чтения стал предсказуемее, кеш-хиты подросли, и это заметно по pg_stat_bgwriter.buffers_clean - их стало меньше, что хороший знак.

Конфигурационная деталь, которую стоит проверить при апгрейде: если у вас был кастомный checkpoint_completion_target = 0.95 как обходной манёвр для сглаживания пиков - с инкрементальными чекпоинтами его можно снизить обратно к дефолтным 0.9 или даже к 0.8, поскольку само по себе сглаживание теперь встроено в механизм. Не обязательно, но даёт чуть больше агрессии при сбросе.

Async I/O и batch SELECT: цифры устаканились

На аналитическом профиле (batch SELECT по большим таблицам, отчётные джобы, ETL) прирост от io_method=io_uring стабилизировался в диапазоне 18-22%. Это соответствует тому, что мы ожидали по бенчмаркам, и за шесть месяцев не деградировал - что важно, поскольку первые пару месяцев всегда есть соблазн списать хороший результат на «эффект свежего кеша».

Ключевое условие, которое мы теперь документируем явно для каждого нового контура:

• io_method = io_uring работает только если ядро 6.1+ и io_uring не заблокирован через seccomp или cgroup. В контейнерах на некоторых платформах по умолчанию заблокирован - проверяйте.
• max_io_concurrency - на NVMe мы выставляем 48-64, на SAS-стойке оставляем дефолт. Выше не всегда лучше: при чрезмерном значении начинается конкуренция внутри io_uring-очереди, и прирост срезается.
• effective_io_concurrency - для аналитических запросов поднимаем до 256, для OLTP-контуров оставляем скромнее: там latency важнее throughput.

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

Вот это стало сюрпризом. На одном из контуров - внутренняя система документооборота, специфическая нагрузка - после перехода на PG18 начали замечать рост latency на отдельных запросах. Не на всех, и не сразу: через несколько недель после перехода.

Покопавшись, нашли причину. Нагрузка использует большое количество коротких курсоров: приложение открывает курсор, выбирает несколько строк, закрывает, открывает следующий - и так тысячи раз в секунду. В PG17 это работало нормально. В PG18 в этом паттерне проявилось нежелательное взаимодействие между логикой управления буферами async I/O и тем, как GID (global identifier) назначается в контексте незавершённых курсорных операций.

Точнее: при высокой частоте открытия/закрытия курсоров в условиях активного async I/O возникал contention на внутреннем локе при регистрации GID. Это не deadlock, но throughput на этом паттерне падал - на нашей нагрузке примерно на 15-20% относительно PG17.

Решение нашлось через ALTER SYSTEM. Конкретно помогло:

ALTER SYSTEM SET io_method = 'worker';
ALTER SYSTEM SET max_io_concurrency = 16;
SELECT pg_reload_conf();

То есть откат к модели worker для этого конкретного инстанса, без перезапуска. GID-contention исчез, latency вернулась к норме. Потеря в throughput на batch SELECT - да, есть, около 8-10%. Но на этом контуре batch SELECT нет, и компромисс оказался приемлемым.

Важный вывод: ALTER SYSTEM без перезапуска - это не только удобство, это операционная страховка. На PG17 для изменения io_method требовался рестарт; на PG18 ряд параметров, включая этот, перегружается через pg_reload_conf(). Это реальная разница при инциденте в боевом контуре.

Общее ощущение через полгода

PG18 в продакшне - это не «обновился и забыл». Это версия, которая даёт ощутимые выигрыши на нагрузках с I/O-давлением, но требует понимания, что именно она делает иначе. Инкрементальные чекпоинты и async I/O - это не просто «быстрее», это другая модель взаимодействия с железом и ОС.

Регресс на курсорной нагрузке неприятный, но обходимый. И хорошо, что инструментарий для обхода - ALTER SYSTEM плюс pg_reload_conf() - есть без перезапуска. На системах, где рестарт СУБД это событие с согласованием, это принципиально.

Параллельно идёт процесс сертификации Postgres Pro 18 Enterprise через ФСТЭК - об этом писали в апреле. Для КИИ-контуров это всё ещё ограничение: функциональность есть, регуляторного зазора нет. Там остаёмся на сертифицированных версиях и ждём.

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

Что показывает статистика

Согласно публикации, 73% всех выявленных нарушений относятся к двум кластерам: организация мониторинга и реагирование на инциденты. Технические средства защиты - сертифицированные МЭ, антивирусы, системы обнаружения вторжений - дают оставшиеся 27%.

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

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

Что конкретно нарушают

Из описания в документе можно восстановить типовые картины. ФСТЭК не называет объекты, но группирует нарушения по признакам.

Неполное покрытие источников событий. Промышленные контроллеры, SCADA-системы, специализированное оборудование АСУТП - туда SIEM зачастую не дотягивается. Причины стандартные: нет стандартного интерфейса экспорта, производитель не поддерживает syslog, интеграция требует доработки под конкретную модель. В январских методрекомендациях регулятор сделал оговорку про компенсирующие меры для такого оборудования - но компенсация должна быть задокументирована, иначе это нарушение.

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

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

Передача в ГосСОПКА не в реальном времени. Пакетный режим вместо потокового - нарушение для первой категории. Многие объекты настроили интеграцию давно, в пакетном режиме, и не переводили. Теперь это видно в проверках.

Почему технические средства дают только 27%

Отчасти это хорошая новость: отрасль в целом освоила базовый набор сертифицированных решений. Сертифицированный МЭ, антивирус, СЗИ НСД - это уже не редкость. Плохая новость в том, что технические средства сами по себе не работают без процессов вокруг них.

Это то, с чем мы сталкиваемся на практике регулярно. Заказчик потратил серьёзные деньги на SIEM, выстроил архитектуру сбора событий - а потом оказывается, что три сегмента ОТ не подключены, потому что «там сложный вендор, разберёмся потом». Или правила корреляции не обновлялись два года. Или дежурный аналитик SOC физически не успевает разбирать алерты, и они просто накапливаются.

Регулятор, похоже, это понял раньше многих объектов.

Что это значит для наших проектов

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

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

Второе: непрерывность мониторинга - это метрика, которую надо мерить. Если SIEM не получал событий от источника дольше N часов, это должен быть алерт, а не открытие при следующей проверке.

Третье: документ по реагированию на инциденты - это не формальность для папки. Инспектор будет спрашивать, как вы применяли его в последние полгода. Журнал разборов, служебные записки по аномалиям - вот что делает документ живым.

Четвёртое: передача в ГосСОПКА в реальном времени - для первой категории это теперь стандартный пункт в предписании, если не сделано. Лучше разобраться с сетевыми ограничениями до проверки, чем объяснять инспектору, почему пакетный режим.

Публикация ФСТЭК хороша тем, что даёт системный срез, а не просто впечатления от конкретных объектов. Цифра 73% - достаточно весомый аргумент для внутреннего разговора о приоритетах, когда бюджет ограничен, а купить ещё один сертифицированный продукт проще, чем выстроить процесс.

Кого это касается

Граница проходит не по размеру организации, а по архитектуре подключения. Если организация:

• имеет собственный автономный номер (ASN) и анонсирует свои префиксы в BGP;
• подключена к нескольким транзитным провайдерам напрямую, минуя единую точку обмена трафиком под ТСПУ;
• эксплуатирует точку обмена трафиком или IX-подключение на своей стороне.

...то формально попадает в категорию, для которой требования об установке средств фильтрации и мониторинга теперь распространяются напрямую.

Большинство средних компаний, которые подключены через одного-двух интернет-провайдеров в пассивном режиме, под требования не попадают - трафик проходит через ТСПУ провайдера. Но среди наших managed-клиентов несколько организаций имеют именно такую «продвинутую» топологию - их кто-то когда-то убедил взять собственный ASN ради независимости от провайдера.

Что конкретно меняется

Практика пока складывается неравномерно. По нашим наблюдениям - и по тому, что слышим от коллег - технические требования к оборудованию на стыке с интернетом такие:

• Место установки. ТСПУ должно стоять на всех точках подключения к сетям связи общего пользования. Если у организации два аплинка от разных провайдеров - на каждом.
• Управление. Оборудование должно принимать сигналы управления от Роскомнадзора в автоматическом режиме. Это означает наличие отдельного управляющего интерфейса и стабильного канала до систем РКН.
• Логирование. Журналы трафика через ТСПУ - отдельный болезненный вопрос по срокам хранения и доступу.

Что происходит с VPN-туннелями до облаков

Здесь самое интересное с операционной точки зрения. У нескольких клиентов инфраструктура частично размещена в отечественных IaaS-облаках, и связность между корпоративной сетью и облаком организована через IPsec или WireGuard поверх интернета.

ТСПУ - это DPI-оборудование. Оно инспектирует трафик. IPsec в туннельном режиме непрозрачен для DPI - с точки зрения фильтра это зашифрованный поток между двумя точками. На практике это порождает несколько сценариев:

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

Использование VPN-продуктов из стоп-листа. Ряд VPN-решений, особенно западных вендоров, уже попал или может попасть под ограничения. Если организация использует такой продукт для связи с облаком - придётся мигрировать на альтернативу. На практике для корпоративных IPsec-туннелей это решается заменой клиентского ПО на сертифицированные отечественные аналоги или на нативные средства операционной системы.

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

Для туннелей до облаков мы рекомендуем переходить на прямое L3-подключение к облачному провайдеру там, где это доступно, - минуя публичный интернет. Это снимает вопрос и с ТСПУ, и с DPI, и заодно даёт более предсказуемую производительность.

Конфигурация пограничных маршрутизаторов

На нескольких проектах нам пришлось пересматривать конфигурацию BGP-сессий на пограничных маршрутизаторах. Несколько практических наблюдений:

• Анонсы и фильтрация. ТСПУ стоит между маршрутизатором и провайдером - это влияет на видимость управляющего канала. Нужно явно проверить, что out-of-band управление маршрутизатором не зависит от туннелей, которые могут быть прерваны при применении правил фильтрации.
• Failover-логика. Если ТСПУ выходит из строя или применяет некорректное правило, трафик может упасть. Схему failover стоит протестировать отдельно - убедиться, что secondary-аплинк действительно подхватывает нагрузку.
• Документация топологии. На аудитах ФСТЭК, которые мы сопровождали в марте, инспекторы фиксировали замечания за несоответствие схемы реальной топологии. С ТСПУ ситуация аналогичная: оборудование появляется в схеме, его нужно отразить в документации и включить в процесс управления изменениями.

Где сейчас неопределённость

Честно: нормативная база ещё не устоялась. Разъяснения РКН выходят неравномерно, правоприменительная практика по корпоративным сетям только формируется. Мы видим расхождения между тем, что написано в письмах регулятора, и тем, что реально требуют при проверках.

Наша текущая рекомендация клиентам с собственными ASN: инициировать консультацию с РКН для уточнения применимости требований именно к вашей топологии, не ждать проверки. Это не гарантирует отсутствия замечаний, но фиксирует добросовестную позицию организации. И параллельно - провести аудит всех VPN-продуктов на пограничных устройствах: что из этого из ограниченного списка, что нет.

История с ТСПУ для корпоративных сетей ещё не дописана - это точно не финальная версия требований.

Три задачи, три разных паттерна, три разных итога.

Задача первая: incident triage

Это наш RCA-агент поверх Zabbix + Loki. Алерт прилетел - агент собирает контекст, строит гипотезу, пишет дежурному.

Мы начинали с ReAct (Reasoning + Acting): агент шаг за шагом рассуждает, решает, какой инструмент вызвать, смотрит на результат, продолжает. Выглядело логично - инцидент непредсказуем, жёсткий план не поможет.

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

Мы зафиксировали максимум 3 итерации и добавили явный «план» на старте: сначала Loki за последние 15 минут, потом Zabbix за метриками, потом синтез. Это уже ближе к Plan-and-Execute, чем к чистому ReAct. Агент стал предсказуемым и дешевле. Качество диагностики при этом не упало - скорее чуть выросло, потому что порядок сбора контекста стал осмысленным.

Вывод по incident triage: ReAct хорош теоретически, но в инциденте, где есть шум и ложные корреляции, нужны ограничения. Облегчённый Plan-and-Execute с фиксированным порядком инструментов и потолком итераций работает лучше.

Задача вторая: knowledge retrieval

У другого клиента - корпоративный ассистент по базе знаний: несколько тысяч страниц в Confluence, разработчики задают вопросы на русском, агент отвечает с цитатами.

Здесь мы с самого начала попробовали простую цепочку без агентной оркестрации: пользователь -> embeddings-поиск -> reranker -> LLM. Сработало на базовых запросах. Но посыпалось на составных: «покажи, как настроить nginx для нашего кластера и какие ограничения в политике ИБ для внешних портов». Это два поиска, результаты которых нужно свести вместе.

Multi-agent здесь дал правильное разделение: оркестратор принимает запрос, декомпозирует на подзадачи, каждую отдаёт агенту-специалисту (search-agent для KB, policy-agent для ИБ-документов), потом синтезирует ответы. Каждый агент маленький и предсказуемый, оркестратор не лезет в детали поиска.

Грабля, на которую мы наступили: оркестратор иногда дробит запрос на слишком мелкие подзадачи. Вопрос «как перезапустить сервис» превращается в три параллельных поиска, каждый из которых находит одно и то же. Пришлось добавить классификатор на входе: простой запрос идёт прямо в search-agent, минуя декомпозицию. Это не самое элегантное решение, но работает.

Вывод по knowledge retrieval: multi-agent даёт ценность именно на составных запросах с разными источниками данных. На простых запросах оркестрация - лишний оверхед и лишние токены. Классификатор сложности запроса на входе обязателен.

Задача третья: конфигурационный аудит

Периодическая задача: обойти инфраструктуру клиента, собрать конфиги, проверить на соответствие baseline-у, сформировать отчёт. Это не интерактив - это батч с детерминированным результатом.

ReAct здесь даже не рассматривали: задача хорошо декомпозируется заранее. Plan-and-Execute в чистом виде - составить план обхода, потом выполнить каждый шаг - подходит идеально.

Агент-планировщик принимает список хостов и категорий проверок, строит граф задач. Агент-исполнитель проходит по задачам, вызывает инструменты (SSH, API Ansible, запросы к инвентарю), собирает результаты. Агент-синтезатор сводит результаты в читаемый отчёт.

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

Вывод по конфигурационному аудиту: Plan-and-Execute для батчевых задач с детерминированной структурой - просто правильный выбор. Персистентный граф задач с восстановлением после сбоев делает задачу надёжной без сложной логики в промпте.

Что общего между тремя случаями

Если смотреть поперёк задач, видны два фактора выбора паттерна.

Первый - предсказуемость структуры задачи. Если структура известна заранее (аудит, батч, отчёт) - Plan-and-Execute. Если структура зависит от того, что агент найдёт по пути (инцидент, исследование) - ReAct, но с ограничениями. Если задача композитная и хорошо делится на независимые части - multi-agent.

Второй - стоимость ошибки. ReAct в инциденте ошибается дорого: петля из пяти итераций в два часа ночи задерживает ответ. Plan-and-Execute ошибается дешевле: провалил шаг - перезапустил шаг. Multi-agent ошибается предсказуемо: если упал один агент-специалист, оркестратор это видит.

Отдельное наблюдение по мониторингу агентов: без трейсов на уровне span-ов мы бы не увидели, что ReAct на incident triage делает лишние круги. Число итераций на запрос - метрика, которую теперь смотрим отдельно для каждого агента.

Где мы сейчас

Ни один из трёх паттернов не стал «дефолтным» для всех задач. Это раздражает, потому что хочется единого шаблона, но практика показывает: паттерн - следствие структуры задачи, а не предпочтение архитектора.

Одна вещь, которую мы планируем проверить в ближайших спринтах: гибридный оркестратор, который начинает как Plan-and-Execute, но позволяет агенту-исполнителю отклоняться от плана при неожиданных находках. По ощущениям, это могло бы закрыть пробел между incident triage и аудитом. По факту - пока не знаем.

Что прижилось

VictoriaMetrics как хранилище метрик. Здесь без оговорок - работает. Сжатие лучше Prometheus-а, single-node держит нагрузку, которую раньше тянул только Prometheus в федерации. Cluster-режим подняли на двух проектах с особенно активными сервисами - там это оправдано. На остальных single-node и не думает потеть. Удобная вещь - vmbackup/vmrestore: бэкапы и восстановление без танцев с iptables и снапшотами.

Grafana как единый фронт. Три источника данных в одном дашборде - VictoriaMetrics, Loki, Tempo - это то, ради чего весь стек вообще имеет смысл. Когда дежурный видит spike latency на графике и кликом открывает связанные логи за тот же интервал - это реальное ускорение диагностики, а не демо с конференции. Grafana On-Premise держится стабильно, обновления выходят регулярно, ничего принципиально сломанного в последних версиях не попадалось.

Loki для логов. С оговорками, но в целом - да, прижился. Модель «только индекс по лейблам, остальное в объекте» работает при правильных лейблах. Если лейблы сделаны плохо - и запросы медленные, и объём индекса раздутый. Мы набили шишки на первых инсталляциях: лейбл pod_name с уникальными значениями на каждый под - почти то же самое, что вообще без индекса. Переделали на namespace, app, component - стало нормально.

Где всё ещё больно

Alertmanager-маршрутизация - самое больное место. Логика маршрутизации в yaml-конфиге Alertmanager устроена так, что при попытке описать нетривиальные правила («этот алерт - в дежурный канал, но только ночью и только если severity=critical, а если днём - просто в общий чат») быстро получается нечитаемая матрёшка из routes, matchers и continue: true. Мы сделали несколько итераций, написали внутреннюю документацию с примерами - помогло, но каждый новый человек в команде всё равно спотыкается об это место.

Cardinality под нагрузкой. VictoriaMetrics справляется лучше Prometheus-а, но высокая cardinality метрик всё равно бьёт по памяти. На одном проекте разработчики добавили в метрики лейбл user_id - и мы получили несколько миллионов уникальных time series за сутки. VictoriaMetrics не упала, но потребление памяти выросло неприятно. Пришлось добавить в процесс code review отдельный чеклист на лейблы метрик. Это организационная проблема, не техническая, но она реальна.

Loki и долгосрочное хранение. Loki хранит данные хорошо, пока объём умеренный. Когда логов много и retention длинный - появляются вопросы к стоимости хранения и скорости compaction. На двух проектах с compliance-требованиями, где логи надо хранить год, мы пришли к тому, что Loki держит горячий период (30-60 дней), а холодный архив идёт в object storage через конфигурацию storage и compactor. Работает, но настройка не тривиальная.

Отсутствие нормальной RBAC в Grafana на уровне дашбордов. Enterprise-функции Grafana с fine-grained permissions нам недоступны - клиенты не хотят платить за подписку поверх On-Premise. Дефолтная ролевая модель Grafana грубая: либо viewer для всего, либо editor почти для всего. Для клиентов, где разные команды должны видеть только свои namespace-ы, мы используем Organizations - несколько изолированных «организаций» внутри одного Grafana. Работает, но это костыль, и поддерживать одинаковые дашборды в нескольких Organizations - боль.

Почему не SaaS

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

Ответ несложный. Во-первых, у большинства наших клиентов данные в метриках и логах - чувствительная информация: имена хостов, внутренние адреса, параметры запросов, иногда персональные данные в трейсах. Отправлять это в иностранный SaaS - не вариант, это не про паранойю, а про compliance. Отечественных SaaS-мониторингов с нормальным Prometheus-совместимым API и Loki-совместимым приёмником пока нет в том виде, который нас устроил бы.

Во-вторых, операционная нагрузка на поддержку стека оказалась меньше, чем мы ожидали. VictoriaMetrics не требует постоянного ухода. Grafana обновляется раз в несколько месяцев. Основная работа - это именно настройка дашбордов, алертов и разбор проблем с cardinality. Это осмысленная работа, а не просто «держи инфраструктуру живой».

Что с Zabbix

Zabbix мы не выкинули. На нескольких проектах он остался как основной источник алертов по инфраструктурным метрикам - хост недоступен, диск заканчивается, процесс упал. Zabbix 8 с встроенным anomaly detection выглядит как шаг вперёд, но мы пока смотрим на это осторожно: anomaly detection хорошо работает на предсказуемых паттернах, а на нагрузке с большой дисперсией даёт ложные срабатывания. Будем тестировать.

Для нас Zabbix и VictoriaMetrics/Grafana - не конкуренты. Zabbix хорош для агентного мониторинга хостов, network devices, windows-серверов с нестандартными метриками. VictoriaMetrics + Grafana - для cloud-native сервисов, где метрики отдаются через /metrics endpoint. На большинстве проектов оба стека работают параллельно, и дежурный смотрит в Grafana, потому что там всё в одном месте.

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

Контекст: мы используем оба дистрибутива у разных заказчиков. РЕД ОС чаще идёт на серверные роли в смешанных инфраструктурах, Astra Linux SE - там где нужна сертификация по классу защищённости или есть требование к мандатному управлению. Иногда выбор ОС диктуется не нами, а закупкой или политикой. Так что сравнение честное - не «какую купить», а «что учесть при работе с каждой».

Стенд и нагрузка

Две идентичные ВМ на одном гипервизоре: 8 vCPU, 32 ГБ RAM, NVMe-том. Одна - РЕД ОС 9.2 с минимальной установкой плюс docker и podman из штатного репозитория. Вторая - Astra Linux SE 2.15, тот же набор пакетов, Parsec в режиме enforcing.

Нагрузка состоит из трёх частей: запуск набора контейнерных сервисов через Compose, применение набора Ansible-плейбуков из нашей общей коллекции, и синтетический тест IO на NVMe с параллельными потоками. Ничего экзотического - это то, с чем мы работаем каждый день.

Контейнеры: разный стартовый уровень

РЕД ОС 9.2 обновила podman до актуального патча-релиза пятой ветки - то, что мы разбирали после 9.1 в февральском посте. Compose-манифесты запустились без изменений, crun работает штатно, rootless-режим ведёт себя предсказуемо. В 9.2 появилась более свежая версия buildah, что важно для тех, кто собирает образы прямо на серверах без отдельного CI.

У Astra Linux SE 2.15 ситуация другая. Docker здесь присутствует, но его взаимодействие с Parsec по-прежнему требует внимания. При запуске контейнера с bind-mount на каталог с ненулевым мандатным уровнем получаем AVC-отказ - поведение знакомое по 2.14, мы его касались в январском обзоре. В 2.15 добавили документированный механизм маппинга мандатных меток для контейнеров, что технически правильно, но настройка занимает время. Из восьми сервисов в нашем Compose-наборе шесть запустились без правок. Два потребовали явного задания контекста через переменные окружения и метки в юнит-файлах.

Для задач, где контейнеры работают без пересечения с мандатной иерархией - например, полностью изолированные сервисы без монтирований в защищённые каталоги - Astra Linux SE 2.15 работает нормально. Но как только появляется интеграция с файловой системой хоста и Parsec включён, нужно планировать время на настройку.

Ansible: где коллекции работают, а где нет

Мы гоняли один набор плейбуков из нашей коллекции для управления серверами: конфигурация sshd, управление пользователями, деплой systemd-юнитов, настройка logrotate и базовый hardening. Все плейбуки работают через community.general и ansible.posix без вендорских модулей.

На РЕД ОС 9.2 всё прошло без единой ошибки. Это RHEL-производная с предсказуемым расположением конфигурационных файлов и стандартным поведением systemd - Ansible с такими системами дружит давно.

На Astra Linux SE 2.15 плейбуки выполнились, но с нюансами. Задачи, работающие с файлами через copy и template, в нескольких случаях получили неожиданное поведение из-за Parsec: файл записывался, но с не той меткой, и последующий сервис его не видел. Проявляется это не ярко - задача завершается как changed, ошибок нет, а сервис потом не может прочитать конфиг. Диагностируется через pdp-ls на целевых файлах.

Решение - либо явно задавать метки через pdp-chml в отдельной задаче после copy/template, либо убедиться, что плейбук запускается в контексте с нужным уровнем. Второй вариант чище, но требует доработки плейбуков под конкретную Astra-среду. Для нашей общей коллекции мы добавили Astra-специфичные задачи в отдельный опциональный тег parsec_labels - применяем только там, где он нужен.

Несколько модулей из ansible.posix работали не совсем корректно с SELinux-контекстами на Astra - там собственная подсистема, и часть модулей, ориентированных на стандартный SELinux, читает типы контекстов иначе. Не блокирует, но надо держать в голове.

Поддержка железа: обновление ядра

РЕД ОС 9.2 поставляется с обновлённым ядром из 6.6 LTS, в котором закрыт ряд проблем с драйверами RAID-контроллеров и NVMe на новых чипсетах. На нашем тестовом стенде разница не была видна - железо стандартное. Но у одного из заказчиков с недавно поставленными серверами на Elbrus-compatible шине эта деталь принципиальна: на 9.1 у них были прерывистые таймауты IO, на 9.2 - нет.

Astra Linux SE 2.15 тоже обновила ядро - до 6.6 LTS, что выравнивает ситуацию с железом. Это закономерно: обе ОС сейчас идут на одном ядерном треке, и hardware-совместимость у них примерно одинакова. Исключение - драйверы, специфичные для конкретных российских производителей: здесь у каждого вендора своя история, и лучше проверять по конкретной модели, а не полагаться на общую логику.

Где что уместно

После этого сравнения наш практический вывод простой.

РЕД ОС 9.2 - дистрибутив, с которым стандартный серверный инструментарий работает без сюрпризов. Если вы управляете серверами через Ansible с обычными коллекциями, используете контейнеры в rootless-режиме, и вам не нужен мандатный контроль доступа - это предсказуемая, хорошо управляемая RHEL-подобная система.

Astra Linux SE 2.15 - правильный выбор там, где сертификация и мандатный контроль доступа не опция, а требование. Parsec работает, его можно настроить под контейнеры и Ansible - но это отдельная работа, которую нужно закладывать в оценку проекта. На объектах КИИ с требованиями ФСТЭК к классу защищённости выбор в пользу Astra часто не технический, а регуляторный.

Обе ОС получили в мае обновления, которые актуальны - свежее ядро, закрытые CVE, исправленные пакеты. Это хорошо. Но при выборе между ними стоит честно ответить на вопрос: есть ли у вас требование к мандатному контролю, или вы берёте Astra «на всякий случай»? Во втором случае дополнительная сложность не добавляет безопасности - только работы.

Для нас это прямой повод провести gap-анализ: что из новых угроз БДУ уже закрыто у наших клиентов, что закрыто частично, а где дыра. Записываем, что нашли.

Что именно добавили

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

Первый - угроза перехвата управления LLM-агентом (формулировка в реестре звучит примерно как «угроза навязывания недоверенных инструкций автономному агенту через обрабатываемые данные»). Это та же механика, которую мы разбирали в марте при threat model хелпдеск-агента: вредоносные инструкции в пользовательском вводе или во внешних данных, которые агент обрабатывает как часть контекста. Теперь этому вектору есть идентификатор в БДУ, что значит: при аудите КИИ-объекта с LLM-агентами аудитор формально обязан его проверить.

Второй - угроза подмены зависимостей через неоднозначность имён пакетов в корпоративных репозиториях (dependency confusion). Здесь акцент именно на отечественных репозиториях: Nexus с зеркалами Гит-репозиториев отечественного ПО, GitFlic Packages, внутренние PyPI-зеркала. Вектор известен с 2021 года на международной сцене, но в БДУ он долго не попадал - видимо, регулятор считал его «западной» проблемой. Теперь нет: несколько публичных инцидентов с российскими внутренними реестрами в 2025-2026 годах изменили позицию.

Gap-анализ: что есть, чего нет

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

По agent hijacking:

• OPA-guardrails или аналогичный policy layer - есть у двух клиентов из пяти. Это те, где мы сами выстраивали защиту агентов после прошлогодних инцидентов.
• Изоляция пользовательского ввода от системного промпта - сделана везде, но с разным качеством. У одного клиента «изоляция» - это просто префикс «User said:» перед вводом. Это не изоляция, это декорация.
• Логирование попыток tool-call с отклонением - есть у одного клиента из пяти. Остальные логируют только успешные вызовы.
• Документированный threat model агента - нет ни у кого, кроме проекта, который мы разбирали в марте.

По dependency confusion:

• Явный приоритет внутреннего репозитория над публичным в настройках pip/npm/maven - есть у трёх клиентов из четырёх, у которых мы смотрели конфиги. Но у одного из трёх настройка есть только в CI-пайплайне; на developer-машинах - нет, и разработчики ставят пакеты с дефолтными настройками.
• Проверка на подозрительные совпадения имён при добавлении новой зависимости - нет нигде. Это ручной процесс, который никто не делает систематически.
• SBOM с фиксацией источника каждого пакета (не просто имя и версия, но и откуда скачан) - есть у двух клиентов, которые уже перестроились под требования ФСТЭК к SBOM.

Что делаем

На основе gap-анализа формируем план по двум трекам.

Трек агентской безопасности. Для каждого клиента с LLM-агентом в продакшне - провести threat model по обновлённому чеклисту, который теперь явно включает новый идентификатор БДУ. Формат: рабочая сессия с командой, два-три часа, результат - список tool-call политик и приоритетный backlog по их реализации. Там, где агент использует сторонние инструменты (почта, JIRA, AD), первым делом идёт жёсткая фиксация допустимых параметров на уровне policy, а не надежда на то, что модель «сама не согласится» на вредоносный вызов.

Трек supply chain. Здесь работа разбивается на три шага: проверка конфигов менеджеров пакетов на всех окружениях (включая developer-машины, не только CI), проверка что внутренний репозиторий явно объявлен как единственный источник для внутренних имён пакетов, и добавление проверки источника в SBOM-пайплайн. По последнему пункту - у Syft есть поддержка метаданных об источнике в формате CycloneDX, это не требует смены инструмента, только конфигурирования.

Полного закрытия этих векторов за один спринт не выйдет - особенно там, где нет ни OPA, ни нормального threat model. Но приоритизировать работу теперь проще: БДУ ФСТЭК - это прямой аргумент в разговоре с CISO о том, почему это нужно делать не «когда-нибудь», а в ближайший квартал.

Если у вас в инфраструктуре есть LLM-агенты или внутренние репозитории с отечественным ПО - разобраться с gap-анализом под новые угрозы БДУ можно в рамках аудита.