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

Привет, Хабр! Я Михаил Косцов, руковожу практикой вычислительной инфраструктуры и систем резервного копирования в К2Тех. Сегодня сделаю обзор и поделюсь с вами результатами теста еще одного интересного российского решения. Это программная система хранения резервных копий BRO с мощной дедупликацией для быстрого бэкапа и восстановления из него. Мы давно знали о разработке этой платформы, и уговорили вендора предоставить нам возможность «погонять» ее на реальном железе еще до официального релиза. Под катом — проверка производительности в реальных условиях, анализ уже реализованных и перспективных фичей, история с устранением багов, а также разбор аспектов настройки новинки для работы с популярными средствами РК. 

В эпоху повсеместного внедрения AI/ML мы часто фокусируемся на вычислительной мощности GPU и моделях, но упускаем из виду, что уникальная архитектура сетевых фабрик для AI создает новую поверхность атаки. Если в традиционных ЦОДах мы выстраиваем эшелонированную оборону и контролируем трафик на периметре, то в мире AI/ML эти парадигмы требуют серьезного пересмотра.

99.9% аптайма.

Три невинные цифры, которые хостинг‑компании размещают по всем своим маркетинговым материалам как знаки отличия. Звучит впечатляюще, не так ли? Почти идеальная надежность. Ваш сайт работает стабильно 999 минут из каждой 1000.

Но вот что они вам не говорят: 99.9% аптайма означает, что ваш сайт недоступен 8 часов 46 минут каждый год.

Если хотите проверить математику, таблицы доступности конвертируют 99.9% в ~8ч 46м/год, а 99.99% в ~52.6м. В 30-дневном месяце 99.9% допускает около 43м 49с простоя, в то время как 99.99% около 4м 23с.

Это целый рабочий день. Исчез. Клиенты видят страницы ошибок, продажи испаряются, email‑сообщения возвращаются обратно. Пока вы платите премиальные цены за «корпоративную надежность».

И становится хуже. Разница в 0.1% между 99.9% и 99.8% аптайма? Она представляет удвоение времени простоя с 8.77 часов до 17.53 часов в год. Тем не менее хостинг‑компании ценят эти тарифы так, будто разница незначительна.

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

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

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

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

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

 Автоматизация должна решить ключевые проблемы, возникающие при формировании отчетности:

Избыточность ручного труда: формирование части форм отчетности требует ручной обработки больших объемов данных, агрегации выгрузок из различных АБС в один отчет

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

Техгиганты, вроде Google (Alphabet), Meta (признана экстремистской в России) и Яндекса, получают огромную прибыль с монетизации пользовательских данных; менее очевидные Spotify, OZON и т.п. тоже неплохо зарабатывают на данных и рекламе. Банки каждую секунду проводят сотни тысяч транзакций, небольшие интернет-магазины собирают кучу телеметрии, а социальные сети крутят бесконечные алгоритмические фиды, чтобы вы смотрели свою персональную ленту с котиками и мемами.

Каждый клик, каждое движение мышкой, каждый свайп или тап по экрану — это запись в базе данных. И да, серверы давно умеют с этим всем работать.

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

А вот зачем

Для транзакций в реальном времени нужна одна система — OLTP (Online Transaction Processing), а для аналитики другая — OLAP (Online Analytical Processing). OLTP похож на Соника — он всегда в движении, стремительно мчится вперёд, реагирует на каждое препятствие и собирает колечки. А OLTP — отрабатывает каждую транзакцию быстро и предсказуемо. OLAP же напоминает Кирби — он втягивает в себя всё, что попадётся — горы предметов, врагов, целые миры. А OLAP поглощает массивы данных — миллионы и миллиарды строк, чтобы потом переварить их и превратить в осмысленный отчёт.

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

Что делать, если продукт перестал соответствовать потребностям или больше не поддерживается вендором? Можно притворяться, что проблемы нет с вами в комнате, допиливать своими силами, подставлять «костыли» из других систем — или решиться на миграцию. 

Привет, Хабр! Меня зовут Ксения, я — бизнес-аналитик в ITSM 365, организую переезды клиентов на наш сервис деск. Опыт накоплен большой, давайте вместе разберемся на реальных кейсах:

- внешняя и внутренняя миграция — в чем особенности,

- зачем мигрировать на новую конфигурацию продукта,

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

- для кого миграция — не выход, и что делать в этом случае.

Автоматическая установка Ubuntu Server без PXE? Возможно! В статье о том, как можно упростить развертывание серверов с помощью самодостаточного ISO-образа с autoinstall. Такой подход убирает лишнюю инфраструктуру (DHCP, TFTP, preseed), автоматически определяет оборудование, настраивает сеть и получает конфигурацию через API. В итоге — меньше ручной работы, больше гибкости и быстрая установка серверов даже в масштабах дата-центра.

24 сентября прошла конференция Yandex Neuro Scale 2025 — главное событие Yandex Cloud, собравшее более 10 000 участников онлайн и офлайн. Переименование флагманской конференции с Yandex Scale на Yandex Neuro Scale отражает стратегический поворот компании к искусственному интеллекту как ключевому драйверу развития облачных технологий. «Нейро» не случайно появилось в названии конференции — ИИ и ML находятся в фокусе крупнейших компаний и меняют подход к созданию продуктов, — отметил руководитель Yandex Cloud Григорий Атрепьев. Компания представила масштабные обновления своей платформы, сделав ставку на интеграцию искусственного интеллекта во все аспекты облачных вычислений — от инфраструктуры до разработки приложений.

Создание ИИ-агентов теперь доступно каждому

Центральным анонсом конференции стала кардинально обновленная платформа AI Studio с интегрированным конструктором ИИ-агентов Agent Atelier. Новая архитектура решает критически важную проблему современного IT — необходимость глубоких знаний в области машинного обучения для создания ИИ-решений. Платформа использует low-code интерфейс, схожий с сервисом n8n, где логика работы агента выстраивается из готовых блоков. Это позволяет компаниям значительно ускорить внедрение ИИ-решений в свои бизнес-процессы.

Платформа позволяет создавать различные типы агентов, включая голосовых ассистентов для контакт-центров, мультиагентные системы для решения комплексных задач (например, анализ спроса и планирование закупок), а также поисковых ботов на базе технологии AI Search. AI Studio уже интегрирована с сервисами «Контур.Фокус» и amoCRM, а в будущем планируется поддержка ряда других сервисов из экосистемы Яндекса.

По данным рыночных исследований, только треть организаций точно знает, на что тратится их облачный бюджет. Остальные 80%+ косплеят лося, несущегося по горящему лесу — их ведет судьба. В конце месяца они получают счет за облако, но разобраться, кто и на что потратился, у них не получается. Да и как тут разобраться, если одни команды экономят и оптимизируют, другие боятся пожертвовать ресурсоемкими экспериментами, а третьи просто забывают выключить тестовые среды?

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

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

9 сентября NVIDIA представила новый графический процессор Rubin CPX, разработанный специально для задач искусственного интеллекта с длинным контекстом. Этот монолитный чип оснащен 128 ГБ памяти GDDR7, способен обрабатывать миллионы токенов информации и оптимизирован для фазы предварительной обработки данных в задачах инференса. В деталях рассказываем, какую мощность выдает новинка и для какой работы подходит.

Привет, Хабр! Меня зовут Алексей Николаевский, и мы с командой делаем СУБД Яндекса. С 2013 года в Яндексе использовали Kafka для потоковой передачи данных. Но Kafka со временем перестала справляться с растущими объёмами, и в 2017 году мы перешли на своё решение.

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

Привет, Хабр! Меня зовут Данила Гудынин, я DevOps-инженер направления Evolution ML Inference в Cloud.ru. В мире машинного обучения GPU — главный актив, но что делать, когда ваши дорогостоящие видеокарты используются всего на 50%? Мы у себя столкнулись именно с такой проблемой и, чтобы наши клиенты не платили за простаивающие ресурсы, разработали собственную технологию виртуализации GPU.

В этой статье пробежимся по верхам и расскажем, какие подходы рассматривали, и что в итоге позволило нам даже в условиях очень дорогого железа снизить цены до уровня западных облаков без просадки в производительности. А во второй части, которую опубликуем позже для тех, кто готов к глубокому погружению в оптимизацию GPU, мы поделимся готовыми алгоритмами для каждого из способов оптимизации и дадим «списать» немножко кода. Можете подписаться, чтобы не пропустить.

Привет, Хабр! Меня зовут Алексей Августинович, я принимаю участие в разработке операционной системы для линейки коммутаторов KORNFELD. В этом материале расскажу о возможностях нашей сетевой операционной системы, а именно — о поддержке функциональности L2 VXLAN. 

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

Мониторинг служебных компонентов Kubernetes в пространстве kube-system часто остается за пределами первоначальной настройки кластера. Однако стабильность таких компонентов как kube-apiserver, kube-scheduler и kube-controller-manager напрямую определяет работоспособность всей системы. Сбор метрик с этих подов требует точной настройки механизма обнаружения и безопасного доступа к их эндпоинтам.

Привет, Хабр! Меня зовут Катя Низовцева, я системный администратор в Selectel. В этой статье я покажу практическую методику развертывания vmagent с помощью Helm и настройки конфигураций для сбора метрик с ключевых системных компонентов. Это обеспечит видимость их состояния без избыточной сложности. Мы увидим в Victoria Metrics Cluster метрики, снимаемые с подов в служебном неймспейсе kube-system. Но обо всем по порядку.

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

Недавно к нам приехали коммутаторы для ЦОД российского вендора Eltex. И эта статья открывает цикл материалов, посвященных тестированию данного оборудованию в разных условиях. 

Сегодня на Yandex Neuro Scale 2025 наша ML‑команда представила обновлённую AI Studio — платформу с большим набором инструментов для разработки ИИ‑агентов в единой end‑to‑end‑среде. Среди новинок — визуальный конструктор агентов, поддержка популярных API и реализация протокола MСP, механизмы AI search.

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

Вместе с коллегами из команды разработки Анастасией Каримовой и Дмитрием Рыбалко покажем, как это устроено под капотом:

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

— как мы сталкивались с особенностями опенсорс‑инструментов для ML и учились справляться с этим разными способами;

— как мы упростили создание голосовых агентов и заодно уменьшили latency запросов.

Привет, коллеги! Хочу рассказать одну историю. Был у нас в стойке один сервер. Назовем его «Феникс». Работал как часы, аптайм — 986 дней. Мы им гордились, ставили в пример новичкам, мол, вот как надо настраивать железо и софт. А потом пришло время планового техобслуживания в дата-центре. Простое выключение-включение. «Феникс» больше не взлетел. RAID-контроллер решил, что с него хватит, а заодно прихватил с собой пару дисков из массива. Вот тогда я впервые по-настояшему задумался о том, что цифровой мир подчиняется тем же жестоким законам, что и физический.

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

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

Можно ли перейти с Oracle или MS SQL на СУБД из Реестра российского ПО без переписывания всей хранимой логики?
Один из возможных подходов к решению этой задачи.

С 1 октября 2026 года в силу вступает № 289-ФЗ — закон, регулирующий работу цифровых платформ. Формально это про правила работы сервисов в России, но на самом деле — продолжение долгой мировой истории, начавшейся ещё в 90-х. В статье расскажу, какой была первая система для онлайн-покупок, почему первым интернет-сервисом считается сайт доставки пиццы и как эволюция сервисов закономерно привела нас к регулированию.