Часть VI. Организационная модель¶
К этому моменту у нас уже есть почти весь технический каркас:
- архитектура;
- безопасность;
- память;
- слой выполнения;
- наблюдаемость и цикл оценки.
Но дальше почти всегда начинается не техническое, а организационное узкое место.
Part V уже объяснила, как систему наблюдать и как выносить judgments о ее поведении. Следующий вопрос другой: кто владеет этими слоями, кто поддерживает shared defaults и у кого вообще есть право удерживать продуктовые команды внутри production discipline.
Даже хорошая агентная платформа быстро упрется в вопросы:
- кто владеет базовыми слоями;
- кто отвечает за политики и guardrails;
- как продуктовые команды используют платформу, не ломая ее;
- как не получить пять несовместимых рантаймов внутри одной компании.
В этой части мы разберем организационную модель: кто за что отвечает, как строить золотые пути и как не превратить платформу в хаотичный набор локальных решений.
Короткий маршрут по этой части
Если тебе нужен быстрый проход, иди так:
- Глава 14: понять, где проходит граница между platform ownership и product ownership;
- Глава 15: посмотреть, как эта граница превращается в golden paths и shared gateways;
- Часть VII: увидеть, как орг-модель закрепляется уже в эталонной реализации.
Вместе это показывает, что operating model нужен не для орг-диаграммы, а для устойчивости всей production-системы.
Что решает эта часть¶
- делает ownership boundaries явными до того, как платформа расползется организационно;
- показывает, как platform ownership превращается в golden paths, shared gateways и controlled deviations;
- объясняет, кто должен владеть теми слоями, которые предыдущие части уже определили технически;
- подготавливает переход от operating model к reference implementation.
В этой части¶
- Глава 14. Платформенная команда и продуктовые команды Эта глава продолжает тот же support-кейс на уровне владения: кто должен отвечать за runtime, policies, gateways и platform incidents.
- Глава 15. Золотые пути, общие шлюзы и антизоопарк-подходы Эта глава превращает ownership boundaries в инженерные defaults: какие общие пути должны быть проще локального переизобретения, где gateway должен централизовать чувствительные задачи и как не дать платформе превратиться в зоопарк.
Куда она ведет дальше¶
Следом идет Часть VII: путь от ownership model и golden paths к reference implementation, где эти решения уже закрепляются в runtime, policy layer и rollout skeleton.
То есть мост здесь намеренный:
- Part V задает capture, health и judgment;
- Part VI раздает ownership для этих concerns;
- Part VII превращает эту орг-модель в runnable structure;
- Part VIII управляет системой после rollout через response, evidence и accountability.