DevOps *

Знаете, что я делал вчера с 10 до 12 утра? Деплоил новую версию на production. Вручную. На 15 серверов. По SSH. В 2024 году. И это не самое грустное. Самое грустное — что я делаю это каждую неделю. И каждый раз обещаю себе, что вот на следующей неделе точно автоматизирую. Но следующая неделя наступает, и я снова сижу и копипащу команды в терминал.

Если вы узнали себя — добро пожаловать в клуб анонимных toil-оголиков. Давайте поговорим о том, почему мы все еще делаем руками то, что должны были автоматизировать еще вчера.

Всем привет! Я Алексей Босенко, DevOps-инженер в компании KTS. В этой статье я покажу, как комплексно настроить быструю и эффективную сборку проектов в Kubernetes с использованием BuildKit, которая учитывает не только производительность, но и стоимость ресурсов.

Под этой громкой фразой я подразумеваю целый комплекс решений: как создать и настроить экономичный кластер Kubernetes для сборок (ведь цена вопроса всегда важна), как настроить GitLab Runners и как сделать эффективное масштабирование сборок. Особый акцент будет на том, почему мы выбрали BuildKit, какие варианты использования он предлагает, и как непосредственно настроить один из них.

Будет много подробностей о том, почему мы принимали эти решения и как внедряли их у себя, так что статью можно использовать в качестве Production-ready-мануала.

Истории из нашей практики: разные подходы к организации инфраструктуры и процессов DevOps. Первая статья из серии.

Кхм. Громковатый заголовок, но я всё объясню.

Итак, у меня был сервис. Обычная молотилка данных, каждый с такой хотя бы раз да сталкивался - что-то на входе, что-то на выходе, а внутри походы в базу, HTTP-вызовы, шаблоны, скриптовая логика... В общем, много всякого.

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

Поэтому вот такая картина потребления памяти меня до недавних пор особо не смущала:

Многие считают ITIL (Information Technology Infrastructure Library) устаревшим набором практик, которые не работают на современных процессах. Опыт «Петрович-ТЕХа» доказывает обратное.

Привет, Хабр! Меня зовут Антон Скутин и я business relationship & service level manager в «Петрович-ТЕХ». Вырос из специалиста техподдержки в лида направления качества и сервиса, в компании уже шесть лет, веду телеграм-канал BRM о своей работе. Расскажу про опыт, как мы в «Петрович-ТЕХ» внедрили ITIL и получили реальный профит. В процессе роста компании мы выделили три временных этапа внедрения ITIL-практик.

Статья написана по мотивам моего доклада для конференции DevOps Conf.

Исследование показывает, что наиболее востребованная технология в 2025 году — контейнеризация. Kubernetes закрывает эту потребность и помогает управлять контейнизированными приложениями. Среди специалистов нет определенного мнения, какой вариант развертывания лучше: самостоятельное или готовое решение. На этот вопрос каждой компании нужно ответить самостоятельно. 

В тексте поделимся выгодами и недостатками каждого подхода, чтобы вы могли принять взвешенное решение. Сравнивать будем не с технической точки зрения, а со стороны бизнеса. Определим, какой вариант экономически выгоден в долгосрочной перспективе. Подробности под катом!

В 2025 году Kubernetes стал практически таким же распространенным решением, как и операционная система линукс. Действительно, с внедрением микросервисов и необходимостью управлять парком серверов нам нужна распределенная операционная система. Именно такой системой и является оркестратор Kubernetes. 

Не я один подметил это, этот факт подсвечен во многих материалах по K8s. Например, вот: 

Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.

Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.

В этой статье я делюсь реальным опытом:

- как мы ушли от ручных релизов к автоматическому деплою в прод;

- какие практики и инструменты позволили нам перестать бояться каждого коммита;

- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.

Этот материал будет особенно полезен техлидам, инженерам DevOps, разработчикам и командам, которые всё ещё живут в мире ручных деплоев, боятся нажимать «мердж» в пятницу вечером. Если вы задумываетесь, как перейти от хаоса к предсказуемости в релизах — вы по адресу.

А как мы этого добились — читайте под катом!

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

Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно TTF порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!

Врет метрика, а вы ей верите.

Давайте разбираться.

Когда я только начинал Tunio, я хотел просто познакомиться с Kubernetes. В итоге получилось построить полноценную платформу для радио с AI-музыкой, новостями, прогнозами погоды, подкастами, гео-кластеризацией и TTS-ведущими - без команды, инвестиций и грантов. Эта статья - о том, как из pet-проекта вырос продакшн-сервис с реальными клиентами, и какие технические фэйлы и открытия случились по дороге.

Когда вы работаете с распределённой системой — будь то микросервисы, фронтенд + бэкенд или nginx + приложение — жизненно важно иметь возможность «протянуть» один и тот же идентификатор запроса через все её компоненты. Это позволяет сопоставлять логи из разных источников, быстро находить ошибки и проводить корреляционный анализ.

В nginx для этого из коробки есть переменная $request_id — 32-символьный hex-идентификатор (например, a1b2c3d4e5f678901234567890abcdef). Его можно передать бэкенду через proxy_set_header X-Request-ID $request_id; или fastcgi_param HTTP_X_REQUEST_ID $request_id;, а также сохранить в access-логах.

Однако стандартный $request_id — это просто случайная строка без временной привязки и без структуры, удобной для аналитики. В этой статье мы рассмотрим, как улучшить ситуацию с помощью ULID и UUIDv7.

Когда в инфраструктуре десятки сервисов и баз данных разных типов, ручное резервное копирование превращается в кошмар.

Один сервер использует PostgreSQL, другой — MySQL, третий — MongoDB, и для каждого нужны свои команды (pg_dump, mysqldump, mongodump) и свои скрипты.

Проект Dumper решает эту проблему он объединяет все типы баз в один универсальный инструмент.

Dumper написан на Go и работает через CLI, конфигурация задаётся в YAML — поэтому его легко встроить в cron, CI/CD pipelines, GitHub Actions или Docker-окружение.

19–20 октября 2025 года в регионе us-east-1 произошёл каскадный сбой, повлиявший на доступность глобальных сервисов. Компания AWS опубликовала детальный разбор, в котором раскрыла первопричину — дефект в автоматизированной системе управления DNS для сервиса DynamoDB. В статье приводятся полная хронология событий, описание воздействия на смежные сервисы (EC2, NLB, Lambda) и список запланированных улучшений для предотвращения подобных инцидентов в будущем.

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

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

Каждая контейнерная платформа — Docker, Podman, Kubernetes — реализует собственную DNS-архитектуру со специфическими особенностями, преимуществами и подводными камнями. Понимание этих различий критически важно для построения надежных и производительных контейнерных инфраструктур. С чем мы и попробуем разобраться в этой статье.

Привет, Хабр! На связи Александр Усачёв, системный аналитик в группе облачных продуктов Рунити. В основе нашей облачной платформы Рег.облако лежит микросервисная архитектура: каждый сервис отвечает за свой участок бизнес-логики — от биллинга до управления сетями. Между собой они обмениваются задачами через брокер сообщений. 

В этой статье расскажу, как мы повысили отказоустойчивость нашей облачной платформы — и почему выбрали асинхронные цепочки задач вместо синхронных вызовов. Это история про устойчивость, Celery, RabbitMQ и немного про то, как инженерам стало жить спокойнее.

Развитие квантовых компьютеров ставит под угрозу классическую криптографию: потенциально они смогут взломать существующие алгоритмы шифрования вроде RSA и ECC. На выручку приходит постквантовая криптография (PQC). Автор статьи объясняет, как обстоят дела с PQC в TLS, что это значит для Kubernetes — и почему уже сегодня кластеры получили постквантовую защиту почти случайно.

Как скачать файлы с удаленной машины по пути, прочитанному из environment variable? Environment variable при этом сама расположена на удаленной машине...

Привет, Хабр! Мы только что получили из типографии топовую DevOps-новинку этого года — книгу Камиль Фурнье и Иэна Ноуленда «Инжиниринг платформ: техническое и управленческое руководство». Промокод для читателей Хабра (скидка 32%) - fournier. Она продолжает и конкретизирует тему облачного развёртывания и дальнейшей поддержки приложений любой сложности, на которую мы ранее перевели отличную книгу Кифа Морриса «Программирование инфраструктуры» и сейчас обновляем её до 3-го издания (готовый перевод ожидается до конца года, затем пойдёт редактура). Также у нас в работе есть для вас книга «Terraform Cookbook» — за сроками выхода следите в разделе «Скоро!» у нас на сайте. Под катом же предлагаем вам перевод статьи, которую Камиль Фурнье написала около года назад, подробно изложив в ней, зачем и о чём она пишет книгу «Инжиниринг платформ», и какое место эта книга займёт на полке умелого девопса.

UPDATE: книгу прочитали сотрудники компании SSP-SOFT и разместили в своём блоге на Хабре подробную рецензию о ней, которую вам будет очень интересно почитать. Благодарим уважаемого Сергея Березина @sergbe и готовимся к наплыву покупателей.

Мрачным утром 20 октября 2025 года мониторинг AWS был краснее некуда, его залило кровью сервисов. Пал крупнейший и по совместительству старейший регион, обрабатывающий 35–40% всего глобального трафика AWS — US-EAST-1. На его воскрешение чернокнижники из AWS потратили 13 часов.

В этой статье я хочу разобрать, что именно произошло, почему восстановление заняло так много времени, и самое главное — что мы можем сделать, чтобы наши системы пережили подобное в будущем. Ведь US-EAST-1 падает уже не первый раз, и явно не последний.