<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Стебаков · SRE / DevOps</title>
    <link>https://stebas.com/ru/</link>
    <description>Заметки из продакшена и домашней лаборатории: апгрейды, миграции, инциденты и логика решений.</description>
    <language>ru</language>
    <item>
      <title>RDS отказывал в подключениях при 10% CPU: дефолтные пулы, умноженные на реплики</title>
      <link>https://stebas.com/ru/posts/rds-connection-ceiling-npgsql-pools/</link>
      <guid>https://stebas.com/ru/posts/rds-connection-ceiling-npgsql-pools/</guid>
      <pubDate>Mon, 12 Oct 2026 00:00:00 GMT</pubDate>
      <description>Нагрузочные тесты упирались в ровное плато ~420 подключений, и просили «базу побольше». Реальный потолок — max_connections против дефолтных пулов Npgsql.</description>
    </item>
    <item>
      <title>Calico в Ready и без ошибок, а каждый новый под полминуты недоступен</title>
      <link>https://stebas.com/ru/posts/calico-xdp-resync-new-pod-blackhole/</link>
      <guid>https://stebas.com/ru/posts/calico-xdp-resync-new-pod-blackhole/</guid>
      <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
      <description>После апгрейда Calico свежие поды 15–42 секунды сидели в чёрной дыре. Felix крутился в цикле XDP-resync, который видно только тестом «новый под ↔ новый под между нодами».</description>
    </item>
    <item>
      <title>Kubernetes с 1.32 до 1.37 за день, пять хопов, без kubespray, которым кластер собирали</title>
      <link>https://stebas.com/ru/posts/kubernetes-five-hop-upgrade-without-kubespray/</link>
      <guid>https://stebas.com/ru/posts/kubernetes-five-hop-upgrade-without-kubespray/</guid>
      <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
      <description>Bare-metal кластер на EOL-версии, потерянный инвентарь kubespray и бинарники вне пакетного менеджера. Как прошли пять хопов kubeadm за один день и грабли, которых не было ни в одном плане.</description>
    </item>
    <item>
      <title>Минуту работало, потом таймауты: MetalLB L2 с kube-proxy ipvs без strictARP</title>
      <link>https://stebas.com/ru/posts/metallb-l2-ipvs-strictarp/</link>
      <guid>https://stebas.com/ru/posts/metallb-l2-ipvs-strictarp/</guid>
      <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
      <description>Перевод хостов на новый LoadBalancer IP работал недолго, потом внешний балансировщик увидел таймауты на L4. На ARP за один и тот же IP отвечали все ноды.</description>
    </item>
    <item>
      <title>Сертификаты истекли по расписанию. Алерт неделю кричал — в пустоту</title>
      <link>https://stebas.com/ru/posts/kubeadm-certs-expired-alert-into-null/</link>
      <guid>https://stebas.com/ru/posts/kubeadm-certs-expired-alert-into-null/</guid>
      <pubDate>Fri, 09 Oct 2026 00:00:00 GMT</pubDate>
      <description>kubeadm-кластер потерял control plane ровно через год после установки. Алерт об истечении горел семь дней, но у Alertmanager был только receiver null.</description>
    </item>
    <item>
      <title>Алерт сработал, и никто его не увидел: метка cluster потерялась в агрегации</title>
      <link>https://stebas.com/ru/posts/alert-lost-cluster-label/</link>
      <guid>https://stebas.com/ru/posts/alert-lost-cluster-label/</guid>
      <pubDate>Wed, 07 Oct 2026 00:00:00 GMT</pubDate>
      <description>Нода четыре часа сидела на 90–98% CPU и закончила OOM kill. Алерт на CPU сработал, но avg by(instance) выкинул метку, по которой выбирали все маршруты и дашборды.</description>
    </item>
    <item>
      <title>Kubernetes 1.33 → 1.36 и Calico → Cilium за один день</title>
      <link>https://stebas.com/ru/posts/k8s-136-cilium-in-one-day/</link>
      <guid>https://stebas.com/ru/posts/k8s-136-cilium-in-one-day/</guid>
      <pubDate>Wed, 30 Sep 2026 00:00:00 GMT</pubDate>
      <description>Репетиция на домашней лаборатории: три хопа Kubernetes, замена CNI на Cilium без kube-proxy и отказ от ретированного ingress-nginx в пользу Gateway API — почему контролируемый big-bang оказался безопаснее живой миграции и какие грабли стоит знать заранее.</description>
    </item>
    <item>
      <title>Боевой сертификат истёк, и никто не заметил: внешний прокси прикрыл аварию собой</title>
      <link>https://stebas.com/ru/posts/expired-tls-hidden-by-front/</link>
      <guid>https://stebas.com/ru/posts/expired-tls-hidden-by-front/</guid>
      <pubDate>Thu, 17 Sep 2026 00:00:00 GMT</pubDate>
      <description>Все публичные хосты отдавали 200, пока кластер отдавал просроченный wildcard. Прокси со своей TLS-терминацией спрятал аварию; настоящая находка — отсутствие алерта на истечение.</description>
    </item>
    <item>
      <title>multipathd захватил том Longhorn: «mount point busy», хотя ничего не смонтировано</title>
      <link>https://stebas.com/ru/posts/multipathd-hijacks-longhorn/</link>
      <guid>https://stebas.com/ru/posts/multipathd-hijacks-longhorn/</guid>
      <pubDate>Thu, 17 Sep 2026 00:00:00 GMT</pubDate>
      <description>Под пять дней висел в Init, 2413 попыток монтирования, полный ребут не помог. multipathd построил карту поверх iSCSI-устройства Longhorn и держал его открытым.</description>
    </item>
    <item>
      <title>Ребаланс-шторм оказался обычным деплоем: порог, который растёт вместе с группой</title>
      <link>https://stebas.com/ru/posts/rebalance-storm-deploy-signature/</link>
      <guid>https://stebas.com/ru/posts/rebalance-storm-deploy-signature/</guid>
      <pubDate>Wed, 16 Sep 2026 00:00:00 GMT</pubDate>
      <description>Алерт на ребалансы Kafka горел на 60 в час при каждом релизе. Метрика суммировалась по 40 консьюмерам и усреднялась по скользящему часу — алерт описывал прошлое.</description>
    </item>
    <item>
      <title>Argo CD показывал Synced, а API-сервер молча выкинул мой фикс</title>
      <link>https://stebas.com/ru/posts/argocd-synced-but-field-pruned/</link>
      <guid>https://stebas.com/ru/posts/argocd-synced-but-field-pruned/</guid>
      <pubDate>Tue, 15 Sep 2026 00:00:00 GMT</pubDate>
      <description>Месяцы без метрик, фикс уже в git и зелёный Synced. Поля не было в схеме CRD, API-сервер его отрезал, и никто не пожаловался.</description>
    </item>
    <item>
      <title>Liveness-проба, привязанная к чужой сети: 330 рестартов, которые ничего не чинили</title>
      <link>https://stebas.com/ru/posts/liveness-probe-external-dependency/</link>
      <guid>https://stebas.com/ru/posts/liveness-probe-external-dependency/</guid>
      <pubDate>Tue, 15 Sep 2026 00:00:00 GMT</pubDate>
      <description>Две одинаковые реплики cloudflared — 330 и 13 рестартов. Liveness проверяла туннель до edge, поэтому каждая икота аплинка превращалась в SIGKILL.</description>
    </item>
    <item>
      <title>Экран загрузки был retry-циклом, а не зависанием — и ребут был не нужен</title>
      <link>https://stebas.com/ru/posts/retry-loop-not-a-hang/</link>
      <guid>https://stebas.com/ru/posts/retry-loop-not-a-hang/</guid>
      <pubDate>Mon, 14 Sep 2026 00:00:00 GMT</pubDate>
      <description>Игра на моей Linux-машине зависала на экране загрузки, и известным лекарством был полный ребут. Пять секунд счётчиков из /proc показали горячий retry-цикл, который заканчивается одним SIGTERM.</description>
    </item>
    <item>
      <title>Три отказа алертинга из одного корня: имя там, где должен быть ID</title>
      <link>https://stebas.com/ru/posts/mutable-name-vs-contract/</link>
      <guid>https://stebas.com/ru/posts/mutable-name-vs-contract/</guid>
      <pubDate>Mon, 07 Sep 2026 00:00:00 GMT</pubDate>
      <description>Кто-то переименовал канал в Slack, и доставка алертов продакшен-системы молча умерла. Это был третий отказ на одном и том же идентификаторе — все прошлые фиксы меняли транспорт и оставляли имя.</description>
    </item>
    <item>
      <title>Kafka на 94 % диска, 17 часов в запасе и retention, который хранил вдвое больше</title>
      <link>https://stebas.com/ru/posts/kafka-retention-segment-roll/</link>
      <guid>https://stebas.com/ru/posts/kafka-retention-segment-roll/</guid>
      <pubDate>Sun, 06 Sep 2026 00:00:00 GMT</pubDate>
      <description>Трафик вырос в 150 раз, а тома никто не пересматривал. Хуже того, при дефолтном роллинге сегментов retention в 7 дней на деле означал 7–14. Как мы выиграли время и устранили причину.</description>
    </item>
    <item>
      <title>Basic auth пропал на 80-м порту после переезда с Ingress на Gateway API</title>
      <link>https://stebas.com/ru/posts/gateway-api-policy-per-listener/</link>
      <guid>https://stebas.com/ru/posts/gateway-api-policy-per-listener/</guid>
      <pubDate>Tue, 01 Sep 2026 00:00:00 GMT</pubDate>
      <description>Все статусы зелёные, мой curl возвращал 401. А вход в WordPress был открыт всем: Gateway API привязывает политику к одному listener'у, а аннотации Ingress покрывали все порты.</description>
    </item>
    <item>
      <title>NotReady шесть часов, а нода всё это время была жива</title>
      <link>https://stebas.com/ru/posts/notready-was-memory-thrashing/</link>
      <guid>https://stebas.com/ru/posts/notready-was-memory-thrashing/</guid>
      <pubDate>Mon, 31 Aug 2026 00:00:00 GMT</pubDate>
      <description>Все сигналы говорили, что нода мертва. На деле она задыхалась от нехватки памяти, а очевидный фикс — удалить ноду и принудительно отцепить том — был в одной команде от порчи базы.</description>
    </item>
    <item>
      <title>Звёздочка в середине пути Vault — не wildcard</title>
      <link>https://stebas.com/ru/posts/vault-acl-mid-path-glob/</link>
      <guid>https://stebas.com/ru/posts/vault-acl-mid-path-glob/</guid>
      <pubDate>Mon, 31 Aug 2026 00:00:00 GMT</pubDate>
      <description>Протухший токен уронил оператор секретов. Его перевыпуск вскрыл более старый баг: 27 политик Vault со * в середине пути молча запрещали то, что объявляли, и прятали избыточные права.</description>
    </item>
    <item>
      <title>Реплика Postgres 23 часа крутилась в цикле pg_rewind: пересоздавать, а не чинить</title>
      <link>https://stebas.com/ru/posts/cnpg-replica-pg-rewind-loop/</link>
      <guid>https://stebas.com/ru/posts/cnpg-replica-pg-rewind-loop/</guid>
      <pubDate>Fri, 28 Aug 2026 00:00:00 GMT</pubDate>
      <description>После failover реплика CloudNativePG не смогла сделать rewind: её WAL-сегменты были нулевого размера, а каталог данных — в десять раз меньше, чем у primary. 23 часа никто не заметил, потому что метрики оператора не собирались.</description>
    </item>
    <item>
      <title>Error budget в VictoriaMetrics: recording rules, burn-rate алерты и одна честная панель</title>
      <link>https://stebas.com/ru/posts/error-budget-burn-rate-alerts/</link>
      <guid>https://stebas.com/ru/posts/error-budget-burn-rate-alerts/</guid>
      <pubDate>Wed, 26 Aug 2026 00:00:00 GMT</pubDate>
      <description>Как мы собрали error budget для сервисов первого уровня из уже существующих метрик: SLO-цели по сервисам, multi-window burn-rate алерты, ряд в Grafana — и почему отрицательный бюджет сразу после запуска не был инцидентом.</description>
    </item>
    <item>
      <title>Один алерт на p99, пять медленных маршрутов, пять разных причин</title>
      <link>https://stebas.com/ru/posts/latency-triage-per-route/</link>
      <guid>https://stebas.com/ru/posts/latency-triage-per-route/</guid>
      <pubDate>Wed, 26 Aug 2026 00:00:00 GMT</pubDate>
      <description>Алерт на латентность уровня сервиса не называл ни одного эндпоинта. Разбивка по маршрутам показала внешний шлюз, проверку капчи, вызов провайдера — и набор ловушек измерения, которые увели бы нас не туда.</description>
    </item>
    <item>
      <title>Переезд продового Postgres с RDS Multi-AZ instance на Multi-AZ DB cluster</title>
      <link>https://stebas.com/ru/posts/rds-instance-to-multi-az-cluster-cutover/</link>
      <guid>https://stebas.com/ru/posts/rds-instance-to-multi-az-cluster-cutover/</guid>
      <pubDate>Mon, 24 Aug 2026 00:00:00 GMT</pubDate>
      <description>Плановый cutover почти без потери данных — и три ловушки: «техработы», которые не остановили запись, пароли, которые RDS не даёт скопировать, и дамп за 25 минут через VPN против 31 секунды внутри VPC.</description>
    </item>
    <item>
      <title>Лаг упал в ноль, а ничего не починилось: зависший Kafka-консьюмер, спрятанный переименованием group.id</title>
      <link>https://stebas.com/ru/posts/kafka-consumer-stall-hidden-by-group-rename/</link>
      <guid>https://stebas.com/ru/posts/kafka-consumer-stall-hidden-by-group-rename/</guid>
      <pubDate>Fri, 21 Aug 2026 00:00:00 GMT</pubDate>
      <description>Лаг консьюмера рос пять дней, потом упал в ноль и там остался. Выглядело как «само рассосалось». На деле консьюмер завис, метрика исчезла, а алерт зарезолвился сам.</description>
    </item>
    <item>
      <title>Профилируем утечку памяти в Python на проде с memray — и авария, которую мы устроили по дороге</title>
      <link>https://stebas.com/ru/posts/python-memory-leak-memray-in-production/</link>
      <guid>https://stebas.com/ru/posts/python-memory-leak-memray-in-production/</guid>
      <pubDate>Mon, 17 Aug 2026 00:00:00 GMT</pubDate>
      <description>Бэкенд падал по OOM каждые 10–15 часов. Почасовые снимки memray на живом поде нашли утечку в библиотечных middleware, а не в коде приложения — после того как первая попытка положила прод на семь минут.</description>
    </item>
    <item>
      <title>Переезд продового кластера с Longhorn на LINSTOR — и ожидание, которое не сбылось</title>
      <link>https://stebas.com/ru/posts/longhorn-to-linstor-migration/</link>
      <guid>https://stebas.com/ru/posts/longhorn-to-linstor-migration/</guid>
      <pubDate>Sun, 16 Aug 2026 00:00:00 GMT</pubDate>
      <description>Зачем мы заменили Longhorn на LINSTOR/DRBD на self-managed кластере, как каждая нагрузка переезжала своим способом и что пошло не так по дороге.</description>
    </item>
    <item>
      <title>С ingress-nginx на Envoy Gateway без простоя: 27 Ingress, 39 HTTPRoute</title>
      <link>https://stebas.com/ru/posts/ingress-nginx-to-envoy-gateway/</link>
      <guid>https://stebas.com/ru/posts/ingress-nginx-to-envoy-gateway/</guid>
      <pubDate>Sat, 15 Aug 2026 00:00:00 GMT</pubDate>
      <description>ingress-nginx ретирован и блокирует апгрейды Kubernetes. Как мы перевели 16 публичных хостов на Envoy Gateway: подняли новый вход рядом со старым и в самом конце поменяли только адрес.</description>
    </item>
    <item>
      <title>Перевод CloudNativePG на плагин Barman Cloud без разрыва архива</title>
      <link>https://stebas.com/ru/posts/cnpg-barman-cloud-plugin-switchover/</link>
      <guid>https://stebas.com/ru/posts/cnpg-barman-cloud-plugin-switchover/</guid>
      <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
      <description>CNPG убирает встроенную поддержку barmanObjectStore. У переключения нет валидного промежуточного состояния, у базы не было ни одного базового бэкапа, а один путь решает, работает ли ещё point-in-time recovery.</description>
    </item>
    <item>
      <title>Четыре проверки, которые врали, пока система была здорова</title>
      <link>https://stebas.com/ru/posts/four-checks-that-lied/</link>
      <guid>https://stebas.com/ru/posts/four-checks-that-lied/</guid>
      <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
      <description>За один день миграций платформы четыре проверки сообщали об ошибке, хотя всё было в порядке. Когда один сигнал спорит со всеми остальными, первым подозревайте сам сигнал.</description>
    </item>
    <item>
      <title>Алерты, которые не могут сработать: слепой ServiceMonitor и мёртвый канал доставки</title>
      <link>https://stebas.com/ru/posts/alerts-that-cannot-fire/</link>
      <guid>https://stebas.com/ru/posts/alerts-that-cannot-fire/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Пир Vault 32 часа был sealed, а секреты неделю не синхронизировались — при алерте VaultSealed в репозитории и здоровом Alertmanager. Инцидент спрятали два независимых сбоя.</description>
    </item>
    <item>
      <title>«Дрейф ядер» оказался дрейфом аптайма: патчи ставились, ребутов не было</title>
      <link>https://stebas.com/ru/posts/kernel-drift-was-uptime-drift/</link>
      <guid>https://stebas.com/ru/posts/kernel-drift-was-uptime-drift/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Три разных ядра на семи нодах выглядели как незавершённые волны патчей и увели расследование по ложному следу. Патчи на всех нодах были одинаковые, различался только аптайм.</description>
    </item>
    <item>
      <title>kubectl patch --type merge стёр CoreDNS, а все проверки остались зелёными</title>
      <link>https://stebas.com/ru/posts/kubectl-merge-patch-wiped-coredns/</link>
      <guid>https://stebas.com/ru/posts/kubectl-merge-patch-wiped-coredns/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Однострочное обновление образа заменило всю спецификацию контейнера. CoreDNS потерял конфиг, тихо откатился на плагин whoami и отвечал на всё NOERROR без ответа.</description>
    </item>
    <item>
      <title>Замена MetalLB на Cilium LB IPAM без единого потерянного запроса</title>
      <link>https://stebas.com/ru/posts/metallb-to-cilium-lb-ipam/</link>
      <guid>https://stebas.com/ru/posts/metallb-to-cilium-lb-ipam/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>В кластере был ровно один LoadBalancer IP, и от него зависели все маршруты. Как я передал его от MetalLB к Cilium без единой ошибки — дав обоим контроллерам поработать одновременно.</description>
    </item>
    <item>
      <title>Перевод Vault с Shamir на transit auto-unseal и четыре ловушки по дороге</title>
      <link>https://stebas.com/ru/posts/vault-transit-auto-unseal/</link>
      <guid>https://stebas.com/ru/posts/vault-transit-auto-unseal/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Каждый рестарт пода Vault заканчивался запечатанным хранилищем и замороженной синхронизацией секретов. Как мы добавили transit-провайдер, мигрировали raft-кластер из трёх нод и на чём споткнулись.</description>
    </item>
    <item>
      <title>Vault запечатывался сам. Причиной была 15-минутная заморозка VM ниже кластера</title>
      <link>https://stebas.com/ru/posts/vm-backup-freeze-cascade/</link>
      <guid>https://stebas.com/ru/posts/vm-backup-freeze-cascade/</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Четыре seal'а Vault за три недели, каждый разбирали как отдельный инцидент. Анализ пауз в journald показал, что гипервизор замораживает VM во время бэкапа, а Longhorn превращает это в каскад.</description>
    </item>
    <item>
      <title>Апгрейд GitLab и два сигнала, которые врали</title>
      <link>https://stebas.com/ru/posts/gitlab-upgrade-signals-that-lie/</link>
      <guid>https://stebas.com/ru/posts/gitlab-upgrade-signals-that-lie/</guid>
      <pubDate>Wed, 12 Aug 2026 00:00:00 GMT</pubDate>
      <description>Рядовой минорный апгрейд self-hosted GitLab в Docker. Предварительная проверка насчитала 32 незавершённые миграции, а контейнер стал healthy, ничего не обслуживая.</description>
    </item>
    <item>
      <title>Как обновить ОС на семи нодах Kubernetes так, чтобы никто не заметил</title>
      <link>https://stebas.com/ru/posts/rolling-os-update-seven-nodes/</link>
      <guid>https://stebas.com/ru/posts/rolling-os-update-seven-nodes/</guid>
      <pubDate>Wed, 12 Aug 2026 00:00:00 GMT</pubDate>
      <description>Поочерёдное обновление Ubuntu в кластере, который хранит всё своё состояние сам. Предварительные проверки превратили страшную работу в скучную, а темп задавал Longhorn.</description>
    </item>
    <item>
      <title>Одна забытая DHCP-опция положила весь Kubernetes-кластер</title>
      <link>https://stebas.com/ru/posts/stale-dhcp-route-killed-cluster/</link>
      <guid>https://stebas.com/ru/posts/stale-dhcp-route-killed-cluster/</guid>
      <pubDate>Mon, 10 Aug 2026 00:00:00 GMT</pubDate>
      <description>После ребута хоста около пятидесяти подов ушли в крашлуп, хотя все ноды были Ready. Причина — забытая DHCP-опция classless routes, которая молча убрала шлюз по умолчанию.</description>
    </item>
    <item>
      <title>Смержено, засинкано, смонтировано — и всё равно не алертит: vmalert без hot reload</title>
      <link>https://stebas.com/ru/posts/vmalert-rules-no-hot-reload/</link>
      <guid>https://stebas.com/ru/posts/vmalert-rules-no-hot-reload/</guid>
      <pubDate>Fri, 07 Aug 2026 00:00:00 GMT</pubDate>
      <description>Новые правила для Kafka прошли через Git и Argo CD в ConfigMap, но vmalert их так и не начал оценивать. GitOps-конвейер оборвался на последнем шаге.</description>
    </item>
    <item>
      <title>Панель Grafana, которая говорит, когда под упадёт по OOM</title>
      <link>https://stebas.com/ru/posts/grafana-capacity-forecast-dashboard/</link>
      <guid>https://stebas.com/ru/posts/grafana-capacity-forecast-dashboard/</guid>
      <pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
      <description>Как превратить тренд памяти в ETA до OOM и до заполнения диска на PromQL, два бага, из-за которых панель врала, и утечка, которую она поймала в первый же день.</description>
    </item>
    <item>
      <title>ONLINE_UNCERTAIN: когда MySQL-оператор и база не согласны</title>
      <link>https://stebas.com/ru/posts/innodb-online-uncertain-rescan/</link>
      <guid>https://stebas.com/ru/posts/innodb-online-uncertain-rescan/</guid>
      <pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
      <description>Router флапает, оператор два дня висит в блокировке, CRD застыл на 2/3 — а все три члена InnoDB Cluster здоровы. Лечится одним rescan метаданных.</description>
    </item>
    <item>
      <title>Vault Secrets Operator замолчал после seal — и рестарт его не разбудил</title>
      <link>https://stebas.com/ru/posts/vso-stuck-after-vault-seal/</link>
      <guid>https://stebas.com/ru/posts/vso-stuck-after-vault-seal/</guid>
      <pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
      <description>38 из 43 VaultStaticSecret два дня висели с замёрзшей ошибкой. Unseal Vault и рестарт оператора ничего не дали; помогло изменение одного поля в spec.</description>
    </item>
    <item>
      <title>Петля логина в WordPress, которая случалась только иногда</title>
      <link>https://stebas.com/ru/posts/wordpress-redirect-loop-per-pod-salts/</link>
      <guid>https://stebas.com/ru/posts/wordpress-redirect-loop-per-pod-salts/</guid>
      <pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
      <description>wp-admin выкидывал обратно на страницу логина с reauth=1, но не всегда. Причина — случайные auth-соли, сгенерированные в каждом поде за балансировщиком без sticky-сессий.</description>
    </item>
    <item>
      <title>Три инцидента, которые были одним: IP базы, зашитый в конфиг</title>
      <link>https://stebas.com/ru/posts/dbaas-master-ip-change/</link>
      <guid>https://stebas.com/ru/posts/dbaas-master-ip-change/</guid>
      <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
      <description>500 на логине, бэкенды в CrashLoopBackOff и зависший деплой выглядели как три проблемы. Все три оказались одним захардкоженным IP базы в конфиге pgbouncer.</description>
    </item>
    <item>
      <title>«Ошибки диска» оказались OOM: как тома Longhorn потеряли бэкенд</title>
      <link>https://stebas.com/ru/posts/longhorn-eio-was-node-oom/</link>
      <guid>https://stebas.com/ru/posts/longhorn-eio-was-node-oom/</guid>
      <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
      <description>EIO, ext4 в read-only, повреждённый datadir MySQL и запечатанный Vault выглядели как умирающий диск. dmesg хоста показал OOM на всю ноду, который первым убил instance-manager Longhorn.</description>
    </item>
    <item>
      <title>«Vault сам себя запечатывает» — нет, он просто никогда не распечатывается</title>
      <link>https://stebas.com/ru/posts/vault-shamir-reseals-on-restart/</link>
      <guid>https://stebas.com/ru/posts/vault-shamir-reseals-on-restart/</guid>
      <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
      <description>Под Vault днями висел в Ready 0/1, пока кворум raft тихо держался на двух пирах. Никто его не запечатывал: Shamir без auto-unseal оставляет запечатанным каждый рестарт.</description>
    </item>
    <item>
      <title>Том Longhorn, который не хотел расти: attachment ticket, прибитый к плохой ноде</title>
      <link>https://stebas.com/ru/posts/longhorn-online-expansion-stuck-on-bad-node/</link>
      <guid>https://stebas.com/ru/posts/longhorn-online-expansion-stuck-on-bad-node/</guid>
      <pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
      <description>PVC бесконечно висел в Resizing, а Longhorn каждые пять секунд повторял расширение без единой ошибки. Устаревший attachment ticket держал том на одной нездоровой ноде.</description>
    </item>
    <item>
      <title>Меняем неизменяемое поле StatefulSet, не перезапустив ни одного пода</title>
      <link>https://stebas.com/ru/posts/resize-immutable-sts-field/</link>
      <guid>https://stebas.com/ru/posts/resize-immutable-sts-field/</guid>
      <pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
      <description>В Git — 20 GiB, в живом StatefulSet — шаблоны на 6 GiB, а Argo CD показывает Synced. Как удаление с orphan и OnDelete пересобрали шаблон без простоя.</description>
    </item>
    <item>
      <title>Пять дней на 1/3 при зелёных дашбордах: когда статус CRD врёт</title>
      <link>https://stebas.com/ru/posts/crd-status-lies-stalled-controller/</link>
      <guid>https://stebas.com/ru/posts/crd-status-lies-stalled-controller/</guid>
      <pubDate>Tue, 28 Jul 2026 00:00:00 GMT</pubDate>
      <description>MySQL InnoDB Cluster пять дней работал без HA, а статус ресурса, фаза подов и readiness gate показывали здоровье. Все три сигнала шли от одного зависшего оператора.</description>
    </item>
    <item>
      <title>Helm пишет «another operation is in progress», а ничего не запущено</title>
      <link>https://stebas.com/ru/posts/helm-pending-upgrade-lock/</link>
      <guid>https://stebas.com/ru/posts/helm-pending-upgrade-lock/</guid>
      <pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate>
      <description>Отменённая CI-джоба оставила два Helm-релиза в pending-upgrade и заблокировала все деплои. Как найти lock, безопасно его снять и проверить весь namespace разом.</description>
    </item>
    <item>
      <title>Как я подхожу к платформе</title>
      <link>https://stebas.com/ru/posts/hello/</link>
      <guid>https://stebas.com/ru/posts/hello/</guid>
      <pubDate>Thu, 16 Apr 2026 00:00:00 GMT</pubDate>
      <description>Инфраструктура как продукт, GitOps, CI/CD, DevSecOps — предсказуемые релизы и безопасность в пайплайне.</description>
    </item>
  </channel>
</rss>
