11 мая 2026 г.

Мысленные модели для отладки - из Thinking in Systems к практике

Прочитала Донеллу Медоуз и попыталась перетащить её рамки в работу с багами. Что получилось, что развалилось.

Thinking in Systems - это про то, как видеть петли обратной связи в больших системах: экономике, экологии, организациях. Я попыталась применить эти рамки к отладке кода. Получилось - частично.

Что Медоуз называет stock и flow

Stock - это запас (накопленная величина), flow - поток (изменение во времени). У ванны вода - stock, вода из крана - flow на вход, слив - flow на выход.

В коде stock - это состояние программы в момент времени. Flow - это что происходит между событиями. Большинство багов - это либо stock в неожиданном состоянии, либо flow с неожиданной скоростью или направлением.

Звучит банально. Но когда я начала задавать себе вопросы в этих терминах, отладка ускорилась. «А что у нас в очереди прямо сейчас?» (stock). «Сколько туда приходит в секунду?» (flow). «Что-то его очищает?» (output flow).

Балансирующие и усиливающие петли

У Медоуз главный понятийный аппарат - петли обратной связи. Балансирующая петля стабилизирует систему (термостат). Усиливающая - раскачивает (вирусный рост).

Большая часть продакшн-инцидентов - это сломанная балансирующая петля или незамеченная усиливающая. Cache не инвалидируется - балансирующая петля сломана, stale data растёт. Retry без backoff - усиливающая петля, очередь раздувается.

Я заметила: когда я ловлю «странную» проблему - это часто значит «здесь работает петля, которой я не вижу». И вместо того, чтобы крутить ручки наугад, нужно найти петлю.

Где модель развалилась

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

Ещё. У Медоуз нет понятия «версия». Социальные системы существуют непрерывно. Коды деплоятся, бэк катится назад, баг исчезает. Это другая динамика.

Полезное переключение

Раньше когда я отлаживала, я строила в голове граф вызовов - «функция вызывает функцию, та вызывает третью». Теперь чаще строю граф состояний - «состояние А переходит в B при событии X, обратно при Y».

Это два разных видения. Граф вызовов хорош для понимания структуры. Граф состояний - для понимания поведения. Большинство неочевидных багов сидят в графе состояний, не в графе вызовов.

Книга для непрограммистов

Медоуз написала эту книгу не для разработчиков. Половину примеров можно пропустить - про популяцию оленей или цепочки поставок зерна. Но рамки переносятся.

Главное наблюдение, которое я унесла: «структура определяет поведение». В коде это работает один в один.

Юлия

Информационная безопасность, государственная структура. Больше десяти лет в этой работе. Училась в Бауманке. Здесь пишу про то, чем занимаюсь вне работы.

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