Какие production-риски чаще всего возникают в проектах на Python: производительность, зависимости, конкурентность, деплой или observability?

Production-риски Python-проектов

Python-проекты в production сталкиваются с предсказуемым набором рисков. Ниже — наиболее критичные с конкретными примерами и стратегиями митигации.

1. Производительность и GIL

GIL (Global Interpreter Lock) в CPython не позволяет потокам выполнять Python-bytecode параллельно. Для CPU-bound задач это критично:

# CPU-bound: потоки не помогут из-за GIL
import concurrent.futures
import math

def compute(n: int) -> float:
    return sum(math.sqrt(i) for i in range(n))

# Неэффективно для CPU-bound:
with concurrent.futures.ThreadPoolExecutor(max_workers=4) as ex:
    results = list(ex.map(compute, [10**6] * 4))

# Эффективно — обходим GIL:
with concurrent.futures.ProcessPoolExecutor(max_workers=4) as ex:
    results = list(ex.map(compute, [10**6] * 4))

В Python 3.13+ появился experimental free-threaded mode (python3.13t), но он ещё не production-ready.

2. Управление зависимостями

Dependency hell — один из главных рисков. Лучшие практики:

# Фиксируйте точные версии в production
pip freeze > requirements.lock

# Используйте uv или poetry для детерминированного lockfile
uv lock          # uv.lock
poetry lock      # poetry.lock

# В Docker: копируйте lockfile ДО кода, используйте слои кэша
COPY requirements.lock .
RUN pip install -r requirements.lock --no-deps

3. Конкурентность: asyncio и блокирующие вызовы

Блокирующие вызовы в asyncio event loop убивают throughput:

import asyncio
import time

# ПЛОХО: блокирует event loop для всех корутин
async def bad_handler():
    time.sleep(1)  # блокирующий вызов!
    return "done"

# ХОРОШО: передаём блокирующую работу в threadpool
async def good_handler():
    loop = asyncio.get_event_loop()
    await loop.run_in_executor(None, time.sleep, 1)
    return "done"

# Или: используйте asyncio-совместимые библиотеки
import httpx  # вместо requests
import asyncpg  # вместо psycopg2

4. Memory leaks

Типичные источники утечек памяти в Python:

• Глобальные словари как кэш без TTL/LRU-ограничения
• Циклические ссылки с __del__ (не собираются стандартным GC)
• Накопление объектов в asyncio очереди без потребителей

from functools import lru_cache
from cachetools import TTLCache

# Плохо: неограниченный рост
cache: dict = {}

# Хорошо: LRU с ограничением
@lru_cache(maxsize=1000)
def get_user(user_id: int): ...

# Хорошо: TTL-кэш
cache = TTLCache(maxsize=500, ttl=300)

5. Observability

Без метрик и трейсов production-инциденты невозможно диагностировать:

# OpenTelemetry — стандарт де-факто
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

tracer = trace.get_tracer(__name__)

async def process_order(order_id: str):
    with tracer.start_as_current_span('process_order') as span:
        span.set_attribute('order.id', order_id)
        # ...

6. Деплой: версионирование и zero-downtime

# Gunicorn + Uvicorn для FastAPI
gunicorn app.main:app \
  -w 4 \
  -k uvicorn.workers.UvicornWorker \
  --graceful-timeout 30 \
  --preload  # pre-fork для Copy-on-Write экономии памяти

Подводные камни

• Asyncio не защищает от блокирующих вызовов — один requests.get() внутри корутины остановит весь event loop.
• Мультипроцессинг (multiprocessing) не масштабируется горизонтально на Kubernetes без изменения архитектуры.
• Python 3.x minor версии могут менять поведение (3.11 → 3.12 ускорил интерпретатор, 3.12 изменил GIL для free-threading).
• Зависимости с нативными расширениями (C/C++) требуют совместимости manylinux-wheels с вашим Docker base image.
• Память: CPython не возвращает ОС освобождённую память сразу — RSS-метрика будет расти даже при нормальном GC.
• Сигналы (SIGTERM) по умолчанию не обрабатываются в asyncio — нужен явный signal.signal для graceful shutdown.
• Logging в multiprocessing-окружении требует QueueHandler, иначе вывод логов будет interleaved и частично потерян.

• Говорить только о запуске Python, но не об эксплуатации
• Не упоминать observability, обновления, безопасность и rollback
• Описывать риски абстрактно, без способов их снижать

• Видит production-риски Python
• Говорит про monitoring, rollout, rollback и безопасность
• Умеет ранжировать риски по вероятности и влиянию