Занимался ли доработкой инфраструктуры под конкретные фреймворки или приложения?

Да, это стандартная задача. Инфраструктура должна учитывать особенности приложения для достижения максимальной производительности и отказоустойчивости.

Примеры из опыта:

1. Для веб-приложений (Python/Django, FastAPI):

• Django/Gunicorn: Настраивал количество воркеров Gunicorn на основе формулы (2 * cores) + 1, конфигурировал Nginx как reverse proxy с кэшированием статики и буферизацией запросов. Добавлял мониторинг метрик Gunicorn (через Prometheus) для отслеживания длины очереди запросов.
• FastAPI/Uvicorn: Использовал асинхронный запуск через Uvicorn с настройкой количества процессов (workers) для CPU-bound задач и корректной работы с ASGI. Интегрировал в Kubernetes с readiness-пробами для graceful startup.

2. Для Java-микросервисов (Spring Boot):

• Настраивал JVM-параметры в Docker-образах (Xms, Xmx, сборщик мусора) под выделенные лимиты ресурсов в Kubernetes.
• Внедрял sidecar-контейнеры для распределенного трейсинга (Jaeger) и сбора JVM-метрик (JMX Exporter для Prometheus).

3. Общие практики:

• Создавал Helm-чарты или Kustomize overlay'и, которые инкапсулировали специфичные для фреймворка настройки (environment variables, volumes для статики, health-check endpoints).
• Настраивал Horizontal Pod Autoscaler (HPA) на основе кастомных метрик приложения (например, RPS для API или длина очереди воркеров Celery), а не только CPU/Memory.

Пример фрагмента конфигурации HPA для приложения на FastAPI:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: fastapi-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100