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

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

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

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

За последние несколько лет мы реализовали обе модели. MULTIFACTOR используется как классическое on-premise решение внутри инфраструктуры заказчиков и одновременно существует как облачный сервис, который ежедневно обслуживает более миллиона пользователей. За это время стало очевидно, что вопрос «облако или коробка» уже не отражает реальную картину. Гораздо важнее понять, какие требования предъявляются к системе и каким образом должна быть построена ее архитектура.

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

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

Нейросети работают на GPU — это вроде бы очевидно. А что, если я вас скажу, что аж в 2018 году группа из UCLA напечатала нейросеть на 3D‑принтере из обычного пластика. Пять пластин. И никаких транзисторов. Никакой памяти. Никакого электричества. Причем, точность распознавания рукописных цифр — 91.75%.

И оно, чудо это — работало.

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

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

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

Kubernetes незаметно стал платформой по умолчанию для ИИ и машинного обучения. Запускаете ли вы серверы notebook-ов для дата-сайентистов, планируете распределённые задачи обучения, настраиваете гиперпараметры или оркестрируете многоэтапные ML-пайплайны. Эти нагрузки всё чаще оказываются в кластере Kubernetes. Kubeflow — один из самых популярных способов собрать этот стек, причём Kubernetes-нативным путём: каждая возможность описана как CRD (Custom Resource Definition, описание пользовательского типа ресурса Kubernetes).

Такая архитектура подарок операторам кластера: ML-нагрузки можно наблюдать и управлять ими теми же примитивами, что и всем остальным в кластере. Но на практике специализированные ML-дашборды, которые поставляются с этими платформами, скрывают лежащий под ними слой Kubernetes. Когда notebook застревает или задача обучения падает, оператор часто вынужден откатываться к kubectl, чтобы выяснить, что на самом деле произошло на уровне Pod.

Команда VK Cloud перевела статью о плагине Headlamp Kubeflow, который закрывает этот разрыв и выводит пользовательские ресурсы Kubeflow прямо внутри универсального Kubernetes UI. Это проработанный пример паттерна, которому может следовать любая насыщенная CRD платформа: встречать операторов там, где они уже работают, и показывать им истину на уровне кластера.

Сам Headlamp это расширяемый веб-UI для Kubernetes, поддерживаемый в рамках Kubernetes SIG UI и лицензированный под Apache 2.0. Он работает как десктопное приложение или внутри кластера, а через систему плагинов кто угодно может добавить полноценные представления для пользовательских ресурсов.

Что такое гиперскейлер и в чем его неотъемлемая связь с облачными вычислениями и советскими НИИ?

Сегодня мы попробуем ответить на этот вопрос, а также рассказать, как развитие технологий позволило AWS, Google Cloud, MS Azure и российским Yandex Cloud и Cloud.ru стать крупнейшими облачными провайдерами. 

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

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

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

В итоге организации снова и снова изобретают решения одной задачи, ставшей распространённой платформенной проблемой: предоставление возможностей Database-as-a-Service (DBaaS, база данных как сервис, выдача БД по запросу как готового сервиса), которые работают одинаково в разных окружениях.

Команда VK Cloud перевела статью о том, как в 2026 году устроен provisioning баз данных в Kubernetes-инфраструктуре: почему модель service broker из Cloud Foundry не прижилась в облачных экосистемах и как open source-проект Klutch.io пытается создать Kubernetes-native стандарт для Database-as-a-Service. Материал будет полезен платформенным инженерам, DevOps- и SRE-специалистам, а также техническим руководителям, которые выстраивают внутренние платформы для баз данных в гибридных и on-prem-окружениях.

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

Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform, VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

Привет! Я Артур Валиев. Мы с командой EvertyDesk размышляем над экспериментальным режимом для игрового стриминга и хотим обсудить не очередной ползунок качества, не новый пресет битрейта и не надпись Ultra Low Latency на главном экране.

Нас интересует более странный вопрос:

Привет! Меня зовут Александр Титов. Я директор Ассоциации профессионалов индустрии облачно-ориентированных технологий «АОТ», организатор сообщества DevOps Moscow и генеральный директор «Фланта». В этом посте я расскажу, как получилось так, что я не только занимаюсь предпринимательством, но и руковожу некоммерческой ассоциацией, которая развивает облачно-ориентированные технологии в России, и почему, на мой взгляд, сегодня отрасли нужна именно такая форма работы.

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

Стройку видно не по чертежам, а по бетону. У энергоцентра в Марфино появилось то, с чего начинается любая стройка, — фундамент.

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

Проблема начинается, когда данных становится так много, что прежняя архитектура перестает выдерживать изменения: появляются новые источники, ускоряются бизнес-процессы, растет стоимость хранения и обработки, а каждое изменение в модели данных требует пересмотра уже принятых решений. Как быть, когда архитектурные подходы организации данных, такие как DWH, Data Fabric, Data Lake, Снежинка, Data Vault, Anchor Modeling и другие, перестают отвечать требованиям и почему под давлением динамично меняющихся обстоятельств стройные концепции постоянно нарушаются?

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

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

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

Меня зовут Сергей Петриченко. Я продуктовый менеджер 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-адреса или любые другие ресурсы, которые продолжают потреблять бюджет после завершения задачи. Но проблема почти всегда шире, чем один тип инфраструктуры.

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