DevOps *

Каждый раз, когда речь заходит о новом проекте, начинается вечный спор: какой фреймворк выбрать? Go или Rust для производительности? Python для скорости разработки? А может, стоит попробовать что-то на Elixir? Муки выбора знакомы многим. Вместо того чтобы в очередной раз теоретизировать, я решил пойти другим путем: взять и протестировать их все.

Так родилась идея проекта Framework DevBox — универсальной песочницы, где десять популярных фреймворков на разных языках упакованы в Docker-контейнеры и готовы к запуску одной командой.

Агентные ИИ-системы обещают ускорить разработку, но ускоряют только там, где уже налажен быстрый поток поставки: автономные продуктовые команды, короткие циклы, непрерывная обратная связь. Реальность же прозаична: по DORA многие организации релизят реже раза в неделю, у четверти change failure rate доходит до 40%, а инциденты чинятся неделями.

В статье разбираемся, почему без «взрослого» Agile и DevOps ИИ-агенты всего лишь делают узкие места заметнее, и как организационная агентность (право и способность команд действовать) становится предпосылкой для реальной выгоды от ИИ.

Отладка больших CMake-проектов часто превращается в боль. Уходит не один час на то, чтобы с помощью message() и бубна найти проблему. Но существуют более удобные и эффективные способы. Например, отладчик, который позволяет пошагово пройтись по CMake-скриптам и посмотреть значение переменных. Или профилировщик, показывающий последовательность вызовов и время их выполнения. Как их использовать? Читайте в статье.

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

(Анонс: Привет. Собираю статистику по инженерным процессам — от enterprise до инди‑команд (форма в конце статьи). Результаты агрегирую и опубликую на хабре в ближайшее время. Анонимно, 5–10 минут. Важен каждый.)

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

Привет, Хабр! Я — Калашников Сергей, DevOps‑инженер в Центре Перспективных Разработок (ex. R&D) компании Bercut. Cегодня поделюсь опытом внедрения систем на базе Tarantool и Tarantool Vshard в оркестратор Kubernetes.

Tarantool — платформа, которая включает в себя in‑memory базу данных, а также встроенный сервер приложений. На базе этой платформы наша команда разрабатывает различные информационные системы, расширяя функциональность с применением языков Lua, Rust, C\C++.

Несмотря на все очевидные плюсы Tarantool, он не является тривиальным в части конфигурирования и bootstrap. Это привело нас к разработке Operator для Kubernetes, который обеспечивает развертывание и конфигурирование кластеров на базе Tarantool и Tarantool Vshard.

Запускать в 2025 году свой майнинг-пул? Серьёзно? Все крупные игроки уже поделены, битва за хешрейт давно закончилась. Но наш клиент пришёл не за «очередным пулом». У него был парк в десятки тысяч ASIC-ов, разбросанных по разным уголкам планеты, и конкретная бизнес-задача — не просто майнить, а делать это с максимальной эффективностью и контролем. И он понимал, что типовые решения его не устраивают. Вот тут-то и началось самое интересное.

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

Привет, Хабр! Меня зовут Данила Гудынин, я 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) у нас уходило от нескольких часов до пары дней.

Представьте: каждый день ваши автотесты генерируют десятки отчетов об ошибках, QA команда тратит часы на анализ падений, а разработчики получают невразумительные описания в духе "test.feature упал на строке 410". Знакомо?

Мы решили эту проблему, интегрировав AI в процесс анализа тестов, и хотим поделиться опытом.

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