Что делать, если баг не воспроизводится локально?

Стратегия работы с невоспроизводимыми багами в продакшене

Когда баг не воспроизводится локально — это сложная, но рутинная ситуация в разработке. Вот системный подход, который я использую на протяжении 10+ лет работы с PHP-бэкендом.

1. Детальный сбор информации о баге

Первое и самое важное — собрать максимум контекста:

// Пример: структура логов, которую мы используем для отслеживания проблем
class BugReproductionLogger {
    private function logCriticalContext() {
        $context = [
            'timestamp' => date('c'),
            'environment' => $_ENV['APP_ENV'] ?? 'unknown',
            'php_version' => PHP_VERSION,
            'request_id' => $this->generateRequestId(),
            'user_id' => Auth::id() ?? 'guest',
            'url' => $_SERVER['REQUEST_URI'] ?? '',
            'method' => $_SERVER['REQUEST_METHOD'] ?? 'GET',
            'input_data' => $this->sanitizeInput($_REQUEST),
            'server_ips' => $_SERVER['SERVER_ADDR'] ?? '',
            'client_ip' => $_SERVER['REMOTE_ADDR'] ?? '',
            'memory_peak' => memory_get_peak_usage(true),
            'execution_time' => microtime(true) - LARAVEL_START,
        ];
        
        Log::critical('non_reproducible_bug_context', $context);
    }
}

Ключевые данные для сбора:

• Полный стектрейс ошибки (если доступен)
• ID пользователя и его роль
• Точное время возникновения (с часовым поясом)
• Версии всех компонентов: PHP, расширения, фреймворк, база данных
• Параметры запроса (GET, POST, headers)
• Состояние сессии и аутентификации

2. Анализ различий сред

В 80% случаев проблема в расхождениях между средами. Проверяю:

Конфигурационные различия:

# Сравнение PHP конфигураций
php -i | grep -E "(memory_limit|max_execution_time|error_reporting)" > prod_config.txt
php -i | grep -E "(memory_limit|max_execution_time|error_reporting)" > local_config.txt
diff prod_config.txt local_config.txt

Различия в зависимостях:

// composer.json — версии могут отличаться
{
    "require": {
        "php": "^8.1", // На продакшене 8.1.22, локально 8.1.25
        "laravel/framework": "^10.0", // Минорные версии могут иметь баги
        "ext-redis": "*" // Расширение может быть другой версии
    }
}

3. Воссоздание условий продакшена

Создаю максимально близкую к продакшену среду:

1. Использую Docker-контейнеры с идентичными версиями ПО
2. Копирую актуальные данные из продакшена (обезличенные)
3. Настраиваю идентичные параметры инфраструктуры:
   • Размеры пулов соединений (MySQL, Redis)
   • Лимиты памяти и времени выполнения
   • Настройки кеширования и сессий

4. Методика логирования и трассировки

Внедряю дополнительное логирование именно для этого бага:

class DebugTracer {
    private static $tracePoints = [];
    
    public static function trace(string $point, $data = null): void {
        if ($_ENV['DEBUG_TRACE_ENABLED'] ?? false) {
            self::$tracePoints[] = [
                'point' => $point,
                'data' => $data,
                'memory' => memory_get_usage(true),
                'time' => microtime(true),
                'backtrace' => debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 3)
            ];
            
            // Логируем при достижении лимита или в конце выполнения
            if (count(self::$tracePoints) > 50) {
                self::flushLogs();
            }
        }
    }
    
    public static function flushLogs(): void {
        file_put_contents(
            storage_path('logs/trace_' . date('Y-m-d') . '.log'),
            json_encode(self::$tracePoints, JSON_PRETTY_PRINT),
            FILE_APPEND
        );
        self::$tracePoints = [];
    }
}

// Использование в подозрительных местах
DebugTracer::trace('before_user_query', ['user_id' => $userId]);
$user = User::find($userId);
DebugTracer::trace('after_user_query', $user ? $user->toArray() : null);

5. Анализ временных факторов и состояний

Невоспроизводимые баги часто связаны с:

• Конкурентным доступом (race conditions) — использую логирование с микросекундными метками
• Кешированием и устаревшими данными — очищаю все кеши перед тестированием
• Внешними зависимостями (API, очереди, файловые системы) — мониторю их состояние
• Специфическими данными — анализирую, что уникального у пользователя с проблемой

6. Проактивные меры и инструменты

Внедряю в проект:

1. Sentry/Bugsnag для автоматического сбора ошибок с контекстом
2. Request ID для сквозной трассировки запросов
3. Метрики и алерты на аномальное поведение
4. Чеклист воспроизведения багов для команды

7. Когда всё ещё не воспроизводится

Если после всех мер баг остаётся неуловимым:

1. Пишу автоматизированный тест, который проверяет гипотезу о причине
2. Добавляю защитный код (fallback, валидацию, дополнительные проверки)
3. Устанавливаю мониторинг для поимки повторного возникновения
4. Документирую случай в базе знаний команды

Золотое правило: Невоспроизводимый баг, который произошёл один раз — возможно, случайность. Но если он повторился — это системная проблема, требующая глубокого расследования. В PHP-бэкенде особенно важно учитывать состояние приложения между запросами, работу с разделяемыми ресурсами и особенности конфигурации окружения.

Такой системный подход позволяет не просто "починить" невоспроизводимый баг, но и улучшить наблюдаемость всей системы, что предотвращает подобные проблемы в будущем.