DevOps *

Привет, Хабр! Это вторая часть большой статьи, где мы — Егор Салиев и Николай Пушкарев, DevOps-инженеры Hilbert Team, — рассказываем, как построить GitOps-платформу на Argo CD.

В первой части разобрали базу: познакомились и установили Argo CD, изучили его компоненты и показали установку через Helm и Terraform. В этой — перейдём к практике и ответим на вопрос, что делать, когда команда растёт вместе с количеством приложений и усложняется инфраструктура. Пройдём по сценариям от маленькой команды до большой организации и соберём рабочую GitOps-модель на Argo CD.

Как поддерживать свыше 2300 кластеров MySQL без заметных простоев? В Uber это решают разделением на плоскости данных, управления и обнаружения и строгим приведением фактического состояния к desired state. В материале — анатомия control plane (Odin, Cadence, контроллер с правилами), как устроены плавные и аварийные переключения primary, замена узлов и онлайн-изменения схемы; как discovery на etcd и реверс-прокси даёт стабильный VIP; как наблюдаемость, CDC (Storagetapper→Kafka→Hive) и бэкапы закрывают эксплуатацию. ФВ фокусе — инженерные решения, которые позволяют удерживать 99,99% доступности без ручной магии.

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

1. Анализ рабочей нагрузки и требований
2. Разработка схемы данных
3. Настройка хостовых машин
4. Настройка конфигурации Cassandra
5. Настройка топологии кластера
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста

В этой части мы возьмём простой советский...

150 млн чтений в секунду — итог скрупулёзной инженерии кэша. В этом кейсе Uber — как ужесточить консистентность без удушения записи: инвалидация «по пути записи» из слоя запросов, дедупликация по commit-timestamp из БД, сочетание TTL и CDC на бинлогах, плюс измерение «черствости» через Cache Inspector. Разобраны реальные источники stale-данных (лаг CDC, реплики, негативное кэширование) и компромиссы вроде read-your-writes — с практическими схемами, которые масштабируются до сотен миллионов RPS.

Процессы безопасной разработки — это не просто набор инструментов для проверки кода. Основная концепция в том, чтобы все процессы работали как единый механизм, а безопасность была не просто дополнением, а неотъемлемой частью разработки. Фреймворк Building Security in Maturity Model (BSIMM) предлагает смотреть на процессы безопасной разработки с точки зрения зрелости, как на измеримую систему действий и результатов, а не просто как на чек‑лист практик.

В этом году Synopsys не обделил нас новым отчетом и представил BSIMM 15, который мы с вами разберем. Не буду углубляться, что такое BSIMM и как его применять на практике, об этом вы можете прочесть в статье про BSIMM 14, но стоит отметить, что BSIMM дает ежегодную оценку применимости различных практик. На этом и сосредоточимся, посмотрим, какие появились новые активности и какие сейчас в тренде.

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

Меня зовут Юлия Рубцова, я ведущий менеджер продукта Yandex Monitoring. В этой серии статей я и мой коллега Владимир Гордийчук @gordiychuk рассказываем про реальные сценарии использования мониторинга облачных решений. Что вас ждёт: мы покажем, как настроить дашборды, быстро проверить гипотезы при расследовании инцидента, а в конце соберём лучшие практики для настройки мониторинга. 

Начнём с базы: что такое мониторинг, для чего он нужен, что такое золотые сигналы, как использовать гистограммы и перцентили. А уже затем рассмотрим сценарии мониторинга асинхронных задач.

См. вторую часть в этой серии: Переходим к очередям и клиент-серверному взаимодействию

Многие компании реализуют GitOps-подход как часть внутренней Developers Platform. Он помогает унифицировать и автоматизировать доставку кода, повысить надёжность деплоя и дать разработчикам удобный интерфейс для работы с инфраструктурой. Один из самых популярных инструментов для этого — Argo CD.

Статья основана на воркшопе Егора Салиева и Николая Пушкарева, DevOps-инженеров Hilbert Team, проведённом на DevOps Conf 2025. В ней мы разберемся, как внедрить Argo CD и его ключевые компоненты, чтобы построить масштабируемую GitOps-платформу.

Материал будет в двух частях. Он будет полезен разработчикам и DevOps-инженерам, которые хотят понять, с чего начать внедрение GitOps в команде, организовать инфраструктуру под разные масштабы, а также всем, кто ищет способы унификации деплоя.

Terraform Actions — это новая концепция, представленная в Terraform 1.14, которая позволяет выполнять операции вне стандартного рабочего процесса CRUD (Create-Read-Update-Delete). Это расширяет возможности Terraform, позволяя взаимодействовать с ресурсами способами, для которых раньше требовались другие инструменты, например Ansible.

Привет, Хабр! Сейчас только ленивый не пишет про eBPF. Получается — теперь пишет.

Я Саша Лысенко, техлид DevSecOps в К2 Кибербезопасность. Как ИБ-специалиста, меня просто приводит в восторг идея, предлагаемая технологией eBPF. Произвольная программа в контексте ядра операционной системы — и все это без паники, ну сказка.

На самом деле eBPF уже активно применяется в индустрии разработки. Например, в Cilium для организации сети, в Tetragon для runtime безопасности контейнеров, в Falco для мониторинга событий на хостах и в контейнерах, в Katran для балансировки нагрузки, в Android для профилирования использования памяти, сети и энергии. Список этот огромный и продолжать можно долго.

Пройти мимо такого просто не возможно, и я тоже решил попробовать написать небольшой материал о том, как подступиться к eBPF. Для развлечений я обычно использую Rust, и этот случай не будет исключением.

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

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

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

Я уже некоторое время работаю в компании Scalehost, где мы исследуем возможности внедрения AI и ML в нашу инфраструктуру. В процессе поиска материалов, я наткнулся на данную статью, которая показалась мне интересной. В ней рассматривается как объединение подходов DevOps и MLOps помогает компаниям создавать более устойчивые и эффективные процессы разработки, снижать риски и повышать качество продуктов. 

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

OpenRC + AUR + Wine с DXVK/VKD3D + модульный TUI-установщик. Всё это — QuasarLinux, основанный на Artix, но независимый от него.

В Ситидрайве Kubernetes обновляют регулярно — инфраструктура большая, и актуальность версий критически важна. После апгрейда до версии 1.29.15 один из GPU-узлов внезапно «забыл» о своей видеокарте, и нам пришлось срочно искать решение. В этой статье я расскажу, в чём была причина бага и как Time-Slicing помог повысить утилизацию GPU. Статья будет полезна всем, кто работает с GPU в Kubernetes и хочет избежать подобных сюрпризов в продакшене.

В нашей практике DevOps мы столкнулись с задачей оптимизации Kubernetes-кластера в AWS, включая перевод нагрузки на ARM64-инстансы с процессорами Graviton и эффективное использование spot-инстансов. Благодаря Amazon EKS и Karpenter нам удалось ускорить ввод новых узлов до всего 40 секунд и успевать переносить нагрузку при отборе узлов со стороны AWS. При этом мы сохранили привычный набор инструментов Deckhouse для мониторинга и управления — статья подробно рассказывает о нашем опыте и решениях.

С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в MТС Web Services. Кроме своей основной деятельности в роли инженера, я провожу собеседования и всегда задаю вопросы кандидатам о том, как они видят пользу, которую их роль приносит бизнесу, как могут оценить свою деятельность, какой у них метод ведения работы. Как многие, я читаю профильные чаты, тематические ресурсы. И... кажется, в ИТ‑сообществе до сих пор бытует мнение, что DevOps и SRE — это следующие этапы развития системного администратора.

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

Ситуацию можно сравнить с подбором стоматолога по навыку работы специалиста с бормашиной. В такой клинике у вас высокий шанс попасть как к ювелиру, так и к мастеру маникюра.

За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".

Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.

Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.

Вы наверняка знаете, Kubernetes просто повсюду. От разработчиков, тестировщиков, DevOps-инженеров и системных аналитиков ожидают умения работать с этим инструментом. Даже продакт-менеджеры иногда интересуются, что это такое.

Если вы только начинаете знакомство с Kubernetes и хотите понять, с чего начать, эта статья для вас. Разберем, какие задачи он решает, какие у него основные объекты и как можно управлять кластером без сложных команд в терминале. Подробнее читайте внутри.

Мнение после десяти лет в производственных окопах от Джастина Кормака, бывшего CTO Docker.

Несколько лет назад я провёл немало времени, отвечая на вопросы Федеральной торговой комиссии (FTC) по поводу покупки VMware компанией Broadcom. Их интересовало, можно ли считать контейнеры конкурентами виртуальных машин - они пытались разобраться в конкурентной среде вокруг VMware.

Это напомнило мне первые пять лет работы в Docker, когда все только и делали, что сравнивали контейнеры с виртуальными машинами. Контейнеры - это просто “облегчённые” виртуалки? Или это небезопасная ерунда, от которой все скоро откажутся и вернутся к старым добрым VM?

Зачем вообще использовать gMSA в контейнерах?

Group Managed Service Accounts (gMSA) решает проблему хранения и обновления сервисных паролей: пароль хранится только в AD и регулярно обновляется автоматически. Использование gMSA позволяет не менять уже настроенные ACL и роли на файловых шарах и SQL-серверах - приложения продолжают работать с прежними правами через корпоративные Kerberos/SPN-механизмы. Такая интеграция обеспечивает прозрачный и контролируемый переход классических приложений в контейнерную инфраструктуру Kubernetes.

Посмотрим как это работает на примере простого кроссплатформенного dotnet-приложения.

Бывают сбои, которые не исчезают после устранения причины: система залипает, полезная пропускная способность почти нулевая, а петли обратной связи удерживают отказ. В статье формализуем это как метастабильные отказы, разберем цикл «стабильное → уязвимое → метастабильное», характерные метрики и «скрытую ёмкость». Обсудим практики сохранения полезной пропускной способности под перегрузкой: бюджет повторов, приоритеты и отбрасывание запросов, обслуживание «последних первыми», грамотное управление очередями и автомат защиты.