DevOps *

Всем привет. Я Backend разработчик, в основном на Python и немного Go. Хотел бы рассказать про свой опыт оптимизации docker образов и написать некий «туториал». Он скорее будет полезен для разработчиков или начинающим DevOps. Для опытных DevOps инженеров, возможно будет мало интересного и полезного.

Привет, хабровчане!

Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. 

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

Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. Когда у компании одновременно есть свои датацентры, частное облако и несколько публичных облаков, вопрос стоимости вычислительных ресурсов быстро перестает быть бухгалтерской формальностью. Без понятной модели невозможно нормально распределять затраты, сравнивать варианты размещения и объяснять, почему одна и та же виртуальная машина в разных контурах обходится по-разному.

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

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

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

Поэтому дальше я сосредоточусь именно на частных системах виртуализации и на простом примере покажу, как посчитать стоимость 1 ядра CPU и 1 GB RAM.

Для простоты будем считать, что кластер виртуализации состоит из однотипных серверов. Допустим, в каждом сервере установлены 2 CPU по 64 ядра и 1024 GB RAM. Тогда стоимость сервера складывается из стоимости памяти, стоимости процессоров и стоимости платформы, куда входит все остальное: сетевые карты, материнская плата, корпус, блоки питания и прочие компоненты.

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. Когда в компании одновременно есть локальная инфраструктура, облако, общие платформенные сервисы и выделенные ресурсы под продукты, считать ИТ-расходы "в среднем по больнице" уже не получается. Мы пришли к модели, в которой у каждого ресурса есть понятные метки, владелец и правило аллокации. В этой части разберу, с чего такая модель вообще начинается.

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

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

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

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

Все кто касался темы обеспечения бесперебойной работы сервисов знает на сколько изнуряющим и трудно оценимым по времени бывает диагностика и устранение инцидентов. Настало время это исправить!

Пятница, 17:40. Билд красный, GitLab живой, curl отвечает за полсекунды — а git clone из контейнера молча висит две минуты и падает. Все инструменты говорят «всё ОК». Виновник — 50 байт, о которых никто не подумал.

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

За 7 лет работы с Docker я устал от этой рутины и решил написать простой инструмент, который решает проблему на уровне инфраструктуры как кода. В этой статье полезем под капот ядра Linux: разберемся, как безопасно прыгать по неймспейсам (netns) в Go, чтобы не сломать планировщик, почему я выбросил iptables в пользу бинарного протокола netlink и как сеты в nftables позволяют обновлять правила без потери трафика.

Реальные сообщения от пользователей - мы читаем всё и стараемся оперативно реагировать. Именно так появились многие фичи PingZen.
Так же о подключении PingZen к AI-агентам через MCP: выбираем инструмент (Claude Code, Cursor, VS Code, Claude Desktop, Windsurf) - и всё готово. Дальше сервис сам проведёт через OAuth.

Коротко для ленивых

В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb.

Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency.

В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x.

Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения.

Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo.

Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.

Ваша ML-модель работает в ноутбуке, а в продакшене — нет. Бывало такое? Именно здесь начинается настоящая инженерная задача: взять эксперимент из Jupyter-ноутбука и превратить его в воспроизводимый, наблюдаемый и масштабируемый пайплайн — от сырых данных до стабильного инференса под реальной нагрузкой. Kubernetes давно стал де-факто стандартом для этой работы: более 70% компаний используют его в продакшене — это не дань хайпу, это прагматичный выбор тех, кто уже наступал на грабли.

В этой статье разберем, почему K8s выигрывает у альтернатив именно для ML-нагрузок, а также обсудим какие мифы и анти-паттерны тормозят команды на пути к продакшену. Пройдемся по полному стеку: от подготовки кластера и фиксации данных через DVC до canary-деплоя модели и автоскейлинга GPU-подов. В конце вас ждет взгляд на то, куда движется индустрия: serverless-ML, multi-LLM-ops и edge-развертывания.

Если вы DevOps- или MLOps-инженер, которому приходится запускать обучение и инференс в одном кластере, или R&D-инженер, чьи модели «магически ломаются» при переходе в прод — читать обязательно.

Каждый пуш в main — и ты зажмуриваешься на 2 минуты: 502 или пронесло? Знакомо? Сотни разработчиков сталкиваются с этим при деплое Next.js на VPS. Решение — буквально замена одной команды и удаление одной строки. В статье: конкретный рецепт zero-downtime с PM2 cluster mode, две главные ловушки (restart vs reload и rm -rf .next), расчёт сэкономленных денег, и честное сравнение с Kubernetes.

В этом тексте я покажу как собрать прошивку при помощи компилятора IAR и GNU Make файлов.

Собрать прошивку компилятором IAR с помощью GNU Make — это не просто возможно, это стандартный подход для автоматизации сборки, например, на CI/CD серверах, где использование IDE неудобно. IAR поставляется с набором консольных утилит, которые делают этот процесс вполне прямолинейным.

Привет, я Александр Хренников, руководитель DevOps-юнита в KTS.

Нам тут, оказывается, 5 лет стукнуло. Точнее, нашему блогу на Хабре. Подарков мы не дождались, так что решили сами вручить их вам. Дарить будем футболки с нашим фирменным принтом — Котзиллой. Это как Годзилла, только кот.

Но подарок получат не все, а десять DevOps-инженеров, которые справятся с нашим испытанием быстрее остальных. Суть проста: мы даем вам тестовый стенд с кластером Kubernetes с ArgoCD и отдельный GitLab-сервер. В ArgoCD добавлено приложение — простой Nginx, обернутый в Helm-чарт. И оно не запускается. Надо запустить.

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

К 2026 году стало очевидно: классические подходы к защите информационных систем перестали работать не потому, что «появилось больше уязвимостей», а потому что изменилась сама природа инфраструктуры и атак.

Руководитель информационной безопасности сегодня не «ставит продукты», а управляет риском в динамической среде, где изменения происходят ежедневно. Ниже — три наиболее болезненных блока, которые в облаке определяют реальную устойчивость, и набор практик, без которых защита превращается в набор заплаток.

Привет, Habr!

Меня зовут Максим Юрченко, я руководитель группы DevOps-инженеров в Lenta tech («Группа Лента»). В статье я расскажу о том, как за последние четыре года менялась наша система логирования, какие решения мы принимали по ходу роста инфраструктуры и к какому результату в итоге пришли (спойлер — без подводных камней и граблей не обошлось).

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

В MTС Web Services мы столкнулись с такой потребностью в масштабе сотен команд — и вместо очередной документации решили сделать внутренний практический курс с живыми инструментами, реальными процессами и выпускным проектом, который нужно собрать end-to-end. 

Меня зовут Елисей Захаров, я из центра практик DevOps в MTS Web Services. В этой статье расскажу, как мы вместе с командой Центра обучения и развития проектировали курс, почему он получился именно таким и какие результаты дает спустя несколько лет. Покажу, с какими трудностями столкнулись и на какие грабли наступили, — если будете разрабатывать курс для внутреннего обучения, вам это пригодится.

Привет! На связи команда Yandex Monium, это вторая часть серии про эффективный мониторинг. Исторически Monium был разработан командой Yandex Infrastructure как внутренняя observability‑платформа и использовался для мониторинга критических сервисов внутри Яндекса. В прошлый раз мы рассказали о том, что важно знать про мониторинг в целом, а также рассмотрели подробнее асинхронные задачи. На примере кейса с таинственным зависанием задач мы увидели, как с помощью метрик можно определить не очевидную проблему, вызванную скрытым багом. 

Но вполне возможно, что у вас всё взаимодействие происходит через очереди, а не через асинхронные задачи. Далее в этой статье:

— В первой части разберём кейсы на примере in‑memory‑очереди. Это также применимо для различных типов очередей, в том числе для Apache Kafka. 

— Во второй части перейдём к клиент‑серверному взаимодействию.

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

В моменте идея развертывания дома почтового сервера может показаться излишеством, ведь вполне для отправки различного рода уведомлений можно использовать Telegram или любой другой мессенджер, а для переписок со своего домена почту можно завернуть на какой-нибудь почтовый сервис, предлагающий возможность использования своего домена бесплатно, например mail.ru. Однако с учетом последних телодвижений РКН в сторону блокировки Telegram и ограничение в 5 ящиков на mail.ru (а с недавнего времени и использование сторонних почтовых клиентов только на платных тарифах), вариант использования собственного почтового сервера кажется все более интересной альтернативой.