ADI · ОБЗОР
ADI: трёхверсионный анализ как ежедневная практика
Хороший следователь не фиксируется на первой версии. Он выписывает несколько,
описывает проверяемое следствие для каждой - и только потом собирает замеры.
ADI (Adversarial Decision Inquiry - состязательный анализ решений) переносит
этот приём в инженерную практику: три версии причины, одна из которых должна
вас опровергнуть.
Откуда приём
В XIX веке терапевты заметили закономерность: врач, первым назвавший диагноз,
редко его менял - даже когда симптомы указывали в другую сторону. Первая версия
создаёт когнитивный коридор: всё последующее интерпретируется в её пользу.
Ответом стала практика дифференциальной диагностики. Прежде чем выбрать лечение,
врач обязан записать несколько конкурирующих объяснений симптомов - и для каждого
описать, какое наблюдение его подтвердит или опровергнет. Только после этого -
сбор данных и выбор.
Та же логика появилась в философии науки под именами абдукция, дедукция, индукция.
Абдукция - «объяснение удивительного факта», то есть построение лучшей гипотезы.
Дедукция - «если гипотеза верна, мы должны наблюдать X». Индукция - «мы
наблюдаем X, значит гипотеза подтверждена». Без первого шага (нескольких
конкурирующих гипотез) вся цепочка работает как самоисполняющееся пророчество.
В инженерной практике приём разошёлся по нескольким областям. В контроле
качества производства - анализ первопричин с обязательным «не менее трёх
возможных причин». В информационной безопасности - threat modeling, где
аналитик обязан рассмотреть несколько векторов атаки перед тем как решить,
какой закрывать. В исследовательской разработке - конкурирующие гипотезы
как стандарт оформления эксперимента.
Общее во всех версиях: одна версия - это не анализ, это рефлекс.
ADI - это практика, которая переводит рефлекс в анализ.
Когда применять
ADI эффективен в ситуациях, где первая версия объяснения создаёт ложное ощущение
понимания. Шесть типовых контекстов.
ОТЛАДКА
«Почему сервис начал падать»
Первая версия («утечка памяти») часто оказывается правильной, но не единственной. Одновременно может быть и утечка, и гонка состояний, и деградация соседнего сервиса. Три версии помогают не остановиться на первой починке.
АРХИТЕКТУРНЫЙ ВЫБОР
«Почему наш первый вариант кажется лучшим»
Команда предлагает решение, которое с первого взгляда кажется очевидным. ADI заставляет выписать две конкурирующие архитектуры и явно проверить, по каким критериям они хуже - а не просто принять «ну, все так делают».
РЕТРОСПЕКТИВА
«Почему задача заняла втрое больше»
«Недооценили сложность» - ответ, который закрывает разговор и не даёт выводов. ADI разворачивает его в три конкурирующие версии: недооценили, изменились требования, были заблокированы внешне. Каждая требует разного лечения.
МЕТРИКИ ПЛЫВУТ
«Конверсия упала на 12%»
Версии могут быть несовместимы (деградация API, изменение поведения пользователей, проблема с формой на мобильных). Без явного списка версий команда обычно проверяет первую, не находит «явного виновника» и объявляет «статистический шум».
ОТКАЗ ЗАВИСИМОСТИ
«Внешний сервис не отвечает»
Причина может быть у поставщика, в сетевом слое, в изменении аутентификации или в нашем коде. ADI даёт порядок проверки - от самой вероятной к самой редкой - вместо хаотичного «давайте перезапустим всё подряд».
РЕШЕНИЕ НЕ РАБОТАЕТ
«Мы внедрили X, но ситуация не улучшилась»
Версии: X неправильно имплементирован, X решает не ту проблему, проблема усилилась по другой причине. Третья версия самая неудобная - и именно её чаще всего пропускают без явного списка.
Как выглядит один цикл
Четыре шага. Цикл занимает 20-40 минут для простой ситуации, 2-3 часа для
сложной архитектурной. Главное - что он заканчивается конкретным действием,
а не расширенным обсуждением.
01
Выписать три версии причины
Записать три конкурирующих объяснения наблюдаемого явления. Первая -
та, что пришла в голову сразу. Вторая - альтернатива из другого слоя
(например, если первая была «баг в коде», вторая - «инфраструктурная»).
Третья - «неудобная»: та, которую хочется отмахнуться как маловероятную,
но которая объясняет все симптомы.
Пример: падение времени ответа API. В1: утечка соединений с базой.
В2: деградация соседнего сервиса. В3: изменился паттерн трафика клиентов.
02
Описать проверяемое следствие для каждой
Для каждой версии - один вопрос: «если эта версия верна, что именно
мы должны наблюдать в данных». Следствие должно быть проверяемым:
конкретный показатель, конкретный диапазон. Не «счётчик ошибок вырастет»,
а «p95 задержка вырастет при нагрузке выше 200 RPS».
В1: если утечка - pool_size в метриках должен расти монотонно.
В2: если соседний - его задержка должна коррелировать с нашей.
В3: если трафик - распределение по эндпоинтам изменилось в логах.
03
Собрать замеры
Не «посмотреть» на данные, а целенаправленно проверить следствие
каждой версии. Порядок - от самой дешёвой проверки к самой дорогой.
Важно: замеры делаются до того, как принято решение о действии.
Иначе действие будет по первой версии, которая кажется «очевидной».
Проверили: pool_size стабилен. Задержка соседнего сервиса - ровная.
Распределение запросов: доля тяжёлых эндпоинтов выросла с 12% до 31%.
04
Отбросить неподтверждённые, зафиксировать вывод
Версии, чьи следствия не подтвердились - явно отброшены с причиной.
Версия, чьё следствие совпало с наблюдением - принята как рабочая.
Если ни одна не подтвердилась - цикл повторяется с новым набором версий.
Вывод и отброшенные версии записываются в артефакт.
Вывод: причина - смещение профиля трафика. В1 и В2 отброшены: данные
не совпали. Действие: оптимизировать тяжёлые эндпоинты, не трогать пул.
Ключевой момент второго шага: следствие должно быть опровергающим, а не
подтверждающим. Не «если версия верна, мы найдём что-то похожее», а «если
версия верна, мы найдём именно это - и если не найдём, версия ложна».
Разница тонкая, но именно она отличает анализ от поиска подтверждений.
Почему именно три
Число не случайное. Есть конкретная статистическая причина, почему именно
три версии - а не одна, не две и не пять.
1
Одна версия
Это рефлекс, а не анализ. Человеческий мозг формирует первую версию
объяснения за доли секунды - из эвристик, паттернов, недавнего опыта.
Одна версия не требует усилия, не создаёт сравнения и не имеет механизма
самопроверки. Любые данные будут интерпретированы в её пользу.
2
Две версии
Лучше, но создаёт ложный выбор. Психологически две версии воспринимаются
как бинарная дилемма: «либо А, либо Б». Команды с двумя версиями тратят
время на споры «чья версия правильная» вместо поиска данных. Проблема
может оказаться третьей, которую никто не рассмотрел.
3
Три версии
Ломают коридор. Третья версия заставляет выйти за пределы первых двух
и рассмотреть объяснение из другого слоя. Статистически: в реальных
инцидентах более 60% случаев - причина не первая и не вторая версия.
Три версии - минимум, при котором реальная причина попадает в список.
Число «три» - это не магия, это эмпирика. Четыре и пять версий тоже работают,
но порог усилий растёт быстрее, чем польза. На практике третья версия уже
даёт 80% защиты от «первая версия всегда правильная». Четвёртая и пятая -
для ситуаций, где ставки очень высоки.
Один важный нюанс: третья версия должна быть из другого слоя,
а не просто вариацией первой. Если первые две - «утечка в коде» и «ещё одна
утечка в коде», третья должна быть инфраструктурной, продуктовой или
операционной. Иначе три версии остаются одним коридором, только чуть шире.
Глубже
Полный формальный разбор цикла принятия одного решения - включая то, как
ADI встраивается в документирование выбора и доказательную базу.