Какие production-риски есть у Symfony: blocking code, connection pooling, config, auth, observability, deploy или graceful shutdown?

Конфигурация и утечка секретов

Частая ошибка — хранить APP_SECRET, DB-пароли и API-ключи прямо в .env.prod в репозитории. Правильный подход:

# Symfony Secrets Vault
php bin/console secrets:set DATABASE_URL
php bin/console secrets:set MAILER_DSN
# ключ шифрования хранится отдельно (env var SYMFONY_DECRYPTION_SECRET)

Vault шифрует секреты по libsodium, зашифрованные файлы можно коммитить в репозиторий. В production нужна только переменная SYMFONY_DECRYPTION_SECRET.

Blocking code и модель выполнения

Symfony работает поверх синхронного PHP-FPM: каждый запрос занимает один воркер на всё время своей обработки. Длинные операции (медленный SQL, HTTP к внешнему API, генерация PDF) блокируют весь воркер. Решения:

• Переносить тяжёлую работу в очередь через Symfony Messenger с транспортом redis:// или amqp://.
• Использовать HttpClient с AsyncResponse и stream() для параллельных HTTP-запросов без блокировки.
• Для WebSocket/SSE — запускать отдельный процесс на Swoole или FrankenPHP в worker-mode.

Connection pooling

PHP-FPM не переиспользует соединения между запросами — каждый запрос открывает новое соединение к PostgreSQL/MySQL. При 200 rps это легко исчерпывает max_connections. Решение:

• PgBouncer (transaction mode) перед PostgreSQL — прозрачный пул; Doctrine ничего не знает о его наличии.
• В doctrine.yaml установить server_version корректно, чтобы Doctrine не делал лишний SELECT version() при каждом соединении.
• Redis: использовать persistent_id в DSN (redis://localhost?persistent_id=myapp) для persistent connections через phpredis.

Аутентификация и авторизация

Типичные риски в production:

• Сессионные куки без secure и samesite=lax — уязвимость к CSRF и сниффингу.
• Отсутствие rate limit на /login — брутфорс. Используйте RateLimiter (framework.rate_limiter) с policy sliding_window.
• Voter'ы без явного ACCESS_DENIED молча пропускают неавторизованные запросы, если supports() возвращает false.

# config/packages/security.yaml
firewalls:
  main:
    lazy: true
    cookie_secure: true
    cookie_samesite: lax
    login_throttling:
      max_attempts: 5
      interval: '15 minutes'

Observability

По умолчанию Symfony пишет в монолитный var/log/prod.log. В production нужно:

• Structured logging через Monolog + JsonFormatter, вывод в stderr, сборка через Fluentd/Loki.
• Distributed tracing через symfony/opentelemetry-bundle (или DataDog APM) — иначе медленные запросы невозможно отследить по микросервисам.
• Метрики: symfony/metrics-bundle или prometheus/client_php с endpoint /metrics.

# config/packages/monolog.yaml
monolog:
  handlers:
    main:
      type: stream
      path: php://stderr
      formatter: monolog.formatter.json
      level: warning

Deploy и graceful shutdown

Symfony Messenger-воркеры (messenger:consume) должны корректно завершаться при деплое:

# supervisord или systemd шлёт SIGTERM
# воркер заканчивает текущее сообщение и останавливается
php bin/console messenger:consume async --time-limit=3600 --memory-limit=128M

Без --memory-limit воркеры накапливают утечки Doctrine EntityManager и падают в OOM. Кроме того, после деплоя обязательно cache:clear и doctrine:migrations:migrate --no-interaction через Ansible/Deployer до переключения трафика.

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

• OPcache stale code: после деплоя без opcache.validate_timestamps=1 или opcache_reset() старый байт-код может выполняться часами.
• Doctrine proxy-классы: если var/cache/prod не очищен, Doctrine использует устаревшие proxy; всегда запускайте cache:warmup в CI перед сборкой образа.
• Messenger и транзакции: диспетчеризация события внутри транзакции Doctrine отправит сообщение в очередь до коммита; используйте DispatchAfterCurrentBusMiddleware.
• APP_ENV=prod без APP_DEBUG=0: dev-режим профайлера активен даже в prod, если переменные не выставлены явно — утечка стека ошибок наружу.
• Session handler: PHP-сессии по умолчанию файловые; при горизонтальном масштабировании (несколько FPM-узлов) сессии теряются; нужен Redis-handler.
• Отсутствие health-check endpoint: load balancer отправляет трафик на узел с упавшей Doctrine-connection; добавьте /healthz с реальной проверкой БД.
• Long-running migrations: миграция с ALTER TABLE на таблице 10M строк блокирует её на минуты; используйте pt-online-schema-change или Percona Toolkit.

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

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