DevOps для ДевоПсов

Поднимите S3-совместимое хранилище для staging на том же VPS Если staging загружает аватары, отчёты и тестовые файлы в облачный S3, вы платите за хранилище и трафик, которые на самом деле не нужны. MinIO, open-source сервер объектного хранилища на Go, реализующий API Amazon S3, можно развернуть в Docker на VPS за 10–15 минут и платить только за диск сервера. Код приложения не меняется: те же SDK, PutObjectCommand, presigned URL и те же ошибки SignatureDoesNotMatch. Меняются только переменные окружения: endpoint, ключи и флаг forcePathStyle, который нужен большинству S3-совместимых сервисов, включая MinIO и R2. Не отдавайте приложению root-ключи. Создайте отдельного пользователя с IAM-политикой только на нужный бакет, а HTTPS и домен отдайте reverse proxy, Traefik или NGINX, с Let’s Encrypt. Пошаговый разбор — с Docker, бэкапом в холодное хранилище и деталями настройки.

Сохраняйте causal-лог падений Kubernetes до перезаписи kubelet События подов в Kubernetes ротируются быстрее, чем вы успеваете открыть инцидент. Поле LastTerminationState перезаписывается после рестарта, а в crash-loop таких рестартов бывает несколько. Причина падения уходит за evidence horizon. Operational Memory Architecture (OMA) — открытый инструмент на Go, который отслеживает события кластера, строит цепочки причинно-следственных связей и складывает их в SQLite. В тестах на Minikube и AKS с 20 crash-loop подами средняя задержка на связь меньше 1 мс, коллектор потребляет менее 10 МБ памяти. Если отладка в вашем кластере упирается в пустой kubectl describe pod, посмотрите OMA — возможно, пора добавить operational memory layer.

Сохраняйте causal-лог падений Kubernetes до перезаписи kubelet События подов в Kubernetes ротируются быстрее, чем вы успеваете открыть инцидент. Поле LastTerminationState перезаписывается после рестарта, а в crash-loop таких рестартов бывает несколько. Причина падения уходит за evidence horizon. Operational Memory Architecture (OMA) — открытый инструмент на Go, который отслеживает события кластера, строит цепочки причинно-следственных связей и складывает их в SQLite. В тестах на Minikube и AKS с 20 crash-loop подами средняя задержка на связь меньше 1 мс, коллектор потребляет менее 10 МБ памяти. Если отладка в вашем кластере упирается в пустой kubectl describe pod, посмотрите OMA — возможно, пора добавить operational memory layer.

Всем привет! Сегодня в канале стартует партнёрский месяц с Флантом 🦆 Флант развивает экосистему Deckhouse, продукты на базе Kubernetes и Cloud Native-подходов. А уточка на аватарке — маскот экосистемы. В этом месяце расскажем о Deckhouse Kubernetes Platform и сообществе её пользователей, анонсируем пятый митап Deckhouse User Community (он посвящён Community Edition, бесплатной Open Source-редакции платформы) и поделимся полезным для DevOps-специалистов. Для нас это новый формат — надеемся, вам понравится!

Закрепите GitHub Actions и образы по хешу — Cilium ужесточает CI/CD Команда Cilium пинит все uses: в workflow по полному SHA: вместо тега @v6 указывается коммит-хеш. Образы тоже фиксируются через @sha256:..., а не по mutable-тегу. Если тег скомпрометируют, CI всё равно возьмёт проверенный код. Но пиннинг не покрывает транзитивные зависимости actions. Закреплённый checkout не спасёт от взлома вложенного action, который разрешается по тегу во время выполнения. GitHub обещает workflow-level dependency locking в roadmap 2026, аналогично go.mod + go.sum. Пока проверьте свои workflow: замените теги на SHA, закрепите образы по дайджесту и следите за дорожной картой GitHub.

Запустите o11y-bench, прежде чем доверить ИИ-агенту вашу Grafana Не доверяйте ИИ-агенту доступ к продовой Grafana, пока не проверите его в o11y-bench. Grafana открыла код бенчмарка: он запускает агентов против реального стека с доступом к серверу Grafana MCP и оценивает их на observability-задачах. Внутри — запросы к метрикам, логам и трассировкам, расследование инцидентов и точечные правки дашбордов. Среда построена на фреймворке Harbor от авторов Terminal Bench. Перед доступом к проду прогоните свой сценарий через бенчмарк и убедитесь, что агент реально справляется, а не просто красиво отвечает.

K8s 1.35: почему под не рестартнулся после обновления конфига Обновили ConfigMap, Secret или Istio, а приложение всё ещё видит старое? kubelet следит только за pod spec, и без смены spec'а контейнер не перезапустится. Проверяйте UID пода, а не только restart count: новый UID — под пересоздали и счётчик сбросился, старый UID с растущим restart count — CrashLoop в том же объекте. В K8s 1.35 CPU resize контейнер не трогает, память перезапускает только при политике RestartContainer; иначе JVM сохранит старый heap. envFrom из ConfigMap заморозит значения до kubectl rollout restart, volume mount обновится атомарно. Что делать: подключите Reloader с reloader.watchGlobally=true и аннотацией reloader.stakater.com/auto: "true", или вручную вызывайте kubectl rollout restart deployment/app. Матрица и команды в гайде.

Cloudflare ускорила security-сканы с 10 до 120+ в секунду без новых партиций Security Insights сканировала аккаунты раз в 1–2 недели, а бесплатные часто не попадали в очередь. Цель — ~10→100 сканов/с, но консьюмеры лагали, API таймаутился и процессы падали. В разборе инженеры пишут, что распараллелили обработку сообщений внутри партиции, разделили «медленные» и «быстрые» потоки и убрали блокировку головы очереди. Вставки в Postgres по одной строке заменили на гибридный bulk-insert, API перевели в active-passive у основной БД. Шедулер — под adaptive rate limiter: зоны считают отдельно, стартовые временные метки размазали, лимит пересчитывается каждые полчаса. Итог: производительность выросла >10× и достигла 120+ сканов/с. Прежде чем добавлять партиции или железо, смотрите метрики, SQL, логи и код.

Severity во время инцидента может мешать больше, чем помогать Dan Slimmon в спорной заметке критикует SEV-шкалы. Не потому что классификация совсем не нужна, а потому что в начале инцидента команда часто тратит силы на спор «это SEV-1 или SEV-2», когда важнее понять blast radius, назначить lead и двигать расследование. Для SRE-практики полезный угол такой: severity хороша для отчётности, коммуникации и post-incident анализа, но плохо заменяет operational questions. Что сломано? Кто координирует? Какой next action? Когда следующий update? Если ваш incident template начинается с выбора SEV, стоит проверить, не прячутся ли за ним реальные шаги управления инцидентом.

SELECT в Postgres тоже может выглядеть как запись Dan Slimmon разбирает странный инцидент: в Postgres появлялись пики WALWrite, хотя нагрузка была read-only. Виновником оказался не внезапный write-запрос, а hint bits и full page writes. Для SRE это хороший пример, почему «чтения не пишут» в базах не всегда безопасное упрощение. Первый SELECT после изменений может пометить tuple metadata, а если страница ещё не была записана после checkpoint, Postgres отправит full page image в WAL. Практический вывод: когда видите write spikes на read-heavy workload, не останавливайтесь на поиске INSERT/UPDATE. Смотрите checkpoints, hint bits, buffer dirties и то, что реально происходит на уровне storage.

CoreDNS в Kubernetes можно патчить Terraform'ом, не через kubectl edit Jérôme Petazzoni разбирает практичную боль: кластер сам создал CoreDNS ConfigMap, но править Corefile руками не хочется, потому что потом это невозможно нормально повторить и проверить в IaC. Решение строится вокруг Terraform/OpenTofu: прочитать существующий ConfigMap, применить patch к нужному фрагменту и оставить изменение в коде, а не в истории команд администратора. Это особенно полезно, если нужно добавить upstream, rewrite, cache-настройки или внутренние DNS-правила. Материал стоит открыть тем, у кого в кластере ещё есть «один раз поправили руками». CoreDNS обычно как раз из таких мест, где ручная правка потом всплывает в самый неудобный момент.

Linux page cache для тех, кто смотрит на память в проде У Viacheslav Biriukov есть большой разбор page cache для SRE. Это материал про ту самую память, которая в top выглядит занятой, но не всегда означает утечку в приложении. Внутри: как Linux кэширует страницы файлов, что меняется с cgroup v2, как читать smaps, где помогают mincore, mmap, fsync, vmtouch, perf и strace. Практический фокус хороший: не «ядро сложное», а как не ошибиться при разборе memory pressure. Если у вас были алерты вида «RAM почти кончилась», а потом всё само проходило, этот текст стоит сохранить в runbook по Linux diagnostics.

Self-hosting дома, где ломается всё самое сетевое В авторском разборе блог хостится дома, но с обычными бытовыми ограничениями: динамический IPv4, меняющийся IPv6 prefix, OpenWRT, DNS-обновления и WireGuard как связка для доступа извне. Материал полезен не как рецепт «делайте прод дома», а как компактная лаборатория по сети. Тут сразу видно, где заканчивается красивый self-hosting и начинается реальность провайдера: prefix delegation, firewall rules, DDNS, туннели и восстановление после смены адресов. Хорошее чтение для тех, кто хочет руками потрогать networking без облачного abstraction layer. После такого проще понимать, что именно скрывают managed load balancer и static IP.

Нагрузочный тест лучше собирать не из фантазии, а из telemetry Grafana показывает подход, где сценарий для k6 строится из production telemetry. Вместо «давайте поставим 100 virtual users» берутся реальные RPS, p95/p99, распределение endpoint'ов и форма трафика из Grafana Cloud. Это полезно для SRE-команд, которые уже хранят метрики в Prometheus/Mimir, но нагрузочные тесты всё ещё пишут вручную. Такой тест ближе к боевому профилю: он проверяет не абстрактную пропускную способность, а конкретные пики и маршруты, которые уже видны в проде. Хороший кандидат для следующего performance review: взять неделю нормального трафика и превратить её в k6-сценарий.

GKE standby buffers: запас capacity без постоянного overprovisioning Google Cloud показал standby buffers для GKE. Идея в том, чтобы держать подготовленные, но suspended-ноды: они уже прошли init, DaemonSet'ы и preload, но не жгут полный compute как обычный запас. Для кластеров со всплесками это замена balloon pods и ручному overprovisioning. Standby-ноды возобновляются в 2-3 раза быстрее, чем создаётся свежая нода, а buffer описывается через CapacityBuffer. В статье есть YAML-пример и проверка через kubectl get nodes с condition Suspended. Если у вас latency SLO страдает именно на scale-up, это стоит тестировать на отдельном node pool.

В большинстве компаний 1С и облачная инфраструктура живут в параллельных мирах: DevOps смотрит в Grafana, финдиректор — в 1С, а когда падает оплата, все смотрят друг на друга. На самом деле подружить 1С с современными инструментами мониторинга вполне реально всего за один спринт. В блоге Centicore рассказали, как это сделать. В статье разбирается, как вытащить метрики из 1С через OData без единой строчки кода, написать Prometheus Exporter на Python и собрать бизнес- и технические метрики на одном дашборде. А заодно — где интеграция обычно ломается и как это пережить.

Сервис должен уметь сказать, какая версия сейчас запущена Michael Stapelberg в заметке формулирует простое правило: все программы должны репортить свою версию. Не «мы вроде деплоили коммит утром», а конкретный build id, commit, timestamp или package version, которые можно получить из бинаря или runtime. Для incident response это не косметика. Когда алерт горит, команда должна быстро понять, какие инстансы уже на новом билде, где остался старый артефакт и какой образ реально крутится в pod'е или systemd unit. Практический шаг: проверьте свои CLI, сервисы и health/debug endpoints. Если версия не достаётся одной командой, расследование уже начинается с лишней неопределённости.

Контейнерный supply chain стоит проверять не только на этапе registry Docker собрал чеклист по безопасности цепочки поставки для контейнеров. Там не про один волшебный сканер, а про всю дорогу образа: base image, зависимости, secrets в CI, SBOM, provenance, подписи и runtime monitoring. Хороший минимум для своей платформы: закрепить digest вместо плавающих тегов, генерировать SBOM на сборке, ограничить scope секретов в pipeline, проверять provenance перед deploy и не считать successful build доказательством безопасности. Материал удобно открыть рядом с CI/CD и registry-настройками. Не как теорию, а как список мест, где обычно тихо накапливается риск.

Golden images теперь можно держать на поводке в HCP Packer Если образы собирают разные команды, security baseline быстро начинает жить на честном слове: где-то забыли агент мониторинга, где-то не включили hardening, где-то compliance-шаг остался в локальном пайплайне. HashiCorp добавила enforced provisioners в HCP Packer. Platform-команда задаёт обязательные provisioning-шаги централизованно, а отдельные сборки уже не могут их отключить. Это касается AMI, VM, Docker-образов и других golden images. Практический смысл простой: если у вас Packer разъехался по командам, стоит вынести обязательные security/compliance шаги из локальных шаблонов в enforced policy.

CodeQL быстрее сканирует Go и C/C++ в pull request'ах GitHub включил инкрементальный анализ для CodeQL по Go и C/C++. Вместо полного прохода по репозиторию скан смотрит на изменения и переиспользует предыдущий результат. Для больших монореп это как раз та разница, из-за которой security job перестаёт быть самым долгим этапом CI. На github.com фича включена по умолчанию для проектов с build mode none в default setup и advanced setup. Для сторонних CI нужен CodeQL CLI 2.25.5 или новее. Если CodeQL у вас давно «временно» вынесен из обязательных checks из-за скорости, есть повод вернуть его в pipeline и сравнить время прогона.