С чего ты начнешь тестирование падающего сервера?

Мой алгоритм действий при падении сервера направлен на быструю локализацию проблемы:

1. Проверка доступности и базового состояния:

   • Выполню ping до хоста, чтобы проверить сетеую доступность.
   • Использую curl или telnet для проверки доступности конкретного порта и эндпоинта (например, health-check).

     curl -v -m 5 http://server:8080/health
     # Или проверить только код ответа:
     curl -s -o /dev/null -w "%{http_code}" http://server:8080/api/v1/status

2. Анализ логов: Это основной источник информации. Подключусь к серверу или в систему централизованного логирования (ELK Stack, Loki, Cloud Logging) и изучу логи приложения за последние несколько минут.

   # Поиск ошибок и исключений в лог-файле
   tail -n 100 /var/log/app/application.log | grep -E "(ERROR|Exception|FAILED)"
   # Просмотр логов контейнера Docker
   docker logs --tail 50 --timestamps <container_id>

3. Проверка метрик и ресурсов: Открою дашборды в системах мониторинга (Grafana, Prometheus, Zabbix). Посмотрю на:

   • Утилизацию CPU, памяти, дискового пространства (возможно, диск переполнен).
   • Количество активных потоков/процессов.
   • Статус сборщика мусора (для JVM-приложений).
   • Количество ошибок в логах и failed-запросов.

4. Проверка зависимостей: Убежусь, что все внешние сервисы, от которых зависит падающий сервер, доступны: база данных, кэш (Redis), брокер сообщений (Kafka, RabbitMQ), другие микросервисы.

5. Воспроизведение: Если проблема неочевидна, попробую воспроизвести её в тестовом окружении, сымитировав те же условия (данные, нагрузку, конфигурацию), что и на продакшене. Это помогает безопасно экспериментировать с фиксами.