Как будешь анализировать проблему с сервисом?

Методология анализа проблем с сервисом

Это фундаментальный скилл DevOps и backend инженера. Есть систематический подход, который работает всегда.

Этап 1: Сбор информации

Что-то сломалось. Первый вопрос: что именно?

# Запиши симптомы:
- Когда началось? (время, дата)
- Какие пользователи затронуты? (все или конкретная группа)
- Какое поведение? (500 ошибки, медленный ответ, зависание)
- Воспроизводится ли на тестовом окружении?

Примеры плохих информаций:

• "Сервис упал" — слишком расплывчато
• "API не работает" — какой эндпоинт?
• "Медленно" — 100мс или 10 секунд?

Этап 2: Проверка инфраструктуры

# 1. Работает ли сервис?
docker ps | grep service_name
pkg-get status service_name
pgrep -a python | grep app

# 2. Слушает ли порт?
netstat -tlnp | grep 8000
lsof -i :8000

# 3. Сетевая доступность
curl -v http://localhost:8000/health
ping service.domain.ru

# 4. Ресурсы
top
df -h  # диск
free -h  # память

Этап 3: Проверка логов

# Docker контейнер
docker logs -f container_name --tail 100

# Systemd сервис
journalctl -u service_name -n 100 -f

# Приложение
tail -f /var/log/app.log

# Grep по ошибкам
grep -i "error\|exception\|traceback" /var/log/app.log | tail -50

Что ищешь в логах:

• Stack trace (тип исключения)
• Когда произошла ошибка
• На каком коде
• Контекст (user_id, request_id, параметры)

Этап 4: Логирование в коде

# Хорошее логирование помогает анализировать
import logging
from pythonjsonlogger import jsonlogger

logger = logging.getLogger(__name__)
handler = logging.StreamHandler()
formatter = jsonlogger.JsonFormatter()
handler.setFormatter(formatter)
logger.addHandler(handler)

# В коде
def process_payment(user_id, amount):
    logger.info("payment_started", extra={
        "user_id": user_id,
        "amount": amount,
        "timestamp": datetime.now().isoformat()
    })
    
    try:
        result = payment_gateway.charge(user_id, amount)
        logger.info("payment_success", extra={"result": result})
        return result
    except PaymentError as e:
        logger.error("payment_failed", extra={
            "error": str(e),
            "user_id": user_id
        })
        raise

Этап 5: Проверка зависимостей

# База данных
psql -h db.host -U user -d dbname -c "SELECT 1"
mysql -h db.host -u user -p dbname -e "SELECT 1"

# Redis/Memcached
redis-cli ping
telnet cache.host 11211

# Очереди
# RabbitMQ
rabbitmqctl status

# Kafka
kafka-broker-api-versions.sh --bootstrap-server localhost:9092

Этап 6: Проверка конфигурации

# Проверить env переменные
import os
print(os.getenv('DATABASE_URL'))  # Правильный URL?
print(os.getenv('SECRET_KEY'))    # Не пусто?

# Проверить конфиг файлы
cat config.yaml
echo $PYTHONPATH

Этап 7: Проверка производительности

# Процессор
top -b -n 1 | head -20
ps aux --sort=-%cpu | head -5

# Память
free -h
ps aux --sort=-%mem | head -5

# I/O
iostat -x 1 5

# Сеть
netstat -an | grep ESTABLISHED | wc -l
ss -s

Этап 8: Проверка базы данных

-- Сколько ждущих запросов?
SELECT pid, usename, state FROM pg_stat_activity;

-- Есть ли deadlocks?
SELECT * FROM pg_stat_database WHERE deadlocks > 0;

-- Медленные запросы
SELECT query, calls, total_time, mean_time 
FROM pg_stat_statements 
ORDER BY mean_time DESC 
LIMIT 10;

Систематический алгоритм

while problem_exists:
    1. Собрать данные (логи, метрики, состояние)
    2. Выдвинуть гипотезу
    3. Проверить гипотезу
    4. Если подтверждена → fix
    5. Если нет → вернуться к шагу 1 с новой гипотезой

Инструменты мониторинга

• Prometheus — метрики
• ELK Stack (Elasticsearch, Logstash, Kibana) — логи
• Grafana — визуализация
• Sentry — отслеживание ошибок
• New Relic / Datadog — APM (Application Performance Monitoring)

Пример диагностики реальной проблемы

Проблема: API медленный

# 1. Проверить метрики (tail из логов)
grep "duration" /var/log/app.log | tail -100
# Видим: обычно 50мс, сейчас 5000мс

# 2. Проверить базу
SELECT * FROM pg_stat_activity;  # Долгие запросы?

# 3. Посмотреть в лог приложения
docker logs app | grep "ERROR"
# Видим: "DatabaseError: connection pool exhausted"

# 4. Выдвинуть гипотезу: connections истощены
# Проверить конфиг
grep "POOL" config.py

# 5. Найти утечку соединений
# Посмотреть на close() вызовы
grep -r "conn.close()" src/

# 6. Fix: добавить контекст-менеджер
with db.connection() as conn:  # Автоматический close
    result = conn.execute(...)

Культура постмортема

После решения проблемы:

1. Write postmortem: Что произошло? Когда заметили? Как исправили?
2. Root cause: Какая первопричина?
3. Action items: Как предотвратить в будущем?
4. Share с командой: Все должны научиться

Лучший разработчик — не тот, кто не делает ошибок, а тот, кто их систематически диагностирует и исправляет.