DevOps *

Падает один шлюз - и дежурному прилетает пачка уведомлений: молчат хосты за ним, гаснет uptime-монитор, срабатывают метрические пороги, горит SLO. Событие одно, уведомлений десятки. Разбираю, как собрать такой каскад в одну карточку инцидента и почему наивная реализация ломается: почему группировать надо по верхнему упавшему предку, а не по прямому родителю; что делать, когда события приходят в обратном порядке; почему “молчит, потому что за него сказал корень” и “не эскалируется, потому что родитель лежит” - это два разных состояния, которые нельзя склеивать; и где в такой системе обязательно выбирать шум вместо тишины. С кодом обхода графа, схемой таблиц и списком граблей.

29 августа Anthropic разослала еженедельный дайджест по Claude Code. Пересказ на русском: /resume подхватывает терминальную сессию в десктопном приложении, сессию на своей машине можно запустить с телефона через Remote Control, субагенту можно дать собственную память между сессиями строкой memory в frontmatter, а /color и /rename помогают различать несколько открытых терминалов. Плюс версии 2.1.243–2.1.248: режим --restricted, автоматический баг-репорт, редактирование правил авторежима из /permissions, часовой prompt cache, zstd-сжатый бинарник CLI и починенные десктопные сессии.

Статья посвящена завершению поддержки ingress-nginx и рассматривает это событие не просто как необходимость заменить один Kubernetes-компонент на другой, а как повод пересмотреть архитектуру маршрутизации в Kubernetes-платформе. В статье показано, как со временем простой Ingress превращается в набор NGINX-specific annotations и накопленного технического долга, который сложно поддерживать и объяснять. Так же разбираются возможности Gateway API, разделение ответственности между Platform-командой и разработчиками, а также подходы к миграции существующей инфраструктуры. Особое внимание уделяется аудиту текущих Ingress, постепенному внедрению новой модели и отказу от массовой миграции ради миграции. Основная идея статьи — не просто перенести сотни Ingress в HTTPRoute, а использовать изменения для построения более понятной, управляемой и масштабируемой Kubernetes-платформы.

В рабочем чате: «Сайт не открывается, сертификат истёк», следом — скриншот с 502. Первый рефлекс — certbot renew и перезагрузить nginx. Иногда помогает. Иногда сайт после этого не поднимается совсем.

Дело в том, что «всё из-за сертификата» — это на самом деле две разные поломки с разными решениями: сертификат не продлился или продлился, но сервер отдаёт старое. В выдаче их валят в кучу, поэтому советы вроде «просто сделай certbot renew» либо не помогают, либо роняют сайт по-настоящему.

Разбираем по шагам: как за десять минут понять, какая из двух у вас, вернуть HTTPS и настроить продление так, чтобы это не повторилось.

Один и тот же артефакт разворачивается монолитом и кластером микросервисов. Те же модули, один дашборд на все воркеры, горячая замена без рестарта контейнера.

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

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

redb.Tsak предлагает другой обмен: плоскость эксплуатации живёт в рантайме, и она одна и та же независимо от того, запущен у вас один воркер или девять. Кластер, дашборд, REST API, CLI, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

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

Merge queue гоняет полный сьют один раз на каждый пул-реквест в группе. Четверо ждут посадки — четыре полных прогона, причём последний из них уже содержит три остальных. Обязаны ли те три прогоняться? Мы построили одноразовый стенд, прогнали на нём четыре способа останавливать лишние прогоны и померили каждый: один сажает сломанный код, один залипает намертво, один безопасен и стоит ровно столько же, сколько мы платим сейчас. Четвёртый — наш, и он экономит около 19 машинных минут на посаженный пул-реквест ценой примерно четырёх минут ожидания.

Одна минута macOS-раннера в GitHub Actions стоит десять минут Linux. Я перенёс iOS-сборку Flutter-приложения в Xcode Cloud: с ~45 оплачиваемых минут на релиз до 6, без .p12 и профилей в секретах, с тремя shell-скриптами вместо 90 строк YAML. Внутри — схема тегов ios/v* и android/v*, настройки Xcode Cloud, которые молча сжигают compute-часы, и таблица семи падений первого живого прогона — ни одно из них не было ошибкой миграции. Плюс чек-лист и открытый скилл, который из этого вырос.

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

Вводный вебинар предварял стартующий 1 сентября 2026 года курс «Автоматизированное тестирование в 1С». Его провел ведущий разработчик ИТ-лаборатории Инфостарта и автор курса Александр Кунташов. Эксперт показал, как с помощью ИИ и Vanessa Automation пройти путь от исходной инструкции до работающего автотеста, а затем отдельно разобрал вопросы участников о безопасности данных, MCP, сопровождении сценариев и интеграции с CI/CD...

В рамках этой статьи расскажу, как реализовалась идея о псевдорандоме и магии внутри пайплайна, и как я выложил инструмент который гадает «удачный ли будет релиз?» с помощью Таро на GitHub Market.

Ситуация, знакомая многим командам: в кластере Kubernetes живут обычные бизнес сервисы, нагрузка на которые днём растёт, а ночью падает. Обычно используют два плохих варианта: держать статический пул нод под дневной пик, которые ночью простаивают и стоят денег, или положиться на cluster autoscaling — и тогда при дневном росте нагрузки бизнес-поды проведут в статусе Pending до создания новой ноды.

Проблема ожидания, пока Cluster Autoscaler развернёт новую ноду, решается паттерном node overprovisioning, настраиваемым через PriorityClass и механизмы Cluster Autoscaler: мы заранее запускаем ничего не делающие capacity-overprovisioning поды (в документации Kubernetes они называются placeholder-подами), которые занимают небольшую часть ресурсов нод. Когда приходит нагрузка и реплики бизнес-приложений увеличиваются — поды бизнес-приложений немедленно занимают освободившееся место, вытесняя capacity-overprovisioning под за секунды. Вытесненный capacity-overprovisioning под уходит в Pending, Cluster Autoscaler добавляет ноду.

Ключевая выгода паттерна — экономия. Ночью и утром, когда нагрузка падает, KEDA снижает число реплик бизнес-приложения, Cluster Autoscaler удаляет недозагруженные ноды, и кластер схлопывается до минимального числа нод. Утром при росте нагрузки capacity-overprovisioning поды отдают место мгновенно.

В этой статье разберём, как это устроено внутри, и развернём демо-стенд: от KEDA-автоскейлинга бизнес-приложения по RPS, который генерирует генератор нагрузки, до живого вытеснения capacity-overprovisioning подов, которое можно наблюдать своими глазами в kubectl get events.

«1С тормозит» — это не техническое утверждение, а начало спора. Бизнес говорит «тормозит», подрядчик говорит «у нас всё в норме», и обе стороны правы, потому что меряют разное: пользователь меряет секунды до открытия документа, подрядчик — загрузку CPU на сервере.

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

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

Я в одиночку делаю и эксплуатирую платформу мониторинга: метрики, логи и трейсы для чужой инфраструктуры, мультитенантно, на VictoriaMetrics cluster / VictoriaLogs / VictoriaTraces, FastAPI, nginx и Postgres. Прод — один сервер: Debian 12, 4 CPU, 8 ГБ, четырнадцать контейнеров.

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

Это статья не про то, «как правильно проводить НТ» — таких статей достаточно. Она про то, какие именно виды нагрузки ломают систему приёма телеметрии, почему привычный сценарий «загоним 1000 rps через k6 и посмотрим на перцентили» проходит мимо всех трёх, и как выглядит воспроизводимый прогон, который эти отказы ловит.

Все цифры ниже — с живого сервера, не синтетика.

Полгода на Arch, одно обновление ядра и AmneziaWG выходит из строя. Snapper молчит, бэкап сломан. Решил попробовать NixOS…

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

Для примера будем использовать наш продукт для просмотра топологии и верификации(EDA) и расскажем, как мы построили его лицензирование.

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

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

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

В этот момент плохо работает модель «один бинарь и проверка лицензии есть или нет».

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

Восстановление данных буду делать с помощью второго PostgreSQL контейнера. Если кратко - данные WAL и base_backup будут прокидываться с помощью volume и контейнер будет стартовать с новыми данными.

Пока что рабочий стенд будет ограничиваться PostgreSQL 17 в Docker (без S3, Kubernetes, автоматизации и т.п), потом возможно сделаю дополнительные статьи, охватывающие более сложные production случаи.

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

Эту тему подробно разобрали на восьмом митапе MWS для DevOps и SRE. Эксперты из MTC Web Services и Orion Soft показали разные стороны перехода к агентной разработке и поделились кейсами, как ИИ потихоньку превращается в виртуального сотрудника — агента, действующего без постоянного сопровождения человека, и что для этого приходится менять в инженерных процессах.

Хранилище артефактов, как правило, находится в критическом месте инфраструктуры компании: между сборкой продукта и внешним миром. Через него команды получают зависимости, публикуют собственные пакеты и передают артефакты дальше по цепочке поставки. Если такой сервис недоступен или его содержимое нельзя считать доверенным, то проблема быстро выходит за пределы одной лишь команды DevOps. Останавливаются сборки и поставки программного обеспечения, а вредоносный или уязвимый пакет может попасть во множество проектов.

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

В первой части мы разобрали, почему Aeza ушла со сторонней платформы и как AVM устроен в общих чертах. Здесь уровень ниже: путь запроса от вызова до задачи на конкретной ноде, устройство конвейеров, поведение при сбоях и то, где система хранит состояние виртуальных машин.

Любой запрос клиента заканчивается цепочкой задач на ноде: скачать образ, создать диск, поднять машину. Этими цепочками управляет AVM — собственная система управления виртуализацией.

Мы списали uv со счетов. А потом он ускорил наш CI на 80%

В Python-сообществе вокруг uv уже несколько месяцев шум: быстрый резолвинг, один инструмент вместо зоопарка утилит и обещание ускорить привычный workflow. Звучит хорошо — пока не проверишь на своём стеке.

Мы так и сделали. Взяли один микросервис: Python 3.14, 37 прямых зависимостей, 153 пакета в lock-файле, приватные пакеты и внутренний Nexus. Ожидание было простым: если uv действительно быстрее Poetry, миграция окупится сама.

Локально получилось наоборот. Резолвинг — да, быстрее. Установка по готовому lock-файлу — нет, иногда даже медленнее. Эксперимент закрыли и остались на Poetry.

Через несколько недель пришлось вернуться. Не из любопытства, а из-за алерта Trivy и сюрпризов Poetry 2 с корпоративными индексами. И вот тогда uv показал себя совсем в другом месте — в CI.

В статье разберем:

- почему локальный бенчмарк uv vs Poetry нас обманул;
- как Poetry 2 сломал привычную разработку без VPN;
- зачем мы писали парсер poetry.lock → requirements.txt и почему это оказалось костылём;
- как точечная замена Poetry на uv sync в пайплайне сократила время с 5:10 до 2:50;
- почему в итоге uv стал единым стандартом и локально, и в CI.

Коротко: если инструмент не выиграл с первого прогона — это ещё не значит, что он бесполезен. Часто вы просто мерили не то узкое место.