Перейти к содержанию

Часть VI. Организационная модель

К этому моменту у нас уже есть почти весь технический каркас:

  • архитектура;
  • безопасность;
  • память;
  • слой выполнения;
  • наблюдаемость и цикл оценки.

Но дальше почти всегда начинается не техническое, а организационное узкое место.

Часть V уже объяснила, как систему наблюдать и как выносить суждения о ее поведении. Следующий вопрос другой: кто владеет этими слоями, кто поддерживает общие настройки по умолчанию и у кого вообще есть право удерживать продуктовые команды внутри промышленной дисциплины.

Даже хорошая агентная платформа быстро упрется в вопросы:

  • кто владеет базовыми слоями;
  • кто отвечает за политики и защитные ограничения;
  • как продуктовые команды используют платформу, не ломая ее;
  • как не получить пять несовместимых сред исполнения внутри одной компании.

В этой части мы разберем организационную модель: кто за что отвечает, как строить золотые пути и как не превратить платформу в хаотичный набор локальных решений.

Короткий маршрут по этой части

Если тебе нужен быстрый проход, иди так:

  • Глава 14: понять, где проходит граница между платформенной и продуктовой ответственностью;
  • Глава 15: посмотреть, как эта граница превращается в золотые пути и общие шлюзы;
  • Часть VII: увидеть, как орг-модель закрепляется уже в эталонной реализации.

Вместе это показывает, что операционная модель нужна не для орг-диаграммы, а для устойчивости всей промышленной системы.

Маршруты канонических сценариев

В операционной модели три канонических сценария требуют разных границ ответственности. Разбор обращений поддержки проверяет, кто владеет настройками записи тикетов, режимом подтверждения и путем восстановления после дубля. Внутренний ассистент знаний проверяет, кто владеет корпусом знаний, проверкой доступа, качеством поиска и происхождением знаний. Координация инцидентов проверяет, кто владеет правом эскалации, политикой уведомлений, ответственностью за реагирование и действиями после инцидента.

Что решает эта часть

  • делает границы ответственности явными до того, как платформа расползется организационно;
  • показывает, как платформенная ответственность превращается в золотые пути, общие шлюзы и управляемые отклонения;
  • объясняет, кто должен владеть теми слоями, которые предыдущие части уже определили технически;
  • подготавливает переход от операционной модели к эталонной реализации.

Редакционная связка с предыдущей частью такая: если в Части V команда научилась доказывать, что произошло и можно ли выпускать изменение дальше, то в Части VI она назначает владельцев этих доказательств. Без этого trace, SLO и eval gate остаются правильными артефактами без операционной ответственности.

Практический мост от SLO и eval к владельцам и золотому пути

После trace review, SLO-карты и regression gate следующий вопрос уже не технический: кто владеет этим контуром и как сделать его путем по умолчанию для следующих команд.

Минимальная связка ответственности выглядит так:

responsibility_map:
  support_ticket_write_path:
    product_owner:
      owns:
        - user_workflow
        - task_success_definition
        - escalation_policy_for_support
    platform_owner:
      owns:
        - runtime_retry_contract
        - trace_schema
        - eval_gate_integration
        - rollout_default_policy
    security_owner:
      owns:
        - high_risk_write_policy
        - approval_requirements
        - audit_retention_expectations
    oncall_owner:
      owns:
        - containment_decision
        - rollback_or_freeze_execution

А минимальный золотой путь для пишущего агента должен уже включать не только runtime template, но и общий tool gateway, idempotency key, tool_policy_decision, approval path, trace events, eval gates и staged canary по умолчанию.

golden_path:
  name: support_write_agent
  required_controls:
    - shared_tool_gateway
    - idempotency_key
    - standard_trace_schema
    - approval_for_high_risk_write
    - duplicate_ticket_after_timeout_eval
    - no_open_side_effect_unknown_incidents
  rollout:
    default_mode: staged_canary
    expansion_requires:
      - offline_eval_passed
      - online_slo_within_budget
      - responsibility_confirmed

Этот мост нужен для логической нити рукописи: часть про надежность доказывает, что произошло и можно ли выпускать изменение дальше; организационная часть назначает владельцев этих доказательств; золотой путь делает безопасный маршрут проще локального обхода.

В этой части

Куда она ведет дальше

Следом идет Часть VII: путь от модели ответственности и золотых путей к эталонной реализации, где эти решения уже закрепляются в среде исполнения, слое политик и каркасе поэтапного выпуска.

То есть мост здесь намеренный:

  • Часть V задает захват поведения, здоровье системы и суждения;
  • Часть VI распределяет ответственность за эти темы;
  • Часть VII превращает эту орг-модель в исполняемую структуру;
  • Часть VIII управляет системой после поэтапного выпуска через реагирование, доказательства и ответственность.