Какие шаги следует предпринять, если сервер выходит из строя и перестает отвечать?

Что хотят услышать интервьюеры:

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

Определение:

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

Пример использования:

Типичный сценарий: веб-приложение на Python перестало отвечать на запросы.

1. Проверяют доступность хоста: ping, ssh, health-check.
2. Смотрят состояние сервиса и логи приложения.
3. Анализируют нагрузку: CPU, память, диск, сеть.
4. Если сервис завис, перезапускают его или переключают трафик на резервную ноду.
5. Проверяют, не связан ли сбой с последним релизом или внешним API.
6. После восстановления фиксируют причину и добавляют мониторинг/алерт.

# Проверка доступности и состояния сервиса
ping server.example.com
ssh user@server.example.com
systemctl status myapp
journalctl -u myapp --since "10 min ago"

# Быстрая диагностика ресурсов
top
df -h
free -m

Пояснение кода:

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

Разбор примера по шагам:

1. ping помогает понять, отвечает ли сервер на сетевом уровне.
2. ssh показывает, доступна ли машина для администрирования.
3. systemctl status myapp позволяет проверить, запущен ли нужный сервис.
4. journalctl и логи приложения помогают увидеть ошибку: падение процесса, нехватку памяти, исключение в коде.
5. top, df -h, free -m помогают выявить типичные причины: перегрузку CPU, заполнение диска, нехватку RAM.
6. После диагностики принимается решение: перезапуск, откат, масштабирование или переключение на резерв.

Ключевые моменты:

• Начинать нужно с быстрой диагностики: сеть, хост, сервис, логи, ресурсы.
• Не стоит сразу перезапускать всё подряд: важно сначала понять причину сбоя.
• Если есть резервирование, лучше сначала переключить трафик, а уже потом разбираться с узлом.
• После восстановления обязательно провести root cause analysis и зафиксировать инцидент.
• Полезно заранее иметь мониторинг, алерты, health-check и план аварийного восстановления.
• Для Python-сервиса важно отдельно проверять утечки памяти, зависшие воркеры, ошибки внешних зависимостей и последствия последних деплоев.