Библиотека девопса | DevOps, SRE, Sysadmin

📎 Просмотр файлов в терминале Команда less помогает листать большие текстовые файлы в терминале, не загружая их целиком в память. Запуск: less filename Клавиши для движения • Стрелка вниз/Enter/j – на строку вперёд • Стрелка вверх/k – на строку назад • Пробел/Page Down – страница вперед • Page Up/b – страница назад. • g – в начало, G – в конец. Поиск: /текст для поиска вперед, ?текст для поиска назад. n – следующий, N – предыдущий. Полезные флаги: • -N – номера строк • -s – сжимает пустые строки • -i – поиск без учета регистра • +F – следит за изменениями, как tail -f 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🔄 Последний Linux 6 версии Линус Торвальдс выпустил стабильный релиз Linux 6.18. Это последняя версия 6.x, следующий релиз будет 7.0. Ничего страшного не случилось, просто пофиксили баги. Что починили и улучшили • Улучшили драйверы ice и enetc • Поправили микрофоны на Acer и HP ноутбуках. • btrfs и ceph не крашатся из-за утечек памяти. • nouveau и AMD display работают лучше ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🆕 Прошла первая неделя февраля Самые заметные материалы и новости этой недели. — Bottles 61 — Хакеры атаковали Notepad++ — Linux From Scratch отказывается от SysVinit — Диагностика сетевых проблем — Terragrunt 1.0 RC1 — 9 способов найти заказы без бирж 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #дайджест_недели

Кто будет деплоить и мониторить этих агентов? Вы Разработчики напишут логику агента, но заставить это работать в продакшене 24/7 — задача инженера. Как мониторить расход токенов, отлавливать галлюцинации в логах и скейлить векторные кластеры? На курсе мы разбираем не только код, но и инфраструктуру 2026 года. На вебинарах решаем реальные вопросы: как обеспечить безопасность (Guardrails), настроить observability для цепочек рассуждений и упаковать всё это в Kubernetes. DevOps-составляющая курса: — AgentOps: инструменты мониторинга и трассировки (Tracing). — Deploy: контейнеризация агентов и микросервисная архитектура. — Storage: работа с векторными БД под нагрузкой. — FinOps: контроль и оптимизация затрат на инференс. Освоить MLOps/AgentOps практики

👨‍💻 Дебаг файрволла и фильтрация пакетов ➡️ Предыдущая часть Маршрутизация настроена правильно, ping gateway работает, но связь всё равно не работает. Вероятно, виноват файрволл. Он может молча блокировать пакеты, не оставляя очевидных следов. Linux может использовать несколько систем: iptables, nftables, firewalld. iptables — классическая система:

iptables -L -n -v

Флаги: -L — list, показывает правила -n — numeric, не резолвит имена -v — verbose, показывает счётчики пакетов Вывод показывает три основные цепочки: - INPUT — входящие пакеты - OUTPUT — исходящие пакеты - FORWARD — транзитные (для маршрутизатора) Политика по умолчанию:

Chain INPUT (policy DROP)

Policy DROP — всё блокируется по умолчанию, разрешено только то, что явно указано в правилах выше. Безопасно, но легко сломать связность. Policy ACCEPT — всё разрешено по умолчанию, блокируется только указанное. Менее безопасно, но проще в отладке.

iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1523 128K DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Смотрите на колонку pkts (packets). Если правило с DROP/REJECT показывает большое количество — оно активно блокирует трафик. В примере выше: 1523 пакета на порт 22 (SSH) были отброшены. Временное отключение файерволла:

iptables -F  # Очистить все правила
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Если после этого всё заработало — проблема точно в правилах. Восстановите их и ищите конкретное блокирующее правило. firewalld — современная альтернатива:

firewall-cmd --list-all

Показывает активную зону и все правила в ней. Firewalld работает с концепцией зон: public, internal, trusted, dmz и т.д. Проверьте: - Какая зона активна для вашего интерфейса - Какие сервисы разрешены в этой зоне - Какие порты открыты Какие зоны активны и на каких интерфейсах:

firewall-cmd --get-active-zones

Добавление правил firewalld Разрешить сервис (HTTP):

firewall-cmd --add-service=http --permanent
firewall-cmd --reload

Разрешить порт:

firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload

Флаг --permanent делает правило постоянным. Без него — только до перезагрузки firewalld. Если правил много, найти виновника сложно. Добавьте логирование для отброшенных пакетов: iptables:

iptables -I INPUT -j LOG --log-prefix "DROPPED: "

Теперь все отброшенные пакеты будут логироваться в /var/log/messages с префиксом "DROPPED:". firewalld:

firewall-cmd --set-log-denied=all

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🛠 Новый уровень контроля готовности узлов в k8s В стандартном Kubernetes готовность узла определяется единственным бинарным условием. Это работает для простых случаев, но создает проблемы в прод-окружениях, где узлам требуется множество зависимостей перед запуском подов: • Сетевые агенты и CNI-плагины • Драйверы систем хранения (CSI) • GPU-драйверы и специализированная прошивка • Кастомные health-проверки и мониторинг агенты Текущий механизм не позволяет гарантировать, что все эти компоненты работают корректно до того, как планировщик начнет размещать поды на узле. Node Readiness Controller вводит декларативный механизм управления node taints на основе кастомных условий готовности. Контроллер работает с API NodeReadinessRule, который позволяет определить специфические требования для разных типов узлов. Коротко о возможностях: • Автоматическое управление node taints на основе кастомных условий • Два режима: постоянный контроль или только при инициализации • Интеграция с Node Problem Detector и кастомными health-check агентами • Разные правила готовности для разных типов узлов: GPU, storage, standard • Декларативная настройка через Kubernetes API Контроллер предоставляет декларативный способ управления сложными многоэтапными процессами инициализации узлов с полной наблюдаемостью через стандартные Kubernetes API. ➡️ Блог разработчиков 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

❓ Вопрос с собеса На собесах спрашивают про лимиты памяти в контейнерах, и знать про --memory хорошо, но нужно вспомнить про --memory-swap. Вопрос:

Как работает memory-swap в Docker?

Ключевой момент: swap — это не дополнительная память, а ответ в канале с вопросами 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #задача_со_звёздочкой

LLM в проде: как мониторить и деплоить агентов? Разработчики научились писать агентов, но вопрос эксплуатации остаётся открытым. Курс «Разработка ИИ-агентов» стартовал, и в нём мы уделяем внимание не только коду, но и Ops-составляющей. Что полезного для инженера: — AgentOps: инструменты для трассировки и мониторинга цепочек вызовов; — безопасность: как избежать инъекций и утечек данных; — оптимизация: работа с токенами, кэширование и стоимость запросов; — деплой мультиагентных систем (архитектура, интеграции). Курс на Python, но понимание принципов работы LangGraph и векторных БД критически важно для современной инфраструктуры. Записаться на курс Смотреть первую лекцию

⚙️ top для systemd systemd-cgtop — это инструмент из systemd для просмотра топа control groups по использованию CPU, памяти и I/O. Он обновляется каждую секунду и похож на классический top, но фокусируется на группах процессов. Что показывает top:

PID  USER     CPU%  MEM%  COMMAND
1234 www-data 45.0  12.3  /usr/bin/php-fpm
5678 www-data 32.1  8.7   /usr/bin/php-fpm

Что показывает cgtop:

Control Group          Tasks  %CPU  Memory
/system.slice/nginx     12    78.2  2.1G
/system.slice/postgresql 8    23.4  1.8G
/system.slice/redis      4    12.1  512M

Разница критична: nginx может порождать сотни worker'ов, и в top вы увидите хаос из процессов. В systemd-cgtop — одна строка с суммарным потреблением. Примеры команд:

# Что тормозит сервер?
systemd-cgtop --order=cpu

# Кто съел всю память?
systemd-cgtop --order=memory

# Кто нагружает диск?
systemd-cgtop --order=io

# Следить только за веб-сервисами
systemd-cgtop | grep -E '(nginx|apache|php)'

Полезные клавиши В интерактивном режиме: • p / t / c / m / i — сортировка по path/tasks/cpu/memory/io • % — показать CPU в процентах или абсолютных значениях • + / - — развернуть/свернуть дерево cgroups • q — выход Если вы используете systemd и хотите понять, какой сервис потребляет ресурсы, а не тонуть в списке процессов — systemd-cgtop ваш инструмент. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #aрсенал_инженера

🤨 Прошу, прочти конфиг Классическая ситуация: вы правите конфиг, применяете изменения, проверяете логи — а там всё по-старому. Приложение просто не знает, что конфигурация изменилась. Когда под стартует, он монтирует ConfigMap как volume. Kubernetes обновляет содержимое этого volume автоматически, но: • Большинство приложений читают конфиг один раз при запуске • Они не следят за изменениями файлов • Перечитывание конфига в рантайме — это дополнительная логика, которую надо реализовывать Команда, чтобы конфиг точно перечитался:

kubectl rollout restart deployment <deployment-name>

Никакой магии — просто обычный rolling update, но без изменения версии образа. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

🚀 9 способов найти заказы без бирж Малый бизнес до сих пор не знает, где искать разработчиков. Кто-то спрашивает у знакомых, кто-то ищет на Авито, кто-то пишет в Telegram-чатах. Будьте на их пути — и первые заказы найдутся сами. ➡️ Самые топовые способы в статье 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a

💡 Диагностика сети: IP связность и маршрутизация Проверка базовой связности Интерфейсы UP, ошибок нет — переходим к проверке IP связности. Команда ping — простой и эффективный тест:

ping 8.8.8.8

Google DNS 8.8.8.8 — хороший выбор для теста: стабильный, быстрый, разрешает ping. Если работает — базовая связь с интернетом есть. Если нет — копаем глубже. Таблица маршрутизации

ip route show

Таблица маршрутизации определяет, куда система отправляет пакеты для разных сетей. Критичная запись — default gateway или маршрут по умолчанию:

default via 10.0.0.1 dev eth0

Это означает: все пакеты для неизвестных сетей отправляются через шлюз 10.0.0.1 на интерфейсе eth0. Если этой записи нет — связь с внешним миром невозможна. Система не знает, куда отправлять пакеты. Проверка default gateway Убедитесь, что gateway находится в той же подсети, что и IP адрес интерфейса:

ip addr show eth0

Если IP 10.0.0.50/24, а gateway 10.0.1.1 — это конфликт. Маска /24 означает подсеть 10.0.0.0-10.0.0.255, gateway за её пределами. Тестирование шлюза:

ping 10.0.0.1

Пингуем сам gateway. Это локальная сеть, должно работать. Если не работает: 1. Проблема с физической связностью (вернитесь к посту #2) 2. Проблема с ARP (проверьте ip neighbour show) 3. Шлюз недоступен или выключен Проблемы с ARP:

ip neighbour show

Ищите запись для gateway IP. Должна быть строка типа:

10.0.0.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Состояния ARP: - REACHABLE — всё хорошо - STALE — запись старая, но рабочая - FAILED — не удалось определить MAC адрес - INCOMPLETE — процесс определения не завершён Если FAILED — gateway не отвечает на ARP запросы. Возможно, он выключен или есть проблемы на L2. Специфичные маршруты Кроме default gateway могут быть статические маршруты для конкретных сетей:

ip route show
10.20.0.0/16 via 10.0.0.5 dev eth0

Это говорит: для сети 10.20.0.0/16 используй другой шлюз — 10.0.0.5. Ошибка в таком маршруте может сломать связность с конкретным сегментом инфраструктуры. Добавление маршрутов вручную Временно (до перезагрузки):

ip route add default via 10.0.0.1 dev eth0
ip route add 10.20.0.0/16 via 10.0.0.5

Удаление маршрута:

ip route del 10.20.0.0/16

Для постоянных маршрутов редактируйте конфигурацию сети в /etc/sysconfig/network-scripts/route-eth0 (RHEL) или netplan конфиг (Ubuntu). Traceroute — путь до цели:

traceroute 8.8.8.8

Показывает каждый хоп до цели. Полезно, когда ping не работает — увидите, где именно пакеты теряются. Если traceroute зависает на определённом хопе — проблема там. Если все хопы показывают * * * — ICMP блокируется firewall. mtr — улучшенный traceroute:

mtr 8.8.8.8

Комбинация ping и traceroute. Показывает latency и packet loss на каждом хопе в реальном времени. Более информативно, чем обычный traceroute. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🤩 Чей сетап? 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🍪 Топ-вакансий для девопсов за неделю DevOps-инженер — от 180 000 с гибридом в Москве или на удалёнку. MLOps\DevOps — удалёнка. DevOps-инженер — от 250 000 ₽ на удалёнку. ➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs 🐸Библиотека devops'a #вакансия_недели

👨‍💻 Дебаг на физическом и канальном уровне ➡️ Первая часть Первое, что нужно проверить — сами сетевые интерфейсы. Даже в виртуализированной среде они могут оказаться в состоянии DOWN из-за проблем с драйверами, ошибок конфигурации или сбоев гипервизора. ip link show — проверка состояния интерфейсов:

ip link show

Ищите строку с state UP — интерфейс активен и готов передавать данные. Если видите state DOWN, проблема на этом уровне. Что означает DOWN: • Физические серверы: отсоединённый кабель, неисправный порт коммутатора, проблемы с сетевой картой. • Виртуальные машины: проблема с виртуальным свитчем, неправильная привязка к VLAN, ошибки в конфигурации гипервизора. Счётчики ошибок

ip -s link show eth0

Флаг -s показывает статистику. Смотрите на поля: •errors — ошибки при передаче/приёме dropped — отброшенные пакеты/нехватка буферов overruns — переполнение буфера приёма collisions — коллизии на старых half-duplex Если эти значения растут — проблемы с передачей пакетов. ethtool — детальная диагностика

ethtool eth0

Показывает: • Link detected: yes/no — есть ли физический линк • Speed — текущая скорость (1000Mb/s, 10000Mb/s) • Duplex — full или half • Auto-negotiation — включено ли автосогласование Если Link detected: no, но интерфейс UP — физический линк отсутствует. Проверяйте кабель, порт коммутатора. ARP таблица:

ip neighbour show
# или старый вариант:
arp -n

ARP связывает IP адреса с MAC адресами в локальной сети. Если для вашего gateway нет записи или она в состоянии FAILED — система не может определить MAC адрес шлюза. Очистка ARP кеша:

ip neighbour flush all

Дальше разберём проблемы маршрутизации. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

📌 Ядерная кнопка для зависших подов Иногда под зависает в состоянии «завершается» из-за проблем с монтированием тома и не уходит часами. В этот момент обычное удаление через kubectl delete pod уже не помогает. В таких случаях можно использовать более жестокий вариант:

kubectl delete pod <имя-под> --grace-period=0 --force

--grace-period=0 говорит Kubernetes не ждать стандартный terminationGracePeriodSeconds и не давать контейнеру время на мягкое завершение. --force просит сервер API немедленно убрать объект под из etcd. Объект под удаляется из API сразу, но сам контейнер на узле может ещё какое-то время жить, пока kubelet не добьёт его. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

🤩 Terragrunt 1.0 RC1 Разработчики Terragrunt уже на финишной прямой. Terragrunt — это обёртка над Terraform, которая устраняет дублирование конфигов, управляет remote state и зависимостями модулей. Что в первом релиз-кандидате Terragrunt перестроили под масштабируемость. Новый CLI упрощает команды, фильтр заменяет семь флагов вроде -terragrunt-include-dir. Stacks группируют связанные модули Terraform в единый деплой. Runner Pool ускоряет параллельные запуски, улучшает обработку ошибок. В 1.x не сломается ничего критичного. Стабильны флаги CLI, HCL-конфиги, вывод find и reports. RC1 — шанс повлиять на Terragrunt 1.0. Тестируйте stacks и runner pool в реальных воркфлоу. ➡️ Анонс 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🧑‍💻 Диагностика сетевых проблем Когда серверы становятся недоступными, это немедленно влияет на все сервисы, пользователей и бизнес. Сетевая связность — это не одна система, а стек взаимодействующих слоёв: от физических интерфейсов до маршрутизации, firewall, DNS и прикладных протоколов. Проблема может находиться на любом из этих уровней, и симптомы часто не указывают прямо на причину. Добавьте облачную инфраструктуру с виртуальными сетями, security groups, load balancers — и картина становится ещё сложнее. Одна неправильная запись в таблице маршрутизации или забытое правило firewall могут полностью изолировать критичный сервис. Профессиональный DevOps подходит к диагностике системно, методично проверяя каждый уровень снизу вверх. Модель OSI в практике DevOps Теоретическая модель OSI с семью уровнями в реальной практике упрощается до ключевых проверок: Уровень 1-2: Физика и канал • Состояние интерфейсов (UP/DOWN) • Физическое соединение • Ошибки передачи пакетов Уровень 3: Сетевой • IP адресация • Маршрутизация • ICMP связность Уровень 4: Транспортный • Firewall правила • Фильтрация пакетов • NAT и security groups Уровень 5-7: Прикладной • DNS резолвинг • Доступность портов • Логика приложения Систематический подход Золотое правило: двигайтесь снизу вверх. Не имеет смысла проверять DNS, если сетевой интерфейс в состоянии DOWN. Не тестируйте приложение, если базовая IP связность не работает. Каждый уровень зависит от нижележащих. Проверили физику → проверили IP → проверили firewall → проверили DNS → проверили приложение. Только так можно быстро локализовать проблему. Инструменты диагностики Базовый набор: • ip — управление интерфейсами, адресами, маршрутами • ping — базовая проверка связности • nc — тестирование TCP/UDP портов • dig — DNS диагностика • tcpdump — захват трафика Системные: • systemctl — управление сервисами • journalctl — просмотр логов • iptables / firewall-cmd — firewall В следующих постах разберём каждый уровень с практическими примерами и командами. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

💻 Linux From Scratch отказывается от SysVinit Проект Linux From Scratch (LFS) и Beyond Linux From Scratch (BLFS) прекращают поддержку System V Init в будущих версиях Phoronix. Начиная с LFS 13.0, который ожидается 1 марта 2026, останется только systemd. Причины отказа 1. Двойная нагрузка на мейнтейнеров. Каждый пакет нужно проверять для обеих init-систем при подготовке релиза. 2. Жёсткие зависимости. GNOME и скоро KDE Plasma встраивают требования, которые нуждаются в возможностях systemd, отсутствующих в System V. «Как личное замечание — мне не нравится это решение» — написал автор анонса. Решение продиктовано не идеологией, а практическими ограничениями. Прагматизм победил принципы. Малочисленная команда LFS не может поддерживать две init-системы в условиях растущей экосистемы Linux. ➡️ Анонс 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии