DevOps *

Как мы построили DevOps в локальном облаке без AWS и managed-сервисов: GitLab CI, Kubernetes, PostgreSQL, мониторинг на Prometheus и Grafana. 10 000 TPS в пике, 12 минут на деплой, 2 минуты на восстановление — и всё это в проде.

Привет, Хабр. В этом дайджесте мы собрали обучающие материалы по ИТ‑инфраструктуре — чтобы вы могли получить нужные знания точечно или системно и перенять лучшие практики от экспертов индустрии, так сказать, не отходя от станка. Без долгих предисловий, перейдём к делу.

Так ли нужно хранить 3 ТБ метрик за 180 дней? Устали от компромисса между детализацией мониторинга и размером storage?
В статье разберём, как разделить метрики на два независимых потока без Multi Retention из Enterprise-версии. Solution inside: простое, но эффективное решение с сохранением детализации для оперативного мониторинга и разумным использованием дискового пространства. Идём организовывать хранение сырых метрик на 30 дней и агрегированных — на 180!

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

Но есть способ лучше - автоматизация через Chocolatey и PowerShell. В этой статье разберём:

1. Как развернуть ПО на всех машинах за кратчайший срок;
2. Как создать собственные пакеты и управлять ими;
3. Как внедрить данное решение в вашу организацию.

Если вы системный администратор, DevOps, ИТ-инженер или специалист ТП - постараюсь помочь сэкономить вам десятки часов рутинной работы.

Всем привет, меня зовут Кирилл и я Android-разработчик в Scanny.

В прошлой статье, мы описали то, как будет выглядеть наш CI/CD, научились запускать статический анализатор кода, выполнять Unit-тестирование, собирать различные Build Flavors и отправлять их в нашу Telegram-группу.

В этой статье я покажу, как можно подключить и запустить Android-тесты в рамках CI/CD на примере Marathon Labs и Firebase Test Lab.

У нас были две сотни брокеров, шесть тысяч топиков, клиенты на четырех языках программирования, миллионы сообщений в секунду и целое море различных паттернов использования Kafka. А также жесткие требования по latency, тонна SLA и желание сделать гибкую систему аутентификации и авторизации для сервисов. Не то, чтобы все это было категорически необходимо для начала этой истории, но если уж начал рассказывать про асинхронные взаимодействия, то иди в этом до конца.

Единственное, что меня беспокоило — это авторизация. В мире нет ничего более желанного для ИБ и ненавистного разработчиками, чем контроль доступа. И я знал, что довольно скоро мы доберёмся и до этого вопроса.

Если вам интересно распутать клубок асинхронного взаимодействия тысяч продюссеров и консьюмеров, узнать, где документация Kafka нас обманывает, а librdkafka и Confluent.Kafka не могут договориться, и как один потерянный пакет может привести к Permission denied, добро пожаловать под хабракат. Эта история для тех, кто догадался, что недостаточно было «просто включить флажок в конфиге».

Привет, Хабр! Меня зовут Виктор Корейша и я — руководитель направления Managed Services в Ozon. Я и моя команда, в том числе, отвечаем за всю инфраструктуру асинхронного взаимодействия между сервисами, которую строим на базе Kafka. А ещё я ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

Эта статья написана по мотивам моего доклада для DevOps Conf 2025. Расскажу нашу историю про внедрение авторизации и аутентификации в Kafka. Инженеры по эксплуатации найдут в ней обзор решений реализации SASL-сервера, разработчики — историю о конфликтах в production-ready клиентах, архитекторы — любопытные кейсы взаимодействия высоконагруженных систем, ну а менеджеры — эпос о внедрении технически сложных изменений в больших компаниях.

Хабр, привет! В этой статье расскажем, как команда банка ВТБ построила собственную аналитическую систему на базе открытых технологий и с использованием решений Arenadata. Мы рассмотрим архитектуру платформы, разберём её сильные и слабые стороны, а также заглянем «под капот» — покажем, как устроены процессы внутри банка и почему ВТБ решил идти своим путём, а не использовать готовые вендорские системы.

Kubernetes давно стал стандартом для масштабируемого управления микросервисами, но использование его возможностей не всегда так очевидно, как кажется.

В этой статье мы рассмотрим, как расширение функционала K8s с помощью пользовательских ресурсов помогает решать инфраструктурные задачи, позволяя разработчикам быстро запускать и масштабировать сервисы без лишних хлопот. Однако с этим подходом приходят и свои проблемы, такие как ограничения в хранении больших объёмов данных. Разберемся, что стоит за этими вызовами, и почему HariKube — перспективное решение для эффективного распределения данных в Kubernetes.

Контейнеры падают, а вы узнаёте об этом постфактум? Ошибки в логах проходят мимо?

Собрал Rattle за три дня — простой self-hosted инструмент, который отправляет события из Docker в Telegram. Без лишних панелей, без сложной настройки — просто работает и сообщает о самом важном.

В статье рассказываю, зачем он мне понадобился, как устроен внутри и как можно быстро развернуть его у себя. Покажу Telegram Mini App, через которую удобно управлять уведомлениями.

📎 Ссылка на репозиторий: github.com/rattle-bot/rattle

Переход к SRE — это не просто внедрение новых инструментов, а целая культурная трансформация, которая ставит надежность в центр всех процессов. В этой статье мы разберемся, почему подход Site Reliability Engineering стал неотъемлемой частью современного IT, чем он отличается от DevOps и как его внедрение меняет подход к разработке и эксплуатации систем. Мы также коснемся ключевых вызовов, с которыми сталкиваются компании, пытаясь интегрировать SRE в свою работу, и объясним, почему без отказов и сбоев в реальном мире обойтись все равно не удастся.

Когда микросервисов становится столько, что в них легко запутаться, а Prometheus уже не справляется с единой картиной мира, пора переходить на новый уровень observability.

Расскажу как именно я внедрял OpenTelemetry в своей инфраструктуре, с какими сложностями столкнулся и какие возможности открывает такой подход.

Спойлер: вышло хорошо

Привет, Хабр! Меня зовут Евгений Никулин, я – тимлид инженеров эксплуатации в К2 Cloud.

Пару месяцев назад меня позвали на онлайн-митап «Карьера в Линукс» – обсудить, как сейчас всё устроено: какие подходы используют компании, каких специалистов ценят и что помогает соискателям находить общий язык с работодателями.

Решил с вами поделиться самым важным оттуда. Полная запись, если что, есть на канале K2 Cloud Team – там же можно узнать, как мы с 2009 года строим облачную платформу собственной разработки.

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

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

Здравствуйте. Меня зовут Николай, и сегодня я расскажу, как мне пригодились Ansible и Python для работы с Yandex Cloud, и совсем не пригодился Terraform. 

Привет, Хабр! Меня зовут Роман Аминов, я руковожу группой автоматизации бизнес-сценариев в команде СУБД Pangolin в СберТехе. Это специальная доработанная сборка PostgreSQL, целевая СУБД в Сбере и не только. СУБД — сложный продукт, обновление, настройка и другие рутинные действия, связанные с её сопровождением, сопряжены с риском потери данных. Чтобы облегчить жизнь пользователям (и вдобавок разгрузить нашу техподдержку) мы разработали инструмент для автоматизации кластеров СУБД, их настройки и конфигурирования, обновления версий компонентов в их составе и обслуживание. Решение уже прошло проверку на тысячах кластеров в Сбере и я готов поделиться тем, как всё это работает.

Уточню, что мы используем систему управления конфигурациями Ansible. Всё, что нужно для её работы — это возможность устанавливать SSH-соединения и Python на удалённых серверах.

Надеюсь, статья будет полезна или натолкнёт на свои мысли автоматизаторов и администраторов СУБД и вообще всех, кто связан с базами данных. 

DevOps — это не отдельная роль, а скорее философия или набор практик, принятых внутри компании/команды. Его цель — улучшить коммуникацию и объединить разработку и эксплуатацию общей целью, повысить прозрачность и скорость доставки ценности до клиента.

По крайней мере, так нам заявляют основные труды по DevOps, а также те, кто стоял у истоков этого движения. Но в индустрии сложилось совершенно другое представление о DevOps: у нас выделились отдельные DevOps-инженеры, и даже появилось мнение,
что DevOps — это просто «сисадмин на стероидах». Есть ли способы жить иначе?
И превратить DevOps в настоящую культуру внутри команды?

Одна команда — и сервер настроен. Я больше не лезу вручную и не повторяю одно и то же десятки раз. Внутри рассказано о том, как Ansible помогает автоматизировать задачи, от настроек до деплоя.

Десятки тысяч компаний используют Ansible для управления конфигурациями и автоматизации ИТ-процессов. И мы подготовили подборку материалов, которые помогут познакомиться с этим инструментом — от базовых руководств уровня «с чего начать» до продвинутых практик по написанию эффективных плейбуков.

В программировании часто приходится писать программные компоненты, которые, в общем очень похожи друг на друга по своей структуре и API.

В заметке я представил простую утилиту r.exe для авто-замены токенов в файлах и названиях файлов.

В Kubernetes 1.28 появилось новое поведение: init-контейнеры теперь могут иметь поле restartPolicy (KEP 753). Это позволяет явно указать kubelet’у, что такой контейнер следует считать сайдкаром, а не классическим init-контейнером. В Kubernetes 1.33 эта долгожданная фича наконец получила стабильный статус. Разбираемся, что такое сайдкар-контейнеры и когда их лучше использовать.