Библиотека девопса | DevOps, SRE, Sysadmin
Все самое полезное для девопсера в одном канале. Наши курсы: https://clc.to/ZJ7Z1w По рекламе: @proglib_adv Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Show more📈 Analytical overview of Telegram channel Библиотека девопса | DevOps, SRE, Sysadmin
Channel Библиотека девопса | DevOps, SRE, Sysadmin (@devopsslib) in the Russian language segment is an active participant. Currently, the community unites 10 389 subscribers, ranking 11 434 in the Technologies & Applications category and 61 255 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 389 subscribers.
According to the latest data from 28 August, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -4 over the last 30 days and by -3 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 10.37%. Within the first 24 hours after publication, content typically collects 4.23% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 077 views. Within the first day, a publication typically gains 439 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 1.
- Thematic interests: Content is focused on key topics such as devops'a, навигация, скрипт, docker, git.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @proglib_adv
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787”
Thanks to the high frequency of updates (latest data received on 29 August, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
mount подключает файловую систему с устройства к каталогу — точке монтирования.
Файл /etc/fstab — сердце автоматизации
Каждая строка файла описывает одну файловую систему с параметрами:
• Устройство: путь, UUID или метка (например, /dev/sdb1, UUID=xxxxxxxx)
• Точка монтирования: каталог назначения (/mnt/data, /home)
• Тип файловой системы: ext4, xfs, ntfs, nfs, cifs
• Опции: defaults, rw, ro, noauto, nofail и др.
• Dump: для утилиты резервного копирования (обычно 0 или 1)
• Pass: порядок проверки через fsck (0 — отключена, 1 — корневая ФС, 2 — остальные)
Пример:
UUID=a1b2c3d4-e5f6-7890 /mnt/backup ext4 defaults,nofail 0 2
Команда mount -a (mount all) монтирует все файловые системы из /etc/fstab, которые:
• Имеют опцию auto
• Ещё не смонтированы
Записи с опцией noauto пропускаются — они монтируются только вручную.
Зачем это нужно
Init-система запускает mount -a, автоматически монтируя все необходимые файловые системы: корневую, /home, /var, сетевые шары.
После правки /etc/fstab не нужно перезагружаться или монтировать всё вручную — достаточно одной команды.
Добавление нового раздела:
# Создаём точку монтирования
sudo mkdir /data
# Добавляем в /etc/fstab
/dev/sdc1 /data ext4 defaults 0 2
# Применяем изменения
sudo mount -a
# Проверяем
df -h /data
mount -a — избавляет от рутины и обеспечивает применение конфигурации монтирования.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_promptping 8.8.8.8 работает, но ping google.com выдаёт "Name or service not known" — это проблема с DNS. Современные приложения используют доменные имена для всего, поэтому DNS критичен.
Файл /etc/resolv.conf:
cat /etc/resolv.conf
Содержит адреса DNS серверов:
nameserver 8.8.8.8 nameserver 8.8.4.4Если файл пустой или содержит неправильные адреса — резолвинг не работает. Проверьте доступность DNS сервера:
ping 8.8.8.8
nc -zv 8.8.8.8 53
Порт 53 — это DNS. Если порт закрыт или недоступен — сервер не может отвечать на DNS запросы.
dig — детальная DNS диагностика:
dig google.com
Показывает весь процесс разрешения имени:
• Какой DNS сервер ответил
• Сколько времени занял запрос
• Полученные A записи — IP адреса
Типичные ошибки в dig:
status: NXDOMAIN — домен не существует. Опечатка или домен удалён
status: SERVFAIL — DNS сервер столкнулся с ошибкой. Проблема на стороне DNS
status: REFUSED — сервер отказался обрабатывать запрос. ACL блокирует ваш IP
connection timed out — DNS сервер недоступен. Проверьте firewall
nslookup — альтернатива dig:
nslookup google.com
Проще, чем dig, но менее информативен. Полезен для быстрой проверки.
Проблемы с DNS в контейнерах
В Kubernetes и Docker DNS часто предоставляется внутренним сервисом.
Kubernetes:
• CoreDNS или kube-dns
• Проверьте: kubectl get pods -n kube-system | grep dns
• Логи: kubectl logs -n kube-system coredns-xxx
Docker:
• Встроенный DNS на 127.0.0.11
• Проблемы при неправильной конфигурации сети контейнера
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераless помогает листать большие текстовые файлы в терминале, не загружая их целиком в память.
Запуск: less filename
Клавиши для движения
• Стрелка вниз/Enter/j – на строку вперёд
• Стрелка вверх/k – на строку назад
• Пробел/Page Down – страница вперед
• Page Up/b – страница назад.
• g – в начало, G – в конец.
Поиск: /текст для поиска вперед, ?текст для поиска назад. n – следующий, N – предыдущий.
Полезные флаги:
• -N – номера строк
• -s – сжимает пустые строки
• -i – поиск без учета регистра
• +F – следит за изменениями, как tail -f
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженера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
#арсенал_инженера--memory хорошо, но нужно вспомнить про --memory-swap.
Вопрос:
Как работает memory-swap в Docker?Ключевой момент: swap — это не дополнительная память, а ответ в канале с вопросами 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #задача_со_звёздочкой
AgentOps: инструменты для трассировки и мониторинга цепочек вызовов;
— безопасность: как избежать инъекций и утечек данных;
— оптимизация: работа с токенами, кэширование и стоимость запросов;
— деплой мультиагентных систем (архитектура, интеграции).
Курс на Python, но понимание принципов работы LangGraph и векторных БД критически важно для современной инфраструктуры.
Записаться на курс
Смотреть первую лекцию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рсенал_инженераkubectl rollout restart deployment <deployment-name>
Никакой магии — просто обычный rolling update, но без изменения версии образа.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#root_promptping — простой и эффективный тест:
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
#арсенал_инженера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 -nARP связывает IP адреса с MAC адресами в локальной сети. Если для вашего gateway нет записи или она в состоянии FAILED — система не может определить MAC адрес шлюза. Очистка ARP кеша:
ip neighbour flush allДальше разберём проблемы маршрутизации. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера
