DevOps *

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

Пятница, 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 (а с недавнего времени и использование сторонних почтовых клиентов только на платных тарифах), вариант использования собственного почтового сервера кажется все более интересной альтернативой.

Привет! Меня зовут Вероника, я руководитель проекта по разработке ГИС. Эту статью мы писали вместе с Евгением — нашим DevOps-инженером, который отвечает за CI/CD, релизы и за то, чтобы наши обновления не превращались в ночной кошмар.

…

Однажды темным хмурым вечером в ожидании очередного деплоя я имела неосторожность задеть DevOps-инженера вопросом: «Что ты там часами делаешь, тебе же всего одну кнопку надо нажать?». Он объяснил, что это не совсем так. Я предложила:

— А давай сделаем одну «большую зеленую кнопку», которая все сама задеплоит?

— Технически можно, но…

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

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

Недавно на глаза попалась интересная статья про новый проект TeleMT. И я бы наверно не стал заморачиваться. И тоже настроил бы его за 5 минут. По шагам из статьи. Если бы не пара «но». Во‑первых, я болен хроническим неприятием засовывания докера где следует и где не следует. А во‑вторых — 443 порт на моем подопытном сервере уже занят предыдущим «экспериментом».

На нестандартный порт вешать второй «эксперимент» мне не хотелось. Покупать второй айпишник или хостинг — тем более. Требовалось сотворить чутка новой дичи магии. О результатах сего докладываю в этой статье. Вдруг кому‑то пригодится.

В 2026 году выбор AI-инструмента для бизнеса — это уже не сравнение бенчмарков, а управление рисками. Зарубежные облачные сервисы работают в условиях управляемой нестабильности: ТСПУ деградирует соединения, Cloudflare теряет трафик, а ПП РФ №1667 закладывает инфраструктурную основу для перехода к «белым спискам» IP. Разбираем правовую и сетевую карту рисков для каждой категории AI-сервисов — и объясняем, почему self-hosted модели в 2026 году стали не нишевым решением для параноиков, а базовым требованием к Enterprise-архитектуре.

Сейчас очень часто в вакансиях на ДевОпс ищут людей которые, понимают и могут в Helm чарт.

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

Я решил поделиться с вами своим опытом и понял что тут как никогда пригодится метод понимания процессов через визуализацию. О принципах работы метода «Дворца памяти» можно прочитать тут же на Хабр.

Привет, друзья!

Сегодня поговорим о кластерном режиме в Pilot – линейке продуктов, на базе которых организуют совместную работу над строительными проектами, сборку и проверку BIM-моделей.

Кластерный режим Pilot обеспечивает отказоустойчивость и горизонтальное масштабирование её центрального компонента — Pilot-Server. Для хранения данных в кластере используется PostgreSQL, а для взаимодействия между узлами — Redis.

Примечание: На данный момент кластеризация доступна только для Pilot-Server. Pilot-BIM-Server и Pilot-Web-Server работают как отдельные сервисы без возможности горизонтального масштабирования.

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

1. Аппаратный сбой на сервере Pilot-Server. При падении машины, на которой расположен единственный экземпляр Pilot-Server, работа пользователей парализуется, никакие действия с системой в режиме онлайн невозможно совершить. При нескольких компонентах на разных серверах, в случае падения одного из них, мгновенно назначается новый активный узел из оставшихся рабочих. Для пользователей это будет кратковременный разрыв соединения, после которого они переподключатся к новому узлу.

2. Обновление ПО. При обновлении Pilot-Server с единственным экземпляром, пользователи не могут подключаться в этот момент. В кластерном режиме обновление можно произвести в режиме “Последовательного обновления”.

3. Рост нагрузки на Pilot-Server. Большое количество запросов к одному компоненту Pilot-Server может превысить пропускную способность одного сервера. В кластерном режиме за счёт нескольких узлов с Pilot-Server  нагрузка будет распределяться между ними через балансировщик.