Привет Хабр! В каждой компании есть люди, которые не пишут код каждый день, но почти каждый день принимают решения, от которых этот код либо спокойно живёт под нагрузкой, либо превращается в источник инцидентов и срочных созвонов. Думаю они согласятся, что масштабируемые IT-продукты строятся не только на технологиях, а ещё и на умении мыслить вероятностно.
Когда в команде спорят о фичах, производительности или надёжности, я редко слышу принципиально разные аргументы. Чаще это разные формы одного и того же:
-Мне кажется, пользователям понравится.
-Я уверен, что система выдержит.
-Ну сейчас же всё работает.
Проблема в том, что «кажется» и «уверен» плохо масштабируются. А числа — масштабируются отлично.
Любая IT-система живёт в мире случайностей. Пользователи кликают не по инструкции. Сети иногда тормозят. Серверы могут вести себя по-разному даже в идентичных условиях. И чем сложнее система, тем больше источников неопределённости.
Интуитивно хочется с этим бороться: всё предусмотреть, всё зафиксировать, всё контролировать. Но математика предлагает другой путь — не устранять случайность, а усреднять её.
Закон больших чисел говорит простую, почти успокаивающую вещь:
В большом количестве наблюдений случайные отклонения перестают доминировать.
Это идея, без которой невозможно ни A/B-тестирование, ни нагрузочное тестирование, ни мониторинг продакшна. И именно она позволяет превращать хаос пользовательского поведения в предсказуемые продуктовые и инженерные решения.
❯ Почему один эксперимент не доказывает ничего?
Продуктовые команды любят быстрые выводы. Запустили эксперимент — увидели рост — поехали дальше. И в этом месте статистика чаще всего проигрывает скорости.
Но любой A/B-тест — это не проверка идеи, а оценка случайной величины. Конверсия - это не константа. Это вероятность, оценённая по конечной выборке. И эта оценка всегда шумная.
Когда мы видим разницу между вариантами, первый вопрос, который стоит задать, звучит не «какой вариант лучше», а: насколько мы уверены, что эта разница не случайна?
Допустим, новая версия интерфейса дала рост конверсии с 5,4% до 5,6%. Это кажется маленькой, но приятной победой. Однако если посмотреть на это с точки зрения теории вероятностей, становится ясно: при таком размере выборки подобное отклонение вполне может возникнуть просто из-за случайного распределения пользователей.
Именно здесь появляется p-value — метрика, которую часто используют формально, но редко осмысляют.
p-value не говорит, «хорошая ли фича». Он отвечает на другой вопрос: насколько правдоподобно наблюдать такой результат, если на самом деле эффекта нет?
Если вероятность высока, мы всё ещё находимся в мире «трёх подбрасываний монетки».
Если низка — закон больших чисел начинает работать на нас.
Пример из практики:
A/B-тест кнопки «Купить»:
Вариант A: 10 000 пользователей, 540 покупок -> 5,4%
Вариант B: 10 000 пользователей, 560 покупок -> 5,6%
Разница есть. Но является ли она эффектом или шумом? Мы формулируем статистические гипотезы:
H0 (нулевая): разницы нет, наблюдаемое отличие — случайность
H1 (альтернативная): разница реальна
Дальше считаем p-value — вероятность получить такую разницу или больше при условии, что H0 верна. Если p-value = 0,15, это означает: в 15% случаев мы бы увидели такой же результат даже без реального эффекта. Для продакшн-решений это слишком рискованно.
Мы увеличиваем выборку до 50 000 пользователей на вариант:
5,5% vs 5,7%
p-value < 0,01
Теперь вероятность случайности менее 1%. Закон больших чисел уменьшил дисперсию, эффект стабилизировался.
Но даже статистически значимый результат — это не истина в последней инстанции. Он всего лишь означает, что эффект, скорее всего, существует. А вот насколько он велик — показывает доверительный интервал.
❯ Среднее значение — источник иллюзий
В разработке ошибка обычно начинается со слова «в среднем».
Среднее время ответа, средняя загрузка CPU, средняя скорость обработки — все эти метрики выглядят разумно, пока не сталкиваются с реальностью пользователей. Потому что пользователи живут не в среднем, а в хвостах распределений.
Если 99% запросов обрабатываются быстро, а 1% — катастрофически долго, именно этот 1% формирует ощущение «система тормозит». И никакие средние значения это ощущение не исправят.
Поэтому нагрузочное тестирование — это исследование распределения задержек под нагрузкой. Мы сознательно смотрим на P95 и P99, потому что именно там живёт настоящий риск.
Если:
99 запросов обрабатываются за 100 мс,
1 запрос — за 10 секунд,
то среднее выглядит приемлемо. Но пользователь, попавший в этот 1%, так не считает.
Поэтому мы смотрим на перцентили:
P95 — 95% запросов быстрее этого значения
P99 — 99% запросов быстрее этого значения
Важно и то, как мы получаем эти цифры. Один прогон нагрузки — это почти всегда случайность. Небольшое изменение порядка запросов, состояния кэша или фоновой активности может радикально повлиять на результат. Один прогон — шум. Десять прогонов — уже картина. Пятьдесят — уверенность.
И только серия тестов позволяет увидеть устойчивую картину. Закон больших чисел снова работает как фильтр: случайные пики сглаживаются, системные ограничения становятся видимыми.
В этот момент мы уже не «надеемся», что система выдержит, а знаем, при каких условиях она начнёт деградировать и с каким запасом.
❯ Надёжность — вероятностный контракт
В продакшне статистика перестаёт быть аналитическим инструментом и становится инструментом управления.
SLO часто воспринимают как формальную метрику для отчётов. Но по своей сути это вероятностный контракт между командой и пользователем. Мы не обещаем идеальный сервис. Мы обещаем, что сбои будут редкими и контролируемыми.
Когда мы говорим «99,9% доступности», мы заранее признаём: система иногда будет недоступна. И это не провал, а часть модели. Потому что альтернатива — бесконечные оверинвестиции в надёжность, которые редко окупаются.
Error budget в этом смысле — одно из самых зрелых инженерных понятий. Он переводит абстрактную надёжность в конкретные управленческие решения. Пока бюджет есть — мы можем экспериментировать. Когда он исчерпан — система говорит нам «остановись».
И снова всё упирается в закон больших чисел. Отдельный инцидент почти ничего не значит. Значение имеет частота и распределение инцидентов во времени. Именно поэтому агрегация метрик и анализ трендов важнее, чем реакция на единичные алерты.
Надёжность — это не отсутствие ошибок. Это способность отличить случайность от закономерности и реагировать только на вторую.
Закон больших чисел, теория вероятностей и статистика не делают системы идеальными. Но они делают их предсказуемыми. А предсказуемость — это, по сути, и есть масштабируемость. Без этих принципов мы строим продукты на ощущениях.
С ними — проектируем системы с рассчитанным запасом прочности. И если уж выбирать, на чём строить сложные продукты — я всегда выбираю числа. Потому что они, в отличие от уверенности, не подводят.
Спасибо за внимание!
Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩
