11.3 Теория массового обслуживания

Обзор и мотивация

Теория массового обслуживания это математическое изучение очередей ожидания. В программной инженерии это тихая теория за огромным объёмом практики. Отзывчивость службы поддержки клиентов, планирование канбан (метод вытягивания, ограничивающий незавершённую работу ради улучшения потока), межпроцессные очереди сообщений, конвейеры непрерывного развёртывания: всё это очереди, и все они подчиняются одним законам. Понимание этих законов позволяет команде рассуждать о временах выполнения, пропускной способности, мощности и истинной цене работы систем у предела, вместо того чтобы удивляться им в производстве. Эта глава стоит в части о потоке, потому что теория массового обслуживания формальный фундамент потока: она объясняет, почему работа ждёт и что на самом деле сокращает ожидание.

Вот мотивация: интуиция об очередях надёжно неверна, и неверна дорогими способами. Люди полагают, что сервер с загрузкой 90% «в 10% от беды», тогда как на деле время ожидания взрывается нелинейно по мере приближения загрузки к 100%. Они полагают, что добавление незавершённой работы (WIP) ускоряет поставку, тогда как оно удлиняет время выполнения. Они планируют мощность по средним значениям, затем разбиваются об изменчивость. Немного теории массового обслуживания заменяет эти дорогие интуиции небольшим числом надёжных соотношений, важнейшее из них закон Литтла, справедливых одинаково для клиентских очередей, досок задач и конвейеров CI/CD.

Для больших команд, корпораций и государства теория массового обслуживания общий язык для мощности и потока, связывающий роли, которые иначе говорят мимо друг друга. Менеджеров по продукту заботит время выполнения от идеи до клиента. SRE заботит загрузка серверов и задержка. Команды DevOps заботит частота развёртываний. Руководителей поддержки заботят времена ответа. Это всё метрики очередей, и выражение их в одной рамке (интенсивность поступления, интенсивность обслуживания, загрузка, время ожидания) позволяет организации планировать мощность, задавать реалистичные SLO (целевые уровни обслуживания) и обосновывать вложения математикой, а не анекдотами.

Ключевые принципы

Всё, где есть ожидание, очередь: включая заявки, задачи, сообщения и развёртывания.
Закон Литтла якорь: элементов в системе = интенсивность поступления × время в системе (κ = λτ).
Загрузка и время ожидания нелинейны: последние 15% мощности самые дорогие.
Изменчивость враг потока: средние скрывают боль; дисперсия создаёт очереди.
Снижение незавершённой работы снижает время выполнения: цель поток, а не занятость.
Измеряйте весь поток: поступления, обслуживание, успехи, сбои, пропуски и ожидания.
Процесс это очередь очередей: моделируйте стадии, затем оптимизируйте ограничивающую.

Рекомендации

Выучите основные обозначения и используйте их последовательно

Горстка величин описывает любую очередь. Стандартизация на них (греческие буквы условны) снимает неоднозначность между командами:

λ (лямбда), интенсивность поступления: как быстро входят новые элементы.
μ (мю), интенсивность обслуживания: как быстро элементы обрабатываются. Поскольку «интенсивность обслуживания» используется неоднозначно, нередко стоит явно разделить пропускную способность на общую интенсивность (χ), интенсивность успехов (α), интенсивность сбоев (β) и интенсивность пропусков (σ), где χ = α + β + σ.
ρ (ро), загрузка / интенсивность трафика = λ / μ: важнейшая отдельная сводка. ρ < 1 означает, что очередь опустошается; ρ ≥ 1 означает, что она растёт без границ.
Времена: время выполнения (τ, от начала до конца), рабочее время (φ, фактическая обработка), время ожидания (ω, в ожидании) и время шага (θ, между завершениями).
ε (эпсилон), доля ошибок: сбои ÷ всего.

Явное называние сбоев и пропусков важно в программном обеспечении: элемент, который оставлен (клиент, сдавшийся, брошенная корзина, отклонённая заявка), покидает очередь, не будучи обслуженным, а притворство, что он «обслужен», искажает ваши метрики. Отслеживайте отказ присоединиться (balking, решение не вставать в очередь), уход из очереди (reneging, сдача после ожидания) и перепрыгивание (jockeying, смена очереди) как первоклассные исходы.

Опирайте планирование на закон Литтла

Закон Литтла утверждает, что долгосрочное среднее число элементов в устойчивой системе равно средней интенсивности поступления, умноженной на среднее время, которое каждый элемент проводит в системе: κ = λ τ (классически L = λW). Он поразительно общ (не требует допущений о распределении поступлений или порядке обслуживания), что делает его рабочей лошадкой планирования потока. В переписанном виде он говорит, что время выполнения = незавершённая работа ÷ пропускная способность. Это математическая основа канбан и бережливости: если вы хотите более короткое время выполнения и не можете поднять пропускную способность, нужно снизить WIP. Он также даёт быстрые проверки здравого смысла. Если открыто 40 заявок, а вы закрываете 8 в день, средняя заявка занимает около 5 дней, как бы заняты ни ощущали себя все. Его единственное требование устойчивость: поступления не должны постоянно превышать выбытия (ρ < 1), иначе очередь и допущения закона рушатся.

Уважайте нелинейность загрузки

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

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

Следствие для проектирования: намеренно закладывайте запас. Нацеливание на загрузку 70–80% для чувствительных к задержке систем не потери; это покупка предсказуемого времени отклика. Это прямо информирует планирование мощности и SLO (главы 3.5 и 9.1).

Моделируйте процессы как очередь очередей

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

Воронки, где число элементов сжимается на каждой стадии (найм: охват → собеседование → предложение; закупки: просмотр → корзина → оплата; поставка: интеграция → приёмка пользователем → производство). Оптимизируйте стадию, которая важнее всего: максимизируйте поступления на входе воронки, минимизируйте пропуски в середине (брошенные корзины) или минимизируйте ошибки на последней стадии (плохие выкатки в производство).
Потоки исследования и поставки «двойной алмаз» (исследовать → определить → разработать → поставить), которые часть о потоке этой книги рассматривает напрямую (глава 11.1).

Нахождение и разгрузка ограничивающей стадии (узкого места) то, где улучшение потока окупается; оптимизация неограничивающих лишь перемещает очередь.

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

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

Время выполнения поставки (Dτ), «от замысла до клиента», это мера времени выполнения (τ) и метрика DORA (DevOps Research and Assessment) (глава 11.2).
Частота развёртываний (Dμ) это мера интенсивности обслуживания.
Доля неудачных изменений (Dε) это доля ошибок.
Время восстановления (Rτ) это время выполнения восстановления, то есть MTTR (глава 9.3).

Различайте несколько MTTR (среднее время до реакции, ремонта, восстановления и разрешения), потому что они измеряют разные сегменты очереди инцидентов и рутинно смешиваются. Опирание SLI/SLO/SLA (глава 9.1) на термины очередей держит цели честными и сопоставимыми.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
Работа систем при высокой загрузке	Меньше цена оборудования/единицы	Нелинейные взрывы задержки; хрупкость к всплескам
Щедрый запас мощности	Предсказуемая задержка; устойчивость к дисперсии	Выше цена в установившемся режиме; выглядит «недоиспользованным»
Ограничение WIP (канбан)	Короче время выполнения; меньше переключений контекста	Ощущается медленнее; нужна дисциплина удерживать лимит
Формальное моделирование очередей	Квантифицированные решения о мощности; меньше сюрпризов	Кривая обучения; модели упрощают неопрятную реальность
Только эмпирические правила	Быстро, без математики	Неверны именно там, где дороже всего (у предела мощности)

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

Вопросы для обсуждения с командой

Какова ваша явная целевая загрузка для каждой чувствительной к задержке системы и кто её утвердил? Запас это намеренная покупка предсказуемой задержки, поэтому он должен быть заявленной политикой, а не случайностью той нагрузки, что оказалась. Поскольку время отклика растёт нелинейно, работа при 85% уже может означать повышенную хвостовую задержку, однако финансы видят запас как потери и толкают загрузку вверх. Принесите числа: текущую загрузку, измеренную кривую задержки и цену вашего последнего инцидента с задержкой, затем покажите, где лежит обрыв для каждого сервиса. Для корпоративных и государственных систем с сезонными пиками (сезон подачи деклараций, окна зачисления) задавайте цель от обрыва для пика, а не среднего. Если никто не владеет целевой загрузкой, инциденты с задержкой будут продолжать появляться «из ниоткуда».
Где в ваших системах очередь неограничена, без обратного давления для сброса нагрузки при перегрузке? Неограниченная очередь не отказывает изящно; она деградирует в коллапс, потому что поступления, постоянно превышающие выбытия (ро >= 1), означают, что очередь растёт без предела. Составьте опись ваших очередей сообщений, пулов потоков и буферов запросов и спросите, что происходит в каждой, когда интенсивность поступления превышает интенсивность обслуживания: сбрасывает ли она нагрузку, применяет обратное давление или падает? Это остро важно в корпоративном масштабе, где одна насыщенная нижестоящая система может каскадом пройти по сервисам. Принесите результат нагрузочного теста или прошлый инцидент, где очередь накопилась, и проверьте, отклонила ли система избыточную работу или пыталась удержать всю. Исправление ограниченные очереди с явным обратным давлением и тайм-аутами, выведенными из закона Литтла, чтобы перегрузка сбрасывалась, а не опрокидывала.
Моделируете ли вы поток от идеи до производства как очередь очередей и нацелены ли ваши улучшения на настоящее ограничение? Многостадийный процесс это очередь, чьи элементы стоят в очереди на каждой стадии, а оптимизация чего-либо, кроме ограничивающей стадии, лишь перемещает очередь. Картируйте вашу воронку поставки (интеграция, приёмка пользователем, производство или исследовать, определить, разработать, поставить) и измеряйте интенсивности поступления, обслуживания, ожидания и пропусков на каждой стадии, чтобы найти, где работа на самом деле копится. Команды рутинно оптимизируют стадию, которую понимают лучше всего, а не узкое место, что тратит усилия и ничего не двигает. Принесите данные о времени ожидания по стадиям, а не чутьё, потому что узкое место нередко состояние ожидания (рецензия, одобрение, доступность окружения), а не состояние работы. Узнав ограничение, нацельтесь туда и оставьте неограничивающие в покое.
Используете ли вы закон Литтла для задания лимитов WIP или добавляете мощность, чтобы лечить времена выполнения, которые исправила бы только дисциплина? Закон Литтла говорит, что время выполнения равно незавершённой работе, делённой на пропускную способность, так что, если вы не можете поднять пропускную способность, единственный оставшийся рычаг для более коротких времён выполнения снижение WIP, что не стоит ничего, кроме сдержанности. Конкурирующая тяга реальна: ограничение незавершённой работы ощущается медленнее и праздно, а руководители под давлением предпочли бы нанять или купить оборудование, чем сказать командам начинать меньше и заканчивать больше. Принесите жёсткие числа, текущие открытые элементы и интенсивность завершения по стадиям, и вычислите подразумеваемое среднее время выполнения, затем сравните с тем, что люди считают; разрыв обычно большой и неловкий. В большой корпорации или ведомстве запрос на найм или закупку, обоснованный как исправление времени выполнения, следует сначала проверить этой арифметикой, потому что рост штата, повышающий WIP, может удлинить те самые времена, которые должен был сократить.
Планируете ли вы мощность по средним или квантифицировали изменчивость, на самом деле создающую ваши очереди? Очереди образуются из дисперсии, а не из среднего, поэтому две системы с одинаковой средней нагрузкой могут вести себя совершенно по-разному, если у одной всплесковые поступления или длиннохвостые времена обслуживания. Напряжение в том, что средние легко собрать и успокаивающе сообщать, тогда как дисперсию и хвост труднее измерить и нежелательно включать в обновление статуса. Принесите распределение, а не среднее: всплесковость поступлений, 95-й и 99-й процентили времён обслуживания и ожидания и размеры партий, концентрирующие работу в пики. Для корпоративных и государственных систем с предсказуемыми всплесками (сезон подачи деклараций, расчёт зарплаты, окна зачисления, нагрузки конца квартала) планируйте буфер и целевую загрузку от дисперсии пикового периода, потому что проект, рассчитанный на годовое среднее, откажет именно тогда, когда на него смотрит общество.
Какие из ваших очередей молча считают уходы и отклонения так, словно работа была обслужена, и какой неудовлетворённый спрос это скрывает? Элемент, который отказался присоединиться, ушёл из очереди или был отклонён, покидает очередь необработанным, а запись его как «обслуженного» одновременно искажает вашу пропускную способность, долю ошибок и план мощности. Конкурирующее соображение в том, что «отвеченные звонки» или «закрытые заявки» выглядят на панели лучше, чем «позвонившие, которые сдались», поэтому честное число то, которое никто не вызывается показать. Принесите интенсивность пропусков (σ), счётчики отказов и уходов и разницу между предложенной нагрузкой и обслуженной, чтобы истинный спрос стал видим. Это резко важно в предоставлении государственных услуг, где граждане, бросившие телефонную очередь или заявление на пособие, это неисполненные обязательства, а не разрешённые дела, и сообщение о них как об обработанных одновременно искажает эффективность и занижает мощность, которой общество обязано.

Взгляд по секторам

Стартап. У вас нет времени на формальное моделирование очередей и нет в нём нужды. Сначала возьмите две самые дешёвые победы: примените закон Литтла к бэклогу, чтобы увидеть реальное время выполнения, подразумеваемое вашим WIP, и следите за доской канбан на стадию, где копится работа, прежде чем нанимать против узкого места, которого может не быть. Держите загрузку вдали от обрыва на любом чувствительном к задержке пути, оставляя запас, а не подстраивая, потому что сбой во время всплеска роста стоит гораздо больше небольшой простаивающей мощности.

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

Крупная организация. Работа в том, чтобы сделать мышление очередями общей дисциплиной по многим командам: одни согласованные обозначения (λ, μ, ρ, время выполнения), последовательные политики WIP и запаса загрузки и стандарты обратного давления, чтобы насыщенная нижестоящая система не могла каскадом пройти по сервисам. Задавайте SLO и мощность из анализа очередей, а не догадок, и управляйте вашими очередями как портфелем с базовыми значениями и рецензиями, чтобы ни одна команда не работала горячо в изоляции. Впекайте анализ в управление мощностью и аудит, чтобы целевой запас был документированным решением, которым кто-то владеет.

Государственный сектор. Закупки, прозрачность и общественная подотчётность формируют каждый выбор мощности. Рассчитывайте контакт-центры и системы для граждан от дисперсии пикового периода (сезон подачи деклараций, окна зачисления), а не годового среднего, и комплектуйте штат так, чтобы держать загрузку вдали от обрыва при всплесках спроса. Отслеживайте отказы и уходы как неудовлетворённый общественный спрос, а не прячьте их внутри «отвеченных звонков», и обосновывайте расходы на мощность оценками времени ожидания по закону Литтла, дающими аудиторам и выборным должностным лицам защитимый, подкреплённый математикой довод вместо анекдота.

Примеры

Стартап. Команда SaaS из пяти человек, тонущая в бэклоге поддержки, полагает, что ей нужно нанять ещё одного агента. Прежде чем тратить деньги, они применяют закон Литтла: 60 открытых заявок и 12 закрытых в день означают, что средняя заявка ждёт около 5 дней, что совпадает с сердитыми письмами. Наблюдая за доской канбан, они замечают, что заявки копятся в ожидании инженерии, а не поддержки, поэтому ограничивают незавершённую работу и направляют сообщения об ошибках прямо в спринт, а не позволяют им стоять в очереди. Время выполнения падает до менее двух дней без нового найма, а освободившийся бюджет они тратят на настоящее узкое место.

Крупная организация. Платёжная платформа, рассчитывающая сервис авторизации, измеряет λ ≈ 850 запросов/секунду и μ на узел ≈ 200/секунду. Наивно это ~5 узлов (ρ = 0,85), но зная, что ρ = 0,85 уже означает резко повышенную хвостовую задержку, команда закладывает ρ ≈ 0,65 и использует закон Литтла для предсказания числа запросов в полёте и задания глубины очередей и тайм-аутов. Пиковосезонные инциденты, раньше появлявшиеся «из ниоткуда», исчезают, потому что команда больше не работала на крутой части кривой.

Государственный сектор. Контакт-центр налоговой службы моделирует поддержку в сезон подачи как очередь: всплески поступлений (λ), мощность агентов (μ) и, критично, интенсивность пропусков (σ) граждан, бросающих трубку после долгого ожидания. Отслеживая отказы и уходы, а не только «отвеченные звонки», руководство видит истинный неудовлетворённый спрос, комплектует штат, чтобы держать загрузку вдали от обрыва в пики, и обосновывает дополнительную мощность оценками времени ожидания по закону Литтла, защитимым, подкреплённым математикой доводом в пользу общественных расходов, а не анекдотическим.

Бизнес-обоснование: мотивы, ROI и TCO

Теория массового обслуживания окупается, предотвращая две дорогие ошибки: избыточное обеспечение (оплата простаивающей мощности, которая была не нужна) и, гораздо вреднее, недостаточное обеспечение у обрыва (где малые приросты нагрузки вызывают большую задержку, нарушенные SLA, ушедших клиентов и аварийные расходы). Поскольку цена работы около 100% загрузки нелинейна, экономия от «просто добавить немного нагрузки» мала, а негативный сценарий катастрофичен, именно та асимметрия, которую немного математики превращает в намеренное решение. Отдача измеряется избегнутыми сбоями, соблюдёнными SLA, удержанными клиентами, которые иначе отказались бы присоединиться, и спокойными дежурствами.

По совокупной стоимости владения рамка дёшева во внедрении (это знание, а не инструменты) и улучшает почти каждое решение о мощности, задержке и потоке, которое большая организация принимает за жизнь системы. Закон Литтла и лимиты WIP сокращают времена выполнения, ничего не покупая (чистая победа процесса), а дисциплина загрузки обменивает скромную предсказуемую цену установившегося режима на устранение дорогих непредсказуемых сбоев. Чтобы обосновать перед руководством, переведите недавний инцидент с задержкой на кривую загрузки и покажите, как целевой запас предотвратил бы его, и используйте закон Литтла, чтобы напрямую связать снижение WIP с более быстрой поставкой.

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1, Начальный: Очереди (заявки, задачи, сообщения, развёртывания) неуправляемы и реактивны; мощность угадывается; загрузка идёт туда, куда ляжет нагрузка; проблемы с задержкой удивляют команду и тушатся постфактум.
Уровень 2, Развитие: Несколько команд собирают базовые метрики (пропускная способность, среднее ожидание), но читают их как средние и применяют непоследовательно; некоторые группы ограничивают WIP или оставляют запас, а другие работают горячо; нет общих обозначений, поэтому практики не переходят между командами.
Уровень 3, Стандартизация: Общие обозначения (λ, μ, ρ, время выполнения) документированы и принуждаются по организации; лимиты WIP и цели запаса загрузки задаются намеренно для каждой чувствительной к задержке системы; различаются несколько MTTR; ограниченные очереди с обратным давлением по умолчанию по сервисам.
Уровень 4, Управление: Очереди измеряются и контролируются относительно базовых значений: интенсивность поступления, интенсивность обслуживания, загрузка, хвостовая задержка (p95/p99) и время выполнения отслеживаются относительно определённых целей и SLO; глубина очередей, тайм-ауты и запас выводятся из закона Литтла, а не угадываются; отказы, уходы и интенсивность пропусков считаются, так что предложенная нагрузка отличается от обслуженной; решения о мощности рецензируются на этих свидетельствах, а не по ощущению.
Уровень 5, Оркестрация: Поток непрерывно моделируется как очередь очередей; узкие места выявляются и разгружаются как текущая практика; мощность, SLO и обратное давление адаптируются к сдвигам спроса и дисперсии; метрики очередей напрямую связаны с DORA и бизнес-KPI, а организация перебалансирует мощность по всему потоку по мере изменения картины нагрузки и риска.

Идеи для обсуждения

На какой загрузке на самом деле работают ваши чувствительные к задержке системы и где их обрыв?
Примените закон Литтла к текущему бэклогу: какое время выполнения подразумевает ваш WIP ÷ пропускная способность и совпадает ли оно с реальностью?
Какие из ваших очередей молча считают «пропуски» (уходы, отклонения) так, словно они обслужены?
Где снижение WIP сократило бы время выполнения дешевле, чем добавление мощности?
Какая стадия в вашем потоке от идеи до производства настоящее узкое место и нацелены ли туда ваши улучшения?
Показывают ли ваши панели средние там, где на самом деле больно хвост?

Главные выводы

Клиентские очереди, доски канбан, очереди сообщений и конвейеры развёртывания все очереди, управляемые одними законами.
Закон Литтла (κ = λτ) якорь планирования потока: время выполнения = WIP ÷ пропускная способность.
Загрузка и время ожидания нелинейны: закладывайте запас; последние 15% самые дорогие.
Отслеживайте полную картину: поступления, обслуживание, успехи, сбои и пропуски и ожидания; не позволяйте уходам прятаться.
Моделируйте процессы как очередь очередей и чините узкое место, а не занятость.
Метрики очередей напрямую отображаются на меры DORA/потока и SLI/SLO (главы 11.1, 11.2, 9.1), давая всей организации один язык для мощности и потока.

Источники и дополнительное чтение

Bob Wescott, Seven Insights into Queueing Theory (and The Every Computer Performance Book).
John D. C. Little, “A Proof for the Queuing Formula L = λW” (1961): Little’s Law.
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: flow-based DORA metrics that align with queue KPIs.
Donald Reinertsen, The Principles of Product Development Flow: queues, batch size, and WIP economics.
Daniel Vacanti, Actionable Agile Metrics for Predictability: Little’s Law applied to kanban.
Joel Parker Henderson, Queueing Theory: notation, KPIs, and queue-of-queues (github.com/joelparkerhenderson/queueing-theory).
Dan Slimmon, “The most important thing to understand about queues” (2016).
Wikipedia: “Queueing theory,” “M/M/1 queue,” “Little’s law,” “Markov chain.”