Какие ошибки вылезали на Production

Какие ошибки вылезали на Production за мою карьеру?

За 10+ лет работы QA Engineer я сталкивался с самыми разными инцидентами на продакшене. Их можно условно разделить на категории по причинам возникновения. Главный урок — ни одна система не застрахована от багов в Production, но качественные процессы могут минимизировать их частоту и влияние.

1. Ошибки, связанные с конфигурацией и окружением

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

• Различия в конфигурационных файлах. Классический пример — в продакшене остался флаг включения A/B-теста, который в тестовой среде был выключен. Это привело к тому, что 10% пользователей увидели неоттестированную, сырую функциональность, что вызвало волну негативных отзывов.
• Различия в версиях зависимостей. На тестовом стенде использовалась одна версия библиотеки для обработки платежей, а на продакшене — более старая, с известной уязвимостью, которую "забыли" обновить. Это привело к сбоям при проведении транзакций в час пик.
• Проблемы с кэшированием. После развертывания нового релиза не был сброшен кэш контента (например, CDN или базы данных типа Redis). Пользователи продолжали видеть старые версии страниц, старые цены в каталоге или устаревшие данные в личном кабинете.

2. Ошибки интеграции и зависимостей от внешних сервисов

Современные системы редко живут в изоляции, и сбои во внешних API могут парализовать ключевые процессы.

• Некорректная обработка ответов от внешнего API. Наш сервис зависел от API почтовой службы для отправки уведомлений. В тестах мы использовали мок, который всегда возвращал HTTP 200 OK. В реальности API начал возвращать HTTP 429 Too Many Requests (лимит запросов), а наше приложение не обрабатывало эту ошибку, что приводило к накоплению исключений и падению очереди обработки писем.

  # Пример плохого кода, который не ожидает разные статусы
  def send_notification(user_email, message):
      response = requests.post('https://external-mail-api/send', json={'to': user_email, 'body': message})
      # Проблема: предполагается, что ответ всегда успешный
      data = response.json()
      return data['status'] == 'sent'
  
  # Исправленная версия с базовой обработкой ошибок
  def send_notification_safe(user_email, message):
      try:
          response = requests.post('https://external-mail-api/send', json={'to': user_email, 'body': message})
          response.raise_for_status()  # Выбросит исключение для статусов 4xx/5xx
          data = response.json()
          return data.get('status') == 'sent'
      except requests.exceptions.RequestException as e:
          log_error(f"Failed to send email to {user_email}: {e}")
          return False
  

• Изменение формата данных сторонним сервисом без предупреждения. Партнерский сервис обновил свой JSON-ответ, добавив новый обязательный ключ и переименовав старый. Наш парсер данных падал с KeyError, что приводило к остановке процесса импорта товаров.

3. Ошибки, связанные с данными и их объемами

На тестовых стендах редко работают с объемами и разнообразием данных, сравнимыми с продакшеном.

• Утечка памяти из-за большого набора данных. Функция генерации отчета для администратора прекрасно работала на тестовой базе с 1000 пользователей. На продакшене с 2 миллионами пользователей она потребляла всю доступную оперативную память сервера, вызывая его остановку.
• Проблемы с производительностью запросов к БД. Отсутствие индекса на критическом поле в условии WHERE в продакшн-БД приводило к полному сканированию таблицы (full table scan). Запрос, выполнявшийся на тесте за 50 мс, на продакшене стал выполняться 30 секунд, "подвешивая" интерфейс пользователя.
• Некорректная миграция данных. Скрипт обновления базы данных содержал ошибку в условии, из-за которой для части пользователей были обнулены балансы бонусных баллов. Ошибка вскрылась только через несколько часов по обращениям в поддержку.

4. Логические ошибки в бизнес-логике и крайних случаях (Edge Cases)

Часто самые простые сценарии тестируются тщательно, а "углы" остаются без внимания.

• Ошибки в расчетах с плавающей точкой. В финансовом модуле при определенной последовательности операций (например, многократное начисление и списание сотых долей) из-за особенностей float возникала ошибка округления, приводящая к расхождению в копейках при сверке с бухгалтерией.

  // Пример проблемы
  let total = 0.1 + 0.2; // Ожидается 0.3
  console.log(total);    // В JavaScript выведет: 0.30000000000000004
  console.log(total === 0.3); // false!
  

• Неучтенные временные зоны. Функция, формирующая отчет "за сегодня", на сервере в UTC времени показывала данные, частично относящиеся к завтрашнему дню по местному времени пользователей из Азии.
• Обработка null и дефолтных значений. При создании заказа, если у пользователя не был указан телефон, система вместо подстановки значения из профиля падала с NullPointerException, и заказ не создавался.

5. Ошибки, связанные с параллелизмом и состоянием гонки (Race Conditions)

Проявляются только под высокой нагрузкой, которую сложно смоделировать на тестовом стенде.

• Двойное списание средств. Классическая race condition в платежном модуле: два параллельных запроса на списание одной и той же суммы (из-за двойного клика пользователя или ретрая) проходили проверку достаточности баланса практически одновременно и оба успешно списывали деньги. В результате у пользователя списывалась удвоенная сумма.

Выводы и превентивные меры

Каждый такой инцидент — это дорогостоящий урок, который приводит к усилению процессов:

• Инфраструктура как код (IaC) и идентичные stage-среды для минимизации дрейфа конфигурации.
• Тщательное тестирование интеграций, включая негативные сценарии (сбои API, таймауты).
• Нагрузочное тестирование (Performance/Load Testing) на приближенных к проду объемах данных.
• Статический анализ кода (SAST) и регрессионное тестирование.
• Внедрение Canary-релизов и Feature Flags для контроля над развертыванием.
• Четкий процесс проверки миграций данных и их отката.
• Мониторинг и алертинг ключевых бизнес- и технических метрик для быстрого обнаружения аномалий.

Главная цель QA — не поймать все баги до релиза (это невозможно), а выстроить такие процессы, которые либо не допустят критических ошибок в продакшен, либо обеспечат их максимально быстрое обнаружение и минимальное воздействие на пользователей.