Библиотека девопса | DevOps, SRE, Sysadmin – Telegram
Библиотека девопса | DevOps, SRE, Sysadmin
10.4K subscribers
1.8K photos
76 videos
4 files
3.16K links
Все самое полезное для девопсера в одном канале.

По рекламе: @proglib_adv

Учиться у нас: https://proglib.io/w/25874ec4

Для обратной связи: @proglibrary_feeedback_bot

РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Download Telegram
🤔 Кажется, мониторинг окончательно перестал быть «графиками на всякий случай» и стал частью управления рисками и выручкой.

Yandex B2B Tech запустила Monium — observability-платформу для мониторинга и управления состоянием ИТ-систем в реальном времени. Важно, что продукт вырос из внутренней платформы Яндекса, разработанной командой Yandex Infrastructure: его использовали для мониторинга критичных сервисов, а теперь он доступен внешним компаниям.

Что внутри:

1. единый интерфейс для метрик, логов и трейсов — чтобы быстро собрать полную картину по системе
2. поиск инцидентов и первопричин (особенно полезно в микросервисной архитектуре)
3. гибкий алертинг и сценарии эскалации, включая уведомления и звонки ответственным
4. мониторинг приложений, инфраструктуры и ИИ-агентов — в облаке и в on-prem среде


Внутри Яндекса с платформой ежемесячно работают около 16 тысяч сотрудников. В систему каждую секунду записывается до 3 млрд семплов метрик, 44 млн спанов и 60 ГБ логов.

Платформу уже тестируют ОТП Банк и крупная FMCG-компания — хороший сигнал для enterprise-сегмента.

Observability всё чаще связывают с экономическим эффектом, потому что простои и деградации напрямую бьют по доходам, а скорость диагностики становится фактором конкурентоспособности.

Где больнее всего мониторинг: микросервисы, legacy-монолит, on-prem, гибрид или облако? 👇
🔥3🌚1
Топ-вакансий для девопсов за неделю

DevOps-инженер — от 345 000 ₽, офис в Москве

DevOps Engineer — от 250 000 до 300 000 ₽, гибрид в Москве

Middle DevOps Engineer — Удалёнка

➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs

🐸Библиотека devops'a

#вакансия_недели
Please open Telegram to view this post
VIEW IN TELEGRAM
🔄 Nitrux 6.0.0

Nitrux позиционирует себя как дистрибутив для тех, кто хочет полный контроль над железом и не готов мириться с лишними слоями абстракции. Шестая версия продолжает эту логику.

Ядро и низкоуровневые компоненты

Система работает на ядре Linux 6.19.2 с патчами от CachyOS. Одно из заметных изменений на уровне ядра — NVMe-накопитель теперь не уходит в глубокий режим сна.

Добавлена отдельная запись в GRUB под названием «Intel Xe Mode». Она позволяет принудительно использовать драйвер xe вместо i915 на поддерживаемых GPU Intel.

VxM — виртуализация с проброской GPU

VxM — утилита оркестрации гипервизора, написанная на C++. Она работает через VFIO PCI passthrough и IOMMU-изоляцию, что позволяет передавать дискретную видеокарту напрямую виртуальной машине.

На практике это означает близкую к нативной производительность для гостевой ОС без эмуляционных накладных расходов.

NUTS переписан на C++

Nitrux Update Tool System теперь реализована на C++. Прежняя версия на Shell Script заменена клиент-серверной архитектурой с интерфейсом на MauiKit и интеграцией PolicyKit для контроля привилегированных операций.

Это релиз, в котором команда последовательно избавляется от legacy-кода и переводит ключевые компоненты на C++ с нативной Wayland-интеграцией.

➡️ Release Notes

📍 Навигация: ВакансииЗадачиСобесы

🐸 Библиотека devops'a

#пульс_индустрии
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
🛠 Ingress-NGINX уходит

В ноябре 2025 года Kubernetes официально объявил об отставке Ingress-NGINX. Март 2026 года — финальная дата. Если вы до сих пор не думали о миграции, самое время начать. И дело не только в том, чтобы переписать манифесты.

Ingress-NGINX — один из самых распространённых ingress-контроллеров в экосистеме Kubernetes. За годы использования в нём накопилось немало неочевидных особенностей поведения. Именно они создают реальную угрозу при переходе на Gateway API.

Важно понять одну вещь: Ingress-NGINX и NGINX Ingress — это два разных проекта. Ingress-NGINX поддерживает сообщество Kubernetes, и он уходит. NGINX Ingress от F5 продолжает существовать. Оба используют NGINX как dataplane, но в остальном они не связаны между собой.

Основной риск миграции — не синтаксис, а семантика. Казалось бы корректный перевод Ingress-манифестов в HTTPRoute может изменить фактическое поведение маршрутизации.

Готовим для вас цикл постов по подводным камням при миграции.

📍 Навигация: ВакансииЗадачиСобесы

🐸 Библиотека devops'a

#арсенал_инженера
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
This media is not supported in your browser
VIEW IN TELEGRAM
👍 На курсе по контролируемой разработке AI-агентов мы будем разбирать ровно то, о чём говорит Владислав в голосовом, но уже в формате системной практики.

📅 Старт курса — 20 апреля.

Если хотите разобраться, как строить управляемые агентные системы:
➡️ Присоединяйтесь.

P.S. С первого занятия будет практика: код и разбор реальных ошибок, а не только теория.
Please open Telegram to view this post
VIEW IN TELEGRAM
🧑‍💻 Безопасный способ вывести ноду из строя

Надо обновить ноду, поменять железо или просто перезагрузить сервер. Проблема в том, что на ноде уже крутятся поды с реальной работой. Просто выключить её нельзя. Вот тут на помощь приходит kubectl drain.

Команда:
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data


Kubernetes корректно выведет все поды с ноды, перенесёт их на другие ноды в кластере и отметит саму ноду как недоступную для новых подов. Workloads при этом не упадут, они просто переедут.

--ignore-daemonsets говорит системе не трогать DaemonSets, потому что они крутятся на каждой ноде и переносить их бесполезно. --delete-emptydir-data удаляет поды с пустыми томами, которые нельзя перенести нормально.

Drain работает только с управляемыми подами. Если у вас валяются standalone поды без контроллера, они просто удалятся. Поэтому перед drain проверьте, что важные поды находятся в Deployments, StatefulSets или других контроллерах.

После drain нода остаётся в состоянии unschedulable. Когда закончите работу, верните её обратно:
kubectl uncordon <node-name>


📍 Навигация: ВакансииЗадачиСобесы

🐸 Библиотека devops'a

#root_prompt
Please open Telegram to view this post
VIEW IN TELEGRAM
👍42
👨‍💻 Регулярные выражения в Ingress-NGINX работают не так, как вы думаете

Разбираем особенности Ingress-NGINX перед его отставкой. Одна из самых частых причин тихих сбоев при миграции — это поведение регулярных выражений в путях маршрутизации.

Предположим, нужно направлять на бэкенд только запросы, путь которых состоит ровно из трёх заглавных букв. Пишете паттерн /[A-Z]{3}, включаете аннотацию nginx.ingress.kubernetes.io/use-regex: "true" и считаете задачу решённой.

На деле Ingress-NGINX обрабатывает такой паттерн как _префикс без учёта регистра_. Запрос /uuid пройдёт — потому что три буквы в начале пути есть. /some-long-path тоже пройдёт. Именно это поведение было в продакшене, даже если вы об этом не знали.

При переходе на Gateway API с типом матчинга RegularExpression всё меняется. Реализации на базе Envoy — Istio, Envoy Gateway, Kgateway — делают полное совпадение с учётом регистра. Паттерн /[A-Z]{3} уже не пропустит /uuid. Запросы, которые раньше работали, начнут возвращать 404.

Чтобы сохранить прежнее поведение, паттерн нужно переписать явно: /[a-zA-Z]{3}.*. Либо использовать флаг (?i), если конкретная реализация его поддерживает.

Перед миграцией пройдитесь по каждому регулярному выражению и проверьте, какие запросы оно реально пропускало. Не то, что написано в паттерне, а то, что фактически проходило в продакшене.

📍 Навигация: ВакансииЗадачиСобесы

🐸 Библиотека devops'a

#арсенал_инженера
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔 Не гоняйте, пацаны

Terraform-собеседование — и вот вам вопрос:
Команда хранит state в S3 и периодически ловит его порчу при одновременных apply. Как исключить race condition?


Подсказка: одного только версионирования S3 недостаточно. Нужен механизм, который не дает двум apply работать одновременно.

➡️ Проверить себя

📍 Навигация: ВакансииЗадачиСобесы

🐸 Библиотека devops'a

#задача_со_звёздочкой
Please open Telegram to view this post
VIEW IN TELEGRAM
1
🧑‍💻 Linux From Scratch 13: больше компонентов, systemd по умолчанию

LFS это руководство по сборке Linux с нуля. Вы компилируете каждый компонент сами, из исходников. Это едва ли полезно для production систем, но отлично работает как обучение.

В Linux From Scratch 13.0 обновилось 36 компонентов. Вот самые заметные: ядро Linux 6.18.10, systemd 259.1, Python 3.14.3, OpenSSL 3.6.1, SQLite 3.50.4. Все обновлено и актуально.

Главное изменение: LFS 13.0 полностью переходит на systemd. Старые версии 12.4 шли с SysVinit, и это было огромным минусом для обучения, потому что современный Linux это практически всегда systemd.

➡️ Источник

📍 Навигация: ВакансииЗадачиСобесы

🐸 Библиотека devops'a

#пульс_индустрии
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔1