DevOps *

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

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

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

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

Самый простой способ получить удалённый доступ к домашнему серверу — купить у провайдера статический «белый» IP (обычно 100–200 ₽/мес). Если же у вас уже есть арендованный VPS с публичным IP (например, для сайта, VPN или других проектов), его можно использовать как мост для доступа к серверу, сэкономив на покупке статического IP. В этой статье я расскажу, как настроил обратный SSH‑туннель через существующий VPS, чтобы стабильно подключаться к своему домашнему серверу, находящемуся за NAT от провайдера.

Ниже — выверенная и локализованная на русский язык версия текста об оптимизации производительности СУБД. Термины без устойчивых русских эквивалентов сохранены на английском с первым пояснением.

🚀 Как перестать бояться релизов и начать жить: практический гайд для тимлидов

Сбор практик для тех, кто хочет сделать доставку кода не болью, а удовольствием

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

Актуальность статьи: в современном мире скорость доставки фич — это не просто модный тренд, а вопрос выживания на рынке. Компании с быстрой доставкой обгоняют конкурентов по доходам на 20–40%.

Цель исследования — показать, как технические и управленческие практики влияют на ключевые бизнес-метрики и уровень счастья команды. Мы делимся реальным опытом из агротех-разработки.

Методология основана на практическом применении DevOps-практик и измерении результатов через метрики DORA. Мы покажем, как:

Trunk-Based Development сокращает время доставки на 30%

Feature Toggles делают релизы безопасными

Left-shifting тестирование снижает время восстановления с 15–20 часов до 1 часа

Kanban превращает хаос в прозрачную систему

Основные результаты демонстрируют, что быстрые релизы = быстрые проверки гипотез, маленькие партии изменений = дешёвые ошибки, частые деплои = счастливая команда.

P.S. Если вы всё ещё релизите раз в квартал — эта статья поможет вам пересмотреть свои подходы к разработке. 🎯

Я работаю в одном крупном российском банке, где занимаюсь разработкой распределённых систем. За последние несколько лет наша архитектура заметно усложнилась — часть сервисов работает в OpenShift, часть на виртуалках, а кое-что до сих пор крутится на «железе».

Основная боль заключалась в том, что у нас не было единой системы мониторинга. Метрики мы собирали из разных источников: где-то стоял Prometheus, где-то — Zabbix, в Kafka писали свои дашборды, а для C++ приложений вообще не было нормального мониторинга. Каждый инцидент превращался в расследование: мы переключались между тремя-четырьмя консолями, сверяли логи, писали временные скрипты для выгрузки метрик. В среднем на поиск корневой причины (root cause analysis) у нас уходило от нескольких часов до пары дней.

В этой статье будет приведено практическое руководство по базовой настройке и запуску следующих инструментов для работы с LLM: Ollama, LM Studio, vLLM, Triton, llama.cpp, SGLang.

Сегодня расскажу о Devsyringe — инструменте для автоматизации работы с динамическими значениями в статических файлах.

Мы, разработчики, постоянно сталкиваемся с API-токенами, временными URL, строками подключения и флагами функций. В Node.js и других средах есть dotenv и менеджеры конфигураций, которые подставляют значения во время выполнения.

Но что делать со статическими файлами — HTML, JS-конфигурациями или старыми конфигами? Обычно приходится вручную копировать значения, открывать файлы, вставлять, сохранять — скучно, долго и легко ошибиться. Devsyringe решает эту проблему, автоматизируя процесс.

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

Что в статье:

— Фильтрация;
— Экономичные бэкапы;
— Диагностика и решение проблем.

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

Так же внезапно (и не так уж безболезненно) интернет получил новую «дорожно-транспортную» логику: QUIC и HTTP/3. В этой статье разберём, что конкретно дают HTTP/3/QUIC веб- и мобильным приложениям, где эффект заметен сразу, а где — только после тщательного теста. Детали под катом.

Всех приветствую! Послушал обзор курса «Мониторинг высоконагруженных систем» от OTUS, в котором упоминалось, что используется асинхронный подход в мониторинге и решил реализовать его в установленном WG. Готового легковесного в интернете ранее не нашел, а вопрос назрел в ввиду оперативного понимания, кто забивает канал, да и логи хотелось бы увидеть о событиях. Если читатель надеется, что тут я опишу изменение исходника, не тратьте время, будем обрабатывать вывод команды wg в консоли Python-ом, который уже есть в ubuntu 20.04 и содержит asincio. Можете по

Сколько и куда инвестировать в дев-инструменты и платформу, как считать отдачу от оптимизаций (хоть от снижения CPU), и где гонять тесты — на пресабмите или на интеграции? Простых ответов нет. В этой статье я предлагаю целостную модель баланса между затратами разработки и создаваемой ценностью с учётом рисков: успех продукта, продуктивность команды, эффективность ресурсов и стратегические возможности. Дам практичные ориентиры для продактов, инженеров и менеджеров, а также покажу, как инфраструктура и архитектура сдвигают этот баланс и где именно выгодно усиливать автоматизацию и проверки.

Заманчивые зарплаты в ИТ — это не только магнит для вчерашних студентов и карьерных поворотов после 30. Это ещё и вкусная приманка для тех, кто мечтает получать шестизначные суммы… не особенно утруждаясь работой. Иногда соискатели доходят до абсурда — например, с чужой помощью запрыгивают на уровень, который не тянут.

Autoscaler призван оптимизировать ресурсы CPU и памяти кластеров. Но что, если он сам становится источником проблем? Обычный алерт о пропавших метриках обернулся расследованием на всю ночь. Шаг за шагом команда выясняла, почему VPA начал агрессивно пересоздавать поды, пока не дошла до скрытой настройки, едва не похоронившей кластер. Подробности в статье.

Привет, Хабр! На связи Евгений Мартынов, CIO Рег.облака. Сегодня мы подключили вторую зону доступности облака в Москве на базе дата-центра «Медведково-2» . И вместе с новым запуском провели значительный апгрейд  технологический базы: пересобрали сетевую архитектуру, ушли от большого L2, навели порядок в изоляции трафика и перевели API на BGP-анонсы. В статье расскажу про конкретные решения — как и что мы пробовали, какие процессы отложили и к каким выводам пришли.

Любому веб-приложению нужен веб-сервер для доступа извне. На самом деле, многие даже не уделяют выбору веб-сервера для своего приложения достаточного внимания: на Django берут "популярный" Gunicorn (а кто-то ещё и обвязывает его Uvicorn'ом), а для FastAPI Uvicorn практически стандарт. Тут "на сцену" выходит Granian, представляющий впечатляющие результаты производительности с простой настройкой.

В своём проекте "Код на салфетке" я использовал uWSGI, но недавно узнал про новый Granian и мне стало интересно на что он способен. Так появилась идея для этой статьи.

В этой статье узнаем:

Всем привет! Это вновь Илья Смирнов, архитектор решений из Cloud.ru. В прошлой статье мы рассмотрели традиционные подходы к масштабированию подов и узлов кластера Kubernetes. Но остался нерешенным вопрос — как масштабировать приложение по событиям из внешней системы? Ведь мы хотим, чтобы каждое новое сообщение в очереди RabbitMQ масштабировало нагрузку вверх, реализовать event-driven подход и масштабировать приложение не по метрикам утилизации ресурсов, а по факту появления новых событий от внешних систем. Так как же быть?

Я предлагаю использовать решение KEDA 😉

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

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