@usr_bin_linux

Перестаньте заучивать команды! Вместо этого освойте эти 10 рабочих сценариев Linux

2026-07-28T13:07:26.717Z

Это перевод оригинальной статьи Stop Memorizing Commands! Learn These 10 Linux Workflows Instead.

Подписывайтесь на телеграм-канал usr_bin, где я публикую много полезного по Linux, в том числе ссылки на статьи в этом блоге.

Новички сосредоточены на командах. Опытные инженеры мыслят рабочими сценариями

Команды меняются, но рабочий процесс остается прежним

Команды — это всего лишь инструменты. Они могут различаться в зависимости от окружения, дистрибутива, версии системы или предпочтений команды. На одном сервере может быть доступен только top, на другом используют htop. Одни команды работают с grep, другие предпочитают rg (ripgrep). Именно поэтому недостаточно просто запоминать команды.

Например, если нам нужно проанализировать запущенные процессы, конкретная команда вторична. Гораздо важнее понимать, какую информацию необходимо получить и как её интерпретировать. Когда цель ясна, выбрать подходящий инструмент уже несложно. Рабочий процесс остаётся неизменным, даже если команды меняются.

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

#1. Высокое потребление памяти

Высокое потребление памяти — одна из самых распространённых причин срабатывания оповещений в Linux. Обычно первым делом запускают команду free -h, которая подтверждает наличие проблемы, но не объясняет её причину.

Когда использование памяти высокое, главная задача — не допустить, чтобы OOM Killer (Out-Of-Memory Killer) завершил критически важные сервисы, такие как базы данных или основные процессы приложения. Для этого нужен последовательный алгоритм действий, который поможет правильно определить причину и устранить проблему до того, как она станет критической.

Шаг 1. Проверьте, не сработал ли уже OOM Killer

OOM Killer (Out Of Memory Killer) означает, что в системе закончилась память, и Linux принудительно завершил один или несколько процессов, чтобы сохранить работоспособность системы. Если это уже произошло, текущее состояние отражает последствия аварии, а не нормальную работу системы.

dmesg -T | grep -E "(Out of memory|oom_kill|Killed process)" | tail -20

#or
journalctl -k | grep -i "killed process"

# Example output:
[Mon Feb 23 03:14:22 2026] Out of memory: Killed process 18432 (java)
 total-vm:8388608kB, anon-rss:6291456kB, file-rss:0kB, shmem-rss:0kB

Если ошибка нехватки памяти уже произошла:

Определите, какой процесс был завершён;
Оцените текущее состояние системы, найдите первопричину и устраните проблему с памятью (шаги 2–7);
Восстановите работу сервиса (systemctl restart <service-name>)

Шаг 2. Подтвердите наличие нехватки памяти

Распространённая ошибка — считать, что высокое использование памяти автоматически означает её нехватку. На самом деле Linux активно использует свободную оперативную память для файлового кэша и буферов диска, чтобы повысить производительность.

free -h

               total        used        free      shared  buff/cache   available
Mem:            15Gi       6.2Gi       1.1Gi       512Mi       7.7Gi       8.3Gi
Swap:           2.0Gi         0B       2.0Gi

Обращайте внимание на available, а не на free:
Поле available показывает, сколько оперативной памяти действительно доступно для новых задач с учётом кэша и буферов, которые при необходимости могут быть освобождены.

Высокое значение (норма): доступно примерно 30–50% общего объёма RAM — запас памяти достаточный.
Среднее: доступно 10–30% — нормальное состояние, но стоит наблюдать, если показатель продолжает снижаться.
Низкое: менее 10% — память начинает испытывать нагрузку.
Критическое: менее 5% (или стабильно менее 1–2 ГБ на системах с большим объёмом памяти) — существует риск использования swap, снижения производительности или срабатывания OOM Killer.

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

Использование swap:
Ещё один важный показатель — swap. Он показывает, какой объём данных был выгружен из оперативной памяти на диск из-за её нехватки. Однако оповещения должны срабатывать раньше, чем начинает активно использоваться swap, поскольку его использование обычно означает, что свободной RAM уже недостаточно.

0% swap — идеальное состояние, нехватки памяти нет.
Низкое использование: 1–20% от общего объёма swap — незначительная нагрузка, обычно это нормально (если показатель остаётся стабильным).
Высокое использование: более 20–30% — система испытывает серьёзную нехватку памяти, возможны замедление работы и повышенная нагрузка.

Шаг 3. Определите основных потребителей памяти

Если объём available невелик, проверьте, какие процессы используют больше всего памяти.

# live monitoring
top        # press Shift + M to sort by memory

# snapshot
ps -eo pid,comm,%mem,rss --sort=-rss | head

# Output: ps -eo pid,comm,%mem,rss --sort=-rss | head

  PID COMMAND         %MEM    RSS
 2341 firefox         12.3  1024300
 1987 chrome          10.1   842500
 1102 java             8.7   725300
  901 gnome-shell      3.2   265400
  745 systemd           1.5   120000
  512 dockerd           1.2    98000
  333 sshd              0.5    42000
  210 cron              0.1    12000
  105 systemd-journal   0.1    11000

Определите подозрительные процессы и закономерности:
Просмотрите процессы, потребляющие больше всего памяти, и обратите внимание на необычные скачки, стабильно высокое потребление памяти или сервисы, поведение которых не соответствует ожидаемому. Зафиксируйте всё, что выглядит подозрительно, чтобы подробнее изучить это на следующем шаге.

Шаг 4: Изучите полученные результаты.

Для каждого процесса с высоким потреблением памяти или подозрительным поведением выясните, сколько памяти он использует: оперативной памяти (RAM), swap и виртуальной памяти.

cat /proc/<PID>/status | grep -E 'VmRSS|VmSwap|VmPeak|VmSize'

VmRSS   :  120000 kB   (RAM used)
VmSwap  :   50000 kB   (swap used)
VmSize  :  300000 kB   (total virtual memory)
VmPeak  :  320000 kB   (peak memory usage)

В первую очередь обращайте внимание на VmRSS и VmSwap:
VmRSS показывает, сколько реальной оперативной памяти использует процесс, а VmSwap показывает, какой объём памяти процесса был выгружен на диск (в swap) из-за нехватки оперативной памяти.

VmRSS высокий уровень: > 30% RAM → процесс потребляет много RAM
VmSwap > 0 → часть памяти процесса уже находится в swap (нехватка памяти).
Высокий VmRSS + растущий VmSwap → явный признак проблем с памятью

Шаг 5: Подтверждение поведения

VmSwap > 0 (процесс уже использует swap)
Иногда это может быть нормальным, но также может указывать на нехватку памяти, если объём swap продолжает расти или сопровождается высоким значением VmRSS.

# Monitor system memory + CPU + swap activity view updated every 1 second.
vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us  sy  id  wain   cs  us  sy  id  wa
 1  0  10240  200000  50000 800000    0    5     2     3   120  200  5   2  90   3

si (swap in) → память возвращается с диска в оперативную память.
so (swap out) → данные выгружаются из оперативной памяти в swap на диске.

Если значение so постоянно больше 0, это означает, что система испытывает постоянную нехватку памяти и активно выгружает данные в swap.

Если si часто больше 0, значит система регулярно возвращает данные из swap обратно в RAM, что указывает на трудности с восстановлением свободной памяти.

VmRSS High
Процесс использует большой объем оперативной памяти. Это может быть как нормальным явлением (для ресурсоёмких сервисов), так и свидетельствовать о проблеме (например, об утечке памяти).

# Monitor VmRSS every 5 seconds to check if memory usage is stable or growing
watch -n 5 "cat /proc/<PID>/status | grep VmRSS"

# Output:
VmRSS:   245678 kB

Стабильное значение → нормальное поведение
Постоянный рост → вероятный признак утечки памяти или аномального потребления, вызванного тем, что процесс непрерывно выделяет память, не освобождая её, либо увеличением нагрузки или трафика, с которыми система уже не справляется эффективно.

Шаг 6: Примите меры

После того как проблема с памятью подтверждена (высокий VmRSS, использование swap или непрерывный рост потребления памяти), выберите соответствующий способ её устранения, в зависимости от серьёзности проблемы:

1. Перезапустите сервис (предпочтительный первый шаг)
Перезапуск сервиса — самый быстрый и безопасный способ снизить нагрузку на память и восстановить нормальную работу без глубокого анализа причины. Он устраняет временные утечки памяти и освобождает память, запуская процесс заново.

systemctl restart <service-name>

2. Завершите процесс (если он завис или работает некорректно)
Завершение процесса немедленно освобождает занимаемую им память и другие ресурсы, однако при некорректном завершении возможна потеря данных.

# graceful shutdown (recommended first)
kill <PID>   # allows the process to exit cleanly

# force shutdown (use only if it does not respond)
kill -9 <PID>   # immediately terminates the process

3. Снизьте нагрузку на систему
Снизьте нагрузку, временно освободив память и уменьшив объём выполняемой работы, чтобы система перестала активно использовать swap и вернулась в стабильное состояние.

# Clear cache (temporary relief)
sync; echo 3 > /proc/sys/vm/drop_caches

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

Шаг 7: Предотвратите повторение подобного инцидента

После устранения непосредственной проблемы важно сделать так, чтобы она не повторилась.

1. Найдите первопричину
Цель — определить, почему резко выросло значение VmRSS, почему начала использоваться swap и какие изменения в системе или приложении привели к этому.

# If we know which service is the root cause
# Analyze logs for a specific service
# Goal: find what exactly is wrong with that service
journalctl -u <service-name>

Обратите внимание на:

Критические ошибки: записи в логах с ERROR, FAILED или FATAL.
Частые перезапуски: быстро повторяющиеся циклы Restarting, Started или Stopped.
Системное вмешательство: сообщения OOM killed (нехватка памяти) или ошибки сегментации (segfault).
Узкие места: предупреждения о превышении времени ожидания или сбои в работе зависимостей.

# If we don’t know which service is the root cause
# Review all system logs leading up to the incident
# Goal: Correlate system-wide events to establish a timeline of the failure.
journalctl --since "2 hours ago" -p 3..0

Обратите внимание на:

События-триггеры: какой конкретный процесс или развертывание изменились непосредственно перед скачком потребления памяти?
Каскадные сбои: одновременные ошибки в нескольких независимых сервисах.
Вмешательства ядра: сообщения Out of memory: Kill process.
Ограничения ресурсов: предупреждения о проблемах с дисковой подсистемой, высокой нагрузке на CPU или нехватке памяти.

2. Внедрите долгосрочные меры по устранению проблемы

После выявления первопричины примените одно или несколько из следующих постоянных решений:

На уровне приложения → устраните утечки памяти в коде или оптимизируйте ограничения конфигурации (например, настройте размер кучи Java через параметр -Xmx или лимиты рабочих процессов Apache/Nginx).
На уровне инфраструктуры → задайте жёсткие ограничения ресурсов с помощью systemd cgroups или лимитов памяти Docker, чтобы один процесс не мог вывести из строя всю систему.
На уровне мониторинга → настройте предупреждения при использовании памяти на уровне 80%, чтобы вмешиваться до того, как система начнёт активно использовать swap или сработает OOM Killer.

#2. Высокая загрузка CPU

Высокая загрузка процессора — ещё одна распространённая причина оповещений в Linux. Обычно первым делом открывают top или htop и смотрят, какой процесс находится вверху списка. Однако это показывает лишь кто использует процессор, но не объясняет почему.

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

Шаг 1. Подтвердите загрузку CPU

Загрузка CPU на уровне 100% не всегда означает проблему. Например, пакетная обработка данных может вполне закономерно использовать все доступные ресурсы процессора. Сначала убедитесь, что процессор действительно полностью загружен и что такая нагрузка не является ожидаемой.

# Refresh every 1 second to monitor CPU, memory, and process activity in real time
top -d 1

top - 14:32:15 up 10 days,  3:21,  2 users,  load average: 1.25, 1.10, 0.95
Tasks: 215 total,   1 running, 214 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us,  3.2 sy,  0.0 ni, 83.1 id,  0.8 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  16000.0 total,   1200.0 free,   9500.0 used,   5300.0 buff/cache
MiB Swap:   2048.0 total,   1800.0 free,    248.0 used

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1234 appuser   20   0   12.5g   4.2g   150m S  85.0 26.3  45:12.31 java
 5678 nginx     20   0  250000  45000  12000 S   2.0  0.3   2:15.04 nginx
 9012 mysql     20   0    3.0g   1.1g   300m S   1.5  6.9 120:45.18 mysqld

Обратите внимание на:

us (пространство пользователя): > 70% → приложение активно использует ЦП
sy (пространство ядра): >20% → высокая активность ядра; может указывать на большое количество системных вызовов, интенсивную работу сети или частое переключение контекста.
wa (ожидание ввода-вывода): > 5% → вероятно, узким местом является дисковая подсистема или сеть, а не процессор.

Шаг 2. Найдите виновника.

Если объем пользовательского пространства (%us) высок, выясните, какое приложение или сервис создаёт основную нагрузку.

# Show the top 20 processes sorted by CPU usage (highest first)
ps aux --sort=-%cpu | head -20

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
appuser   1234 85.2 12.3 12500000 4200000 ?   Sl   10:00  45:12 java
mysql     2345 15.4  6.8  3200000 1100000 ?   Sl   09:30 120:45 mysqld
nginx     3456  2.1  0.3   250000   45000 ?   S    08:00   2:15 nginx
root      4567  1.5  0.1   120000   12000 ?   S    07:00   0:30 systemd
...

Сосредоточьтесь на:

%CPU → какие процессы потребляют больше всего процессорного времени.
COMMAND → определите, какое приложение/сервис вызывает нагрузку (наше приложение, база данных или неожиданный процесс).
TIME → общее время использования CPU. Высокое значение за короткий период жизни процесса может указывать на резкий всплеск нагрузки.
PID → идентификатор процесса для дальнейшего анализа.
%MEM → проверьте, не является ли процесс одновременно ресурсоёмким по памяти.

Если системное пространство (%sy) велико, изучите активность ядра, чтобы определить, какие системные вызовы или системные задачи потребляют ресурсы ЦП.

# Show real-time system performance (updated every 1 second)
# Helps identify CPU pressure, context switching, and I/O wait
vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us  sy  id  wain   cs  us  sy  id  wa
 1  0  10240  200000  50000 800000    0    5     2     3  120  200   5   3  90   2
 2  0  10240  198000  50000 799000    0    3     0     4  150  250   6   4  88   2

Сосредоточиться на:

cs (переключения контекста): > 10 000/сек → процессор слишком часто переключается между процессами или потоками, что создаёт дополнительную нагрузку на планировщик задач и может замедлить работу системы.
in (прерывания): > 10 000/сек → процессор слишком часто обрабатывает аппаратные прерывания (сетевые карты, диски и другие устройства). Высокие значения обычно указывают на интенсивную сетевую активность, работу дисков или проблемы с драйверами.

Шаг 3. Выясните, что стало причиной всплеска нагрузки на CPU

Высокое значение us означает, что большая часть процессорного времени тратится на выполнение кода приложений (в пространстве пользователя, user space). Чтобы определить причину, выясните, какие изменения или условия могли увеличить нагрузку на приложение или снизить его эффективность:

Не увеличился ли неожиданно объём трафика или количество запросов?
Не было ли недавно развёртывания новой версии, изменения конфигурации или перезапуска?
Не зациклился ли процесс, не выполняет ли он чрезмерное количество повторных попыток (retries) или циклов обработки ошибок?
Не обрабатывает ли приложение необычно большой объём данных (пакетные задания, обработку данных, построение отчётов и т. п.)?

Высокое значение sy (системного процессора) означает, что значительная часть процессорного времени расходуется в ядре Linux (операционной системе), а не в коде приложения. Чтобы определить причину, выясните, что вызывает повышенную нагрузку на уровне системы:

Выполнялись ли в момент всплеска нагрузки какие-либо задания cron?
Не потребляют ли ресурсы задачи резервного копирования?
Не устанавливались ли системные обновления примерно в это же время?
Совпадает ли всплеск загрузки CPU с увеличением активности пользователей?

Шаг 4. Выберите подходящее решение

Проблемы на уровне приложения (высокое us):

Ожидаемый рост нагрузки → Продолжайте наблюдение и убедитесь, что система остаётся стабильной при штатном масштабировании.
Всплеск трафика → Масштабируйте приложение по горизонтали (добавьте новые экземпляры) или оптимизируйте обработку запросов и распределение нагрузки.
Неэффективный код или неверная конфигурация → Выполните профилирование приложения, найдите наиболее затратные участки кода (hot paths) и оптимизируйте их.
Бесконечный цикл или некорректная логика → Исправьте ошибку и при необходимости перезапустите затронутый процесс.
Ресурсоёмкая пакетная обработка → Перенесите выполнение на другое время, ограничьте скорость обработки или распределите нагрузку между несколькими узлами.

Проблемы на уровне ядра/системы (высокое sy):

Высокая активность ввода-вывода (диск/сеть) → Оптимизируйте операции ввода-вывода, используйте кэширование и сократите количество лишних операций чтения и записи.
Слишком много системных вызовов → Уменьшите чрезмерное количество обращений приложения к ядру и по возможности объединяйте системные операции.
Интенсивное переключение контекста → Сократите число потоков и процессов, настройте уровень параллелизма.
Неэффективность ядра или драйверов → Обновите ядро/драйверы и изучите известные проблемы системного уровня.
Задания Cron, резервное копирование или системные задачи → Измените расписание их выполнения, чтобы избежать конкуренции за ресурсы.
Резкий скачок трафика, создающий нагрузку на систему → Масштабируйте инфраструктуру и настройте параметры ОС и сети (очереди, буферы, параметры сетевого стека).

Шаг 5. Предотвращение повторных проблем с CPU

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

Настройте мониторинг и оповещения по CPU → Отслеживайте устойчивые значения us и sy (а не только общую загрузку CPU) и настройте предупреждения до того, как ситуация станет критической.
Оптимизируйте неэффективный код → Выполните профилирование приложения, устраните наиболее затратные участки, сократите лишние циклы, повторные попытки и тяжёлые вычисления.
Настройте параметры приложения → Скорректируйте уровень параллелизма, размеры пулов потоков и пулов соединений, чтобы избежать перегрузки процессора.
Пересмотрите расписание фоновых задач → Разнесите по времени выполнение cron, резервного копирования и пакетных заданий, чтобы избежать предсказуемых пиков нагрузки.
При необходимости увеличьте ресурсы → Если высокая загрузка CPU стала новой нормой, а не временным всплеском, масштабируйте систему по горизонтали или увеличьте вычислительные ресурсы.

#3. Высокая интенсивность дискового ввода-вывода

Высокая нагрузка на дисковую подсистему — распространённая проблема в Linux, особенно на серверах баз данных, файловых серверах и системах с интенсивной обработкой данных. Первой реакцией часто становится запуск команды df -h, однако она показывает лишь использование дискового пространства, а не степень загрузки подсистемы ввода-вывода.

Цель диагностики — определить, достигло ли устройство хранения предела своей производительности, выяснить, какие процессы создают нагрузку на диск, и устранить узкое место. Когда операции ввода-вывода выполняются медленно, приложения простаивают в ожидании чтения и записи данных, что приводит к увеличению времени отклика, задержкам в работе баз данных и общему снижению производительности системы.

Шаг 1. Подтвердите наличие нагрузки на дисковую подсистему

Убедитесь, что система действительно испытывает проблемы с подсистемой хранения данных, а предупреждение не вызвано другой причиной.

# detailed disk I/O stats, refreshed every 1s (5 times)
iostat -xz 1 5

Device:         rrqm/s   wrqm/s     r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda               0.00     5.00   120.0    80.0     1.2     3.5     45.00     2.10   15.20    10.50    22.10   2.50  92.30

Сосредоточиться на:

%util: > 80% → диск сильно загружен (если значение длительное время держится около 100%, это может указывать на насыщение).
await: SSD > 1 мс, HDD > 10 мс → высокая задержка свидетельствует о медленной обработке операций ввода-вывода.
r/s и w/s → количество операций чтения и записи в секунду (интенсивность нагрузки).
rkB/s и wkB/s → объём данных, считываемых и записываемых в секунду (пропускная способность).

Шаг 2. Определите, какие процессы за это отвечают.

# show all processes with I/O activity (accumulated + active only)
iotop -ao

Total DISK READ: 12.34 M/s | Total DISK WRITE: 45.67 M/s
Current DISK READ: 3.21 M/s | Current DISK WRITE: 10.11 M/s
    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
  1823 be/4  mysql      2.10 M/s    8.30 M/s   0.00 %  95 %    mysqld
  2210 be/4  appuser    0.50 M/s    1.20 M/s   0.00 %  40 %    java -jar app.jar
  1401 be/4  root       0.00 M/s    0.80 M/s   0.00 %  20 %    rsyslogd

Обратите внимание на:

DISK READ / DISK WRITE → Объём данных, который процесс считывает с диска или записывает на диск в секунду. Ищите процессы с необычно высокой дисковой активностью.
IO% (или IO>): > 30% → процесс значительную часть времени ожидает завершения операций ввода-вывода. Это означает, что он блокируется дисковой подсистемой.
COMMAND→ определяет сервис, являющийся источником нагрузки.

Шаг 3. Определите, к каким файлам осуществляется доступ.

Определите, к каким файлам обращается процесс, генерирующий наибольшее количество операций ввода-вывода на диске (наибольший объем чтения или записи на диск).

# list all files opened by a specific process
lsof -p <PID> | grep REG    # Regular files only

java    2210 appuser  5u  REG  8,1  1048576  789 /var/log/app.log
java    2210 appuser  7u  REG  8,1  5242880  912 /opt/app/data.db
java    2210 appuser 12w  REG  8,1   204800  333 /tmp/cache.tmp

Обратите внимание на:

FD → режим использования файла (r: чтение, w: запись, u: чтение и запись). Большое количество w/u может свидетельствовать об интенсивной записи, большое число FD — о возможной утечке, а постоянный доступ к одним и тем же файлам — о неэффективной работе приложения.
TYPE → тип ресурса. Обычно основной причиной высокой нагрузки являются обычные REG-файлы (такие как logs/DB/data).
NAME → путь к файлу. Это наиболее важное поле для определения реального источника дисковой нагрузки.

Шаг 4. Проверьте состояние файловой системы и устройства хранения

Цель этого шага — определить, вызвана ли проблема состоянием диска или нехваткой места, а не работой приложения.

# Shows how much disk space is used on each filesystem and what type it is (ext4, xfs, etc.).
df -hT

# Searches kernel logs for disk and hardware-related errors.
dmesg | grep -i 'error\|I/O error\|reset\|timeout' # Detect failing disks, cables, or controllers

# Reads the internal health data of a physical disk.
smartctl -a /dev/sda  # Detect early hardware degradation

df -hT → «Не заполнен ли диск?»
dmesg → «Система сообщает об ошибках диска?»
smartctl → «Не выходит ли из строя сам накопитель?»

Шаг 5. Проверьте исчерпание инода

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

# show inode usage per filesystem (how many files can still be created)
df -ih

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 1.2M 1.1M 100K 92% /
/dev/sdb1 2.0M 500K 1.5M 25% /data
tmpfs 250K 50K 200K 20% /run

Обратите внимание на:

IUse% (процент использования inode): > 90% → использование inode очень высокое. Система может перестать создавать новые файлы (логи, временные файлы, записи баз данных), даже если свободное место на диске ещё есть.

Шаг 6. Примите меры.

После того как причина проблемы определена, выполните соответствующие действия:

Выявлена проблема → Перезапустите, исправьте или настройте приложение, создающее чрезмерную нагрузку на дисковую подсистему ввода-вывода.
Интенсивная работа с файлами (логи, базы данных, временные файлы) → Настройте ротацию логов, оптимизируйте доступ к базе данных или очистите временные файлы.
Файловая система заполнена → Освободите место на диске или увеличьте объём хранилища.
Исчерпаны inode (IUse% > 90%) → Удалите ненужные мелкие файлы, очистите логи и кэш или увеличьте количество доступных inode.
Обнаружены ошибки диска или оборудования → Замените или отремонтируйте неисправный накопитель и выясните первопричину аппаратной неисправности.

#4. Медленная работа сети

Медленную работу сети бывает сложно диагностировать, потому что причина не всегда заключается в самой сети. Такие проблемы, как неполадки с DNS, высокая задержка, потеря пакетов, перегрузка сети, правила межсетевого экрана (firewall) или перегруженные приложения, могут сделать приложение медленным.

Многие начинают диагностику с ping, но успешный ответ на ping лишь подтверждает наличие соединения — он не объясняет проблемы с производительностью. Цель — определить, где возникает задержка, и понять, что является первопричиной: клиент, сервер, сетевой маршрут или приложение.

Шаг 1. Исключите задержки DNS.

Часто «медленная сеть» на самом деле оказывается медленным DNS-резолвером. Если разрешение имени занимает 2 секунды, а передача данных — всего 10 миллисекунд, значит сама сеть работает нормально.

# Measure precise DNS resolution time
time dig www.google.com

; <<>> DiG 9.18 <<>> www.google.com
;; ANSWER SECTION:
www.google.com.  300  IN  A  142.250.190.68

real    0m0.045s
user    0m0.010s
sys     0m0.005s

Обратите внимание на real (общее время разрешения DNS):

< 50 мс → Быстрый DNS
50–200 мс → Приемлемо
200–500 мс → Медленный DNS
> 1 с → Вероятная проблема с DNS

Шаг 2. Проверьте загрузку и ошибки локального сетевого интерфейса.

Убедитесь, что локальная сетевая карта (NIC) не теряет пакеты и не упирается в предел своей пропускной способности.

# View live network throughput across all interfaces
ip -s link

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    RX: bytes    packets   errors   dropped
    1256347890   1543210   0        12

    TX: bytes    packets   errors   dropped
    987654321    1321456   0        5

Обратите внимание на errors и dropped. Потерянные пакеты означают, что сетевой адаптер или ядро системы не успевают обрабатывать входящий трафик.

# Monitor real-time interface statistics (refreshes every 1 second)
sar -n DEV 1

12:00:01 AM IFACE   rxkB/s   txkB/s
12:00:01 AM eth0     1250      980
12:00:02 AM eth0     1305     1024
12:00:03 AM eth0     1288      995

Следите за rxkB/s - входящим и txkB/s - исходящим сетевым трафиком: если значения длительное время близки к максимальной пропускной способности интерфейса, это может свидетельствовать о перегрузке сети.

Шаг 3. Определите источники сетевой нагрузки

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

# show top remote connections grouped by IP:port and TCP state
ss -tnp | awk '{print $5, $6}' | sort | uniq -c | sort -rn | head -20

150 10.0.0.5:443 ESTAB
120 10.0.0.8:443 ESTAB
 90 10.0.0.12:443 TIME-WAIT
 40 10.0.0.15:443 SYN-RECV
 25 10.0.0.20:443 CLOSE-WAIT

Обратите внимание на:

SYN-RECV (Соединения, ожидающие завершения TCP-рукопожатия) → Большое количество может указывать на SYN-флуд, проблемы балансировщика нагрузки или сети.
TIME-WAIT (недавно закрытые соединения) → Высокое количество соединений может наблюдаться во время пиков трафика или при работе приложений, создающих множество кратковременных соединений.
CLOSE-WAIT (удалённое соединение закрыто, локальное ещё нет) → Высокие значения обычно указывают на проблему в приложении (утечке соединений или отсутствии корректного закрытия).

Шаг 4. Проверьте общую нагрузку на сокеты

Проверьте, не испытывает ли система перегрузку сети/сокетов, проанализировав общее количество соединений и их состояния.

ss -s

Total: 1200
TCP:   900 (estab 600, closed 150, orphaned 0, timewait 120)

Transport Total     IP        IPv6
RAW       1
UDP       50
TCP       900
INET      951

Команда выводит сводную статистику по состояниям сокетов. Обратите внимание на:

Очень высокий показатель ESTAB → высокий сетевой трафик или приложение с большим количеством активных соединений;
Очень высокий показатель TIME-WAIT → множество короткоживущих соединений или отсутствие повторного использования соединений;
Ненулевое значение ORPHANED → Проблема обработки сокетов приложения

Шаг 5. Сбор и анализ трафика.

Чтобы проверить истинную причину проблем в сети, проанализируйте фактические пакеты, передаваемые по сети, а не только статистику соединений, и подтвердите, что происходит на самом деле (рукопожатия, повторные передачи, потери пакетов и другие аномалии).

# capture 200 TCP packets on port 443 (HTTPS)
tcpdump -i eth0 -n -c 200 'tcp port 443'

12:01:01.123 IP 10.0.0.5.52344  > 10.0.0.12.443: Flags [S], seq 12345, win 64240
12:01:01.124 IP 10.0.0.12.443   > 10.0.0.5.52344: Flags [S.], seq 67890, ack 12346
12:01:01.125 IP 10.0.0.5.52344  > 10.0.0.12.443: Flags [.], ack 67891


# S → connection start (SYN)
# S. → SYN-ACK (handshake response)
# . → established data transfer
# F → connection close

Обратите внимание на:

Повторяющиеся SYN-пакеты (только S) → неудачные попытки подключения (возможно, флуд, блокировка брандмауэром или сбой рукопожатия)
Повторная передача SYN-пакета → повторная попытка клиента из-за отсутствия SYN-ACK (потеря пакета, перегрузка сети или нестабильность сети)
Нет ответа SYN-ACK → сервер не отвечает или трафик блокируется
Много кратковременных соединений (быстрое S → F) → неэффективная обработка соединений или высокая текучесть соединений.
Повторная передача / дублирование подтверждений → потеря пакетов, перегрузка сети или ухудшение качества сети.
Доминирование одного IP-адреса в трафике → всплеск трафика, неправильно настроенный клиент или возможная атака.

Шаг 6. Проверьте исчерпание таблицы отслеживания соединений (на хостах NAT/брандмауэра).

Проверьте, не заканчиваются ли в системе записи отслеживания соединений, так как это может привести к разрывам соединений, таймаутам или случайным сбоям сети на хостах NAT/брандмауэра.

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Если значение count близко к max, новые соединения будут незаметно разрываться.

Шаг 7. Примите меры.

После выявления первопричины примените соответствующее исправление для восстановления нормальной работы сети и предотвращения повторного возникновения проблемы:

Задержки DNS → смените DNS-резолвер, исправьте конфигурацию DNS или настройте более эффективное кэширование.
Перегрузка или ошибки сетевого интерфейса → уменьшите объём трафика, увеличьте пропускную способность или устраните проблемы с сетевой картой и оборудованием.
Высокая сетевая нагрузка → ограничьте скорость для клиентов (rate limiting), оптимизируйте запросы или масштабируйте сервисы.
Перегрузка сокетов (TIME-WAIT, CLOSE-WAIT и т.д.) → настройте обработку соединений в приложении или устраните утечки соединений.
Потеря пакетов, повторные передачи, ошибки SYN → проверьте правила firewall, маршрутизацию и устраните перегрузку сети.
Исчерпание conntrack → увеличьте лимиты или уменьшите количество создаваемых соединений.
Проблемы на уровне приложения → оптимизируйте повторные попытки запросов, повторно используйте соединения и устраните неэффективные сетевые вызовы.

#5. Высокий показатель средней нагрузки (Load Average)

Высокая средняя загрузка не обязательно означает высокую загрузку ЦП (различие, которое многие упускают из виду). Средняя загрузка измеряет количество процессов, которые либо выполняются на процессоре, либо ожидают доступа к ресурсам, таким как процессорное время или дисковый ввод-вывод. В результате система может иметь высокую среднюю загрузку, даже если загрузка ЦП кажется низкой.

Цель состоит в том, чтобы определить, какие процессы создают нагрузку, и выяснить, чего именно они ожидают: процессорного времени, дискового ввода-вывода или другого ресурса, прежде чем предпринимать какие-либо действия.

Шаг 1. Подтвердите среднюю загрузку.

Для начала проверьте текущую нагрузку.

# show system uptime and load average (1, 5, and 15 minutes)
uptime

14:32:18 up 25 days,  4:17,  2 users,  load average: 2.15, 1.87, 1.42

# 2.15 → average load over the last 1 minute
# 1.87 → average load over the last 5 minutes
# 1.42 → average load over the last 15 minutes

Сравните среднюю загрузку процессора с количеством ядер процессора:

Загрузка ≈ ядер CPU → система полностью загружена
Загрузка > ядер CPU → процессы ожидают ресурсов
Загрузка < ядер CPU → у системы есть запас производительности

Шаг 2. Разграничьте нагрузку на CPU и нагрузку на ввод-вывод.

Средняя загрузка процессора — это не только использование CPU. Она включает в себя процессы, работающие на CPU, и те, которые ожидают ресурсов, таких как операции ввода-вывода на диске. Высокая средняя загрузка может указывать на перегрузку CPU, узкие места в операциях ввода-вывода или и то, и другое.

# show CPU, memory, and I/O activity every 1 second (5 times)
vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa stin   cs us sy id wa st
 2  0      0 512000  45000 820000    0    0     5    10  120  300 25  5 70  0  0
 8  3      0 500000  45000 820000    0    0  1200  800  500 1200 20 10 30 40  0

В центре внимания: r (процессы, ожидающие загрузки CPU), b (процессы, заблокированные, обычно ожидающие операций ввода-вывода), wa (время CPU, затраченное на ожидание операций ввода-вывода), us / sy (нагрузка CPU приложения/системная нагрузка).

Высокая r (> количества ядер CPU) + высокая us/sy (us + sy > 70%) → загрузка ЦП
Высокий b (> 1) + высокий wa( wa > 10%) → нагрузка ввода/вывода
Высокое значение r (> количество ядер CPU) + низкое значение us/sy ( us + sy < 50%) → Наиболее вероятно - время ожидания ввода-вывода (подтвердите, проверив значение wa > 10% и/или ненулевое значение b)

Если проблема связана с загрузкой CPU, следуйте алгоритму действий при высокой загрузке CPU.
Если проблема связана с загрузкой ввода-вывода, следуйте алгоритму действий при высокой нагрузке на дисковый ввод-вывод.
Если проблема связана с ожиданием ввода-вывода, следуйте алгоритму действий при высокой нагрузке на дисковый ввод-вывод.

#6. Сервис не запускается

Отказ сервиса запускаться — одна из самых распространённых эксплуатационных проблем в Linux. Типичная реакция — снова и снова выполнять systemctl restart в надежде, что проблема исчезнет. Иногда это помогает. Но чаще всего — нет.

Цель — определить, почему сервис не смог запуститься, устранить первопричину и безопасно восстановить его работу.

Шаг 1. Подтвердите сбой.

# Show service state, recent logs, and start/stop status
systemctl status <service>

● nginx.service - A high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: failed (Result: exit-code) since Thu 2026-06-25 10:15:12
  Process: 2210 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)

Jun 25 10:15:12 server nginx[2210]: nginx: [emerg] bind() to 0.0.0.0:80 failedbind() to 0.0.0.0:80 failed
Jun 25 10:15:12 server systemd[1]: nginx.service: Failed to start

Активное состояние
active (running) → всё в порядке
failed → сервис не запускается
inactive → сервис остановлен
ExecStart error → показывает причину, по которой произошёл сбой при запуске
Строки логов (внизу) → указывают на первопричину (конфликт портов, ошибка конфигурации, проблема с правами доступа)

Шаг 2. Просмотрите логи

Логи обычно позволяют быстрее всего найти первопричину.

# Shows recent logs with errors and explanations
journalctl -u <service-name> -xe --no-pager

-- Logs begin at Thu 2026-06-25 --
Jun 25 10:15:12 systemd[1]: Starting My Application Service...
Jun 25 10:15:12 myapp[2210]: ERROR: Failed to load configuration file /etc/myapp/config.yaml
Jun 25 10:15:12 systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Jun 25 10:15:12 systemd[1]: myapp.service: Failed with result 'exit-code'.'exit-code'.
Jun 25 10:15:12 systemd[1]: Failed to start My Application Service.

Обратите внимание на:

сообщения об ошибках ( emerg, error, failed) → непосредственная причина сбоя сервиса
ошибки привязки/порта → порт уже используется
ошибки прав доступа → отсутствует доступ к файлу или каталогу
Сбои в работе зависимостей → необходимый сервис не запущен.

Шаг 3. Проверьте конфигурацию

Некорректная конфигурация — одна из самых частых причин, по которым сервис не запускается. Многие сервисы имеют встроенную команду проверки конфигурации, поэтому всегда выполняйте её перед перезапуском сервиса или применением изменений.

# test Nginx configuration for syntax errors
nginx -t

# test Apache configuration
apachectl configtest

# HAProxy syntax check
haproxy -c -f /etc/haproxy/haproxy.cfg

# SSH configuration test (syntax check only)
sshd -t

Если у сервиса нет встроенной команды проверки, вручную запустите исполняемый файл сервиса из командной строки, используя те же аргументы, которые указаны в unit-файле systemd.

# shows the full unit file including ExecStart
systemctl cat <service-name>

# /lib/systemd/system/nginx.service
[Unit]
Description=A high performance web server

[Service]
Type=forking
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID

[Install]
WantedBy=multi-user.target

Обратите внимание на:

ExecStart= → точная команда, используемая для запуска сервиса;
ExecReload/ExecStop → как сервис перезагружается и останавливается;
Дополнительные параметры (если присутствуют) → пользовательские переопределения, которые могут изменять поведение по умолчанию.

Шаг 4. Проверьте зависимости

Некоторые сервисы зависят от других сервисов. Убедитесь, что все необходимые зависимости (сервисы, сокеты, базы данных или точки монтирования) запущены и доступны.

# show all required and optional dependencies
systemctl list-dependencies <service>

myapp.service
● ├─network.target
● ├─mysql.service
● ├─redis.service
● ├─system.sliceslice
● └─basic.target

Обратите внимание на:

Обязательные сервисы (например, mysql.service, redis.service) → они должны быть активны, иначе сервис не запустится.

# check if a specific dependency is running
systemctl status <dependency-service>

network.target → сеть должна быть доступна до запуска сервиса.

Шаг 5. Проверьте наличие конфликтов портов

Если в логах указано "Address already in use" или "Failed to bind", это означает, что другой процесс уже прослушивает сетевой порт, который требуется вашему сервису.

# Identify which process is holding the target port (e.g., port 80)
ss -tulpn | grep :80

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

Шаг 6. Проверьте права доступа и владельцев файлов

Сервисы, которыми управляет systemd, часто запускаются от имени непривилегированного системного пользователя (например, mysql, www-data, redis). Если этот пользователь не может прочитать файл конфигурации или записать данные в каталоги логов или данных, сервис завершится с ошибкой при запуске.

# Verify the user/group assigned to the service
systemctl show <service-name> -p User,Group

# Verify ownership of the service's critical directories
ls -ld /var/log/<service-name> /var/lib/<service-name> /etc/<service-name>

Если во время ручной диагностики файлы были случайно изменены или созданы от имени root, восстановите правильного владельца:

# change ownership of service data directory to correct user and group
chown -R <service-user>:<service-group> /var/lib/<service-name>

Шаг 7. Проверьте системные ресурсы

Если сервис по-прежнему не запускается, проверьте, достаточно ли системе ресурсов (CPU, памяти, дискового пространства и системных лимитов) для его работы.

# check CPU and memory usage
top

# check available memory and swap usage
free -h

# check disk space availability
df -h

# check process/resource limits
ulimit -a

Обратите внимание на:

высокое потребление памяти / недостаток свободной оперативной памяти → сервис может завершаться или не пройти инициализацию.
высокая загрузка ЦП → запуск может быть медленным или завершаться ошибкой;.
диск заполнен (100%) → сервис не сможет записывать логи или временные файлы;
слишком низкие лимиты файловых дескрипторов или других ресурсов → сервис не сможет открыть необходимые файлы или сокеты.

Шаг 8. Запустите сервис и убедитесь, что он работает

После устранения проблемы запустите сервис и убедитесь, что он работает корректно.

# start the service
systemctl start <service-name>

# verify service is active and running
systemctl status <service-name>

# check logs if service still fails or behaves unexpectedly
journalctl -u <service-name> -xe --no-pager

#7. Исследование процесса

Каждое приложение, работающее в Linux, является процессом. Понимание жизненного цикла процесса — одна из фундаментальных основ эффективного администрирования систем. Многие инженеры знают отдельные команды, такие как ps, kill или systemctl, однако устранение проблем, связанных с процессами, требует понимания всего жизненного цикла — от создания процесса до его завершения.

Цель в том, чтобы определить, что делает процесс, как он оказался в текущем состоянии и нужно ли его отслеживать, перезапустить или завершить.

Шаг 1. Найдите процесс

# Search for a running process by name
ps aux | grep <process-name>

root      2210  2.5  1.2  450000 50200 ?  Sl  10:15   0:08 nginx: master process
www-data  2211  1.1  0.8  451200 34120 ?  S   10:15   0:03 nginx: worker process

Обратите внимание на PID(например, 2210, 2211) → уникальный идентификатор процесса, который используется в последующих командах для исследования, мониторинга или управления процессом.

Шаг 2. Исследуйте процесс

После того как PID найден, исследуйте процесс, чтобы понять его текущее состояние и поведение.

# Show detailed information for a specific process
ps -o pid,ppid,state,%cpu,%mem,etime,cmd -p <PID>

  PID  PPID S %CPU %MEM     ELAPSED CMD
 2210     1 S  2.5  1.2     02:15:43 nginx: master process

Обратите внимание на:

PPID: 1 → идентификатор родительского процесса.
STATE ( S):
R → выполняется (Running)
S → спящий (Sleeping)
D → непрерываемый сон (ожидание I/O)
Z → процесс-зомби (Zombie)
%CPU: 2.5 → текущее использование CPU
%MEM: 1.2 → текущее использование памяти
ELAPSED: 02:15:43 → как долго длится этот процесс
CMD: nginx: master process → команда, которой был запущен процесс.

Шаг 3. Проверьте ооткрытые файлы и сетевые соединения

Определите, с чем именно взаимодействует данный процесс, например, с файлами, каталогами, устройствами и сетевыми сокетами.

# List all open files and network connections for the process
lsof -p <PID>

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
nginx   2210 root  cwd    DIR  8,1      4096       2 /
nginx   2210 root  txt    REG  8,1   1260032  393298 /usr/sbin/nginx
nginx   2210 root    3r   REG  8,1    524288 1048576 /etc/nginx/nginx.conf
nginx   2210 root    6w   REG  8,1   1048576 2097152 /var/log/nginx/error.log
nginx   2210 root    7u  IPv4  45678       0     TCP 0.0.0.0:80 (LISTEN)
nginx   2210 root    8u  IPv4  45679       0     TCP 192.168.1.10:80->192.168.1.20:52314 (ESTABLISHED)

Обратите внимание на:

FD
r → чтение
w → запись
u → чтение и запись
TYPE
REG → обычный файл
DIR→ каталог
IPv4/ IPv6 → сетевой сокет
NAME
Путь к файлу → указывает, к каким файлам обращается процесс
LISTEN → ожидание входящих соединений
ESTABLISHED → активное сетевое соединение

Шаг 4. Просмотрите логи

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

# Show all logs for a specific systemd service
journalctl -u <service>

Обратите внимание на:

Сообщения ERROR / FAIL → непосредственная причина сбоя;
последовательность запуска (Startup sequence) → что происходило до сбоя;
ошибки конфигурации или прав доступа → наиболее распространённые причины;
коды завершения (Exit codes) → причина остановки сервиса.

Шаг 5. Примите соответствующее решение

После просмотра логов и определения первопричины выберите правильное решение в зависимости от типа ошибки.

Ошибка конфигурации → исправьте конфигурационный файл, затем повторно выполните проверку и перезапустите сервис.
Сбой зависимостей → запустите или восстановите отсутствующую зависимость (БД, сеть, точку монтирования).
Конфликт портов → остановите конфликтующий процесс или измените порт сервиса.
Проблема с правами доступа → исправьте владельца или права (chown, chmod).
Проблема с ресурсами → освободите место на диске или память либо скорректируйте системные лимиты.
Сбой/неизвестная проблема → изучите более подробные логи и выполните отладку в фоновом режиме.

Не завершайте процесс, пока не поймёте его назначение и влияние на зависящие от него сервисы.

#8. Процесс не завершается

Когда приложение перестаёт отвечать или зависает, необходимо использовать безопасную и последовательную процедуру его завершения. Безрассудное завершение процесса может привести к повреждению базы данных, появлению осиротевших дочерних процессов или утечке сегментов общей памяти.

Шаг 1. Корректное завершение

Всегда начинайте с наиболее мягкого сигнала, чтобы дать приложению возможность освободить ресурсы, записать буферы на диск и корректно закрыть сетевые сокеты.

# Request polite termination (SIGTERM - Signal 15)
kill -15 <PID>

Альтернатива для многопроцессных приложений: если главный процесс создал несколько рабочих процессов (например, Apache, Nginx или PHP-FPM), используйте pkill, чтобы отправить сигнал всей группе процессов по имени:

# Safely request all processes matching the name to stop
pkill -15 -f <process-name>

Шаг 2. Принудительное завершение.

Этот способ немедленно завершает процесс, не позволяя ему выполнить очистку ресурсов.

# Force termination via the kernel (SIGKILL - Signal 9)
kill -9 <PID>

Шаг 3: Проверьте состояние процесса

Если kill -9 не удалил процесс из вывода ps или top, значит процесс находится в состоянии, в котором он не может принимать сигналы.

# show process state, wait channel, and command
ps -o pid,stat,wchan,comm -p <PID>

PID STAT WCHAN  COMMAND
 2210 D    0      java

Обратите внимание на STAT:

D → процесс находится в непрерываемом сне (Uninterruptible Sleep), обычно ожидая завершения операций ввода-вывода (диск, NFS или другое хранилище). Такой процесс нельзя завершить, пока операция ввода-вывода не завершится.
Z → процесс-зомби (Zombie). Он уже завершил выполнение, но всё ещё присутствует в таблице процессов, потому что родительский процесс ещё не получил его статус завершения.

Шаг 4. Выполните необходимые действия

Процесс находится в состоянии D (непрерываемый сон).
Если в столбце STAT отображается D, процесс ожидает завершения операций ввода-вывода на уровне ядра.

# Shows what kernel function the process is currently waiting on (if any)
cat /proc/<PID>/wchan

blk_mq_get_tag → ожидание очереди блочного устройства (узкое место дисковой подсистемы)
io_schedule → ожидание планировщика ввода-вывода
nfs_* → задержка сетевой файловой системы

Для решения этой проблемы необходимо определить и устранить узкое место в подсистеме хранения или сетевой файловой системе: уменьшить нагрузку на I/O, исправить проблемы с диском или NFS либо остановить процесс, создающий чрезмерную нагрузку. Если подсистема хранения полностью перестала отвечать, последним средством остаётся перезагрузка системы.

Процесс в состоянии Z (зомби)
Если в столбце STAT отображается Z, значит, процесс уже завершил выполнение, но всё ещё присутствует в таблице процессов.

# Find the parent process
ps -o ppid= -p <PID>

Для решения этой проблемы определите родительский процесс и перезапустите или исправьте его, чтобы он корректно собирал статусы завершившихся дочерних процессов (с помощью wait()), после чего процесс-зомби будет автоматически удалён системой.

#9. Дисковое пространство заполнено

Заполненный диск — один из самых распространённых инцидентов в Linux. Первая реакция — обычно выполнить df -h, чтобы убедиться, что файловая система заполнена. Но эта команда лишь показывает, где находится проблема, а не что именно занимает место.

Цель состоит в том, чтобы определить, что использует дисковое пространство, понять, является ли рост использования ожидаемым или аномальным, и безопасно освободить место, не вызвав дополнительных проблем.

Шаг 1. Определите затронутую файловую систему

Для начала определите, какая файловая система заканчивает свободное место.

# Show disk usage in human-readable format
df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   45G   2.0G  96% /
/dev/sdb1       200G  120G   80G   60% /data
tmpfs            3.9G     0  3.9G    0% /run

Обратите внимание на:

Use% → процент использования
Mounted on → где файловая система смонтирована в системе.

Шаг 2. Найдите самые большие каталоги

После того как мы определили, какая точка монтирования заполнена, углубитесь в этот каталог, чтобы найти самые большие папки и файлы.

# Shows which top-level directories consume disk space (e.g., /)
du -xh / --max-depth=1 2>/dev/null | sort -h

4.0K    /proc
120M    /boot
600M    /home
1.2G    /usr
2.5G    /var
8.0G    /opt
15G     /

Продолжайте углубляться в самый большой каталог, повторяя анализ размеров на каждом уровне.

Распространённые причины проблем в производстве:

/var/log/ → логи, которые не ротируются, или приложение пишет чрезмерно подробные (debug) логи.
/var/lib/docker/ → неиспользуемые слои контейнеров, "висящие" (dangling) тома или большие кэши сборки.
/tmp/ → забытые дампы памяти (core dumps) или неочищенные временные файлы, загруженные приложениями.

Шаг 3. Найдите большие файлы

После того как каталог найден, углубитесь в него и найдите необычно большие файлы, чтобы определить точный источник использования дискового пространства.

# Search for files larger than 500MB within a specific mounted filesystem/directory
find <mount_point> -type f -size +500M

# find /var/lib -type f -size +500M
/var/lib/mysql/ibdata1
/var/lib/mysql/mysql-bin.000012
/var/lib/docker/overlay2/sha256-layer/layer.tar

Этот вывод показывает конкретные большие файлы внутри проблемной точки монтирования, помогая определить, что именно занимает дисковое пространство.

Шаг 4. Проверьте удалённые файлы, которые всё ещё используются

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

# Show files that are deleted but still held open by processes
lsof | grep deleted

nginx   2210 root  6w   REG  8,1  104857600 /var/log/nginx/access.log (deleted)
java    3321 app   12u  REG  8,1  524288000 /tmp/cache.tmp (deleted)

Если удалённый файл всё ещё открыт, перезапуск процесса, которому он принадлежит, может освободить занимаемое пространство.

Шаг 5. Определите причину

Прежде чем что-либо удалять, разберитесь, почему диск оказался заполнен.

Не сработала ротация логов?
Приложение генерирует слишком много логов?
Недавно была создана резервная копия?
База данных растёт ожидаемым образом?
Пользователь загрузил большой объём данных?

Устранение симптома без устранения причины часто приводит к повторению того же инцидента.

Шаг 6. Безопасно освободите пространство

В зависимости от результатов анализа можно:

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

Избегайте бездумного удаления файлов, особенно в каталогах /var, /etc или каталогах с данными приложений.

Безопасная экстренная очистка

Если необходимо быстро освободить немного места, чтобы восстановить работу неработающего сервиса, выполните следующие безопасные команды очистки:

# Clean up systemd journal logs older than 3 days
journalctl --vacuum-time=3d

# Safely purge unused Docker containers, networks, and dangling images
docker system prune -f

# Clean package manager repository caches (Ubuntu/Debian)
apt-get clean

#10. Исчерпание inode

Иногда df -h показывает, что свободного места на диске достаточно, но приложения всё равно выдают ошибку No space left on device. Это означает, что закончились иноды (индексные узлы метаданных).

Шаг 1. Подтвердите исчерпание инода.

# Check inode utilization instead of block storage
df -i

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      3276800 3200000  76800   98% /
/dev/sdb1     13107200  500000 12607200   4% /data
tmpfs          1000000     120   999880   1% /run

Обратите внимание на IUse% (процент использования inode):

< 80% → норма
80–90% → предупреждение
> 90% → высокий риск
~100% → исчерпание inode (невозможно создать новые файлы)

Шаг 2. Найдите каталоги, содержащие слишком большое количество файлов

Когда использование inode высокое, проблема обычно заключается в слишком большом количестве мелких файлов, а не крупных. Поэтому нам нужно выяснить, где происходит «взрывной рост» файлов.

# Find which directories consume most inodes
du -x --inodes / | sort -nr | head -n 10

1200000  /var
950000   /var/lib
600000   /var/log
450000   /home
300000   /var/cache
120000   /usr
80000    /tmp
50000    /opt
30000    /run
10000    /etc

Этот вывод показывает, какие каталоги используют больше всего inode (нагрузка по количеству файлов), а не дискового пространства.

Шаг 3. Перейдите к каталогам с большим количеством файлов.

# Narrow down inode-heavy subdirectories
du -x --inodes /var | sort -nr | head -n 10

800000   /var/log
500000   /var/lib
300000   /var/lib/docker
250000   /var/cache
120000   /var/spool
80000    /var/tmp
50000    /var/www
20000    /var/backups
15000    /var/mail
10000    /var/run

Что это нам говорит:

/var/log → взрывной рост логов (очень распространённая проблема с inode)
/var/lib/docker → слои контейнеров / образы / файлы overlay
/var/cache → накопление кэша (менеджеры пакетов, приложения)
/var/spool → задания в очереди (почта, печать, cron)

Эти данные помогают точно определить, какие подкаталоги внутри /var потребляют больше всего inode, позволяя выполнить целевую очистку вместо того, чтобы действовать наугад.

Шаг 4. Определите источник увеличения размера файлов

# Inspect directories likely generating many small files
find /var/log -type f | head

/var/log/syslog
/var/log/auth.log
/var/log/kern.log
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/journal/abcd1234/system.journal
/var/log/mysql/error.log
/var/log/apt/history.log
/var/log/dpkg.log
/var/log/faillog

Эта команда позволяет быстро просмотреть структуру файлов логов, помогая определить, в каком направлении углубить анализ проблем с inode или использованием диска.

Шаг 5. Исправьте проблему и выполните очистку

Очистка логов / ротация:

logrotate -f /etc/logrotate.conf

Удалите безопасные временные файлы:

rm -rf /tmp/*
rm -rf /var/tmp/*

Исправление на уровне сервиса:

перезапустить шумный сервис
исправить конфигурацию логирования
снизьте скорость генерации файлов

Шаг 6. Проверьте восстановление

# confirm inode usage dropped
df -i

# 11. Сервер работает медленно

«Сервер работает медленно» — один из самых распространённых и при этом наименее конкретных инцидентов, с которыми мы сталкиваемся. Он не указывает на какую-то одну проблему. Первой реакцией часто становится подключение к серверу по SSH и запуск top. Хотя это вполне разумная отправная точка, она показывает лишь часть общей картины.

Цель — определить, какая подсистема вызывает замедление, локализовать узкое место и устранить первопричину, а не действовать наугад.

Шаг 1. Проверьте возможные причины

Начните с быстрой проверки основных системных ресурсов, чтобы определить, где находится узкое место. Сосредоточьтесь на четырёх основных областях:

CPU → высокая загрузка или ресурсоёмкие процессы
Память → Высокое использование оперативной памяти или swap
Диск → высокий дисковый I/O, высокая задержка или недостаток свободного места на диске

# Display a one-time snapshot of CPU, memory, load average, and top resource-consuming process
top -b -n 1

Для быстрой оценки состояния системы обычно используются следующие пороговые значения:

Средняя загрузка: > количества ядер CPU → Высокая средняя загрузка
%CPU (us + sy): > 90% → Высокая загрузка CPU
Доступная память: < 20% → Нехватка памяти

Шаг 2. Определите дальнейшие действия

Исходя из первоначальных результатов, продолжайте работу в соответствии с установленным порядком.

Высокая средняя загрузка → Сценарий при высокой средней загрузке
Высокая загрузка CPU (>90%) → Сценарий высокой загрузки CPU
Мало доступной памяти (<20%) → Сценарий диагностики высокой средней нагрузки

Если средняя загрузка, CPU и память в норме, проверьте другие параметры.

Сеть работает медленно.
Дисковое пространство заполнено

Шаг 3. Проверьте последние изменения.

Если ничего очевидного не обнаруживается, выясните, что изменилось.

# Focus on recent system logs 
# to check errors, service failures, or anomalies in the last 30 minutes
journalctl -S "30 minutes ago"

Найдите наиболее распространённые причины медленной работы сервера в логах:

Изменения сервисов: Started, Stopped, Restarting, Reloaded
Ошибки и сбои: ERROR, failed, failure, crash
Проблемы производительности: timeout, slow, took too long, delayed
Проблемы с ресурсами: Out of memory, OOM killer, No space left on device
Нестабильность системы: kernel, panic, soft lockup, hang
Проблемы сети: connection refused, reset, timed out

Шаг 4. Проверьте приложение

Если сервер выглядит исправным, сосредоточьтесь на уровне приложений.

Проверьте логи приложения → найдите ошибки, исключения, тайм-ауты.
Проверьте состояние сервиса → убедитесь, что процессы приложения запущены и не перезапускаются/не завершаются с ошибкой.
Проверьте время отклика → медленные API, конечные точки с высокой задержкой.
Производительность базы данных → Медленные запросы, блокировки, ограничения на количество подключений
Недавние развертывания/изменения конфигурации → новый код, конфигурация или feature flags, вызывающие замедление
Внешние зависимости → превышение времени ожидания при вызовах API, сервисов или сторонних сервисов
Ограничения на количество потоков/соединений → Исчерпаны рабочие потоки или пулы соединений

Универсальный алгоритм устранения неполадок в Linux

Независимо от типа полученного оповещения (медленная работа сервера, высокая загрузка ЦП, проблемы с памятью или сбой сервиса), расследование обычно следует следующей закономерности:

Alert
  │
  ▼
Identify affected resource
(CPU, Memory, Disk, Network, Service)
  │
  ▼
Find the top consumer
  │
  ▼
Collect evidence
(top, vmstat, iostat, ss, journalctl)
  │
  ▼
Determine root cause
  │
  ▼
Apply a fix
  │
  ▼
Verify and monitor

Всегда используйте подход system → changes → application → root cause, который помогает избежать догадок и обеспечивает быструю и структурированную диагностику неисправностей каждый раз.

Заключительные мысли

Существует бесчисленное количество статей и шпаргалок, в которых перечислены команды Linux, которые, как считается, мы должны запомнить. Хотя такие материалы полезны, они могут создать впечатление, что стать более сильным инженером — это просто вопрос изучения большего количества команд.

В действительности опытные инженеры подходят к решению проблем иначе. Они не начинают с вопроса: «Какую команду мне выполнить?». Они начинают с вопроса: «Что именно я пытаюсь найти?». Когда цель ясна, выбрать правильную команду становится гораздо проще. Сценарии предоставляют воспроизводимый процесс исследования проблем независимо от того, какие инструменты доступны.

Опытные инженеры часто превращают часто используемые последовательности команд в псевдонимы (aliases), функции оболочки (shell functions) или небольшие shell-скрипты. Это уменьшает количество повторяющегося ввода, стандартизирует процесс расследования и позволяет сосредоточиться на анализе результатов, а не на запоминании команд.

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

На этом все! Спасибо за внимание! Если статья была интересна, подпишитесь на телеграм-канал usr_bin, где будет еще больше полезной информации.

Linux сложен в освоении — пока вы не поймете эти 7 вещей

2026-07-28T07:45:37.905Z

Это перевод оригинальной статьи Linux Is Hard — Until You Understand These 7 Things.

Ошибки новичков, о которых редко предупреждают.

Мне казалось, что Linux меня наказывает

Когда Linux впервые выдал сообщение «Доступ запрещен», я воспринял это лично.

Я правильно ввел команду.
Я следовал руководству слово в слово.

И всё равно Linux отказался сотрудничать.

Я смотрел на терминал, будучи уверенным, что Linux создан, чтобы запутывать новичков.
В тот вечер я почти удалил систему и вернулся на Windows.

Тогда я не знал простого:

Linux не мешал мне. Linux учил меня правилу, которому я никогда не учился.

Изображение сгенерированы ИИ.

Часть 1: Права доступа. Первое препятствие, с которым сталкивается каждый новичок.

Я пытался запустить скрипт оболочки.

./backup.sh

Linux ответил мгновенно:

bash: ./backup.sh: Permission denied

Я попробовал снова.
Результат тот же.

Я добавил sudo, не понимая зачем.

sudo ./backup.sh

Это сработало, но я чувствовал себя неловко. Словно я сжульничал.

Именно тогда один из старших инженеров задал мне один вопрос:

«Ты знаешь, кто владеет этим файлом?»

Я этого не знал.

День, когда права доступа наконец обрели смысл.

В Linux каждый файл отвечает на три вопроса:

Кто мной владеет?
Кому ещё разрешён доступ?
Что именно им разрешено делать?

Я выполнил:

ls -l backup.sh

Вывод:

-rw-r--r-- 1 pawan pawan 2456 backup.sh

Эта строка выглядела пугающе, но она была честной.

rw- → Я могу читать и записывать
Нет x → Я не могу выполнить

Linux не был злым.
Linux был точным.

Поэтому я сделал то, чего ожидал Linux:

chmod +x backup.sh

Затем:

./backup.sh

Оно работало.

Тот момент научил меня важному:
Linux не угадывает твои намерения. Он следует правилам.

Часть 2: Файловая система — почему Linux сначала кажется «потерянным»

Когда я установил свой первый сервис, я задал себе глупый вопрос:

«Куда оно делось?»

Нет диска C:.
Нет окна установщика.
Нет ярлыка.

Просто… тишина.

Затем я узнал, что Linux не скрывает файлы — он их классифицирует.

Конфигурации находятся в:

/etc

Логи попадают в:

/var/log

Данные пользователя хранятся в:

/home

Исполняемые файлы находятся в:

/bin
/usr/bin

Как только я перестал искать информацию наугад и начал мыслить структурно, Linux перестал казаться мне хаотичным.

Дело было не в отсутствующих файлах.
Мне не хватало карты.

Часть 3: Процессы — невидимая толпа внутри системы

Моя система работала медленно.

Мучительно медленно.

Я перезагрузил систему.
Ничего не изменилось.

Тогда мне показали:

top

Внезапно Linux перестал быть тихим.

Я мог видеть:

загрузку CPU
использование памяти
процессы, пожирающие ресурсы

Позже я изучил:

ps aux | grep java

Linux не был медленным. Медленным был один некорректно работающий процесс.

Тогда я понял, Linux даёт вам видимость, а не оправдания.

Часть 4: Сервисы — причина, по которой «Вчера всё работало»

Однажды утром мой веб-сервер не запустился.

Никакого всплывающего окна.
Никакого предупреждения.

Сервис просто не работает.

Вместо того чтобы переустанавливать всё (моя старая привычка), я выполнил следующую команду:

systemctl status nginx

Ответ был прямо перед глазами — отсутствовал конфигурационный файл.

Я исправил.
Перезапустил сервис:

systemctl restart nginx

Linux не подвёл.
Я просто не задал правильный вопрос.

Часть 5: Логи — Linux всегда всё объясняет

Месяцами я считал, что Linux «никогда не сообщает о проблемах».

Это было моим самым большим заблуждением.

Linux предоставляет всю необходимую информацию — в логах.

Когда что-то ломалось, я научился проверять:

journalctl -xe

или

tail -f /var/log/syslog

У каждого сбоя была своя история.
Каждая ошибка оставляла за собой след.

Linux не выдает ошибок.
Он их записывает.

Часть 6: Сеть — «У меня на машине работает»

Сервис был запущен.
Порт был открыт.
Тем не менее, соединения не было.

Я научился проверять элементарные вещи:

ip a

ss -tuln

ping google.com

Затем брандмауэр:

firewall-cmd --list-all

Сеть перестала быть магией, когда я начал воспринимать её как логику.

Часть 7: Ментальный сдвиг, который изменил всё

Linux не сложен.
Linux честен.

Он не предполагает.
Он не гадает.
Он не защищает от плохих решений.

Как только я перестал бороться с Linux и начал его понимать, всё изменилось.

Я не стал умнее.
Я стал более осознанным.

Почему я пишу эту серию

Каждый начинающий пользователь Linux проходит через это:

Сомнения в себе
Путаница
Молчаливое разочарование

Если это про вас — вы не терпите неудачу.

Вы изучаете Linux так, как это делают профессионалы:
ломая, исправляя и, в конце концов, понимая.

xargs: команда, которая делает всё остальное компонуемым

2026-07-28T07:40:41.546Z

Это перевод оригинальной статьи xargs: The command that makes everything else composable.

Вы видели её в ответах на Stack Overflow. Вы копировали и вставляли её один или два раза. Вы примерно знаете, что она как-то связана с конвейерами.

Но если бы вас попросили написать команду xargs с нуля, вы, скорее всего, задумались бы.

В этом и заключается пробел в понимании xargs. Большинство разработчиков знают, что она существует. Почти никто не использует её уверенно. Эта статья исправит это.

Фотография Фото Tommy Diner на Unsplash .

Проблема, которую она решает

Конвейер Unix | — мощный инструмент. Он берет вывод одной команды и передает его в качестве входных данных следующей команде.

cat files.txt | grep "error"

Это работает, потому что grep предназначена для чтения из stdin. Но многие команды устроены иначе. Они ожидают аргументы, а не stdin.

Попробуйте это:

echo "file.txt" | rm

Это не сработает. rm не читает из stdin. Она ожидает аргументы: rm file.txt.

Именно этот пробел и заполняет xargs. Она читает данные из stdin и преобразует этот ввод в аргументы для другой команды

echo "file.txt" | xargs rm

Теперь это работает. xargs получил file.txt из stdin и передала его в rm как аргумент.

В этом и заключается вся модель понимания. xargs преобразует stdin в аргументы.

Базовый синтаксис

command1 | xargs command2

command1 формирует вывод. xargs берет этот вывод и передает его в качестве аргументов для command2.

По умолчанию xargs разбивает ввод по пробельным символам и символам новой строки, а затем за один вызов передает все элементы как аргументы.

echo "a b c" | xargs echo
# Output: a b c

Всё просто. Теперь давайте сделаем это полезным.

Реальное использование, шаг за шагом

Удаление списка файлов

У вас есть файл, содержащий пути к файлам, которые нужно удалить:

cat to_delete.txt | xargs rm

Или найти и удалить напрямую:

find . -name "*.log" | xargs rm "*.log" | xargs rm

Это наиболее распространенный шаблон использования xargs. find формирует список путей, а xargs передает их все в rm.

Без xargs вам пришлось бы использовать цикл:

# Without xargs — more verbose
for f in $(find . -name "*.log"); do
  rm "$f"
done

xargs позволяет записать это в одну строку.

Флаг `-I`: размещение аргумента именно там, где нужно

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

cat branches.txt | xargs -I {} git checkout {}

-I {} определяет заполнитель. Везде, где вы помещаете {} в команде, xargs подставляет текущий элемент. В качестве заполнителя можно использовать любую строку. {} — это просто соглашение.

Реальный пример: перемещение файлов в каталог резервных копий.

find . -name "*.bak" | xargs -I {} mv {} ./backup/{}"*.bak" | xargs -I {} mv {} ./backup/{}

Это перемещает каждый файл .bak в каталог ./backup/, сохраняя имя файла. Без -I выразить это было бы неудобно.

`-n:` обрабатывать по одному элементу за раз

По умолчанию xargs объединяет все аргументы в один вызов команды. Иногда требуется один вызов на каждый элемент.

cat servers.txt | xargs -n 1 ping -c 1

-n 1 указывает xargs передавать один аргумент на каждый вызов команды. Поэтому, если в servers.txt содержится пять серверов, команда ping -c 1 будет выполнена пять раз — по одному разу для каждого сервера.

-n 2 будет передавать по два аргумента за один вызов и так далее.

`-P`: Выполнять параллельно

Именно здесь xargs становится по-настоящему мощной.

cat urls.txt | xargs -n 1 -P 4 curl -O

-P 4 запускает до 4 процессов параллельно. В сочетании с -n 1 (один URL на вызов) это позволяет загружать все URL по четыре одновременно, а не последовательно.

Тот же шаблон подходит для любой медленной задачи, которую можно распараллелить: обработка файлов, запуск тестов, обращения к API:

find . -name "*.csv" | xargs -n 1 -P 8 python process.py

Восемь файлов обрабатываются одновременно. Без очередей задач, без дополнительных инструментов. Только xargs.

Шаблон `-print0` и `-0`

В большинстве примеров с xargs есть одна неочевидная проблема. Имена файлов могут содержать пробелы. А поскольку по умолчанию xargs разбивает ввод по пробельным символам, файл с именем my report.csv будет воспринят как два аргумента: my и report.csv.

Решение:

find . -name "*.csv" -print0 | xargs -0 rm"*.csv" -print0 | xargs -0 rm

-print0 указывает find разделять результаты нулевым символом вместо символа новой строки. -0 указывает xargs разбивать ввод по нулевым символам вместо пробельных. Теперь имена файлов с пробелами обрабатываются корректно.

Возьмите это за привычку всякий раз, когда объединяете find и xargs. Это защитный подход, который ничего не стоит.

# Fragile -> breaks on filenames with spaces
find . -name "*.log" | xargs rm

# Robust -> handles all filenames correctly
find . -name "*.log" -print0 | xargs -0 rm

`args` как связующее звено между командами

Как только вы поймете xargs, вы начнете замечать её повсюду — не как команду, которую нужно искать в справочнике, а как связующее звено, которое делает остальные команды комбинируемыми.

Несколько шаблонов, которые стоит запомнить:

Поиск с помощью grep среди отфильтрованного набора файлов:

find . -name "*.java" -print0 | xargs -0 grep -l "NullPointerException""*.java" -print0 | xargs -0 grep -l "NullPointerException"

Найти все Java-файлы, содержащие NullPointerException. -l указывает grep выводить только имена файлов, а не совпавшие строки.

Перезапуск списка сервисов:

echo -e "nginx\npostgres\nredis" | xargs -n 1 systemctl restart-e "nginx\npostgres\nredis" | xargs -n 1 systemctl restart

Массовое переименование файлов:

find . -name "*.jpeg" -print0 | xargs -0 -I {} bash -c 'mv "$1" "${1%.jpeg}.jpg"' _ {}"*.jpeg" -print0 | xargs -0 -I {} bash -c 'mv "$1" "${1%.jpeg}.jpg"' _ {}

Немного сложнее → используется -I {} и вложенная оболочка для выполнения преобразования строки, но при этом массовое переименование выражается одной строкой.

Подсчет количества строк в нескольких файлах:

find . -name "*.log" -print0 | xargs -0 wc -l"*.log" -print0 | xargs -0 wc -l

`xargs` или цикл `for`

Частый вопрос: когда следует использовать xargs, а когда цикл for?

Я бы использовал xargs, когда:

у вас есть список элементов из stdin, и вы хотите передать их команде;
вам нужно параллельное выполнение с помощью -P;
вам нужны лаконичные, легко комбинируемые однострочники.

И использовал бы цикл for, когда:

для каждого элемента нужна условная логика;
важна обработка ошибок для каждого элемента;
операция достаточно сложная, и читаемость важнее краткости.

xargs оптимизирована для производительности и комбинируемости. Циклы for оптимизированы для управления.

xargs делает только одну вещь: она преобразует stdin в аргументы.

Всё остальное — -I для размещения, -n для пакетной обработки, -P для параллелизма, -0 для безопасности — лишь управляет тем, как происходит это преобразование.

Как только это станет понятно, вы перестанете копировать xargs из Stack Overflow и начнете использовать её естественным образом. Она станет тем самым связующим звеном, которого вам не хватало между командами, формирующими вывод, и командами, ожидающими аргументы.

Именно тогда терминал начинает ощущаться по-настоящему управляемым.

Прощай, Docker: почему многие разработчики переходят на Podman

2026-07-28T07:32:31.719Z

Это перевод оригинальной статьи Bye Bye Docker: Why Many Developers Are Switching to Podman

Docker стал незаменимым инструментом для разработчиков. Он стал обязательным навыком в каждом наборе инструментов DevOps. Современные руководства по развертыванию почти всегда начинаются с Docker, и не без оснований: он сделал приложения портативными, воспроизводимыми и простыми для запуска где угодно.

Даже при развёртывании на виртуальных машинах (ВМ) или облачных серверах Docker часто играл центральную роль. Он стал фактическим стандартом — если вы серьёзно относились к DevOps, вам требовалось понимать Docker.

Но, как и любые технологии, всё развивается. И недавно возник насущный вопрос: остаётся ли Docker лучшим выбором?

О Podman

Дискуссия об альтернативах Docker набрала обороты, когда разработчики открыли для себя Podman. На первый взгляд, Podman выглядит практически идентично Docker: оба инструмента представляют собой инструменты управления контейнерами.

Различия кроются в их происхождении и философии:

Docker разработан компанией Docker Inc.
Podman разработан компанией Red Hat и использует другой подход к управлению контейнерами.

Самое приятное? Podman совместим с Docker. Те же команды, которые вы вводите в Docker (docker run, docker build, docker ps), работают и в Podman, а значит, вам не придётся переучивать свою мышечную память.

А для тех, кто предпочитает графический интерфейс, Podman предлагает Podman Desktop, зеркально отображающий рабочий стол Docker. С точки зрения удобства использования переход практически незаметен.

Изменение лицензии Docker Desktop

Настоящий переворот произошел 31 августа 2021 года, когда Docker Inc. объявила о существенном изменении лицензирования для Docker Desktop .

Согласно Соглашению о подписке на услуги Docker (2025), Docker Desktop остается бесплатным только для малых предприятий, которые соответствуют обоим следующим условиям:

Менее 250 сотрудников
Годовой доход менее 10 миллионов долларов США

Особые ограничения лицензии для автономного использования Docker Desktop.

Если организация превышает любой из порогов, для коммерческого использования требуется платная подписка.

Компания Docker предоставила компаниям льготный период до 31 января 2022 года для перехода. После этого предприятия, не соответствующие определению «малого бизнеса», должны будут платить за соблюдение требований.

Это стало поворотным моментом. Предприятия оказались перед выбором: либо взять на себя расходы по лицензированию, либо искать бесплатную, легальную альтернативу.

Проблема «полётов под радаром»

Некоторые команды подумывали просто проигнорировать новые правила: «Мы просто продолжим использовать Docker Desktop бесплатно. Кто это заметит?»

Но это рискованный шаг. Docker Desktop собирает телеметрию и данные об использовании, которые могут указывать на масштабное злоупотребление (например, когда тысячи пользователей на одном корпоративном IP-адресе всё ещё используют бесплатный тариф). Даже если это единичный случай, сочетание телеметрии и прав аудита делает контроль осуществимым, а риски, связанные с несоблюдением правил, весьма реальными.

Более того, лицензионное соглашение Docker прямо включает пункт об аудите , предоставляющий Docker право проверять записи для подтверждения соответствия требованиям с предварительным уведомлением не менее чем за 10 дней.

Соглашение о подписке на услуги Docker

Если тысячи сотрудников одной компании будут использовать бесплатную версию с одного корпоративного IP-адреса, это будет выглядеть подозрительно в данных телеметрии. Для предприятий это создаёт вполне реальный юридический и финансовый риск.

Вывод? Экономия средств с помощью Docker Desktop — неэффективная стратегия.

Преимущества Podman

Podman Desktop

Вот тут-то и появляется преимущество у Podman .

Бесплатно и с открытым исходным кодом
Распространяется по лицензии Apache, разрешающей неограниченное коммерческое использование.
Совместимость с Docker, поэтому разработчики могут повторно использовать знакомые команды
Поддерживается большим и активным сообществом разработчиков ПО с открытым исходным кодом

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

Внедрение Podman

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

Для развёртывания образы контейнеров по-прежнему собираются в соответствии со стандартами Docker (что обеспечивает совместимость с Kubernetes). Однако этапы сборки и тестирования можно легко запустить на Podman без проблем.

Этот гибридный подход позволяет компаниям избегать лицензионных сборов Docker Desktop и при этом сохранять бесперебойность производственных процессов.

Стоит ли вам менять подход?

Так стоит ли вам отказаться и от Docker?

Это зависит:

Если вы индивидуальный разработчик, студент или небольшой стартап , Docker Desktop по-прежнему бесплатен и безопасен для использования.
Но если вы работаете в крупной компании, переход на Podman будет более рациональным вариантом, поскольку он защитит вашу команду от юридических рисков и одновременно сократит расходы.

В конечном счёте, и Docker, и Podman — мощные инструменты контейнеризации. Разница заключается в моделях лицензирования и философии.

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

А вы? Вы всё ещё используете Docker или уже начали экспериментировать с Podman?

Мой полный набор нативных замен на MacOS в 2025 году

2026-07-28T07:23:04.749Z

Это перевод оригинальной статьи My Complete Native Replacements Stack on MacOS for 2025

Я заменил все стандартные приложения Apple — браузер, Spotlight, Notes, терминал — всё. Вот приложения, которые изменили мою работу.

Большинство пользователей довольствуются тем, что Apple дает им «из коробки», и понятия не имеют, насколько это их замедляет.

После многих лет, сотен испробованных приложений, бесконечных настроек и попыток убедить себя, что я действительно всё оптимизирую, я наконец-то «обточил» свой Mac до идеального минимума.

Вот полный набор приложений, который каждый день максимально ускоряет мою продуктивность.

#1: Safari → Brave

скриншот автора. спасибо Brave

Проблема: Chrome перегружен, а Safari закрыт и ограничен. Мне нужен был быстрый, гибкий браузер, который не отправлял бы все мои действия на чей-то рекламный сервер.

Моя замена: Brave — браузер на базе Chromium со встроенной блокировкой рекламы, настройками конфиденциальности и производительностью, которую Chrome потерял много лет назад. Я также попробовал Arc, который поначалу был неплох, но я так и не смог к нему привыкнуть.

Почему лучше: Brave даёт мне скорость Chrome без слежки. Он просто работает — чисто, быстро, без лишнего шума. Мне не нужно бороться с вкладками или производительностью. Я просто открываю нужное, делаю своё — и двигаюсь дальше.

#2: Apple Notes (общие заметки и исследования) → Obsidian

скриншот автора

Проблема: все приложения для заметок, которыми я пользовался, хотели сделать из меня администратора баз данных. Notion был слишком медленным. Apple Notes — слишком поверхностным. Мне хотелось чего-то, что позволило бы думать и проводить исследования глубоко. Я хотел, чтобы всё моё знание было в одном месте — в едином хранилище.

Моя замена: Obsidian — основанная на markdown «вторая память», которая работает локально, мгновенно синхронизируется и не привязывает вас ни к какой системе, кроме вашей собственной. Он бесплатный, с бесконечным количеством плагинов, безграничными возможностями настройки, бесплатной синхронизацией с Git и впечатляющими функциями для всех типов заметок.

Почему лучше: Он локальный и уважает ваш мозг. Вы пишете так, как думаете, без задержек, отвлечений и индикатора загрузки. Obsidian — это не холст. Это хранилище. Его также можно оптимизировать для чего угодно, будь то построение таблиц или ведение сложных математических заметок.

#3: Spotlight → Raycast

скриншот автора

Проблема: Spotlight медленный. Siri бесполезна. Finder перегружен. Мне нужен был более быстрый, плавный и мощный способ навигации по моему Mac.

Моя замена: Raycast — командный центр, управляемый с клавиатуры, который запускает приложения, управляет настройками, управляет историей буфера обмена и заменяет половину моей строки меню.

Почему лучше: Он не просто запускает приложения. Он запускает целый поток. Всё, что мне нужно, находится в одном нажатии клавиши. Raycast снова делает macOS настоящей операционной системой. Это приложение позволяет мне управлять всей системой из одного места, и это бесплатно.

Подробнее о Raycast можно узнать здесь .

#4: Apple Notes (написание текстов) → Ulysses

скриншот автора

Проблема: писать в Notes — всё равно что отправлять сообщения. Писать в Word — как наказание. Писать в Obsidian — это Markdown, который не самый лучший друг Medium. Мне нужно было пространство, созданное для настоящего письма, без шума и помех.

Моя замена: Ulysses — специализированная среда для написания текстов, которая упрощает создание черновиков, редактирование и публикацию. Мне нравится, что я могу просто скопировать текст, и всё форматирование автоматически перенесётся в браузер.

Почему лучше: Он понятный, структурированный и синхронизируется со всеми моими устройствами Apple. Он не мешает — а именно это и должно быть в приложении для письма. У него гибкая настройка и хорошее сообщество, которое создаёт множество замечательных тем.

#5: Собственная утилита для создания скриншотов от Apple → CleanShot X

скриншот автора

Проблема: скриншоты в macOS — это пещерная технология. Приходится вручную обрезать, сохранять на рабочий стол и перетаскивать куда-нибудь ещё. Это медленно, некрасиво и мучительно.

Моя замена: CleanShot X — профессиональный инструмент для создания скриншотов с мгновенным комментированием, размытием, закреплением на экране, записью видео, загрузкой в облако и работой с буфером обмена. Одно из моих самых любимых приложений на macOS.

Почему лучше: Скриншоты становятся средством общения. С CleanShot X я могу поделиться чем-то в Slack, отправить электронное письмо или записать запись в блоге за считанные секунды — и это будет выглядеть отлично.

Подробнее о CleanShotX.

#6: Поддержание Mac в активном режиме → Amphetamine

скриншот автора

Проблема: Мой Mac постоянно уходит в спящий режим в самый неподходящий момент — во время загрузок, рендеринга или выполнения сложных задач. Я хотел, чтобы он оставался в спящем режиме столько, сколько я скажу.

Моя замена: Amphetamine — лёгкая утилита, которая не даст вашему Mac заснуть именно тогда, когда вам нужно. Она бесплатная и очень удобная.

Почему лучше: Мне не нужно отключать сон глобально. Я настраиваю его для каждого приложения, каждой задачи, каждого сеанса. Амфетамин отлично справляется с одной задачей и не мешает остальному.

#7: Панель навигации Apple → Hidden Bar

скриншот автора. Благодарность Hidden Bar

Проблема: моя панель меню превратилась в мигающий хаос. Слишком много значков, слишком много отвлекающих элементов и вообще слишком много визуального беспорядка.

Моя замена: Hidden Bar — бесплатный инструмент, который позволяет скрывать и упорядочивать панель меню, не теряя функциональности.

Почему лучше: возвращает визуальное спокойствие. Я вижу только то, что важно. Всё остальное скрыто за одной вкладкой, там, где ему и место.

#8: Терминал: Terminal → Warp

скриншот автора

Проблема: Терминал macOS неплох. Но он мог бы быть гораздо лучше, по крайней мере, в плане эстетики.

Моя замена: Warp — клиент терминала, которого кто-то ненавидит, а кто-то любит. Думаю, он идеально мне подходит, потому что я использую терминал слишком примитивно.

Для меня эстетика и простота использования гораздо важнее, чем реальная функциональность. Я не бэкенд-разработчик и не системный администратор; я использую команду ls, открываю и создаю файлы, редактирую их в NeoVim и делаю резервные копии своего Obsidian через git.

Почему лучше: Автозаполнение, настраиваемые цвета, великолепный пользовательский интерфейс, функции ИИ, триггеры — превращает Warp в космический корабль.

Заключение

Apple даёт нам возможность создавать собственные наборы инструментов для повышения производительности. Я создал свой с нуля, и он помогает мне каждый день! Если хотя бы одна из этих замен сделает ваш ежедневный рабочий процесс более плавным, быстрым или увлекательным — я рад, что смог этим поделиться.

Vi / Vim Editor: Практические команды, которые должен знать каждый разработчик, системный администратор и DevOps-инженер.

2026-07-28T07:04:49.826Z

Это перевод оригинальной статьи Vi /Vim Editor : Practical commands every developer, sysadmin, and DevOps engineer should know..

Подписывайтесь на телеграм-канал usr_bin, где я публикую много полезного по Linux, в том числе ссылки на статьи в этом блоге

часто используемые команды редактора vi

Текстовый редактор vi существует уже несколько десятилетий, и тем не менее он остается одним из самых мощных и легковесных текстовых редакторов, доступных в любой Unix-подобной системе. Для разработчиков освоение его возможностей становится особенно важным. vi может стать решающим фактором между неуклюжим редактированием файлов и эффективной работой прямо в терминале.

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

1. Что такое `vi` редактор и почему он важен?

vi (сокращенно от visual editor ) — это текстовый редактор, встроенный в большинство систем Unix и Linux. Он известен своей высокой скоростью работы, ориентированностью на клавиатуру и доступностью практически на любой платформе. В отличие от графических редакторов или IDE, vi не использует мышь — все действия выполняются с помощью нажатий клавиш.

Для разработчиков, работающих по SSH-подключениям или администрирующих серверы без графического интерфейса, vi является основным инструментом. Если вы работаете с серверами, контейнерами Docker или облачными средами, vi это ваш лучший друг. Как только вы запомните основные команды, вы сможете редактировать быстрее, чем в большинстве графических редакторов.

2. Установка и настройка `vi` в Ubuntu

Большинство дистрибутивов Ubuntu поставляются с vim (Vi IMproved) — улучшенной версией vi, которая добавляет современные возможности, такие как подсветка синтаксиса и история отмены изменений.

Чтобы установить Vim, выполните:

sudo apt update
sudo apt install vim

Чтобы установить Vim в качестве редактора по умолчанию:

sudo update-alternatives --config editor

Выберите /usr/bin/vim.basic из списка и подтвердите.

Теперь вы можете открывать файлы с помощью:

vi filename.txt

3. Понимание режимов `vi`

В отличие от большинства редакторов, имеющих только режим «набора текста», Vim работает в нескольких режимах, каждый из которых предназначен для решения различных задач.
Переключение между ними может показаться поначалу непривычным, но именно в этом и заключается его мощь.

Обычный режим

Здесь вы проводите большую часть времени: навигация, удаление, копирование и вставка.
Если сомневаетесь, в каком режиме находитесь, нажмите дважды Esc, чтобы вернуться сюда. Экран может мигнуть или прозвучит звуковой сигнал для подтверждения.

Вставка

Здесь вы набираете или редактируете текст, как в обычном редакторе.
В режим вставки из обычного режима можно перейти тремя способами:

i -> Вставить перед курсором
a -> Вставить после курсора
o -> Вставьте новую строку ниже

Визуальный режим

Визуальный режим позволяет выделять текст и выполнять над ним операции.

v -> Начать визуальное выделение
V -> Выделить строки целиком
Ctrl + v -> Выделить прямоугольный блок (для редактирования столбцов)

После выделения вы можете удалить, скопировать или изменить отступ блока.

Режим командной строки

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

:w     -> Save
:q     -> Quit
:wq    -> Save and quit
:%s/foo/bar/g   -> Replace all 'foo' with 'bar'

Режим замены

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

Двоичный режим

Признаюсь — даже я не знал об этом до недавнего времени. Я наткнулся на эту возможность, изучая документацию vi (ссылка приведена ниже).

Вы можете открывать бинарные файлы (например, скомпилированные программы или изображения) с помощью команды:

vi -b file.bin

Вы также можете просматривать и редактировать байты в шестнадцатеричном виде с помощью:

:%!xxd

и вернуться обратно командой:

:%!xxd -r

4. Основные команды vi, которые вы будете использовать.

Ниже приведены некоторые из наиболее полезных команд, которые помогут оптимизировать процесс редактирования:

Навигация

h, j, k, l -> перемещение влево, вниз, вверх, вправо.
w -> Переход к началу следующего слова.
b -> Переход к началу предыдущего слова.
gg -> Переход в начало файла.
G -> Переход в конец файла.
:n -> Переход к строке номер n (например, :42).

Редактирование

i -> Вставка перед курсором.
a -> Вставка после курсора.
o -> Открыть новую строку ниже.
dd -> Удалить строку.
yy -> Скопировать строку.
p -> Вставьте ниже текущей строки.

Отмена и повтор

u -> Отменить последнее изменение.
Ctrl + r -> Повторить отмененное изменение.

Поиск

/word -> Выполнить поиск по слову вперед.
?word -> Выполнить поиск по слову назад.
nи N -> Повторить поиск вперед или назад.

Сохранение и выход

:w -> Сохранить изменения.
:q -> Выйти.
:wq или ZZ -> Сохранить и выйти.
:q! -> Принудительный выход без сохранения.

Полезный совет: комбинируйте действия для повышения скорости. Например, 3dd удаляет три строки, а 5y копирует пять строк. Когда вы войдёте в ритм, редактирование станет интуитивным.

Анимированный GIF-файл, демонстрирующий режим вставки.

Анимированный GIF-файл, демонстрирующий режим командной строки.

5. Полезные продвинутые приемы для разработчиков

Когда вы освоите основы, следующие приёмы сделают вашу работу с vi намного удобнее.

Поиск и замена:
Используйте :%s/foo/bar/g для замены всех вхождений слова «foo» на «bar».
Добавьте c в конце (:%s/foo/bar/gc) для подтверждения каждой замены — очень полезно при рефакторинге кода.

Отступы и форматирование:
Используйте >> для отступа строки и << для снятия отступа.
Для автоматического отступа блока визуально выделите его (v) и нажмите =.

Разделение экрана:
Нужно просматривать два файла одновременно?
Запустите команду :split filename для горизонтального разделения или :vsplit filename для вертикального.
Переключаться между окнами можно с помощью Ctrl + w + w.

Работа с буфером обмена:
Вы можете скопировать текст из Vim в системный буфер обмена с помощью "*yy и вставить его с помощью "*p.
Это особенно удобно при переключении между терминалом и браузером.

История отмены:
Хотели когда-нибудь вернуться в прошлое?
Используйте :earlier 5m, чтобы вернуть файл к состоянию пятиминутной давности, или :later 5m, чтобы снова переместиться вперёд.

Магия блочного редактирования:
Нажмите Ctrl + v, чтобы перейти в режим визуального блочного редактирования, выделите несколько строк и введите I#, чтобы добавить комментарии # ко всем выбранным строкам.
Нажмите Esc, и комментарий появится на каждой строке — это значительно экономит время.

Повтор последней команды:
Клавиша .(точка) повторяет ваше последнее действие.
Удалите слово один раз, нажмите ., и будет удалено следующее. Как только вы начнете этим пользоваться, это вызовет привыкание.

Заключение

Поначалу vi может показаться сложным, но освоение быстро окупается. Знание этого полезно каждому разработчику, особенно тем, кто работает с серверами, контейнерами Docker или облачными средами. Это быстро, надежно и всегда доступно.

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

Дополнительная литература

Если вы хотите узнать больше, чем просто базовые вещи:

Официальная документация Vim: https://vimhelp.org/
Шпаргалка по Vim (любимая у разработчиков): https://vim.rtorr.com
Руководство по GNU vi (для любителей истории): https://www.gnu.org/software/ed/manual/vi.html

Проверка логов Linux, которая спасла меня от скрытого сбоя (это должен знать каждый администратор)

2026-07-28T06:44:29.951Z

Это перевод оригинальной статьи The Linux Log Check That Saved Me from a Silent Outage (Every Admin Should Know This).

Большинство сбоев не начинаются с аварии.

Они начинаются с крошечного предупреждения, скрытого где-то в логах вашей системы, тихо сообщающего вам:

«Сейчас что-то сломается».

Как инженер по безопасности Linux, управляющий сотнями серверов в корпоративных средах, я усвоил одну вещь:

👉 Если вы успеете вы поймаете сигнал заранее, вы полностью избежите сбоя.
👉 Если вы его пропустите, вам придётся тушить пожар в 3 часа ночи.

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

🔧 Однострочная команда, предсказывающая 80% сбоев

Перед любым вмешательством в продакшн-систему я запускаю следующую команду:

grep -Ei "fail|error|warn|critical" /var/log/syslog | tail -50

Эта команда делает три вещи:

Сканирует на наличие наиболее опасных ключевых слов.
Сужает результат до последних 50 событий (чтобы не перегружать).
Точно отображает проблемы, о которых сигнализировала система.

Почему это работает

Потому что Linux всегда сообщает, когда что-то начинает ухудшаться:

Замедление дискового ввода-вывода
Давление на память
Нестабильная работа сервисов
Ошибки доступа
Нестабильность сети
Аномалии безопасности

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

🔥 Реальный пример: Скрытый сбой диска, который вот-вот взорвётся

Несколько месяцев назад во время моей предварительной проверки на сервере Ubuntu появилась следующая строка:

EXT4-fs warning: mounting fs with errors

Никаких алертов.
Никаких писем.
Ни одна система мониторинга не зафиксировала это.

Но эта единственная строчка мне сказала:

«Ваша файловая система вот-вот будет повреждена».

В течение 10 минут я перенёс рабочие нагрузки, выполнил полную проверку файловой системы и предотвратил катастрофический сбой.

А если бы я не проверил логи?
Этот сервер бы окончательно вышел из строя.

🛡️ Почему каждый DevOps-разработчик или бэкенд-инженер должен это делать

Большинство продакшн-сбоев можно разделить на три категории:

1️⃣ Деградация инфраструктуры

I/O errors  
OOM kills  
Network congestion  
Clock drift

2️⃣ Проблемы приложений

Service restarts  
Uncaught exceptions  
Deprecation warnings

3️⃣ Аномалии безопасности

Failed SSH attempts  
Permission denied errors  
Unexpected sudo usage

И все они оставляют следы в логах, до того, как станут реальной проблемой.

⚡ Сделайте его еще более впечатляющим: добавьте цвет и анализ частоты.

Вот проверка частоты логов, которую я использую при реагировании на инциденты:

grep -Ei "error|fail|critical" /var/log/syslog | \
awk '{print substr($0, index($0,$5))}' | \
sort | uniq -c | sort -nr | head -10

Здесь показаны наиболее часто повторяющиеся ошибки.

Отлично подходит для:

Приоритизации задач
Выявление шумных сервисов
Выявления трендов до их эскалации

🚨 Бонус: Привычка проверять логи безопасности, которую должен выработать каждый инженер.

Системные логи показывают сбои.
Логи аутентификации показывают злоумышленников.

Выполняйте это один раз в день:

grep -Ei "failed|invalid|root|denied" /var/log/auth.log | tail -30

Вы мгновенно обнаружите:

попытки перебора паролей по SSH
некорректные cron-задачи
злоупотребление правами sudo
Попытки несанкционированного доступа

Эта одна привычка позволяет обнаружить вторжение на ранней стадии, еще до того, как система регистрации и обнаружения вторжений (EDR) выдаст предупреждение.

🧠 Контрольный список, который я использую перед любым деплоем

Вы можете скопировать это в ваш внутренний runbook.

Контрольный список для подготовки к развертыванию (2 минуты):

🔍 Выполнить grep -Ei "fail|error|warn" по системным логам
🔥 Проверка логов аутентификации на предмет подозрительного поведения входа
🧠 Проверка частоты повторяющихся ошибок
🔧 Проверка перезапусков сервисов за последние 24 часа
📦 Убедиться, что место на дисках и inode в порядке
🛡️ Подтвердить отсутствие скрытых предупреждений ядра

Один только этот контрольный список предотвратил:

Сбои
Откаты
«Тушение пожаров» после развертывания
Нарушения безопасности, вызванные игнорируемыми аномалиями в логах.

📌 Заключительные мысли

Логи — это нервная система вашей инфраструктуры.

Инженеры, добивающиеся успеха в долгосрочной перспективе, — это не те, у кого лучшие панели мониторинга, а
те, кто умеет распознавать предупреждающие сигналы системы до того, как всё рухнет.

Если вы вынесете из этой статьи только одну мысль, пусть это будет следующее:

👉 Проверяйте свои логи до возникновения проблем, а не после.

Создание собственного портала мониторинга даркнета за 30 минут

2026-07-28T05:59:50.474Z

Это перевод оригинальной статьи Building a Self-Hosted Dark Web Monitoring Portal in 30 minutes.

В этой статье мы превратим локальную машину с Ubuntu в автоматизированный монитор даркнета. Он будет сканировать список целевых сайтов onion и размещать «страницу статуса», доступную через Tor, при этом не потребуется открывать ни одного порта на вашем домашнем маршрутизаторе.

Очевидно, это лишь первый шаг, с несколькими жестко заданными ONION-ссылками, которые отслеживаются. В следующей статье мы расширим это решение, чтобы получать список onion-ссылок из определённого репозитория и выполнять более автоматизированный мониторинг, с динамическим удалением и дополнительным сбором информации.

Этап 1: Усиление безопасности ОС

Поскольку эта машина находится в вашей локальной сети, нам необходимо обеспечить её защиту. В отличие от VPS, нам не нужно беспокоиться о проверках со стороны провайдера. Уровень защиты зависит от того, где вы размещаете сервер, поскольку в данном случае это локальная виртуальная машина, но она может работать буквально на любом облачном провайдере. Я использую облако OVH для всех своих нужд, связанных с VPS и выделенными серверами.

Сначала основы

Убедитесь, что ваша недавно установленная Ubuntu обновлена до последней версии.

sudo apt update && sudo apt upgrade -y

Далее: Создание пользователя-аналитика

Никогда не запускайте постоянные скрипты от имени root.

sudo adduser osint_lab
sudo usermod -aG sudo osint_lab
su - osint_lab

Брандмауэр

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

Мы настроим брандмауэр так, чтобы он разрешал доступ по SSH только из вашей локальной сети (LAN), чтобы вы могли управлять устройством из дома, но запрещал всё остальное. Вы также можете сделать это через такие сервисы, как ZeroTier, чтобы иметь возможность доступа и извне дома. Уже делал об этом видео, делюсь им здесь, хотя оно, конечно, нуждается в обновлении :).

Если у вас ещё не установлен ufw

sudo apt install ufw -y

Запретите весь входящий трафик по умолчанию

sudo ufw default deny incoming

Разрешите исходящий трафик (чтобы Tor мог взаимодействовать с сетью)

sudo ufw default allow outgoing

Разрешите SSH только из вашей локальной сети (замените 192.168.50.0/24 на вашу подсеть).

sudo ufw allow from 192.168.50.0/24 to any port 22

Включите брандмауэр

sudo ufw enable

Проверка: Попробуйте подключиться к вашему серверу по SSH с вашего ноутбука в той же сети, которую вы разрешили. Должно сработать. Попробуйте подключиться извне (если есть возможность) — соединение должно быть отклонено.

Скрытая сервисная инфраструктура

Нам нужно, чтобы Tor выполнял две задачи:

Прокси: позволял нашему Python-скрипту посещать сайты даркнета (SOCKS5h).
Хостинг: позволял публиковать отчёт как веб-сайт (скрытый сервис).

Установка Tor

sudo apt install tor nginx -y

Настройка Tor

Нам нужно отредактировать файл torrc, чтобы включить скрытый сервис.

sudo vi /etc/tor/torrc

Добавьте/раскомментируйте следующие строки:

Включите SOCKS-прокси для нашего скрипта сканирования.

SocksPort 9050

Настройка скрытой службы (Блог/Отчет)

HiddenServiceDir /var/lib/tor/onion_monitor/

HiddenServicePort 80 127.0.0.1:80

Примените изменения

Перезапустите Tor, чтобы сгенерировать ключи.

sudo systemctl restart tor

Узнайте свой адрес

Узнайте, какой у вас новый URL-адрес в даркнете:

sudo cat /var/lib/tor/onion_monitor/hostname

Сохраните этот адрес (например, v2xyz…onion). Именно по нему будет доступен ваш отчёт.

Этап 3: Среда Python

Мы будем использовать виртуальное окружение, чтобы изолировать зависимости.

sudo apt install python3-venv python3-pip -y
mkdir ~/dark-monitor
cd ~/dark-monitor
python3 -m venv venv
source venv/bin/activate
# Install libraries
# 'requests' for fetching pages
# 'pysocks' for routing through Tor
# 'stem' for controlling the Tor process
pip install requests pysocks stem

Скрипт сканера и публикации

Это короткий скрипт, который сканирует цели и генерирует статический HTML-файл, который может обслуживаться Nginx. Таким образом сканер превращается в живой блог. Вы можете использовать его и модифицировать под свои задачи.

Создайте файл scanner.py:

vi scanner.py

Вставьте этот код:

import requests
import socks
import socket
import datetime
import urllib3
import re
import time

# Suppress SSL warnings
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

# --- CONFIGURATION ---
OUTPUT_HTML = "/var/www/html/index.html"

# TARGET LIST
TARGETS =

# Configure Tor Proxy (Remote DNS Resolution)
PROXIES = {
    'http': 'socks5h://127.0.0.1:9050',
    'https': 'socks5h://127.0.0.1:9050'
}

HEADERS = {
    'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; rv:109.0) Gecko/20100101 Firefox/115.0'
}

def get_page_title(html_content):
    """Simple regex to extract the <title> tag"""
    try:
        match = re.search(r'<title>(.*?)</title>', html_content, re.IGNORECASE | re.DOTALL)
        if match:
            return match.group(1).strip()[:40]  # Truncate to 40 chars
    except:
        pass
    return "Unknown Title"

def check_site(url):
    try:
        start_time = time.time()
        # Timeout 60s
        resp = requests.get(url, proxies=PROXIES, headers=HEADERS, timeout=60, verify=False)
        latency = round(time.time() - start_time, 2)
        
        title = get_page_title(resp.text)
        
        if 200 <= resp.status_code < 300:
            return "UP", "green", f"{latency}s", title
        elif resp.status_code == 403:
            return "UP (Blocked)", "orange", f"{latency}s", "403 Forbidden"
        else:
            return "ISSUES", "orange", f"{latency}s", f"Status {resp.status_code}"
            
    except requests.exceptions.ConnectionError:
        return "DOWN", "red", "-", "Connection Failed"
    except requests.exceptions.Timeout:
        return "DOWN", "red", ">60s", "Timed Out"
    except Exception as e:
        return "ERROR", "red", "-", str(e)[:30]

def generate_report():
    # FIX: Get local time with correct Timezone Name (e.g., PST/CST)
    now = datetime.datetime.now().astimezone()
    timestamp = now.strftime("%Y-%m-%d %H:%M %Z")
    
    html_content = f"""
    <!DOCTYPE html>
    <html>
    <head>
        <title>Dark Web Observatory</title>
        <meta http-equiv="refresh" content="300"> 
        <style>
            body {{ font-family: 'Courier New', monospace; background: #0d0d0d; color: #e0e0e0; padding: 20px; }}
            h1 {{ color: #00ff00; text-transform: uppercase; border-bottom: 2px solid #333; padding-bottom: 10px; }}
            table {{ border-collapse: collapse; width: 100%; max-width: 1400px; margin-top: 20px; font-size: 0.9em; }}
            th, td {{ border: 1px solid #333; padding: 12px; text-align: left; vertical-align: middle; }}
            th {{ background-color: #1a1a1a; color: #fff; text-transform: uppercase; letter-spacing: 1px; }}
            tr:nth-child(even) {{ background-color: #111; }}
            a {{ color: #888; text-decoration: none; }}
            a:hover {{ color: #fff; text-decoration: underline; }}
         .green {{ color: #00ff00; font-weight: bold; background-color: #001a00; text-align: center; }}
         .orange {{ color: #ffa500; font-weight: bold; background-color: #1a1000; text-align: center; }}
         .red {{ color: #ff3333; font-weight: bold; background-color: #1a0000; text-align: center; }}
         .small {{ font-size: 0.85em; color: #999; }}
         .title-text {{ font-style: italic; color: #aaa; }}
        </style>
    </head>
    <body>
        <h1>/var/log/onion_status</h1>
        <p>Last Scan: {timestamp}</p>
        <table>
            <tr>
                <th style="width: 15%">Target Name</th>
                <th style="width: 35%">Onion Address</th>
                <th style="width: 8%">Status</th>
                <th style="width: 8%">Latency</th>
                <th style="width: 34%">Page Title / Error</th>
            </tr>
    """

    print(f"[*] Starting scan at {timestamp}")
    for target in TARGETS:
        print(f"  > Scanning {target['name']}...")
        status, color, latency, detail = check_site(target['url'])
        print(f"    Result: {status} ({latency}s)")
        
        html_content += f"""
            <tr>
                <td>{target['name']}</td>
                <td class="small"><a href="{target['url']}">{target['url']}</a></td>
                <td class="{color}">{status}</td>
                <td style="text-align: center;">{latency}</td>
                <td class="title-text">{detail}</td>
            </tr>
        """

    html_content += """
        </table>
        <p style="margin-top:50px; font-size: 0.8em; color: #555;">
            <i>Generated by Automated Local Sentinel (Ubuntu 25.04)</i>
        </p>
    </body>
    </html>
    """

    try:
        with open(OUTPUT_HTML, "w") as f:
            f.write(html_content)
        print(f"[*] Report successfully updated")
    except PermissionError:
        print("[!] Error: Cannot write to /var/www/html.")

if __name__ == "__main__":
    generate_report()

Исправление прав доступа

По умолчанию пользователь osint_lab не может записывать данные в /var/www/html. Давайте это исправим, чтобы наш скрипт мог обновлять веб-сайт.

sudo chown -R osint_lab:osint_lab /var/www/html

Автоматизация

Запускать каждый час.

crontab -e

Добавьте:

0 * * * * /home/osint_lab/dark-monitor/venv/bin/python3 /home/osint_lab/dark-monitor/scanner.py

Доступ к вашей обсерватории

Откройте браузер Tor на своем ноутбуке или телефоне.

Вставьте имя хоста, которое вы сгенерировали на предыдущих шагах.

Вы увидите свою собственную панель управления с автоматическим обновлением.

Я специально добавил несколько неправильных URL, чтобы показать различные статусы, которые вы будете получать. Это будет выглядеть примерно так:

12 инструментов командной строки, которые значительно ускорят вашу работу разработчика

2026-07-23T06:23:20.722Z

Это перевод оригинальной статьи 12 CLI Tools That Will Supercharge Your Developer Workflow.

Каждая команда должна работать на вас 🖥️
Инструменты командной строки ускоряют и упрощают рабочий процесс. Они помогают отлаживать код, управлять файлами, форматировать код и автоматизировать задачи, не выходя из терминала. Такие инструменты, как Ruff, pre-commit и pipx, обеспечивают согласованность проектов и изоляцию окружения, позволяя тратить больше времени на кодинг и меньше — на исправление проблем с настройкой.

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

1. Bat 🖥️

Bat заменяет стандартную cat, добавляя подсветку синтаксиса, нумерацию строк и интеграцию с Git для файлов кода. Это делает чтение файлов в терминале удобным и понятным.

bat app.py

В терминале вы получаете подсветку синтаксиса по цветам, нумерацию строк и подсветку изменений Git прямо в терминале.

Если нужен простой вид.

bat --style=plain app.py

стиль простой

Почему мне нравится: Bat превращает отладку скриптов Python в увлекательное занятие, сравнимое с листанием прекрасно иллюстрированной книги.

GitHub - sharkdp/bat: A cat(1) clone with wings.

A cat(1) clone with wings. Внесите свой вклад в разработку sharkdp/bat, создав учетную запись на GitHub.

github.com

2. tldr 📘

tldr предлагает краткие, основанные на примерах объяснения команд вместо длинных и сложных справочных страниц. Идеально подходит для быстрого напоминания и освоения новых инструментов.

tldr tar

Вы сразу видите часто используемые команды tar для распаковки или сжатия файлов, без необходимости листать страницы документации.

Почему мне это нравится: если коротко, то это похоже на полезного наставника, показывающего только самое необходимое для выполнения задач.

tldr

Упрощенные и созданные сообществом справочные страницы (man pages)

tldr.sh

3. eza📂

eza модернизирует ls, добавляя цвета, иконки и интеграцию с Git. Это делает вывод списка файлов визуально понятным и информативным прямо в терминале.

eza -l --git

источник — документ eza

Вы получаете информацию о правах доступа к файлам, размеры, даты изменения и статус Git — всё в одном удобном представлении.

Почему мне это нравится: eza делает навигацию по каталогам похожей на прогулку по хорошо организованной галерее.

GitHub — eza-community/eza: современная альтернатива ls

Современная альтернатива команде ls. Внесите свой вклад в разработку eza-community/eza, создав учетную запись на GitHub.

github.com

4. Ruff ⚡

Ruff — это сверхбыстрый линтер и форматтер для Python, написанный на Rust. Он практически мгновенно проверяет ваш код на стилевые ошибки, неиспользуемые импорты и проблемы форматирования.

ruff check temp-api/

Он сканирует весь ваш проект за считанные секунды и может автоматически исправить большинство проблем.

Почему мне это нравится: Ruff молниеносно проходит по моим проектам, поддерживая код чистым и единообразным, не замедляя работу.

Ruff ⚡

Чрезвычайно быстрый линтер и форматтер кода для Python, написанный на Rust.

docs.astral.sh

5. pre-commit 🔒

pre-commit выполняет автоматические проверки перед каждым коммитом Git, выявляя такие проблемы, как ошибки форматирования, проблемы с линтингом или утечки секретных данных.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files

  - repo: https://github.com/psf/black
    rev: 24.3.0
    hooks:
      - id: black

Ниже приведены команды, необходимые для работы с этой конфигурацией:

pre-commit install
pre-commit run --all-files

Это позволит выполнить все настроенные хуки trailing-whitespace, end-of-file-fixer, check-yaml, check-added-large-files и black для каждого файла в репозитории.

Почему мне это нравится: pre-commit защищает мою команду от проблем с неаккуратным кодом, предотвращая некорректные коммиты до их совершения.

pre-commit

pre-commit.com

6. cookiecutter🍪

Начинать проект с нуля — утомительно. Cookiecutter генерирует шаблоны проектов одной командой.

cookiecutter gh:cookiecutter/cookiecutter-django

Ответьте на несколько вопросов, и вы получите готовый к работе Django-проект. Он работает как сборник рецептов по программированию, экономя часы на настройке.

Почему мне это нравится: cookiecutter — это мой быстрый способ создания API или CLI за считанные минуты.

Cookiecutter: Better Project Templates — документация к версии 2.6.0

Cookiecutter создает проекты на основе шаблонов проектов (cookiecutters), например, проекты пакетов Python на основе шаблонов пакетов Python…

cookiecutter.readthedocs.io

7. ⚡ hyperfine

Хотите узнать, какой скрипт работает быстрее? Hyperfine проводит бенчмаркинг команд с подробной статистикой.

hyperfine 'sleep 0.3' 'sleep 0.4'

Программа запускает тесты несколько раз и показывает среднее время, стандартное отклонение и сравнения. Это как секундомер для терминала, идеально для оптимизации.

Почему мне это нравится: hyperfine помогает мне точно настраивать инструменты без догадок.

GitHub - sharkdp/hyperfine: инструмент для командной строки для бенчмаркинга

Инструмент для бенчмаркинга в командной строке. Присоединяйтесь к разработке sharkdp/hyperfine, создав учетную запись на GitHub.

github.com

8. lazygit📋

Команды Git могут показаться запутанными. lazygit предоставляет терминальный интерфейс для удобной навигации по коммитам, веткам и изменениям.

lazygit -p PROJECT PATH

Нажмите ? для получения справки, добавьте файлы в индекс с помощью пробела и зафиксируйте изменения с помощью клавиши c. Это как иметь панель управления Git прямо в терминале.

Почему мне это нравится: lazygit упрощает работу со сложными репозиториями.

GitHub - jesseduffield/lazygit: простой терминал для команд Git

Простой терминал для команд Git. Внесите свой вклад в разработку jesseduffield/lazygit, создав учетную запись на GitHub.

github.com

9. pipx📦

pipx устанавливает и запускает Python CLI-приложения в изолированных средах, не засоряя основной Python.

pipx install black
black script.py

Запускайте такие инструменты, как black, flake8, или httpie, безопасно где угодно.

Почему мне это нравится: pipx поддерживает чистоту моего глобального Python-кода, при этом используя лучшие инструменты.

10. entr📝

entr следит за файлами и запускает команды при их изменении. Идеально подходит для автоматического тестирования, пересборки или запуска скриптов на лету.

ls *.py | entr -r python main.py

При каждом изменении файла .py ваш скрипт автоматически перезапускается.

Почему мне это нравится: entr превращает повторяющиеся ручные операции в полностью автоматизированные рабочие процессы, не требующие участия пользователя.

11. httpie⚡

httpie — это инструмент командной строки для выполнения HTTP-запросов с понятным синтаксисом и форматированным выводом. Идеально подходит для тестирования API.

http GET https://api.github.com/repos/python/cpython

Он автоматически форматирует JSON-ответы, упрощая отладку вызовов API.

Почему мне это нравится: httpie делает взаимодействие с API быстрым и удобным для пользователя, без лишних сложностей curl.

12. glow📊

Glow отображает Markdown в терминале с цветами, таблицами и ссылками. Идеально подходит для чтения документации, не выходя из командной строки.

glow README.md

Читайте файл README или документацию вашего проекта непосредственно в терминале. Также можно получать разметку Markdown по протоколу HTTP.

glow https://raw.githubusercontent.com/fastapi/fastapi/master/README.md

Почему мне это нравится: Glow делает чтение Markdown приятным прямо во время кодинга, без необходимости открывать редактор.

Эти инструменты командной строки упрощают разработку, автоматизируя проверки, организуя файлы и ускоряя выполнение рутинных задач. Используйте hyperfine для тестирования производительности, lazygit для упрощения работы с Git и glow для чтения документации без переключения окон.

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

10 ключевых концепций Docker, которые я хотел бы, чтобы мне объяснили в первый день

2026-07-23T06:20:06.487Z

Это перевод оригинальной статьи 10 Essential Docker Concepts I Wish Someone Explained to Me on Day One.

Когда я только начинал изучать Docker, все говорили мне одно и то же: «Это просто. Изучи образы и контейнеры». Но никто не объяснил, насколько перегруженно выглядит Docker, когда у тебя ещё нет целостной картины. Образы, контейнеры, тома, реестры, сети, Compose — каждый термин звучит изолированно, и в учебных пособиях их часто объясняют как карточки, а не как единую систему.

По-настоящему понял Docker только тогда, когда перестал запоминать команды и начал строить ментальные модели. Docker — это не магия. Это очень продуманный способ упаковки программного обеспечения, его перемещения и надежного запуска где угодно. В этой статье я поделюсь тем, как теперь объясняю Docker новичкам — те объяснения, которые мне самому хотелось бы получить, когда я только начинал.

Воспринимайте это как объяснение концепций Docker от опытного инженера, написанное на доске, а не как описание на странице документации.

1. Docker-образы: это шаблоны, а не запущенные программы

Первая ошибка, которую допускают новички, — думать, что образ уже что-то выполняет. Это не так.

docker build -t my-python-app:1.0 .

Образ Docker — это замороженный шаблон вашего приложения. Он содержит всё необходимое для работы приложения — код, среду выполнения, библиотеки, системные инструменты и параметры конфигурации по умолчанию — но сам по себе ничего не делает.

Мне нравится представлять образ Docker как карточку с рецептом из ресторана. В ней перечислены ингредиенты, этапы и инструкции. Вы можете сделать тысячу копий, но пока вы не приготовите блюдо, ничего не произойдет. Именно этап приготовления — это и есть контейнер.

Сила образов заключается в их неизменяемости. После создания они никогда не меняются. Именно эта неизменяемость является настоящей причиной того, почему Docker так хорошо работает в продакшене. Если один и тот же образ работает на моем ноутбуке, на тестовом сервере и на продакшене, то оправдание «у меня все работало» перестает быть оправданием.

Эта идея неизменяемости (immutability) встречается повсюду в современных системах. Я на собственном опыте видел, во что обходится её игнорирование — в том числе клиент, который терял тысячи долларов в месяц из-за «безопасных» архитектурных решений, не понимая поведения системы во время выполнения.

Образы Docker решают задачи одной и той же категории: предсказуемость в масштабе.

2. Контейнеры: запущенные экземпляры шаблона.

Если образ — это шаблон, то контейнер — это запущенный экземпляр этого шаблона.

docker run -d -p 8000:8000 my-python-app:1.0

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

Вот важная часть, которую большинство руководств обходят стороной:

👉 Вы можете запускать множество контейнеров на основе одного и того же образа, и они не будут мешать друг другу.

Так работает современное масштабирование. Вместо того чтобы создавать один гигантский сервер, вы запускаете десять идентичных контейнеров за балансировщиком нагрузки. Если один из них выходит из строя, вы его заменяете. Никакой эмоциональной привязанности.

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

Как только вы это поймете, Kubernetes тоже станет понятным — это всего лишь планировщик для контейнеров, а не какая-то загадочная штуковина.

3. Docker-файлы: контракт для вашей среды выполнения

Dockerfile — это не просто скрипт настройки. Это контракт.

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["python", "app.py"]

Он явно отвечает на вопрос:

«Что должно существовать для того, чтобы моё приложение работало?»

Когда вы пишете Dockerfile, вы документируете свои предположения в исполняемой форме.

Каждая инструкция в Dockerfile существует потому, что когда-то что-то сломалось без неё. Отсутствующие системные библиотеки. Неправильная версия Python. Зависимость, которая работала локально, но не работала в CI. Dockerfile пишутся кровью прошлых инцидентов.

4. Слои образа: почему скорость сборки вдруг начинает иметь смысл

Слои образов — одна из самых недооцененных идей Docker.

Каждая строка в Dockerfile создает слой, и Docker активно кэширует эти слои. Если в слое ничего не меняется, Docker повторно использует его вместо пересборки.

Это объясняет, почему порядок выполнения команд в Dockerfile так важен. Зависимости изменяются реже, чем код приложения, поэтому вы устанавливаете их перед копированием исходного кода. Когда вы изменяете один файл Python, Docker не переустанавливает все — он просто перестраивает последние несколько слоев.

Как только вы разберетесь с многоуровневой архитектурой, медленные сборки Docker перестанут казаться случайными. Они становятся задачей проектирования, которую можно оптимизировать.

5. Тома: контейнеры одноразовые, данные — нет.

Вот горькая правда:

👉 Контейнеры предназначены для удаления.

Если удаление контейнера пугает вас, потому что вы потеряете данные, ваша архитектура неправильная.

docker run -d \
  -v postgres-data:/var/lib/postgresql/data \
  postgres:15

Тома Docker существуют для того, чтобы отделить среду выполнения от состояния. Том существует вне жизненного цикла контейнера. Вы можете бесконечно уничтожать и создавать контейнеры заново, в то время как ваши данные будут спокойно существовать.

Это особенно важно для баз данных. Если ваш контейнер с Postgres выходит из строя, но том остается, вы не потеряли данные — вы потеряли только процесс.

docker run -d \
  -v $(pwd):/app \$(pwd):/app \
  -p 8000:8000 \
  my-python-app:1.0

Как только вы это осознаете, вы перестаете относиться к серверам как к питомцам и начинаете относиться к ним как к скоту. Этот сдвиг мышления является фундаментом cloud-native подхода.

6. Docker Hub: Магазин приложений для инфраструктуры

Docker Hub — это просто реестр, место, где хранятся образы.

docker search redis

Но с культурной точки зрения он ближе к магазину приложений. Вместо того чтобы вручную устанавливать Redis или PostgreSQL, вы загружаете проверенный, версионированный образ, поддерживаемый экспертами, которые занимаются этим на постоянной основе.

docker pull redis:7-alpine

Это меняет подход к работе команд. Вы договариваетесь использовать redis:7-alpine и переходите к решению бизнес-задач.

docker tag my-python-app:1.0 username/my-python-app:1.0

docker push username/my-python-app:1.0

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

7. Docker Compose: Когда системы становятся реальностью

Одиночные контейнеры полезны для обучения. Compose — это место, где начинается реальность.

version: '3.8'

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://postgres:secret@db:5432/myapp
      - REDIS_URL=redis://cache:6379
    depends_on:
      - db
      - cache
    volumes:
      - .:/app
  
  db:
    image: postgres:15-alpine
    volumes:
      - postgres-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=myapp
  
  cache:
    image: redis:7-alpine

volumes:
  postgres-data:

В тот момент, когда вашему приложению требуется база данных, кэш и воркеры, Docker Compose становится незаменимым инструментом. Он позволяет описать всю вашу систему — сервисы, сети, тома, переменные окружения — в одном файле.

Compose — это не просто инструмент для удобства. Это общая ментальная модель для команд. Любой может клонировать репозиторий и запустить всю систему локально, без необходимости обладать какими-либо специфическими знаниями.

docker-compose down

docker-compose up -d --build

Идея воспроизводимости системы локально — именно то, с чем крупные компании испытывают трудности в масштабе.

8. Сетевое взаимодействие контейнеров: Имена вместо IP-адресов

Работа с сетью в Docker кажется сложной, пока вы не поймете одну вещь:

👉 Контейнеры общаются друг с другом по именам, а не по IP-адресам.

Docker обрабатывает DNS внутри. Если ваш сервис называется db, ваше приложение подключается к db:5432. Никаких статических IP-адресов. Никаких догадок.

docker network create my-app-network
docker run -d --network my-app-network --name api my-python-app:1.0
docker run -d --network my-app-network --name cache redis:7

Эта небольшая абстракция устраняет целый класс ошибок конфигурации. Она также отражает принцип работы обнаружения сервисов в производственных системах, таких как Kubernetes.

Изоляция — это второе важное преимущество. Контейнеры в разных сетях не могут взаимодействовать, если вы явно этого не разрешите. Безопасность по умолчанию лучше, чем безопасность, обеспечиваемая документацией.

docker network ls

docker network inspect my-app-network

9. Переменные окружения и секреты: код — это не конфигурация.

Если вы когда-либо случайно коммитили API-ключ, этот раздел вызывает неприятные воспоминания.

Docker способствует четкому разделению кода и конфигурации. Ваш образ остается одинаковым во всех средах. Меняются только переменные окружения и секреты.

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

Такой подход — отделение стабильных элементов от нестабильной конфигурации — повсеместно встречается в зрелых системах.

10. Реестры контейнеров: собери один раз, запускай везде

Приватный реестр контейнеров — это последний элемент пазла.

Вместо сборки кода на производственных серверах (медленно и рискованно), вы выполняете сборку один раз в CI, загружаете образ в реестр и загружаете его везде. Этот единственный образ становится вашей развертываемой единицей.

Именно так современные CI/CD-пайплайны остаются быстрыми, воспроизводимыми и безопасными.

Когда команды пропускают этот шаг, развертывания снова становятся «снежинками» — каждый сервер немного отличается, каждый релиз превращается в риск.

В заключение: Docker — это система, а не инструмент.

Docker не так уж сложен, если перестать воспринимать его как набор команд.

Это система для упаковки предположений, их безопасного перемещения и предсказуемого выполнения. Образы, контейнеры, тома, сети, реестры — все это части одной истории.

Если вы сегодня изучаете Docker, не спешите переходить к Kubernetes. Сначала упакуйте простое приложение в контейнер. Добавьте базу данных с помощью Compose. Ломайте всё. Удаляйте контейнеры без страха. Так приходит понимание Docker.

Когда это происходит, вся остальная облачная экосистема внезапно становится гораздо менее загадочной.