После нагрузочного теста оценка вероятности сбоя изменилась. Как корректно обновить риск в реестре?
Нужно повторно оценить риск на основании новых данных, зафиксировать изменившиеся вероятность и последствия, обновить приоритет и назначенные меры. Риск нельзя просто закрыть: тест обычно уменьшает неопределённость или вероятность сценария, но не доказывает отсутствие риска во всех условиях.
Реестры рисков появились как способ сделать неопределённости проекта видимыми до наступления проблем. Без такого подхода решения часто принимаются по памяти, а результаты проверок остаются разрозненными и не влияют на стратегию качества.
Переоценка после получения новых свидетельств нужна потому, что исходные оценки строятся на предположениях. Тестирование, мониторинг и инциденты превращают предположения в более обоснованные данные, поэтому риск-ориентированное управление должно быть циклическим.
До нагрузочного теста команда могла считать сбой вероятным из-за отсутствия подтверждённой пропускной способности. После теста выяснилось, что система выдерживает ожидаемую нагрузку, но при пиковом сценарии возникают задержки или исчерпание ресурсов.
Неверно оставить старую оценку без изменений: команда будет тратить ресурсы на уже менее значимый риск. Неверно и удалить запись: результаты теста ограничены проверенными нагрузкой, конфигурацией, длительностью и условиями окружения.
Сначала нужно связать результат теста с конкретным сценарием риска: какие условия проверялись, какое поведение наблюдалось, какие пороговые значения были достигнуты и какие ограничения имел эксперимент. Затем пересматриваются две составляющие риска — вероятность и ущерб.
Результат может уменьшить вероятность сбоя, но обычно не меняет ущерб. Если отказ по-прежнему критичен для пользователей, даже небольшая вероятность может оставить риск высоким и потребовать защитных мер.
В реестре следует обновить:
Важно различать подтверждённый результат теста и доказательство отсутствия риска. Например, тест на ожидаемой нагрузке не подтверждает поведение при длительной деградации зависимостей, скачке трафика или изменении конфигурации.
Если используется числовая шкала, правила пересмотра должны быть заранее согласованы. Нельзя механически снижать оценку только потому, что тест завершился успешно: учитываются покрытие сценария, достоверность данных, близость окружения к production и качество самих измерений.
Интернет-магазин перед сезонным пиком оценивал риск отказа оформления заказа как высокий: вероятность — высокая, ущерб — критический. Нагрузочный тест на ожидаемом пиковом трафике прошёл успешно, но при длительной нагрузке обнаружилось постепенное накопление соединений к базе данных.
Команда рассматривала два варианта. Первый — закрыть риск как проверенный: это быстро, но игнорирует обнаруженное ограничение и создаёт ложное чувство безопасности. Второй — оставить исходную оценку без изменений: это сохраняет осторожность, но не отражает новые данные и затрудняет приоритизацию.
Выбранное решение состояло в снижении оценки вероятности для обычного пикового сценария, сохранении высокого приоритета для длительной нагрузки и добавлении действий: исправить управление соединениями, повторить тест после исправления и включить метрики пула соединений в мониторинг. Такой вариант разделил проверенный сценарий и остаточный риск вместо преждевременного закрытия записи.
1. Нужно ли менять оценку ущерба, если тест показал меньшую вероятность сбоя?
Нет, автоматически менять ущерб нельзя. Ущерб описывает последствия наступления события: например, потерю заказов, нарушение обязательств или недоступность критичной функции. Тест обычно уточняет вероятность или условия наступления, а последствия нужно пересматривать только при изменении самого контекста продукта.
2. Когда успешный тест не даёт оснований снизить риск?
Когда тест не репрезентативен для реального сценария. Причинами могут быть недостаточная длительность, неполный профиль нагрузки, отличия тестового окружения, нереалистичные данные или отсутствие проверки зависимостей. В этом случае результат снижает неопределённость, но не обязательно снижает вероятность риска.
3. Кто должен принимать решение об остаточном риске?
Владелец риска со стороны продукта или бизнеса, а не QA единолично. QA предоставляет свидетельства, оценивает полноту проверок и формулирует ограничения результата; технические специалисты предлагают меры снижения. Решение о принятии возможного ущерба должно оставаться у роли, которая отвечает за бизнес-последствия и имеет полномочия изменить план выпуска.