В главе When to Stop Analysis книги Systems Performance обсуждается, как определить момент, когда дальнейший анализ проблемы становится неэффективным из-за низкого соотношения затрат к выгоде (ROI).

Аппетит приходит во время игры, ага:)

Автор предлагает три критерия, когда стоит остановиться:

1. Если найденное решение покрывает основную часть проблемы (66+ % от деградации);
2. Если затраты на анализ превышают потенциальную выгоду (отрицательный ROI);
3. Если есть другие задачи с более высоким ROI.

На мой взгляд, удобнее смотреть на схему по другому — перевернуть с ног на голову и сверяться с ней на каждом шаге:

1. Выбираем наиболее приоритетную проблему — хорошо когда можем сделать количественную оценку (деньги, время);
2. Погружаемся в суть и ищем решение, которое закроет хотя бы 66% проблемы;
3. GOTO 1 — проводим переоценку: точно ли оставшиеся 34 % всё ещё важнее других задач?

Звучит просто, но сколько раз я залипал на часы, разбирая то, что к делу почти не относится — подсчёту не поддаётся:)

P.S. есть мнение, что подход будет работать далеко за пределами траблшутинга и IT.