Часть VI. Организационная модель¶
К этому моменту у нас уже есть почти весь технический каркас:
- архитектура;
- безопасность;
- память;
- слой выполнения;
- наблюдаемость и цикл оценки.
Но дальше почти всегда начинается не техническое, а организационное узкое место.
Часть V уже объяснила, как систему наблюдать и как выносить суждения о ее поведении. Следующий вопрос другой: кто владеет этими слоями, кто поддерживает общие настройки по умолчанию и у кого вообще есть право удерживать продуктовые команды внутри промышленной дисциплины.
Даже хорошая агентная платформа быстро упрется в вопросы:
- кто владеет базовыми слоями;
- кто отвечает за политики и защитные ограничения;
- как продуктовые команды используют платформу, не ломая ее;
- как не получить пять несовместимых сред исполнения внутри одной компании.
В этой части мы разберем организационную модель: кто за что отвечает, как строить золотые пути и как не превратить платформу в хаотичный набор локальных решений.
Короткий маршрут по этой части
Если тебе нужен быстрый проход, иди так:
- Глава 14: понять, где проходит граница между платформенной и продуктовой ответственностью;
- Глава 15: посмотреть, как эта граница превращается в золотые пути и общие шлюзы;
- Часть VII: увидеть, как орг-модель закрепляется уже в эталонной реализации.
Вместе это показывает, что операционная модель нужна не для орг-диаграммы, а для устойчивости всей промышленной системы.
Маршруты канонических сценариев
В операционной модели три канонических сценария требуют разных границ ответственности. Разбор обращений поддержки проверяет, кто владеет настройками записи тикетов, режимом подтверждения и путем восстановления после дубля. Внутренний ассистент знаний проверяет, кто владеет корпусом знаний, проверкой доступа, качеством поиска и происхождением знаний. Координация инцидентов проверяет, кто владеет правом эскалации, политикой уведомлений, ответственностью за реагирование и действиями после инцидента.
Что решает эта часть¶
- делает границы ответственности явными до того, как платформа расползется организационно;
- показывает, как платформенная ответственность превращается в золотые пути, общие шлюзы и управляемые отклонения;
- объясняет, кто должен владеть теми слоями, которые предыдущие части уже определили технически;
- подготавливает переход от операционной модели к эталонной реализации.
В этой части¶
- Глава 14. Платформенная команда и продуктовые команды Эта глава продолжает тот же сценарий поддержки на уровне владения: кто должен отвечать за среду исполнения, политики, шлюзы и платформенные инциденты.
- Глава 15. Золотые пути, общие шлюзы и антизоопарк-подходы Эта глава превращает границы ответственности в инженерные настройки по умолчанию: какие общие пути должны быть проще локального переизобретения, где шлюз должен централизовать чувствительные задачи и как не дать платформе превратиться в зоопарк.
Куда она ведет дальше¶
Следом идет Часть VII: путь от модели ответственности и золотых путей к эталонной реализации, где эти решения уже закрепляются в среде исполнения, слое политик и каркасе поэтапного выпуска.
То есть мост здесь намеренный:
- Часть V задает захват поведения, здоровье системы и суждения;
- Часть VI распределяет ответственность за эти темы;
- Часть VII превращает эту орг-модель в исполняемую структуру;
- Часть VIII управляет системой после поэтапного выпуска через реагирование, доказательства и ответственность.