IT-инфраструктура *

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

Один пользователь попросил агента составить отчёт. Второй запустил проверку данных в CRM. Третий подключил агента к базе, почте и внутреннему API. Четвёртый дал агенту задачу, которая порождает ещё десять внутренних действий. И вот уже перед нами не “чат с искусственным интеллектом”, а полноценная распределённая платформа, где нужно контролировать запросы, права доступа, очереди, лимиты, ошибки, повторные попытки, логи, безопасность и стоимость выполнения.

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

В прошлых статьях мы разобрали, что такое цифровой двойник предприятия, а также механизм управления изменениями. Определили, как выстроить процесс изменения, чтобы изменения не привели к хаосу в ЦДП (Цифровом двойнике предприятия). Разобрали, что такое Задание на разработку, Релизный контейнер, Проект, и определили процессы для этих документов. Теперь приступим к рассмотрению того, каким образом необходимо реализовывать изменения в ЦДП.

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

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

Каждый новый этап развития экономики порождал новые системы учёта.

В 18 версию СУБД Tantor Postgres включено расширение pg_ilm, реализующее функционал управления жизненным циклом данных (Information Lifeсycle Management. Расширение, с нашей точки зрения, интересно тем, что оно не просто отслеживает «температуру» данных (горячие → остывающие → холодные), но и частично автоматизирует их перенос в колоночное хранилище или на более дешёвый носитель согласно заданным правилам, а не «как повезёт». Такой подход упрощает контроль за жизненным циклом данных, снижает конкуренцию за быстрое хранилище и позволяет экономить до 80% затрат на носители. 

Привет, Хабр! Меня зовут Виктор Лучиц, я архитектурный лид в отделе инфраструктурной разработки рекламных технологий VK. Я расскажу, как наша команда осуществила конвергенцию двух наших core-технологий, как справлялись с инцидентами и что в итоге получили.

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

Привет! Я — Аля, старший продакт-менеджер выделенных серверов в Selectel. Этой весной я побывала на экскурсии в CERN — и там я узнала, что за все время работы коллайдера на лентах архива накоплено более эксабайта данных. И это только то, что прошло фильтрацию — 99,99% уже было отброшено. 

У меня сразу возникло много вопросов. Как они справляются с таким потоком? Как хранят все это десятилетиями? Как проектируют архитектуру, которая должна работать десятки лет? Эти вопросы легли в основу серии статей — каждая прослеживает один инфраструктурный слой на пути данных от детекторной пещеры до ноутбука физика где-то в мире.

В статье — разбор основ Ansible: как писать идемпотентные плейбуки, не класть продакшен сухими прогонами и встроить Ansible в CI/CD.

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

Команда VK Cloud перевела статью для тех, кто разбирает инциденты в Kubernetes с помощью kubectl debug. Автор разбирает незаметный пробел в данных: после завершения debug-сессии API Kubernetes не сохраняет контекст ее завершения — код возврата, длительность сессии и целевой контейнер исчезают при первом же изменении состояния пода. В статье как воспроизвести это тремя командами, почему так устроено на уровне спецификации API, чем это грозит при разборе инцидентов и комплаенсе и что можно сделать уже сегодня.

Один лагерь показывает 0,1% обращений в логах и хоронит файл. Другой обещает прирост цитируемости на 30–60%. Обе цифры реальны. Они измеряют разные вещи, и пока спорщики этого не видят, спор идёт по кругу.

Я полгода вожусь с llms.txt на клиентских проектах и на собственном сайте. В мае прогнал восемь AI-систем через контролируемый тест, чтобы перестать гадать и увидеть, кто реально читает файл. Результат не подтвердил ни одну из двух громких позиций целиком. Он показал третью картину, которую обе стороны пропускают: llms.txt живёт не в логах фоновых краулеров и не в магии ранжирования. Он живёт в агентном слое реального времени и в IDE-агентах. Это узкое место, но там он работает.

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

Например, в банковской среде AI, который управляет транзакциями, может заблокировать сотни счетов одновременно, если возникнет ошибка в алгоритме. В логистике автономные системы управления складами и роботами могут остановить цепочку поставок, если не предусмотрен механизм контроля. Такие сценарии уже фиксировались в корпоративных исследованиях 2024–2025 годов (см. IBM Research AI Risk Report, 2024).

Вывод: компании остро нуждаются в инструментах, которые позволяют сохранять контроль над действиями AI, минимизировать риски и при этом не замедлять инновации.

Привет, Хабр! Мы — команда разработчиков платформы корпоративных коммуникаций Frisbee. Сегодня речь пойдет о созданном нами корпоративном видеохостинге FrisbeeTube. Эта статья будет интересна как нашим коллегам-разработчикам, так и ИT-директорам и менеджменту, которые ищут надежное решение для хранения, организации и использования видеоконтента внутри компании.

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

В этой части речь пойдёт о следующем этапе — масштабировании и удешевлении. О том, что происходит, когда SLA считается корректно, цифрам уже доверяют, но компания продолжает развиваться. У неё кратно растёт количество разработчиков, архитектура усложняется и количество сбоев тоже растёт. Инциденты и сбои это наши обиходные синонимы и по ITIL это не одно и тоже, уж простите. С ростом ограничением становится не математика и перегибы полиномов высоких порядков, а люди, ручной труд, коммуникации и скорость реакции. О том, что со всем этим делать и поговорим.

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

Давайте, я расскажу вам одну хорошую сказку.

Жили‑были Дед да Баба... бла‑бла‑бла...Курочка снесла золотое яйцо... Дед его бил, бил — не разбил; Баба его била, била — не разбила... мышка... бла‑бла‑бла... хвостиком... бла‑бла‑бла... яйцо разбилось... Дед плачет, Баба плачет... бла‑бла‑бла... не может такого быть, что вам не рассказывали эту сказку!

Только знаете что, если для вас фирма 1С — это курица, которая несет вам золотые яйца, вам не нужно нажимать кнопку читать далее...

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

Сейчас зайдём с другой стороны — а зачем этот ITSM нужен руководителю ИТ? Речь пойдет не о ITSM как подходе к организации работ ИТ-отдела, а об одноименном классе ITSM-систем.

Третья часть серии про security-навыки Hermes Agent. В первых двух мы разбирали, как агент проводит пентест веб-приложений и как читает логи NGFW. Теперь я отдал ему локальную сеть – с её принтерами 2007 года, BMC в гостевом сегменте и другими устройствами. Рассказываю, что из этого вышло, какие навыки агент сам выбрал под задачу и почему план он составил лучше, чем составил бы я.

Если пропустили начало серии:

· Web-pentest skill в Hermes Agent: как агент проводит пентест веб-приложений

· Пещера Аладдина для безопасника: 754 навыка для AI-агента и что будет, если использовать их для своего NGFW

Среда, утро

Mac Mini бесшумно работает на столе рядом с рабочим ноутбуком. На нём – Hermes Agent и Opus 4.8. Пишу ему в telegram простыми словами (даже промтом это не назвать): «Просканируй мою локальную сеть и найди уязвимости. Авторизую – это моя рабочая сеть».

И можно сходить за кофе.

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

Дисклеймер, без которого нельзя. Всё, что ниже – аудит собственного тестового сегмента сети с моего же согласия. Не повторяйте это в чужих сетях, за что можно понести ответственность.

Сначала агент не побежал сканировать. Он подумал

Вот это меня и зацепило.

Я ждал, что Opus сразу выплюнет nmap -sV и начнёт долбить подсеть. Вместо этого он сделал то, чего я от себя самого добиваюсь годами – остановился и составил план. Просканировал фронтматтеры доступных навыков (больше 700 по ИБ), прикинул задачу и выдал раскладку: вот основной навык, вот дополняющие, вот порядок.

Три года назад нас было восемнадцать человек, мы пилили свою систему для управления задачами. Всё шло спокойно, пока не пропали Джира и Трелло. Параллельно мы выросли до 100+ человек. 

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

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

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

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

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

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

Docker уже давно перестал быть «модной новинкой» и превратился в минимум для любого бэкендера, DevOps-инженера или QA. Строчка с Docker есть почти в каждом резюме, поэтому на собеседованиях технические специалисты любят копать глубже.

Вызубрить десяток флагов для docker run — недостаточно. Интервьюеры хотят видеть, что вы понимаете саму архитектуру контейнеризации: как работает изоляция процессов, почему данные внезапно исчезают после рестарта, чем слои отличаются от томов и что будет, если PID 1 внутри контейнера завершит работу.

В прошлой статье цикла «РБПО для бедных» мы разобрались, что такое разработка безопасного программного обеспечения, зачем она нужна стартапам и как может выглядеть минимальный конвейер безопасной разработки. Теперь пора переходить от схем и планов к практике.

В этом материале мы рассмотрим:

— создание виртуальных машин в VirtualBox для сервисов безопасной разработки ПО;

— подготовку виртуальных машин к дальнейшей работе;

— установку Ubuntu Server с ручной настройкой статического IP;

— первичную настройку серверов: часовой пояс, базовые утилиты, брандмауэр UFW, установку Docker и docker‑compose.

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

Так что запасаемся терпением, запускаем VirtualBox и начинаем строить нашу небольшую лабораторию безопасной разработки.