RAG Pipeline 6/N: Бенчмарк – 98% на своих данных, 52.7% на чужих
Продолжаю серию про конвейер "общей памяти" между сессиями с LLM. В предыдущих постах разобрали векторный поиск, эмбеддинги, нарезку на чанки, гибридный поиск и переранжирование. Конвейер собран и работает. Сегодня вопрос, который я долго откладывал: насколько он вообще хорош? Пока нет цифры, "хорошо" остаётся ощущением, а не фактом.
Взял 50 своих вопросов по реальным рабочим заметкам и прогнал систему. С первого захода – 20% (поймал пару тихих ошибок: поиск молча возвращал пустоту). После четырёх правок – 98%.
Но 98% на своих вопросах – это экзамен, который сам себе составил и сам же сдал. Поэтому прогнал ту же систему через чужой бенчмарк – LoCoMo (1986 вопросов, придумал не я). Результат: 52.7%. Выше, чем у "голого" GPT-4 на том же тесте (32%), но далеко от лучших (Mem0 – 92.5%).
Дальше попытка улучшить. И вот что показали замеры:
– находить нужный фрагмент система стала заметно лучше: с 67 до 83 из 100;
– а отвечать правильно – почти не сдвинулась: с 53 до 55 из 100.
В этом разрыве вся суть. Найти нужную страницу и дать по ней правильный ответ – две разные задачи. Можно положить перед моделью идеально подходящий текст, а она всё равно ответит мимо. Поиск я подтянул сильно, но узкое место просто переехало в генерацию ответа.
Три вывода:
1. Свой бенчмарк всегда льстит. Нужна честная оценка – бери вопросы, которые придумал не ты.
2. Хороший поиск ≠ хороший ответ. Между "нашёл" и "понял" – разрыв на этапе генерации.
3. 98% и 52% – не противоречие. Первое меряет твой прогресс, второе – реальное место среди других. Нужны обе цифры.
Полная версия с методикой, кодом и разбором всех просадок:
👉 devopsway.ru/posts/rag-06-benchmark/
#кейс #ai
Продолжаю серию про конвейер "общей памяти" между сессиями с LLM. В предыдущих постах разобрали векторный поиск, эмбеддинги, нарезку на чанки, гибридный поиск и переранжирование. Конвейер собран и работает. Сегодня вопрос, который я долго откладывал: насколько он вообще хорош? Пока нет цифры, "хорошо" остаётся ощущением, а не фактом.
Взял 50 своих вопросов по реальным рабочим заметкам и прогнал систему. С первого захода – 20% (поймал пару тихих ошибок: поиск молча возвращал пустоту). После четырёх правок – 98%.
Но 98% на своих вопросах – это экзамен, который сам себе составил и сам же сдал. Поэтому прогнал ту же систему через чужой бенчмарк – LoCoMo (1986 вопросов, придумал не я). Результат: 52.7%. Выше, чем у "голого" GPT-4 на том же тесте (32%), но далеко от лучших (Mem0 – 92.5%).
Дальше попытка улучшить. И вот что показали замеры:
– находить нужный фрагмент система стала заметно лучше: с 67 до 83 из 100;
– а отвечать правильно – почти не сдвинулась: с 53 до 55 из 100.
В этом разрыве вся суть. Найти нужную страницу и дать по ней правильный ответ – две разные задачи. Можно положить перед моделью идеально подходящий текст, а она всё равно ответит мимо. Поиск я подтянул сильно, но узкое место просто переехало в генерацию ответа.
Три вывода:
1. Свой бенчмарк всегда льстит. Нужна честная оценка – бери вопросы, которые придумал не ты.
2. Хороший поиск ≠ хороший ответ. Между "нашёл" и "понял" – разрыв на этапе генерации.
3. 98% и 52% – не противоречие. Первое меряет твой прогресс, второе – реальное место среди других. Нужны обе цифры.
Полная версия с методикой, кодом и разбором всех просадок:
👉 devopsway.ru/posts/rag-06-benchmark/
#кейс #ai
🔥4❤2
⚡️ DevOps Digest #19 | 15.06.2026
🔥 Главное за неделю:
1. Атака на цепочку поставок: клон Shai-Hulud пришёл в PyPI – Пять вредоносных пакетов: тайпсквоттинг Flask, Requests, NumPy плюс перехваченный легитимный mflux-streamlit. Код срабатывает прямо на установке (без import), это самораспространяющийся вор учёток, нацеленный на CI/CD-окружения. Вывод: пиньте версии, проверяйте зависимости перед сборкой, не ставьте свежие релизы вслепую.
🔗 https://about.gitlab.com/blog/shai-hulud-copycat-campaign-targets-python-developers/
2. GitHub Actions: долой PAT для агентных воркфлоу – Теперь можно использовать встроенный GITHUB_TOKEN вместо персонального токена: он короткоживущий, привязан к конкретному запуску и ограничен правами из workflow-файла. Откажитесь от долгоживущих широких PAT в пользу scoped-токенов везде, где это возможно.
🔗 https://devops.com/github-removes-pat-requirement-for-agentic-workflows/
3. AmneziaWG 2.0: маскировка переезжает в сам поток данных – Если раньше имитация была короткой «дымовой завесой» перед хендшейком, то теперь транспортные пакеты на проводе выглядят как трафик другого протокола. Практично для закрытых контуров, где обычный WireGuard режется по DPI.
🔗 https://habr.com/ru/articles/1047080/
4. Ansible Automation Platform 2.7 – Новый релиз развивает self-service-портал автоматизации: операционные команды могут отдавать готовые сценарии тем, кто не является экспертом в Ansible. Если живёте на AAP – посмотрите changelog перед обновлением.
🔗 https://www.redhat.com/en/blog/whats-new-ansible-automation-platform-2-7
5. K8s Necromancer: чёрный ящик для умерших подов – Контроллер перехватывает смерть пода до сборки мусора и замораживает форензику: логи, таймлайн событий, ENV, снапшот spec, графики CPU/память из Prometheus. Лекарство от вечного «CrashLoopBackOff без контекста, логи уже ротировались».
🔗 https://dev.to/solojoe/k8s-necromancer-a-black-box-flight-recorder-for-dead-kubernetes-pods-4pa8
🛠 Команда недели:
Показывает последние 20 событий кластера в хронологическом порядке – быстрый разбор, когда «только что что-то сломалось», а куда смотреть, ещё непонятно.
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Атака на цепочку поставок: клон Shai-Hulud пришёл в PyPI – Пять вредоносных пакетов: тайпсквоттинг Flask, Requests, NumPy плюс перехваченный легитимный mflux-streamlit. Код срабатывает прямо на установке (без import), это самораспространяющийся вор учёток, нацеленный на CI/CD-окружения. Вывод: пиньте версии, проверяйте зависимости перед сборкой, не ставьте свежие релизы вслепую.
🔗 https://about.gitlab.com/blog/shai-hulud-copycat-campaign-targets-python-developers/
2. GitHub Actions: долой PAT для агентных воркфлоу – Теперь можно использовать встроенный GITHUB_TOKEN вместо персонального токена: он короткоживущий, привязан к конкретному запуску и ограничен правами из workflow-файла. Откажитесь от долгоживущих широких PAT в пользу scoped-токенов везде, где это возможно.
🔗 https://devops.com/github-removes-pat-requirement-for-agentic-workflows/
3. AmneziaWG 2.0: маскировка переезжает в сам поток данных – Если раньше имитация была короткой «дымовой завесой» перед хендшейком, то теперь транспортные пакеты на проводе выглядят как трафик другого протокола. Практично для закрытых контуров, где обычный WireGuard режется по DPI.
🔗 https://habr.com/ru/articles/1047080/
4. Ansible Automation Platform 2.7 – Новый релиз развивает self-service-портал автоматизации: операционные команды могут отдавать готовые сценарии тем, кто не является экспертом в Ansible. Если живёте на AAP – посмотрите changelog перед обновлением.
🔗 https://www.redhat.com/en/blog/whats-new-ansible-automation-platform-2-7
5. K8s Necromancer: чёрный ящик для умерших подов – Контроллер перехватывает смерть пода до сборки мусора и замораживает форензику: логи, таймлайн событий, ENV, снапшот spec, графики CPU/память из Prometheus. Лекарство от вечного «CrashLoopBackOff без контекста, логи уже ротировались».
🔗 https://dev.to/solojoe/k8s-necromancer-a-black-box-flight-recorder-for-dead-kubernetes-pods-4pa8
🛠 Команда недели:
kubectl get events -A --sort-by='.lastTimestamp' | tail -20
Показывает последние 20 событий кластера в хронологическом порядке – быстрый разбор, когда «только что что-то сломалось», а куда смотреть, ещё непонятно.
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
GitLab
Shai-Hulud copycat campaign targets Python developers through PyPI typosquatting
GitLab’s Vulnerability Research team has uncovered a new Python supply chain attack targeting PyPI, deploying the Shai-Hulud worm to steal credentials from CI/CD systems.
🔥2❤1
Ошибка, которой нет в логах: как не изобрести велосипед с LLM-мотором на дежурстве
История о том, как одна пропущенная строчка в логе съедает два часа инженерного времени
Пользователь загружает фото с Айфона в наш AI-сервис, получает ошибку, а у разработчиков на тестовых стендах всё работает. В логах стандартный
Пришлось идти в мессенджеры, выпрашивать у клиента исходный файл и ковырять его руками. Выяснилось, что картинка весит 5 МБ (в лимит по байтам укладывались), но её разрешение – 12.2 Мп. Внешний API резал файлы именно по габаритам, выставляя жесткий лимит в 12 Мп. Автоматика могла бы выплюнуть эту причину одной строкой, но вместо неё контекст собирали люди.
В статье разбираем, как правильно выстроить регистрацию ошибок и почему сейчас не стоит слепо следовать тренду на автоматизацию мониторинга с помощью LLM:
– Контекст вместо сырых трейсов: как оформлять логи и настраивать сбор метаданных в Sentry или его легковесном open-source аналоге GlitchTip.
– Почему LLM не место в критическом пути алертинга: разбираем проблемы с недетерминизмом, задержками ответов и поведением моделей во время OOM-штормов, когда логи сыплются тысячами строк в секунду.
– Архитектура здорового человека: как спроектировать трехуровневую систему, где за мгновенные оповещения отвечает жесткое ядро на регулярных выражениях, а нейросеть работает офлайн и пакетно — просто предлагая новые правила для этого ядра.
Фикс кейса: как мы закрыли проблему с Айфонами с помощью Pillow и как доставляем такие инциденты до дежурных через alert-платформу Pusk.
👉 Читать статью полностью
#кейс #devops
История о том, как одна пропущенная строчка в логе съедает два часа инженерного времени
Пользователь загружает фото с Айфона в наш AI-сервис, получает ошибку, а у разработчиков на тестовых стендах всё работает. В логах стандартный
raise_for_status() на 400 Bad Request. Видно, что упало, но само тело ответа от внешнего провайдера никто не сохранил.Пришлось идти в мессенджеры, выпрашивать у клиента исходный файл и ковырять его руками. Выяснилось, что картинка весит 5 МБ (в лимит по байтам укладывались), но её разрешение – 12.2 Мп. Внешний API резал файлы именно по габаритам, выставляя жесткий лимит в 12 Мп. Автоматика могла бы выплюнуть эту причину одной строкой, но вместо неё контекст собирали люди.
В статье разбираем, как правильно выстроить регистрацию ошибок и почему сейчас не стоит слепо следовать тренду на автоматизацию мониторинга с помощью LLM:
– Контекст вместо сырых трейсов: как оформлять логи и настраивать сбор метаданных в Sentry или его легковесном open-source аналоге GlitchTip.
– Почему LLM не место в критическом пути алертинга: разбираем проблемы с недетерминизмом, задержками ответов и поведением моделей во время OOM-штормов, когда логи сыплются тысячами строк в секунду.
– Архитектура здорового человека: как спроектировать трехуровневую систему, где за мгновенные оповещения отвечает жесткое ядро на регулярных выражениях, а нейросеть работает офлайн и пакетно — просто предлагая новые правила для этого ядра.
Фикс кейса: как мы закрыли проблему с Айфонами с помощью Pillow и как доставляем такие инциденты до дежурных через alert-платформу Pusk.
👉 Читать статью полностью
#кейс #devops
🔥3👍2
⚡️ DevOps Digest #20 | 22.06.2026
🔥 Главное за неделю:
1. Прогнал gitleaks по своему репозиторию – нашёл 12 живых секретов – Инженер был уверен, что его homelab-репозиторий чист: CI зелёный, секреты вроде бы в Vault. Полный скан истории нашёл 12 секретов в открытом виде, включая приватный OIDC-ключ, которым подписываются SSO-токены для ArgoCD, Vault и Grafana. Прогони полную историю у себя – почти наверняка что-то всплывёт.
🔗 https://dev.to/dwoitzik/i-ran-gitleaks-against-my-own-repo-and-found-12-real-secrets-1j18
2. IncidentRelay дорос до полноценного on-call – Open-source и self-hosted система дежурств: маршрутизация алертов, эскалации, ACK/Resolve. За месяц добралась до v1.0.21-beta и закрыла всю цепочку дежурства. Живая альтернатива PagerDuty и OpsGenie для закрытого контура.
🔗 https://habr.com/ru/articles/1050286/
3. Terraform Ansible collection 2.0 – HashiCorp выкатила версию 2.0 на pyTFE: динамический инвентарь и доработанные Terraform actions. Связка provisioning (Terraform) и управления конфигурацией (Ansible) стала плотнее и двунаправленной. Если оба инструмента в твоей обвязке – посмотри, что поменялось.
🔗 https://www.hashicorp.com/blog/whats-new-with-terraform-ansible
4. Вышел Valkey 9.1 – Open-source форк Redis под крылом Linux Foundation: кеш, очереди, key-value-структуры. Заметную часть багфиксов в релизе бэкпортировал AI-агент – сам разруливал конфликты и гонял CI. Главное – это бесплатная замена Redis после смены его лицензии.
🔗 https://thenewstack.io/valkey-ai-backporting-agents/
5. Arcane – простой веб-UI для Docker – Self-hosted панель управления контейнерами на Go, на этой неделе набрала больше сотни звёзд. Лёгкая альтернатива Portainer, когда нужен понятный интерфейс для контейнеров на одном-двух хостах.
🔗 https://github.com/getarcaneapp/arcane
6. "Скорость – это не поток" – Деплои чаще, дашборды зелёные, а ценность всё равно стоит в очереди. Разбор, почему автоматизация без системного выравнивания просто разгоняет хаос, и как Value Stream Mapping показывает, где реально застревает работа. Полезно тем, кто внедряет DevOps-практики.
🔗 https://devops.com/you-cannot-fake-flow-what-organizations-get-wrong-about-value-delivery/
🛠 Команда недели:
Использование inode по файловым системам. Если IUse% подходит к 100, а по df -h места ещё полно – диск забит не объёмом, а числом файлов: классика на legacy-серверах, где мелкие логи или сессии выели все inode, и запись падает с No space left on device, хотя "место вроде есть".
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Прогнал gitleaks по своему репозиторию – нашёл 12 живых секретов – Инженер был уверен, что его homelab-репозиторий чист: CI зелёный, секреты вроде бы в Vault. Полный скан истории нашёл 12 секретов в открытом виде, включая приватный OIDC-ключ, которым подписываются SSO-токены для ArgoCD, Vault и Grafana. Прогони полную историю у себя – почти наверняка что-то всплывёт.
🔗 https://dev.to/dwoitzik/i-ran-gitleaks-against-my-own-repo-and-found-12-real-secrets-1j18
2. IncidentRelay дорос до полноценного on-call – Open-source и self-hosted система дежурств: маршрутизация алертов, эскалации, ACK/Resolve. За месяц добралась до v1.0.21-beta и закрыла всю цепочку дежурства. Живая альтернатива PagerDuty и OpsGenie для закрытого контура.
🔗 https://habr.com/ru/articles/1050286/
3. Terraform Ansible collection 2.0 – HashiCorp выкатила версию 2.0 на pyTFE: динамический инвентарь и доработанные Terraform actions. Связка provisioning (Terraform) и управления конфигурацией (Ansible) стала плотнее и двунаправленной. Если оба инструмента в твоей обвязке – посмотри, что поменялось.
🔗 https://www.hashicorp.com/blog/whats-new-with-terraform-ansible
4. Вышел Valkey 9.1 – Open-source форк Redis под крылом Linux Foundation: кеш, очереди, key-value-структуры. Заметную часть багфиксов в релизе бэкпортировал AI-агент – сам разруливал конфликты и гонял CI. Главное – это бесплатная замена Redis после смены его лицензии.
🔗 https://thenewstack.io/valkey-ai-backporting-agents/
5. Arcane – простой веб-UI для Docker – Self-hosted панель управления контейнерами на Go, на этой неделе набрала больше сотни звёзд. Лёгкая альтернатива Portainer, когда нужен понятный интерфейс для контейнеров на одном-двух хостах.
🔗 https://github.com/getarcaneapp/arcane
6. "Скорость – это не поток" – Деплои чаще, дашборды зелёные, а ценность всё равно стоит в очереди. Разбор, почему автоматизация без системного выравнивания просто разгоняет хаос, и как Value Stream Mapping показывает, где реально застревает работа. Полезно тем, кто внедряет DevOps-практики.
🔗 https://devops.com/you-cannot-fake-flow-what-organizations-get-wrong-about-value-delivery/
🛠 Команда недели:
df -ih
Использование inode по файловым системам. Если IUse% подходит к 100, а по df -h места ещё полно – диск забит не объёмом, а числом файлов: классика на legacy-серверах, где мелкие логи или сессии выели все inode, и запись падает с No space left on device, хотя "место вроде есть".
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
DEV Community
I Ran Gitleaks Against My Own Repo and Found 12 Real Secrets
A full-history gitleaks scan of a homelab repo that had been running for months turned up 12 distinct plaintext secrets — including an OIDC signing key. Here's the scanning setup, the baseline strategy that doesn't block on pre-existing leaks, and the remediation…
👍4🔥1
Разбираемся с сетями (без занудства и OSI ради OSI)
Давай честно: сколько раз за последний год ты нейрогуглил что-то по сетям или лез в калькулятор подсетей, чтобы проверить маску /24 и /25, или пытался понять, а те, кто выпускают для корпсети имена доменов в своём уме или это у тебя уже кукуха отлетела? А когда на собесе спрашивают "что происходит, если ввести URL в браузер", внутри обычно что-то типа: "Ну там DNS бороздит просторы Большого театра и пакеты летают".
И это нормально. Обычно сети либо учат по академическим кирпичам типа Олифера (где засыпаешь на главе про физический уровень), либо собирают по кусочкам на практике: тут скопировал конфиг ингресса, там пробросил порт в докере – вроде завелось, и ладно.
Проблемы начинаются как обычно внезапно, когда сыплет 502 ошибка, pod не видит базу, а сертификат внезапно протух. И ты сидишь перед монитором, пытаясь угадать, на каком вообще этапе всё сломалось. (Хотя мы-то знаем, что виноват всегда DNS. Даже когда он не виноват).
Решил собрать в кучу и разложить по полочкам ту базу по сетям, которая реально нужна каждый день в DevOps. Назовём это Networking 20/80.
План такой: пройдёмся по ключевым темам короткими и понятными постами. Никакой зубрёжки ради собесов, только практика:
1. Как на самом деле устроена модель сети (и почему OSI полезна только для диагностики).
2. IP-адреса, подсети и маршрутизация на пальцах.
3. DNS – как он устроен внутри и почему ломается.
4. TCP и UDP: флаги, хендшейки и почему рвутся соединения.
5. HTTP, HTTPS и TLS (что под капотом у сертификатов).
6. Файрволы и базовый забор из правил.
7. Балансировка трафика и то, как всё это крутится внутри Kubernetes.
В каждом посте – минимум теории, происхождение протоколов (чтобы понять логику создателей) и живые команды, которые пригодятся в консоли (ip, ping, traceroute, ss). Задача – научиться понимать, на каком уровне искать, когда всё упало.
Первый пост уже готов, погнали разбираться 👇
https://devopsway.ru/posts/networking-00-model/
#networking #linux #devops
Давай честно: сколько раз за последний год ты нейрогуглил что-то по сетям или лез в калькулятор подсетей, чтобы проверить маску /24 и /25, или пытался понять, а те, кто выпускают для корпсети имена доменов в своём уме или это у тебя уже кукуха отлетела? А когда на собесе спрашивают "что происходит, если ввести URL в браузер", внутри обычно что-то типа: "Ну там DNS бороздит просторы Большого театра и пакеты летают".
И это нормально. Обычно сети либо учат по академическим кирпичам типа Олифера (где засыпаешь на главе про физический уровень), либо собирают по кусочкам на практике: тут скопировал конфиг ингресса, там пробросил порт в докере – вроде завелось, и ладно.
Проблемы начинаются как обычно внезапно, когда сыплет 502 ошибка, pod не видит базу, а сертификат внезапно протух. И ты сидишь перед монитором, пытаясь угадать, на каком вообще этапе всё сломалось. (Хотя мы-то знаем, что виноват всегда DNS. Даже когда он не виноват).
Решил собрать в кучу и разложить по полочкам ту базу по сетям, которая реально нужна каждый день в DevOps. Назовём это Networking 20/80.
План такой: пройдёмся по ключевым темам короткими и понятными постами. Никакой зубрёжки ради собесов, только практика:
1. Как на самом деле устроена модель сети (и почему OSI полезна только для диагностики).
2. IP-адреса, подсети и маршрутизация на пальцах.
3. DNS – как он устроен внутри и почему ломается.
4. TCP и UDP: флаги, хендшейки и почему рвутся соединения.
5. HTTP, HTTPS и TLS (что под капотом у сертификатов).
6. Файрволы и базовый забор из правил.
7. Балансировка трафика и то, как всё это крутится внутри Kubernetes.
В каждом посте – минимум теории, происхождение протоколов (чтобы понять логику создателей) и живые команды, которые пригодятся в консоли (ip, ping, traceroute, ss). Задача – научиться понимать, на каком уровне искать, когда всё упало.
Первый пост уже готов, погнали разбираться 👇
https://devopsway.ru/posts/networking-00-model/
#networking #linux #devops
🔥7👍1
⚡️ DevOps Digest #21 | 29.06.2026
🔥 Главное за неделю:
1. Podman 6.0 — много breaking changes – Вышел мажор: несколько статических IP на контейнер, улучшенная изоляция сети ради совместимости с Docker, переписанные Quadlet и обработка конфигов. Перед апгрейдом обязательно прочитай release notes – ломающих изменений хватает.
🔗 https://lwn.net/Articles/1079600/
2. Плагин Cluster API для Headlamp – У open-source UI для Kubernetes появился визуальный модуль для Cluster API: обзор кластеров, MachineDeployments и Machines, масштабирование прямо из интерфейса вместо сырых kubectl-команд. Удобно тем, кто рулит жизненным циклом кластеров.
🔗 https://kubernetes.io/blog/2026/06/25/headlamp-cluster-api-plugin/
3. DataSafeS3 v1.0.1 / v1.0.2 – Молодой российский open-source: своё S3-хранилище с веб-консолью, ролями и журналом действий на своём железе (нужны только Docker и Linux). Команда честно разбирает, что сломалось после первого релиза и как чинили – полезно тем, кто уже катит его в тестовом контуре.
🔗 https://habr.com/ru/articles/1053082/
4. Progressive delivery: управляем blast radius – Разбор, как уйти от "выкатил и молись" к контролируемым релизам: разделяем deployment (выкладка кода) и release (показ фичи юзерам), катим на 1–5% трафика через canary и feature flags, держим наготове kill switch. Наблюдаем, решаем, расширяем.
🔗 https://devops.com/mastering-the-blast-radius-deployment-without-fear-progressive-delivery-in-modern-devops/
5. Когда брешь вендора становится твоей – Забытый доступ у вендора Klue открыл атакующим данные Salesforce его клиентов. Хороший разбор цепочечных SaaS-взломов и чек-лист: какие ключи и интеграции пора проаудитить, чтобы чужой инцидент не стал твоим.
🔗 https://snyk.io/blog/when-a-vendors-breach-becomes-yours-lessons-from-the-klue-incident/
6. Vessel – обновление панели для VPS – Локальная (local-first) панель управления сервером на Rust/Tauri: автодетект и установка Docker, запуск контейнеров из UI, хвост логов нескольких контейнеров в одном окне через один SSH-канал. Лицензия MIT.
🔗 https://github.com/shihebamrii/vessel
🛠 Команда недели:
Список всех SUID-бинарников: каждый запускается с правами root, поэтому забытый или подозрительный файл здесь – прямой путь к эскалации привилегий. -xdev держит поиск в пределах одной ФС (не лезет в /proc, /sys, сетевые маунты) – быстро и без шума.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Podman 6.0 — много breaking changes – Вышел мажор: несколько статических IP на контейнер, улучшенная изоляция сети ради совместимости с Docker, переписанные Quadlet и обработка конфигов. Перед апгрейдом обязательно прочитай release notes – ломающих изменений хватает.
🔗 https://lwn.net/Articles/1079600/
2. Плагин Cluster API для Headlamp – У open-source UI для Kubernetes появился визуальный модуль для Cluster API: обзор кластеров, MachineDeployments и Machines, масштабирование прямо из интерфейса вместо сырых kubectl-команд. Удобно тем, кто рулит жизненным циклом кластеров.
🔗 https://kubernetes.io/blog/2026/06/25/headlamp-cluster-api-plugin/
3. DataSafeS3 v1.0.1 / v1.0.2 – Молодой российский open-source: своё S3-хранилище с веб-консолью, ролями и журналом действий на своём железе (нужны только Docker и Linux). Команда честно разбирает, что сломалось после первого релиза и как чинили – полезно тем, кто уже катит его в тестовом контуре.
🔗 https://habr.com/ru/articles/1053082/
4. Progressive delivery: управляем blast radius – Разбор, как уйти от "выкатил и молись" к контролируемым релизам: разделяем deployment (выкладка кода) и release (показ фичи юзерам), катим на 1–5% трафика через canary и feature flags, держим наготове kill switch. Наблюдаем, решаем, расширяем.
🔗 https://devops.com/mastering-the-blast-radius-deployment-without-fear-progressive-delivery-in-modern-devops/
5. Когда брешь вендора становится твоей – Забытый доступ у вендора Klue открыл атакующим данные Salesforce его клиентов. Хороший разбор цепочечных SaaS-взломов и чек-лист: какие ключи и интеграции пора проаудитить, чтобы чужой инцидент не стал твоим.
🔗 https://snyk.io/blog/when-a-vendors-breach-becomes-yours-lessons-from-the-klue-incident/
6. Vessel – обновление панели для VPS – Локальная (local-first) панель управления сервером на Rust/Tauri: автодетект и установка Docker, запуск контейнеров из UI, хвост логов нескольких контейнеров в одном окне через один SSH-канал. Лицензия MIT.
🔗 https://github.com/shihebamrii/vessel
🛠 Команда недели:
find / -xdev -perm -4000 -type f 2>/dev/null
Список всех SUID-бинарников: каждый запускается с правами root, поэтому забытый или подозрительный файл здесь – прямой путь к эскалации привилегий. -xdev держит поиск в пределах одной ФС (не лезет в /proc, /sys, сетевые маунты) – быстро и без шума.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
LWN.net
Podman 6.0 released
Version 6.0.0 of the Podman container-management tool has been released. Notable new features i [...]
🔥3
IP-адреса и подсети: та самая математика, из-за которой ты лезешь в калькулятор
📺 В предыдущих сериях: это второй пост мини-курса "Networking 20/80" – 20% сетевых знаний, которые закрывают 80% работы DevOps. В нулевом разбирались с картой слоёв: на каком этаже искать супостата, когда всё упало. Сегодня спускаемся на этаж адресов.
На собесе меня как-то спросили: "для чего нужна маска подсети?". Мозг, натренированный на корпоративный тикет – где заполняешь поля по готовой архитектурной схеме, как предки завещали, – честно выдал то, чем реально пользуешься, когда нарезаешь подсети под контуры: "чтобы посчитать, сколько влезет хостов". Формально не враньё. Но это ответ про побочный эффект, а не про смысл – и если интервьюер в теме, он тут же начнёт раскручивать тебя в нужном направлении, или нет 😅
А смысл в том, что маска проводит границу: где заканчивается "своя" сеть и начинается "чужая". Из этой границы растёт всё остальное – пойдёт пакет напрямую через свитч или полезет через роутер, можно ли отрезать одно окружение от другого. Сколько хостов влезет – это просто сдача от битов, которые остались под хост.
Плохая новость: в адресации действительно есть арифметика.
Хорошая: вся она – степени двойки, и её реально держать в голове, а не в закладке с калькулятором.
В посте раскладываю по полочкам:
– почему в сети /24 не 256 адресов, а 254 (куда делись два и кто их съел);
– как за десять секунд понять, в одной ли сети два адреса – и почему от этого зависит, нужен тебе роутер или хватит свитча;
– откуда взялись 10.x, 172.16.x и 192.168.x и почему их не пускают в интернет;
– что на самом деле делает NAT, когда твой pod или домашний ноут выходят наружу под одним IP;
– IPv6 – ровно тот минимум, из-за незнания которого сервис молча не отвечает половине клиентов.
Плюс три классических подвоха с собеса (с ответами, которые не стыдно проговорить вслух) и код-челлендж: разбить
Полная версия с таблицами масок, разбором NAT в Kubernetes и шпаргалкой размеров сетей 👇
https://devopsway.ru/posts/networking-01-ip-subnets/
#networking #linux #devops
📺 В предыдущих сериях: это второй пост мини-курса "Networking 20/80" – 20% сетевых знаний, которые закрывают 80% работы DevOps. В нулевом разбирались с картой слоёв: на каком этаже искать супостата, когда всё упало. Сегодня спускаемся на этаж адресов.
На собесе меня как-то спросили: "для чего нужна маска подсети?". Мозг, натренированный на корпоративный тикет – где заполняешь поля по готовой архитектурной схеме, как предки завещали, – честно выдал то, чем реально пользуешься, когда нарезаешь подсети под контуры: "чтобы посчитать, сколько влезет хостов". Формально не враньё. Но это ответ про побочный эффект, а не про смысл – и если интервьюер в теме, он тут же начнёт раскручивать тебя в нужном направлении, или нет 😅
А смысл в том, что маска проводит границу: где заканчивается "своя" сеть и начинается "чужая". Из этой границы растёт всё остальное – пойдёт пакет напрямую через свитч или полезет через роутер, можно ли отрезать одно окружение от другого. Сколько хостов влезет – это просто сдача от битов, которые остались под хост.
Плохая новость: в адресации действительно есть арифметика.
Хорошая: вся она – степени двойки, и её реально держать в голове, а не в закладке с калькулятором.
В посте раскладываю по полочкам:
– почему в сети /24 не 256 адресов, а 254 (куда делись два и кто их съел);
– как за десять секунд понять, в одной ли сети два адреса – и почему от этого зависит, нужен тебе роутер или хватит свитча;
– откуда взялись 10.x, 172.16.x и 192.168.x и почему их не пускают в интернет;
– что на самом деле делает NAT, когда твой pod или домашний ноут выходят наружу под одним IP;
– IPv6 – ровно тот минимум, из-за незнания которого сервис молча не отвечает половине клиентов.
Плюс три классических подвоха с собеса (с ответами, которые не стыдно проговорить вслух) и код-челлендж: разбить
10.100.0.0/16 на prod, staging и dev так, чтобы ничего не пересеклось.Полная версия с таблицами масок, разбором NAT в Kubernetes и шпаргалкой размеров сетей 👇
https://devopsway.ru/posts/networking-01-ip-subnets/
#networking #linux #devops
🔥4
⚡️ DevOps Digest #22 | 06.07.2026
🔥 Главное за неделю:
1. Вышел Git 2.55.0 – появилась
🔗 https://about.gitlab.com/blog/whats-new-in-git-2-55-0/
2. Анатомия атаки на Codecov: звонок из твоего же пайплайна – разбор того, как одна строка в bash-скрипте 61 день сливала переменные окружения из CI-раннеров тысяч организаций. Это не разовый сбой одного вендора, а структурная дыра почти всех CI. Если секреты живут в пайплайне – прочти и проверь, что и откуда ты curl-ишь в раннере.
🔗 https://thenewstack.io/codecov-supply-chain-attack/
3. Docker vs Kubernetes: нужен ли тебе оркестратор уже сейчас – трезвый разбор для тех, кто вкатывается. Docker пакует и запускает контейнер на одной машине, Kubernetes держит заявленное состояние на флоте машин. Ранний переезд на K8s – это сложность, которая аукнется в субботу с пейджером в руках, а не выгода.
🔗 https://dev.to/jjoyneriv/docker-vs-kubernetes-do-you-actually-need-an-orchestrator-yet-57k0
4. Как перенести Docker Compose на новую VPS без даунтайма – практический гайд ровно под типовую скромную инфру: один сервер, compose, nginx как реверс-прокси. Разобран переезд к провайдеру пожирнее без простоя для круглосуточного сервиса.
🔗 https://habr.com/ru/articles/1055858/
5. EasyTier – децентрализованный mesh-VPN на Rust с поддержкой WireGuard – self-hosted и cloud-agnostic: связать разбросанные машины в единую сеть внутри закрытого контура без чужого облака и центрального сервера. 200+ звёзд за неделю – стоит присмотреться.
🔗 https://github.com/EasyTier/EasyTier
6. Health, readiness и observability: что измерять, прежде чем назвать сервис "живым" – понятный джуну разбор, чем liveness отличается от readiness и как отличить "процесс запущен" от "сервис реально обслуживает запросы". База, на которой строятся нормальные пробы в K8s.
🔗 https://blog.stackademic.com/health-readiness-and-observability-signals-what-to-measure-before-you-call-something-up-0c4c64f6ae64
🛠 Команда недели:
Показывает удалённые, но всё ещё открытые процессами файлы – ровно тот случай, когда
#дайджест #devops #cicd
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Вышел Git 2.55.0 – появилась
git history fixup: правки уходят в старый коммит без интерактивного rebase, а все зависимые ветки в стеке пересобираются сами. Плюс fsmonitor-демон для Linux (быстрый git status в монорепо) и ускоренные git grep/git cherry в partial clone.🔗 https://about.gitlab.com/blog/whats-new-in-git-2-55-0/
2. Анатомия атаки на Codecov: звонок из твоего же пайплайна – разбор того, как одна строка в bash-скрипте 61 день сливала переменные окружения из CI-раннеров тысяч организаций. Это не разовый сбой одного вендора, а структурная дыра почти всех CI. Если секреты живут в пайплайне – прочти и проверь, что и откуда ты curl-ишь в раннере.
🔗 https://thenewstack.io/codecov-supply-chain-attack/
3. Docker vs Kubernetes: нужен ли тебе оркестратор уже сейчас – трезвый разбор для тех, кто вкатывается. Docker пакует и запускает контейнер на одной машине, Kubernetes держит заявленное состояние на флоте машин. Ранний переезд на K8s – это сложность, которая аукнется в субботу с пейджером в руках, а не выгода.
🔗 https://dev.to/jjoyneriv/docker-vs-kubernetes-do-you-actually-need-an-orchestrator-yet-57k0
4. Как перенести Docker Compose на новую VPS без даунтайма – практический гайд ровно под типовую скромную инфру: один сервер, compose, nginx как реверс-прокси. Разобран переезд к провайдеру пожирнее без простоя для круглосуточного сервиса.
🔗 https://habr.com/ru/articles/1055858/
5. EasyTier – децентрализованный mesh-VPN на Rust с поддержкой WireGuard – self-hosted и cloud-agnostic: связать разбросанные машины в единую сеть внутри закрытого контура без чужого облака и центрального сервера. 200+ звёзд за неделю – стоит присмотреться.
🔗 https://github.com/EasyTier/EasyTier
6. Health, readiness и observability: что измерять, прежде чем назвать сервис "живым" – понятный джуну разбор, чем liveness отличается от readiness и как отличить "процесс запущен" от "сервис реально обслуживает запросы". База, на которой строятся нормальные пробы в K8s.
🔗 https://blog.stackademic.com/health-readiness-and-observability-signals-what-to-measure-before-you-call-something-up-0c4c64f6ae64
🛠 Команда недели:
lsof -nP +L1 2>/dev/null | sort -k7 -rn | head
Показывает удалённые, но всё ещё открытые процессами файлы – ровно тот случай, когда
df кричит "диск полон", а du ничего не находит. Классика после ротации логов: место освободится только после рестарта процесса или обнуления его дескриптора.#дайджест #devops #cicd
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
GitLab
What's new in Git 2.55.0?
Learn about the new features and changes in Git 2.55, including a new git-history(1) fixup command, an fsmonitor daemon for Linux, pushing to remote groups, and more.
🔥3❤2
Услуги связи снова доступны в полном объёме
Чего уж там, сам себе злобный Буратино. Полгода не оплачивал один из номеров, и он уплыл. Но вот дальше началась дивная механика операторов, которую пришлось вытягивать из поддержки по кускам.
Схема классическая: номер когда-то перенёс по MNP к другому оператору. Новому платить перестал, тот молча расторг договор и вернул номер "материнскому" оператору – туда, где он родился. Там он благополучно упал в карантин.
Звоню материнскому оператору, прошу вернуть как было. Поддержка идёт навстречу, оформляет заявку, и мне падает SMS:
Номер обращения есть, тикет закрыт, галочка в биллинге горит. Система отработала безупречно. Правда, ровно через сутки этот номер купил совершенно другой человек.
В этой истории нет злого умысла. Это чистокровный разрыв между верификацией и валидацией, который ломает прод каждый день.
Верификация – это проверка "сделали ли мы то, что написано в ТЗ". Система заглянула внутрь себя: блок снят, статус поменялся, SMS улетела. Внутренняя логика сошлась, тесты зелёные.
Валидация – это проверка "а совпадает ли результат с реальным миром". В реальности "доступны в полном объёме" означало лишь то, что с моей стороны сняли технический стоп-лист. Но сам номер к этому моменту уже крутился на витрине свободных продаж.
Моя интенция – получить рабочий инструмент – и то, что сделала автоматика, разошлись.
Самое прекрасное в этой SMS – строчка внизу: "Невозможно отправить сообщение на специальный номер". Верификация всегда рапортует в одну сторону, у неё в принципе нет обратного канала из реальности.
Обычный человек на этом месте начинает недоумевать. А инженер, который эту оппозицию видит в проде каждую неделю, просто грустно усмехается.
Зелёный пайплайн умеет виртуозно врать, потому что верификация никогда не выходит наружу – она проверяет только соответствие системы её собственным представлениям о себе.
Мостом в реальность работает исключительно валидация.
Мы видим это постоянно:
– Балансировщик льёт трафик на бэкенд, потому что
– Пайплайн зелёный, а выкаченная фича делает вообще не то, что нужно бизнесу.
–
Система уверенно рапортует об успехе в рамках своей закрытой модели, пока реальный мир за её пределами горит синим пламенем.
В декабре я писал пост про коммуникативные неудачи в DevOps-культуре и про то, как интенция ломается об интерпретацию. История с номером – ровно тот же зазор, только на стыке человека и автоматики.
Хайп вокруг AI обостряет эту проблему до предела. Нейросети гениально верифицируют: код компилируется, тесты проходят. Но они не умеют в валидацию, потому что физического мира не видят. "Всё зелёное" от ассистента – это лишь доклад о том, что его внутренняя модель непротиворечива сама себе. О том, как это отработает под нагрузкой, он не знает ничего.
Инженерная зрелость начинается там, где появляется привычка не верить зелёному статусу. Вся боль прода живёт именно в этом зазоре между "сделано по спецификации" и "а в жизни-то что".
Мой номер в итоге так и остался у нового владельца. Верификация сказала "да", реальность – "давай, до свидания".
#devops #ai #кейс
Чего уж там, сам себе злобный Буратино. Полгода не оплачивал один из номеров, и он уплыл. Но вот дальше началась дивная механика операторов, которую пришлось вытягивать из поддержки по кускам.
Схема классическая: номер когда-то перенёс по MNP к другому оператору. Новому платить перестал, тот молча расторг договор и вернул номер "материнскому" оператору – туда, где он родился. Там он благополучно упал в карантин.
Звоню материнскому оператору, прошу вернуть как было. Поддержка идёт навстречу, оформляет заявку, и мне падает SMS:
"Мы восстановили ваш номер. Услуги связи снова доступны в полном объёме. Обращение №1-890776747009"
Номер обращения есть, тикет закрыт, галочка в биллинге горит. Система отработала безупречно. Правда, ровно через сутки этот номер купил совершенно другой человек.
В этой истории нет злого умысла. Это чистокровный разрыв между верификацией и валидацией, который ломает прод каждый день.
Верификация – это проверка "сделали ли мы то, что написано в ТЗ". Система заглянула внутрь себя: блок снят, статус поменялся, SMS улетела. Внутренняя логика сошлась, тесты зелёные.
Валидация – это проверка "а совпадает ли результат с реальным миром". В реальности "доступны в полном объёме" означало лишь то, что с моей стороны сняли технический стоп-лист. Но сам номер к этому моменту уже крутился на витрине свободных продаж.
Моя интенция – получить рабочий инструмент – и то, что сделала автоматика, разошлись.
Самое прекрасное в этой SMS – строчка внизу: "Невозможно отправить сообщение на специальный номер". Верификация всегда рапортует в одну сторону, у неё в принципе нет обратного канала из реальности.
Обычный человек на этом месте начинает недоумевать. А инженер, который эту оппозицию видит в проде каждую неделю, просто грустно усмехается.
Зелёный пайплайн умеет виртуозно врать, потому что верификация никогда не выходит наружу – она проверяет только соответствие системы её собственным представлениям о себе.
Мостом в реальность работает исключительно валидация.
Мы видим это постоянно:
– Балансировщик льёт трафик на бэкенд, потому что
/health честно отдаёт 200 OK (verified). А то, что пул коннектов к базе мёртв и ни один пользовательский запрос не проходит – никого не волнует (not validated).– Пайплайн зелёный, а выкаченная фича делает вообще не то, что нужно бизнесу.
–
terraform apply прошёл без ошибок, а инфраструктура разъехалась с реальностью из-за дрейфа.Система уверенно рапортует об успехе в рамках своей закрытой модели, пока реальный мир за её пределами горит синим пламенем.
В декабре я писал пост про коммуникативные неудачи в DevOps-культуре и про то, как интенция ломается об интерпретацию. История с номером – ровно тот же зазор, только на стыке человека и автоматики.
Хайп вокруг AI обостряет эту проблему до предела. Нейросети гениально верифицируют: код компилируется, тесты проходят. Но они не умеют в валидацию, потому что физического мира не видят. "Всё зелёное" от ассистента – это лишь доклад о том, что его внутренняя модель непротиворечива сама себе. О том, как это отработает под нагрузкой, он не знает ничего.
Инженерная зрелость начинается там, где появляется привычка не верить зелёному статусу. Вся боль прода живёт именно в этом зазоре между "сделано по спецификации" и "а в жизни-то что".
Мой номер в итоге так и остался у нового владельца. Верификация сказала "да", реальность – "давай, до свидания".
#devops #ai #кейс
🔥4
"Круто, возьмём". Почему автоматизация инженера умирает через полгода
Знакомый инженер решил автоматизировать свою рутину. Раздача доступов руками съедала у него половину дня, поэтому он написал скрипт, сократив процесс с восьми часов до 15 минут. Презентовал саппорту, показал инфре, разобрал на живых примерах. Все дружно сказали: "Круто, берём в работу".
Полгода спустя – ни одного тикета, закрытого его автоматикой. Хех, классика 🤪
Обычно такие истории списывают на банальную человеческую лень и нежелание меняться. Но это слишком слабое объяснение – оно ничего не предсказывает и ни на что не влияет. На деле механика глубже, и у неё два слоя.
Технический слой поддаётся коду. Человеческий, то есть усвоение, когда понятно, кто и зачем вообще возьмёт инструмент – поддаётся стимулам, а не коду. Инженер бьёт по тому слою, который гнётся под его привычный инструмент, и локально побеждает.
Но его скрипт остаётся сольным проектом, по сути, личным чёрным ящиком. А чужие чёрные ящики никто добровольно не берёт. Желающих зависеть от чужого кода и ловить блейм, когда этот скрипт сломается с твоим именем на релизе, в проде просто нет. В итоге каждая починка технической части лишь добавляет неусвоенной поверхности в человеческую часть.
Чем сильнее он упаковывает и полирует своё решение, тем менее жизнеспособным становится целое. Локальный оптимум растёт, глобальный, закономерно, падает. Эдвардс Деминг писал, что оптимизация отдельного узла неизбежно суб-оптимизирует систему (suboptimization).
В системном мышлении это классические архетипы
Усвоение всегда живёт на слое стимулов. Пока ручной путь для сотрудника дешевле автоматического, а для человека на окладе за часы, а не за результат, рутина безопаснее и понятнее, – процесс останется ручным.
Более того, этот контур активно подкручивает само руководство. Здесь включается классический парадокс профилактики (prevention paradox): когда инженерия делает свою работу хорошо и в проде ничего не горит, её работа становится невидимой. Управленческие стимулы часто заточены на поощрение за видимое "героическое тушение" реальных кризисов (флешбеки с планерок, как высасываете из пальца КПЭ на квартал 🫠), в то время как системная профилактика рутины никак не награждается.
В итоге менеджмент сам крутит архетип
Ситуация меняется не ростом качества инструмента, а изменением стоимости самого пути. Автоматику нужно встраивать в маршрут так, чтобы обойти её было тупо дороже и сложнее, чем воспользоваться.
Напишите в комментарии, у вас в командах автоматизацию берут добровольно, или только когда обойти её становится слишком дорого?
#devops #мышление
Знакомый инженер решил автоматизировать свою рутину. Раздача доступов руками съедала у него половину дня, поэтому он написал скрипт, сократив процесс с восьми часов до 15 минут. Презентовал саппорту, показал инфре, разобрал на живых примерах. Все дружно сказали: "Круто, берём в работу".
Полгода спустя – ни одного тикета, закрытого его автоматикой. Хех, классика 🤪
Обычно такие истории списывают на банальную человеческую лень и нежелание меняться. Но это слишком слабое объяснение – оно ничего не предсказывает и ни на что не влияет. На деле механика глубже, и у неё два слоя.
Технический слой поддаётся коду. Человеческий, то есть усвоение, когда понятно, кто и зачем вообще возьмёт инструмент – поддаётся стимулам, а не коду. Инженер бьёт по тому слою, который гнётся под его привычный инструмент, и локально побеждает.
Но его скрипт остаётся сольным проектом, по сути, личным чёрным ящиком. А чужие чёрные ящики никто добровольно не берёт. Желающих зависеть от чужого кода и ловить блейм, когда этот скрипт сломается с твоим именем на релизе, в проде просто нет. В итоге каждая починка технической части лишь добавляет неусвоенной поверхности в человеческую часть.
Чем сильнее он упаковывает и полирует своё решение, тем менее жизнеспособным становится целое. Локальный оптимум растёт, глобальный, закономерно, падает. Эдвардс Деминг писал, что оптимизация отдельного узла неизбежно суб-оптимизирует систему (suboptimization).
В системном мышлении это классические архетипы
fixes that fail (решения, создающие проблемы) и shifting the burden (перенос бремени). Симптоматический фикс снимает личную рутину инженера, но способность системы решать корневую проблему, через общее усвоение практик, просто атрофируется.Усвоение всегда живёт на слое стимулов. Пока ручной путь для сотрудника дешевле автоматического, а для человека на окладе за часы, а не за результат, рутина безопаснее и понятнее, – процесс останется ручным.
Более того, этот контур активно подкручивает само руководство. Здесь включается классический парадокс профилактики (prevention paradox): когда инженерия делает свою работу хорошо и в проде ничего не горит, её работа становится невидимой. Управленческие стимулы часто заточены на поощрение за видимое "героическое тушение" реальных кризисов (флешбеки с планерок, как высасываете из пальца КПЭ на квартал 🫠), в то время как системная профилактика рутины никак не награждается.
В итоге менеджмент сам крутит архетип
shifting the burden, поощряя симптоматические фиксы и игнорируя системные изменения. Чтобы переломить это, невидимую профилактику нужно переводить на язык, который руководство понимает дефолтно – язык денег. Например, через дашборд стоимости простоя и ожидаемой ценности (expected value). Когда предотвращённый сбой или сэкономленные часы автоматизации оцифрованы в рублях, ценность инструмента становится очевидной для всей вертикали.Ситуация меняется не ростом качества инструмента, а изменением стоимости самого пути. Автоматику нужно встраивать в маршрут так, чтобы обойти её было тупо дороже и сложнее, чем воспользоваться.
Напишите в комментарии, у вас в командах автоматизацию берут добровольно, или только когда обойти её становится слишком дорого?
#devops #мышление
🔥5
⚡️ DevOps Digest #23 | 13.07.2026
🔥 Главное за неделю:
1. Уязвимость GhostApproval в шести AI-агентах для кода – исследователи Wiz показали: Claude Code, Cursor, Windsurf, Amazon Q и другие агенты пишут файлы по симлинку без разрешения пути – вредоносный репозиторий получает запись за пределы рабочей директории вплоть до RCE. Если используешь AI-агенты – не запускай их на незнакомых репозиториях без песочницы.
🔗 https://devops.com/ghostapproval-flaw-featuring-decades-old-feature-found-in-six-ai-coding-tools/
2. Argo CD опубликовал результаты опроса пользователей 2026 – 42% респондентов управляют 500+ приложениями, 79% используют ApplicationSets, главная боль – производительность одного инстанса на много кластеров. Полезный ориентир: какие паттерны GitOps стали стандартом индустрии и к чему готовиться при росте.
🔗 https://blog.argoproj.io/argo-cd-2026-user-survey-results-dcffc9a8e48e
3. Гайд: полный стек мониторинга в Docker Compose – пошаговая сборка Prometheus + Grafana + Alertmanager + cAdvisor с авто-провижнингом дашбордов, алертами и чек-листом продакшн-настройки. Готовый шаблон, если мониторинга ещё нет или он собран на коленке.
🔗 https://dev.to/ramansah/how-to-set-up-prometheus-and-grafana-monitoring-stack-with-docker-compose-3ea6
4. Управление удалёнными Windows-точками без Active Directory – живой опыт: Syncthing + Ansible + 1С вместо зоопарка BAT/PowerShell-скриптов на торговых точках с USB-модемами. Показательный пример, как IaC-подход внедряют в легаси-условиях, где "правильную" инфраструктуру не построить.
🔗 https://habr.com/ru/articles/1057308/
5. Headscale – в топе трендов GitHub недели – self-hosted реализация контрол-сервера Tailscale: mesh-VPN между площадками и сотрудниками без зависимости от чужого облака. Для закрытых контуров – одна из самых практичных альтернатив классическому VPN, стоит присмотреться.
🔗 https://github.com/juanfont/headscale
6. pgrust – клон PostgreSQL на Rust – переписан с помощью c2rust и AI-ассистента, уже проходит все регрессионные тесты PostgreSQL и совместим с форматом данных 18.3. Для прода рано, но это показательный кейс того, как AI-миграция легаси-кода становится реальностью.
🔗 https://www.opennet.ru/opennews/art.shtml?num=65879
🛠 Команда недели:
Раскладывает HTTP-запрос по фазам (DNS, TCP, TLS, ответ сервера) – когда "сервис тормозит", сразу видно, где именно теряется время.
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Уязвимость GhostApproval в шести AI-агентах для кода – исследователи Wiz показали: Claude Code, Cursor, Windsurf, Amazon Q и другие агенты пишут файлы по симлинку без разрешения пути – вредоносный репозиторий получает запись за пределы рабочей директории вплоть до RCE. Если используешь AI-агенты – не запускай их на незнакомых репозиториях без песочницы.
🔗 https://devops.com/ghostapproval-flaw-featuring-decades-old-feature-found-in-six-ai-coding-tools/
2. Argo CD опубликовал результаты опроса пользователей 2026 – 42% респондентов управляют 500+ приложениями, 79% используют ApplicationSets, главная боль – производительность одного инстанса на много кластеров. Полезный ориентир: какие паттерны GitOps стали стандартом индустрии и к чему готовиться при росте.
🔗 https://blog.argoproj.io/argo-cd-2026-user-survey-results-dcffc9a8e48e
3. Гайд: полный стек мониторинга в Docker Compose – пошаговая сборка Prometheus + Grafana + Alertmanager + cAdvisor с авто-провижнингом дашбордов, алертами и чек-листом продакшн-настройки. Готовый шаблон, если мониторинга ещё нет или он собран на коленке.
🔗 https://dev.to/ramansah/how-to-set-up-prometheus-and-grafana-monitoring-stack-with-docker-compose-3ea6
4. Управление удалёнными Windows-точками без Active Directory – живой опыт: Syncthing + Ansible + 1С вместо зоопарка BAT/PowerShell-скриптов на торговых точках с USB-модемами. Показательный пример, как IaC-подход внедряют в легаси-условиях, где "правильную" инфраструктуру не построить.
🔗 https://habr.com/ru/articles/1057308/
5. Headscale – в топе трендов GitHub недели – self-hosted реализация контрол-сервера Tailscale: mesh-VPN между площадками и сотрудниками без зависимости от чужого облака. Для закрытых контуров – одна из самых практичных альтернатив классическому VPN, стоит присмотреться.
🔗 https://github.com/juanfont/headscale
6. pgrust – клон PostgreSQL на Rust – переписан с помощью c2rust и AI-ассистента, уже проходит все регрессионные тесты PostgreSQL и совместим с форматом данных 18.3. Для прода рано, но это показательный кейс того, как AI-миграция легаси-кода становится реальностью.
🔗 https://www.opennet.ru/opennews/art.shtml?num=65879
🛠 Команда недели:
curl -o /dev/null -sw 'dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n' https://example.comРаскладывает HTTP-запрос по фазам (DNS, TCP, TLS, ответ сервера) – когда "сервис тормозит", сразу видно, где именно теряется время.
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
DevOps.com
GhostApproval Flaw Featuring Decades-Old Feature Found in Six AI Coding Tools
Six major AI coding tools, including Anthropic's Claude Code and Google's Antigravity, are vulnerable to a decades-old Unix feature that attackers can abuse to trick them into showing sensitive information or handing them control of a developer's system,…
🔥5
DNS: почему "виноват всегда он" и как доказать это за минуту
📺 В предыдущих сериях: это третий пост мини-курса "Networking 20/80" – 20% сетевых знаний, закрывающих 80% работы DevOps. Уже разобрали карту слоёв и математику адресов. Сегодня – система имён, из-за которой прод падает чаще всего.
Старая инженерная классика: если что-то сломалось – это DNS. Уверен, что не DNS? Значит, плохо проверял. Смешно ровно до момента, когда сервис перестаёт видеть базу, а
DNS – это телефонная книга интернета, только распределённая по миллионам серверов и кешированная на каждом шагу: браузер, ОС, промежуточные резолверы. Поменял запись, а часть пользователей ещё сутки ходит на старый адрес, пока не протухнет TTL. Лёг резолвер – новое имя вообще не поднимется:
В посте разложил базу, которую спрашивают на каждом втором собесе:
– путь резолва (кеш браузера →
– A против CNAME – чем отличаются и как лишний CNAME незаметно съедает запросы;
– ловушка
–
Плюс три подвоха с собеса и чеклист диагностики на три ночи.
Полная версия 👇
https://devopsway.ru/posts/networking-02-dns/
#networking #linux #devops
📺 В предыдущих сериях: это третий пост мини-курса "Networking 20/80" – 20% сетевых знаний, закрывающих 80% работы DevOps. Уже разобрали карту слоёв и математику адресов. Сегодня – система имён, из-за которой прод падает чаще всего.
Старая инженерная классика: если что-то сломалось – это DNS. Уверен, что не DNS? Значит, плохо проверял. Смешно ровно до момента, когда сервис перестаёт видеть базу, а
ping по имени молчит, хотя по IP всё живо.DNS – это телефонная книга интернета, только распределённая по миллионам серверов и кешированная на каждом шагу: браузер, ОС, промежуточные резолверы. Поменял запись, а часть пользователей ещё сутки ходит на старый адрес, пока не протухнет TTL. Лёг резолвер – новое имя вообще не поднимется:
NXDOMAIN или тишина до таймаута.В посте разложил базу, которую спрашивают на каждом втором собесе:
– путь резолва (кеш браузера →
/etc/hosts → кеш ОС → DNS) и почему /etc/hosts всегда побеждает;– A против CNAME – чем отличаются и как лишний CNAME незаметно съедает запросы;
– ловушка
ndots:5 – как CoreDNS в Kubernetes тихо превращает один запрос в пять;–
dig – как одной командой найти, где именно застрял резолв.Плюс три подвоха с собеса и чеклист диагностики на три ночи.
Полная версия 👇
https://devopsway.ru/posts/networking-02-dns/
#networking #linux #devops
❤4🥰1
⚡️ DevOps Digest #24 | 20.07.2026
🔥 Главное за неделю:
1. xAI выложила Grok Build в open-source после утечки SSH-ключей – терминальный AI-агент для кода тихо заливал целые репозитории (SSH-ключи, .env, базы паролей) в облачный бакет xAI, игнорируя переключатель приватности. Урок на всю неделю: любой AI-инструмент в терминале запускай в изолированном окружении, а не в домашней директории.
🔗 https://devops.com/xai-open-sources-grok-build-coding-agent-after-cloud-upload-exposes-ssh-keys-repos/
2. Полный гайд по Squid 7.5: krb+ldap, ssl-bump, JSON-логи, кэш – детальная инструкция по прокси для закрытого контура, собранная в одном месте вместо десятка форумов и устаревших статей. Актуально для on-premise, где Squid до сих пор держит весь исходящий трафик.
🔗 https://habr.com/ru/articles/1060658/
3. Паттерн App of Apps в Argo CD на практике – как одним родительским Application управлять всем стеком: дочерние приложения, Helm-чарты, health-checks, единая синхронизация. Хороший старт для тех, кто выстраивает GitOps без ручного kubectl apply.
🔗 https://dev.to/ptp2308/mastering-argo-cd-app-of-apps-for-python-microservices-36a4
4. lima – контейнеры и Linux-VM локально без облака – легковесная альтернатива Docker Desktop без лицензионных ограничений: поднимает Linux-виртуалку под контейнеры одной командой. Удобно для on-prem и локальной разработки.
🔗 https://github.com/lima-vm/lima
5. AI не сдвинул узкое место с кодинга на ревью – по данным исследования, у 90% команд изменения копятся пачками между ревью и деплоем, и скорость теряется именно там, а не в написании кода. Повод посчитать, сколько ваших PR прошли ревью, но ещё не выкачены пользователям.
🔗 https://thenewstack.io/ai-code-bottleneck-myth/
6. Кривой DNSSEC-ролловер положил всю зону .al – одна ошибка при смене ключей сделала недоступными все домены национальной зоны Албании. Резолвер 1.1.1.1 теперь через EDE-код сообщает, когда DNSSEC-валидация обойдена. Напоминание: смена DNSSEC-ключей – операция с риском на весь домен, а не рутинная замена.
🔗 https://blog.cloudflare.com/dnssec-nta-ede-33/
7. Порция security-патчей: nginx, podman, buildah, skopeo, qemu-kvm – свежие обновления для контейнерного стека и веб-серверов в Alma/Oracle/RHEL/SUSE/Ubuntu. Если держите легаси на длинной поддержке – проверьте, что докатили критичное.
🔗 https://lwn.net/Articles/1083201/
🛠 Команда недели:
Показывает все файлы с установленными Linux capabilities (cap_net_raw, cap_setuid и т.д.) – быстрый аудит потенциальных векторов эскалации привилегий, которые обычные права в chmod не покажут.
#дайджест #security #linux
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. xAI выложила Grok Build в open-source после утечки SSH-ключей – терминальный AI-агент для кода тихо заливал целые репозитории (SSH-ключи, .env, базы паролей) в облачный бакет xAI, игнорируя переключатель приватности. Урок на всю неделю: любой AI-инструмент в терминале запускай в изолированном окружении, а не в домашней директории.
🔗 https://devops.com/xai-open-sources-grok-build-coding-agent-after-cloud-upload-exposes-ssh-keys-repos/
2. Полный гайд по Squid 7.5: krb+ldap, ssl-bump, JSON-логи, кэш – детальная инструкция по прокси для закрытого контура, собранная в одном месте вместо десятка форумов и устаревших статей. Актуально для on-premise, где Squid до сих пор держит весь исходящий трафик.
🔗 https://habr.com/ru/articles/1060658/
3. Паттерн App of Apps в Argo CD на практике – как одним родительским Application управлять всем стеком: дочерние приложения, Helm-чарты, health-checks, единая синхронизация. Хороший старт для тех, кто выстраивает GitOps без ручного kubectl apply.
🔗 https://dev.to/ptp2308/mastering-argo-cd-app-of-apps-for-python-microservices-36a4
4. lima – контейнеры и Linux-VM локально без облака – легковесная альтернатива Docker Desktop без лицензионных ограничений: поднимает Linux-виртуалку под контейнеры одной командой. Удобно для on-prem и локальной разработки.
🔗 https://github.com/lima-vm/lima
5. AI не сдвинул узкое место с кодинга на ревью – по данным исследования, у 90% команд изменения копятся пачками между ревью и деплоем, и скорость теряется именно там, а не в написании кода. Повод посчитать, сколько ваших PR прошли ревью, но ещё не выкачены пользователям.
🔗 https://thenewstack.io/ai-code-bottleneck-myth/
6. Кривой DNSSEC-ролловер положил всю зону .al – одна ошибка при смене ключей сделала недоступными все домены национальной зоны Албании. Резолвер 1.1.1.1 теперь через EDE-код сообщает, когда DNSSEC-валидация обойдена. Напоминание: смена DNSSEC-ключей – операция с риском на весь домен, а не рутинная замена.
🔗 https://blog.cloudflare.com/dnssec-nta-ede-33/
7. Порция security-патчей: nginx, podman, buildah, skopeo, qemu-kvm – свежие обновления для контейнерного стека и веб-серверов в Alma/Oracle/RHEL/SUSE/Ubuntu. Если держите легаси на длинной поддержке – проверьте, что докатили критичное.
🔗 https://lwn.net/Articles/1083201/
🛠 Команда недели:
getcap -r / 2>/dev/null
Показывает все файлы с установленными Linux capabilities (cap_net_raw, cap_setuid и т.д.) – быстрый аудит потенциальных векторов эскалации привилегий, которые обычные права в chmod не покажут.
#дайджест #security #linux
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
DevOps.com
xAI Open-Sources Grok Build Coding Agent After Cloud Upload Exposes SSH Keys, Repos
xAI open-sourced Grok Build after researchers found the coding agent uploading developer repositories and sensitive credentials to an xAI cloud bucket.
🔥4❤1
Connection refused и Connection timeout – это два разных диагноза. Перепутал – и чинишь не ту половину системы.
Ошибка на вид одна, причина противоположная. "Connection refused" – на том конце кто-то есть и ответил "нет": порт закрыт, сервис не слушает или слушает на 127.0.0.1 вместо 0.0.0.0.
"Connection timeout" – ответа нет вообще: пакет ушёл в пустоту, файрвол сделал DROP, не тот адрес или нода недоступна. Первое – проблема на хосте, второе – в сети. Различить за полминуты дешевле, чем полчаса чинить не то.
Разницу задаёт TCP – надёжная доставка поверх ненадёжной сети: рукопожатие, номера последовательностей, подтверждения.
Рядом UDP – без рукопожатий и гарантий, зато быстрый: на нём работают DNS и видеозвонки.
📺 Networking 20/80, четвёртый пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Слои, адреса и имена уже разобрали – сегодня о том, как между двумя точками устанавливается связь.
В посте:
– TCP против UDP: когда нужна гарантия доставки, а когда скорость;
– трёхстороннее рукопожатие – зачем три пакета, а не два;
– что такое сокет и почему nginx на одном порту 8080 держит тысячи соединений;
– состояния соединения и TIME_WAIT, который пугает в выводе ss;
– ss и tcpdump: кто на самом деле слушает порт (и тот самый 127.0.0.1) и куда уходят пакеты;
– чеклист "почему не подключается" по слоям, от кабеля до приложения;
– три вопроса с собеса – с разбором, что отвечать.
Полная версия 👇
https://devopsway.ru/posts/networking-03-tcp-udp/
#networking #linux #devops
Ошибка на вид одна, причина противоположная. "Connection refused" – на том конце кто-то есть и ответил "нет": порт закрыт, сервис не слушает или слушает на 127.0.0.1 вместо 0.0.0.0.
"Connection timeout" – ответа нет вообще: пакет ушёл в пустоту, файрвол сделал DROP, не тот адрес или нода недоступна. Первое – проблема на хосте, второе – в сети. Различить за полминуты дешевле, чем полчаса чинить не то.
Разницу задаёт TCP – надёжная доставка поверх ненадёжной сети: рукопожатие, номера последовательностей, подтверждения.
Рядом UDP – без рукопожатий и гарантий, зато быстрый: на нём работают DNS и видеозвонки.
📺 Networking 20/80, четвёртый пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Слои, адреса и имена уже разобрали – сегодня о том, как между двумя точками устанавливается связь.
В посте:
– TCP против UDP: когда нужна гарантия доставки, а когда скорость;
– трёхстороннее рукопожатие – зачем три пакета, а не два;
– что такое сокет и почему nginx на одном порту 8080 держит тысячи соединений;
– состояния соединения и TIME_WAIT, который пугает в выводе ss;
– ss и tcpdump: кто на самом деле слушает порт (и тот самый 127.0.0.1) и куда уходят пакеты;
– чеклист "почему не подключается" по слоям, от кабеля до приложения;
– три вопроса с собеса – с разбором, что отвечать.
Полная версия 👇
https://devopsway.ru/posts/networking-03-tcp-udp/
#networking #linux #devops
🔥2❤1
Утренний шторм в инфраструктуре не начинается с громких взрывов – он стартует с тихого шёпота в алертах.
Сегодня прилетел алерт с моей инфры. В 06:15:45 мониторинг фиксирует рядовой сбой:
На этот предупреждающий писк я почти забил. А зря: именно он оказался единственным свидетелем катастрофы, которая через несколько минут уронит сервер в софтверный нокаут с перегревом процессора до 96°C 🫠
Как один ночной апдейт запускает цепную реакцию:
1. Автообновление (unattended-upgrades) ночью накатывает новый драйвер NVIDIA. Пользовательские библиотеки и модуль на диске получают новую версию, а работающий в ядре старый выгрузить нельзя, его держат активные процессы. Возникает критический рассинхрон версий (mismatch).
2. Сервисы теряют GPU, падают на процессор, нагрузка улетает в космос, система раскаляется докрасна.
3. И вишенка: Docker рапортует, что девайс используют все контейнеры разом, а реально его держат всего два процесса. Манифесты врут, симптомы маскируют истинную причину.
Как распутать клубок версий, выгрузить старый драйвер без ребута хоста и настроить детектор рассинхрона, чтобы ловить проблему за 9 минут до перегрева – в подробном разборе:
👉 https://devopsway.ru/posts/incident-nvidia-driver-mismatch/
#кейс #devops
Сегодня прилетел алерт с моей инфры. В 06:15:45 мониторинг фиксирует рядовой сбой:
⚠️ SystemdServiceFailed: nvidia-cdi-refresh.service — failed
На этот предупреждающий писк я почти забил. А зря: именно он оказался единственным свидетелем катастрофы, которая через несколько минут уронит сервер в софтверный нокаут с перегревом процессора до 96°C 🫠
Как один ночной апдейт запускает цепную реакцию:
1. Автообновление (unattended-upgrades) ночью накатывает новый драйвер NVIDIA. Пользовательские библиотеки и модуль на диске получают новую версию, а работающий в ядре старый выгрузить нельзя, его держат активные процессы. Возникает критический рассинхрон версий (mismatch).
2. Сервисы теряют GPU, падают на процессор, нагрузка улетает в космос, система раскаляется докрасна.
3. И вишенка: Docker рапортует, что девайс используют все контейнеры разом, а реально его держат всего два процесса. Манифесты врут, симптомы маскируют истинную причину.
Как распутать клубок версий, выгрузить старый драйвер без ребута хоста и настроить детектор рассинхрона, чтобы ловить проблему за 9 минут до перегрева – в подробном разборе:
👉 https://devopsway.ru/posts/incident-nvidia-driver-mismatch/
#кейс #devops
❤2🔥2
⚡️ DevOps Digest #25 | 27.07.2026
🔥 Главное за неделю:
1. 10 типичных ошибок в CI/CD-пайплайнах – от "set and forget" до одного монолитного пайплайна на всё, из-за чего сборки тормозят, а команда буксует. Хороший чек-лист, чтобы пересобрать процесс, а не терпеть 40-минутные прогоны на каждый push.
🔗 https://devops.com/these-are-10-ci-cd-pipeline-mistakes-that-slow-down-engineering-teams-2/
2. Self-hosted WAF в Docker за 15 минут – разбор, как поставить перед своим стеком открытый SafeLine (reverse-proxy перед Nginx), не трогая код приложения. Режет ботов, сканеры и SQL-инъекции; ставится рядом с уже работающим reverse-proxy. Практично для одиночного VPS, который сразу начинают сканировать из интернета.
🔗 https://dev.to/_eb0609572b9efcf27472066/how-i-added-a-self-hosted-waf-to-my-docker-stack-in-15-minutes-11hn
3. Observability в одном Go-бинарнике – инженер собрал self-hosted, Sentry-совместимый сбор ошибок поверх PostgreSQL и ClickHouse, без Kafka и Redis. Для пары проектов, где официальные "два десятка контейнеров" – это перебор; перенос сводится к смене DSN в существующем SDK.
🔗 https://habr.com/ru/articles/1062624/
4. Terraform: восстановление workspace и Stacks (GA) – HCP/Terraform Enterprise научился откатывать удалённый workspace или stack в один клик, вместе со стейтом, историей прогонов и переменными. Раньше случайно снесённое окружение импортировали руками по ресурсу – теперь есть штатный recovery.
🔗 https://www.hashicorp.com/blog/terraform-introduces-workspaces-and-stacks-restore-and-more
5. Что сломалось, что зависит, кто владелец – три вопроса при любом алерте, на которые без карты сервисов (service map) отвечают часами методом тыка. Разбор, как service architecture превращает эти часы в минуты. База для быстрого разбора инцидентов, которой в легаси-командах часто просто нет.
🔗 https://thenewstack.io/build-resilient-service-architecture/
6. SRE Weekly #527 – свежая подборка: цена дежурства с кодом, который написал AI (кто и как отлаживает это в 3 ночи), негативное время до обнаружения инцидента и разбор сложной миграции Kafka в Honeycomb. Хорошее чтение на неделю.
🔗 https://sreweekly.com/sre-weekly-issue-527/
🛠 Команда недели:
Показывает, что реально занимает место на Docker-хосте – образы, контейнеры, тома и build cache, с колонкой RECLAIMABLE (сколько можно освободить). Первое, что смотреть, когда на сервере внезапно кончается диск, до того как вслепую запускать prune.
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. 10 типичных ошибок в CI/CD-пайплайнах – от "set and forget" до одного монолитного пайплайна на всё, из-за чего сборки тормозят, а команда буксует. Хороший чек-лист, чтобы пересобрать процесс, а не терпеть 40-минутные прогоны на каждый push.
🔗 https://devops.com/these-are-10-ci-cd-pipeline-mistakes-that-slow-down-engineering-teams-2/
2. Self-hosted WAF в Docker за 15 минут – разбор, как поставить перед своим стеком открытый SafeLine (reverse-proxy перед Nginx), не трогая код приложения. Режет ботов, сканеры и SQL-инъекции; ставится рядом с уже работающим reverse-proxy. Практично для одиночного VPS, который сразу начинают сканировать из интернета.
🔗 https://dev.to/_eb0609572b9efcf27472066/how-i-added-a-self-hosted-waf-to-my-docker-stack-in-15-minutes-11hn
3. Observability в одном Go-бинарнике – инженер собрал self-hosted, Sentry-совместимый сбор ошибок поверх PostgreSQL и ClickHouse, без Kafka и Redis. Для пары проектов, где официальные "два десятка контейнеров" – это перебор; перенос сводится к смене DSN в существующем SDK.
🔗 https://habr.com/ru/articles/1062624/
4. Terraform: восстановление workspace и Stacks (GA) – HCP/Terraform Enterprise научился откатывать удалённый workspace или stack в один клик, вместе со стейтом, историей прогонов и переменными. Раньше случайно снесённое окружение импортировали руками по ресурсу – теперь есть штатный recovery.
🔗 https://www.hashicorp.com/blog/terraform-introduces-workspaces-and-stacks-restore-and-more
5. Что сломалось, что зависит, кто владелец – три вопроса при любом алерте, на которые без карты сервисов (service map) отвечают часами методом тыка. Разбор, как service architecture превращает эти часы в минуты. База для быстрого разбора инцидентов, которой в легаси-командах часто просто нет.
🔗 https://thenewstack.io/build-resilient-service-architecture/
6. SRE Weekly #527 – свежая подборка: цена дежурства с кодом, который написал AI (кто и как отлаживает это в 3 ночи), негативное время до обнаружения инцидента и разбор сложной миграции Kafka в Honeycomb. Хорошее чтение на неделю.
🔗 https://sreweekly.com/sre-weekly-issue-527/
🛠 Команда недели:
docker system df -v
Показывает, что реально занимает место на Docker-хосте – образы, контейнеры, тома и build cache, с колонкой RECLAIMABLE (сколько можно освободить). Первое, что смотреть, когда на сервере внезапно кончается диск, до того как вслепую запускать prune.
#дайджест #devops #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
DevOps.com
These are 10 CI/CD Pipeline Mistakes That Slow Down Engineering Teams
Avoid common CI/CD pipeline mistakes that slow software delivery, increase costs, and reduce developer productivity.
❤2🔥1
"Я джун, взяли меня прямо перед твоим отпуском.
Ты уехал на Багамы, связь фиговая – еле созвонились.
У нас полсайта лежит, я твои руки на клавиатуре. Диктуй, что делать."
Один из моих дежурный вопросов на собесе, который позволял понять, кто по ту сторону экрана. И это честная проверка: знаешь ты сети или просто помнишь, куда тыкать. Печатаешь не ты – мышечная память бесполезна. Надо вслух, по шагам, вести чужие руки: что за ошибка, на каком уровне искать, какой командой.
А половина таких "полсайта лёг" – это 5xx на прокси. Первое, что диктуешь джуну: не рестартить nginx – он-то как раз работает. 502 значит, что прокси жив, но не достучался до бэкенда за ним. Дальше по шагам: curl к бэкенду мимо nginx, ss – кто слушает порт, логи. Чинишь либо сам сервис, либо связь до него.
📺 Networking 20/80, пятый пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Слои, адреса, имена и соединения уже разобрали – сегодня язык, на котором говорит почти весь веб: HTTP и его зашифрованный конверт TLS.
В посте:
– анатомия запроса и ответа: что реально летит в
– статус-коды группами (2xx/3xx/4xx/5xx) – почему их учат пачками, а не по одному;
– 401 против 403 – классика собеса, на которой путаются даже сеньоры;
– как дебажить 502 по шагам, а не гаданием;
– TLS-рукопожатие: что именно проверяет сертификат и откуда бесплатные Let's Encrypt;
– чем HTTP/2 и HTTP/3 отличаются от привычного HTTP/1.1.
Плюс три подвоха с собеса – включая коварный "зачем TLS, если трафик и так внутри VPC".
Полная версия 👇
https://devopsway.ru/posts/networking-04-http-tls/
#networking #linux #devops
Ты уехал на Багамы, связь фиговая – еле созвонились.
У нас полсайта лежит, я твои руки на клавиатуре. Диктуй, что делать."
Один из моих дежурный вопросов на собесе, который позволял понять, кто по ту сторону экрана. И это честная проверка: знаешь ты сети или просто помнишь, куда тыкать. Печатаешь не ты – мышечная память бесполезна. Надо вслух, по шагам, вести чужие руки: что за ошибка, на каком уровне искать, какой командой.
А половина таких "полсайта лёг" – это 5xx на прокси. Первое, что диктуешь джуну: не рестартить nginx – он-то как раз работает. 502 значит, что прокси жив, но не достучался до бэкенда за ним. Дальше по шагам: curl к бэкенду мимо nginx, ss – кто слушает порт, логи. Чинишь либо сам сервис, либо связь до него.
📺 Networking 20/80, пятый пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Слои, адреса, имена и соединения уже разобрали – сегодня язык, на котором говорит почти весь веб: HTTP и его зашифрованный конверт TLS.
В посте:
– анатомия запроса и ответа: что реально летит в
curl -v;– статус-коды группами (2xx/3xx/4xx/5xx) – почему их учат пачками, а не по одному;
– 401 против 403 – классика собеса, на которой путаются даже сеньоры;
– как дебажить 502 по шагам, а не гаданием;
– TLS-рукопожатие: что именно проверяет сертификат и откуда бесплатные Let's Encrypt;
– чем HTTP/2 и HTTP/3 отличаются от привычного HTTP/1.1.
Плюс три подвоха с собеса – включая коварный "зачем TLS, если трафик и так внутри VPC".
Полная версия 👇
https://devopsway.ru/posts/networking-04-http-tls/
#networking #linux #devops
🔥5❤1
⚡️ DevOps Digest #26 | 03.08.2026
🔥 Главное за неделю:
1. Homelab дорос до прода: SQLite уронил control plane k3s – k3s по умолчанию хранит состояние в SQLite (через kine). Десятки операторов с leader-election раздули базу: WAL 13.8 ГБ не чекпоинтился, CPU в потолок, load 79 на 8 ядрах. Разбор инцидента + миграция на встроенный etcd (7.5 ГБ SQLite → 313 МБ etcd, load 79 → 5). Гоняешь k3s не только для тестов – закладывай etcd заранее.
🔗 https://dev.to/tomaszwostal/when-your-homelab-grows-up-how-sqlite-took-down-my-k3s-control-plane-1kdp
2. GitHub бьёт по supply-chain-атакам на npm и GitHub Actions – разбор, как устроены цепочки атак через пакеты и CI/CD (кража токенов, саморазмножение по сотням проектов) и какие защиты GitHub уже включил. Читать всем, у кого пайплайны тянут внешние экшены и пакеты.
🔗 https://github.blog/security/supply-chain-security/disrupting-supply-chain-attacks-on-npm-and-github-actions/
3. DNS – это инфраструктура. Управляй ей как кодом – домены и DNS-записи всё ещё правят руками в дашборде регистратора, без истории "кто что менял". Тезис простой: заводи их в Terraform/Ansible, как и остальную инфру. Напоминание – 1.1.1.1 от Cloudflare лежал 62 минуты не из-за атаки, а из-за misconfiguration.
🔗 https://thenewstack.io/dns-domain-management-automation/
4. Почему логи – недостающее звено в разборе инцидентов – метрики показывают, ЧТО сломалось, но первопричина чаще в логах, а прыжки между тремя инструментами (метрики → логи → трейсы) съедают время. У трети команд 5+ инструментов observability, у двух третей время до устранения больше 4 часов.
🔗 https://devops.com/why-log-monitoring-is-the-missing-link-in-most-incident-response-workflows/
5. gluetun – VPN-клиент в лёгком Docker-контейнере – один контейнер заворачивает трафик других сервисов в OpenVPN/WireGuard, с DNS-over-TLS и парой прокси из коробки. Удобно для self-hosted: прячешь исходящий трафик контейнеров за VPN, не трогая сами сервисы.
🔗 https://github.com/passteque/gluetun
6. SRE Weekly #528: контринтуитивно про инциденты – подборка недели: если гнаться за снижением ЧИСЛА инцидентов – система станет менее надёжной; цель – больше инцидентов, отработанных хорошо. Плюс новая роль incident tech lead и постмортем Spotify по сбою публикации подкастов.
🔗 https://sreweekly.com/sre-weekly-issue-528/
🛠 Команда недели:
Показывает, через какой интерфейс и с каким исходным IP реально уйдёт пакет к адресу. Мгновенно отвечает на вопрос "с какой NIC на самом деле выходит трафик" на multi-homed хосте – когда есть несколько сетей и подозреваешь асимметричный роутинг.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Homelab дорос до прода: SQLite уронил control plane k3s – k3s по умолчанию хранит состояние в SQLite (через kine). Десятки операторов с leader-election раздули базу: WAL 13.8 ГБ не чекпоинтился, CPU в потолок, load 79 на 8 ядрах. Разбор инцидента + миграция на встроенный etcd (7.5 ГБ SQLite → 313 МБ etcd, load 79 → 5). Гоняешь k3s не только для тестов – закладывай etcd заранее.
🔗 https://dev.to/tomaszwostal/when-your-homelab-grows-up-how-sqlite-took-down-my-k3s-control-plane-1kdp
2. GitHub бьёт по supply-chain-атакам на npm и GitHub Actions – разбор, как устроены цепочки атак через пакеты и CI/CD (кража токенов, саморазмножение по сотням проектов) и какие защиты GitHub уже включил. Читать всем, у кого пайплайны тянут внешние экшены и пакеты.
🔗 https://github.blog/security/supply-chain-security/disrupting-supply-chain-attacks-on-npm-and-github-actions/
3. DNS – это инфраструктура. Управляй ей как кодом – домены и DNS-записи всё ещё правят руками в дашборде регистратора, без истории "кто что менял". Тезис простой: заводи их в Terraform/Ansible, как и остальную инфру. Напоминание – 1.1.1.1 от Cloudflare лежал 62 минуты не из-за атаки, а из-за misconfiguration.
🔗 https://thenewstack.io/dns-domain-management-automation/
4. Почему логи – недостающее звено в разборе инцидентов – метрики показывают, ЧТО сломалось, но первопричина чаще в логах, а прыжки между тремя инструментами (метрики → логи → трейсы) съедают время. У трети команд 5+ инструментов observability, у двух третей время до устранения больше 4 часов.
🔗 https://devops.com/why-log-monitoring-is-the-missing-link-in-most-incident-response-workflows/
5. gluetun – VPN-клиент в лёгком Docker-контейнере – один контейнер заворачивает трафик других сервисов в OpenVPN/WireGuard, с DNS-over-TLS и парой прокси из коробки. Удобно для self-hosted: прячешь исходящий трафик контейнеров за VPN, не трогая сами сервисы.
🔗 https://github.com/passteque/gluetun
6. SRE Weekly #528: контринтуитивно про инциденты – подборка недели: если гнаться за снижением ЧИСЛА инцидентов – система станет менее надёжной; цель – больше инцидентов, отработанных хорошо. Плюс новая роль incident tech lead и постмортем Spotify по сбою публикации подкастов.
🔗 https://sreweekly.com/sre-weekly-issue-528/
🛠 Команда недели:
ip route get 1.1.1.1
Показывает, через какой интерфейс и с каким исходным IP реально уйдёт пакет к адресу. Мгновенно отвечает на вопрос "с какой NIC на самом деле выходит трафик" на multi-homed хосте – когда есть несколько сетей и подозреваешь асимметричный роутинг.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
DEV Community
When Your Homelab Grows Up: How SQLite Took Down My k3s Control Plane
Originally published at wostal.eu. TL;DR: My Hetzner k3s lab quietly became a platform. Dozens of...
❤2🔥1
iptables -j DROP не в той строке
SSH отвалился, а до сервера уже не достучишься, пока не доберёшься до консоли.
Файрвол – это не набор правил, а алгоритм: он читает их сверху вниз и останавливается на первом совпадении.
Поставил общий DROP выше, чем ACCEPT на порт 22 и твой SSH попал под запрет раньше, чем под разрешение. Правило верное, порядок нет. На удалённом сервере это уже не отладка, а квест через управляющую консоль или через звонок админу с просьбой ребутнуть железку.
Тот же принцип белого списка кусает и в Kubernetes. Одна NetworkPolicy с default-deny на namespace и поды перестают резолвить имена: забыл открыть egress на DNS (UDP 53). По всему кластеру "Name or service not known", дежурный час копает CoreDNS, а DNS жив, его просто перестали выпускать. Обычно "виноват всегда DNS", а тут его полномочия как бы всё.
Firewall – это не стена, а фильтр: на каждый пакет решение "пропустить / отбросить молча / отказать явно" по правилам, которые читаются по порядку.
📺 Networking 20/80, шестой пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Слои, адреса, имена, соединения и HTTP уже разобрали – сегодня как этот трафик фильтровать и не отстрелить себе ногу или чего ещё 🫠
В посте:
– iptables как фундамент: таблицы, цепочки и почему их ПОРЯДОК решает – одно правило не на своём месте открывает или рубит всё;
– DROP против REJECT: почему один клиент висит до таймаута, а другой сразу ловит "refused" – и когда что выбирать;
– Kubernetes NetworkPolicy: почему в кластере по умолчанию всё открыто и как закрыть по белому списку, не уронив DNS;
– Security Groups в облаках – тот же файрвол, но для виртуалок, и чем stateful отличается от stateless;
– чеклист "почему после правила перестало работать".
Плюс три подвоха с собеса и код-челлендж: написать NetworkPolicy, которая пускает только откуда надо.
Полная версия с iptables, NetworkPolicy и Security Groups 👇
https://devopsway.ru/posts/networking-05-firewall/
#networking #security #devops
SSH отвалился, а до сервера уже не достучишься, пока не доберёшься до консоли.
Файрвол – это не набор правил, а алгоритм: он читает их сверху вниз и останавливается на первом совпадении.
Поставил общий DROP выше, чем ACCEPT на порт 22 и твой SSH попал под запрет раньше, чем под разрешение. Правило верное, порядок нет. На удалённом сервере это уже не отладка, а квест через управляющую консоль или через звонок админу с просьбой ребутнуть железку.
Тот же принцип белого списка кусает и в Kubernetes. Одна NetworkPolicy с default-deny на namespace и поды перестают резолвить имена: забыл открыть egress на DNS (UDP 53). По всему кластеру "Name or service not known", дежурный час копает CoreDNS, а DNS жив, его просто перестали выпускать. Обычно "виноват всегда DNS", а тут его полномочия как бы всё.
Firewall – это не стена, а фильтр: на каждый пакет решение "пропустить / отбросить молча / отказать явно" по правилам, которые читаются по порядку.
📺 Networking 20/80, шестой пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Слои, адреса, имена, соединения и HTTP уже разобрали – сегодня как этот трафик фильтровать и не отстрелить себе ногу или чего ещё 🫠
В посте:
– iptables как фундамент: таблицы, цепочки и почему их ПОРЯДОК решает – одно правило не на своём месте открывает или рубит всё;
– DROP против REJECT: почему один клиент висит до таймаута, а другой сразу ловит "refused" – и когда что выбирать;
– Kubernetes NetworkPolicy: почему в кластере по умолчанию всё открыто и как закрыть по белому списку, не уронив DNS;
– Security Groups в облаках – тот же файрвол, но для виртуалок, и чем stateful отличается от stateless;
– чеклист "почему после правила перестало работать".
Плюс три подвоха с собеса и код-челлендж: написать NetworkPolicy, которая пускает только откуда надо.
Полная версия с iptables, NetworkPolicy и Security Groups 👇
https://devopsway.ru/posts/networking-05-firewall/
#networking #security #devops
🔥4❤1
⚡️ DevOps Digest #27 | 10.08.2026
🔥 Главное за неделю:
1. KubeVirt: живая миграция VM между кластерами упирается не в KubeVirt, а в сеть – децентрализованная live-migration приехала в v1.6, но VM должна сохранить IP и MAC на новом кластере, а значит нужен растянутый L2 между площадками. Разбор, как это закрыть через EVPN без новых VLAN, тикетов и change-window. Актуально всем, кто переносит VM в Kubernetes взамен VMware.
🔗 https://thenewstack.io/kubevirt-evpn-vm-migration/
2. Dependabot теперь ловит вредоносные пакеты не только в npm, а в 8 экосистемах – malware-предупреждения расширены на PyPI, Maven, RubyGems, NuGet, Go, crates.io и PHP Composer (на базе открытых данных OpenSSF malicious-packages). Если тянете зависимости из публичных реестров – теперь алерты приходят и по Go, Rust, Python, а не только по JS.
🔗 https://github.blog/security/supply-chain-security/how-we-took-malware-advisories-beyond-npm/
3. Docker-песочницы в 2026: как изолировать недоверенный код и где это ломается – практический разбор границ безопасности контейнера через namespaces, cgroups и capabilities, и когда их уже мало (нужен gVisor). Главная мысль для легаси-контуров: ядро у контейнера и хоста общее, побег из контейнера = доступ к хосту.
🔗 https://dev.to/kaixintelligence/docker-sandboxes-in-2026-the-evolution-of-secure-code-isolation-55b8
4. Microsoft выложил open-source агент для генерации юнит-тестов – code-testing-generator (в репозитории dotnet/skills) полезен не столько кодом, сколько уроком про тихий отказ: AI-тесты часто компилируются и проходят локально, но никогда не запускаются в CI, потому что их забыли подключить к решению или тест-команде. Проверьте, что ваши тесты реально гоняются в пайплайне, а не только на ноутбуке.
🔗 https://devops.com/microsofts-new-testing-agent-tackles-the-trust-gap-in-ai-generated-code/
5. Ansible на русском: настройка серверов с нуля (часть 7.1 серии "С нуля до Junior DevOps") – пошагово про автоматизацию рутины после создания сервера: пакеты, пользователи, службы, Docker, Nginx. Хороший вход в IaC для джунов и тех, кто до сих пор настраивает серверы руками.
🔗 https://habr.com/ru/articles/1068460/
6. SRE Weekly #529: процесс инцидентов – это не документ, а программа – подборка недели: почему процесс управления инцидентами загнивает без поддерживающей его программы, кейс с route cache ядра как скрытым убийцей надёжности и как LLM-агенты меняют паттерны запросов к системам наблюдаемости. Пища для тех, кто выстраивает культуру эксплуатации, а не только графики.
🔗 https://sreweekly.com/sre-weekly-issue-529/
🛠 Команда недели:
Показывает счётчики ошибок и потерь по каждому интерфейсу (errors, dropped, overrun) – первый шаг, когда подозреваешь потерю пакетов или флапающий линк, прежде чем винить приложение или сеть.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. KubeVirt: живая миграция VM между кластерами упирается не в KubeVirt, а в сеть – децентрализованная live-migration приехала в v1.6, но VM должна сохранить IP и MAC на новом кластере, а значит нужен растянутый L2 между площадками. Разбор, как это закрыть через EVPN без новых VLAN, тикетов и change-window. Актуально всем, кто переносит VM в Kubernetes взамен VMware.
🔗 https://thenewstack.io/kubevirt-evpn-vm-migration/
2. Dependabot теперь ловит вредоносные пакеты не только в npm, а в 8 экосистемах – malware-предупреждения расширены на PyPI, Maven, RubyGems, NuGet, Go, crates.io и PHP Composer (на базе открытых данных OpenSSF malicious-packages). Если тянете зависимости из публичных реестров – теперь алерты приходят и по Go, Rust, Python, а не только по JS.
🔗 https://github.blog/security/supply-chain-security/how-we-took-malware-advisories-beyond-npm/
3. Docker-песочницы в 2026: как изолировать недоверенный код и где это ломается – практический разбор границ безопасности контейнера через namespaces, cgroups и capabilities, и когда их уже мало (нужен gVisor). Главная мысль для легаси-контуров: ядро у контейнера и хоста общее, побег из контейнера = доступ к хосту.
🔗 https://dev.to/kaixintelligence/docker-sandboxes-in-2026-the-evolution-of-secure-code-isolation-55b8
4. Microsoft выложил open-source агент для генерации юнит-тестов – code-testing-generator (в репозитории dotnet/skills) полезен не столько кодом, сколько уроком про тихий отказ: AI-тесты часто компилируются и проходят локально, но никогда не запускаются в CI, потому что их забыли подключить к решению или тест-команде. Проверьте, что ваши тесты реально гоняются в пайплайне, а не только на ноутбуке.
🔗 https://devops.com/microsofts-new-testing-agent-tackles-the-trust-gap-in-ai-generated-code/
5. Ansible на русском: настройка серверов с нуля (часть 7.1 серии "С нуля до Junior DevOps") – пошагово про автоматизацию рутины после создания сервера: пакеты, пользователи, службы, Docker, Nginx. Хороший вход в IaC для джунов и тех, кто до сих пор настраивает серверы руками.
🔗 https://habr.com/ru/articles/1068460/
6. SRE Weekly #529: процесс инцидентов – это не документ, а программа – подборка недели: почему процесс управления инцидентами загнивает без поддерживающей его программы, кейс с route cache ядра как скрытым убийцей надёжности и как LLM-агенты меняют паттерны запросов к системам наблюдаемости. Пища для тех, кто выстраивает культуру эксплуатации, а не только графики.
🔗 https://sreweekly.com/sre-weekly-issue-529/
🛠 Команда недели:
ip -s link
Показывает счётчики ошибок и потерь по каждому интерфейсу (errors, dropped, overrun) – первый шаг, когда подозреваешь потерю пакетов или флапающий линк, прежде чем винить приложение или сеть.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
The New Stack
Why your KubeVirt VMs can’t move between clusters — and how EVPN fixes it
Migrate KubeVirt VMs between clusters seamlessly with EVPN/VXLAN overlays and OpenPERouter CRDs. No network tickets required.
🔥6❤1
kubectl get pods – всё Running, казалось бы.
Service есть. А в ответ – 503.
Потому что selector в Service разошёлся с labels пода на один символ, и список endpoint-ов пустой. Кубер сделал ровно что просили: слать трафик туда, где никого нет.
Service – это вам не сервер. Это правило "куда слать": совпали labels – есть endpoint-ы, не совпали, пока пока, 503 при живых подах. И так на каждом слое: снаружи Ingress (L7, роутинг по Host/URL) → Service (L4, стабильный IP) → iptables/kube-proxy → pod. Пять мест, где "всё выглядит правильно", а трафик не идёт.
📺 Networking 20/80, седьмой и последний пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Модель, адреса, DNS, TCP, HTTP и файрволы уже разобрали – сегодня собираем всё вместе: как запрос снаружи долетает до пода и делится между репликами.
В посте:
– L4 против L7: почему Service балансирует по IP:порту, а маршрутизация по URL и Host – это уже Ingress;
– четыре типа Service (ClusterIP / NodePort / LoadBalancer / ExternalName) – что где открывается наружу;
– Ingress и nginx как обратный прокси: терминация TLS, upstream, алгоритмы балансировки – и почему их нельзя смешивать в одном upstream;
– service mesh на пальцах: что даёт sidecar (Envoy) и почему джуну не надо настраивать Istio;
– чеклист диагностики: Service → Endpoints → DNS → Ingress, где именно рвётся.
И да – контроллер ingress-nginx ушёл на пенсию в марте 2026. Поэтому разбираем принципы L4/L7, а не один тул: они переносятся на любой контроллер.
Плюс три подвоха с собеса (в том числе "почему kube-proxy – вовсе не proxy") и финальный код-челлендж: описать весь путь запроса от https://… до пода по слоям.
Финал мини-курса. Полная версия 👇
https://devopsway.ru/posts/networking-06-lb-k8s/
#networking #kubernetes #devops
Service есть. А в ответ – 503.
Потому что selector в Service разошёлся с labels пода на один символ, и список endpoint-ов пустой. Кубер сделал ровно что просили: слать трафик туда, где никого нет.
Service – это вам не сервер. Это правило "куда слать": совпали labels – есть endpoint-ы, не совпали, пока пока, 503 при живых подах. И так на каждом слое: снаружи Ingress (L7, роутинг по Host/URL) → Service (L4, стабильный IP) → iptables/kube-proxy → pod. Пять мест, где "всё выглядит правильно", а трафик не идёт.
📺 Networking 20/80, седьмой и последний пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Модель, адреса, DNS, TCP, HTTP и файрволы уже разобрали – сегодня собираем всё вместе: как запрос снаружи долетает до пода и делится между репликами.
В посте:
– L4 против L7: почему Service балансирует по IP:порту, а маршрутизация по URL и Host – это уже Ingress;
– четыре типа Service (ClusterIP / NodePort / LoadBalancer / ExternalName) – что где открывается наружу;
– Ingress и nginx как обратный прокси: терминация TLS, upstream, алгоритмы балансировки – и почему их нельзя смешивать в одном upstream;
– service mesh на пальцах: что даёт sidecar (Envoy) и почему джуну не надо настраивать Istio;
– чеклист диагностики: Service → Endpoints → DNS → Ingress, где именно рвётся.
И да – контроллер ingress-nginx ушёл на пенсию в марте 2026. Поэтому разбираем принципы L4/L7, а не один тул: они переносятся на любой контроллер.
Плюс три подвоха с собеса (в том числе "почему kube-proxy – вовсе не proxy") и финальный код-челлендж: описать весь путь запроса от https://… до пода по слоям.
Финал мини-курса. Полная версия 👇
https://devopsway.ru/posts/networking-06-lb-k8s/
#networking #kubernetes #devops
🔥4