DevOps *

От YAML-манифеста до работающих контейнеров: разбираемся, что Kubernetes делает после kubectl apply.

Как systemd превратил обычный скрипт перезапуска в бесконечный дедлок — почему мониторинг не заметил собственную смерть

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

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

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

Облачные PaaS-сервисы позволяют использовать платформенные компоненты для построения инфраструктуры и избежать при этом лишних затрат, предоставляя сервисы в том объеме и той конфигурации, что необходимы клиенту. Одна из категорий клиентов PaaS-сервисов — разработчики ПО, и в этой статье предлагаю поговорить о том, чем использование платформенных сервисов ценно именно для разработчиков, обсудить принципы разработки Cloud-native приложений (методику 12 факторов), а также я расскажу о том, что мы в Cloud X делаем для повышения эффективности процессов создания ПО. 

Устал смотреть в логи: опять подбор пароля к ssh, опять лезут в несуществующие файлы сайта. Fail2ban ставил — утонул в настройках. Написал своё: обходит свой сайт, запоминает нормальные адреса, по лишним 404 и по ssh режет IP в nftables. Рассказываю — зачем и как ставил. Код покажу там, где самому было интересно.

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

Экспортер написан на Go и совмещает функции сборщика метрик, логов, проверки обновлений образов и встроенной панели мониторинга в одном легковесном образе.

IMPulse - ChatOps система менеджмента инцидентов. Если вы получаете алерты напрямую от Alertmanager, IMPulse поможет формировать из них полноценные инциденты с эскалацией, ответственными и тредом обсуждения проблемы. Подробности в статье.

После прошлого поста вышли v3.4.0-v3.7.0. Ниже - что изменилось по факту.

Я сел проверить собственный инструмент — локальную память для кодовых агентов — и нашёл в нём подряд одиннадцать вещей, которые надо было чинить. Stop-хук, рекурсивно породивший 4083 сессии за сутки; recall, мёртвый на обычной установке; миграция на 66 секунд внутри хука с таймаутом 10. Разбор каждого пункта: что сломалось, как чинили и кто это нашёл — я, внешнее ревью другой моделью, CI или проверка на живой Ubuntu.

Переезд с include на GitLab CI Components: у модуля появляется объявленный spec: inputs с типами и дефолтами, а опечатка в имени input роняет пайплайн до старта…

Всем привет, меня зовут Пётр, я DevOps инженер компании Nixys. История с алертами и дежурствами для меня, как и для любого DevOps инженера, довольно противная, потому что не знаешь, что вызывает больше негатива: ложный звонок посреди ночи или критичный алерт, который почему-то не сработал.

Долгое время решением этого были Grafana OnCall, PagerDuty и другие платформы, которые предоставляли возможность установки open-source инструментов для оповещения инженеров, ведения смен и эскалации происшествий. Но в марте 2026 года состоялась полная архивация проекта Grafana OnCall OSS, а PagerDuty полностью прекратила сотрудничество с клиентами из России еще в 2022. И вот, время шло, а крепкой зарубежной opensource замены уровня Grafana так и не появлялось. Это побудило нас самостоятельно взяться за разработку локального проекта для управления алертингом, который мы бы хотели предоставить в открытый доступ.

Инструмент внедрили за неделю, а правила приёмки не написали вовсе. Это не преувеличение. За последний год картина в большинстве команд стала одинаковой: ИИ-ассистент стоит почти у каждого разработчика, его код ежедневно уходит в продукт, а общего стандарта «что считать принятым» у компании нет. Проверять успевают не всё, т.к. изменений стало в разы больше, а ревьюеров в лучшем случае осталось столько же. «Выглядит правдоподобно» подменяет «проверено». Ошибка, не пойманная на входе, возвращается переделкой через одну-две недели.

Скорость выросла у всех, а дисциплина почти ни у кого. Эта статья про то, почему обычное ревью и обычный SAST в эпоху vibe coding перестают быть достаточным контуром контроля, какой стандарт приёмки ИИ-кода мы считаем минимально рабочим и как устроена проверка, в которой модель, написавшая код, не является тем, кто его принимает. Мы разберём, что именно ломается в инженерном процессе, когда код пишет не человек, и какие слои контроля должны появиться до репозитория, в IDE, в pull request и в CI/CD.

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

Для этого существует distributed tracing — распределённая трассировка.

В этой статье разберём, зачем она нужна, из чего состоит Trace, что такое Span, как между сервисами передаётся tracing context, какую роль в этом играет OpenTelemetry и где потом смотреть собранные данные.

Агент отработал полчаса и остановился. У вас спрашивают, что он делал.

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

Вопрос, на который нет ответа ни в одном из двух окон: откуда вообще берётся знание о том, что агент делал. Не что он про себя написал, а что он сделал.

Привет, Хабр! Меня зовут Александр, я работаю DevOps-инженером в команде Мир Plat.Form. Одна из достаточно сложных задач, которая стояла перед отделом DevOps, это миграция Jenkins в K8S и развертывание динамических (эфемерных) агентов.

Сама миграция Jenkins оказалась относительно простой частью. Но поскольку для сборки и деплоя наших приложений мы активно используем подход DinD (Docker-in-Docker) при переносе Jenkins-агентов в Kubernetes нам пришлось учитывать ряд технических особенностей.

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

Команда VK Cloud перевела материал Netflix о двух подходах к автомасштабированию Apache Flink. Сначала компания разработала собственный автоскейлер, который анализировал внешние метрики кластера и эффективно экономил ресурсы на простых потоковых конвейерах. Но с ростом числа stateful-задач и сложных графов обработки этого стало недостаточно.

В статье — о том, чем автомасштабирование на уровне отдельных операторов отличается от масштабирования всего кластера, как Flink Autoscaler использует показатель True Processing Rate, зачем Netflix запускает отдельный Temporal workflow для каждой задачи и почему ради стабильности иногда выгоднее сознательно оставить запас вычислительных ресурсов.

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

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

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

Сервер при этом в Москве, у российского хостера. И с ним всё в порядке.

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

Я тут недавно пытался попасть на бесплатные курсы от Aston, но получил отказ с такой формулировкой.

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

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

Сегодня хочу попробовать пройти тестовое задание от клауд.ру. Оно охватывает тот самый стек для devops, linux, docker, git, kubernetes.

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

Тестовое задание состоит из 4 задач, начнем с первой.

Kubernetes без магии и заучивания команд. Разберёмся, зачем он вообще нужен, как устроен кластер, чем Control Plane отличается от Worker Nodes и какую роль играют Pod, Scheduler, kubelet, etcd и другие основные компоненты.

Когда вы в последний раз проверяли свои репозитории на забытые токены? Пока вы скроллите ленту, боты парсят GitHub и подхватывают утекшие ключи за 2–3 минуты. Мы собрали главные дыры — от .env и CI-логов до ИИ-конфигов. В конце чек-лист, чтобы проверить себя за пару минут.

Когда говорят про High Availability, довольно быстро получается классическая картина: три сервера, балансировщик, кластер PostgreSQL, распределённое хранилище, мониторинг и ещё несколько компонентов, про которые никто не вспоминал, пока всё работало на одной виртуалке.

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

При этом хотелось выполнить несколько условий:

1) падение одной основной VM не должно останавливать систему;

2) PostgreSQL должен автоматически переключаться;

3) приложение должно понимать, на какой ноде ему разрешено выполнять активные операции;

4) пользовательские файлы должны оставаться доступными после переключения;

5) переключение не должно требовать ручного изменения DNS;

6) всё должно разворачиваться и обслуживаться через Ansible;

7) покупать третью полноценную машину только ради кворума не хотелось.

Последний пункт в итоге и породил архитектуру, которую между собой я называл «HA для бедных». Спойлер: третья машина всё-таки появилась. Но это маленький witness, который практически ничего не делает с точки зрения бизнес-нагрузки.