Внедрение больших языковых моделей (LLM) в разработку программного обеспечения вынудило многие организации быстро пересмотреть свои практики и структуры. Старые методы подвергаются сомнению, заменяются или переосмысляются по мере того, как экономика производства нового кода кардинально меняется. Поскольку люди и LLM не взаимозаменяемы, возникающая динамика принципиально иная. Но системы остаются системами, и поэтому, что бы ни менялось, существуют известные закономерности, на которые можно опираться для получения ориентиров и предостережений.
Не сделав шага назад и не взглянув на мышление, лежащее в основе устройства системы, в которой вы работаете, вы рискуете получить несвязный — в смысле «противоречивый» и «конфликтующий», а не «бессмысленный» — набор мер и политик. Поэтому в этой статье я хочу рассмотреть, как мы организуем системы, противопоставив два семейства подходов.
Первый строится на аналитической декомпозиции (analytical decomposition) с целью сохранить контроль над системой, второй исходит из взгляда на сложные системы (complex systems), которые сопротивляются анализу и ориентируются на выявление взаимодействий и механизмов, порождающих желаемое эмерджентное поведение (emergent behaviour).
Это сравнение всегда помогало обнажить неявные допущения и важные элементы системного проектирования — и оно не теряет актуальности сейчас, когда предлагаются новые виды изменений.
Подходы
Аналитическая декомпозиция и контроль
В основе классической науки, инженерии и многих управленческих практик лежит идея о том, что целое можно понять через его части. Если достаточно разложить сложную вещь на составляющие и досконально изучить каждую из них, можно понять, как работает ансамбль в целом. Этот подход — аналитическая декомпозиция (иногда называемая «картезианско-ньютоновской») — проявил себя как надёжный и состоятельный в бесчисленном множестве областей современной жизни.
Способность делить, анализировать и понимать, как правило, распространяется и на причинно-следственные связи во времени: каждое действие порождает реакцию, у каждого события есть материальная причина, и всё это поддаётся отслеживанию, оценке или объективной проверке. Из этого следует, что мы можем перевернуть логику: если мы достаточно хорошо понимаем объект, то можем предсказать, как он поведёт себя под воздействием.
Это фундамент для построения машин и процессов с какой-либо предсказуемостью и надёжностью. Можно иметь высокоуровневую цель и множество разрозненных частей, разложить задачу на подзадачи, собрать хорошо протестированные компоненты с допусками в пределах нормы — и получить работающее решение. Следствие: если каждая деталь машины исправно выполняет свою роль, то и машина в целом должна работать исправно.
Для этого требуется укротить хаотичный мир и держать параметры под контролем, чтобы вариативность оставалась в допустимых границах. Заложи достаточно допусков и резервирования — и всё будет работать. Если нет — можно залезть внутрь, разобрать, разобраться, что сломалось, починить и выйти из этого опыта мудрее.
Этот подход встречается повсюду: от обработки сигналов и телекоммуникаций, где потери при передаче информации обнаруживаются и исправляются с помощью избыточности, до промышленного контроля качества, где статистические процессы позволяют задавать допустимые границы производства.
Он присутствует и на уровне человека: в инженерии человеческого фактора (human factors engineering) такие понятия, как рабочая память (сколько вещей оператор может удерживать в голове одновременно) или идеальный наблюдатель (теоретический человек, контролирующий приборы с оптимальной частотой, относительно которого определяется «невнимательность»), конструируются для того, чтобы обеспечить работу людей в системе в пределах желаемых параметров.
Этот же подход заметен на организационном уровне. Бюрократические процессы и иерархии призваны поддерживать согласованность сверху вниз, чтобы весь ансамбль работал слаженно. В ход идут механизмы дисциплины и прозрачности (legibility), удерживающие эволюцию организации под контролем. В более широком масштабе организации нередко пытаются контролировать своё окружение, рынок или законодательный контекст, в котором работают.
По сути, договорившись о том, какой уровень беспорядка допустим внутри процесса, мы можем определить более чёткий интерфейс снаружи, с которым будут взаимодействовать другие. Такая абстракция создаёт упрощённый, но действенный способ объединить сложный ансамбль в управляемую единицу.
Программное обеспечение в каком-то смысле воплощает идеал этого мировоззрения: системы можно писать на языках, обеспечивающих определённую с трудом достигнутую детерминированность. Выполнение в идеале всегда одинаково, нет износа, то, что работало вчера, будет работать завтра и везде. Политические решения, принятые далеко от передовой, могут детерминированно применяться на всех уровнях.
Это позволяет строить системы из компонентов снизу вверх в соответствии с намерениями сверху вниз, ограничивая вариативность, возникающую как при обработке деталей, так и из-за поведения людей. Идеал — высокопредсказуемая, контролируемая, конкурентоспособная и реактивная система.
Сложность и эмерджентность
Проблема в том, что по определению сложные системы сопротивляются аналитической декомпозиции.
Существует множество конкурирующих описаний сложных систем — поведенческих и структурных. Все они сводятся примерно к следующему: «вещи настолько взаимосвязаны и обладают таким количеством состояний, что становятся либо неописуемыми, либо непредсказуемыми, либо неуправляемыми».
Другие ключевые характеристики: такие системы динамичны, сильно зависят от своей собственной истории и открыты — они непрерывно меняются и взаимодействуют так, что не уважают никаких чистых границ. Это создаёт напряжение: множество участников имеют различные цели, представления, взгляды и степени свободы. К тому времени, когда вы завершили анализ системы, она уже стала чем-то другим. Даже само наблюдение за системой меняет её существенным образом.
Иными словами: если поведение системы вас удивило, то к тому моменту, когда вы разберётесь, что произошло, система уже будет другой, и ваши изменения в политике будут либо запаздывать, либо порождать новые неожиданные сюрпризы. На сложные системы скорее влияют, чем управляют ими.
Эта динамичность диктует стратегии, предполагающие столь же динамичные корректировки. Поскольку предсказуемости добиться нельзя, вмешательства, как правило, будут небольшими и итеративными. Либо, если невозможно упростить элементы или взаимодействия, которые вы пытаетесь контролировать, можно увеличить разнообразие управляющих воздействий, чтобы лучше справляться с текущими изменениями. Обычно это означает: «поместите регулятор — человека или машину — с достаточной внутренней сложностью, чтобы компенсировать сложность контролируемого объекта». В терминах кибернетики это попытка создать более адаптивные и динамичные механизмы управления.
Равновесие достигается не за счёт удержания вещей в статике, а за счёт их постоянного движения.
Идеальная система осознаёт себя и гибка настолько, чтобы бесконечно адаптироваться и поддерживать своё существование, несмотря на всё возрастающие вызовы. Достижимо ли это в действительности — неясно.
Как подходы сочетаются (или не сочетаются)
Системы, как правило, развиваются из ограниченного определения проблемы и возможных решений — чего-то поддающегося обработке и эффективного. По мере того как масштаб и охват операций расширяются, дальнейшие попытки управлять системой приносят всё меньше отдачи и всё чаще дают непредвиденные результаты. Это признаки того, что в дело вступают свойства сложных систем — всё запутывается.
Чаще всего я наблюдаю такой механизм преодоления трудностей: удвоить усилия, делать ещё больше анализа, ещё больше декомпозиции и вкладывать больше сил в более гибкую автоматизацию, охватывающую больше случаев. Это, в свою очередь, меняет природу успеха и неудач, порождая иногда более редкие, но крупные инциденты. Такая форма сочетания происходит путём замены того, что ломается, где возможно, а порой — просто случайно. Упорядоченным этот процесс не бывает.
Значительно реже встречаются механизмы, которые пытаются понять, от какой части аналитических и ориентированных на контроль подходов мы можем позволить себе отказаться, выявляют то, что неизменно в принципе, и затем расширяют механизмы, учитывающие сложность, изнутри наружу. Это куда менее комфортно, поскольку такая позиция требует отказаться от убеждения, что вы действительно контролируете ситуацию — крайне неприятное положение дел для любого бизнеса.
Действительно, давно ведутся споры о том, можно ли вообще избежать крупных аварий в значительных масштабах. Например, Жан-Кристоф Ле Коз предлагает следующую классификацию:
-
«Детерминистская» ветвь, где сами свойства технологических систем (например, жёсткая связность и сложность) в конечном счёте сводят на нет усилия по предотвращению аварий.
-
«Эпистемическая» ветвь, основанная на идее о том, что организации будут страдать от «провалов предвидения»: слабые сигналы и признаки того, что авария назревает, не будут замечены или приняты структурами власти, а устоявшиеся картины мира не будут соответствовать новым вызовам — что и ведёт к авариям.
-
«Самоорганизующаяся» ветвь, рассматривающая системы как адаптивные и потому интерпретирующая успехи и неудачи как последствия, возникающие из самоорганизации систем через исследование пространства проблем и решений с доступными им ресурсами.
Эти взгляды не полностью несовместимы, и авторы из одной категории нередко заимствуют идеи у других. Однако каждый подход имеет свою точку фокусировки — то, что считается важным и достойным внимания: структура управления, историчность системы, динамика властных структур, адаптивная и изменчивая природа систем, ограниченность перспектив участников, понятия вокруг культуры и так далее.
Многие участники этих дискуссий, констатируя, что аварии непредсказуемы или их трудно избежать, тем не менее ищут объяснения, способные сделать их менее вероятными. Они изучают ограничения известных подходов и расширяют границы того, что следует принимать во внимание, привнося новые перспективы, способные открыть новые грани понимания.
Существует обширная литература по многим дисциплинам, из которой можно почерпнуть понимание того, что не работает (и когда), и что контекстуально полезно. Противопоставление аналитической декомпозиции для контроля и сложности для эмерджентности, которое я предлагаю здесь, грубо и лишено нюансов — но именно это, хочется надеяться, делает его приемлемым инструментом для осмысления меняющихся систем.
Мы намеренно упрощаем, и понимать, какого рода упрощение мы допускаем, — полезно. Как сказал Джордж Бокс (1976): «Поскольку все модели неверны, [нам] следует быть бдительными к тому, что неверно существенным образом».
Сравнение подходов на практике
Следующие примеры намеренно карикатурны: они показывают относительно стереотипные взгляды на темы, актуальные для разработки ПО, — с позиции аналитической декомпозиции (с акцентом на контроль) и с позиции сложности (с акцентом, намеренно ограниченным влиянием):
| Тема | Аналитическая декомпозиция / Контроль | Сложность / Эмерджентность |
|---|---|---|
Обучение и образование |
Выстроить чётко определённую программу, лучшие практики для преподавателей и тренеров, механизмы проверки для обеспечения предсказуемых результатов и единообразия среди учащихся. |
Создавать среды, способствующие исследованию, экспериментированию и обмену информацией; обеспечивать руководство и поддержку. |
Безопасность |
Предотвращать нежелательные действия, ведущие к сбою. Опасности должны быть изолированы или устранены, а отклонения от процедур или лучших практик рассматриваются как риск. |
Поощрять позитивные действия, ведущие к успеху. Выяснять, как люди заполняют пробелы в процессах, обходят препятствия и восстанавливаются после проблем. |
Корректность |
Программное обеспечение делает то, что предписывает спецификация или API. Тесты проходят, функциональность реализована, система работает в известных границах. |
Пользователи или клиенты способны успешно решать свои задачи; цели могут меняться в зависимости от их потребностей. |
Надёжность |
Время доступности укладывается в допустимые рамки и верифицируется через SLA, SLO и т. д. Нагрузочное тестирование и тщательная верификация могут предотвратить сбои. |
«Девятки» не имеют значения, если клиенты недовольны. К тому же вы никогда не знаете наверняка, работает ли программа, пока она не выйдет в продакшен. Планируйте восстановление и умение справляться с неожиданностями. |
Работа с инцидентами |
Runbook’и определяют лучшие практики. Протоколы и процессы описывают, как максимально эффективно расследовать и сортировать проблемы. Строить системы для чёткой передачи информации и быстрой диагностики. Разбираться, что сломалось, чтобы исключить повторение. |
Неожиданности могут потребовать импровизации. Никто не знает, что произойдёт; нужно строить способность справляться с неизвестным. Расследования должны изучать нормальную работу, чтобы понять, как система функционирует в первую очередь. |
Разработка функций |
Понимание потребностей пользователей и сильных и слабых сторон текущих предложений позволяет определить, что и как строить. |
Эксперименты в реальных условиях с потенциальными функциями, которые вы итеративно совершенствуете, — лучший способ понять, какие функции окажутся полезными. |
Стандарты и нормы |
Формулируются однозначно, на основе верифицируемых процессов и результатов, чтобы применение было управляемым, масштабируемым и понятным. |
Формулируются в терминах целей, чтобы поддерживать и направлять людей, выполняющих работу и вынужденных адаптировать правила к своей реальности. |
Позиция, принятая в каждой из категорий, может подтолкнуть людей к принципиально разным подходам и практикам, которые иногда могут пересекаться, а иногда — нет. Стремление контролировать затраты и ошибки может мешать эффективности и желанию экспериментировать, а представления о том, как работают сложные системы, могут противоречить всевозможным мерам, традиционно используемым для демонстрации подотчётности.
Я называю эту таблицу карикатурной, потому что в реальном мире границы часто не столь чёткие и не столь поверхностные. Иерархия, ориентированная на контроль, вполне может согласовать менеджеров вокруг целей и делегировать полномочия вниз, чтобы справляться со сложностью системы; при этом контроль может подчёркиваться в зависимости от того, кому доверяют люди, обладающие властью. Централизованный контроль, как правило, наиболее эффективен на стороне аналитической декомпозиции, но есть и подходы, не ориентированные на контроль, которые от него выигрывают.
На самом деле многие практики могут использоваться в обоих подходах и служить разным людям для разных целей — или даже одновременно одному и тому же человеку:
| Практика | Аналитическая декомпозиция / Контроль | Сложность / Эмерджентность |
|---|---|---|
Ревью кода |
Находить баги и дефекты; отслеживать и распределять ответственность; обеспечивать качество. |
Формировать осведомлённость и создавать пространство для обратной связи внутри команд и между ними. |
Внедрение SLO |
Организационный инструмент, обеспечивающий надлежащее управление надёжностью всеми командами. |
Инструмент приоритизации, ценность которого определяется тем, что команды обсуждают и определяют приемлемый уровень надёжности. |
Рефакторинг |
Гасить технический долг, снижать сложность, улучшать поддерживаемость и гибкость, нормализовать используемые паттерны. |
Противодействие энтропии, адаптация кодовой базы к изменяющимся контекстам на основе новой информации или смещающихся требований. |
Chaos Engineering |
Проверка того, что ожидаемые сценарии отказов должным образом допускаются или из них восстанавливаются. |
Упражнение, движимое экспериментами, в ходе которого участники формулируют гипотезы о поведении системы в сценариях отказов и пытаются их подтвердить или опровергнуть. |
Использование платформы |
Общая платформа может поощрять правильные архитектурные паттерны и препятствовать нежелательным, абстрагируя сложность для команд, которые на ней строят. |
Платформы предоставляют системам средства для коммодитизации общих элементов ради экономии от масштаба и специализации, а также решают организационные узкие места через самообслуживание. |
Даже если практики из этого списка могут служить обоим подходам, это не значит, что они будут.
Например, ревью кода, ориентированное на контроль и стремящееся выкорчевать любое отклонение от устоявшихся норм, может приобретать конфронтационный характер, вызывать тревогу или мешать реальной обратной связи. Некоторые реализации, однако, могут успешно совмещать автоматизацию и правильные социальные нормы, в той или иной мере поддерживая обе цели.
По моему опыту, для этих практик исходная позиция действительно имеет значение — если вы хотите понять, как они разворачиваются и почему иногда не оправдывают чьих-то ожиданий. Эта исходная позиция также важна при расстановке приоритетов между практиками. Если участники или заинтересованные стороны не сходятся на высокоуровневой цели и желаемом результате, возникает разрыв в ожиданиях относительно того, как эти практики должны выполняться и как они выполняются на деле, — и в том, насколько важным им придают в системе.
Когда кто-то хочет изменить, дополнить или убрать какую-то из этих практик, полезно задуматься: в чём суть изменения и какую перспективу оно предпочитает?
Переключение между подходами
Как эвристика: когда доступны несколько линз, можно либо попытаться найти наилучшую (по каким-то произвольным критериям), либо использовать дополняющий или пересекающийся подход, задействующий как можно больше из них. Выбор единственной линзы может привести к поиску реализаций, которые в данном контексте максимизируют один тип деятельности — будь то контроль или эмерджентность, — тогда как комбинированный подход может добиться того, чтобы выбранные практики были способны обслуживать несколько свойств одновременно, как своего рода компромисс.
Иногда получается не то, что было задумано. Организация, выстраивающая практики ради контроля, может обнаружить, что незаметно полагается на практиков, которые переориентируют эти практики на вклад, согласованный со сложностью. Между тем лица, принимающие решения в организации, осуществляют меньше контроля, чем им кажется, или приписывают достигнутые результаты собственным действиям. Тогда они могут потерять то, что имели, — изменив механизмы контроля и попутно помешав скрытым адаптациям.
И наоборот: если практики настроены на эмерджентность, но выполняются механически, как будто предназначены для контроля, они не принесут ожидаемых преимуществ и рискуют выглядеть и ощущаться как бесполезная работа ради работы: организация не получает ни контроля, ни адаптивного эффекта.
По широким темам и категориям — таким как надёжность или корректность — зачастую нет чётко обозначенных задокументированных принципов, которыми можно руководствоваться. Тем не менее организации, как правило, располагают некоторыми общими инструментами, которые выстраиваются вдоль спектра от контроля к эмерджентности, — обычно это инструменты проектирования процессов и механизмы принуждения к их исполнению.
Предположим, вам не нравится, что команды из других отделов без предупреждения изменяют чувствительный код, которым владеет ваша команда. Можно предпринять следующее: провести с ними переговоры, подтверждая право собственности и напоминая об ожидаемом процессе. Потребовать предварительного RFC-документа или тикета перед подачей любого запроса на изменение. Опираться на файлы владения кодом (code ownership files), чтобы ни одно неожиданное изменение не продвинулось без вашего согласия. Перенести ключевой код в репозитории, к которым другие команды не имеют доступа.
Все эти меры относительно локальны и воздействуют на непосредственную окружающую структуру, чтобы скорректировать действия и предотвратить нежелательные. Они могут быть чрезвычайно эффективными при минимальных усилиях, но также могут невольно не сделать желаемое поведение более вероятным.
С позиции, ближе к эмерджентности, более типично разобраться, что заставляет другие команды присылать эти изменения без предупреждения. Какие ограничения и давления они видят, из-за которых их нынешнее поведение кажется им разумным? Если все соглашаются, что процесс — это хорошее идеальное состояние, но его регулярно игнорируют, что воспринимается как более важное? Только разобравшись в этом, следует проектировать вмешательство. Такое исследование — нередко подсказываемое паттернами, на которые ранее указывал Ле Коз, — как правило, тянет за нить, которая разматывается через всю организацию. Это может занять много времени и быть трудным без установленного доверия, но способно переформатировать ожидания и с равной лёгкостью привести как к масштабным переменам, так и к небольшим вмешательствам на более ранних этапах.
Комбинированный подход — это когда широкое понимание ситуации достигается опорой на методы, учитывающие сложность, а затем используется для проектирования простых, но высокоэффективных проверок и барьеров, при которых минимальный контроль даёт высокую отдачу. Он опирается на позицию, учитывающую сложность, чтобы смотреть не только на структуру и цели системы, но и на то, как взаимодействуют её различные компоненты и участники. Когда взаимодействия становятся понятнее, аналитический подход, хочется надеяться, оказывается более действенным.
Риск здесь в том, что вы можете оказаться с системой, которая либо кажется настолько неуправляемой, либо настолько устойчивой к подходам, учитывающим сложность, либо настолько негибкой к сквозным вмешательствам, что вы возвращаетесь к чисто локальным защитам — только уже запоздавшим и требующим больше усилий для достижения того же результата.
Тогда вопрос не в том, какой подход лучше, а в том, как узнать, когда текущий подход исчерпывает себя, — и что делать дальше?
Ловушки некритического проектирования систем
Люди постоянно меняют свои системы — осознанно или нет. Им это нередко удаётся, пусть и не всегда, и не так, как они планировали. Знание, на что обращать внимание, не гарантирует успеха, но повышает его шансы.
Это может быть справедливо и в нынешних потрясениях, движимых LLM. Поскольку технология новая и проектные паттерны ещё не устоялись, многие люди экспериментируют несколько хаотично. Многие их идеи содержат интересные элементы или аспекты, достойные изучения, но с точки зрения систем в них есть очевидные пробелы, которые всё равно придётся заполнять.
Читая мнения в технических изданиях, почти невозможно не наткнуться на примеры масштабных предложений о переменах, которые я намеренно не буду здесь цитировать. Но среди них встречаются идеи вроде:
-
Замены ревью кода различными видами барьеров (тесты и автоматические проверки) — как правило, без вопросов о том, какие эмерджентные роли эта практика могла выполнять и чем статичные барьеры качественно отличаются от более адаптивных.
-
Разбивки работы с ПО на высокоуровневые спецификации, которые переводятся в код в чёрном ящике с исключительно внешними проверками — без объяснений того, как спецификации могут охватывать разные уровни абстракции, как внешние проверки могут оставаться управляемыми и как в каждом направлении должна пересекать эти границы полезная информация.
-
Призывов к тому, чтобы все стали своего рода менеджерами агентов, удерживая агентов в жёстких контурах управления — без вопросов о том, что именно теряется (или хотя бы вызывается как эффекты второго порядка) в этой аналогии при оптовой замене механизмов делегирования и контроля.
-
Акцента на наблюдаемых системных результатах и отказа от навязывания внутренней структуры — в расчёте на то, что система самоорганизуется надлежащим образом.
Если вы проектируете систему, ориентируясь на контроль, — используете барьеры (вспомните модель швейцарского сыра), обширное тестирование, процессы и процедуры, гарантирующие лучшие практики, — то следует уделять не меньше внимания механизмам, позволяющим понять, работает ли контроль на самом деле. Это значит задавать себе такие вопросы:
-
Как мы знаем, что наши наблюдения остаются актуальными и что мы улавливаем нужные сигналы?
-
Как мы можем понять, что наше понимание системы теряет точность?
-
Что наш анализ оставляет за рамками или затушёвывает, пытаясь сделать вещи прозрачными?
-
Сколько вариативности допустимо и не подавляем ли мы необходимые её виды?
-
Не создаёт ли то, что мы оптимизируем, хрупкость в других местах?
-
Наш контроль реален или иллюзорен? Как мы узнаем, если это изменится?
Хорошо регулируемые системы компенсируют нарушения таким образом, что скрывают или подавляют сигналы о накапливающихся проблемах — как на техническом, так и на культурном уровне. Эти вопросы направлены на то, чтобы выяснить, задумывается ли кто-нибудь о том, что скрывает подобное поведение.
Когда вы проектируете ради эмерджентности — думайте о самоорганизации, рыночно-подобных механизмах или делегировании решений участникам с местным контекстом, — возникают другие вопросы:
-
Не работают ли локальные части системы в противоречии друг с другом?
-
Насколько эффективна согласованность целей? Что поддерживает связность?
-
Какими возможностями или эффективностью мы жертвуем, отказываясь от прозрачности?
-
Можем ли мы позволить себе потерять эффективность системы, ориентированной на контроль? Когда она может понадобиться?
-
Как отличить адаптацию от дрейфа?
-
Что сохраняет инакомыслие и доносит информацию с периферии системы?
Поскольку подходы, учитывающие сложность, как правило, противятся предписывающим позициям, здесь нередко возникают риски усиления инерции или повсеместного рассогласования. Эмерджентные свойства будут ключевыми для успеха и неудачи, но без определённой осторожности в мышлении и влиянии вещи могут зажить собственной жизнью.
Когда кто-то продвигает системное проектирование, ориентированное на аналитическую декомпозицию или контроль, спрашивайте, как они знают, что делают нужное, и какими механизмами адаптируются. Когда кто-то продвигает проектирование, обещающее саморегуляцию и бесконечную гибкость, спрашивайте, как они будут поддерживать связность и на каких условиях рассчитывают на хорошие результаты. Когда кто-то призывает перейти от одного к другому, спрашивайте, что зависит от нынешнего поведения, и обдумывайте возможные эффекты второго порядка.
Технологические компании часто спешат переизобрести себя вокруг грандиозных обещаний новых технологий. Интеграция новой технологии в существующие рабочие процессы, как правило, требует преобразования этих процессов. Такие изменения нередко направлены на снижение вариативности и усиление контроля, но пересекают границы подсистем так, что разрушают запутанные взаимодействия, которые были динамически стабильны.
Автоматизация, делающая вещи предсказуемыми, неизбежно устраняет элементы непредсказуемости, которые могут быть полезны для адаптации и эволюции. Равным образом, попытка сделать часть системы более адаптивной неизбежно делает её менее предсказуемой. И то, и другое имеет волновые эффекты на остальную систему.
Где и как система мигрирует из одного режима работы в другой? Где контроль необходим, а где — нет? Что мы решаем анализировать и декомпозировать, а к чему относиться как к экосистеме?
Если у нас нет ответов на эти вопросы, у нас нет и хорошего ответа на то, как наши системы будут избегать сбоев или добиваться успеха. Системы — это системы. Они будут продолжать вести себя как системы и отказывать как системы.