Первым, кто дал инструмент для управления хаосом, был Якоб Бернулли. Закон больших чисел –идеологический фундамент любого бизнеса, основанного на обслуживании. Мы не можем предсказать поведение одного клиента, мы точно можем предсказать поведение ста тысяч.

Когда количество независимых случайных событий увеличивается, среднее значение стремится к математическому ожиданию. Для руководителя колл-центра это означает переход от гадания к инженерии. Если у вас 10 клиентов, бизнес –лотерея. Если 10 миллионов – статистика.

Закон больших чисел позволяет понять, что завтра в 10:00 утра поступит именно 450 звонков, плюс-минус три процента, хотя каждый звонящий принимает решение о наборе номера абсолютно самостоятельно. Этот принцип лежит в основе прогнозирования спроса и управления очередями.

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

Снаряды ложатся не в одну точку, а образуют фигуру рассеивания. Так появилось понятие доверительного коридора. В колл-центре — коридор ожидания. Если понимаем распределение Гаусса, можем рассчитать, какой процент клиентов попадёт в интервал времени ожидания.

Коридор попадания превратился в Service Level – главный показатель, определяющий, сколько ресурсов готовы потратить, чтобы удержать качество в заданных границах. Показатель устанавливает связь между статистической вероятностью события и операционной реальностью.

Теория массового обслуживания (ТМО) родилась из технологического тупика. В начале XX века телефонные сети Дании столкнулись с кризисом: количество абонентов росло, а соединительных линий было ограничено. Нельзя было проложить провод к каждому дому от каждой станции.

Агнер Краруп Эрланг, работая в Копенгагенской телефонной компании, решил эту задачу через математическое моделирование. Понял, что телефонная сеть – не просто провода, а живой организм, где заявки на соединение конкурируют за ограниченный ресурс (коридор).

Учёный первым вывел формулы, которые позволили рассчитать вероятность отказа в обслуживании. Erlang B и Erlang C – до сих пор являются «золотым стандартом» планирования и основой для расчёта размеров колл-центров, служб поддержки и нагрузки серверных систем.

Великий математик Хинчин дополнил картину, создав модель поиска ожиданий. Показал, что случайный процесс в системе можно описать через «память» системы. Концепция позволила инженерам учитывать не только мгновенный входящий сигнал, но и накопленную инерцию.

Которая продолжает влиять на скорость обслуживания даже после того, как пик нагрузки прошёл. Понимание связи критически важно для настройки параметров задержек, так как объясняет, почему система не возвращается в норму мгновенно после кратковременного сбоя.

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

Однако, как верно заметил Хевенг, в теории массового обслуживания главными являются не сухие цифры, а понимание физики процесса. ТМО – искусство находить баланс между экономикой (не держать лишних сотрудников/серверов) и качеством (не заставлять клиентов ждать).

Чтобы построить эффективный колл-центр, необходимо декомпозировать работу на элементарные частицы: заявка, задача и поток. Без чёткой терминологии расчёт нагрузки превращается в гадание. Все начинается с заявки, в телефонии входящий вызов, в мессенджере –HTTP-запрос/сообщение.

Когда заявка попадает в систему, должна быть решена определённая задача. Задача – повторяющаяся активность: авторизация пользователя, поиск данных в базе, ответ на вопрос или перевод звонка. Последовательность заявок образует поток — реку, которая течёт через колл-центр.

Потоки бывают разными.

Регулярный поток предсказуем: например, если вы договорились с клиентами, что будете обзванивать их строго каждые 5 минут. Здесь нет ТМО, здесь есть расписание.

Случайный поток – реальность. Заявки приходят в неопределённый моменты времени, и не имеют контроля. Вступает в силу распределение Пуассона, описывающее вероятность прихода определённого количества заявок за интервал времени.

Канал – то, что потребляет заявку. В классическом колл-центре канал – оператор. В цифровом сервисе каналом может выступать поток процессора (goroutine) или открытое TCP-соединение. Процесс обслуживания – время от момента, когда канал взял заявку, до момента освобождения.

Здесь кроется критическая ловушка: время обслуживания почти всегда является случайной величиной. Один клиент решит вопрос за минуту, другой за сорок. Среднее время удобно для отчётов, но дисперсия (разброс) времени обслуживания напрямую влияет на длину очереди.

Если все каналы заняты, заявка попадает в очередь. Очередь – буфер, который сглаживает пики нагрузки. Однако очередь не живёт сама по себе. Существует дисциплина обслуживания – набор правил, по которым система выбирает, кого обслужить следующим:

FIFO (First In, First Out) – кто первый пришёл, тот первый обслужен.

Приоритетное обслуживание – когда VIP-клиент или экстренный вызов обходит очередь. Приоритеты могут быть статичными (по типу клиента) или динамичными (когда приоритет растёт по мере ожидания).

LIFO – редкий случай, когда последняя пришедшая заявка обрабатывается первой (часто встречается в некоторых компьютерных стеках).

Уровень терпимости — самый сложный параметр для расчёта в ТМО. Человек не пакет данных, у него есть предел ожидания. Если очередь слишком длинная, клиент вешает трубку или закрывает приложение. Ограничения характеризуются как «система с ограниченным временем ожидания».

Задача архитекторов – рассчитать систему так, чтобы время ожидания не превышало порог терпимости основной массы пользователей. Иначе будут тратиться ресурсы на обслуживание «разозлённых» клиентов, которые уже не лояльны или потеря клиентов с высокой маржой.

В зависимости от того, как настроены правила, колл-центр может превратиться в одну из следующих систем:

Системы с отказом (Loss Systems): если свободного канала нет, заявка просто исчезает. Клиент слышит короткие гудки. Это самая простая и самая жёсткая модель. Здесь считается вероятность того, что клиент вообще не дозвонится.

Системы с ожиданием (Queue Systems):

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

С ограниченным ожиданием: когда мы принудительно разрываем соединение через 5 минут или когда клиент сам уходит.

Марковские системы: системы с «отсутствием памяти». Вероятность того, что произойдёт переход из одного состояния в другое (например, из «все свободны» в «один занят»), зависит только от текущего состояния, а не от того, что было час назад.

Немарковские системы: здесь важна предыстория. Если операторы устают к концу смены, время обслуживания начинает расти. Системы с предпосылками, и их расчёт требует сложных имитационных моделей.

Для прогнозирования нужно понимать ключевые показатели производительности. Нельзя просто сказать «нам нужно 100 человек». Мы должны знать:

Среднее число заявок, обслуженных за единицу времени — пропускная способность

Средняя доля времени простоя. Если операторы заняты 100% времени, очередь будет расти до бесконечности. Здоровая система всегда имеет «запас тишины»

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

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

Чтобы понять, как классическая теория работает в цифровой среде, рассмотрим пример тестирования мессенджера. Идеальный кейс, где каналами являются горутины и HTTP-воркеры, а заявками – события обмена сообщениями. Система построена на распределённых Go-бекендах.

Главная проблема – экспоненциальный рост нагрузки. При росте числа серверов (N) количество событий DispatchToPeer растет как O(N2). Классическая «замкнутая система» с ограниченным количеством состояний, где каждый новый узел добавляет нагрузку на все остальные.

Прежде чем считать очередь, нужно понять возможности одного канала. Тестирование показало, что на базовом уровне (HTTP transport) система идеальна: 2000 RPS (запросов в секунду) проходят с нулевыми ошибками. При 50-100 RPS задержка выше (300+ мс), чем при 500+ RPS (125 мс).

В теории систем явление называется состоянием выхода на стационарный режим. Холодный пул соединений Postgres – аналог оператора, который только пришёл на смену и ещё не разложил документы. Как только «каналы» (соединения с БД) открыты, система стабилизируется.

Здесь можно увидеть магию ТМО в действии. Запускаем воркеры парами. Каждая пара – два пользователя, обменивающихся сообщениями. Результат: при достижении всего 28 пользователей (14 пар) время отклика (RPC) пробивает порог в 500 мс (SLO). CPU при этом загружен всего на 30%.

С точки зрения классического менеджера – ресурсов ещё полно. С точки зрения ТМО – возник затор в дисциплине обслуживания. Увеличиваем нагрузку до 960 пользователей. Система не падает, ошибок нет. Но RPC достигает 16 секунд. Это пример Graceful Degradation.

Система обслуживает всех, но время ожидания в очереди (очереди горутин и event-bus) становится фатальным для пользователя. Пользователь видит «вечное ожидание», хотя сервер считает, что успешно выполняет задачу. Анализ показал, что бутылочное горлышко – механизм Long-Poll:

Каждая сессия – занятый канал

Поскольку соединение удерживает всё время ожидания события, количество «заблокированных» каналов растёт линейно с количеством пользователей

При 480 парах занято 960+ каналов ожидания

CPU простаивает, потому что каналы ничего не вычисляют, а просто «стоят в очереди» на получение события из event-bus

Построение колл-центра или высоконагруженного мессенджера – не покупка мощного железа. Это управление очередями. Добавление ядер не поможет, если дисциплина обслуживания (Long-Poll) неэффективна. Для исправления ситуации необходимо изменить природу канала:

Переход на WebSocket: позволит одному каналу обслуживать тысячи заявок в асинхронном режиме

L7 Балансировка: распределение заявок между каналами (серверами) на основе реальной загрузки

Backpressure: внедрение механизмов обратного давления, чтобы система могла сказать «стоп» до того, как RPC достигнет 16 секунд

Математика Эрланга и Гнеденко работает так же, как и сто лет назад. Разница лишь в том, что сегодня «оператор» – горутина, а «телефонная трубка» – смартфон с HTTP-запросом. Но законы вероятности и коридоры ожидания неизменными. Не понимаете очередь, не управляете системой.