Системный администратор в 2026: Linux, сети и облака

Сначала ограничить аварию, потом искать красивую причину

Работа системного администратора во время инцидента начинается не с любимой команды, а с границ проблемы. Что сломано для пользователя, когда началось, какие узлы и сегменты затронуты, что недавно менялось? Сравнение исправного и неисправного пути обычно полезнее общего осмотра сервера. Если сбой появился только на новых узлах после выпуска, остановите дальнейшее развёртывание и выведите проблемные экземпляры из балансировки. Так команда уменьшает ущерб и сохраняет данные для диагностики.

Следующий шаг — проверить наблюдение на одном запросе. Имя разрешается? TCP-соединение устанавливается? TLS-обмен заканчивается? Приложение отвечает и обращается к зависимости? Запишите точное время, адреса, идентификатор запроса и результат каждого слоя. Формулировка «сеть иногда висит» не даёт точки проверки. Формулировка «новые узлы сбрасывают соединение сразу после TLS ClientHello, старые при том же клиенте отвечают» уже отделяет маршрут от конфигурации TLS или процесса.

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

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

Linux: процесс видит числа, контексты и открытые дескрипторы

Процесс, запущенный вручную, и служба systemd работают в разных условиях. У unit могут отличаться пользователь, рабочий каталог, переменные окружения, ограничения ресурсов, порядок зависимостей и доступ к файлам. Поэтому проверяют systemctl status, журнал нужного запуска, User, Group, Environment, WorkingDirectory и зависимости unit. Успешная команда из интерактивной оболочки root не доказывает, что служба получит те же права и конфигурацию.

После переноса локального каталога ошибка Permission denied требует проверки числовых UID и GID — идентификаторов пользователя и группы, обычных битов доступа, ACL и контекста SELinux или AppArmor. Совпадающее имя пользователя на экране ещё не гарантирует одинаковый UID. Проверять нужно каждый каталог пути: процессу требуется право прохода по родительским каталогам, а не только запись в конечный файл. Для локальной файловой системы здесь не нужно начинать с сетевого экспорта или правил облачного хранилища.

Ротация журнала иллюстрирует разницу между именем файла и открытым объектом. Если файл удалили или переименовали, процесс может продолжать писать через старый файловый дескриптор, пока не переоткроет журнал. Место занято, хотя путь уже не виден обычным ls. Связь находят по открытым удалённым файлам, после чего безопасно заставляют приложение переоткрыть лог или перезапускают его с учётом влияния. Создание нового файла с прежним именем не переключит старый дескриптор.

Сеть диагностируют по месту, где обрывается обмен

Если сервис доступен по IP, но не по имени, сначала проверяют фактическую DNS-запись, используемый DNS-резолвер, кэш и область поиска. Если имя разрешается верно, переходят к соединению. SYN без ответа ведёт к маршруту и фильтрации; установленный TCP с ошибкой TLS — к сертификатам, протоколам и настройке приложения; HTTP 503 — к сервису или его зависимостям. Такое движение по фактам экономит время и не позволяет менять сразу DNS, firewall и приложение.

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

Доступность из одной подсети и таймаут из другой требуют сравнить прямой и обратный путь. Проверяют таблицы маршрутов, policy routing — правила выбора маршрута по источнику или метке, сетевые ACL, firewall и трансляцию адресов. Ответ может уходить через другой интерфейс и отбрасываться из-за асимметрии. Открытый порт на межсетевом экране узла не гарантирует внешний доступ: перед узлом могут стоять облачная security group, NACL, балансировщик и маршрут к неверному адресу.

Особый симптом — маленькие ответы проходят, а большие зависают после установленного соединения. MTU — максимальный размер пакета на участке сети; PMTUD — обнаружение допустимого MTU по всему пути. Если промежуточный участок не пропускает крупный пакет, а сообщения ICMP Fragmentation Needed для IPv4 или Packet Too Big для IPv6 блокируются, стороны не уменьшают размер. Проверяют MTU интерфейсов и туннелей, MSS в TCP, пакетную трассу и прохождение нужного ICMP, а не просто увеличивают таймаут приложения.

Высокий load average при слабой занятости CPU тоже требует перевода симптома. В Linux в нагрузку входят задачи, ожидающие CPU, и некоторые задачи в непрерываемом ожидании, часто дискового или сетевого ввода-вывода. Поэтому смотрят состояния процессов, задержки диска, очередь I/O и ошибки ядра. Добавлять процессоры до этой проверки бессмысленно: узким местом может быть зависший том, а новый CPU лишь оставит больше мощности без работы.

Облако: сеть и разрешение операции — разные проверки

Ответ объектного хранилища 403 AccessDenied означает, что запрос дошёл до API и был отклонён на уровне разрешения. До изменения маршрута проверьте фактическую учётную запись процесса: роль VM или pod, временные учётные данные и срок их действия. Затем разберите запрошенное действие, область ресурсов, политику роли, политику ресурса и явные запреты. Успешная авторизация другим профилем с ноутбука не доказывает права приложения на сервере.

Обратный случай — таймаут до API без HTTP-ответа. Тогда проверяют DNS, маршрут, сетевой адрес API, security group, NACL и прокси. Эти ветки нельзя смешивать: добавление IAM-разрешений не исправит отсутствующий сетевой путь, а открытие сети не отменит явный запрет. В портфолио и на интервью называйте наблюдаемый ответ перед гипотезой. Это показывает, что решение следует из слоя сбоя, а не из списка знакомых облачных настроек.

Массовое изменение на ста серверах проводят через систему управления конфигурацией. Изменение должно быть идемпотентным: повторный запуск приводит к тому же состоянию, а не накапливает правки. Сначала применяют изменение к малой пробной группе, проверяют сервисную метрику и дрейф, затем расширяют охват. Ручная команда по SSH быстрее только до первого пропущенного узла, неизвестного состояния или необходимости доказать, что настройка действительно одинакова.

Восстановимость и разбор, который меняет систему

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

Разбор инцидента не заканчивается фразой «усилить мониторинг». Корректирующее действие должно менять условие, позволившее сбою повториться: добавить проверку схемы, ограничить доступ, автоматизировать проверку на пробной группе или регулярно испытывать восстановление. Для действия назначают владельца, срок и проверку эффективности. Например, мало установить предупреждение о дублях purchase: через месяц нужно подтвердить, что тестовый повтор блокируется, а время обнаружения реального дубля сократилось.

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