DevOps *

Представьте, что вы DevOps-инженер и разработчик просит развернуть новое приложение в Kubernetes. В большинстве случаев в нем будут секреты: логин или пароль от базы данных, ключи для S3-бакета и так далее. Эти секреты желательно спрятать.

Есть несколько способов это сделать. Мы в команде используем HashiCorp Vault. Храним там секреты в формате key-value, откуда они попадают в приложения, развернутые в ArgoCD с помощью ArgoCD Vault Plugin или аналогичных решений. Звучит не очень сложно, но кое-что в такой схеме нам не нравилось: ручное добавление или изменение существующих секретов в Vault, а также необходимость периодически создавать руками новые key-value secrets engine. Еще стоит упомянуть, что Vault используется не только DevOps инженерами, но и разработчиками, например в их Jenkins-джобах, а у разработчиков нет доступа на запись в Vault, поэтому любой запрос на добавление/изменение секретов с их стороны выполнялся в рамках заведенного на DevOps-инженера Jira-тикета. Тикеты не всегда вовремя замечались в бэклоге, поэтому такая простая задачка, как добавление секретов, могла растянутся на пару дней. Поэтому процесс взаимодействия с Vault мы решили автоматизировать.

В статье я расскажу, как можно управлять Vault через подход IaC (Infrastructure as a Code) с использованием OpenTofu — open-source форка Terraform.

Раньше вас ревьюил злой коллега — теперь это делает AI. AI Review — open-source инструмент, который сам проверяет код прямо в CI/CD. Поддерживает OpenAI, Claude, Gemini, GitLab и GitHub. Быстро, честно и без боли.

Привет, Хабр! Это Станислав Егоркин, инженер юнита k8s департамента разработки Infrastructure в Авито. В одной из своих прошлых статей я описал, как мы детектируем проблемы на нодах Kubernetes-кластеров. Логичным продолжением этой работы стала автоматизация их лечения. В этой статье я расскажу, как у нас устроены механики Auto Healing.

Статический анализ — это не только запуск проверки. Как обрабатывать отчёты, рассылать предупреждения разработчикам и визуализировать результаты? Рассказываем, как с помощью утилит и интеграций PVS-Studio превратить сырые данные анализатора в эффективный процесс улучшения кода.

Как кусок кремния и немного металла превращаются в память, способную хранить гигабайты данных и оперировать ими за наносекунды?

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

GitOps — широко известен и востребован, поэтому по теме регулярно появляются новые материалы для начинающих, а также специализированные инструменты. Мы в Beeline Cloud подобрали примечательные вводные статьи, гайды и open source-решения, которые интересно изучить и потестировать: от управления DNS-зонами и секретами до GitOps-инструментов от энтузиастов и крупных фирм-разработчиков.

Каждый раз, когда речь заходит о новом проекте, начинается вечный спор: какой фреймворк выбрать? 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. Если вы всё ещё релизите раз в квартал — эта статья поможет вам пересмотреть свои подходы к разработке. 🎯