Приведи пример дефекта с низким приоритетом и критической серьезностью

Дефект с низким приоритетом и критической серьезностью

Концепция: В контексте управления дефектами существует различие между приоритетом (Priority) и серьёзностью (Severity).

• Приоритет — это срочность, с которой дефект должен быть исправлен, и порядок его устранения в списке задач. Он зависит от бизнес-логики, маркетинговых сроков, влияния на ключевых пользователей.
• Серьёзность — это степень влияния дефекта на функциональность системы, её стабильность, безопасность или данные. Оценивает "разрушительную силу" бага.

Сочетание низкого приоритета с критической серьёзностью — нечастая, но возможная ситуация. Это дефект, который наносит серьезный ущерб системе (например, приводит к её падению или потере данных), но:

1. Встречается в очень специфических и редких условиях, которые почти невозможно воспроизвести обычному пользователю.
2. Для его активации требуются особые, "лабораторные" настройки, недоступные в production-среде без глубокого вмешательства администратора.
3. Путь к воспроизведению включает цепочку крайне маловероятных действий или данных.

---

Конкретный пример: "Критический краш сервера при парсинге специально сформированной строки в неиспользуемом API эндпоинте"

Продукт: Веб-приложение для управления документами.

Дефект:

• Критическая Серьёзность (Severity: Critical/Blocker): При отправке определенного HTTP-запроса на один из API-методов (POST /api/v1/internal/legacy-parser) сервер приложения полностью падает (возникает необработанное исключение уровня runtime, ведущее к Segmentation Fault в бэкенде на C++). Все пользователи, подключенные к данному инстансу сервера, получают ошибку 502/503. Требуется ручной перезапуск службы. Фактически это отказ в обслуживании (DoS) для всего приложения.
• Низкий Приоритет (Priority: Low):

    1.  **Устаревший и неиспользуемый эндпоинт**: Путь `/internal/legacy-parser` — это внутренний, унаследованный метод, отключенный на уровне маршрутизации (роутера) в production-среде с самого начала. **Клиентский код (фронтенд) и официальное API никогда его не вызывают.** Он "живет" только в кодовой базе.
    2.  **Недоступен извне**: Эндпоинт закрыт фаерволлом для внешнего мира.
    3.  **Специфические условия для краша**: Сбой происходит только при выполнении ВСЕХ условий:
        *   Отправлен HTTP-запрос **НЕ через стандартный роутер**, а напрямую на порт приложения, минуя фаерволл и шлюз.
        *   В заголовке `Content-Type` установлено значение `text/plain; charset=ibm866`.
        *   Тело запроса содержит специальную строку с определенной последовательностью escape-символов и нулевым байтом (`%00`), например: `"%%D0%%00%%FF%%1F%%AA%%??"`.
        *   Сервер должен работать в режиме отладки (`--debug-mode`), который отключен во всех production-сборках.

Путь к воспроизведению (строго на тестовом стенде):

# 1. Запустить сервер в специальном, НЕ продуктовом, режиме.
$ ./backend_app --debug-mode --enable-legacy-internal

# 2. Использовать утилиту curl, чтобы отправить запрос напрямую на порт приложения (минуя Nginx).
$ curl -X POST \
  http://localhost:8080/api/v1/internal/legacy-parser \
  -H 'Content-Type: text/plain; charset=ibm866' \
  -d '%%D0%%00%%FF%%1F%%AA%%??'
# После выполнения этой команды процесс backend_app аварийно завершится.

---

Почему приоритет назначается низким?

Обсуждение на triage-встрече (оценке инцидентов) приведет к следующим аргументам:

• Нулевой пользовательский и бизнес-impact: Функциональность не используется, никто из реальных пользователей не пострадал и не пострадает.
• Сверхсложные условия эксплуатации в реальности: Злоумышленник или пользователь должен иметь прямой доступ к "голому" порту приложения в production-среде, что исключено архитектурой (запросы идут через API Gateway и WAF).
• Фиксация несет собственные риски: Изменения в старом, сложном и "монолитном" модуле парсера могут неожиданно задеть другую, актуальную логику. Требуется очень глубокий рефакторинг.
• Ресурсы направляются на важные задачи: Разработчики и QA заняты новыми фичами и исправлением реальных, воспроизводимых пользователями багов.

Решение по такому дефекту

Обычно принимается одно из следующих решений:

1. Запланировать исправление на "технический долг" — дефект вносят в бэклог с низким приоритетом.
2. Полное удаление "мертвого кода" — лучшая практика. Эндпоинт и весь связанный с ним унаследованный модуль планируют к удалению в следующем крупном рефакторинге.
3. Добавление защитного программирования и мониторинга:

   // Пример упрощенного "костыля" на уровне входа в функцию
   void LegacyParser::parse(const std::string& input) {
       // Защита от нулевого байта внутри строки (основная причина краша)
       if (input.find('\0') != std::string::npos) {
           logSecurityEvent("Invalid null byte in legacy parser input");
           throw std::invalid_argument("Invalid input data");
       }
       // ... остальная (рискованная) логика парсинга ...
   }
   

4. Документирование и "черный список": Информация о проблеме вносится в known-issues, а специфичная строка добавляется в правила WAF как потенциально опасная на будущее.

Вывод: Данный пример наглядно показывает, что даже критический по серьёзности дефект может быть низкоприоритетным, если вероятность его возникновения в реальных условиях стремится к нулю, а его исправление не приносит бизнес-ценности и потенциально рискованно. Такие ситуации требуют взвешенного подхода, основанного на анализе рисков, а не на автоматическом следовании классификации Severity.