DevOps *

Grafana показывала, что горит, Mattermost доставлял уведомления, но после смены дежурного приходилось заново выяснять, кто занимается проблемой и когда ждать результат. Рассказываю, как мы собрали поверх них рабочее место с владельцами, ETA, общей историей, группировкой каскадных алертов, инцидентами и postmortem — без отдельной базы данных и без передачи управления состоянием LLM.

10 июля мы выпустили Monq 9.2.0. Если описать релиз одной фразой: пороги получили собственное рабочее пространство, научились учитывать расписание, автоматически находить свою КЕ в CMDB и хранить прогноз собственного состояния. Для работы на больших объёмах хранение порогов перенесено из PostgreSQL в ClickHouse, а связанный конвейер сервисов переработан.

Перед вами обзор обновления отечественной observability платформы зонтичного мониторинга от вендора. Тут не будет обещаний «предсказать любую аварию» и общих слов про AIOps. Разберём точную механику, новые фичи, работу дежурной смены, нюансы обновления и честную границу между тем, что уже работает в 9.2, и адаптивными порогами, которые появятся в 9.3.

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

С Днём системного администратора!

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

Все они — от эникея до SRE-инженера по сей день остаются самыми мифическими работниками ИТ-сферы. Они восхитительны, и у нас на это как минимум 10 аргументов.

С вашим праздником, админы!

Часто первое, что хочется сделать при неполадках в кластере, — уменьшить его и надеяться, что всё решится само. Получается, большой кластер = куча проблем?

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

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

Рано или поздно большинство зрелых проектов приходят к необходимости использовать как виртуальные машины, так и выделенные серверы. Это логично, поскольку под разные задачи требуются разные вычислительные ресурсы. Однако затем возникает проблема управления физическим оборудованием.

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

Привет! На связи Сергей, системный администратор в Selectel. Надеюсь, этот обзор будет полезен системным администраторам, DevOps-инженерам, архитекторам и всем, кто хочет избавиться от путаницы в процессах и управлять пулом гибридных вычислительных ресурсов через один инструмент.

В 2024 году была опубликована интересная статья, в которой описано, как за 54 дня обучения Llama 3 405B кластер Meta из 16 384 карт H100 пережил 419 внезапных прерываний, примерно по одному каждые три часа. 58,7% из них пришлись на GPU и их память. Процессоры за то же время отказали дважды. Свежее по такому масштабу никто ничего не публиковал, но тренд на Kubernetes с тех пор только усилился: по опросу CNCF за 2025 год, 82% пользователей контейнеров гоняют кубер в проде и 66% компаний с genAI-моделями держат на нем инференс.

Сам Kubernetes до сих пор как будто бы уверен, что отказы лечатся рестартами. Для stateless-сервиса это правда, а вот для пода с GPU нет: если контейнер упадет, то kubelet поднимет его заново на том же мертвом устройстве, и все пойдет по кругу.

Я Стас Погоржельский, технологический евангелист VK Cloud. Про то, как раздавать GPU через DRA, на Хабре уже писали, про отказоустойчивость кластеров в целом тоже. Эта статья про то, о чем обе умалчивают: что происходит после того, как выданное устройство умерло. Мы посмотрим на это наглядно: соберем отказный стенд, отберем у пода GPU и посмотрим глазами kubectl, кто и когда об этом узнает. А потом разберем механизмы 1.36, с которыми из этой ситуации впервые можно выйти без вечного Pending и без убийства ноды целиком.

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

Но потом всё изменилось. Сначала пришли облака с докерами и кубернетесом. Так появились девопсы. Профессия стала меняться. Следом в продвинутых компаниях появились корпадмины — вроде менеджеров, но с техническим уклоном.

В итоге значительную часть работы теперь можно выполнять вообще на удалёнке!

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

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

Сначала списал на случайные глюки у провайдеров. Мало ли, бывает. Но обращений становилось больше, а не меньше, и в какой-то момент стало ясно: это не совпадение, это системная штука. Пришлось лезть в сетевой дебаг с головой.

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

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

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

Подключил к AI-ассистенту 23 мцп сервера, они отдают 733 инструмента. Решил посчитать, сколько это в токенах: вышло 170 256 при окне модели в 131 072. То есть каталог инструментов в модель уже просто не влезает. Рассказываю, как я раздаю его агентам порциями, и почему у оркестратора в промте всего 180 токенов вместо 170 тысяч.

Короткая история про то, как штатная замена ноды оставила quorum-очереди с двумя членами вместо трёх, и почему cluster_status этого не показывает.

Стенд: OpenStack Caracal (2024.1), развёрнут kolla-ansible. RabbitMQ — кластер из трёх нод, quorum-очереди.

Прерываемые ноды в Managed Kubernetes появились ещё в феврале 2025 года, и Selectel анонсировал их отдельной статьёй в своём блоге — про экономию до 70% и про то, что «нода оперативно вернётся в кластер, а восстановление займёт не более минуты». Про поды, которые в этот момент на ноде работают, там не сказано ничего: ни про SIGTERM, ни про drain, ни про PDB, ни про потерю данных. Как раз эту дырку мы и полезли закрывать.

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

Мы в Okko строим IaC для VMware Cloud Director на базе Pulumi и Python, чтобы инженеры могли управлять ресурсами через простой и понятный YAML. Но когда счёт объектов в облаке пошёл на тысячи, цикл проверки и применения изменений катастрофически растянулся.

Под катом рассказываем, как с помощью Jaeger разобрали выполнение по операциям, нашли повторные обращения к VCD API, добавили in-memory кэширование и подобрали уровень параллельности с учётом архитектуры площадок. А заодно выяснили, почему увеличение PULUMI_PARALLEL не всегда ускоряет развёртывание.

Что получится, если собрать PostgreSQL, Airflow, JupyterLab, MinIO, Superset, шесть MCP-сервисов и локальную модель Ollama в одном Docker Compose-стенде?

Показываю полный путь синтетических промышленных данных: от витрин и проверок качества до Parquet-артефактов, MCP-инструментов и LLM-пояснений. Внутри — архитектура, воспроизводимый запуск, результаты проверок и открытый репозиторий.

SRE‑инженер Mindbox рассказывает, как DevOps‑команда столкнулась с неконтролируемым запуском хаос‑тестов, когда проводила плановые проверки с помощью Chaos Mesh. Что запускало «зомби‑тесты», какие пробовали решения и на чем в итоге остановились — делимся в статье.

Модель Security Champion многим кажется очевидной: если внутри команды появляется человек, который смотрит на продукт еще и с точки зрения безопасности, всем становится лучше. Но на деле путь от формального назначения до реально работающей роли гораздо длиннее и тернистее, чем кажется.

Привет, Хабр! На связи Илья Шаров (@issharov), Head of DevSecOps, и Николай Лузгин, DevSecOps Lead из МТС Web Services. Мы тоже через это проходили и в какой-то момент пересмотрели весь подход. Если в прошлый раз мы рассказывали о пользе, ролях и о том, что стоит предусмотреть при внедрении Security Champion, то сегодня поделимся опытом трансформации: как сместили фокус на вовлеченность, развитие компетенций и естественное встраивание безопасности в повседневную работу команд.

Всё началось с обычной бытовой боли. У меня был сайт, и сайту иногда нужно было сказать мне что-то важное: «заказ оплачен», «диск на 91%», «пришёл ответ от банка».

Так родилась идея: сервис, куда сайт стучится одним HTTP-запросом, а на всех твоих устройствах через секунду загорается уведомление. Я назвал его Pheme.

А дальше случилось то, что случается со всеми пет-проектами. Ты пишешь «просто релей уведомлений», потом смотришь на код и понимаешь, что у тебя уже есть пользователи, устройства, каналы, история сообщений, лента, комментарии — и остаётся дописать «всего лишь» шифрование, звонки и федерацию, чтобы получился полноценный мессенджер. Что я и сделал.

Управление десятками и сотнями Helm-релизов быстро перестает быть тривиальной задачей, особенно когда появляются зависимости между релизами, CRD, несколько окружений и своя логика деплоя. 

Меня зовут Владимир Фидунин, я работаю в команде мессенджера VK WorkSpace. В статье расскажу, как мы прошли путь от Puppet + Helm до Helmwave и почему в итоге он стал для нас универсальным инструментом управления Helm-релизами. 

Разработчикам регулярно требовались виртуальные машины, но self-service не существовал. Образ, ресурсы, сеть и доступы настраивала инфраструктурная команда. По отдельности операции были несложными, но в сумме пользователи ждали, а инженерное время уходило на повторяемую ручную работу.

Так появился внутренний dev cloud на KubeVirt. Разработчик сам создаёт VM из поддерживаемого шаблона, управляет lifecycle и портами, меняет ресурсы, смотрит Events, метрики и serial-консоль. Платформа сохраняет контроль над доступами, шаблонами, бюджетами команд и ёмкостью нод.

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

Я давно привыкла первым делом спрашивать «а как это упадет?». Когда в наш ландшафт пришли ИИ‑агенты, выяснилось интересное: привычные ответы на этот вопрос здесь просто не работают. Агент в проде, дашборды настроены по классике: latency, error rate, uptime. Алертов нет, агент исправно отвечает на каждый запрос. А то, что он три дня подряд уверенно врет, вы узнаете из жалобы пользователя, и никак иначе.

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