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

Привет Хабр! Я Иван, QA в Хайстекс. Уже несколько лет занимаюсь тестированием и внедрением решения Акура.

Этот материал родился из практики. Внутри компании мы регулярно поднимаем решения в OpenStack для тестов, пилотов и внедрений, и часто сталкиваемся с одними и теми же вопросами. Где-то не тот порт, где-то нестандартный эндпоинт, где-то сеть устроена чуть иначе, чем ожидаешь. Мелочи, которые на старте могут съедать часы.

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

Всем привет! Меня зовут Александр, я работаю менеджером по аналитике в Cloud.ru. В этой статье разберёмся, с какими подводными камнями сталкиваются компании при работе с облаком и как их можно избежать.

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

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

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

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

Когда на RDP или VPN одновременно приходит несколько тысяч запросов авторизации, 2FA перестает быть просто удобным способом безопасного входа. Это становится чисто инженерной задачей: как выдержать нагрузку, не потерять запросы на авторизацию и не превратить безопасность в точку отказа.

Мы в МУЛЬТИФАКТОР несколько лет решаем именно этот вопрос — строим систему двухфакторной аутентификации, которая работает в больших и маленьких корпоративных сетях, поддерживает все основные протоколы и при этом не зависит от зарубежных сервисов. В этой статье расскажем о том, как устроена система MULTIFACTOR: архитектура, взаимодействие компонентов и инженерные решения, которые позволяют системе быть стабильной при любой нагрузке.

Мы с командой  LBX Биллинга  проводим много  касдевов с основателями SaaS сервисов с различными моделями монетизации. 

Удивительно, насколько часто даже в зрелых продуктах не было чёткого понимания: «Как именно мы зарабатываем?». Все говорили о том, что «продают подписку», а о деталях никто не задумывался.

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

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

Боль: Аренда GPU-сервера стоит дорого ($300–$1000/мес), а простаивает он 90% времени. Serverless GPU решения часто имеют ограничения по времени выполнения или окружению, в которые видеорендеринг не влезает.

Решение: Самописная оркестрация "Одноразовых Воркеров" (Disposable Workers). Основной бекенд (Node.js) через API облака поднимает VPS с GPU только на момент рендера задачи и уничтожает его сразу после завершения.

Стек: Node.js (Orchestrator & Worker main process), Redis (State Machine), Python (Worker components), DigitalOcean API, FFmpeg, LLM провайдеры.

Экономика: Расходы снизились с $1100/мес (постоянный сервер) до ~$130/мес (оплата поминутно только за время рендера).

В этой статье разберём, во сколько обходится LLM-сервис при нагрузке в 100 000 диалогов в день и где проходит граница окупаемости разных вариантов. Посмотрим на стоимость облачных API, аренды GPU и собственного железа, а заодно прикинем, какая инфраструктура нужна, чтобы всё это выдержало боевой трафик.

Я — Оксана Пастернак, старший юрисконсульт компании Cloud.ru. Мы предоставляем облачные сервисы и взаимодействуем с Роскомнадзором (РКН) по вопросам защиты персональных данных и соответствия требованиям законодательства. Изнутри вижу, как важно выстроить процессы так, чтобы облако оставалось безопасным и проверку можно было пройти спокойно.

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

Казалось бы, облака давно разобрали по косточкам. Уже даже финдирам понятно, что и как там устроено. Но стоит только кому-то запустить новую платформу или свернуть проект, как начинается: а почему не в паблике? А почему не в приватке? А оно нам вообще надо? И пошло-поехало. Хотя на деле-то выбор часто донельзя очевиден, если знать пару нюансов.

Привет, Хабр! Меня зовут Даниил Сухан, я занимаюсь разработкой AI-приложений в Just AI. Недавно вышедший AgentKit от OpenAI быстро стал одним из самых обсуждаемых инструментов в сообществе разработчиков.

Мы протестировали платформу для создания ИИ-агентов от OpenAI и сравнили её с нашей Agent Platform. В этой статье разбираем, как создаются агенты на обеих платформах, и в чём заключаются их принципиальные отличия.

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

Мне давно хотелось услышать мнение DevOps про практики FinOps, и вот в подкасте FinOpsWeekly вышло интервью с участием Виктора Фарчича, в котором он в присущей ему провокационной манере говорит о том, как одно дополняет другое и как девопсы видят оптимизацию со своей стороны. Предлагаемые решения в основном рассчитаны на Kubernetes, но основной посыл и обсуждаемые тренды так или иначе актуальны для многих компаний: эфемерные среды разработки, right-sizing и масштабирование.

В мире 1С нет более известной фамилии, чем Гилев. Его тест — это своего рода «народный» стандарт, первое, что запускают администраторы для проверки производительности. Это простой и быстрый способ получить заветную цифру, которая говорит о скорости системы.

Мы и сами решили использовать этот тест, запуская новый высокопроизводительный сервис 1С. Нам нужно было понять, как себя проявят наши новые серверы с процессорами 4.0 ГГц.

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

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

Привет! Я Эмиль Ибрагимов — старший Go-разработчик команды Development Platform в MWS Cloud Platform. В этой статье расскажу о том, как мы создали облачную CLI на Go и что из этого вышло. Спойлер: получилось реализовать утилиту и поддерживать её силами небольшой команды внутри Development Platform.

Всем привет, меня зовут Семён. Я пишу на С++ и работаю в группе Антиробота. Антиробот — это сервис, который на уровне L7 защищает нас от парсеров и DDoS-атак. Разрабатывать его начали более 10 лет назад — сначала он предназначался только для защиты Поиска, затем был внутренним инструментом, который в онлайн‑режиме анализирует запросы к сервисам Яндекса. Постепенно Антиробот вырос в настоящий highload. Сейчас это часть облачного сервиса Smart Web Security (SWS).

В этой статье я расскажу, как с нашим сервисом мы прошли путь от текстовых правил до машинного обучения. Вы узнаете, зачем вообще нужен Web Application Firewall (WAF) — межсетевой экран для веб-приложений — и разберётесь, как он устроен. А ещё — как работают рулсеты, почему у нас их целых три и какие существуют метрики для оценки качества и быстродействия сервиса.

На календаре 2025 год, и термин platform engineering прочно вошел в лексикон всех инженеров и менеджеров, занимающихся вопросами ИТ-инфраструктуры предприятий — примерно так же, как когда-то «DevOps», а еще раньше «Agile». К слову, предыдущие тренды порой превращались в модный хайп, под которым каждая компания понимала свое видение процессов разработки и развертывания. Но платформенная инженерия сегодня — это не просто набор практик, а системный ответ на тот уровень сложности, к которому индустрию привели облака, микросервисы, CI/CD, SRE и бесконечный поток обновлений в экосистемах OSS (Open Source Software, мир open-source инструментов).

Привет! Меня зовут Роман Христевич, я DevOps-инженер в Cloud.ru, занимаюсь плагинами и безопасностью для кластеров Kubernetes. Сегодня расскажу, как я сражался с ветряными мельницами — мусором в кластерах Kubernetes после тестирования релизов, рандомных Helm Chart и просто в автотестах. И как я эти мельницы все-таки одолел.

Если вы DevOps, SRE или системный администратор, то вам не раз и не два приходилось вычищать кластеры от отработанных Jobs в статусе Complete или Configmaps с Secrets, которые создали руками для уже раскатанного Helm Chart. Разовая акция не вызывает особых забот, а вот если это надо делать несколько раз в неделю, это уже проблема или даже боль.

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

Привет, Хабр! На связи Кирилл Савин, я — архитектор SDN в Рег.облаке. В прошлой статье «OVN под капотом: как построить сеть в OpenStack» мы уже разбирались, как устроен OVN, чем он отличается от связки Neutron + Open vSwitch и какие инструменты дает для сетевой виртуализации. Если вы с OVN еще только знакомитесь, лучше начать с нее — там собрана базовая архитектура и контекст.

В этом переводе инструкции по трассировке пакетов мы переходим от архитектуры к практике и разбираем, как трассировать пакеты в OVN. 

Давайте честно: написать умного AI-агента сегодня — это самая простая часть работы. Собрали LangChain или LangGraph, прикрутили API OpenAI или Gemini, заставили это работать у себя в терминале — красота! Вы чувствуете себя Тони Старком.

Но настоящий кошмар начинается, когда возникаетвопрос: «А как выкатить это в продакшен?»

И тут вы понимаете, что ваш скрипт на Python — это не бэкенд. Вам нужно думать про:

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

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

Calico, Kolla, Reconciler — это названия технологических сервисов или имена героев аниме? Проверьте свою интуицию и знания в нашем новом тесте, который мы разработали в Хабре вместе с Рунити!

Мы собрали различные популярные и двусмысленные термины, чтобы выяснить, насколько хорошо вы чувствуете границу между IT-технологиями и поп-культурой. Готовы к вызову? Вперед!