Задержки: главный источник неожиданного поведения

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

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

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

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

Что такое задержка в системном смысле

Задержка — это время между изменением в одной части контура и проявлением этого изменения в другой. Не «медленно работает», а именно «эффект приходит позже причины».

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

Четыре разные задержки, четыре разных лечения:

Последняя строка — самая важная. Задержку эффекта задаёт физика системы, а не ваш инструментарий. Новый инженер не станет продуктивным за неделю, потому что вы ускорили найм. JIT-компилятор не прогреется быстрее, потому что вы уменьшили окно метрики. Когда задержку нельзя сократить, остаётся менять поведение контура — об этом ниже.

Механика: почему задержка превращает регулирование в колебания

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

Без задержки регулятор видит текущее отклонение и подрезает его. Отклонение уменьшается, реакция уменьшается, система плавно садится на цель.

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

Псевдокод контура — ровно три строчки, но именно они порождают всю картинку:

на каждом такте:
    seen     <- состояние_запаса(t - задержка)     # регулятор видит прошлое
    мощность <- поток_прогноз + усиление * (seen - цель)
    запас    <- запас + приток - min(запас + приток, мощность)

Реализация, на которой можно поиграть параметрами:

from collections import deque


def simulate(steps=120, delay=3, gain=0.5, rate=10.0, target=200.0):
    """Очередь плюс автоскейлер.

    delay  — суммарная задержка контура в тактах: от изменения очереди
             до момента, когда контур на это изменение отреагировал.
    gain   — усиление: какую долю отклонения регулятор пытается снять за такт.
    rate   — сколько задач обрабатывает один воркер за такт.
    """
    queue = target                          # запас: длина очереди
    arrivals_prev = 100.0                   # оценка входящего потока (лаг в один такт)
    pipeline = deque([queue] * (delay + 1))  # «труба», по которой едет наблюдение
    history = []

    for t in range(steps):
        arrivals = 100.0 if t < 20 else 140.0   # ступенька нагрузки на 20-м такте

        seen = pipeline.popleft()               # регулятор видит состояние из прошлого
        pipeline.append(queue)

        # сколько воркеров нужно: покрыть поток и подрезать отклонение очереди
        workers = max(1.0, (arrivals_prev + gain * (seen - target)) / rate)

        served = min(queue + arrivals, workers * rate)
        queue = queue + arrivals - served        # запас интегрирует разницу потоков
        arrivals_prev = arrivals

        history.append((t, queue, workers))

    return history

Сложность: O(steps) по времени, O(delay) по памяти — вся «труба» и есть память системы о её собственном прошлом.

Что показывает прогон (числа ниже получены на этом коде, воспроизводятся):

Отсюда — первое проверяемое предсказание.

Правило четырёх задержек. Для уравновешивающего контура с одним накапливающим запасом и чистым запаздыванием период автоколебаний вблизи границы устойчивости составляет примерно четыре суммарные задержки контура. Более мягкая реакция даёт период больше; меньше 4τ он практически не бывает.

Это не метафора, а следствие фазового баланса: интегрирующий запас даёт сдвиг фазы на 90°, чистое запаздывание — ещё 90°, когда оно равно четверти периода. Суммарно 180° — обратная связь из отрицательной становится положительной. Строгий разбор — в любом курсе теории управления, например в свободно доступной книге Åström & Murray «Feedback Systems».

Практическая ценность правила в том, что оно работает в обе стороны:

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

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

Виды задержек: их надо различать, иначе лечить будете не то

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

Полезно различать два механизма запаздывания — они по-разному лечатся:

Материальная задержка (труба). Что вошло, то выйдет, но позже. Конвейер, очередь на репликацию, кандидат в пайплайне найма, задача в спринте. Сигнал не искажается, а сдвигается. Единственный способ уменьшить — укоротить трубу или ускорить движение по ней.

Информационная задержка (сглаживание). Значение подтягивается к новому уровню постепенно: оценка = оценка + α * (наблюдение - оценка). Так работают экспоненциальные скользящие средние, оконные агрегаты, «ощущение команды по поводу качества релизов». Сигнал не только сдвигается, но и сглаживается: пики срезаются. Средняя задержка такого фильтра — примерно 1/α тактов; для окна в N точек — около N/2.

Отсюда ловушка, на которую регулярно наступают: длинное окно метрики — это не «стабильнее», это «медленнее». rate(errors[5m]) вносит в контур задержку порядка двух с половиной минут. Если такой сигнал заводят в автоматическое действие, эти минуты складываются с остальными и вполне могут вытолкнуть контур за границу устойчивости. Документация Prometheus по rate() прямо предупреждает про сглаживание длинных окон.

Отдельно — порог дискретизации. Если состояние опрашивается раз в T, колебания с периодом меньше 2T вы не увидите в принципе (это та же теорема Найквиста, что и в обработке сигналов). Скрейп раз в минуту и колебание с периодом 90 секунд дадут на графике не пилу, а случайный шум или ложный медленный тренд. Прежде чем объяснять «странное поведение», проверьте, не наблюдаете ли вы алиасинг.

Бюджет задержки контура

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

Пример: автоматическое масштабирование по очереди в Kubernetes.

Значения по умолчанию — из документации HPA; в вашем кластере проверьте фактические.

Из таблицы сразу читаются две вещи, которые обычно обнаруживают эмпирически и дорого:

1. Контур асимметричен. Вверх он реагирует за 3 минуты, вниз — за 8. Это сделано намеренно, и это правильно: разгон дешевле, чем схлопывание. Но означает, что «пила» будет несимметричной, с длинными плато на спаде.
2. Ожидаемый период колебаний — 12–16 минут (четыре задержки на увеличение). Если в графиках качание с периодом порядка часа, причина не здесь: ищите более длинный контур — кулдаун алерта, ручное вмешательство, ночной джоб.

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

Инженерные примеры

Кэш: задержка инвалидации и стадо

TTL — это задержка, встроенная в контур согласованности данных. Пока он не истёк, система работает по устаревшему представлению — ровно как регулятор, видящий прошлое.

Два разных эффекта, которые путают:

• Сдвиг данных. Пользователь видит состояние, которого уже нет. Лечится инвалидацией по событию, а не временем.
• Синхронизация. Если много ключей записаны одновременно (после деплоя, после прогрева, после массового импорта), они и протухнут одновременно. За этой задержкой стоит не сдвиг, а совпадение фаз: тысяча запросов уходит в базу в одну секунду. Лечение — джиттер TTL и single-flight, а не уменьшение TTL. Уменьшение TTL здесь делает хуже: частота синхронных всплесков растёт.

Подробности по механике кэша — в главе про кэширование трека «Производительность».

Ретраи: задержка обнаружения превращает деградацию в отказ

Разбор по шагам:

1. База деградирует. Ничего страшного пока не произошло — просто выросла латентность.
2. Клиентский таймаут короче, чем реальное время ответа. Работа, которую база уже делает, никому не нужна, но она продолжается — это потерянная работа, чистая задержка без пользы.
3. Каждый повтор добавляет нагрузку до того, как система успела показать, что ей плохо. Задержка обнаружения работает на усиливающий контур.
4. Контур из уравновешивающего («повторим, вдруг это был случайный сбой») стал усиливающим.

Ключевое здесь: проблема не в ретраях, а в том, что решение о ретрае принимается по устаревшему представлению о состоянии зависимости. Поэтому работают именно те лекарства, которые сокращают задержку восприятия или разрывают контур: circuit breaker (быстрый сигнал «не надо»), бюджет ретраев на клиента, экспоненциальная выдержка с джиттером, отмена уже ненужной работы. Эталонные разборы — «Timeouts, retries, and backoff with jitter» в AWS Builders’ Library и глава «Addressing Cascading Failures» в SRE-книге Google. Про гарантии доставки и идемпотентность повторов — соответствующая глава трека «Распределённые системы», про сами паттерны устойчивости — «Resilience patterns».

Найм: контур с задержкой в полгода

От «нам тяжело» до «нам легче» — примерно семь месяцев, причём первые два месяца после выхода человека команде становится тяжелее: наставничество отъедает время сильнее, чем добавляет новый инженер. Это и есть «закон Брукса» из «Мифического человеко-месяца» Брукса (1975), только сформулированный как контур с задержкой и отрицательной начальной фазой.

Что предсказывает модель, и это можно проверить по своей истории:

• Если нанимать реактивно, по факту перегрузки, помощь придёт после пика — часто уже к спаду. Классическая пила: то перегрузка, то избыток.
• Чем длиннее контур, тем более сглаженный сигнал нужно в него заводить. Реагировать на недельный всплеск задач контуром с задержкой в семь месяцев — гарантированные колебания.
• Наём под пик и наём под тренд — разные решения. Первый почти всегда ошибка структуры, а не расчёта.

Практические разборы самого процесса — в главе про найм и про онбординг трека «Инженерное лидерство».

Технический долг: задержка, которую почти никто не замыкает

Срезали угол сегодня — скорость упадёт через месяцы. Этот контур особенно коварен по трём причинам сразу:

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

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

Честная пометка: связь «срезанный угол → падение скорости через N месяцев» на уровне отдельной команды — гипотеза, а не измеренный факт. Отраслевые данные (например, отчёты DORA) показывают корреляции между практиками и результатами, но это не то же самое, что причинная оценка для вашего кода. Что с этим делать — в разделе про проверку.

Дежурство: контур с самой длинной задержкой

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

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

Как задержка усиливается по цепочке

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

Это тот же эффект, что в цепочках поставок известен как bullwhip — «эффект хлыста». У него есть измеренная эмпирическая база, а не только красивая схема:

• Джон Стерман в эксперименте с Beer Distribution Game (Management Science, 1989) показал на сотнях участников, что издержки участников многократно превышают оптимум, и главный источник ошибки — систематическая недооценка уже заказанного, но ещё не пришедшего. Люди не учитывают то, что находится «в трубе».
• Ли, Падманабхан и Ванг (Management Science, 1997) разобрали структурные причины усиления в реальных цепочках: пакетирование заказов, реакция на цены, рационирование при дефиците, обновление прогноза.

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

1. Учитывать «в пути» явно: желаемое = потребность − (уже заказанное и ещё не прибывшее).
2. Не давать одному контуру заказывать чаще, чем приходит результат предыдущего заказа. Кулдаун не меньше времени полного эффекта.

Что делать с задержкой: пять стратегий по убыванию силы

Три замечания, без которых таблица опасна.

Снижение усиления почти всегда недооценено. Оно не требует ни новой архитектуры, ни новых метрик, работает немедленно и обратимо. Кулдаун, гистерезис (разные пороги на вход и выход), ограничение шага изменения — три строчки конфига, которые чаще всего и лечат «пилу». Начинайте с них.

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

Буфер лечит симптом. Это нормально и часто правильно, но помните: буфер скрывает задержку от наблюдателя. Пока запас есть, вы не видите, что контур сломан. Поэтому буфер должен быть измеряемым: если вы не следите за его уровнем и трендом, вы просто отложили инцидент. Адаптивные лимиты конкурентности вроде Netflix concurrency-limits — пример подхода, где буфер сам подстраивается и при этом остаётся наблюдаемым.

Как проверить, что дело действительно в задержке

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

Ступенчатый тест — основной инструмент

Подайте контролируемое скачкообразное изменение и снимите отклик. Это стандартная процедура из теории управления, и она полностью применима к продакшену на нагрузочном стенде.

процедура ступенчатый_тест(контур, амплитуда):
    1. дождаться установившегося режима, записать базовую линию
    2. подать ступеньку известной амплитуды в момент t0
    3. писать состояние с шагом много меньше ожидаемой задержки
    4. измерить:
         мёртвое время     = t(первая реакция) - t0
         время нарастания  = t(63 % от нового уровня) - t(первая реакция)
         перерегулирование = (пик - новый уровень) / (новый уровень - базовая линия)
         период            = расстояние между соседними пиками
    5. сверить период с 4 * (мёртвое время + время нарастания)

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

Оценка лага по историческим данным — вспомогательный инструмент

Когда эксперимент невозможен, остаётся искать сдвиг в данных. Работает хуже, и надо понимать почему.

def lag_of_best_fit(cause, effect, max_lag=30):
    """Сдвиг L, при котором effect лучше всего объясняется cause,
    сдвинутым на L тактов назад. Возвращает (корреляция, лаг)."""

    def pearson(a, b):
        n = len(a)
        ma, mb = sum(a) / n, sum(b) / n
        num = sum((x - ma) * (y - mb) for x, y in zip(a, b))
        da = sum((x - ma) ** 2 for x in a) ** 0.5
        db = sum((y - mb) ** 2 for y in b) ** 0.5
        return num / (da * db) if da and db else 0.0

    return max(
        (pearson(cause[: len(cause) - lag], effect[lag:]), lag)
        for lag in range(max_lag + 1)
    )

Сложность: O(max_lag · n) по времени, O(n) по памяти.

Три ограничения, о которых надо сказать прямо, иначе метод превращается в генератор ложных выводов:

1. На колеблющихся рядах результат неоднозначен. Если оба ряда качаются с периодом T, сдвиги L, L + T, L + 2T дают почти одинаковую корреляцию. На прогоне модели выше, где истинная задержка контура равна 4 тактам, оценка даёт 5 при корреляции всего 0.31 — то есть формально «нашла», но с уверенностью, на которую нельзя опираться.
2. Общая причина. Оба ряда могут следовать за третьим (суточный профиль, релизный цикл), и тогда лаг отражает его структуру, а не связь между ними.
3. Корреляция с лагом — не причинность. Это ровно тот случай, который разбирается в главе про причинные и статистические ошибки трека «Логика». Лаг сужает круг гипотез (следствие не может опережать причину) и только.

Правильное использование: лаг — генератор гипотез, ступенчатый тест — их проверка.

Чек проверяемости модели

Перед тем как показывать кому-то диаграмму с задержками, ответьте на три вопроса:

1. Какое численное следствие она даёт? Период, время реакции, знак изменения, порядок величины. Если никакого — это иллюстрация, а не модель.
2. Какое наблюдение её опровергнет? Если ответа нет, схема совместима с любыми данными и не несёт информации.
3. Откуда взяты величины задержек? Измерены, оценены по бюджету или придуманы? Помечайте прямо на диаграмме: измеренные и придуманные числа выглядят одинаково, а стоят по-разному.

Пределы метода: где системная динамика работает, а где нет

Это раздел, который в большинстве материалов пропускают. Зря.

Что модель с задержками действительно предсказывает хорошо:

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

Что она предсказывает плохо или не предсказывает совсем:

• Точную амплитуду. Амплитуда чувствительна к нелинейностям, насыщениям и начальным условиям.
• Поведение после смены режима. Как только очередь упирается в ноль или пул соединений — в потолок, линейная интуиция перестаёт работать. Про это — следующая глава про нелинейность и пороги.
• Человеческие решения при изменении правил игры. Люди меняют поведение, узнав о модели. Метрика, ставшая целью, перестаёт быть метрикой — эффект, знакомый по главе про продуктовые метрики.
• Долгосрочные траектории при структурных изменениях. Модель предполагает, что структура постоянна. На горизонте, где меняется сама структура, её прогноз не имеет силы.

Честно про доказательную базу. Системная динамика выросла из работ Джея Форрестера — «Industrial Dynamics» (1961), «Urban Dynamics» (1969), «World Dynamics» (1971). Дальше история неоднозначна, и это важно знать.

• «Urban Dynamics» и особенно «Пределы роста» (Meadows et al., 1972, модель World3) вызвали содержательную критику. Самая известная — Уильям Нордхаус, «World Dynamics: Measurement Without Data» (The Economic Journal, 1973): модель богата структурой, но её параметры не оценены по данным, а поведение чувствительно к произвольным допущениям. Сборник «Models of Doom» (Cole et al., 1973) показал, что при других предположениях о технологическом прогрессе модель даёт качественно другие траектории.
• Спустя десятилетия появились работы, сравнивающие сценарии World3 с фактическими данными: Graham Turner (2008, Global Environmental Change) и Gaya Herrington (2021, Journal of Industrial Ecology) находят, что наблюдаемые ряды ближе к базовым сценариям, чем к оптимистичным. Эти работы тоже критикуются — за выбор рядов, за подгонку интервалов, за то, что «попадание в широкий сценарий» слабо отличается от отсутствия предсказания.
• Обе стороны спора по-своему правы, и это полезный урок для инженера. Структурная модель может верно указывать направление и механизм, оставаясь бесполезной для точечного прогноза. Модели, у которой не оценены параметры, нельзя доверять числа; модели, у которой не проверена структура, нельзя доверять и знаки.

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

Если хочется одного учебника, а не одной популярной книги, — это «Business Dynamics» Джона Стермана (2000): там и формальный аппарат, и главы про верификацию и тестирование моделей. «Thinking in Systems» Донеллы Медоуз (2008) — отличная точка входа, но это введение, а не доказательство; её же эссе «Leverage Points» (1999) прямо помечено автором как размышление, а не результат.

Типовые ловушки, связанные с задержкой

Перенос проблемы (shifting the burden). У симптоматического решения задержка короткая, у фундаментального — длинная. Ночной скрипт чинит рассинхрон за минуты; нормальная транзакционность — за кварталы. Контур с короткой задержкой всегда выигрывает конкуренцию за внимание. Проходит год — вокруг скрипта выросла отчётность, права доступа и три интеграции, и теперь фундаментальное решение стоит вдесятеро. Это не про лень: короткая задержка структурно побеждает длинную, если ничего не сделать специально.

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

Эскалация. Две команды поднимают таймауты и ретраи в ответ друг на друга. Каждая видит эффект действий другой с задержкой и приписывает ухудшение внешним причинам. Усиливающий контур, замаскированный под разумную реакцию. Диагностический признак: параметры устойчивости у всех участников только растут и никогда не возвращаются.

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

Локальная оптимизация задержки. Ускорили один этап конвейера — общая задержка не изменилась, потому что узкое место переехало. Более коварный вариант: ускорили этап перед узким местом и сделали хуже, потому что теперь очередь перед ним растёт быстрее. Тема развёрнута в главе про локальную оптимизацию.

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

Реакция на шум. Если период наблюдения короче задержки контура, каждое отклонение выглядит как тренд. Регулятор (человек или автоматика) начинает реагировать на шум и сам становится источником колебаний. Это ровно то, что Эдвардс Деминг демонстрировал экспериментом с воронкой: попытка корректировать процесс по каждому отдельному результату увеличивает разброс, а не уменьшает.

Чеклист

Когда система ведёт себя «странно»:

1. Нарисовать контур целиком и выписать все задержки: восприятия, решения, действия, эффекта.
2. Сложить бюджет задержки. Умножить на четыре — получить ожидаемый период колебаний.
3. Сравнить с наблюдаемым периодом. Совпало — гипотеза жива. Не совпало — ищите пропущенное звено.
4. Проверить дискретизацию: не короче ли период колебаний, чем удвоенный интервал наблюдения.
5. Проверить, учитывает ли регулятор «в пути»: pending, in-flight, уже нанятых, уже заказанное.
6. Прежде чем чинить архитектурно — снизить усиление и поставить кулдаун. Это дёшево, быстро и обратимо.
7. Спросить, какое наблюдение опровергнет вашу схему. Если ответа нет, это не модель.

Мини-итог

• Задержка — время между действием и проявлением его эффекта. Она сидит в четырёх местах контура, и лечатся эти места по-разному.
• Уравновешивающий контур с задержкой не приводит систему к цели плавно, а раскачивает её. Период автоколебаний вблизи границы устойчивости — примерно четыре суммарные задержки контура. Это проверяемое предсказание.
• Устойчивость определяется произведением усиления на задержку. Если задержку сократить нельзя, всегда можно снизить усиление.
• Длинное окно метрики — не «стабильнее», а «медленнее»: это задержка, добавленная в контур собственными руками.
• Регулятор, не учитывающий «уже заказанное, но не прибывшее», систематически перезаказывает. Это единый механизм для автоскейлера, ретраев, найма и планирования спринта.
• Самые опасные задержки — длинные и невидимые: техдолг, выгорание, деградация общего ресурса. Их период больше окна наблюдения, поэтому на дашбордах их нет по построению.
• Модель с задержками хорошо предсказывает знак, механизм и порядок величины; плохо — амплитуду, поведение после смены режима и долгосрочные траектории. Схема без проверяемого следствия — иллюстрация, а не модель.

Источники

• J. Sterman. Business Dynamics: Systems Thinking and Modeling for a Complex World. McGraw-Hill, 2000 — учебник с главами про верификацию и тестирование моделей.
• J. Sterman. Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment. Management Science 35(3), 1989 — экспериментальные данные Beer Distribution Game.
• H. L. Lee, V. Padmanabhan, S. Whang. Information Distortion in a Supply Chain: The Bullwhip Effect. Management Science 43(4), 1997.
• J. Forrester. Industrial Dynamics. MIT Press, 1961.
• W. Nordhaus. World Dynamics: Measurement Without Data. The Economic Journal 83(332), 1973 — базовая критика моделей без эмпирической оценки параметров.
• H. Cole et al. Models of Doom: A Critique of the Limits to Growth. 1973.
• G. Turner. A Comparison of The Limits to Growth with Thirty Years of Reality. Global Environmental Change 18(3), 2008; G. Herrington. Update to Limits to Growth. Journal of Industrial Ecology 25(3), 2021 — попытки сверки World3 с данными и споры вокруг них.
• D. Meadows. Leverage Points: Places to Intervene in a System, 1999.
• K. J. Åström, R. M. Murray. Feedback Systems: An Introduction for Scientists and Engineers — свободно доступный курс теории управления.
• F. Brooks. The Mythical Man-Month. Addison-Wesley, 1975.
• Horizontal Pod Autoscaling — документация Kubernetes, значения по умолчанию для окон стабилизации.
• Timeouts, retries, and backoff with jitter — AWS Builders’ Library.
• Addressing Cascading Failures — Google SRE Book.
• Netflix concurrency-limits — адаптивные лимиты конкурентности как способ убрать задержку из контура.

Что дальше

Задержка объясняет колебания, но не объясняет, почему система иногда не колеблется, а скачком переходит в другой режим и не возвращается. За это отвечают нелинейности и пороги.

Нелинейность и пороги: когда «чуть больше» меняет режим