Системное мышление: карта трека и зачем это инженеру

Профилировщик показал, что сервис упирается в пул соединений к базе: воркеры стоят в ожидании свободного коннекта. Инженер увеличил пул с 20 до 40 — измерение подтвердило гипотезу, p99 на нагрузочном стенде упал на треть.

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

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

Три признака того, что перед вами системная задача

Отладка сводит наблюдаемый эффект к конкретной причине-событию. Метод перестаёт работать, когда сходятся три признака.

1. Эффект отделён от причины во времени — дни или кварталы, и связь в голове наблюдателя не возникает.
2. Эффект отделён от причины в пространстве системы — крутили пул в сервисе A, упало в C, жалуется отдел продаж.
3. Очевидное лекарство ухудшает ситуацию на среднем горизонте — ретраи спасают сегодня и топят под нагрузкой; люди на горящем проекте замедляют его; поднятый таймаут делает отказ незаметнее. Совпали хотя бы два признака — вопрос «кто это сломал» бесполезен: сломала не рука, а контур.

Рабочее определение (и что в него не входит)

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

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

Чем это не является — важнее определения, потому что именно здесь тема обрастает мусором:

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

Проверка на пустоту для любого своего вывода: какое наблюдение сделало бы это утверждение ложным? Нет ответа — вы нарисовали картинку, а не модель. К этому вернёмся в главах о причинных диаграммах и о пределах моделирования.

Где системное мышление стоит относительно соседних треков портала

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

Пять понятий, из которых собран весь инструмент

Минимальный словарь; каждому понятию посвящена своя глава. Все пять — про измеримые вещи.

Запасы и потоки

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

Запас(t) = Запас(0) + Σ (приток − отток)

Отсюда два вывода, которые систематически не делают. Первое: запас растёт при постоянной нагрузке — при притоке 1 200 rps и ёмкости 1 150 утверждения «нагрузка не менялась» и «очередь взорвалась» верны одновременно, разница в 4 % даёт +3 000 сообщений в минуту. Второе: запас нельзя изменить мгновенно, даже перекрыв приток — очередь рассасывается со скоростью оттока, поэтому инцидент не заканчивается вместе со своей причиной. В стационарном режиме работает закон Литтла: L = λ · W, где L — среднее число заявок, λ — интенсивность входа, W — среднее время в системе (John Little, 1961). Перевод: длиннее очередь — линейно длиннее ожидание; ограничив очередь, вы ограничили задержку (глава 04).

Петли обратной связи

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

Все четыре связи в цикле положительные — цикл усиливающий. Он объясняет странное свойство таких отказов: система не восстанавливается даже после того, как исходная причина исчезла, потому что нагрузку теперь генерирует её собственный контур. В литературе это метастабильный отказ — Bronson et al., HotOS 2021, и Metastable Failures in the Wild, OSDI 2022 (usenix.org); публичный разбор того же механизма — постмортем AWS DynamoDB от 20 сентября 2015 года (aws.amazon.com/message/5467D2).

Вывод чисто структурный: усиливающую петлю нельзя победить ёмкостью, её надо разомкнуть. Отсюда бюджеты ретраев, jitter, circuit breaker и load shedding — см. паттерны устойчивости. Дальше — глава про петли.

Задержки

Задержка — время между действием и его наблюдаемым эффектом, главный источник поведения, которое кажется необъяснимым. Уравновешивающая петля без задержки приводит систему к цели; та же петля с задержкой — раскачивает.

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

def simulate(steps=400, arrival=1000.0, per_worker=100.0, delay=4,
             target=500.0, gain=0.35, shock=400.0):
    """Очередь как запас, автоскейлер как уравновешивающая петля с задержкой.

    Решение о мощности принимается по текущей очереди, а доезжает через delay шагов.
    Сложность: O(steps) по времени, O(delay) по памяти.
    """
    queue = target + shock                     # разовый всплеск, дальше трафик постоянный
    pipeline = [arrival / per_worker] * delay  # заказы на мощность, которые ещё «в пути»
    history = []
    for t in range(steps):
        # хотим покрыть входящий поток и вдобавок съесть отклонение от целевой очереди
        pipeline.append((arrival + gain * (queue - target)) / per_worker)
        workers = pipeline.pop(0)              # доехало решение, принятое delay шагов назад
        served = min(queue + arrival, workers * per_worker)
        queue = max(0.0, queue + arrival - served)
        history.append((t, queue, workers))
    return history


for d in (0, 4, 8):                            # размах очереди в хвосте прогона
    tail = [q for _, q, _ in simulate(delay=d)[-60:]]
    print(f"задержка={d}: размах = {max(tail) - min(tail):.0f}")

Вывод: размах 0, 1010 и 1735 при задержках 0, 4 и 8. Без задержки очередь монотонно приходит к цели после всплеска; с задержкой 4 остаётся в незатухающих колебаниях; с задержкой 8 и той же силой реакции размах вдвое больше — при одном и том же постоянном трафике. Замеренный период колебаний — 18 шагов при задержке 4 и 27 при задержке 8, те самые «порядка четырёх задержек».

Как проверить это на своей системе: возьмите график числа инстансов за реальный инцидент, измерьте период колебаний и сравните с суммарной задержкой реакции (окно метрики + cooldown + прогрев). Совпало по порядку — лечится не «увеличить лимит», а уменьшением задержки или силы реакции; не совпало — модель неверна (глава 05).

Границы

Граница — то, что вы объявили внутренним, а что внешним. Её не даёт природа, её выбирает аналитик, и от неё зависит вывод. Команда меряет свой сервис и видит p99 = 40 мс, клиент видит 1,8 секунды: обе цифры верны, границы разные — внутри сервиса нет ни ретраев клиента, ни холодного старта, ни очереди в шлюзе. Пока граница проведена по своему сервису, вывод «у нас всё хорошо» не может быть опровергнут и потому бесполезен. Здесь же корень локальной оптимизации: улучшая внутри границы, вы выталкиваете издержку за неё. Отсюда практика сквозных измерений — наблюдаемость и глава про границы.

Нелинейность и режимы

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

Переход между режимами асимметричен: чтобы войти в метастабильный отказ, хватает короткого всплеска, а чтобы выйти, нужно опустить нагрузку сильно ниже той, при которой он начался. Публичный пример порогового отказа — инцидент AWS Kinesis 2020 года, где добавление мощности упёрлось в лимит числа потоков ОС на фронтенд-серверах (aws.amazon.com/message/11201); дальше — глава 06.

Четыре уровня, на которых можно отвечать на вопрос «почему»

Ценность картинки не в иерархии, а в вопросе к любому постмортему: на каком уровне сформулирован вывод и на каком — действие? Типичная поломка: вывод на уровне события («выкатили плохой релиз»), действие тоже («добавили пункт в чек-лист»). Через квартал повторяется то же самое: релизы по-прежнему большие, откат ручной, проверка упирается в одного человека. Если действие после инцидента звучит как «быть внимательнее» или «добавить ещё одну проверку в ревью» — вы работаете на уровне событий. Разбор инцидентов как процесса — дежурства и инциденты; как системы — глава 14.

Как отличить рабочую модель от красивой схемы

Здесь дисциплина ломается чаще всего: нарисовать стрелочки легко, и картинка всегда выглядит убедительно. Пять критериев к собственной диаграмме:

1. Что она запрещает? Модель, совместимая с любым исходом, ничего не объясняет. Формулируйте так: «при снижении силы реакции автоскейлера размах колебаний упадёт, а средняя очередь вырастет» — проверяется за один эксперимент.
2. Предсказывает ли форму поведения? Чисел от системной модели ждать не надо, формы — надо: рост, колебание, овершут с откатом, S-кривая, срыв в другой режим. Форма проверяется по историческим графикам.
3. Есть ли у каждой переменной наблюдаемый прокси? «Мотивацию команды», которую нельзя оценить даже грубо и регулярно, схема делает красивее, а вывод — непроверяемым.
4. Чувствительна ли модель к параметрам? Если вывод не меняется ни при каких значениях, он заложен в допущениях, а не выведен. Главная претензия к глобальным моделям, о ней ниже.
5. Названы ли знаки и задержки? Стрелка без знака и времени — украшение, а не утверждение.

Уровни строгости, между которыми выбирают осознанно:

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

Честно про доказательную базу

У системной динамики есть основатель, учебники и сильные экспериментальные результаты — и есть громкие провалы, о которых обычно не рассказывают.

Прочно — там, где есть воспроизводимый эксперимент или математика.

• Beer distribution game. Стерман (Management Science, 1989) показал в лаборатории: люди систематически не учитывают собственные заказы «в пути» и раскачивают цепочку поставок даже при постоянном спросе. Воспроизводился сотни раз, эффект устойчив — прямое доказательство того, что человек плохо рассуждает о задержках, и основание всего трека.
• Bullwhip effect. Lee, Padmanabhan, Whang (Management Science, 1997) нашли тот же эффект на данных реальных цепочек: наблюдаемо, измеримо, объясняется структурой.
• Теория очередей и теория управления. Закон Литтла и колебания контура с задержкой — математика, а не наблюдения системных мыслителей.

Слабо — там, где большая модель делает большие выводы. Urban Dynamics (1969) утверждала, в частности, что строительство социального жилья ухудшает положение города. Критика была не политической, а методологической: вывод следовал из допущений о миграции и занятости, не оценённых по данным. Общая критика системного анализа того периода собрана у Иды Хус (Systems Analysis in Public Policy: A Critique, 1972).

The Limits to Growth (1972) — модель World3, самый обсуждаемый случай. Уильям Нордхаус в рецензии World Dynamics: Measurement Without Data (The Economic Journal, 1973) сформулировал претензию, не снятую до сих пор: параметры заданы по здравому смыслу, а не оценены по данным, поэтому модель воспроизводит убеждения авторов. Сборник Models of Doom (SPRU, Сассекс, 1973) показал, что при других правдоподобных допущениях о технологиях и ресурсах исход другой. Позже Грэм Тёрнер (Global Environmental Change, 2008) и Гайя Херрингтон (Journal of Industrial Ecology, 2021) сравнивали сценарии с фактическими данными и находили согласие агрегатов — но совпадение нескольких агрегированных кривых на одном-единственном прогоне истории слабо различает механизмы. Честная позиция: это не подтверждённое предсказание и не опровергнутое шарлатанство, а модель, которую нельзя проверить в том режиме, в каком её предъявляют. Отсюда правило трека:

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

Отдельно про архетипы (Сенге, 1990) и точки воздействия (Медоуз, 1999): это не проверенные теории, а язык описания и эвристика сортировки. Они экономят время, подсказывая, куда смотреть, но «у нас архетип „перенос проблемы“» — гипотеза, которую надо подтвердить данными, а не диагноз. Так они и подаются в главе 09 и главе 11.

Пять ловушек, ради которых стоит читать трек

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

Про трагедию общего ресурса надо сказать честно: Гаррет Хардин (Science, 1968) подавал её как неизбежность, и это эмпирически не подтвердилось. Элинор Остром (Governing the Commons, 1990, Нобелевская премия 2009) на большом корпусе полевых исследований показала, что сообщества справляются с общими ресурсами при выполнимых условиях: наблюдаемость потребления, участие пользователей в правилах, градуированные санкции, дешёвое разрешение конфликтов. Инженерный перевод: общий кластер выживает не от призывов «не злоупотребляйте», а от квот, видимого потребления по командам и понятной процедуры «кого душат первым» — см. кэширование и масштабирование.

Техдолг ведёт себя как запас с петлёй: долг растёт → скорость падает → на рефакторинг остаётся меньше времени → долг растёт быстрее. Усиливающая петля объясняет, почему «поработаем над долгом, когда станет посвободнее» не срабатывает никогда: времени будет всё меньше. Управленческая сторона — глава про техдолг, системная — глава 14.

Точки воздействия: почему «покрутить параметр» почти никогда не работает

Донелла Медоуз в эссе Leverage Points (1999) предложила список из двенадцати мест вмешательства, отсортированный по силе. Список — эвристика, как теория он не проверен, но одна его идея выдерживает проверку практикой: чем легче вмешательство, тем оно слабее. Инженерный перевод, от слабого к сильному:

1. Параметры — поднять таймаут, увеличить пул, добавить реплику. Дёшево, обратимо, эффект почти всегда временный: структура прежняя.
2. Размеры запасов и буферов — ограничить длину очереди, ввести лимит WIP: меняется поведение, а не только уровень.
3. Структура потоков — убрать синхронный вызов, разнести чтение и запись.
4. Задержки — сократить окно метрики, ускорить деплой, приблизить обратную связь к решению. Самый недооценённый рычаг: контур с вдвое меньшей задержкой ведёт себя иначе.
5. Правила — бюджет ретраев на всю цепочку, error budget, «сначала стабилизируем, потом расследуем»: правила определяют, какие петли вообще могут возникнуть.
6. Цели — что считается успехом дежурства: закрытые алерты или отсутствие повторов. Смена цели переписывает поведение сильнее любого параметра, и потому метрики так опасны, см. метрики продукта.

Если после инцидента все действия из пунктов 1–2, через квартал вы вернётесь сюда же (глава 11).

Карта трека

Главы 01–08 дают язык, 09–13 — инструменты, 14–15 — применение:

Маршруты: минимальный — 03, 04, 05, 10 (хватает, чтобы перестать удивляться очередям, колебаниям автоскейлера и ретрай-штормам); полный — по порядку; по проблеме — инцидент повторяется третий раз: 09 и 14; спор про общий ресурс: 02, 09, 10; метрика улучшилась, а клиенту хуже: 02 и 10; автоскейлер раскачивается: 05; схема нарисована, а что дальше — непонятно: 12 и 13.

Практика: 40 минут на своём последнем инциденте

Упражнение стоит проделать до чтения остальных глав: оно задаёт планку конкретности.

1. Возьмите постмортем последнего заметного инцидента.
2. Выпишите запасы — что накапливалось (очередь, лаг репликации, открытые соединения, незакрытые алерты, ретраи в полёте) — и где каждый виден в мониторинге.
3. Выпишите потоки, меняющие эти запасы, с фактическими значениями в момент инцидента.
4. Нарисуйте связи со знаками и найдите замкнутые пути; отметьте усиливающие и уравновешивающие петли. Больше 9 узлов — захватили лишнее, сузьте границу.
5. Проставьте задержки: окно метрики, cooldown, прогрев, время реакции дежурного.
6. Сформулируйте предсказание «если сделать X, форма поведения изменится так-то» и наблюдение, которое эту модель опровергнет.

Критерий успеха: пункт 6 выполним за неделю силами вашей команды. Иначе вы описали инцидент новыми словами, а не разобрали его.

Пределы метода и гигиена

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

• Нефальсифицируемость по желанию. Любой исход задним числом объясняется какой-нибудь петлёй; лечится одним — предсказание формулируется до наблюдения.
• Подмена анализа рисованием. Диаграмма — постановка задачи, а не результат.
• Иллюзия полноты. На схеме десять узлов, в системе тысячи. Вопрос не «полна ли модель», а «достаточна ли для конкретного вопроса».
• Перенос на людей без данных. Стрелка «давление сроков → качество кода» правдоподобна, но её знак и величина у вас не измерены — помечайте такие связи как гипотезы.
• Групповая уверенность. Схема, нарисованная вместе, ощущается как консенсус о реальности, хотя это консенсус о картинке. Спасает вопрос «кто видел данные по этой стрелке».

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

Мини-итог

• Системная задача опознаётся по трём признакам: задержка между причиной и эффектом, разнос причины и эффекта по системе, ухудшение от очевидного лекарства.
• Инструмент состоит из пяти измеримых понятий: запасы и потоки, петли, задержки, границы, нелинейность. Всё остальное — надстройка.
• Главное следствие: усиливающую петлю не победить ёмкостью, а уравновешивающую с большой задержкой — силой реакции.
• База неоднородна: beer game, bullwhip, теория очередей и управления — прочно; глобальные модели вроде World3 — предмет полувекового спора, их выводы во многом заложены в допущениях.
• Архетипы и точки воздействия — язык и эвристика, а не теории: подсказка, где искать, с обязательной проверкой данными.
• Модель обязана что-то запрещать. Не можете назвать опровергающее наблюдение — у вас картинка.

Источники

Основа трека. Donella Meadows. Thinking in Systems: A Primer, 2008 — компактное введение; материалы на donellameadows.org, там же эссе Leverage Points (1999). John Sterman. Business Dynamics, 2000 — учебник с математикой, страница автора: mit.edu/jsterman. Jay Forrester. Industrial Dynamics, 1961 — исток дисциплины. Peter Senge. The Fifth Discipline, 1990 — язык архетипов.

Эксперименты и данные. Sterman. Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment. Management Science 35(3), 1989 (beer game). Lee, Padmanabhan, Whang. Information Distortion in a Supply Chain: The Bullwhip Effect. Management Science 43(4), 1997. J. D. C. Little. A Proof for the Queuing Formula L = λW. Operations Research 9(3), 1961. Elinor Ostrom. Governing the Commons, 1990.

Критика, без которой картина неполная. W. Nordhaus. World Dynamics: Measurement Without Data. The Economic Journal 83(332), 1973. H. S. D. Cole et al. Models of Doom, 1973. Ida R. Hoos. Systems Analysis in Public Policy: A Critique, 1972. G. Turner. A Comparison of The Limits to Growth with Thirty Years of Reality. GEC 18(3), 2008. G. Herrington. Update to Limits to Growth. Journal of Industrial Ecology 25(3), 2021.

Инженерные материалы. Bronson et al. Metastable Failures in Distributed Systems, HotOS 2021; Huang et al. Metastable Failures in the Wild, OSDI 2022 (usenix.org). Постмортемы AWS: DynamoDB, 2015 и Kinesis, 2020. Google SRE Book про перегрузку и каскадные отказы — sre.google/books. Neil Gunther. Guerrilla Capacity Planning, 2007 — закон масштабируемости как пример калибруемой модели.

Что дальше

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