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

Ответ: Аналитический склад ума на примере реального сценария

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

Реальный пример: Проблема с производительностью API

Исходная проблема

В production возникла проблема:

• Жалоба: "API очень медленный, запрос к /api/users занимает 5 секунд"
• Когда заметили: на пике нагрузки (20:00 вечера)
• Как часто: непостоянно, иногда быстро, иногда медленно

Шаг 1: Разделение проблемы на части

Вместо "API медленный" разбиваю на компоненты:

API запрос (5 сек) состоит из:
├── Network latency (клиент → сервер)
├── Database query
├── Python code execution
├── Response serialization
└── Network latency (сервер → клиент)

Вопросы для анализа:

1. Это сеть? Клиент видит задержку?
2. Это БД? Какой конкретно запрос медленный?
3. Это код? Какая часть кода ест время?
4. Это сериализация? JSON слишком большой?

Шаг 2: Сбор данных (не предположения, а факты)

# Добавляю timing логирование в обработчик
import time
import logging

logger = logging.getLogger(__name__)

@app.get("/api/users")
async def get_users(db: Session):
    start = time.time()
    
    # Замеру время БД
    db_start = time.time()
    users = db.query(User).all()  # N+1 query?
    db_time = time.time() - db_start
    
    # Замеру время сериализации
    serialize_start = time.time()
    result = [user.to_dict() for user in users]
    serialize_time = time.time() - serialize_start
    
    total_time = time.time() - start
    
    logger.info(
        f"GET /users timing - DB: {db_time:.2f}s, "
        f"Serialize: {serialize_time:.2f}s, Total: {total_time:.2f}s"
    )
    
    return result

Результат логирования:

GET /users timing - DB: 4.8s, Serialize: 0.1s, Total: 5.0s

Вывод: проблема в БД, не в коде.

Шаг 3: Глубокий анализ БД

Теперь вопрос уже конкретный: "Почему query в БД 4.8 секунды?"

Возможные причины:

1. N+1 query проблема
2. Missing index на таблице
3. Full table scan вместо индекса
4. Слишком много данных в памяти
5. Блокировка на другой транзакции

Проверяю каждую:

# Включу SQL query логирование
from sqlalchemy import event
from sqlalchemy.engine import Engine

@event.listens_for(Engine, "before_cursor_execute")
def receive_before_cursor_execute(conn, cursor, statement, params, context, executemany):
    logger.info(f"SQL: {statement}")

# Теперь вижу какие запросы выполняются

Обнаруживаю:

SELECT * FROM users;  -- 1 запрос ок
SELECT * FROM profiles WHERE user_id = ?;  -- для каждого user!
SELECT * FROM preferences WHERE user_id = ?;  -- для каждого user!

Это N+1 query! На 1000 пользователей: 1 + 1000 + 1000 = 2001 запрос.

Шаг 4: Проверка индексов

-- Проверяю есть ли индекс
EXPLAIN ANALYZE SELECT * FROM users;

-- Вижу: "Seq Scan on users"
-- Это значит: полный скан таблицы (очень медленно на 1М записей)

-- Проверяю индексы
CREATE INDEX idx_users_id ON users(id);
-- Обычно уже есть на primary key

-- Проверяю индекс на status (если фильтруем по нему)
CREATE INDEX idx_users_status ON users(status);

Шаг 5: Формулирование гипотезы

На основе данных:

Гипотеза: Комбинация факторов
1. N+1 query проблема на profiles и preferences
2. Возможно missing индекс на user_id в profiles таблице
3. Происходит на пике нагрузки (20:00) потому что БД становится медленнее
4. На малом количестве юзеров этого не видно

Шаг 6: Решение

Исправляю N+1 query:

# ❌ Плохо — N+1
users = db.query(User).all()
for user in users:
    user.profiles  # каждый раз новый query!

# ✅ Хорошо — eager loading
from sqlalchemy.orm import joinedload

users = db.query(User).options(
    joinedload(User.profiles),
    joinedload(User.preferences)
).all()

Добавляю индекс:

CREATE INDEX idx_profiles_user_id ON profiles(user_id);
CREATE INDEX idx_preferences_user_id ON preferences(user_id);

Шаг 7: Проверка результата

После изменений:

GET /users timing - DB: 0.2s, Serialize: 0.1s, Total: 0.3s

Улучшение: 5.0s → 0.3s (16x faster!)

Почему это аналитический подход

1. Разделение на части

• Не пытался угадать
• Разбил большую проблему на части
• Каждую часть анализировал отдельно

2. Сбор данных

• Добавил логирование
• Получил цифры
• Не слушал ощущения, проверял факты

3. Поиск причины

• После данных понял: проблема в БД
• После SQL логов увидел N+1
• Сформулировал гипотезу

4. Систематическое решение

• Fixil N+1 problem
• Добавил индексы
• Проверил улучшение

5. Причинно-следственная цепь

Причина: N+1 query + missing indices
↓
Следствие: 2001 запрос к БД
↓
Следствие: 4.8 сек ожидания ответа
↓
Следствие: API медленный

Другие примеры аналитического мышления

Пример 2: Memory leak

Проблема: "Сервер ест всю память через неделю"

Аналитический подход:
1. Добавить memory profiler
2. Найти какой объект растёт
3. Разобрать как объект создаётся
4. Найти где он должен был удалиться
5. Найти утечку (circular reference? unclosed resource?)
6. Исправить в одной строчке кода

Пример 3: Intermittent bug (баг случается иногда)

Проблема: "Иногда крашится, но не всегда"

Аналитический подход:
1. Когда происходит? (время суток, нагрузка)
2. Как воспроизвести? (один раз или всегда)
3. Какой код в это время выполняется?
4. Есть ли race condition?
5. Есть ли dependency на порядок операций?
6. Добавить лоиты при баге
7. Найти причину
8. Исправить с гарантией

Ключевые характеристики аналитического ума

Итог

Аналитический склад ума — это когда:

• Видишь проблему → разбираешь на части
• Видишь части → собираешь данные
• Видишь данные → находишь причину
• Видишь причину → решаешь её полностью

Это не быстро, но это работает всегда. На моем примере: вместо слепых попыток исправить "медленный API", я за 30 минут анализа нашел и исправил реальную причину.