Библиотека девопса | DevOps, SRE, Sysadmin
Все самое полезное для девопсера в одном канале. Наши курсы: https://clc.to/ZJ7Z1w По рекламе: @tproger_sales_bot Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787 Заявка: 8137718351
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 340 subscribers, ranking 11 827 in the Technologies & Applications category and 61 477 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 340 subscribers.
According to the latest data from 28 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -44 over the last 30 days and by 1 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 10.47%. Within the first 24 hours after publication, content typically collects 5.07% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 082 views. Within the first day, a publication typically gains 524 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
По рекламе: @tproger_sales_bot
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Заявка: 8137718351”
Thanks to the high frequency of updates (latest data received on 29 October, 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.
tcpdump — инструмент для захвата и анализа сетевого трафика.
➡️ Предыдущий пост
Базовое использование tcpdump
tcpdump -i eth0
Начинает захват всех пакетов на интерфейсе eth0 и выводит на экран. Внимание: генерирует огромное количество данных. Используйте фильтры.
Фильтр по хосту:
tcpdump -i eth0 host 192.168.1.10
Только пакеты от/к этому IP.
Фильтр по порту:
tcpdump -i eth0 port 80
Только HTTP трафик.
Комбинация фильтров:
tcpdump -i eth0 host 192.168.1.10 and port 443
HTTPS трафик к конкретному хосту.
Направление:
tcpdump -i eth0 dst 192.168.1.10 # Только к этому IP
tcpdump -i eth0 src 192.168.1.10 # Только от этого IP
Полезные флаги
• -n — не резолвить IP в имена (быстрее)
• -v — verbose (больше деталей)
• -vv — очень verbose
• -X — показать содержимое пакетов в hex и ASCII
• -A — показать содержимое в ASCII (для HTTP/текста)
Сохранение в файл для анализа
tcpdump -i eth0 -w capture.pcap
Сохраняет пакеты в файл capture.pcap. Можно открыть в Wireshark для детального анализа.
Чтение из файла:
tcpdump -r capture.pcap
Ограничение размера захвата
tcpdump -i eth0 -w capture.pcap -C 100 -W 5
• -C 100 — создавать новый файл каждые 100 МБ
• -W 5 — хранить максимум 5 файлов (ротация)
➡️ Типичные паттерны в дампах
— TCP SYN без SYN-ACK
14:32:15.123456 IP client > server: Flags [S], seq 123456 14:32:16.123456 IP client > server: Flags [S], seq 123456 # РетрансмитКлиент отправляет SYN (запрос на соединение), но сервер не отвечает SYN-ACK. Возможные причины: • Сервис не слушает на порту • Firewall блокирует на сервере • Пакеты не доходят до сервера — TCP RST пакеты
14:32:15.123456 IP client > server: Flags [S], seq 123456 14:32:15.123457 IP server > client: Flags [R.], seq 0Сервер отвечает reset — порт закрыт, соединение отклонено. Сервис точно не слушает. — Множественные ретрансмиты
14:32:15.123456 IP client > server: Flags [.], seq 1000:2000 14:32:15.623456 IP client > server: Flags [.], seq 1000:2000 # Ретрансмит 14:32:16.623456 IP client > server: Flags [.], seq 1000:2000 # Ещё ретрансмитПакет отправляется повторно, потому что ACK не приходит. Указывает на: • Потери пакетов в сети • Проблемы производительности на принимающей стороне • Перегруженный канал ➡️ Wireshark — графический анализ Сохраните дамп и откройте в Wireshark на вашей рабочей станции:
# На сервере
tcpdump -i eth0 -w /tmp/capture.pcap
# Скачайте файл
scp server:/tmp/capture.pcap .
# Откройте в Wireshark
Wireshark умеет:
• Разбирать сотни протоколов
• Показывать TCP stream (весь диалог)
• Находить ретрансмиты автоматически
• Строить графики I/O
• Экспортировать объекты (файлы из HTTP)
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераgrepc — поиск C-кода без индексации
• grepc_c, grepc_mk — вспомогательные утилиты
• mansectf — работа с секциями man-страниц
➡️ Анонс
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#пульс_индустрииstore browse-apps --category Productivity --listing-type top-freeМожно искать по категории, подкатегории, рынку и языку, топ бесплатных, платных, новинки. Установка:
store install vlc store install 9NBLGGH4NNS1 # По ProductIdПохожие приложения:
store similar vlcСписок установленных:
store installedОбновления:
store updates
store upgrade vlc
store upgrade --all
# Обновление конкретного приложения
store update 9WZDNCRFJ3Q2
Ограничение: работает только на машинах с включенным Microsoft Store. На Server Core придётся его сначала активировать.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераrm -rf воспринимает его как флаги и готов снести всё вокруг.
Что делать в такой ситуации? Как удалить этот файл?
Один из ответов спрятали в нашем канале с вопросами с собесов
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#задача_со_звёздочкойgrep -i "network\|eth0\|link" /var/log/messages | tail -50
Что искать:
• link down / link up — интерфейс терял линк
• firmware — проблемы с firmware сетевой карты
• dropped — kernel отбрасывал пакеты
• OOM — Out of Memory, могло убить сетевые процессы
➡️ journalctl — современный способ
journalctl -n 100 # Последние 100 записей
journalctl -f # Следить в реальном времени (как tail -f)
journalctl -p err # Только ошибки
Фильтр по юниту (сервису):
journalctl -u NetworkManager -n 100
journalctl -u systemd-networkd -n 100
Фильтр по времени:
journalctl --since "10 minutes ago"
journalctl --since "2025-02-03 14:00" --until "2025-02-03 15:00"
➡️ NetworkManager и systemd-networkd
Современные Linux-дистрибутивы используют один из этих сервисов для управления сетью.
Проверка статуса:
systemctl status NetworkManager
systemctl status systemd-networkd
Ищите:
- Active: active (running) — всё ОК
- Active: failed — сервис упал
- Ошибки в выводе
Логи в реальном времени:
journalctl -u NetworkManager -f
Запустите эту команду, затем воспроизведите проблему — увидите, что происходит.
➡️ Перезапуск сетевых сервисов
На удалённом сервере это может разорвать SSH соединение!Используйте
screen или tmux перед перезапуском:
screen
systemctl restart NetworkManager
Если потеряли соединение, screen сохранит сессию. Переподключитесь и вернётесь в неё командой screen -r.
Альтернатива: at команда для отложенного восстановления сети:
echo "systemctl restart NetworkManager" | at now + 2 minutes
Если что-то пойдёт не так, через 2 минуты сеть автоматически перезапустится.
➡️ Мониторинг ресурсов
Иногда сетевые проблемы вызваны нехваткой ресурсов.
Проверка памяти:
free -h
Если своп активно используется — система испытывает нехватку RAM. Сетевые процессы могут тормозить или падать.
Проверка CPU:
top
htop
Высокая загрузка CPU может замедлять обработку пакетов.
Проверка дискового I/O:
iostat -x 1
Если диск перегружен, логирование замедляется, конфигурационные файлы читаются медленно.
Типичные находки в логах
NetworkManager: device disconnected
- Интерфейс потерял линк
- Проверьте физику (кабель, порт)
dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval X
- Не может получить IP от DHCP сервера
- DHCP сервер недоступен или перегружен
kernel: Out of memory: Killed process X (name)
- OOM killer убил процесс
- Возможно, убил NetworkManager или systemd-networkd
iptables: DROP IN=eth0 SRC=X.X.X.X
- Firewall блокирует пакеты
- Найдено блокирующее правило
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженераnc -zv example.com 80
Флаги:
• -z — только проверка, без отправки данных
• -v — подробный вывод
Результаты:
Connection to example.com 80 port [tcp/http] succeeded! — порт открыт, сервис слушает
Connection refused — порт закрыт, сервис не запущен
Connection timed out — пакеты не доходят, firewall или сеть
Проверьте, слушает ли приложение:
ss -tulpn | grep :80
или старая версия:
netstat -tulpn | grep :80
Должны увидеть строку типа:
tcp LISTEN 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234))
0.0.0.0:80 означает слушает на всех интерфейсах. 127.0.0.1:80 — только локально и не доступен снаружи.
Если ничего нет — сервис не запущен или слушает на другом порту.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженера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
#арсенал_инженера