Один запомнившийся случай ставят вместо данных о том, как часто так бывает.

Личный опыт — выборка из одного случая, и выбран он потому, что запомнился. Другие объяснения почти всегда наготове. Совпадение. Возврат к среднему: помощи ищут в худший момент, а после него обычно легчает сам. Ошибка выжившего: о случаях, где не сработало, просто не рассказывают. Опыт годится как источник гипотезы, но не как оценка частоты: у него нет знаменателя.

На работе. «На прошлой работе Kafka теряла сообщения, поэтому не берём» — один инцидент трёхлетней давности, на чужой версии и конфигурации. В поддержке три громких тикета за утро кажутся эпидемией, пока не посчитаешь долю: 3 обращения на 40 000 сессий — обычный фон. Один яркий случай задаёт гипотезу, а решение принимают по частоте.

Что отвечать. «Сколько было таких случаев всего и сколько закончились иначе? Мы знаем частоту или один запомнившийся исход?»

Мишень рисуют после выстрела: гипотезу подгоняют под случайное скопление, уже замеченное в данных.

В любом большом наборе данных найдутся скопления — это свойство случайности, а не сигнал. Ошибка — когда сегмент, окно или метрику выбирают, уже посмотрев на результат, и выдают находку за сбывшееся предсказание. Объяснение — арифметика множественных сравнений. Двадцать метрик на пяти сегментах в четырёх окнах — сотни проверок, и при уровне 0,05 десятки «значимых» появятся сами. Гипотезу, найденную в данных, проверяют только на новых данных.

На работе. A/B-тест не дал эффекта на всей выборке. Аналитик режет данные и находит +8% конверсии у Android в Германии на второй неделе. Проверок было около сотни, пять ложных находок ожидаемы и без эффекта. Верный ход: записать находку как гипотезу и проверить заранее объявленным тестом на новом трафике.

Что отвечать. «Сегмент, окно и метрику выбрали до того, как посмотрели данные? Сколько срезов проверили всего и что показали остальные?»

Раз две величины меняются вместе, считают, что одна вызывает другую.

Совместное изменение совместимо минимум с шестью картинами. X вызывает Y. Y вызывает X. Общая причина Z действует на обе. Связь создана отбором — тем, как данные попали в выборку. Обратная связь. Простое совпадение. Корреляция сужает список гипотез, но не выбирает из него. Чтобы говорить о причине, нужны механизм, порядок во времени и группа сравнения.

На работе. На дашборде видно: у сервисов с частыми деплоями больше инцидентов. Вывод «частые релизы ломают прод» переворачивает картину. Важные активные сервисы получают и больше изменений, и больше трафика, и лучший мониторинг — а значит, больше замеченных инцидентов. Смотрите долю неудачных деплоев, а не число инцидентов на сервис.

Что отвечать. «Что могло повлиять и на предполагаемую причину, и на результат? Не может ли стрелка смотреть в обратную сторону?»

Прошлые вложения, которые не вернуть, приводят как довод продолжать, хотя решение зависит только от будущего.

Потраченные деньги, время и репутация не вернутся ни при каком выборе. Они одинаковы в обоих вариантах и поэтому не помогают выбрать. Сравнивать нужно будущую пользу, будущие затраты и лучшую альтернативу. Прошлое важно только там, где оно создало актив, обязательство, знание или цену выхода. Рядом стоит эскалация обязательств: после публичного решения проще вложить ещё, чем признать ошибку.

На работе. Внутреннюю платформу два года пишут шесть инженеров, миграция сервисов не сдвинулась. «Столько вложено, нельзя бросать» подменяет настоящий вопрос: если бы платформы сегодня не было, начали бы мы её при нынешней цене готового решения? Лечится процессом: условия остановки и бюджет записывают до старта, а решение о продолжении принимает не автор идеи.

Что отвечать. «Если бы мы встретили эту возможность сегодня, ничего не вложив, — начали бы? Какие затраты впереди, а не позади?»

Раз B случилось после A, считают, что A вызвало B.

Порядок во времени для причины необходим, но не достаточен. Другие объяснения: совпадение; общая причина обоих событий; процесс, начавшийся раньше и проявившийся с задержкой; возврат к среднему — вмешиваются обычно на пике проблемы, а после пика становится лучше само; изменилось измерение, а не измеряемое. Чем ближе события по времени, тем убедительнее иллюзия и тем нужнее группа сравнения.

На работе. В 14:05 выкатили релиз, в 14:12 p99 вырос втрое, откатили — стало лучше, инцидент закрыт с причиной «релиз». Проверьте: график начал расти до 14:05? Не стартовал ли ночной batch, не деградировала ли зависимость? Откат меняет всё состояние системы, поэтому «после отката полегчало» — такой же post hoc. Причина подтверждена, когда есть механизм и воспроизведение, а не совпадение времени.

Что отвечать. «Что ещё изменилось в том же окне? Метрика начала расти до события? Есть ли похожая группа, где события не было?»

Среднее свойство группы переносят на каждого её участника.

Статистика группы и статистика человека — разные величины. Связь между ними может отличаться по силе и даже по знаку. Связь на уровне групп обычно объясняется составом групп и весами подгрупп, а не поведением людей. Крайний случай — парадокс Симпсона: тренд в каждой группе противоположен тренду в сумме. Зеркальная ошибка — атомистическая: закономерность для человека переносят на группу.

На работе. Команды с высоким покрытием тестами реже роняют прод. Отсюда выводят, что каждый инженер, подняв покрытие своего модуля, снизит свои инциденты. Но на уровне команды работают ревью, CI, дежурства и то, какие сервисы ей достались. Так же 99,9% доступности сервиса не значит 99,9% для каждого клиента. Называйте единицу анализа до подсчёта.

Что отвечать. «Какая здесь единица анализа — группа или человек? Разброс внутри групп не больше разницы между ними?»

Прошлое решение судят по знанию, которого у решавшего тогда не было.

Исход уже известен, и сигналы, которые к нему вели, задним числом кажутся заметными. А десятки таких же сигналов, тонувших тогда в шуме, не видны. Объяснение часто не «человек не подумал», а «сигнал тогда не отличался от фона». За этим стоит ошибка «я так и знал». Честная оценка спрашивает, что было известно в момент решения, а не почему не догадались о том, что знаем мы.

На работе. В постмортеме: «алерт же был в 3:40, почему дежурный не среагировал». В 3:40 этот алерт был одним из семнадцати, и четырнадцать из них шумят каждую ночь. Честный разбор восстанавливает, что было видно, и меняет систему: добавляет сигнал, ранбук или автоматику. Ошибка историка ищет, кто не догадался, и учит людей писать в отчётах меньше.

Что отвечать. «Что было известно человеку в ту минуту и как это выглядело среди остального шума? Мы судим решение или известный исход?»

Сравнение подают без второй стороны, без базы и без условий измерения.

«Быстрее», «дешевле», «на 40% эффективнее» — сравнения двух вещей. Пока не сказано, с чем, при каких условиях и по какой метрике, проверить их нельзя. Слушатель сам достраивает самый выгодный говорящему вариант. Подвохи прячутся в умолчаниях: удобная база, не названный знаменатель, относительный эффект вместо абсолютного, подобранное окно.

На работе. «Новый сервис в три раза быстрее» — чего: старой версии на холодном кеше, на другой машине, при другой нагрузке? Среднее или p99? Классика отчёта: «ошибок стало на 50% больше» без числа запросов — а при удвоившемся трафике доля ошибок упала. Требуйте числитель, знаменатель, базу, окно и абсолютные значения с разбросом.

Что отвечать. «Быстрее, дешевле, лучше — чем именно, по какой метрике и при каких условиях? Какие абсолютные числа и знаменатель?»

От независимого случайного процесса ждут, что он возместит прошлую серию.

Если испытания независимы и вероятность постоянна, прошлые исходы не меняют следующий: у монеты нет памяти. Частоты выравниваются не возвратом долга, а тем, что серия тонет в массе новых испытаний. Зеркальная крайность — вера в «горячую руку», когда серию считают закономерностью. Обе ошибки молча предполагают модель процесса. Поэтому проверять нужно не длину серии, а саму независимость: реальный процесс бывает связан с прошлым, изношен или зависим от общего ресурса.

На работе. «Четыре ночи дежурство было спокойным — сегодня точно рванёт» и обратное «десять зелёных сборок подряд, можно снять проверки». Оба вывода принимают независимость на веру. Полезнее другое: если нестабильный тест падал в 4 случаях из 100, а сегодня упал трижды за час, при независимости это почти невозможно. Значит, испытания зависимы — ищите общий ресурс или исчерпанный пул соединений.

Что отвечать. «Испытания здесь правда независимы? Если да, прошлое не влияет на следующий исход. Если нет, серия говорит, что процесс изменился».

Из данных показывают только подтверждающую часть и молчат о такой же опровергающей.

Наблюдения отбирают по согласию с тезисом, поэтому вывод задан процедурой, а не данными. Объяснение всегда одно и всегда за кадром: невыбранные наблюдения. Частные формы — удобное окно времени, показ только выживших случаев и подгонка анализа, пока не выйдет нужный результат. От честного отбора отличается тем, что критерий придуман после просмотра данных и не раскрыт.

На работе. В отчёте по релизу: конверсия +12% за выбранные девять дней. За кадром: окно начинается сразу после провального понедельника, на него пришлась рассылка скидок, из двадцати метрик показаны две. Защита — процедура: основную метрику, окно и правило остановки записывают до эксперимента, а отрицательные результаты публикуют наравне с положительными.

Что отвечать. «Какие данные того же качества мы не показали? Метрику и окно выбрали до того, как увидели результат?»

Раз событие произошло, считают, что оно не могло не произойти.

Случившийся исход кажется единственно возможным, потому что другие ветки больше не видны. Мы видим одну траекторию и достраиваем к ней связное объяснение. Работают два механизма: «я так и знал», переписывающее память о прежних ожиданиях, и тяга объяснять исход цепочкой шагов, которые к нему «вели». Проверка — какие оценки давали до события, а не насколько гладко звучит рассказ после.

На работе. После инцидента: «эта архитектура рано или поздно обязана была упасть». Возможно. Но той же логикой так же гладко объясняются три года, когда она не падала. Противоядие — записывать прогнозы с вероятностями заранее: журнал решений и premortem перед запуском. После инцидента сверяйте с записями.

Что отвечать. «Есть ли запись, что до события мы считали этот исход вероятным? Какие ветки были возможны тогда и что их закрыло?»

У результата нескольких причин называют одну и считают объяснение законченным.

Сложные исходы обычно рождаются из совпадения условий, и каждое по отдельности недостаточно. Назвав один фактор, мы не исключили остальные и, хуже того, прекращаем поиск. Другие объяснения здесь не альтернатива, а дополнение. Отдельный вид — свести многофакторный результат к виноватому. Тогда разговор уходит с механизма на человека и заканчивается раньше, чем начался.

На работе. «Причина инцидента — тяжёлый SQL-запрос». Рядом обычно ещё четыре условия: индекс не доехал с миграцией, ретраи без паузы, пул соединений на 20, порог алерта выше реального SLO. Инцидент случился, потому что совпали все пять. Поэтому в постмортеме пишут несколько способствующих факторов, а не одну корневую причину.

Что отвечать. «Если бы этого фактора не было, исход точно не наступил бы? Какие ещё условия должны были совпасть?»