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

Apache Kafka — популярная система потоковой обработки событий, предназначенная для сбора, хранения и передачи больших объемов данных в режиме реального времени. Она используется тысячами компаний и разработчиков для построения высокопроизводительных, отказоустойчивых и масштабируемых решений в области аналитики данных, IoT, микросервисов и многих других сфер.

Однако у Kafka есть один важный нюанс: «из коробки» у нее нет графического интерфейса (GUI), что затрудняет понимание текущего состояния кластера, диагностику неполадок и эффективное управление инфраструктурой и самим сервисом, особенно для начинающих пользователей или тех, кому сложно взаимодействовать с консольными инструментами.

Поэтому для комфортной работы с Apache Kafka активно используются специализированные UI-инструменты. Например, ранее для облачного сервиса Managed Kafka от VK Cloud мы использовали Provectus Kafka UI, но в рамках развития сервиса решили заменить UI на более современный и функциональный.

Меня зовут Никита Суровегин. Я продукт-менеджер в команде VK Data Platform, VK Tech. В этой статье я расскажу, с чего мы стартовали, какие инструменты проанализировали и что выбрали в итоге.

Состояние российского рынка дистанционного зондирования Земли на август 2026 года

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

Одновременно государство начинает выступать не только владельцем космической инфраструктуры, но и крупным заказчиком данных у различных поставщиков. По оценке руководства Роскосмоса, потенциал российского рынка данных ДЗЗ после запуска новой модели закупок может вырасти более чем в шесть раз — до 31 млрд рублей. При этом уже в 2026 году Роскосмос сообщил о заключении контрактов на предоставление данных ДЗЗ примерно на 5 млрд рублей для федеральных и других государственных органов.

Именно поэтому 2026 год можно считать одним из переломных для российского рынка ДЗЗ.

Если вы ведете pet‑проекты, требующие большого количества вычислений, то наверняка сталкивались с проблемой их - вычислений - оркестрации. Содержать личный кластер позволить себе могут далеко не все, а каждая арендная платформа имеет свой специфический инструментарий интеграции и свои ограничения, а хуже всего, что ни одна из них не имеет гарантий полного выполнения. Вдобавок к этому, еще и не хотелось бы завязываться на одну конкретную площадку, как минимум потому, что некоторые провайдеры дают бесплатные возобновляемые квоты, и тратить их, вместо своих кровно заработанных, гораздо приятнее. В данной статье будет рассматриваться пример с арендными GPU, однако все основные тезисы полностью переносимы и на другие сценарии использования.

У вас, скорее всего, уже открыт десяток разнообразных вкладок: какая‑нибудь платформа с бесплатными недельными лимитами, вроде Kaggle; что‑нибудь с бесплатными возобновляемыми кредитами, на подобии Lightning AI; возможно, пара площадок со спотовыми машинами по цене чашки кофе, например Vast, но с оговоркой — никто не обещает, что машину не заберут, или у ее владельца не отвалится сеть.

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

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

Итак, приступаем...

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

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

Статья написана на основе моего вебинара, можно посмотреть его в записи. 

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

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

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

Навигация по тексту:

Команда VK Cloud перевела материал о посте Lin Sun в блоге CNCF: остаётся ли Pod правильной единицей развёртывания, идентичности и жизненного цикла для ИИ-агентов на Kubernetes. Материал будет полезен платформенным инженерам, DevOps- и SRE-инженерам и всем, кто разворачивает ИИ-агентов в кластере.

Всем привет! Я Андрей Халиуллин — руководитель направления IAM & Security Services в MWS Cloud Platform, и мы продолжаем делать облако. В этот раз хочется поговорить о стабильности, отказоустойчивости и прочих SLO. В этой статье расскажу, как мы обеспечиваем свою отказоустойчивость, как мы её тестировали (спойлер: мы отключили целую зону доступности) и что нового для себя узнали. Для наглядности решил объяснить наш подход на примере швейцарского сыра.

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

Для платформенных команд и команд ИБ теневой ИИ на самом деле не проблема «разработчики пользуются чат-ботом». Это проблема доступа. Неконтролируемый ИИ может добраться до исходного кода, секретов, данных клиентов, облачных окружений и процессов развёртывания. Как только ИИ-системе разрешают вызывать инструменты и совершать действия, она перестаёт быть просто ПО для продуктивности. Она становится новой машинной идентичностью — с правами доступа, радиусом поражения (blast radius) и местом в вашей модели угроз.

Команда VK Cloud перевела статью, где авторы моделируют угрозы для типичного cloud-native пути поставки — от ноутбука разработчика до рабочей нагрузки, запущенной в Pod Kubernetes. Каждому этапу они сопоставляют меры контроля, которые можно внедрить уже сегодня с помощью проектов CNCF и решений с открытым исходным кодом.

Объектные хранилища, работающие по протоколу S3, уже давно стали де-факто стандартом для работы с неструктурированными данными — от бэкапов корпоративных систем до наполнения озёр данных (Data Lake) для аналитики. Однако переход от простого использования API к построению на базе S3 отказоустойчивой и безопасной инфраструктуры часто оказывается сложнее, чем кажется на первый взгляд, а многие встроенные механизмы остаются невостребованными. И связано не столько с отсутствием бизнес-потребности, сколько с недостаточным пониманием того, как именно эти функции работают. 

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

Всем привет! Меня зовут Андрей Лапкин. Около года назад я перешёл на роль архитектора ИТ-инфраструктуры в подразделении Эксплуатации музыкального сервиса Звук — и практически сразу мы запустили программу управления облачными расходами.

Облачная инфраструктура стримингового сервиса — это сотни виртуальных машин, десятки кластеров Kubernetes, объектные хранилища, базы данных, балансировщики. Ресурсы создаются под задачи, но далеко не всегда удаляются после их завершения. С ростом инфраструктуры вопрос «сколько стоит конкретный сервис?» потребовал системного ответа”.

За полгода систематической работы мы снизили ежемесячные расходы на инфраструктуру примерно на 22%. Для контекста: до старта программы счёт органически рос на 1–2% в месяц. Расскажу, как мы к этому пришли: какую методологию взяли за основу, какие принципы заложили в фундамент и как выглядит дорожная карта. Фокус статьи — на стратегии, процессах и культуре, а не на готовых шаблонах развёртывания.

Команда VK Cloud подготовила перевод обзора релиз-команды Kubernetes (Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor) из блога kubernetes.io. О том, что устареет, сломается и перейдёт в GA в Kubernetes v1.37, релиз которого запланирован на 26 августа 2026 года. Будет полезен тем, кто эксплуатирует кластеры Kubernetes в проде: DevOps- и SRE-инженерам, платформенным командам, которые планируют обновление.

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

Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026, и к нему мы ещё вернёмся.

В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. 

Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии  4.x его нет, и в документации от процедуры остался только линк на 3.9. Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис.

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

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

В этот раз поговорим о китайской компании Z.ai и о ее новом поколении линейки GLM, а также об агентной среде разработки ZCode 3.0, ориентированной на написание кода. Заменит ли она привычные Cursor и Open WebUI, став полноценным агентом «все в одном» — разберемся ниже.

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

Привет, Хабр. Меня зовут Александр Шмелёв. Я Team Lead команды разработки Databases, VK Tech. В этой статье я расскажу о рисках и причинах переполнения дисков, а также рассмотрю несколько способов предотвращения подобных проблем.

Java уже какое-то время витает в облаках. Всё больше приложений и сервисов переходят на облачную архитектуру. Мы решили не отставать и проверить один из главных проектов для разработки производительных облачных приложений на Java — Quarkus.

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

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

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

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

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

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

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

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

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

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

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