Какой будет ваш первый шаг при диагностике падающего продакшен-сервера?

А, слушай, смотри, вот тебе как в бою действовать, когда всё ебнулось. Забудь про глубокий анализ на первые пять минут — твоя задача номер один: чтобы пользователи, эти ненасытные твари, хоть что-то видели, а не белую страницу или спиннер до скончания веков.

План действий, когда уже пиздец:

1. Быстрая разведка (2-5 минут, не больше, а то выебутся) Первым делом — понять, дышит ли эта штука вообще. Не надо в логи лезть, сначала просто пнуть.

# Тыкаем палкой
ping server-prod.example.com
curl -I https://api.example.com/health
nc -zv server-prod.example.com 443

# Глянем, что health endpoint бормочет
curl -s https://api.example.com/health | jq '.status, .timestamp, .version'

Если тут уже curl: (7) Failed to connect или пинг летит в тартарары — всё, приехали, переходим к пункту 2. Если health хрипит, но отвечает — уже пол-дела.

2. Включить режим «Хуй с ним, но работает» (Graceful Degradation) Если в архитектуре заложен фолбэк — включай его, не стесняйся. Лучше упрощённая версия, чем полный пиздец.

# Включаем щадящий режим (типа «мы знаем, что всё плохо»)
./scripts/enable_maintenance_mode.sh --soft

# Если есть резервные копии сервиса — перекидываем трафик туда. Проблемный — нахуй.
kubectl scale deployment/app --replicas=0  # Гробим проблемный
kubectl scale deployment/app-backup --replicas=5  # Поднимаем запасных

3. Сбор улик (быстро, без фанатизма) Теперь, пока резервы разворачиваются, собираем, что плохо лежит.

Системные метрики — вдруг сервер просто сдох:

# Заскочим на сервер одним махом
ssh prod-server "
  echo '=== CPU ==='; top -bn1 | head -5; 
  echo '=== Memory ==='; free -h; 
  echo '=== Disk ==='; df -h; 
  echo '=== Network ==='; ss -tulpn | head -20"

# Если есть прометеус — дергаем оттуда
curl -H "Authorization: Bearer $PROMETHEUS_TOKEN" 
  "https://monitoring.example.com/api/v1/query?query=node_memory_Active_bytes{instance='prod-server'}"

Логи — ищем крик души:

# Последние сто строк, только самое сочное (ERROR, FATAL)
tail -100 /var/log/app/error.log | grep -E "(ERROR|CRITICAL|FATAL|Exception)" | head -20

# Или через journalctl за последние 5 минут
journalctl -u app-service --since "5 minutes ago" --no-pager | tail -50

# Классика: ищем OutOfMemory или Segmentation fault
grep -A5 -B5 "OutOfMemoryError|Segmentation fault|Connection refused" /var/log/app/app.log

4. Проверка «друзей» сервиса Может, он и не виноват, а его кореша-зависимости его подставили.

# База данных жива?
psql -h db-prod -U app_user -d app_db -c "SELECT 1 as db_ok;"
redis-cli -h redis-prod PING

# Внешние API отвечают?
curl -m 5 https://payment-gateway.example.com/health
curl -m 5 https://auth-service.example.com/ready

# Очереди не забились?
rabbitmqctl list_queues name messages_ready messages_unacknowledged | head -10
kafka-topics --bootstrap-server kafka-prod:9092 --list

5. Быстрые пинки (Quick Wins) Иногда помогает просто пнуть систему.

Перезапуск (если не страшно):

# Культурный рестарт
sudo systemctl restart app-service --with-health-check
# Или контейнер
docker restart app-container --time 30
kubectl rollout restart deployment/app

Почистить хвосты:

# Может, кэш засиделся
redis-cli -h redis-prod FLUSHALL
# Или временные файлы говном заросли
find /tmp -name "app_*" -mtime +1 -delete
# Воркер завис — дёрнем его
supervisorctl restart celery-worker:*

6. Страхуем жопу и зовём подмогу

# Делаем слепок состояния на случай, если всё полетит к чертям
./scripts/create_debug_snapshot.sh --server=prod-server --output=incident_$(date +%s).tar.gz

# И орем в общий чат / алерт-систему
curl -X POST -H "Content-Type: application/json" 
  -d '{"priority":"high","service":"app","message":"Prod server degradation detected"}' 
  https://alerts.example.com/notify

Вот, например, если веб-сервер лег:

#!/bin/bash
# Быстрая дичь для Nginx/Apache

SERVER="prod-web-01"
LOG_DIR="/var/log/nginx"

echo "=== Быстрая диагностика для $SERVER ==="

# 1. Он вообще жив?
ssh $SERVER "ps aux | grep -E '(nginx|apache|httpd)' | head -10"
# 2. Порты слушает?
ssh $SERVER "netstat -tulpn | grep :80|:443"
# 3. На что ругается?
ssh $SERVER "tail -50 $LOG_DIR/error.log | grep -v 'favicon.ico' | head -20"
# 4. Конфиг не сломан?
ssh $SERVER "nginx -t 2>&1 || apachectl configtest 2>&1"
# 5. Соединения есть?
ssh $SERVER "ss -s | grep -A5 'Total:'"
# 6. Быстренько дёрнем локально
if [[ $? -eq 0 ]]; then
    echo "n=== Локальный тест на вшивость ==="
    timeout 10 siege -c10 -t5s https://$SERVER/health 2>/dev/null | 
        grep -E '(Transaction rate|Failed transactions|Response time)'
fi

Шпаргалка по симптомам:

• Сыпятся 5xx ошибки? Смотри логи приложения, потом БД/кэш, потом лимиты памяти.
• Всё охуенно медленно? CPU, медленные запросы в БД, сетевая задержка между микросервисами.
• Полный труп (404/Connection refused)? Ping, traceroute, firewall, DNS. Банально, но работает.

Главные правила, ёпта:

1. Не охуей. Методичность важнее хаотичного тыкания. Записывай, что делаешь.
2. Кричи в народ. Держи команду в курсе. Пользователей — если долго.
3. Имей путь к отступлению. Прежде чем что-то менять, знай, как откатиться.
4. Проверь на стейджинге. Если нашел фикс, не втыкай его сразу в прод, как мудак.

Когда всё устаканилось (ну, вроде бы):

# Собери улики для разбора полётов
./scripts/collect_forensic_data.sh --since="2 hours ago"

# Создай тикет в жире
jira create-incident --title="Prod server degradation $(date)" 
  --priority=P1 --assignee=devops-team

# Назначь постмортем, чтобы не повторялось
echo "Разбор полётов завтра в 10:00. Без опозданий." | 
  mail -s "Разборки по инциденту" team@example.com

Вот и вся магия. Не геройствуй, действуй по плану, и есть шанс выйти сухим из этой, блядь, воды.