🐧 Linux · 20 вопросов · ~45 мин · ⏱ Таймер 45:00 · Сложный · 👥 2 прошли

Авария на сервере: найдите причину

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

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. На 20 вопросов отведено 45 минут. Не меньше половины заданий требуют разобрать команды, сценарий Bash, конфигурацию или диагностический вывод. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и краткий разбор каждого решения.

Вопрос 1 из 20

Сайт начал отдавать 500, диск /var показывает 100%. Какой первый шаг полезнее удаления файлов?

date --iso-8601=seconds
df -h /var; df -i /var
findmnt /var
sudo lsof +L1 /var | head
du -xhd1 /var | sort -h

Снять df, du, findmnt и список открытых удалённых файлов до очистки Сразу расширить раздел, не проверяя причину роста и точку монтирования Перезапустить службы, чтобы они закрыли файлы, не сохраняя исходное состояние Удалить самые большие журналы и только потом выяснять, что занимало место

Вопрос 2 из 20

Служба упала сразу после deploy. Что сохранить до restart?

systemctl status app --no-pager
systemctl cat app
systemctl show app -p Result -p ExecMainStatus -p ExecStart -p Environment
journalctl -u app -b -n 200
pid=$(systemctl show app -p MainPID --value)
ps -o pid,ppid,user,lstart,args -p "$pid"
readlink -f /srv/app/current

Сохранить status, journal, фактический unit, параметры процесса и версию релиза Вернуть прошлый релиз до фиксации состояния, чтобы быстрее восстановить сервис Очистить журнал, затем повторить запуск и собирать только новые сообщения Сохранить только страницу ошибки, потому что серверные данные появятся после перезапуска

Вопрос 3 из 20

На 16-ядерном сервере load average вырос до 30, доля user CPU мала, а iowait высок. Какой набор фактов лучше проверит гипотезу об ожидании ввода-вывода?

vmstat, iostat и список процессов в состоянии D с полем wchan ss -s и число соединений в TIME_WAIT free -h и сведения об использовании swap top с сортировкой только по доле пользовательского CPU

Вопрос 4 из 20

После подозрительного входа по SSH что важно зафиксировать первым?

date --iso-8601=seconds
w; last -ai | head
ps auxf
ss -tpn
journalctl -u ssh --since '2 hours ago'

Сразу завершить все новые процессы, не фиксируя их аргументы и соединения Отключить сеть и удалить журналы аутентификации, чтобы злоумышленник их не изменил Сменить host key и имя сервера до сохранения журналов Зафиксировать сеансы, процессы, сетевые соединения, журнал входов и временную линию

Вопрос 5 из 20

Пользователь сообщает «всё медленно», но мониторинг нормален. Что собрать?

Снимок top, сделанный через несколько минут после жалобы Только скриншот ошибки без точного времени запроса Точное действие, время, request id и повторяемость Среднюю загрузку сервера за сутки и список всех пакетов

Вопрос 6 из 20

df /var 100%, du /var 40%. Какая проверка лучше различит открытый удалённый файл и скрытые данные под mount?

sudo lsof +L1 /var
findmnt -R /var

Проверить только df -h и увеличить раздел при наличии свободного места в группе томов Повторить du без -x, чтобы включить все вложенные файловые системы Сопоставить lsof +L1 и findmnt, проверяя удалённые открытые файлы и скрытые данные под mount Остановить все службы и рекурсивно изменить права /var, чтобы du увидел больше файлов

Вопрос 7 из 20

Домен не открывается, но curl по IP работает. Какой следующий тест лучше?

getent ahosts app.example
dig app.example A +short
curl -v --resolve app.example:443:203.0.113.20 https://app.example/

Проверить DNS-ответ и выполнить curl --resolve, сохранив нужные Host и SNI Сразу менять сертификат, потому что обращение по IP уже работает Проверить кэш браузера и локальный файл hosts только на клиенте Сравнить маршрут до IP и до DNS-сервера, не проверяя имя приложения

Вопрос 8 из 20

Nginx отдаёт 502. Какой тест различит отказ соединения и плохой ответ приложения?

Перезапустить Nginx: если 502 исчезнет, upstream можно не проверять Увеличить proxy_read_timeout до нескольких минут и считать причину найденной Сделать прямой запрос к upstream и сопоставить его с точной строкой error_log Проверить только access.log, не обращаясь к приложению напрямую

Вопрос 9 из 20

Процесс использует 100% одного CPU. Как проверить busy loop и нормальную вычислительную работу?

pidstat -u -p "$pid" 1
sudo perf top -p "$pid"

Сразу послать SIGKILL, чтобы исключить влияние процесса на сервер Увеличить swap, поскольку высокая загрузка одного CPU обычно означает нехватку памяти Снять профиль стеков и проверить, продвигается ли полезная работа процесса Повысить nice и сравнить общую загрузку через пятнадцать минут

Вопрос 10 из 20

SSH стал недоступен после изменения sshd_config, но существующий сеанс ещё открыт. Что делать?

sudo sshd -t
sudo sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication)'
ssh -p 22 localhost true

Закрыть текущий сеанс и проверить новый вход после перезагрузки Отключить StrictHostKeyChecking у клиентов и повторить соединение Удалить authorized_keys, чтобы исключить конфликт способов входа Выполнить sshd -t, проверить новый параллельный вход и лишь затем делать reload

Вопрос 11 из 20

На файловой системе есть свободные гигабайты, но touch возвращает No space left on device. Где локализовать проблему?

df -h /srv/cache
df -i /srv/cache
find /srv/cache -xdev -type f | wc -l

Проверить lsof +L1: удалённые открытые файлы удерживают место Проверить df -h: возможно, заняты именно блоки данных Проверить квоту пользователя: она может ограничивать запись Проверить df -i: вероятно, исчерпан запас inode

Вопрос 12 из 20

Службу убивает OOM при свободной памяти на хосте. Что локализовать?

Проверить глобальные счётчики OOM в журнале ядра Проверить объём tmpfs, не связывая его с cgroup службы Проверить MemoryMax= и memory.events cgroup конкретного unit Проверить ulimit -v только в интерактивной оболочке администратора

Вопрос 13 из 20

HTTPS timeout только для больших ответов, маленькие проходят. Где вероятнее искать?

tracepath app.example
ping -M do -s 1472 app.example

Проверить число inode, поскольку крупный HTTP-ответ создаёт больше временных файлов Проверить тайм-аут service unit, который ограничивает размер TCP-сегмента Проверить PMTU, MTU и прохождение ICMP Packet Too Big на рабочем маршруте Проверить права сертификата, потому что большой ответ требует повторного чтения ключа

Вопрос 14 из 20

Nginx возвращает 504 ровно через 60 секунд, а журнал приложения показывает, что обработка запроса длится 75 секунд. Что следует из этих данных?

В TCP keepalive между клиентом и Nginx Timeout находится в proxy, исходная задержка — в upstream Только в proxy_read_timeout: приложение при этом работает без задержки В таймауте браузера, который Nginx передал upstream

Вопрос 15 из 20

systemd показывает active (running), но порт отсутствует. Что локализовать?

systemctl show app -p Type -p MainPID -p SubState
ss -lntp 'sport = :8080'
journalctl -u app -b -n 100

Считать active достаточным доказательством готовности приложения Проверить MainPID, журнал и фактический bind/listen процесса Перезапустить unit с повышенными правами, не выясняя, какой процесс считается основным Проверить только is-enabled: выключенная автозагрузка объясняет отсутствие порта у active-unit

Вопрос 16 из 20

После неудачного релиза current указывает на v9, а v8 был рабочим. Какое восстановление наименьшего радиуса?

test -x /srv/app/releases/v8/bin/app && \
ln -sfn releases/v8 /srv/app/current.new && \
mv -Tf /srv/app/current.new /srv/app/current

Удалить каталог v9 и запускать приложение прямо из v8 без проверки Изменить права всего дерева /srv, чтобы новая версия смогла запуститься Переустановить пакеты приложения поверх обоих релизов Проверить v8 и атомарно переключить current обратно на него

Вопрос 17 из 20

Большой log удалён, но место не вернулось. Как безопаснее освободить его?

Перезагрузить сервер, не устанавливая, какой процесс удерживает inode Создать файл того же имени, чтобы файловая система переиспользовала старые блоки Попросить процесс переоткрыть журнал либо перезапустить только эту службу Удалить соответствующий дескриптор из /proc/PID/fd вручную

Вопрос 18 из 20

База повреждена, есть snapshot и backup. Как действовать?

# clone/snapshot -> /restore
# database recovery/checks
# read-only validation
# controlled cutover

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

Вопрос 19 из 20

Firewall-правило случайно закрыло SSH, но консоль доступна. Как восстановить с минимальным риском?

Через консоль временно разрешить SSH только с административного адреса и проверить доступ Отключить проверку host key у клиентов, не меняя правила фильтрации Открыть SSH всему интернету на короткое время, полагаясь на пароль Очистить весь набор правил и позднее восстановить его по памяти

Вопрос 20 из 20

После восстановления сайт отвечает 200 на /health. Что ещё нужно до закрытия инцидента?

curl -fsS https://app/health
# затем read/write canary, queue depth, error rate, backup freshness

Проверить данные, ключевые операции, очереди, фоновые задания и стабильность под наблюдением Проверить только главную страницу через тот же локальный health-check Закрыть инцидент: один ответ 200 подтверждает данные, фоновые задания и зависимости Удалить путь отката, чтобы случайно не вернуться к старой версии

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу