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

Моя стратегия тестирования падающего сервера

При обнаружении падающего сервера я начну с систематического анализа, чтобы избежать хаотичных действий. Мой подход основан на модели OSI/сетевой модели и принципах устранения неполадок снизу вверх (от инфраструктуры к приложению).

1. Экспресс-диагностика и первичный сбор данных

Первым делом я выполню быструю проверку доступности, чтобы подтвердить проблему и собрать контекст:

# Проверка доступности сервера по ICMP (если разрешено)
ping -c 5 server_ip_or_hostname

# Проверка доступности конкретных TCP-портов (например, 80, 443, 8080)
nc -zv server_ip 80
nc -zv server_ip 443
telnet server_ip 8080

# Проверка DNS-разрешения (если используется доменное имя)
nslookup example.com
dig example.com

Одновременно я запрошу у команды или системы мониторинга:

• Время первого падения и периодичность (случайно или регулярно)
• Предшествующие изменения (деплой, конфигурационные правки, обновления ОС)
• Связанные инциденты в других компонентах системы

2. Проверка инфраструктурного уровня

Я сосредоточусь на базовых ресурсах, так как их исчерпание — частая причина падений:

# Проверка использования CPU (на самом сервере или через мониторинг)
top -n 1
htop

# Анализ памяти и swap
free -h
vmstat 2 10

# Проверка дискового пространства и I/O
df -h
iostat -x 2 5

# Анализ сетевых подключений и ошибок
netstat -tulpn
ss -s

Ключевые метрики, которые я проверю:

• Загрузка CPU выше 80-90% продолжительное время
• Нехватка памяти или активное использование swap
• Заполнение дисков (особенно /var, /log, корневой раздел)
• Исчерпание inodes, файловых дескрипторов или сетевых сокетов

3. Анализ логов и процессов

При наличии доступа к серверу я немедленно исследую логи в хронологическом порядке:

# Просмотр системных логов (формат зависит от ОС)
tail -100 /var/log/syslog
journalctl -u service_name --since "10 minutes ago" -f

# Проверка логов приложения (если известно расположение)
tail -200 /var/log/app/error.log
grep -i "error\|exception\|fatal\|panic" /var/log/app/app.log | tail -50

# Поиск упавших процессов и анализ core dumps
ps aux | grep defunct
ls -la /var/core/ 2>/dev/null

4. Тестирование компонентов приложения

Если инфраструктура стабильна, проблема может быть в самом приложении:

# Проверка состояния веб-сервера (пример для Nginx)
systemctl status nginx
nginx -t  # проверка конфигурации

# Тестирование зависимостей (БД, кэш, внешние API)
# Для БД PostgreSQL:
pg_isready -h localhost -p 5432

# Проверка доступности внутренних портов приложения
curl -I http://localhost:8080/health
curl http://localhost:8080/metrics  # если есть эндпоинт метрик

5. Воспроизведение и углубленная диагностика

На этом этапе я попытаюсь воспроизвести проблему в контролируемых условиях:

• Нагрузочное тестирование для проверки пределов capacity
• Тестирование отказоустойчивости (отключение зависимостей)
• Анализ конфигураций на предмет ошибок или изменений

# Пример простого скрипта для проверки доступности с интервалами
import requests
import time
from datetime import datetime

def check_server_availability(url, interval=5, attempts=20):
    for i in range(attempts):
        try:
            response = requests.get(url, timeout=3)
            print(f"{datetime.now()}: Status {response.status_code}")
        except Exception as e:
            print(f"{datetime.now()}: ERROR - {type(e).__name__}")
        time.sleep(interval)

# Использование
check_server_availability("http://example.com/health")

6. Документирование и эскалация

Весь процесс я документирую в виде:

• Хронологии событий и предпринятых действий
• Собранных логов и метрик (до и после инцидента)
• Гипотез о корневой причине

Если проблема требует глубокой экспертизы (баг в коде, сложная конфигурация БД), я эскалирую к соответствующим специалистам (разработчикам, DevOps, администраторам БД), предоставляя им полный контекст.

Такой системный подход позволяет не просто "перезапустить и забыть", а выявить корневую причину (root cause), что критически важно для предотвращения повторных инцидентов и повышения стабильности системы в долгосрочной перспективе.