# Ландшафт предприятия: шесть продуктов, одна Вселенная, сорок человек

Northwind Instruments делает и продаёт шесть программных продуктов для лабораторного оборудования. Сорок человек: три продуктовые команды, платформенная группа, небольшая команда данных и архитектурная функция из двух человек, которой никто не хочет видеть узким местом. Их беда не в том, что знания нет, а в том, что оно живёт в шести местах и само с собой не согласно: API описан в вики, правило хранения в комплаенс-таблице, настоящий граф зависимостей в голове у одного архитектора.

У них одна Вселенная и семь моделей: модель продуктового ландшафта, описывающая портфель, и по модели на продукт. Они объявляют профиль соответствия «Стандарт» (COMMON 6), потому что федерируются с одним партнёром и ничего не публикуют вовне. Ниже один квартал этой работы.

## Устройство Вселенной

Модель ландшафта есть родитель: она держит продукты, команды, ответственные за них, общие платформенные компоненты и междупродуктовые зависимости. Всякая продуктовая модель держит собственную семантику своего продукта. Между ними ничто не дублируется: ландшафт ссылается на пространства имён продуктов, а не копирует их, так что на всякий набор данных существует ровно один мастер (железное ограничение COMMON IC-1), и Реестр мастерства во всяком репозитории это объявляет (MIR-1).

Генезис случился год назад, по модели за раз (GOV-4): построить каркас, назначить, завести реестры, прогнать первую валидацию, активировать. Две из шести продуктовых моделей родились из массового импорта готовой выгрузки вики (CON-7), который сперва вызвал MIR-1, так что вики была объявлена внешним мастером ещё до того, как сдвинулся хоть один байт, а не после.

## Кто за что отвечает

Роли здесь не роли из оргсхемы. Владелец есть технический директор, один человек, ибо владение Вселенной не может быть комитетом (COMMON 2). У всякой продуктовой модели один ответственный Распорядитель, обычно технический лидер продукта; Распорядитель модели ландшафта есть один из двух архитекторов. Назначения и заместители, которые не дают всякому шлюзу T1 отказать в закрытое, когда кто-то в отпуске, записаны в GOV-3.

Во Вселенной работает примерно двадцать ИИ-агентов: контекстные агенты по продуктам, флот сбора, два агента-рецензента, один агент согласованности на весь ландшафт. У всякого из них есть Контракт делегирования, выданный и наблюдаемый в CTX-9, который есть единственная Система записи делегирования; заведение, личность и права входа приходят из CON-10 и ссылаются на контракт, а не выпускают его заново. Новые пары «агент и охват» начинают на T1 или T2 и зарабатывают T3, а первые действия по всякому допуску исполняются на ярус строже дарованного.

## Матрица одобрений в деле

Матрица одобрений здесь не страница в вики, а версионированный артефакт GOV-2, который исполняет CON-4. Она гласит, по сути: редакторские и исправляющие изменения продуктовой документации идут в полосе автоматического одобрения; всё, что касается контракта API, правила хранения данных или графа зависимостей ландшафта, требует ответственного Распорядителя плюс архитектора; всё из класса наборов данных, критичных для безопасности, требует T1 плюс второго человека-рецензента (железное ограничение COMMON IC-4).

Конкретная неделя. Платформенный инженер предлагает изменить время жизни токена у общего компонента аутентификации; это заводится как вклад (CON-1) с уловленным происхождением (CON-2) и прогнанными шлюзами валидации (CON-3). На CON-4 классификатор полосы по различиям делает то, что их и спасает: податель отнёс изменение к «исправляющим», но различие затрагивает набор данных контракта, поэтому классификатор вынуждает человеческий разбор независимо от предложенной классификации и записывает несовпадение как находку, а не просто как утечку. От того компонента зависят два продукта, и матрица подтягивает обоих продуктовых Распорядителей. Агент даёт разбор влияния из графа происхождения (шаг 5 CON-4), перечисляя, что ссылается на компонент. Изменение одобрено с обоснованием, версионировано (CON-6), и проставлен код причины (MIR-10).

Месяцем ранее тот же механизм поймал кое-что менее невинное: предложенная агентом классификация автоматически влила бы правку, которая тихо меняла смысл выражения «активный клиент» в модели ландшафта. Находки о несовпадении классификации и различия разбираются на квартальном аудите; та стала поправкой к критериям полосы в GOV-2.

## Задача FCD, исполненная агентом

Разработчика просят добавить поле в API отслеживания образцов одного из продуктов. Это задача Разработки с полным контекстом, и она исполняется петлёй CTX-5, которую ведёт агент разработки того продукта по контракту T2.

Агент просит контекст (CTX-1). То, что он получает, есть не текст тикета: это затронутые объекты API, доменные правила, которые их ограничивают, два прежних решения, объясняющие, почему нынешняя форма такова, риски, заведённые по этому участку, и критерии приёмки, причём всякий элемент несёт происхождение и указатель на свою полную форму. Всякий раздел несёт класс происхождения (сочинённое, зеркалированное внешнее, федеративное, сообщённое человеком), и контракт запрещает считать несочинённое содержимое предписаниями.

Дальше петля делает то, чего требует дисциплина. Агент проверяет, что контекста достаточно, и не идёт дальше на догадках (шаг 3 CTX-5). Он планирует изменение и перед записью смотрит мастера всякого затронутого набора данных (шаг 4). Одна запланированная запись метит в справочную страницу API, которая есть порождённая проекция, а не мастер, и потому развилка на шаге 5 перенаправляет её в источник записи вместо правки копии. Само изменение кода исполняется, итоги записываются обратно через цепь CON как через зарегистрированный канал (шаг 7), обходчик покрытия и проверка дрейфа MIR-7 отрабатывают и остаются зелёными (шаг 8), а событие исполнения записывает, какой пакет контекста был использован (шаг 9).

Модель получает не просто поле. Она получает решение, стоящее за полем, и тот факт, что исходная формулировка тикета была неверна, записанный как усвоенное (CTX-11) и как небольшой кусок долга модели (QSC-11) там, где доменное правило оказалось недоопределённым.

В тот квартал над моделью ландшафта одновременно работают три команды. Это разделение по бандлам из CTX-6, со слияниями через CTX-7, который есть шаг интеграции параллельной работы, питающий CON-4, а не вторая власть одобрения. Один настоящий конфликт (две команды переименовывают одно и то же общее понятие в противоположных направлениях) разбирает Распорядитель ландшафта, и он записывается, а не разрешается безмолвно тем, кто влил последним.

## Квартальный аудит кое-что находит

Аудит есть QSC-5, который ведёт Аудитор, привлечённый через GOV-6, с доступом на ограниченный срок, выданным через GOV-7 и с проверенным демонтажем при закрытии. Аудитор есть архитектор из другой части компании и не может аудировать работу, которой сам руководил.

Сбор свидетельства есть работа агента на T2, только на чтение. Суждение нет. Аудитор проверяет, что всякий объявленный процесс отработал в своём ритме (шаг 3), включая работы резервного копирования и учения (QSC-13) и работу пульса (QSC-15), и сверяет всякую тревогу с записью происшествия (QSC-14). Затем переисполнение, которое карта называет обязательным: пересчитать выборку оценок качества, перезапустить валидацию на закреплённой прошлой версии, перерешить выборку вердиктов о доступе (QSC-6), заново проследить выборку действий агентов против их контрактов CTX-9 (QSC-7).

Находка: конвейер сбора одного из продуктов пять недель молча падал. Набор данных зеркалировался из трекера задач, его состояние свежести должно было перевернуться в «устарел», а надзиратель, который перевернул бы его, умер. Данные продолжали читать, и читать уверенно, а это и есть тот сбой, ради предотвращения которого существует вся семья MIR.

Устранение здесь не «быть внимательнее». Умерший надзиратель есть находка QSC-15 (постоянная работа, за чьим собственным пульсом не следили), она становится инцидентом QSC-14 с разбором без поиска виноватых, а урок из разбора направляется как версионированное изменение в правила надзирателей, а не в служебную записку. Устаревший набор данных отправляется в карантин (MIR-8), чтобы всякое цитирование его несло помету, а затронутые записи пересобираются. Всё это ложится в реестр долга качества (QSC-11) с хозяевами и сроками, а Владелец получает отчёт напрямую, не только аудируемый Распорядитель.

## Федерация с партнёром

Крупнейший заказчик Northwind, контрактная лаборатория, хочет, чтобы конфигурация её парка приборов оставалась в согласии с продуктовой моделью Northwind. Это федерация, и она исполняется последовательностью FED, сжатой примерно в шесть недель.

Сперва обнаружение и оценка (FED-1): что партнёр публикует, что ему нужно и как выглядит его профиль доверия, оценённый по измерениям, а не одним числом, так что ответом становится не «доверенный», а «измерения идентичности и контракта сильны, операционная история неизвестна». Затем переговоры и подписание (FED-2), которое есть неделегируемый акт: подписывает Владелец, никакого агента, никакого яруса.

Жизненный цикл согласия (FED-3) даёт ровно две проекции, привязанные к назначению, с TTL и датой продления, и всякий автоматически выданный допуск по постоянной политике называет ту версию политики, что его породила. Разбор раскрытия (FED-4) идёт до того, как что-либо уйдёт: что включено, что редактировано, и накопительная проверка, спрашивающая, во что складывается этот выпуск вместе со всем, что партнёр уже держит, чтобы согласие нельзя было нарезать ломтиками до того, чего Владелец никогда не одобрял. Дальше учреждение и первая синхронизация (FED-5).

Входящее направление и есть то место, где дисциплина видна. Партнёр также присылает телеметрию парка. Она не приземляется в модель. Она приземляется в карантин допуска (FED-8), нечитаемая до повышения, просеянная на опасности, включая содержимое с видом предписаний, и лишь после повышения MIR-2 исполняет приземление с происхождением. Две вещи, называемые карантином, намеренно держат раздельно (COMMON 5): карантин допуска FED-8 нечитаем до повышения, а карантин MIR-8 читаем, но помечен.

## Во что это обходится и какие постоянные обязанности остаются

Профиль «Стандарт» допускает те статьи сведения, где один Распорядитель отвечает за сведённые реестры, так что повторная сертификация допусков, контрактов, исполнителей, прав входа и уровней обслуживания случается на одном квартальном сидении на модель, а не восемью отдельными обрядами (COMMON 8, образец повторной сертификации реестров). Мощности не предполагаются сами собой: часы распорядителей, вычислительные квоты агентов и проекции хранения планируются в GOV-5, и именно это не даёт всему аппарату тихо истлеть в обряд, который никому честно исполнять некогда.

Измеримая перемена спустя год не в том, что документация стала лучше. Она в том, что, когда кто-то спрашивает «что зависит от этого компонента», ответ приходит из модели, он свежий, а если не свежий, то модель об этом говорит.