Облачные вычисления *

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

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

Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье разберем, почему каталог — это не первый шаг к порядку, а скорее мультипликатор уже существующей зрелости и что необходимо сделать, чтобы его внедрение принесло реальную пользу.

Представьте ситуацию: вы приходите к руководству с четким техническим обоснованием миграции в облако: оборудование устаревает, вычислительных мощностей не хватает, риски простоев растут. Рассказываете, как облако поможет быстрее запускать новые сервисы, масштабировать инфраструктуру и снизить нагрузку на команду. А в ответ слышите: «Бюджет не согласован. Живите с тем, что есть».

Знакомая ситуация? Проблема не в качестве ваших аргументов. Проблема в том, что ИТ и бизнес говорят на разных языках. Вы говорите на языке технологий, а CFO – на языке финансов. У вас даже KPI разные: для вас важны аптайм, время восстановления, скорость развертывания сред, в то время как для финансового директора – только деньги.

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

«У нас тридцать два кластера». Руководитель команды platform engineering произнес это как на исповеди. Тридцать два. В компании с девятью продуктовыми командами. По шесть окружений на каждую. Никто не планировал такого — оно просто росло по одному кластеру за раз, каждый раз, когда команде требовалось что-то чуть иное, а самым простым ответом было «подними новый».

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

Multitenancy — ответ на эту проблему. Kubernetes не был спроектирован для multitenancy из коробки, и, чтобы построить его правильно, требуются реальные инженерные инвестиции, но именно так зрелые команды platform engineering решают эту задачу в 2026 году — со все более удобным инструментарием и все лучше понятыми паттернами.

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

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

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

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

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

Привет, Хабр. Меня зовут Дмитрий Сергеев. Я менеджер продукта «виртуальные серверы» (GPU) в компании VK Tech.

Одна из ключевых проблем внедрения нейросетей в бизнес — отсутствие подготовленной ИТ-инфраструктуры. Почти всегда приходится разбираться, какая из тысяч моделей подойдет для задачи и будет учитывать специфику и процессы бизнеса. Часто это становится дорогим занятием без предсказуемого результата.

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

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

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

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

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

Ярким кейсом стал проект к премьере сериала «Кибердеревня». Мы сканировали гостей мероприятия, создавали их 3DGS‑аватары (3D Gaussian Splatting) и интегрировали в подготовленные Unity‑сцены. Этот пайплайн наглядно подсветил узкое место: при масштабировании производства скорость упирается не в креатив или алгоритмы реконструкции, а в возможности инфраструктуры рендеринга. Стало очевидно, что нам нужно решение, способное ускорить обработку в десятки раз.

Традиционно такие задачи решаются на локальных рабочих станциях или через специализированные внешние рендер‑фермы. Однако в Яндексе уже есть YTsaurus — распределённая система с GPU‑кластерами, поддержкой контейнеризации и отработанными механизмами планирования задач. Меня зовут Анатолий Томилов, я разработчик инфраструктуры VR и 3D‑реконструкции, в Фантехе. В статье я расскажу, почему идея использовать YTsaurus в качестве внутренней рендер‑фермы выглядела логичной, но её реализация оказалась нетривиальной.

Привет, постоянные и не очень читатели!

Во второй части мы занимались самым неблагодарным этапом любого проекта миграции — подготовкой. Проводили аудит инфраструктуры, искали забытые зависимости, считали RPO и RTO, выбирали стратегии переноса и пытались понять, какие сервисы стоит переносить, а какие лучше оставить в прошлом вместе с Windows Server 2008.

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

У Huawei Cloud Stack для этого под капотом есть целый стек инструментов: HCCCMS (нет, кнопку не заело) для миграции серверов и виртуальных машин, IMS для работы с образами, DRS (Data Replication Service) для переноса баз данных, CDM (Cloud Data Migration) и DataArts для миграции данных, а также великое множество сетевых и облачных сервисов из публичного облака Huawei Cloud.

Про них и поговорим.

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

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

Привет, Хабр! Совместно с аналитическим агентством Apple Hills Digital мы провели исследование трендов облачного потребления в корпоративном секторе России. Полученные данные показывают, как компании используют облачные технологии для внедрения решений на базе искусственного интеллекта.

Исследование проходило в два этапа. В первом провели 27 глубинных интервью с ИТ-директорами и руководителями крупных компаний. Во втором — онлайн-анкетирование 419 компаний из различных отраслей экономики. Участие приняли руководители и специалисты — лица, отвечающие за принятие решений об IT-инфраструктуре и облачных сервисах.

Сегодня прошло мероприятие VK Cloud Conf 2026, чего было интересного...

Одной из интересных концепций, которую удалось подметить и на которую мы раньше обращали мало внимания: возможность мониторить ошибки на толстом клиенте. Однако если специалист по продукту рассказывал, что это просто интересный инструмент, к которому они подключили ClickHouse, то мы с ним дошли до обсуждения, что ИИ-агенты могут работать явно больше 3,5…15 часов, если получают подробный и отфильтрованный и прошедший отдельную оценку разбор ошибок на клиенте и сервере. 

Вы вставляете в код небольшой JS-скрипт, как при подключении Яндекс-метрики, но он мониторит не только трафика на Ваш сайт, но и то, что у пользователя запустилось, с какого устройства появилась проблема в работе боевого сервера (IPhone / Android / Windows / …). Когда Вы пытаетесь проанализировать ошибки без специальных инструментов, нужно писать кучу разрешений о выводе ошибок, строчить явно не 10 строчек кода, которые на клиенте проанализируют проблему. А здесь вы просто доверяетесь инструменту, где все это сделано за вас. Но прелесть в том, что ваш агент, анализируя и пересматривая результат своей генерации кода, может анализировать именно сообщения и ошибки, «подготовленные на блюдечке» этой тулзой, что повышает результативность работы ИИ-агентов.

Привет, постоянные и не очень читатели!

Недавно на Хабре вышел лонгрид «Поймай меня, если сможешь [часть 1]: облако на Huawei Cloud Stack — что это, как используют и лицензирование», в котором я рассказал про платформу Huawei Cloud Stack (HCS) — как она устроена и почему крупные компании вообще смотрят в её сторону, там же про архитектуру, лицензирование и многое другое.

Но платформа HCS больше, чем сумма её частей: первый лонгрид (при всех моих стараниях) всё равно получился лишь аннотацией к Сильмариллиону. Той теории достаточно для поверхностного знакомства, теперь же обсудим подготовку к миграции: аудит инфраструктуры, разберёмся с RPO и RTO, посмотрим на совместимость виртуальных машин и образов, а самое главное — обсудим стратегии миграции по методологии AWS, которые можно применить не только к HCS, но и к любому другому облаку.

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

Мы тоже сначала не задумывались. Разработали корпоративного AI-агента, прокачали ИТ-команду, чтобы двигаться дальше — и споткнулись о «железный порог». Так родилась идея AI ready модуля. В статье рассказали, что это такое и почему AI начинается не с модели, а с инфраструктуры. 

2,5 км оптики — в земле, генплан на 24 МВт — утверждён. Май в Марфино был про связь и масштаб: показываем, как преобразилась площадка.

...или Протокол SPICE в современном графическом стеке, часть 3.

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

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

Приглашаю под кат всех любознательных - в особенности тех, кто сталкивается с Windows не только как пользователь; с решениями для удалённого доступа; с протоколом SPICE; с системами виртуализации и виртуальными машинами в принципе.

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

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

Но чтобы раскрыть весь потенциал этой функции и грамотно встроить ее в рабочие процессы, важно понимать, как она устроена. 

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

Привет, постоянные и не очень читатели!

Всего одна сделка (зато какая — на 61 000 000 000 $) неплохо так встряхнула мир виртуализации и IT в целом: Broadcom купила VMware, упразднила кучу SKU и ввела подписную модель лицензирования крупными пакетами (многие оплачивают то, что им и не нужно вовсе, так как пакетов меньше просто нет). Самое плохое, что ни партнёры, ни конечные клиенты не были готовы к такому повороту событий и сопутствующему ущербу, а потому до сих пор оправляются.

Вариантов, как все выкручиваются, много, а довольных новой моделью VMware by Broadcom — мало. Если у вас тоже наболело или вы просто зашли поглядеть на ещё один способ сложить (или нет?) все виртуалки в одну проприетарную корзину Huawei Cloud Stack, то эта серия статей для вас.

С ростом сложности рабочих нагрузок инференса больших языковых моделей (LLM) единый монолитный процесс обслуживания упирается в свои пределы. У префилла и декодирования принципиально разные профили вычислений, но традиционные развёртывания заставляют их работать на одном оборудовании. В итоге GPU недозагружены, а масштабирование — негибкое.

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

Команда VK Cloud перевела статью, в которой разбирается, как развернуть дезагрегированный инференс в Kubernetes. Здесь мы посмотрим на разные решения экосистемы, как они работают в кластере и что дают «из коробки».

Привет, Хабр!

Уже больше 10 лет я работаю с виртуализацией, и за это время успел в разной степени потрогать самые разные платформы. Естественно, до 2022 года это была в большей степени VMware, а параллельно с ней и разный опенсорс, в последние же годы руки добрались и до некоторых наших платформ. 

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

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

Зачем я пишу эту статью?

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

Если эта статья кому-то поможет — буду очень рад.