|
|
@@ -0,0 +1,104 @@
|
|
|
+# Ресурсные ограничения в **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
|
|
|
+
|
|
|
+```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** — не допустить, чтобы система попадала в такие состояния без плана выхода из них.
|
SVI