Что будешь делать с ошибкой 500?

Общая стратегия работы с HTTP 500

Ошибка 500 Internal Server Error — это критический сигнал о неполадках на стороне сервера. Моя стратегия включает немедленное реагирование, диагностику, исправление и последующий анализ для предотвращения повторения. Вот пошаговый план действий.

Шаг 1: Немедленное реагирование и минимизация ущерба

• Оповещение: Первым делом я проверяю систему мониторинга (например, Sentry, Datadog, Grafana), которая должна была уже прислать алерт. Если её нет, фиксирую время появления ошибки.
• Маршрутизация трафика: Если приложение работает в кластере (например, под управлением Kubernetes или через балансировщик), проверяю, можно ли временно исключить проблемный инстанс из ротации, чтобы часть пользователей продолжала работать.
• Бэкап и откат: Если ошибка появилась после недавнего деплоя, самым быстрым решением часто является откат (rollback) к предыдущей стабильной версии кода. Это позволяет быстро восстановить работу, после чего уже спокойно искать корневую причину.

Шаг 2: Детальная диагностика и поиск корневой причины

Здесь я обращаюсь к логам и инструментам. Код PHP, вызывающий 500-ю ошибку, обычно генерирует исключение или фатальную ошибку, которая (при правильной настройке) должна быть залогирована.

• Анализ логов приложения:

  # Проверяю логи PHP-приложения (например, Laravel)
  tail -f /var/www/storage/logs/laravel-YYYY-MM-DD.log | grep -A 10 -B 5 "ERROR\|FATAL"
  

    Или логи веб-сервера:

```bash
# Проверяю error_log Nginx/Apache
tail -f /var/log/nginx/error.log
```

• Ключевые места для поиска в логах:

    *   **Fatal Error:** Несуществующий класс или функция, ошибки памяти.
    *   **Uncaught Exception:** Чаще всего это **PDOException** (проблемы с БД), **LogicException**, или кастомные исключения бизнес-логики.
    *   **Stack Trace:** Самая ценная часть. Она покажет точную строку кода, где произошёл сбой.

• Проверка системных ресурсов и зависимостей:

  # Проверка свободной памяти и диска
  free -h
  df -h
  
  # Проверка доступности внешних сервисов (БД, кеш, API)
  nc -zv database_host 3306
  

    *   **База данных:** Не отвечает, закончились соединения, синтаксическая ошибка в тяжелом запросе.
    *   **Кеш (Redis/Memcached):** Потеря связи может сломать механизмы сессий или быстрого доступа к данным.
    *   **Дисковое пространство:** Заполненный диск может помешать работе логов, загрузке файлов или даже интерпретатору PHP.

• Воспроизведение: По возможности, пытаюсь воспроизвести ошибку на staging+-окружении, используя те же параметры запроса (URL, headers, тело), которые были у пользователя.

Шаг 3: Локализация и исправление ошибки

Найдя причину, приступаю к исправлению.

Пример 1: Ошибка синтаксиса или логики Если в логах видно исключение в конкретном методе, исправляю код. Например, обработка возможного null:

// Было (может вызвать ошибку, если $user не найден)
$email = $user->getEmail();

// Стало (более безопасный код)
if ($user !== null) {
    $email = $user->getEmail();
} else {
    // Обработка случая "не найдено", например, логирование и возврат 404
    Log::warning('User not found', ['id' => $userId]);
    abort(404);
}

Пример 2: Проблема с базой данных

try {
    DB::beginTransaction();
    // ... сложная бизнес-логика ...
    DB::commit();
} catch (\PDOException $e) {
    DB::rollBack();
    // Важно: НЕ показывать детали ошибки пользователю в production!
    Log::error('Database transaction failed', ['exception' => $e->getMessage()]);
    // Возвращаем общее сообщение об ошибке сервера
    throw new InternalServerErrorException('Operation failed');
}

Шаг 4: Пост-мортем и превентивные меры

После восстановления работы критически важно предотвратить повторение.

• Пост-мортем анализ (Blameless Postmortem): Документирую цепочку событий, корневую причину, принятые меры и, главное, action items для улучшения системы.
• Превентивные меры:

    *   **Улучшение мониторинга:** Настраиваю алерты на ключевые метрики (ошибки 5xx, потребление памяти, скорость ответа БД).
    *   **Обработка ошибок:** Ввожу глобальный обработчик исключений (`set_exception_handler`) или использую middleware (в рамках фреймворка), чтобы гарантированно логировать все неожиданные ошибки и возвращать корректный HTTP.

// Пример глобального обработчика в Laravel (в App\Exceptions\Handler)
public function register()
{
    $this->reportable(function (Throwable $e) {
        // Отправляем ВСЕ необработанные исключения в Sentry
        if (app()->environment('production')) {
            Sentry\captureException($e);
        }
    });
}

• Нагрузочное тестирование: Провожу тесты перед крупными релизами, чтобы выявить узкие места.
• Ревизия кода (Code Review): Особое внимание в ревью уделяю участкам кода, работающим с внешними зависимостями и потенциально небезопасным операциям.

Итог: Работа с ошибкой 500 — это не просто «починить баг». Это комплексный процесс, сочетающий оперативное восстановление, глубокий технический анализ и системные улучшения инфраструктуры и кодовой базы, направленные на повышение отказоустойчивости приложения в долгосрочной перспективе.