Какие проблемы могут возникать на уровне приложения и как их решать?
Что проверяют
Вопрос нарочно широкий: интервьюер смотрит, умеете ли вы идти от симптома к причине, а не перечислять категории из учебника. Следом почти всегда просят случай из практики: что тормозило или падало и как вы это нашли.
Как отвечать
Сгруппируйте проблемы по симптомам и к каждой назовите способ диагностики и лечения:
- медленные ответы: чаще всего виноват не Python, а доступ к данным. N+1 в ORM лечится
select_related/prefetch_relatedв Django илиselectinloadв SQLAlchemy. Где уходит время, покажутcProfile,py-spyна живом процессе и трейсинг через OpenTelemetry; - заблокированный event loop: синхронный
requestsили тяжёлый расчёт внутриasync defостанавливает все корутины разом. Блокирующий вызов уносят вasyncio.to_thread, вычисления вProcessPoolExecutorили воркер Celery; - зависания на внешних вызовах: у
requestsтаймаута по умолчанию нет, запрос к умершему сервису висит бесконечно. Нужны таймауты, ретраи с backoff и circuit breaker; - исчерпание пулов: соединения с базой не возвращаются в пул, воркеры gunicorn заняты медленными запросами, новые клиенты ждут в очереди;
- утечки памяти: глобальные словари без ограничения размера,
lru_cacheна методе, который держит ссылку наself. Ищутся черезtracemalloc; - ошибки без следа: исключение поймали и проглотили. Нужны структурированные логи с контекстом запроса и Sentry.
Закончите мыслью, что без метрик и логов любое лечение превращается в гадание: сначала наблюдаемость, потом оптимизация.
Где спотыкаются
Перечисляют «производительность, безопасность, масштабируемость» без единого симптома и инструмента. Такой ответ звучит как оглавление статьи.
Сразу предлагают микросервисы и горизонтальное масштабирование. Если узкое место в N+1 или в блокирующем вызове, десять копий приложения просто дадут базе в десять раз больше лишних запросов.
Пишут except Exception: pass ради «стабильности». Приложение перестаёт падать, ошибки уходят в тишину, и проблема всплывает позже как испорченные данные.