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

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

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

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

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

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

На работе. A/B-тест не дал эффекта на всей выборке, аналитик режет данные по сегментам и находит +8% конверсии у Android в Германии на второй неделе. Проверок было около сотни — пять ложных находок ожидаемы даже при полном отсутствии эффекта. Правильный ход: записать находку как гипотезу и проверить её предзарегистрированным тестом на новом трафике, а не выкатывать релиз по субгруппе. То же с алертами и дашбордами: если смотреть 300 графиков, каждый день «деградирует» несколько метрик. Разделяйте exploratory и confirmatory анализ явно, вплоть до разных документов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На работе. Команды с высоким покрытием тестами реже роняют прод — отсюда делают вывод, что каждый инженер, подняв покрытие своего модуля, снизит свои инциденты. Единица анализа подменена: на уровне команды работают ревью, CI, дежурства и то, какие сервисы ей достались, а не покрытие само по себе. Тот же промах в перформанс-обзоре («в команде высокий throughput» не делает высоким throughput каждого) и в SLO: 99,9% доступности на весь сервис не означает 99,9% для каждого клиента — один арендатор может ловить весь бюджет ошибок. Объявляйте единицу анализа — запрос, сессия, пользователь, команда — до того, как считаете, и не смешивайте уровни в одном выводе.

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

Прошлое решение оценивают знанием, которого у решавшего в тот момент не было.

Подменяется информационное состояние: исход уже известен, и сигналы, которые к нему вели, задним числом выглядят выделенными, а десятки равнозначных сигналов, тонувших тогда в шуме, невидимы. Конкурирующее объяснение — не «человек не подумал», а «информация в тот момент была неотличима от фона». Когнитивная подкладка ошибки — hindsight bias, «я так и знал» (глава 10). Честная оценка спрашивает, что было доступно на момент решения; ошибка историка спрашивает, почему не догадались о том, что мы знаем сейчас.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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