AfRel/doc/resource-limitations.md

Ресурсные ограничения в AfRel

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

AfRel выделяет три первичных типа ресурсных ограничений, которые должны быть явно отражены в каждом артефакте ( targ , req , task , check ):

Количество (Quantity, X)

Это масштаб системы (или задачи) в количественных единицах.

Примеры:

• Число пользователей, сервисов, запросов в секунду (RPS)
• Объём данных (TB, количество записей)
• Количество строк кода, модулей, команд
• Время выполнения (секунды, часы, дни)

Как фиксируется в артефактах:

• X должен иметь текущее значение (current), целевое (target) и единицу измерения (unit).
• Для req/task/check — вклад в изменение X по сравнению с родительским артефактом.

Качество (Quality, Y)

Это «плотность» или эффективность на единицу количества.

Примеры:

• Латентность (p95, p99), пропускная способность (throughput)
• Доступность (99.9%, время простоя)
• Частота ошибок (error rate), точность (precision/recall)
• Надёжность (MTBF), безопасность (количество уязвимостей)

Как фиксируется в артефактах:

• Y должен быть измеримым и привязанным к условиям (нагрузка, окружение).
• Y может улучшаться или ухудшаться, и это должно быть явно указано.

Деньги и ресурсы (Money / Resources, Z)

Это стоимость достижения цели или поддержания состояния.

Что сюда входит:

• Бюджет (капитальные и операционные затраты)
• Зарплаты людей, человеко-часы
• Стоимость инфраструктуры (облако, железо, лицензии)
• Стоимость времени простоя, потери данных, юридических рисков

Как фиксируется в артефактах:

• Z должен содержать абсолютные или относительные значения (например, «экономия $100k/год» или «ROI 18 месяцев»).
• Z может быть отрицательным (отток денег на инвестиции), но тогда должен быть план возврата к положительному Z на горизонте цели.
• Взаимодействие ограничений

Три типа ограничений не независимы. AfRel требует фиксировать их вместе, потому что:

• Улучшение качества (Y↑) часто требует увеличения ресурсов (Z↓) или сокращения масштаба (X↓).

• Расширение масштаба (X↑) может привести к падению качества (Y↓) или росту затрат (Z↓).

• Экономия ресурсов (Z↑) может быть достигнута только за счёт сжатия (X↓) или ухудшения качества (Y↓).

Любой артефакт, который описывает изменение только одной оси без учёта двух других, считается неполным (и, как правило, паразитическим). Пример фиксации ограничений в артефакте YAML

id: "1b-targ"
  x:
    current: "10 сервисов, 500 заказов/сек"
    target: "3 сервиса, 500 заказов/сек"
    unit: "число сервисов, заказы/сек"
  y:
    current: "latency p95=200ms, availability=99.9%"
    target: "latency p95=100ms, availability=99.99%"
    unit: "ms, %"
  z:
    current: "операционные затраты $500k/год"
    target: "затраты $350k/год, экономия $150k/год"
    unit: "USD/год"

Выход за ограничения (невозможно, но иногда кажется)

AfRel не запрещает ставить амбициозные цели, но требует:

• Явно указать, какие ограничения временно нарушаются (например, отток Z на время инвестиций)
• Описать обратный путь к соблюдению ограничений
• Иметь контрольные точки, на которых проверяется, не стали ли нарушения необратимыми

Если артефакт не содержит явного плана возврата к допустимым ограничениям — он считается нежизнеспособным.

Связь с кубом выживания

Три оси куба выживания — это и есть ресурсные ограничения:

• X → количество
• Y → качество
• Z → деньги/ресурсы

Каждое состояние системы — точка в кубе. Каждая цель — вектор. Допустимые движения определяются текущими и прогнозируемыми ограничениями.

Отрицательные значения по осям X, Y, Z (например, убыток, уменьшение количества, деградация качества) — это не выход за пределы куба, а состояния, ведущие к нежизнеспособности системы. Задача AfRel — не допустить, чтобы система попадала в такие состояния без плана выхода из них.