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

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

За последние три года рекламная система VK выросла в три раза по количеству кампаний, таргетингов и RPS. При этом мы столкнулись с физическими ограничениями bare-metal инфраструктуры: 128 CPU и 512 ГБ памяти на сервер стали потолком, в который мы упёрлись. Сервис баннерной карусели потреблял всё больше ресурсов, а время деплоя достигало 24 часов.

Меня зовут Артём Букин, я разрабатываю инфраструктурные проекты. В этой статье расскажу о технических деталях миграции ядра рекламной системы VK в облако: как перешли от MySQL-репликации к P2P-доставке снапшотов через торрент-протокол, научились применять данные без downtime и в итоге сократили потребление памяти в 2 раза, а время деплоя — в 4.

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

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

До этого я уже сталкивался с задачами по работе с облачными сервисами, но именно этот эксперимент стал для меня наглядным примером, как много сегодня можно сделать «из коробки». Нужно было лишь придумать задачу (в моем случае — анализ эмоций в тексте), выбрать инструменты и собрать все в единый рабочий процесс.

Я остановился на трех основных вещах: Container Apps для развертывания, n8n в роли конструктора логики и Evolution Foundation Models как источник интеллекта. Плюс удобный Artifact Registry, чтобы хранить образы контейнеров.

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

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

Сентябрь — месяц фундаментальной работы. Пока природа меняет краски, мы закладываем основу для будущей мощности наших ЦОДов в Марфино и Мытищах. Если только присоединяетесь к нашей стройке — добро пожаловать в предыдущие выпуски: раз, два, три, четыре, пять, шесть, семь.

Пусть плюнет в меня IT-директор той компании, который ни разу не задумывался о переходе в облако. Ну, а что? С одной стороны, это должно быть выгодно. Конечно, есть кое-какие вопросики к безопасности, но ведь люди пользуются – и ничего. С другой стороны, переход на облачную инфраструктуру вроде как требует пересмотреть модель бюджетирования. А так не хочется. Да и надо ли? В общем, вопросов, ответы на которые формируются на основе слухов или давно неактуальных данных, хватает. Поэтому мы собрали 10 самых распространенных мифов об облаке, чтобы выяснить, где правда, а где домыслы, не имеющие ничего общего с реальностью.

Привет, Хабр. Меня зовут Дмитрий Куколев. Я руководитель VK SOC. В этой статье я расскажу о мерах обеспечения надежности и защиты VK Cloud, о собственных ИБ-продуктах и новых сервисах безопасности для пользователей нашего облака.

С момента написания на tcl/tk удостоверяющего центра CAFL63 и утилиты cryptoarmpkcs для работы с электронной подписью меня не покидала мысль, что неплохо бы оформить их как облачные сервисы. Я постоянно смотрел в сторону проекта CloudTk.

Привет, Хабр! На связи Тимур Парфёнов, директор департамента эксплуатации Рунити. Сегодня поговорим о Kubernetes. Точнее — о том, почему он стал стандартом де-факто для оркестрации контейнеров и зачем большинству проектов нужен Kubernetes как сервис (KaaS). Статья будет особенно интересна тем, кто еще не знаком с K8s или только планирует его использовать в разработке. Ну, а старичков приглашаю тоже — присоединиться к обсуждению болей и радостей этой технологии.

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

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

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

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

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

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

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

Привет, Хабр! С вами Александр Гришин, руководитель по развитию продуктов хранения данных Selectel: облачных баз данных и S3. Сегодня мы разберем пять ключевых принципов из книги Мадхавана Рамануджама и Георга Таке «Monetizing Innovation», но не ограничимся теорией. Каждый принцип я постараюсь показать на конкретных примерах из AWS, Google Cloud, MongoDB, Elastic/OpenSearch. Где это возможно, добавлю наблюдения из практики и цифры.

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

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%+ косплеят лося, несущегося по горящему лесу — их ведет судьба. В конце месяца они получают счет за облако, но разобраться, кто и на что потратился, у них не получается. Да и как тут разобраться, если одни команды экономят и оптимизируют, другие боятся пожертвовать ресурсоемкими экспериментами, а третьи просто забывают выключить тестовые среды?

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

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

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

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

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

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

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

Когда Google Meet внезапно начал «тормозить» в России, мы оказались перед выбором: Zoom, Яндекс Телемост, NextCloud или self-hosted решения. После тестов мы остановились на Jitsi Meet на VPS и проверили его в боевых условиях. Делимся опытом и подводными камнями.

Создание кастомной AI-модели для бизнеса кажется простой: скачал базовую модель, загрузил данные — и вот уже готовый AI-юрист или диагност. Но на практике компания часто получает беспомощного «Франкенштейна», который генерирует полную ахинею. Итог — месяцы работы впустую и выброшенный бюджет.

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

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

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

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

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

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

При работе с облачными сервисами часто приходится идти на компромисс: либо хранить дешево, но восстанавливать долго, либо платить за скорость. Допустим, у одного eCommerce-сервиса внезапно упал гипервизор, с ним ушли в офлайн несколько ВМ. Все бэкапы хранились в S3-объектном хранилище. Чтобы восстановить ВМ придется разворачивать ее из архива. На все в среднем уходит около 40 минут. Все это время система заказов лежит, а бизнес считает убытки. С Double Storage мы сделали так, что время восстановления сократилось до 6-8 минут. Что это за технология, как она работает и почему с ней действительно проще – разберём под катом. Технические подробности можем разобрать в комментариях, если будет интерес.

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

Облачный рынок в России растет очень стремительно. Только в 2024 году он достиг 392 миллиардов рублей, увеличившись на 26% год к году. Впечатляет, правда? Значит, все больше компаний предпочитают облако. Но чем популярнее оно становится, тем сильнее проявляется проблема перерасхода финансов. Исследования показывают, что 67% организаций тратят на обслуживание облачной инфраструктуры больше, чем было запланировано. То есть с одной стороны все получили гибкость, масштабируемость и отсутствие головной боли с апгрейдом и обслуживанием. А с другой — непредсказуемость расходов, потому что старые методы финпланирования в облачной среде работают примерно как Tesla на дровах. И с этим надо что‑то делать.