Что будешь делать, чтобы найти определенную строку кода при аварии на Linux-сервере?

Стратегия поиска проблемного кода в условиях аварии на Linux-сервере

При аварийной ситуации на Linux-сервере поиск конкретной строки кода требует системного подхода, сочетающего оперативность и методичность. Я использую многоуровневую стратегию, начиная с самых быстрых методов и двигаясь к более глубоким.

1. Мгновенная диагностика и сбор контекста

Первым делом я определяю масштаб аварии и ее симптомы:

# Проверяю системные метрики в реальном времени
top -b -n 1 | head -20
free -h
df -h

# Смотрю логи приложения за последние 5 минут
tail -n 100 /var/log/app/error.log | grep -A5 -B5 "ERROR\|FATAL\|Exception"

# Проверяю системные журналы
journalctl --since "5 minutes ago" | tail -50

Ключевые вопросы, которые я задаю:

• Авария локальная или распределенная?
• Есть ли паттерн в ошибках (время, пользователи, эндпоинты)?
• Какие метрики вышли за пределы нормы (CPU, память, диск)?

2. Целевой поиск по кодовой базе

Зная контекст ошибки, перехожу к поиску конкретного кода:

# Рекурсивный поиск по всему проекту
grep -rn "фрагмент_ошибки" /path/to/project/ --include="*.php"

# Поиск с учетом регистра и контекстом строк
grep -rn -i -C3 "specificErrorCode" /var/www/

# Поиск по stack trace из логов
grep -rn "ExceptionClassName" /path/to/source/ | head -20

Для PHP-проектов особенно важно:

• Искать имена исключений из логов
• Искать сообщения об ошибках (частично или полностью)
• Проверять номера строк, если они указаны в stack trace

3. Анализ логов с продвинутыми инструментами

Использую специализированные утилиты для работы с логами:

# Агрегация и фильтрация логов за период аварии
awk '/StartTime/,/EndTime/' /var/log/app.log | grep -v "DEBUG"

# Поиск паттернов с помощью AWK
awk '{print $1, $4, $7}' /var/log/access.log | sort | uniq -c | sort -nr | head -10

# Анализ частоты ошибок
grep "ERROR" /var/log/app.log | cut -d' ' -f1,2 | uniq -c

4. Инструменты мониторинга и трассировки

В современных проектах активно использую:

• APM-системы (New Relic, Datadog, Blackfire) для поиска медленных транзакций
• Трассировку запросов через XHProf или Tideways
• Метрики приложения в Prometheus/Grafana для выявления аномалий

5. Работа с системой контроля версий

Если проблема связана с недавними изменениями:

# Поиск изменений по ключевым словам в коммитах
git log --all --grep="bugfix\|fix\|error" --since="2 days ago"

# Просмотр изменений в конкретном файле
git blame /path/to/file.php | grep -i "problematic_function"

# Дифф между рабочей и проблемной версией
git diff production..staging -- /path/to/module/

6. Воспроизведение и отладка

Для сложных случаев создаю минимальный воспроизводимый пример:

<?php
// test_reproduce.php
error_reporting(E_ALL);
ini_set('display_errors', 1);

require_once '/path/to/problematic_file.php';

// Изолирую проблемную функцию
try {
    $result = problematicFunction($testData);
    var_dump($result);
} catch (Exception $e) {
    echo "ERROR: " . $e->getMessage() . "\n";
    echo "Stack trace:\n" . $e->getTraceAsString();
}

7. Проактивные меры для будущих инцидентов

После решения проблемы внедряю улучшения:

• Улучшение логгирования – добавляю уникальные идентификаторы запросов
• Структурированные логи в формате JSON для машинного анализа
• Автоматические алерты при появлении определенных ошибок
• Health-чекеры для критичных компонентов системы

Критические принципы при аварии:

1. Не паниковать – методичный подход эффективнее хаотичных действий
2. Документировать каждый шаг – для постмортема и обучения команды
3. Использовать историю команд – history | grep поиск для повторения успешных методов
4. Проверять очевидное – часто проблема в недавних изменениях или конфигурации
5. Привлекать коллег – свежий взгляд помогает увидеть неочевидные связи

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