Системные архетипы: повторяющиеся ловушки

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

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

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

Что такое архетип и чем он не является

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

Чтобы название работало, у архетипа должны быть все четыре части:

1. Структура. Какие петли, какого знака, где между ними задержки. Это то, что рисуется.
2. Сигнатура поведения. Как выглядит график во времени: пила с растущей амплитудой, S-кривая, ступенчатый храповик, расходящиеся ветви. Это то, что можно сверить с данными.
3. Наблюдаемые признаки. Какие метрики и артефакты должны существовать, если структура есть: счётчик применений обходного решения, история изменений порогов, распределение потребления общего ресурса по командам.
4. Точки вмешательства и антисоветы. Что в этой структуре обычно помогает и что заведомо не помогает — например, «усилить быструю петлю» почти всегда бесполезно, потому что именно она и создаёт проблему.

Чем архетип не является:

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

Статус знания: это словарь, а не открытие

Язык архетипов вырос из системной динамики Форрестера, был собран в набор и популяризирован Питером Сенге в «Пятой дисциплине» (1990), затем оформлен как учебные карточки у Дэниела Кима и Уильяма Брауна, а Донелла Медоуз в «Thinking in Systems» описала близкий набор под названием «системные ловушки» (system traps).

Честная оценка доказательной базы выглядит так:

• Состав и число архетипов у разных авторов разные. У Сенге их около восьми-десяти, у Кима десять, у Медоуз восемь ловушек. Эрик Волстенхолм в System Dynamics Review показал, что почти все известные архетипы сводятся к небольшому ядру структур из двух петель, и предложил свести каталог к четырём базовым «проблемным» конфигурациям (doi:10.1002/sdr.259, 2003). Сам факт, что каталог зависит от автора, — сильный признак: перед нами таксономия удобства, а не таксономия природы.
• Систематической эмпирической проверки каталога нет. Есть множество разборов задним числом и почти нет предрегистрированных предсказаний. Отдельные механизмы внутри архетипов проверены хорошо — эффект хлыста измерен на полевых данных (Lee, Padmanabhan, Whang, Management Science, 1997), метастабильные отказы описаны как воспроизводимый класс (Bronson et al., HotOS 2021). Но «каталог из восьми структур покрывает организационные патологии» — утверждение, которое никто не проверял в форме, допускающей опровержение.
• Отдельные утверждения внутри каталога прямо оспорены. Классический пример — трагедия общего ресурса: тезис Гаррета Хардина о неизбежности истощения (Science, 1968) был существенно ограничен полевыми работами Элинор Остром, показавшей множество долгоживущих сообществ, которые управляют общим ресурсом без приватизации и без внешнего принуждения (Нобелевская лекция, 2009). То есть «трагедия» — не закон природы, а следствие отсутствия правил и наблюдаемости. Для инженера это хорошая новость: значит, лечится квотами и атрибуцией.

Отсюда рабочая позиция трека: архетипы полезны как генератор гипотез и чек-лист измерений, и вредны как аргумент в споре. Ровно так они и поданы ниже.

Карточка архетипа

Единый формат, к которому стоит приводить любую гипотезу об архетипе, — шесть строк:

Строка «Опровержение» — единственная, которая отличает работу от рисования. Если её нельзя заполнить, у вас не гипотеза, а метафора; про это же — глава логики о научном и инженерном рассуждении.

Карта каталога, который разбирается дальше:

Протокол применения: от симптома к измерению

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

Каталог структур

1. Починка, которая ломает

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

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

Сигнатура. Пила с растущим уровнем: после каждого вмешательства симптом падает ниже предыдущего дна, но следующий пик выше предыдущего пика, а интервал между вмешательствами сокращается.

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

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

2. Перенос проблемы и зависимость от костыля

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

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

Стадии, по которым это распознаётся раньше:

Точка, после которой цена выхода резко растёт, — переход S3 → S4. До него костыль убирается решением одного тимлида, после него — переговорами с тремя командами.

Модель и предсказание. Структура достаточно проста, чтобы её посчитать. Запасы: S — неисправленные первопричины, W — мощность костыля, C — способность закрывать причины.

# Перенос проблемы: костыль гасит симптом, способность чинить причину атрофирует.
def simulate(weeks=120, remove_crutch_at=None, dt=0.25):
    S, W, C = 5.0, 0.0, 1.0   # причины (шт), мощность костыля (шт), способность (доля)
    inflow = 0.8              # новые первопричины, шт/нед
    alpha, beta = 0.35, 0.30  # рост костыля; доля видимой боли, ставшая вниманием к причине
    gamma, delta = 0.25, 0.08 # рост способности от практики; атрофия без практики, 1/нед
    rho = 0.18                # скорость закрытия причин при полной способности, 1/нед

    log, t = [], 0.0
    while t < weeks:
        crutch_on = remove_crutch_at is None or t < remove_crutch_at
        if not crutch_on:
            W = 0.0                       # костыль отключили
        pain = max(0.0, S - W)            # видимая боль = причины минус то, что гасит костыль
        attention = beta * pain           # внимание к первопричине питается только видимой болью
        dW = alpha * pain if crutch_on else 0.0
        dC = gamma * attention * (1.0 - C) - delta * C
        dS = inflow - rho * C * S
        W += dW * dt
        C = min(1.0, max(0.0, C + dC * dt))
        S = max(0.0, S + dS * dt)
        t += dt
        log.append((round(t, 1), round(pain, 2), round(S, 2), round(W, 2), round(C, 3)))
    return log


base = simulate()                           # костыль живёт всегда
withdrawal = simulate(remove_crutch_at=80)  # костыль отключают на 80-й неделе

Сложность: O(N) по времени и O(N) по памяти при N = weeks / dt шагах интегрирования (и O(1) по памяти, если не копить лог). Модель игрушечная, но она делает нетривиальные утверждения. Результат прогона:

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

Отсюда главное предсказание архетипа, неприятное и потому ценное: при отключении костыля симптом станет заметно хуже, чем был до его появления. В прогоне с отключением на 80-й неделе видимая боль подскакивает до 16.3 против исходных 5.0 — более чем втрое. Инженерное следствие: если вы собираетесь снимать костыль, планируйте не «станет лучше», а провал на несколько недель, и объявите это заранее, иначе провал прочитают как доказательство того, что костыль был нужен.

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

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

3. Эскалация

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

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

Предсказание. В истории изменений доля изменений «вниз» близка к нулю, а изменения одной стороны систематически предшествуют изменениям другой с лагом в дни-недели. Опровержение: изменения идут в обе стороны или не коррелируют по времени — тогда это независимая настройка, а не эскалация.

Вмешательства. Общий потолок вместо локальных: сквозной дедлайн запроса, который передаётся вниз по цепочке и не может быть увеличен локально (AWS о таймаутах и ретраях, адаптивные лимиты Netflix). Бюджет ретраев вместо бесплатных повторов. Для приоритетов — квота на количество P1 у команды. Общий арбитр, у которого метрика — сквозной результат, а не результат одной стороны. Антисовет: «договориться, что все ведут себя разумно» — эскалация не про поведение, а про то, что каждый локально прав.

4. Трагедия общего ресурса

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

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

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

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

Вмешательства — прямо по Остром, переведённые на инженерный:

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

5. Пределы роста

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

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

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

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

6. Рост и недоинвестирование

Разновидность «пределов роста», где ограничитель — собственная ёмкость, а инвестиция в неё откладывается, потому что данные о спросе искажены самим ограничением.

Ловушка в измерении. Спрос, который вы наблюдаете, — это спрос после подавления. Инженеры перестают запускать сборки, объединяют коммиты, гоняют тесты локально. Заявка на расширение кластера отклоняется словами «утилизация не растёт», и это правда про наблюдаемую метрику и ложь про потребность.

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

Вмешательства. Измерять подавленный спрос напрямую. Держать норматив внешним и неизменным (SLO на время сборки, зафиксированный на год). Принимать решение об инвестиции по опережающему показателю, а не по факту деградации — из-за задержки в квартал реагировать по факту всегда поздно (см. задержки и тесты в CI).

7. Сползание цели

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

Инженерные примеры. SLO доступности «уточнили» с 99.9 % до 99.5 %, потому что «прежний был нереалистичным». Порог алерта на p99 подняли с 300 мс до 500 мс, чтобы не шумел. Целевое время реакции на инцидент выросло с 5 до 15 минут. Порог покрытия тестами в CI снизили, чтобы разблокировать релиз. В социологии этот же процесс описан как нормализация отклонения — по разбору катастрофы «Челленджера» у Дианы Вон; инженерная версия того же наблюдения — тезисы Ричарда Кука о том, как работают сложные системы (how.complexsystems.fail).

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

Вмешательства. Якорь снаружи: цель привязана к обязательству перед пользователем или к контракту, а не к текущей способности. Изменение цели проходит той же процедурой, что изменение архитектуры, — с записанным решением и явной ценой. Политика бюджета ошибок вместо ручного подкручивания порогов (SRE book про бюджеты ошибок и про SLO с продуктовой стороны).

8. Успех успешному

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

Инженерные примеры. Команда, «которая умеет доставлять», получает лучшие задачи, лучших кандидатов и приоритет платформы; вторая получает легаси и деградирует до состояния, в котором её уже нельзя нагружать важным. Модуль монолита, где живут все ревьюеры, растёт быстрее остальных, потому что изменения в нём проходят ревью за часы, а в соседнем — за дни. Внешне это выглядит как распределение по заслугам, и в этом ловушка: механизм работает и тогда, когда исходное различие было шумом (в науке — эффект Матфея, Science, 1968).

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

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

9. Случайные противники

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

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

Вмешательства. Общий измеримый результат для обеих сторон. Легальный путь должен быть быстрее обходного — это единственное надёжное средство. Совместный разбор конкретных обходов без поиска виноватых (культура безвинных постмортемов — SRE book). Антисовет: усиливать контроль без ускорения легального пути.

10. Локальная оптимизация

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

Сигнатуры во времени

Быстрый способ отличить архетипы друг от друга — посмотреть на форму графика до того, как рисовать петли. Четыре характерные формы:

Практическое правило: если нет графика хотя бы за два-три полных цикла, разговор об архетипе преждевременен — один цикл не отличает структуру от случайности. Это тот же принцип, что в причинных диаграммах: схема проверяется данными, а не согласием участников совещания.

Как проверять гипотезу об архетипе

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

Рецепты: два счётчика, которые ловят половину каталога

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

groups:
  - name: archetype-signals
    rules:
      # Поток: сколько раз в час запускали обходное решение
      - record: job:workaround_runs:rate1h
        expr: sum(rate(workaround_runs_total[1h]))

      # Тревога не на применение костыля, а на РОСТ частоты применения
      - alert: WorkaroundUsageGrowing
        expr: >
          job:workaround_runs:rate1h
            > 1.5 * avg_over_time(job:workaround_runs:rate1h[14d])          
        for: 6h
        labels:
          severity: ticket
        annotations:
          summary: "Частота обходного решения выросла в 1.5 раза к двухнедельной базе"
          description: "Признак переноса проблемы: симптом гасится, причина не закрывается."

      # Доля инцидентов, закрытых обходом, а не устранением причины
      - record: job:workaround_share:ratio7d
        expr: sum(increase(incidents_closed_total{resolution="workaround"}[7d]))
              / sum(increase(incidents_closed_total[7d]))

Про rate — документация Prometheus; про то, зачем отличать поток от запаса, — глава 04. Второй счётчик — тест на храповик: он одинаково ловит эскалацию (движение вверх) и сползание цели (движение вниз), а данные берутся из таблицы аудита конфигов или восстановленной истории git.

-- Храповик: параметр меняется практически только в одну сторону.
WITH changes AS (
    SELECT
        param_name,
        changed_at,
        new_value,
        LAG(new_value) OVER (PARTITION BY param_name ORDER BY changed_at) AS prev_value
    FROM config_audit
    WHERE param_name IN ('http.timeout_ms', 'retry.max_attempts', 'slo.availability_target')
      AND changed_at >= NOW() - INTERVAL '18 months'
)
SELECT param_name,
       COUNT(*)                                       AS total_changes,
       COUNT(*) FILTER (WHERE new_value > prev_value) AS increases,
       COUNT(*) FILTER (WHERE new_value < prev_value) AS decreases,
       ROUND(100.0 * COUNT(*) FILTER (WHERE new_value > prev_value)
             / NULLIF(COUNT(*), 0), 1)                AS pct_up
FROM changes
WHERE prev_value IS NOT NULL
GROUP BY param_name HAVING COUNT(*) >= 4
ORDER BY pct_up DESC;

Интерпретация: pct_up около 100 % при четырёх и более изменениях — сильный признак храповика. Дальше остаётся проверить лаг: предшествуют ли изменения одной стороны изменениям другой.

Пределы метода

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

1. Каталог не фальсифицируем целиком. Утверждение «в организациях встречаются эти структуры» не запрещает никакого наблюдения. Проверять можно только конкретную гипотезу о конкретной системе с конкретными числами. Если разговор идёт про «у нас в компании много переноса проблемы вообще» — это не гипотеза.

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

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

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

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

6. Иногда правильный ответ — «архетипа нет». Ветка «нет» в протоколе выше — не формальность. Больше половины повторяющихся симптомов объясняются одной невыполненной задачей, а не структурой.

Типичные ошибки использования

• Назвать вместо измерить. Архетип на слайде без единой новой метрики — театр.
• Начать с петель, а не с графика. Схема, нарисованная до данных, всегда подтверждается.
• Один цикл вместо трёх. Одно повторение не отличает структуру от совпадения.
• Смешать симптом и структуру, забыв про задержку. «Очередь растёт» — симптом; архетип объясняет, почему она растёт снова после каждого исправления, и без указания длины задержки вырождается в банальность.
• Лечить быструю петлю. Ускорять симптоматическое решение — самое частое и самое вредное вмешательство в переносе проблемы.
• Не назначить владельца измерения. Гипотеза без ответственного за проверку живёт до следующего инцидента и умирает.

Мини-практика: 45 минут на своей системе

1. Возьмите три симптома, которые повторялись минимум трижды за последние полгода: один технический, один процессный, один межкомандный.
2. Для каждого нарисуйте график по реальным данным, а не по памяти. Если данных нет — это уже результат: первое вмешательство состоит в том, чтобы поставить счётчик.
3. Сверьте форму с четырьмя сигнатурами. Не подошло — работайте с симптомом обычным порядком; подошло — заполните карточку целиком, включая строку «Опровержение», и запишите предсказание с датой проверки.
4. Через два цикла вернитесь и честно закройте карточку: подтвердилось или нет. Именно этот шаг отличает инструмент от красивого языка.

Разбор трёх таких карточек до конца — инцидент, техдолг и очередь — будет в главе 14.

Мини-итог

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

Источники

• Peter Senge. The Fifth Discipline, 1990 — исходная популяризация набора; словарь, а не доказательство. Daniel Kim. Systems Archetypes: Diagnosing Systemic Issues and Designing Interventions — карточки с примерами, thesystemsthinker.com.
• Eric Wolstenholme. Towards the definition and use of a core set of archetypal structures in system dynamics // System Dynamics Review, 19(1), 2003. doi:10.1002/sdr.259 — попытка свести каталог к небольшому ядру.
• Donella Meadows. Thinking in Systems, глава «System Traps and Opportunities», chelseagreen.com.
• John Sterman. Business Dynamics, 2000 — главы о валидации; страница автора. См. также его же «All models are wrong» (doi:10.1002/sdr.261).
• Garrett Hardin. The Tragedy of the Commons // Science, 1968. science.org
• Elinor Ostrom. Beyond Markets and States: Polycentric Governance of Complex Economic Systems, Нобелевская лекция, 2009. nobelprize.org
• Robert Merton. The Matthew Effect in Science // Science, 1968 (doi:10.1126/science.159.3810.56); Lee, Padmanabhan, Whang. Information Distortion in a Supply Chain: The Bullwhip Effect // Management Science, 1997 (doi:10.1287/mnsc.43.4.546).
• Bronson et al. Metastable Failures in Distributed Systems // HotOS 2021. PDF
• Richard Cook. How Complex Systems Fail (how.complexsystems.fail); Diana Vaughan. The Challenger Launch Decision, 1996 — два взгляда на нормализацию отклонения.
• Google SRE Book: бюджеты ошибок, культура постмортемов. Fred Brooks. The Mythical Man-Month, 1975 — «пределы роста» применительно к найму.

Что дальше

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