Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
Библиотека девопса | DevOps, SRE, Sysadmin
Kanalga Telegram’da o‘tish
Все самое полезное для девопсера в одном канале. По рекламе: @proglib_adv Учиться у нас: https://proglib.io/w/25874ec4 Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Ko'proq ko'rsatish📈 Telegram kanali Библиотека девопса | DevOps, SRE, Sysadmin analitikasi
Библиотека девопса | DevOps, SRE, Sysadmin (@devopsslib) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 422 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 11 856-o'rinni va Rossiya mintaqasida 62 948-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 422 obunachiga ega bo‘ldi.
12 Iyun, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -3 ga, so‘nggi 24 soatda esa -2 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 8.76% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 5.32% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 914 marta ko‘riladi; birinchi sutkada odatda 555 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 4 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent devops'a, навигация, скрипт, docker, git kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Все самое полезное для девопсера в одном канале.
По рекламе: @proglib_adv
Учиться у нас: https://proglib.io/w/25874ec4
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 13 Iyun, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
10 422
Obunachilar
-224 soatlar
+77 kunlar
-330 kunlar
Postlar arxiv
🍭 Топ-вакансий для девопсов за неделю
SRE/DevOPS инженер до 500 000 ₽
Senior DevOps-инженер от 4700 до 5700 $
DevOps-инженер до 400 000 ₽
AppSec инженер на удалёнку
Бустер — Офис у вас дома.
➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs
🕷 Забытые ресурсы едят деньги и место
Kubernetes не удаляет ресурсы автоматически. Создали тестовый Deployment, Service, LoadBalancer — забыли удалить. Через месяц в кластере 50 неиспользуемых объектов.
Что происходит
Service с типом LoadBalancer создаёт внешний балансировщик в облаке. Вы платите за него каждый день. PersistentVolumeClaim держит диск, даже если под давно удалён. ConfigMap и Secret захламляют namespace.
Как исправить
Добавьте лейблы всем ресурсам:
metadata:
labels:
owner: team-backend
purpose: experiment
expires: 2025-11-15
Теперь можно найти всё, что создала команда: kubectl get all -l owner=team-backend. Или всё, что просрочено.
Настройте сборку мусора. Kubernetes удалит зависимые объекты, если удалить владельца.
Используйте Kyverno для автоматического удаления ресурсов.
Делайте аудит раз в неделю: kubectl get all --all-namespaces. Ищите незнакомые имена, странные namespace. Удаляйте то, что не нужно.
🐸 Библиотека devops'a
#арсенал_инженера
Open Source в действии: Runtime Radar — первый в России инструмент для защиты контейнерных сред на базе eBPF и Tetragon.
📆 11 ноября, 14:00 (МСК), онлайн, бесплатно
Контейнеры ускорили DevOps, но открыли новые векторы атак.
Узнай, как Runtime Radar помогает выявлять угрозы в реальном времени, расследовать инциденты и защищать Kubernetes без сложной настройки.
Что вас ждёт:
✅ демонстрация Runtime Radar в действии;
✅ интеграция в SOC и мониторинг кластеров;
✅ инсайды от команды PT о развитии проекта.
Open Source — код и документация доступны на GitHub.
Присоединяйтесь и сделайте свою контейнерную инфраструктуру прозрачной и защищенной.
👉🏻 Регистрация на вебинар
⚙️ Окружение работает локально, но падает в CI
Знакомая ситуация: код запускается на ноутбуке, а в CI он сразу же ломается. Причина почти всегда в окружении — где-то не хватает переменной, токен истёк, или указан неправильный регион.
Перед тем как запустить джоб, убедитесь, что все критичные переменные на месте и имеют смысл:
# Проверяем, что все нужные переменные заданы
required=(DB_URL OAUTH_CLIENT_ID OAUTH_SECRET REGION)
for v in "${required[@]}"; do
[ -n "${!v}" ] || { echo "::error::$v missing"; exit 78; }
done
⚡️ Devuan 6 Excalibur
Devuan выпустил шестую версию своего дистрибутива. Это операционная система для тех, кто предпочитает OpenRC или runit вместо systemd. Новая версия основана на Debian 13 Trixie и получит поддержку до конца жизненного цикла Debian — в течение нескольких лет.
Главное изменение — теперь обязателен merged-/usr, то есть директория /usr сливается с корневой директорией. Если обновляетесь со старых версий, нужно сначала установить пакет usrmerge в Daedalus, а потом уже переходить на Excalibur.
➡️ Анонс обновления
🐸 Библиотека devops'a
#пульс_индустрии
😊 Dev и prod — разные миры, но у вас одинаковые манифесты
Команды копируют манифесты из dev в prod, чтобы было проще. Но в деве 2 реплики и 128Mi памяти хватает. В продц нужно 20 реплик и 2Gi памяти.
Что происходит
В dev запустили 10 реплик для теста — кластер упал. В prod оставили 2 реплики — сервис не держит нагрузку. Или забыли поменять ConfigMap с URL базы — prod подключился к dev-базе.
Как исправить
Используйте kustomize. Создайте base с общими настройками, а окружения описывайте в overlays:
base/
deployment.yaml
service.yaml
overlays/
dev/
kustomization.yaml
prod/
kustomization.yaml
В overlay переопределяете replicas, resources, ConfigMap, Secrets. В dev можете вообще не использовать Secrets — подойдёт mock-конфиг. В prod — настоящий Secret из Sealed Secrets или внешнего Vault.
🐸 Библиотека devops'a
#арсенал_инженера
🔭 Долгоживущие флаги
Разработчик создаёт флаг для плавного выката новой фичи. Две недели максимум — думает он. Три месяца спустя флаг всё ещё живёт в кодовой базе. Теперь там две логики работы: старая и новая. Если что-то сломается, непонятно, что именно. Никто не удаляет флаг, потому что вдруг кто-то им пользуется.
Как это решить
Добавляем в каждый флаг срок жизни — дату, после которой он должен исчезнуть. Не данные флага, а сам код его обработки. И конвейер CI останавливает сборку, если срок прошёл.
new_feature_flag: owner: web-platform created: 2025-09-08 expires: 2025-11-01После даты expires случается одно из двух: • CI выдаёт предупреждение на третий день просрочки • CI ломает сборку, если просрочка больше недели Разработчик не может игнорировать проблему, потому что его коммиты просто не пройдут. Проводите flag burn-down — 15-минутный митинг, где смотрите, какие флаги уже 100% включены в прод. 🐸 Библиотека devops'a #арсенал_инженера
Вышла версия Grafana Mimir 3.0 — база данных временных рядов для метрик.
Главное изменение — разделение путей чтения и записи. Раньше один компонент отвечал за обе операции, поэтому тяжёлые запросы замедляли поступление новых данных. Теперь между ними встал Kafka как буфер, и каждый путь масштабируется независимо.
Вторая важная фишка — новый Query Engine для Mimir. Вместо загрузки всех данных в память, он обрабатывает выборку потоком и берёт только необходимые точки на каждом шаге.
➡️ Блог разработчиков
🐸 Библиотека devops'a
#пульс_индустрии
👨💻 kubectl logs — это не логирование
kubectl logs показывает логи только из работающих или недавно упавших контейнеров. Логи лежат на диске ноды. Контейнер удалился, нода перезагрузилась, логи ротировались — всё пропало.
Что происходит
Под упал ночью. Утром вы приходите разбираться — логов нет. Или под был в namespace с агрессивной политикой очистки. Или кто-то удалил Deployment.
В production это значит, что вы не узнаете, почему сервис лёг в 3 часа ночи.
Как исправить
Поднимите централизованное логирование. Fluentd или Fluent Bit собирают логи со всех подов и отправляют в хранилище — Elasticsearch, Loki, S3.
Пример sidecar с Fluent Bit:
containers:
- name: app
image: your-app:1.0
- name: fluent-bit
image: fluent/fluent-bit:latest
volumeMounts:
- name: varlog
mountPath: /var/log
Если нужна корреляция логов с метриками — добавьте OpenTelemetry. Если нужны трейсы — Jaeger. Но начните с простого: соберите логи в одном месте.
🐸 Библиотека devops'a
#арсенал_инженера🤩 Апгрейднули cp
Когда Вы копируете большую папку командой cp -r, Вы не видите, что происходит. Процесс может занять часы, а Вы сидите в неведении — копируется ли вообще? Сколько осталось? Если что-то пойдёт не так, часто нужно начинать заново.
rsync — это утилита для копирования и синхронизации файлов. Главное преимущество: показывает прогресс, сохраняет все атрибуты файлов и умеет возобновлять прерванные копирования.
Базовая команда:
rsync -av --progress /path/to/src/ /path/to/dest/-a — архивный режим. Cохраняет права, временные метки, символические ссылки.
-v — подробный вывод
--progress — показывает прогресс для каждого файла
Если Вы копируете по сети на удалённый сервер, добавьте флаг -z для сжатия:
rsync -avz --progress /local/path/ user@server:/remote/path/
🍷 Wine: 32 бита на 64-битной системе
Вышла версия Wine 10.18. Основной фокус — доработка WoW64 режима, который позволяет запускать 32-битные Windows-приложения на 64-битной Linux-системе, имитируя нативный Windows WoW64 подсистему.
OpenGL теперь использует Vulkan для отображения в памяти в WoW64 режиме, добавлена поддержка SCSI pass-through, реализована API синхронизационных барьеров (нужна для некоторых игр, например The Obsessive Shadow), поддержка WinRT исключений. Плюс 30 багфиксов для приложений и игр.
➡️ Анонс
🐸 Библиотека devops'a
#пульс_индустрии
👨💻 Без probes Kubernetes не знает, что ваше приложение умерло
Kubernetes считает контейнер живым, пока процесс не завершился. Приложение может зависнуть, тупить, инициализироваться 5 минут — Kubernetes всё равно отправит трафик.
Что происходит
Liveness probe проверяет, жив ли контейнер. Если нет — перезапускает. Readiness probe проверяет, готов ли контейнер принимать трафик. Если нет — убирает из Service.
Без readiness probe пользователи попадут на ещё не прогретое приложение. Получат таймауты, 500-е, странные ошибки. Вы будете часами искать баг, которого нет.
Как исправить:
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
Добавьте в приложение два эндпоинта. /healthz отвечает 200, если приложение работает. /ready отвечает 200, если приложение загрузилось и готово обрабатывать запросы.
🐸 Библиотека devops'a
#арсенал_инженера
🔒 Consul 1.22 и MCP-сервер для управления через AI
HashiCorp анонсировал релиз Consul 1.22 и новый MCP-сервер, который меняет способ взаимодействия с платформой service mesh.
Теперь можно управлять сервисами, health checks и конфигурацией через обычный разговор с AI-ассистентом.
Сам Consul 1.22 получил поддержку IPv6 (требование для федеральных агентств США), улучшенную SSO-аутентификацию через private key JWT вместо client_secret, и расширенную телеметрию для IPv6-трафика.
➡️ Блог разработчиков
🐸 Библиотека devops'a
#пульс_индустрии
❓ Что из контента на этой неделе вам особенно понравилось
📰 Шесть непростых дней
Вспоминаем что было за прошедшую рабочую неделю.
— Критический баг в Ubuntu 25.10
— NGINX Unit больше не разрабатывается
— Bottles 51.25
— Fedora Linux 43
— 14 вопросов, после которых вам не перезвонят
#дайджест_недели
😮 Шестидневка позади
Выдохнули — самая насыщенная неделя завершена. Теперь время для перезагрузки: встречи с друзьями, хобби, любимые сериалы — всё, что поможет восстановить силы.
💬 Как вы справились с этой неделей? Что первым делом сделаете в выходные? Рассказывайте в комментариях 👇
🐸 Библиотека devops'a
#холиварня
📎 Боремся с infra-flake
Когда вы запускаете автоматические тесты или задачи, иногда возникают ошибки, связанные с инфраструктурой — с сетью, временными сбоями серверов или сбоями среды выполнения. Они проявляются как короткие перебои или ошибки 5xx.
В таких случаях есть эффективный подход: сделать автоматическую повторную попытку один раз.
Почему это работает? Обычно проблема — не в вашем коде, а в инфраструктуре. Если перезапуск помогает и задача проходит успешно, значит ошибка — временная и связана с сетью или сервером, а не с самим программным продуктом.
Пример:
jobs:
tests:
runs-on: ubuntu-latest
strategy:
fail-fast: false
max-parallel: 4
steps:
- uses: actions/checkout@v4
- name: Run tests with one retry on infra errors
run: |
set -e
for i in 1 2; do
npm test && break || {
if grep -qE "ENETUNREACH|ECONNRESET|502 Bad Gateway" test.log; then
echo "Retrying due to infra indicators..."
sleep 10
else
exit 1
fi
}
done
Такой подход помогает разграничить плохие ошибки, вызванные внешней инфраструктурой, от серьезных багов в коде.
🐸 Библиотека devops'a
#root@prompt
☕️ Gitea 1.25.0
Gitea — это бесплатная платформа для хостинга и управления Git-репозиториями.
Что нового:
• Добавлен предварительный просмотр 3D-файлов и CAD-файлов.
• Поддерживаются email-уведомления о результатах CI/CD.
• Улучшена SSH-подпись коммитов и интеграция с OpenID Connect.
• Админ-панель оптимизирована: архивы исключены из бэкапов, улучшена настройка эмодзи.
• Удалены устаревшие источники аутентификации.
➡️ Release notes
🐸 Библиотека devops'a
#пульс_индустрии
📎 Забыли про requests и limits — получили OOMKilled
Kubernetes не требует указывать requests и limits для CPU и памяти. Поды запускаются и без них. Но когда кластер растёт, начинаются проблемы.
Scheduler не знает, сколько ресурсов нужно поду. Он пихает на одну ноду 20 подов, которые съедают всю память. Результат — OOM killer убивает случайные поды. Или наоборот: один под жрёт все ресурсы, остальные задыхаются.
Как исправить:
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "200m"
Начните с минимальных значений. Запустите под, посмотрите kubectl top pods. Увидите реальное потребление — скорректируете цифры. Если нагрузка скачет, добавьте HorizontalPodAutoscaler.
🐸 Библиотека devops'a
#арсенал_инженера