⚡️ DevOps Digest #17 | 01.06.2026
🔥 Главное за неделю:
1. Kubernetes: исправляют записи о незакрытых CVE — сканеры могут заалертить – 1 июня Kubernetes SRC обновит CVE-записи для трёх старых уязвимостей (CVE-2020-8561, CVE-2020-8562, CVE-2021-25740), которые ранее ошибочно указывали наличие фикса. Эти баги — архитектурные компромиссы, полного исправления нет. После обновления записей сканеры могут начать показывать новые алерты на ваших кластерах — не паникуйте, но проверьте, применимы ли mitigation из описания CVE.
🔗 https://kubernetes.io/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/
2. GitLab 19.0: SBOM-сканирование зависимостей стало GA – Новый анализатор строит полный граф зависимостей (включая транзитивные), сверяет с базой уязвимостей и показывает проблемы прямо в merge request. Если используете GitLab — включите и замените старый Gemnasium-сканер: он видит глубже и находит больше.
🔗 https://about.gitlab.com/blog/sbom-based-dependency-scanning/
3. Чеклист на 54 пункта для деплоя в прод – Инженер из промышленной автоматизации собрал проверки по 4 фазам: pre-deploy, execution, post-deploy, 24h stability. Ничего революционного, но как готовый шаблон для команды без формализованного процесса — отличная отправная точка. Особенно полезно джунам, которые деплоят впервые.
🔗 https://dev.to/fabrciowplima/the-54-point-production-deployment-checklist-that-saves-you-from-3am-rollbacks-22i4
4. Java vs C# в Kubernetes: практический гайд по оптимизации Docker-образов – Подробное сравнение двух стеков в контейнерной среде: размеры образов, время старта, настройка JVM/AOT, GC, лимиты памяти, пробы. Полезно тем, кто контейнеризирует Java/C#-приложения и хочет понять, где теряются ресурсы.
🔗 https://dev.to/syedahmershah/java-vs-c-optimizing-docker-for-kubernetes-1kkc
5. LeafWiki — self-hosted вики в одном Go-бинарнике – SQLite, Markdown-файлы на диске, Ctrl+V для вставки скриншотов, SSO через HTTP-заголовки (Authentik, Authelia), роли. Ноль внешних зависимостей. Если ищете лёгкую вики для внутренней документации в закрытом контуре — стоит попробовать.
🔗 https://github.com/perber/leafwiki
🛠 Команда недели:
Покажет последние 20 событий о failed проверках (liveness/readiness) по всем namespace. Удобно для быстрой диагностики, когда поды рестартятся без видимой причины.
#дайджест #kubernetes #security
🔥 Главное за неделю:
1. Kubernetes: исправляют записи о незакрытых CVE — сканеры могут заалертить – 1 июня Kubernetes SRC обновит CVE-записи для трёх старых уязвимостей (CVE-2020-8561, CVE-2020-8562, CVE-2021-25740), которые ранее ошибочно указывали наличие фикса. Эти баги — архитектурные компромиссы, полного исправления нет. После обновления записей сканеры могут начать показывать новые алерты на ваших кластерах — не паникуйте, но проверьте, применимы ли mitigation из описания CVE.
🔗 https://kubernetes.io/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/
2. GitLab 19.0: SBOM-сканирование зависимостей стало GA – Новый анализатор строит полный граф зависимостей (включая транзитивные), сверяет с базой уязвимостей и показывает проблемы прямо в merge request. Если используете GitLab — включите и замените старый Gemnasium-сканер: он видит глубже и находит больше.
🔗 https://about.gitlab.com/blog/sbom-based-dependency-scanning/
3. Чеклист на 54 пункта для деплоя в прод – Инженер из промышленной автоматизации собрал проверки по 4 фазам: pre-deploy, execution, post-deploy, 24h stability. Ничего революционного, но как готовый шаблон для команды без формализованного процесса — отличная отправная точка. Особенно полезно джунам, которые деплоят впервые.
🔗 https://dev.to/fabrciowplima/the-54-point-production-deployment-checklist-that-saves-you-from-3am-rollbacks-22i4
4. Java vs C# в Kubernetes: практический гайд по оптимизации Docker-образов – Подробное сравнение двух стеков в контейнерной среде: размеры образов, время старта, настройка JVM/AOT, GC, лимиты памяти, пробы. Полезно тем, кто контейнеризирует Java/C#-приложения и хочет понять, где теряются ресурсы.
🔗 https://dev.to/syedahmershah/java-vs-c-optimizing-docker-for-kubernetes-1kkc
5. LeafWiki — self-hosted вики в одном Go-бинарнике – SQLite, Markdown-файлы на диске, Ctrl+V для вставки скриншотов, SSO через HTTP-заголовки (Authentik, Authelia), роли. Ноль внешних зависимостей. Если ищете лёгкую вики для внутренней документации в закрытом контуре — стоит попробовать.
🔗 https://github.com/perber/leafwiki
🛠 Команда недели:
kubectl get events --field-selector reason=Unhealthy --sort-by='.lastTimestamp' -A | tail -20
Покажет последние 20 событий о failed проверках (liveness/readiness) по всем namespace. Удобно для быстрой диагностики, когда поды рестартятся без видимой причины.
#дайджест #kubernetes #security
Kubernetes
Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs
The Kubernetes project relies on transparency to empower cluster administrators and security researchers. One important way we do that is by publishing CVE records into the Common Vulnerabilities and Exposures database. As part of our ongoing effort to mature…
🔥3❤2
RAG Pipeline 5/N: Почему ваш гибридный поиск – это просто первичный отсев, а не точная сортировка
Гибридный поиск (пост 4/N) находит нужный кусок кода или доки в условный top-15, но порядок внутри этого топа напоминает лотерею. Алгоритм RRF пытается скрестить ужа с ежом: "Так, BM25 поставил этот чанк первым, векторный поиск – третьим, складываем обратные ранги".
Проблема в том, что ни один из этих алгоритмов не читал документ вместе с вашим запросом. Они просто сравнивают сухие индексы и вектора. А для LLM критически важен именно top-1. Что туда попало – из того она и соберет ответ. Если на первом месте оказался мусор, замаскированный под релевантный результат, на выходе получите классический garbage in, garbage out. Чтобы решить это, в стек пришлось тащить Cross-encoder.
Как это работает на пальцах
Cross-encoder не занимается сравнением готовых векторов. Он берет запрос, приклеивает к нему текст найденного чанка и читает их вместе, как человек. Модель буквально вчитывается в контекст пары "вопрос-ответ".
Минус очевиден – это дорого по ресурсам. Гонять такую модель по всему корпусу в 360K чанков – безумие. Поэтому мы используем каскадную схему, знакомую любому инженеру по классической архитектуре систем:
– Bi-encoder + BM25 – это наш L1/L2 кэш или Bloom-фильтр перед диском. Его задача – быстро отсечь 99% явного мусора и выплюнуть пачку кандидатов.
– Cross-encoder – это финальный тяжелый запрос к диску. Он ювелирно разбирает оставшийся 1% (наши 15 кандидатов) и расставляет их по реальной релевантности.
Что показали тесты на NORA
Загнал в систему пачку из 30 реальных тестовых запросов по репозиторию. Результат: у двух третей запросов после реранкинга top-1 полностью изменился. Гибридный поиск честно находил нужный кусок, но закапывал его на 5-7 место.
Живой пример:
Запрос: "XSS vulnerability in NORA UI".
– До реранкинга: На первом месте болтался какой-то случайный JSON, который dense search случайно ранжировал выше нужного чанка.
– После реранкинга: Система вытащила конкретный чанк с фиксом пайплайна под issue #521. Rerank score 0.99 – модель уверена.
Цена вопроса и суровая реальность
За точность приходится платить таймингами, и чудес тут нет.
– Время поиска без реранкера: 91ms
– Время поиска с реранкером: 3.3 секунды (на CPU)
Для CLI-утилиты или MCP-тула, который ты запустил в фоне и ждешь развернутый аудит, это приемлемо. Сидишь, пьешь кофе, автоматизация работает. Но если вы попытаетесь прикрутить такую схему на автокомплит в IDE – вы просто убьете UX, разработчики вас проклянут. Для фаст-трека нужен либо мощный GPU-инференс, либо более легкие дистиллированные модели.
В следующем посте разберем классические грабли: почему пайплайн, который выдавал 98% accuracy на моих локальных данных, мгновенно развалился, стоило закинуть в него чужой репозиторий.
Полная версия с кодом интеграции и замерами производительности каскада:
👉devopsway.ru/posts/rag-05-reranking/
#кейс #ai
Гибридный поиск (пост 4/N) находит нужный кусок кода или доки в условный top-15, но порядок внутри этого топа напоминает лотерею. Алгоритм RRF пытается скрестить ужа с ежом: "Так, BM25 поставил этот чанк первым, векторный поиск – третьим, складываем обратные ранги".
Проблема в том, что ни один из этих алгоритмов не читал документ вместе с вашим запросом. Они просто сравнивают сухие индексы и вектора. А для LLM критически важен именно top-1. Что туда попало – из того она и соберет ответ. Если на первом месте оказался мусор, замаскированный под релевантный результат, на выходе получите классический garbage in, garbage out. Чтобы решить это, в стек пришлось тащить Cross-encoder.
Как это работает на пальцах
Cross-encoder не занимается сравнением готовых векторов. Он берет запрос, приклеивает к нему текст найденного чанка и читает их вместе, как человек. Модель буквально вчитывается в контекст пары "вопрос-ответ".
Минус очевиден – это дорого по ресурсам. Гонять такую модель по всему корпусу в 360K чанков – безумие. Поэтому мы используем каскадную схему, знакомую любому инженеру по классической архитектуре систем:
– Bi-encoder + BM25 – это наш L1/L2 кэш или Bloom-фильтр перед диском. Его задача – быстро отсечь 99% явного мусора и выплюнуть пачку кандидатов.
– Cross-encoder – это финальный тяжелый запрос к диску. Он ювелирно разбирает оставшийся 1% (наши 15 кандидатов) и расставляет их по реальной релевантности.
Что показали тесты на NORA
Загнал в систему пачку из 30 реальных тестовых запросов по репозиторию. Результат: у двух третей запросов после реранкинга top-1 полностью изменился. Гибридный поиск честно находил нужный кусок, но закапывал его на 5-7 место.
Живой пример:
Запрос: "XSS vulnerability in NORA UI".
– До реранкинга: На первом месте болтался какой-то случайный JSON, который dense search случайно ранжировал выше нужного чанка.
– После реранкинга: Система вытащила конкретный чанк с фиксом пайплайна под issue #521. Rerank score 0.99 – модель уверена.
Цена вопроса и суровая реальность
За точность приходится платить таймингами, и чудес тут нет.
– Время поиска без реранкера: 91ms
– Время поиска с реранкером: 3.3 секунды (на CPU)
Для CLI-утилиты или MCP-тула, который ты запустил в фоне и ждешь развернутый аудит, это приемлемо. Сидишь, пьешь кофе, автоматизация работает. Но если вы попытаетесь прикрутить такую схему на автокомплит в IDE – вы просто убьете UX, разработчики вас проклянут. Для фаст-трека нужен либо мощный GPU-инференс, либо более легкие дистиллированные модели.
В следующем посте разберем классические грабли: почему пайплайн, который выдавал 98% accuracy на моих локальных данных, мгновенно развалился, стоило закинуть в него чужой репозиторий.
Полная версия с кодом интеграции и замерами производительности каскада:
👉devopsway.ru/posts/rag-05-reranking/
#кейс #ai
🔥3❤2
⚡️ DevOps Digest #18 | 08.06.2026
🔥 Главное за неделю:
1. Риск-ориентированное ревью IaC-пулл-реквестов – Не каждый PR в Terraform/Ansible заслуживает одинакового внимания. Подход с оценкой риска (blast radius, окружение, тип ресурса, откатываемость) помогает направить внимание ревьюеров туда, где оно действительно нужно. Полезная модель для любой команды, которая тонет в PR на инфраструктуру.
🔗 https://devops.com/risk-based-review-for-infrastructure-as-code-pull-requests/
2. Аудит песочницы AI-чатбота как чёрного ящика Linux – Инженер за 6 часов исследовал рантайм Kimi 2.6 стандартными Linux-инструментами: нашёл захардкоженный SSH-пароль в
🔗 https://dev.to/alex72py/i-audited-an-ai-chatbots-sandbox-like-a-black-box-linux-machine-bhe
3. acme.sh снова в трендах GitHub – Чистый shell-скрипт для автоматизации TLS-сертификатов через ACME-протокол. Работает без зависимостей, поддерживает десятки DNS-провайдеров и wildcard-сертификаты. Если вы ещё управляете сертификатами вручную или привязаны к certbot – стоит посмотреть.
🔗 https://github.com/acmesh-official/acme.sh
4. Метастабильные отказы: почему устранение триггера не помогает – SRE Weekly выделяет статью о метастабильных сбоях: система восстанавливается после триггера, но остаётся в нестабильном состоянии и падает снова. Классика для on-premise инфраструктуры с ограниченным запасом ресурсов. Рекомендую прочитать и оригинальную статью.
🔗 https://sreweekly.com/sre-weekly-issue-520/
5. AI ускоряет DevOps, но интеграции тормозят – AI-инструменты сделали отдельные шаги умнее (сканирование, код-ревью, триаж инцидентов), но передача данных между Jira, ServiceNow, мониторингом и CI/CD осталась ручной. Bottleneck сместился от написания кода к стыкам между инструментами. Актуально для команд, которые внедряют AI-помощников и удивляются, что пайплайн не ускорился.
🔗 https://devops.com/ai-is-accelerating-devops-poor-integrations-are-slowing-it-down/
🛠 Команда недели:
Проверяет переменные окружения текущего процесса на утечки секретов. Полезно при аудите контейнеров и CI-раннеров – если видите тут пароли в открытом виде, пора переходить на Vault или sealed secrets.
#дайджест #devops #security
🔥 Главное за неделю:
1. Риск-ориентированное ревью IaC-пулл-реквестов – Не каждый PR в Terraform/Ansible заслуживает одинакового внимания. Подход с оценкой риска (blast radius, окружение, тип ресурса, откатываемость) помогает направить внимание ревьюеров туда, где оно действительно нужно. Полезная модель для любой команды, которая тонет в PR на инфраструктуру.
🔗 https://devops.com/risk-based-review-for-infrastructure-as-code-pull-requests/
2. Аудит песочницы AI-чатбота как чёрного ящика Linux – Инженер за 6 часов исследовал рантайм Kimi 2.6 стандартными Linux-инструментами: нашёл захардкоженный SSH-пароль в
/proc/self/environ, измерил лимиты cgroup, определил инфраструктуру (K8s Pod, Burstable QoS). Отличный пример того, как базовые навыки Linux и контейнерной безопасности работают на практике.🔗 https://dev.to/alex72py/i-audited-an-ai-chatbots-sandbox-like-a-black-box-linux-machine-bhe
3. acme.sh снова в трендах GitHub – Чистый shell-скрипт для автоматизации TLS-сертификатов через ACME-протокол. Работает без зависимостей, поддерживает десятки DNS-провайдеров и wildcard-сертификаты. Если вы ещё управляете сертификатами вручную или привязаны к certbot – стоит посмотреть.
🔗 https://github.com/acmesh-official/acme.sh
4. Метастабильные отказы: почему устранение триггера не помогает – SRE Weekly выделяет статью о метастабильных сбоях: система восстанавливается после триггера, но остаётся в нестабильном состоянии и падает снова. Классика для on-premise инфраструктуры с ограниченным запасом ресурсов. Рекомендую прочитать и оригинальную статью.
🔗 https://sreweekly.com/sre-weekly-issue-520/
5. AI ускоряет DevOps, но интеграции тормозят – AI-инструменты сделали отдельные шаги умнее (сканирование, код-ревью, триаж инцидентов), но передача данных между Jira, ServiceNow, мониторингом и CI/CD осталась ручной. Bottleneck сместился от написания кода к стыкам между инструментами. Актуально для команд, которые внедряют AI-помощников и удивляются, что пайплайн не ускорился.
🔗 https://devops.com/ai-is-accelerating-devops-poor-integrations-are-slowing-it-down/
🛠 Команда недели:
cat /proc/self/environ | tr '\0' '\n' | grep -iE 'pass|key|token|secret'
Проверяет переменные окружения текущего процесса на утечки секретов. Полезно при аудите контейнеров и CI-раннеров – если видите тут пароли в открытом виде, пора переходить на Vault или sealed secrets.
#дайджест #devops #security
DevOps.com
Risk-Based Review for Infrastructure as Code Pull Requests
Learn how risk-based IaC reviews reduce reviewer fatigue and improve deployment safety through transparent risk scoring.
🔥4❤2
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