Как IT-специалисту зарабатывать больше?
Вторая работа 😄
Реферальная программа 👍

Реферальная программа Cloud․ru — это возможность получать стабильный доход, рекомендуя облачные сервисы. За каждого привлеченного клиента вы получаете процент от суммы его чеков, а клиент — бонусные рубли.

Сейчас — лучшее время, ведь действуют специальные условия:
1️⃣ Присоединяетесь к программе до 30 сентября
2️⃣ Приводите первых клиентов
3️⃣ Получаете до 20% от суммы их чеков весь год

Стать партнёром в пару кликов🖱

Управление процессами: больше, чем kill -9

Многие админы по привычке бьют зависшие процессы командой kill -9. Работает — но далеко не всегда это лучший выбор.

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

Основные сигналы

⏺SIGTERM (15) — «пожалуйста, завершись». Корректно останавливает процесс, давая ему время сохранить данные и закрыть соединения. Это дефолтный сигнал для kill без параметров.
⏺SIGHUP (1) — исторически «разрыв связи». Сегодня часто используется для перечитывания конфигурации демона без полного рестарта (например, nginx -s reload).
⏺SIGSTOP — полностью останавливает процесс (приостанавливает выполнение), но не убивает его. Можно потом возобновить SIGCONT. Удобно для отладки.
⏺SIGKILL (9) — жёсткий «убийца». Процесс завершается немедленно, без шанса на сохранение состояния. Использовать только если остальные способы не сработали.

kill, killall и pkill
• kill <PID> — отправляет сигнал по PID.
• killall <имя> — убивает все процессы с указанным именем. Удобно, но осторожно: можно случайно снести лишнее.
• pkill -f <шаблон> — более гибкий поиск по имени или аргументам процесса. Например:

pkill -HUP nginx   # мягкий перезапуск nginx
pkill -9 python    # убить все процессы Python

💬 Вопрос на собеседовании для сисадмина

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

❓Вопрос: Что такое OOM-killer в Linux и как он работает?

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

Алгоритм учитывает “OOM score” процесса: чем выше его потребление памяти и чем меньше его “важность” для системы, тем выше вероятность, что именно он будет завершён. Администратор может влиять на этот выбор с помощью параметра oom_score_adj.

Почему netstat лжёт: как ss показывает реальную картину с сокетами

В современном Linux часто применяются инструменты для мониторинга сетевых соединений.

Несмотря на свою популярность, утилита netstat уже не всегда предоставляет точную информацию о состоянии сокетов.

Неточное отображение состояний с netstat

Netstat долгое время был основным инструментом для вывода информации о сетевых соединениях, но его алгоритмы и подходы к сбору статистики имеют ограничения:

⏺Netstat опирается на данные из /proc, которые могут не отражать динамическое изменение состояния сокетов. В результате он часто показывает устаревшую информацию, например, “мертвые” или заброшенные сокеты, которые уже не участвуют в активной передаче.

⏺При анализе состояний, таких как FIN_WAIT2, netstat может некорректно интерпретировать “зависшие” соединения. Это может ввести администратора в заблуждение относительно истинной загрузки и стабильности системы.

Преимущества ss: точные и детальные данные

Современный инструмент ss (socket statistics) из пакета iproute2 разработан для замены netstat и предоставляет гораздо более подробную и актуальную информацию о сетевых сокетах.

Он способен отсеивать “мертвые” соединения, корректно отображать переходные состояния и использовать расширенные опции для фильтрации и диагностики.

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

ss -tan

Здесь ключи означают:
• -t – вывести только TCP-соединения,
• -a – показать все (слушающие и установленные),
• -n – вывод номеров портов в числовом виде.

Если вам нужно проверить, какие сокеты находятся в “FIN_WAIT2” состоянии, команда ss покажет их корректно, благодаря более точной сборке данных из ядра:

ss -tan state fin-wait-2

Особенно полезна опция -K. Этот параметр позволяет отправлять запросы к ядру для получения более глубокого анализа по каждому сокету – например, чтобы определить, какие “зависшие” сокеты реально не используются.

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

ss -K state established

Эта команда попытается “убить” (удалить) неактивные или ошибочные соединения, предоставляя отчёт о том, какие сокеты останутся в системе после вмешательства. Такой уровень контроля невозможен с netstat.

🎉Linux исполнилось 34 года

25 августа 2025 года Linux отметила 34-летие.

В 1991 году студент Хельсинкского университета Линус Торвальдс создал ядро «для хобби», а сегодня оно управляет миллиардами устройств — от смартфонов до суперкомпьютеров, от МКС до марсоходов.

Первый пост Торвальдса в группе comp.os.minix остался в истории: он писал, что делает ОС «просто ради интереса» и не обещает многого. Через несколько месяцев Linux уже могла запускать bash и gcc.

Сегодня проект поддерживают тысячи разработчиков по всему миру. Только в 2024 году на разработку ядра ушло $6,8 млн, а в июле 2025 года вышло Linux 6.16 под кодовым названием Baby Opossum Posse.

⏺Торвальдс уверяет: формального плана преемственности нет и не нужно — сообщество само найдёт «следующего великодушного повелителя».

SSH Multiplexing и ControlMaster

Быстрее подключение к серверу без лишних рукопожатий

По умолчанию каждый вызов ssh открывает новый TCP-сокет, проходит ключевое рукопожатие, обмен алгоритмами, аутентификацию. Это безопасно, но затратно по времени.

Multiplexing решает проблему: первая сессия открывает основной канал (master), а все остальные используют его.

Для этого в OpenSSH есть опции ControlMaster, ControlPath и ControlPersist.

Настройка

1️⃣ Создаём папку под сокеты:

mkdir -p ~/.ssh/sockets
chmod 700 ~/.ssh/sockets

2️⃣ Добавляем в ~/.ssh/config:

Host myserver
    HostName 192.168.1.10
    User admin
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 10m

Проверка в реальной работе

Первый запуск (идёт полная авторизация):

time ssh myserver exit

Обычно ~0.4–0.6 сек.

Второй запуск (через мастер-сессию):

time ssh myserver exit

Результат: 0.02 сек. Почти мгновенно.

То же с scp:

scp test.txt myserver:/tmp/

Файл начинает копироваться без задержки.

LVM snapshots: быстрые бэкапы и откаты

LVM (Logical Volume Manager) позволяет работать с томами гибче, чем с обычными разделами.

Одна из ключевых возможностей — снапшоты: копия состояния тома в определённый момент времени.

Это полезно для бэкапов и экспериментов: можно сохранить снимок, обновить систему или базу, и при ошибке — откатиться.

Практика

1️⃣Проверяем тома

lvdisplay

Находим имя LV, например vg0/data.

2️⃣ Создаём снапшот

lvcreate -L 5G -s -n data_snap /dev/vg0/data

• -L 5G — размер для изменений (чем больше активность, тем больше нужно).
• -s — создаём снапшот.
• -n — имя снапшота.

3️⃣ Монтируем снапшот

mkdir /mnt/snap
mount /dev/vg0/data_snap /mnt/snap

Теперь можно сделать копию файлов без остановки сервиса.

4️⃣ Откат к снапшоту
Если после обновлений что-то пошло не так:

umount /dev/vg0/data
lvconvert --merge /dev/vg0/data_snap
reboot

После перезагрузки том вернётся к состоянию снапшота.

5️⃣ Удаление снапшота
Когда копия больше не нужна:

lvremove /dev/vg0/data_snap

RAID уровня выше 5

Почему админы выбирают RAID10 или ZFS вместо RAID6

RAID5 и RAID6 долгое время считались «золотым стандартом» для балансировки между надёжностью и экономией диска.

Но с ростом объёмов накопителей и нагрузок они стали проблемными.

Минусы RAID6 при больших дисках:

1️⃣Восстановление после сбоя (rebuild) может занимать сутки и больше. Всё это время массив работает медленнее и под угрозой.
2️⃣ Чем больше диски, тем выше шанс ошибки чтения (URE) во время rebuild. В худшем случае массив падает целиком.
3️⃣ Запись требует вычисления чётности, что сильно режет IOPS.

Почему выбирают RAID10: RAID10 сочетает зеркалирование и страйпинг. Это даёт простую архитектуру и высокую скорость.

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

Почему выбирают ZFS

ZFS идёт дальше классического RAID:

⏺каждая операция проверяется контрольной суммой, что защищает от silent data corruption;
⏺встроены снапшоты и репликация;
⏺пулы расширяются гибко, без жёстких ограничений железного RAID-контроллера;
⏺RAIDZ позволяет балансировать между избыточностью и ёмкостью, при этом сохраняя контроль над целостностью.

💬 Вопрос на собеседовании для DevOps-инженера

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

❓Вопрос: Что такое Memory Overcommit в Linux и какие риски с ним связаны?

✅Ответ: Memory Overcommit — это возможность ядра Linux разрешать процессам выделять больше виртуальной памяти, чем физически доступно в системе.

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

LVM snapshots: пример с PostgreSQL

В прошлый раз я показал, как снапшоты LVM позволяют быстро «замораживать» состояние тома. 

Теперь разберём практическое применение — резервное копирование PostgreSQL без остановки сервиса.

Снапшоты работают по принципу copy-on-write: при изменении данных в оригинальном томе старая версия сохраняется в снапшоте.

⏺Чтобы результат был хорошим, нужно принудительно записать все буферы базы на диск.

sudo -u postgres psql -c "CHECKPOINT;"
sync

Шаги бэкапа

1️⃣Создать снапшот:

lvcreate -L 2G -s -n pgdata_snap /dev/vg0/pgdata

2G — примерный размер под изменения на время копирования.

2️⃣ Смонтировать снапшот:

mkdir /mnt/pgsnap
mount /dev/vg0/pgdata_snap /mnt/pgsnap

3️⃣ Скопировать файлы:

rsync -a /mnt/pgsnap/ /backup/pgdata-$(date +%F)/

4️⃣ Очистить:

umount /mnt/pgsnap
lvremove /dev/vg0/pgdata_snap

SSH к Cisco без пароля: настройка через RSA-ключи

SSH-аутентификация по ключам давно стала стандартом в Linux/Unix-мире, а Cisco IOS (и NX-OS) поддерживает её ещё с начала 2000-х.

Основное преимущество ключей перед паролями:

⏺невозможно перебрать брутфорсом (если ключ длинный),
⏺админ не хранит пароли в заметках/Excel,
⏺удобно централизованно управлять доступом: добавил или удалил ключ в pubkey-chain — и доступ сразу появился/пропал.

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

При подключении клиент доказывает владение приватным ключом, а Cisco сравнивает это с публичным — если совпадает, вход разрешён.

В отличие от классической схемы логин+пароль, тут нет ввода секретов в консоль, поэтому утечка через keylogger или сниффинг невозможна (при условии, что приватный ключ защищён паролем).

Практика

1️⃣Включаем SSH на Cisco

conf t
ip domain-name lab.local
crypto key generate rsa modulus 2048
ip ssh version 2

2️⃣Создаём пользователя

username admin privilege 15 secret StrongPass123

3️⃣Подтягиваем публичный ключ
На клиенте:

ssh-keygen -t rsa -b 2048

Копируем содержимое ~/.ssh/id_rsa.pub и добавляем на Cisco:

ip ssh pubkey-chain
  username admin
   key-string
    ssh-rsa AAAAB3... user@host
   exit
 exit

4️⃣Ограничиваем доступ только по ключам

line vty 0 4
 transport input ssh
 login local

Теперь при подключении:

ssh admin@router

пароль не нужен.

Нюансы

⏺Можно завести нескольких пользователей с разными ключами.
⏺При увольнении сотрудника ключ просто удаляется из pubkey-chain → не надо менять общий пароль.
⏺Минимальный размер ключа лучше 2048, а в проде — 4096 бит.
⏺Рекомендовано всегда включать только SSHv2 — SSHv1 давно небезопасен.