Это метод, позволяющий легко и быстро, коллективно и визуально идентифицировать риски в системе. Метод подразумевает участие нескольких людей. Для более широкого взгляда на рассматриваемую систему, полный состав участников может включать в себя людей из разных направлений и с разными навыками.
Метод
Сам метод состоит из нескольких последовательно выполняемых шагов. Разберём каждый их них.
Шаг 1: Нарисовать диаграммы архитектуры
Поскольку метод подразумевает поиск рисков в готовой или строящейся системе, нам необходимо эту самую систему каким-то образом видеть.
Диаграммы архитектуры в этом плане - прекрасное подспорье. Они проиллюстрируют основные компоненты системы и их взаимосвязи.
Шаг 2. Индивидуальный поиск рисков
На данном шаге, каждый из участников выписывает абсолютно любые риски и проблемы, пришедшие ему в голову, на стикеры.
Этот шаг проводится в абсолютной тишине и должен быть ограничен по времени. Например, 5-10 минут может быть вполне достаточно.
Примерами рисков могут быть абсолютно любые предположения о неработоспособности чего-либо. Например:
Формат данных в сторонней системе изменился
Внешние сервисы недоступны
Неконсистентость данных
Шаг 3. Делимся предположениями
На данном шаге, все участники сессии размещают свои стикеры на диаграммах архитектуры, на основе которых производился поиск рисков.
Стикеры размещаются близко к той части диаграммы, к которой относятся описанные риски.
Если несколько участников сессии описали схожие риски, стикеры этих рисков располагаются вместе.
Шаг 4. Приоритизация
И на заключительном шаге, каждый из найденных рисков, рассматривается и обсуждается коллективно.
Задача этого шага определить насколько высокий приоритет имеет найденная потенциальная проблема.
Вариантов оценить приоритет несколько. Я опишу их два:
Planning Poker (PlanningPoker.com - Estimates Made Easy. Sprints Made Simple.) - это когда участники оценивают риски, используя карты с цифрами и коллективно обсуждая. В конце концов, переговоры должны придти к общему пониманию.
Используя специальную матрицу, на которой на одной оси располагается Вероятность возникновения (Probability) проблемы, а на другой - её Влияние (Impact).
Пример
Для того, чтобы посмотреть на метод в действии, нам понадобится архитектурная схема системы. Поскольку подход абсолютно универсальный - я взял произвольную схему из Интернета:
Теперь, когда у нас есть схема архитектуры мы можем приступать.
Следующим шагом будет попытка каждого участника идентифицировать риски, возможные в абсолютно любой части системы. Риски описываются на стикерах и затем, стикеры, располагаются на той части схемы, к которой риск, описанный на нём, относится.
У меня получилось следующее:
Напомню, что цель данного метода не вычислить каждый возможный потенциальный риск. Естественно, должны быть пределы разумного. «Нападение акул на сотрудников дата центра» - хорошая идея, но это гарантированно не произойдёт (если только дата центр не располагается на дне океана).
Следующим шагом будет коллективная оценка каждого найденного риска, с помощью принятого в команде метода оценки. Для примера я воспользуюсь методом с матрицей. Давайте попробуем оценить приоритет риска с загрузкой в наш сервис гигантского файла (нужно прояснить, под гигантским файлом я имею ввиду любой контент, размер которого выходит за пределы разумного и принятого для данной системы).
Загрузка гигантского файла может заставить нашу систему расходовать большое количество ресурсов на его обработку и хранение. Более того, предположим что наш Image Storage, это S3 сервис от AWS, а это значит что хранение гигантских объёмов данных будет стоить нам больших денег. Поэтому я полагаю, что Вероятность, что кто-то попробует это провернуть не нулевая, так что Medium, а Влияние на работоспособность системы и её обслуживание велико, то есть High. Оценив риск таким образом, я поместил его в соответствующую строку и колонку.
Аналогично, нужно поступить и с каждым из оставшихся рисков. В итоге, мы получим примерно следующую картину:
Итак, мы получили оценки для каждого из рисков. С матрицей уже сейчас можно сделать выводы о том, какие из рисков нужно постараться обработать быстрее остальных. Например, неограниченное количество запросов к сервису может привести к полному отказу работоспособности сервиса из-за DDOS атаки.
Список рисков с их оценкой в дальнейшем послужит отличной вводной информацией для формирования технического бэклога команды, обслуживающей сервис.
Дополнительные материалы
[1] Risk-storming - веб-сайт методологии
[2] https://leanpub.com/software-architecture-for-developers - книга автора методологии. В самой книге, методологии посвящена небольшая глава.
Оригинал этой статьи, а также многие другие на разные темы об IT и разработке, можно найти на моём сайте #fullstackguy.