8. Уровень представления#

Автоматизация VLAN работала уже шесть недель. Сетевая команда гордилась результатом. Каждое утро от прикладных команд поступало три-четыре новых заявки на обслуживание, и оркестратор обрабатывал их без единого нажатия клавиши кем-либо из сетевых инженеров. Развёртывания выполнялись. Коммутаторы настраивались. Сеть работала исправно.

В четверг поступила эскалация. Руководитель прикладной команды спрашивал, почему заявки на VLAN занимают от трёх до пяти рабочих дней, тогда как в портале значится “отправлено”. Сетевая команда проверила свою очередь: ноль ожидающих заявок, все развёртывания успешны. Автоматизация обработала каждую заявку в течение двадцати минут с момента получения. Но тикеты ServiceNow по-прежнему показывали “В работе”, потому что никто не написал интеграцию, которая их обновляла бы.

Автоматизация сделала своё дело. Результат оказался невидимым.

Неделю спустя команда развернула быстрый портал самообслуживания, чтобы прикладные команды могли напрямую подавать заявки и отслеживать их статус. К полудню за один час поступило сорок семь заявок на VLAN. Все корректные. Все правильно отформатированные. Проблема: у портала не было модели авторизации. Он принимал заявки от любого, у кого был URL. Все заявки выполнялись под единственным API-токеном с правами администратора платформы. Не было ни ограничения скорости, ни шлюза согласования, ни журнала аудита.

Автоматизация работала. Модель доступа - нет.

Оба эти сбоя являются сбоями уровня представления. Один - отсутствие обратной связи; другой - отсутствие ограждений. Эта глава закрывает данный пробел.

8.1. Основы#

8.1.1. Контекст#

Каждый из рассмотренных ранее строительных блоков обращён внутрь: к другим блокам или к инженерам, понимающим платформу. Source of Truth (SoT) хранит сетевое намерение для систем автоматизации. Исполнитель применяет изменения к устройствам. Observability проверяет результаты. Orchestrator координирует их все. У каждого из этих блоков есть интерфейс - UI, API или оба - разработанный для тех, кто строил и эксплуатирует платформу, а не для всех, кому нужно с ней взаимодействовать.

Presentation (Layer) уровень обращён наружу. Его задача - сделать платформу доступной для аудиторий, которым не нужно понимать её внутреннее устройство: для прикладной команды, запрашивающей сетевой сервис; для аудитора безопасности, выясняющего, что изменилось в прошлом квартале; для конвейера CI/CD, подготавливающего инфраструктуру без участия человека.

В Главе 3 блок представления располагался на краю фреймворка NAF, обращённый к людям и внешним системам. Глава 6 установила границу между визуализацией наблюдаемости и представлением: дашборды, построенные непосредственно на сетевой телеметрии, относятся к блоку наблюдаемости по концептуальному сходству; то, как эти дашборды предоставляются не-инженерам, управляются доступом или встраиваются в порталы - забота уровня представления. Глава 7 установила, что асинхронные рабочие процессы требуют конечных точек статуса и хуков уведомлений. Уровень представления обеспечивает и то, и другое.

8.1.2. Цели#

Уровень представления преследует три цели, которые напрямую соответствуют трём архитектурным функциям.

1. Обеспечить стабильный аутентифицированный API с согласованной моделью доступа. Каждый потребитель - человек или машина - должен взаимодействовать с платформой через версионированный, управляемый доступом контракт, который не меняется без предупреждения. Базовые блоки могут заменяться, обновляться или реструктурироваться; контракт, обращённый к потребителю, должен оставаться стабильным. Аутентификация и авторизация применяются на этой границе, централизованно, а не дублируются в каждом инструменте.

2. Обслуживать каждый тип потребителя через интерфейс, подходящий его рабочему процессу. У сетевого инженера и у руководителя прикладной команды разные потребности, разная глубина технических знаний и разные ожидания от того, как автоматизация с ними общается. Уровень представления обеспечивает несколько поверхностей: GUI-порталы, Command Line Interface (CLI), интеграции с чат-системами - все они опираются на один API и одну модель доступа, а статус отображается той аудитории, которая инициировала действие.

3. Соединить платформу с внешними системами в обоих направлениях и доставлять результаты через каналы, которыми уже пользуются потребители. Прикладная команда уже работает в ServiceNow. Конвейер CI/CD уже работает в системе контроля версий. Платформа должна встречать их там, где они находятся: принимать запросы из их систем и возвращать результаты в те же системы, не требуя нового инструмента в их рабочем процессе.

8.1.3. Столпы#

Три столпа поддерживают эти цели, по одному на каждую функцию:

1. Уровень API: основа: версионированные, аутентифицированные, применяющие RBAC, стабильные контракты. Аутентификация и мультиарендность применяются здесь, а не в каждом инструменте. На нём строятся все остальные поверхности.
2. Клиентские интерфейсы: все обращённые к потребителю поверхности (GUI-порталы, CLI, мобильные приложения, чат-системы) как разные форм-факторы одного базового API.
3. Интеграции и уведомления: подключения к внешним системам (ITSM, CI/CD конвейеры, системы обмена сообщениями) и доставка исходящих результатов (вебхуки, коллбэки, push-уведомления).

8.1.4. Область применения#

Уровень представления отображает. Он не производит.

В области применения:

• Уровень API: аутентификация, авторизация, версионирование и ограничение скорости для всех потребителей
• Клиентские интерфейсы, построенные на этом API: GUI-порталы, CLI, чат-системы, мобильные поверхности
• Внешние интеграции: рабочие процессы ITSM, хуки конвейера CI/CD, доставка вебхуков
• Исходящие уведомления: коллбэки статуса, push-оповещения, события в каналах обмена сообщениями
• Операционные дашборды при предоставлении не-инженерным аудиториям (управление доступом, охват аудитории и встраивание в порталы; архитектура базовых метрик относится к Главе 6)

Вне области применения:

• Производство данных (Observability, Глава 6)
• Рендеринг конфигурации и обработка шаблонов (источник истины, Глава 4)
• Выполнение рабочих процессов и ведение записей аудита (Orchestrator, Глава 7)

Уровень представления, который начинает накапливать бизнес-логику (решать, какой рабочий процесс запускать, проверять входные данные на соответствие сетевой модели, управлять состоянием рабочего процесса), превратился во что-то другое. Эти обязанности принадлежат оркестратору и источнику истины. Если портал начинает кодировать сетевую политику или логику повторных попыток, архитектурная граница рухнула, и платформу будет трудно развивать независимо.

8.2. Функции#

Три цели и столпа реализуются через три основные функции, каждая из которых непосредственно соответствует одной цели и одному столпу:

1. Уровень API: контракт и модель доступа для всех потребителей
2. Клиентские интерфейсы: поверхности, построенные на этом контракте
3. Интеграции и уведомления: подключения к внешним системам и доставка исходящих данных

graph LR

    subgraph Goals
        direction TB
        A1[Stable authenticated API and consistent access model]
        A2[Right surface for each consumer type]
        A3[Bidirectional integration with external systems]
    end

    subgraph Pillars
        direction TB
        B1[API layer: versioned, authenticated, stable]
        B2[Client interfaces: GUI, CLI, chatops, mobile]
        B3[Integrations and notifications: ITSM, CI/CD, webhooks]
    end

    subgraph Functionalities
        direction TB
        C1[API Layer]
        C2[Client Interfaces]
        C3[Integrations and Notifications]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

8.2.1. Уровень API#

Глава 4 подробно рассматривала собственный API источника истины: как системы автоматизации запрашивают данные о намерении, паттерны потребления (REST, GraphQL, вебхуки) и модель чтения/записи сетевой конфигурации. API, рассматриваемый здесь, отличается по назначению: это обращённый наружу контракт для потребителей платформы автоматизации в целом. Если API источника истины отвечает на вопрос “как должна выглядеть сеть?”, то API уровня представления отвечает на вопрос “что делает платформа автоматизации и как с ней взаимодействовать?”. Оба могут быть REST API; они обслуживают разные аудитории с разными моделями доступа.

API уровня представления является основой. Каждая поверхность потребителя (портал, CLI, форма ITSM, чат-бот, агент ИИ) является вызывающей стороной этого уровня. Аутентификация, RBAC, версионирование и ограничение скорости применяются здесь. Спроектируйте его хорошо, иначе всё вышестоящее унаследует его проблемы.

API представления не должен отражать внутренние интерфейсы блоков. Раскрытие конечной точки /v1/sot/vlans/, проксирующей напрямую к API источника истины, или /v1/orchestrator/jobs/, оборачивающей идентификаторы заданий оркестратора, привязывает потребителей к внутренним деталям реализации. Когда вы заменяете один блок другим, каждый конвейер CI/CD, хранивший эти идентификаторы, нужно обновить. Вместо этого API представления должен раскрывать концепции уровня платформы: конечную точку /v1/requests/, представляющую заявку на обслуживание независимо от того, какой оркестратор её обработал; конечную точку /v1/services/vlan/, возвращающую текущее состояние VLAN, агрегированное из источника истины и наблюдаемости, без раскрытия того, какой блок предоставил каждый фрагмент данных. Потребители получают стабильный контракт; внутренняя реализация может свободно развиваться за ним.

8.2.1.1. Что раскрывает API#

API раскрывает две категории конечных точек:

• Конечные точки чтения: статус и история рабочего процесса, записи аудита, состояние устройств и сервисов, агрегированное из блоков источника истины и наблюдаемости. Это запросы, которые прикладная команда использует для проверки статуса заявки, аудитор - для проверки записи об изменении, а система мониторинга - для проверки работоспособности платформы.

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

Различие чтение/запись также определяет стабильность контракта. Конечные точки чтения должны оставаться стабильными неопределённо долго: дашборд, работающий год, не должен ломаться из-за изменения схемы выше по потоку. Конечные точки записи должны версионироваться явно, с уведомлениями об устаревании до внесения критических изменений.

8.2.1.2. Версионирование и стабильность#

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

Стандартный подход: версионирование через URL-префикс (/v1/, /v2/) или через заголовок Accept, поддержание предыдущей версии в течение определённого периода устаревания и информирование о критических изменениях через журнал изменений. Конвейер CI/CD, восемь месяцев вызывавший /v1/workflows/trigger, не должен в понедельник обнаружить, что конечная точка переехала без предупреждения.

8.2.1.3. Аутентификация и авторизация#

Аутентификация отвечает на вопрос: кто вы? Авторизация отвечает на вопрос: что вам разрешено делать?

Многие команды реализуют аутентификацию раньше авторизации, а затем обнаруживают, что “аутентифицированный” и “авторизованный” - разные проблемы, когда кто-то отправляет сорок семь заявок под действительным токеном, которого у них не должно было быть.

Паттерны аутентификации для платформ сетевой автоматизации:

• SSO / интеграция с LDAP: корпоративный стандарт. Инженеры и прикладные команды аутентифицируются с помощью корпоративной идентификационной записи. Нет отдельных учётных данных для управления, а отзыв доступа происходит автоматически при увольнении.
• OAuth 2.0 / OIDC: для внешних систем и пользователей веб-портала. Создаёт краткосрочные токены вместо долгосрочных учётных данных.
• Токены API с ограниченной областью: для программного доступа конвейерами CI/CD и скриптами автоматизации. Каждый токен ограничен определённым набором разрешений с определённым сроком действия. Общий административный токен, используемый всеми потребителями, - это не аутентификация: это общий пароль, который нельзя отозвать, не сломав одновременно все вызывающие стороны.

Авторизация через RBAC. Роли должны соответствовать операционным обязанностям, а не возможностям инструментов. Начальная модель для сетевой автоматизации:

• read-only: просмотр любых данных, без запуска действий
• operator: запуск предварительно одобренных рабочих процессов, утверждение шлюзов, отправка заявок на обслуживание
• engineer: полное управление рабочими процессами, доступ на запись в источник истины, просмотр всех записей аудита
• admin: конфигурация платформы, управление пользователями, ротация учётных данных

Каждая роль наследует все разрешения роли ниже. Инженер может делать всё, что может оператор, плюс записывать в источник истины и управлять рабочими процессами.

flowchart TD
    RO[read-only]
    OP[operator]
    ENG[engineer]
    ADM[admin]

    RO -->|adds: trigger workflows + approve gates| OP
    OP -->|adds: SoT write access + workflow management| ENG
    ENG -->|adds: platform config + user management| ADM

    style RO fill:#e8f5e9,stroke:#4caf50
    style OP fill:#c8e6c9,stroke:#388e3c
    style ENG fill:#a5d6a7,stroke:#2e7d32
    style ADM fill:#66bb6a,stroke:#1b5e20

RBAC применяется на границе API. Базовые блоки видят только аутентифицированные API-вызовы от уровня представления; они не управляют идентификацией потребителей независимо. Мультиарендность реализуется через ограничение данных: каждый запрос фильтруется по организационной области вызывающей стороны. Прикладная команда корпуса B не должна видеть заявки розничной команды корпуса A. Это должно быть спроектировано с самого начала. Ретроактивное добавление мультиарендности в плоскую модель данных - болезненный проект по реструктуризации.

Журнал аудита должен фиксировать отклонённые запросы наряду с одобренными. Кто пытался что-то сделать и был отклонён, так же важно для соответствия требованиям, как и то, что было разрешено. Уровень представления создаёт эту запись вместе с журналом аудита рабочего процесса из Главы 7. Глава 12 расширяет эту модель ротацией секретов, политикой как кодом и потоками автоматизации, управляемыми требованиями соответствия.

8.2.1.4. Ограничение скорости#

Автоматизированные потребители без ограничения скорости исчерпают очередь оркестратора. Инцидент с сорока семью заявками не требовал злоумышленника: только мотивированной команды, URL и отсутствия дросселирования.

Ограничение скорости на границе API: лимиты на токен (запросов в минуту на потребителя), лимиты пакетов (одновременных выполняемых запросов) и операционно-специфические лимиты (рабочий процесс обновления прошивки никогда не должен выполняться более чем в одном экземпляре на устройство одновременно). Ответы на превышение лимита должны возвращать HTTP 429 с заголовком Retry-After, а не тихое заполнение очереди, проявляющееся как тайм-аут спустя часы.

8.2.1.5. REST, GraphQL и интерфейс MCP#

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

Интерфейс Model Context Protocol (MCP) - это поверхность ИИ уровня представления. Подобно тому, как операторы-люди получают доступ к платформе через CLI, а прикладные команды - через портал, агенты на основе Large Language Model (LLM) получают к ней доступ через MCP-сервер. Агент вызывает инструменты (запросить статус рабочего процесса, запустить устранение неполадки, прочитать журнал аудита) в любой последовательности, которую требует его рассуждение, подчиняясь той же модели RBAC, что и любой другой вызывающий. Это напрямую связывает с паттерном агентной оркестрации, введённым в Главе 7 (раздел 7.2.7): MCP-сервер уровня представления - это интерфейс, который делает эти паттерны работоспособными на всей платформе без жёстко закодированных интеграций между агентом и каждым отдельным блоком.

REST и MCP различаются тем, кто управляет взаимодействием. В REST-интеграции потребитель знает заранее, какие конечные точки вызывать и в каком порядке: конвейер CI/CD вызывает POST /v1/requests/vlan, затем опрашивает GET /v1/requests/{id} до завершения. Последовательность зафиксирована в коде. С MCP агент на основе Large Language Model (LLM) решает во время выполнения, какие инструменты вызывать и в какой последовательности, основываясь на результате каждого предыдущего вызова. Потребитель - не конвейер с заранее определённым графом вызовов; это система рассуждения, которая читает каждый результат, прежде чем решить, что делать дальше. MCP-сервер определяет доступные инструменты и их схемы; агент решает, как их использовать. Это делает MCP подходящим для открытых операционных запросов (“расследуй проблему с подключением между корпусом B и ядром”), которые потребовали бы от разработчика предвидеть каждую возможную последовательность вызовов при реализации через REST. Это также делает авторизацию более чувствительной: агент с широким доступом к инструментам может комбинировать операции способами, для которых модель доступа явно не была разработана. RBAC-модель должна применяться на уровне инструментов, а не только на уровне сервера.

8.2.2. Клиентские интерфейсы#

Клиентские интерфейсы - это поверхности, построенные на API. Они являются разными форм-факторами одной базовой платформы, каждый из которых подходит для разного типа потребителей. RBAC-модель применяется единообразно независимо от того, какая поверхность используется.

8.2.2.1. GUI и портал самообслуживания#

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

Прикладная команда видит трёхэтапный вид: отправлено, в процессе, завершено - со статусом, который читается как “предварительные проверки выполняются на 24 коммутаторах” на понятном языке, а не идентификаторами заданий AWX. Сетевой инженер видит результаты предварительных проверок по устройствам, шлюз утверждения с действиями “одобрить” или “отклонить” и полную трассировку рабочего процесса при необходимости. Администратор видит всё, включая конфигурацию и запросы аудита.

К интерфейсам чтения и записи предъявляются разные требования проектирования. Дашборд только для чтения может быть относительно открытым: любой инженер платформы может видеть текущее состояние своих заявок. Путь записи (отправка заявки, утверждение шлюза, отмена выполняющегося задания) требует проверки входных данных, шага подтверждения и чёткого изложения того, что произойдёт до фиксации действия.

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

Риск принятия выше всего на уровне интерфейса. Технически правильный портал, которым никто не пользуется, потому что он не вписывается в то, как команда уже работает, даёт меньше ценности, чем более простая интеграция в инструмент, который все открывают каждое утро. Прикладная команда, которая уже живёт в ServiceNow, будет последовательнее подавать заявки через форму ServiceNow, чем через новый портал, который нужно изучать и в который нужно отдельно авторизоваться. Инженерная команда, использующая Slack для координации во время инцидентов, будет быстрее реагировать на уведомления о шлюзах утверждения через сообщение в Slack, чем через браузерную ссылку с дополнительной аутентификацией. Знакомость снижает трение при принятии и уменьшает количество ошибок в повседневном использовании. Там, где есть выбор между созданием новой поверхности и встречей пользователей в инструменте, который они уже знают, интеграция почти всегда является правильным первым шагом.

8.2.2.2. CLI#

CLI для платформы автоматизации - это не CLI устройства, который является областью Главы 9. Это интерфейс командной строки для самой платформы: инструмент, используемый инженерами для запуска, проверки и управления автоматизацией без открытия браузера.

Инженеры предпочитают CLI по той же причине, по которой предпочитают шелл-скрипты GUI для повторяющейся работы: компонуемость, скорость и возможность написания скриптов. Команду CLI можно создать как псевдоним, передать другим командам через конвейер, запустить в цикле по списку устройств, включить в инструкцию или зафиксировать в репозитории вместе с управляемой ею инфраструктурой. Клик в портале не может. Во время инцидента в 2 часа ночи команда, набранная по памяти за пять секунд, быстрее, чем портал, на навигацию и аутентификацию в котором уходит двадцать секунд. Для конвейеров CI/CD CLI создаёт структурированные коды выхода (0 для успеха, ненулевой для отказа), которые напрямую сопоставляются с условиями прохождения/отказа шага конвейера без какого-либо разбора. Инженеры также больше доверяют инструментам CLI для высокорисковых операций: параметры видны в истории шелла, поддаются аудиту и воспроизводимы.

CLI занимает своё место даже при наличии портала. Во время инцидента в 2 часа ночи открыть браузер, авторизоваться, перейти к рабочему процессу и нажать на форму медленнее, чем выполнить одну команду. Для конвейеров CI/CD CLI предпочтительнее сырых API-вызовов: он управляет аутентификацией из переменных окружения, создаёт структурированные коды выхода и даёт понятный вывод при сбое.

Принципы проектирования CLI для платформы автоматизации:

• Согласованная структура команд существительное-глагол (workflow run, workflow status, request list), предсказуемо соответствующая API-операциям
• Читаемый машиной вывод через флаг --json, чтобы скрипты конвейера могли разбирать результат
• Конфигурация с учётом окружения: конечная точка API и токен считываются из файла конфигурации или переменных окружения, а не жёстко закодированы в скриптах
• Тот же RBAC, что применяется к API, применяется к CLI: токен с разрешениями уровня оператора не может запускать операции уровня администратора независимо от того, какая поверхность используется

8.2.2.3. Мгновенные сообщения и мобильные приложения#

Slack, Teams и аналогичные платформы выполняют двойную роль в сетевой автоматизации: они являются и каналом уведомлений (уровень представления передаёт в них события), и поверхностью взаимодействия (инженеры отправляют через них команды). Понимание этой двойной роли важно для архитектуры: то же рабочее пространство, которое получает уведомления об оповещениях, должно поддерживать потоки утверждения, снижая переключение контекста для инженеров, которые уже мониторят эти каналы.

Как поверхность взаимодействия, платформы обмена сообщениями работают через ботов, которые переводят разговорные команды в API-вызовы. Бот тонкий: он разбирает сообщение, сопоставляет его с вызовом API уровня представления под идентификационной записью отправителя и форматирует ответ для канала. Три паттерна хорошо работают на практике:

• Потоки утверждения: сообщение в Slack с кнопками “Утвердить” и “Отклонить” позволяет сетевому инженеру действовать в ожидающем шлюзе, не выходя из Slack. Нажатие кнопки вызывает конечную точку API утверждения с идентификационной записью инженера, разрешённой через интеграцию SSO платформы с OAuth Slack.
• Запросы статуса: @netbot status app-payments возвращает текущее состояние рабочего процесса в форматированном сообщении канала.
• Быстрые действия: @netbot compliance-check building-b запускает лёгкий рабочий процесс проверки и публикует результат прямо в чате.

Мобильные интерфейсы обслуживают специфическую аудиторию, которую порталы и CLI не охватывают: технических специалистов центра обработки данных, работающих физически в поле. Техник, заменяющий линейную карту в стойке, не открывает ноутбук. Его руки могут быть заняты, позиция неудобна. Мобильное приложение, позволяющее ему отсканировать штрих-код устройства, посмотреть его текущее состояние автоматизации (управляется автоматизацией, последнее развёртывание 14 дней назад, без ожидающих изменений), подтвердить физическую замену и запустить соответствующий рабочий процесс устранения неполадок, связывает физическую работу с платформой автоматизации без возврата на рабочую станцию. RBAC-модель применяется: токен техника ограничен операциями, которые позволяет его роль. Интерфейс ограничен данными, актуальными для полевой работы: идентификация устройства, текущее состояние, ожидающие задачи и простые действия запуска, а не полный вид платформы.

Та же RBAC-модель применяется. Бот аутентифицирует инженеров через SSO и пересылает запросы с токеном, ограниченным ролью этого инженера. Инженер с доступом только для чтения не может запустить рабочий процесс через Slack так же, как через портал.

Как цель уведомлений, каналы обмена сообщениями получают управляемые событиями обновления от уровня представления: завершения развёртываний, оповещения об отказах, запросы шлюзов утверждения и критические ошибки рабочего процесса. Маршрутизация уведомлений - это политика конфигурации, а не жёстко закодированное сопоставление. Инженеры получают детали об отказах в специализированном канале операций. Прикладные команды получают статус завершения через обновление тикета ITSM. Дежурные инженеры получают критические отказы через PagerDuty.

Мобильные интерфейсы следуют тому же паттерну. Ограничением является размер экрана и модель взаимодействия, а не архитектура. Мобильный интерфейс утверждения, позволяющий инженеру утверждать ожидающий шлюз со своего телефона, вызывает тот же API, что и портал. RBAC-модель не изменяется.

8.2.2.4. Когда создавать, а когда принимать встроенные UI#

Почти каждый блок уже имеет UI. AWX имеет портал рабочего процесса. Nautobot имеет веб-интерфейс. Grafana имеет дашборды. Эти встроенные UI достаточны для инженерных аудиторий, которые понимают платформу. Решение о создании специализированного уровня представления не должно быть стандартным.

Практическая последовательность принятия решения:

1. Все ли потребители - инженеры, уже использующие UI блоков? Используйте встроенные UI. Не создавайте специализированный портал.
2. Нужно ли не-инженерам запрашивать автоматизацию или отслеживать её? Вам нужен либо портал, либо интеграция с ITSM.
3. Является ли ITSM уже местом управления всеми заявками на обслуживание? Либо примите ITSM как уровень представления, либо интегрируйтесь с ним как с основным потребителем. Если движок рабочих процессов ITSM, модель утверждения и система уведомлений достаточны для ваших паттернов запросов, пусть ITSM будет уровнем представления напрямую: вызовы автоматизации исходят из рабочих процессов ITSM, а не из отдельного уровня над ним. Если вам нужен более мощный API-контракт, кросс-блочные представления статуса или RBAC, который ITSM не может чисто применить, тонкий специализированный уровень между ITSM и блоками даёт вам эти свойства, пока ITSM остаётся пользовательской поверхностью.
4. Нужен ли вам RBAC, единообразно охватывающий несколько блоков? Вам нужен уровень API с централизованной аутентификацией, независимо от того, какие клиентские поверхности вы строите поверх него.
5. Можете ли вы взять на себя долгосрочное обслуживание специализированного портала? Если неуверены, начните с интеграции ITSM. Создавайте портал только тогда, когда ITSM оказывается недостаточным для необходимых паттернов доступа.
6. Нужно ли потребителям вводить или просматривать детали, которые формы ITSM не могут представить? Сложные поля ввода (фрагменты YAML, параметры топологии, предварительный просмотр распределения подсетей), встроенная проверка относительно модели источника истины или подробные представления статуса с детализацией по устройствам обычно выходят за рамки того, что конструкторы форм ITSM поддерживают чисто. Если потребителям регулярно нужен такой уровень конкретики, специализированный портал оправдывает свои операционные затраты.

Специализированный портал стоит создавать, когда не-инженерам нужен доступ, который ITSM не может чисто выразить, или когда нужен единый кросс-блочный вид статуса, который ни один из встроенных UI не предоставляет. Наиболее распространённая ошибка - создавать его до проверки того, что потребность реальна.

8.2.2.5. Документация и отчётность#

Два связанных вывода уровня представления только для чтения обслуживают аудитории, которые потребляют знания об автоматизации асинхронно: потребители документации (команды, которым нужно понять текущее состояние сетевых сервисов) и потребители отчётов (менеджеры и аудиторы, которым нужны периодические сводки и доказательства соответствия требованиям).

Здесь применяется паттерн “документация как код”: документация, генерируемая из живых данных платформы с использованием языков шаблонов (Jinja2, Markdown), версионируемая вместе с кодовой базой автоматизации и регенерируемая при каждом изменении. Диаграммы Mermaid, встроенные в генерируемые документы, могут отражать фактическую топологию из источника истины, а не поддерживаемые вручную рисунки. Аналогично, логика нормализации, которую блок наблюдаемости применяет к необработанным метрикам (рассмотренная в Главе 6), может быть повторно использована здесь: шаблон отчёта запрашивает те же нормализованные временные ряды для создания табличных сводок для аудиторов, без дублирования работы по нормализации.

• Автогенерируемая документация преобразует живые данные платформы в читаемые, доступные для совместного использования артефакты без ручного обслуживания. Для каждого развёрнутого сетевого сервиса генерируемый документ может объединить определение сервиса из источника истины, текущий операционный статус из наблюдаемости и историю изменений из журнала аудита оркестратора. Поскольку исходные данные всегда актуальны, документация остаётся актуальной автоматически. Определения рабочих процессов в оркестраторе - ещё один источник: генератор документации может создать понятную для человека инструкцию из определения рабочего процесса, обеспечивая соответствие описанного в инструкции тому, что автоматизация фактически делает.

• Отчётность обслуживает аудитории менеджмента и соответствия требованиям, которым нужны периодические сводки, а не представления в реальном времени. Еженедельные сводки изменений (сколько рабочих процессов выполнено, коэффициент успеха, средняя продолжительность, задействованные устройства) питают операционные обзоры. Экспорты для соответствия требованиям (все записи об изменениях за период, структурированные для аудиторского представления) собираются из журнала аудита оркестратора и журнала авторизации уровня представления. Отчёты о SLA и ёмкости (тенденции времени подготовки, коэффициенты ошибок по классам устройств, невыполненная очередь заявок) питают обсуждения планирования ёмкости и улучшения сервиса.

Операционные дашборды охватывают обе главы по концепции. Глава 6 охватывает архитектуру данных: что собирается, как нормализуется и дашборды, построенные непосредственно на телеметрии для инженерных аудиторий. Участие уровня представления начинается, когда те же дашборды предоставляются не-инженерным аудиториям: встраивание их в портал самообслуживания, ограничение доступа так, чтобы прикладные команды видели только свои сервисы, или структурирование удобных для мобильных устройств представлений для полевого использования. Базовые метрики остаются в блоке наблюдаемости; модель доступа и контекст поверхности - забота уровня представления.

Отличие от операционных дашборды (Глава 6) - в потребителе и временных рамках: дашборды показывают текущее состояние инженерам, принимающим решения в реальном времени; документация и отчёты - снимки, потребляемые асинхронно не-инженерами. Базовые данные могут быть теми же. Поверхность и частота разные.

8.2.3. Интеграции и уведомления#

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

Отличие от уровня API состоит в направленности и инициировании. Уровень API обрабатывает входящие запросы: потребитель вызывает платформу и ждёт ответа. Интеграции и уведомления касаются обращения платформы к системам, которые не инициировали текущее взаимодействие: отправка обновления статуса в тикет ServiceNow, доставка коллбэка вебхука конвейеру CI/CD, ожидающему асинхронно, публикация события в канал Slack, мониторящий конкретный сервис. Уровень API отвечает на вызовы. Этот раздел отправляет события. Оба используют одну и ту же модель аутентификации и границы RBAC; разница в направлении инициирования. При небольшом масштабе один компонент чисто справляется с обоими паттернами. При большем масштабе доставка исходящих событий (со своей логикой повторных попыток, очередями недоставленных сообщений и управлением подписками) обычно становится отдельным компонентом со своими операционными задачами, поэтому эта модель разделяет их как отдельные функции.

8.2.3.1. Интеграция с ITSM#

Платформы ITSM занимают два разных положения в архитектуре сетевой автоматизации, и это различие важно для проектирования. В первом положении платформа ITSM является уровнем представления: её формы определяют пользовательский интерфейс, её движок рабочих процессов обрабатывает утверждения и уведомления, а API автоматизации вызывается из рабочих процессов ITSM. В этой модели нет внешней интеграции, потому что ITSM не является внешним по отношению к уровню представления: она и есть уровень представления. Во втором положении существует специализированный уровень представления, а платформа ITSM является одним из потребителей, с которыми он синхронизируется: запросы поступают через вебхуки ITSM, а обновления статуса возвращаются в тикеты ITSM. Третья роль также распространена: ITSM как источник данных для источника истины. Когда CMDB содержит авторитетные записи об активах или сервисах, источник истины может запрашивать его как федеративный источник данных (рассмотрено в Главе 4), но ITSM в этой роли не участвует в пользовательском интерфейсе автоматизации.

Остаток этого раздела описывает паттерн интеграции (второе положение). Паттерн ITSM-как-уровень-представления (первое положение) является правильным выбором, когда движок рабочих процессов платформы ITSM, модель утверждения и система уведомлений достаточны для ваших паттернов запросов и вы хотите избежать введения отдельного уровня между пользователями и блоками.

Интеграция с ITSM - это то, что вы строите, когда потребители не должны знать о существовании платформы автоматизации. Прикладная команда уже работает в ServiceNow. Наиболее удобный интерфейс - тот, которым они уже пользуются.

Форма ServiceNow “Новая заявка на сетевой сервис” захватывает именно те поля, которые нужны модели источника истины, и отправляет их в структурированном формате, которого ожидает уровень API. Форма - это уровень представления; потребитель никогда не видит API-вызов. При отправке уровень представления проверяет полезную нагрузку, аутентифицирует токен сервисной учётной записи, используемой интеграцией ITSM, и пересылает структурированный запрос оркестратору.

После запуска заявки тикет должен отражать состояние рабочего процесса практически в реальном времени: “Проверка источника истины завершена”, затем “Предварительные проверки выполняются: 24 коммутатора”, затем “Шлюз утверждения: ожидает подписи инженера”, затем “Завершено: 24/24 коммутатора настроены”. Эта двунаправленная синхронизация сложнее одноразового вебхука. Она требует от уровня представления подписки на события статуса оркестратора и их перевода в обновления тикетов с помощью постоянной подписки на события или опросного рекончайлера.

Во многих организациях тикет ITSM является записью управления изменениями. Уровень представления должен обеспечивать, чтобы тикет содержал достаточно информации для удовлетворения требований управления изменениями, даже если авторитетный журнал аудита находится в оркестраторе. Две записи служат разным аудиториям: тикет ITSM служит заявителю и его менеджеру; запись аудита оркестратора служит сетевому инженеру и аудитору соответствия требованиям.

Интеграция с ITSM имеет ограничения. Она подходит для структурированных, форм-ориентированных рабочих процессов запросов с определёнными состояниями. Она не подходит для операционных запросов в реальном времени, проверки трасс сложных рабочих процессов или опытных пользовательских операций, где инженерам нужно быстро итерировать. Проектируйте платформу, зная, что ITSM охватывает большинство не-инженерных запросов, а CLI или портал - остальное.

8.2.3.2. Интеграция с конвейером CI/CD#

Конвейер развёртывания, подготавливающий сетевые ресурсы, вызывает API уровня представления на определённом шаге, передаёт структурированные входные данные и блокируется до получения результата успеха или отказа. Конвейер работает под сервисной учётной записью со скопированным токеном: достаточных разрешений для запуска сетевого рабочего процесса и чтения его статуса, не больше.

Здесь CLI также занимает своё место в автоматизированных контекстах. Шаг конвейера, выполняющий netauto workflow run vlan-deploy --params params.json --wait, проще отлаживать, проще версионировать и проще заменять, чем сырой HTTP-вызов, выстраивающий полезную нагрузку API встроенно. Структурированный код выхода CLI напрямую сопоставляется с условием прохождения/отказа шага конвейера.

8.2.3.3. Push-уведомления и доставка вебхуков#

Когда рабочий процесс завершается, достигает шлюза утверждения или завершается с ошибкой, уровень представления уведомляет нужную аудиторию через нужный канал. Маршрутизация уведомлений - это политическое решение, а не жёстко закодированное сопоставление. Инженеры получают детали об отказах в специализированном канале Slack. Прикладные команды получают статус завершения через обновление тикета. Дежурные инженеры получают критические отказы через PagerDuty. Правила маршрутизации - это конфигурация, а не код.

Доставка вебхуков является исходящим аналогом входящих вебхуков. Вызывающая сторона, зарегистрировавшая URL коллбэка при запуске рабочего процесса, получает результат через HTTP POST при завершении рабочего процесса. Гарантии доставки, политика повторных попыток при отказе и схема полезной нагрузки являются частью API-контракта. Коллбэк, завершающийся молча (без повторной попытки, без журнала, без оповещения), хуже отсутствия коллбэка вообще, потому что вызывающая сторона предполагает, что результат был доставлен.

8.2.4. Ландшафт решений#

Перечисленные здесь инструменты являются примерами для пояснительных целей, а не рекомендациями. Оценивайте их с учётом возможностей вашей команды, существующих инструментов и операционных ограничений.

Глава о представлении имеет иное отношение к ландшафту решений, чем любая другая глава Части 2. Почти не существует инструментов, существующих исключительно как представление. У каждого блока уже есть UI. Архитектурный вопрос звучит не “какой инструмент представления мне использовать?”. Он звучит так: когда принять встроенные UI каждого блока, а когда строить специализированный уровень представления поверх них?

В зрелых платформах автоматизации сосуществуют две модели.

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

• Модель специализированного представления: создание или принятие уровня над блоками, обеспечивающего единый опыт. Необходимо, когда не-инженерам нужен доступ, когда нужен статус нескольких блоков в одном представлении или когда требования RBAC не сопоставляются чисто со встроенными разрешениями отдельных инструментов.

Понимание того, что находится внутри встроенных UI, важно для решений о кастомизации. NetBox построен на Django (Python); его веб-интерфейс и REST API являются представлениями Django и конечными точками Django REST Framework. Nautobot разделяет ту же родословную. Infrahub использует FastAPI. “Компонент представления” этих инструментов источника истины - это зрелый веб-фреймворк: настраиваемый через плагины, пользовательские представления и расширения сериализаторов. Это одновременно его сила (хорошо документированный, производственного уровня) и его ограничение (вы настраиваете внутри фреймворка, разработанного прежде всего для случая источника истины, а не для случая портала самообслуживания).

Строка ITSM в таблице выше представляет ITSM как уровень представления, а не как внешнюю интеграцию. Когда организация стандартизировалась на ServiceNow или Jira Service Management как точке входа для всех заявок на обслуживание, ITSM является уровнем представления. API автоматизации - это то, что ITSM внутренне вызывает как часть своих рабочих процессов; никакой отдельный шлюз не находится между пользователем и ITSM. Шлюз располагается между ITSM и нижестоящими блоками.

Один архитектурный принцип, охватывающий все подходы: уровень представления должен быть тонким. Это поверхность, а не система. Бизнес-логика принадлежит оркестратору и источнику истины. Уровень представления переводит, аутентифицирует и маршрутизирует. В момент, когда он начинает принимать решения об автоматизации, граница рухнула.

8.3. Пример реализации#

8.3.1. Две поверхности, три аудитории, одна платформа#

Мы следовали кампусной сети на протяжении всей Части 2. Заявка на VLAN-сервис для app-payments была смоделирована в источнике истины в Главе 4, развёрнута исполнителем в Главе 5, проверена наблюдаемостью в Главе 6 и скоординирована от начала до конца оркестратором в Главе 7. Что так и не было рассмотрено - как три разные аудитории взаимодействуют с этим рабочим процессом.

В этом кампусе уровень представления состоит из трёх компонентов. ServiceNow является основным интерфейсом для более широкой организации: прикладные команды подают заявки и отслеживают статус полностью внутри ServiceNow, который маршрутизирует через API уровня представления как часть собственной автоматизации рабочего процесса. Специализированный портал с представлением аудита обслуживает инженерную и комплаенс-аудитории: сетевые инженеры проверяют результаты предварительных проверок и действуют в шлюзах утверждения там, а аудиторы безопасности запрашивают составные записи об изменениях через его интерфейс аудита только для чтения. Обе поверхности разделяют один и тот же уровень API, который находится в самом уровне представления и применяет аутентификацию, RBAC и версионирование до того, как любой запрос достигает базовых блоков.

Три аудитории

• Прикладная команда подаёт заявки через форму ServiceNow. Они хотят знать, когда сервис готов и что произошло в случае отказа. Им никогда не нужно открывать AWX или Nautobot. ServiceNow является их уровнем представления; API платформы - это то, что они никогда не видят.

• Сетевой инженер получил уведомление о шлюзе утверждения во время рабочего процесса (Глава 7, шаг 3). Им нужно видеть результаты предварительных проверок для 24 целевых коммутаторов, утвердить или отклонить и иметь возможность проверить результат. Их интерфейс - специализированный портал: более детальный, чем форма ServiceNow, но всё ещё ограниченный областью их команды.

• Аудитор безопасности приходит три месяца спустя с вопросом: кто запросил этот VLAN, кто его утвердил, какая версия рабочего процесса развёртывания выполнялась и каким было состояние затронутых коммутаторов до и после? Их интерфейс - представление аудита портала: только для чтения, без возможности что-либо запускать.

Две поверхности представления

Уровень API является общей основой внутри уровня представления. И ServiceNow, и специализированный портал маршрутизируют каждый запрос через него, прежде чем что-либо достигает базовых блоков. Он применяет три токена на основе ролей: токен оператора прикладной команды (читать собственные заявки, подавать новые заявки), токен инженера сетевой команды (читать все заявки в своей области, утверждать или отклонять шлюзы) и токен аудитора только для чтения (запрашивать записи аудита по всей платформе, без доступа на запись). Ни одна поверхность его не обходит.

flowchart TD
    subgraph Consumers
        AT[Application Team]
        NE[Network Engineer]
        SA[Security Auditor]
    end

    subgraph PL[Presentation Layer]
        SN[ServiceNow]
        PORTAL[Custom Portal]
        API[API Layer: Auth · RBAC · Versioning]
    end

    subgraph Blocks[Platform Blocks]
        ORC[Orchestrator]
        SOT[Source of Truth]
        OBS[Observability]
    end

    AT --> SN
    NE & SA --> PORTAL
    SN & PORTAL --> API
    API --> ORC & SOT & OBS

    classDef presentation fill:#f0e6ff,stroke:#9b59b6,color:#4a235a
    classDef api fill:#e8e8e8,stroke:#555,color:#111,font-weight:bold
    classDef block fill:#f5f5f5,stroke:#999,color:#333

    class SN,PORTAL presentation
    class API api
    class ORC,SOT,OBS block

Шаг 1: ServiceNow как поверхность прикладной команды

Прикладная команда заполняет форму ServiceNow: имя сервиса (app-payments), размер подсети (/24), корпус (building-b), запрашивающая команда и бизнес-обоснование. При отправке ServiceNow вызывает уровень API платформы напрямую как часть собственной автоматизации рабочего процесса. Уровень API проверяет полезную нагрузку относительно модели данных источника истины, аутентифицирует токен сервисной учётной записи, используемой ServiceNow, и пересылает структурированный запрос оркестратору.

Если валидация не проходит (например, запрошенный корпус не соответствует ни одному сайту в источнике истины или размер подсети конфликтует с существующим распределением), уровень API немедленно возвращает структурированную ошибку, до запуска какого-либо рабочего процесса оркестратора. ServiceNow обновляет тикет с чёткой причиной отказа: “building-c не найден в реестре сайтов” или “подсеть /24 конфликтует с существующим распределением 10.22.14.0/24 в building-b”. Прикладная команда видит отклонение в своём тикете и может исправить заявку без участия сетевого инженера. Никакого частичного состояния рабочего процесса не создаётся и никакого отката Saga не требуется, потому что рабочий процесс никогда не запускался.

По мере продвижения рабочего процесса уровень представления подписывается на события статуса оркестратора и переводит их в обновления тикетов ServiceNow: “Проверка источника истины завершена”, “Предварительные проверки выполняются: 24 коммутатора”, “Шлюз утверждения: ожидает подписи инженера”, “Завершено: 24/24 коммутатора настроены”. Прикладная команда наблюдает обновление своего тикета, не зная о существовании оркестратора, источника истины или AWX.

Шаг 2: Поверхность шлюза утверждения

Когда рабочий процесс достигает шлюза утверждения, оркестратор приостанавливается и генерирует событие. Уровень представления получает его, определяет сетевого инженера, ответственного за корпус B, и отправляет запрос на утверждение в его канал Slack с прямой ссылкой на страницу проверки шлюза. На странице проверки показаны результаты предварительных проверок по коммутаторам: какие прошли, какие не прошли, какие были пропущены и почему. Инженер утверждает или отклоняет с портала. Действие регистрируется: кто утвердил, через какой интерфейс, в какое время, под каким токеном.

Шаг 3: Представление аудита

Три месяца спустя аудитор безопасности запрашивает API уровня представления: “показать полную запись об изменении для VLAN app-payments, корпус B”. Конечная точка аудита только для чтения агрегирует три источника:

• Запись выполнения оркестратора (Глава 7, раздел 7.2.4): какая версия рабочего процесса выполнялась, входные и выходные данные каждого шага, любые компенсирующие действия Saga
• Запись об изменении в источнике истины (Глава 4): состояние до и после определения VLAN
• Собственный журнал авторизации уровня представления: кто отправил заявку, какой токен использовал, кто утвердил шлюз и когда

Ответ является структурированным документом, который аудитор может приложить к записи управления изменениями. Ни один из трёх базовых блоков не был разработан для самостоятельного создания этой составной записи. Уровень представления собрал её из их отдельных API под токеном аудитора только для чтения.

Что это демонстрирует

Тот же десятишаговый рабочий процесс из Главы 7 обслужил три разные аудитории через две поверхности представления без необходимости для любой из этих аудиторий понимать базовую платформу. ServiceNow обслуживал более широкую организацию: прикладная команда отслеживала свою заявку через инструмент, которым они уже пользуются каждый день, не зная об AWX, Nautobot или оркестраторе за ним. Специализированный портал обслуживал инженерную и комплаенс-аудитории: сетевой инженер проверил чистый интерфейс утверждения, ограниченный заявками их команды, а аудитор запросил составную запись об изменении, собранную из трёх блоков через единое представление только для чтения. Один уровень API, применяющий одну и ту же модель доступа для обеих поверхностей, сделал платформу доступной, не делая её видимой.

8.4. Итоги#

Presentation (Layer) уровень является последним строительным блоком Части 2, и именно он, скорее всего, будет считаться второстепенным. Блоки ниже него выполняют существенную работу: хранят намерение, применяют изменения, проверяют результаты, координируют рабочие процессы. Уровень представления ничего из этого не производит. Но без него платформа доступна только тем, кто её создал, а все остальные аудитории остаются зависимыми от человека-посредника.

Уровень API является основой. Аутентификация и авторизация, применяемые на границе API (а не в каждом инструменте) - это то, что отделяет доступную автоматизацию от опасной. Версионирование и стабильные контракты - это то, что отделяет платформу от прототипа, ломающего свои вызывающие стороны при каждом обновлении. Интерфейс Model Context Protocol (MCP) расширяет ту же модель доступа до агентов на основе Large Language Model (LLM), делая платформу доступной для паттернов агентной оркестрации, введённых в Главе 7 и развитых далее в Главе 17.

Клиентские интерфейсы - это разные форм-факторы одного базового API. GUI-портал с прогрессивным раскрытием обслуживает не-инженеров, которым нужно запрашивать и отслеживать автоматизацию, не понимая платформы. CLI обслуживает операторов, которым нужна скорость, возможность написания скриптов и интеграция с CI/CD. ChatOps и мобильные поверхности обслуживают потоки утверждения и запросы во время инцидентов. Решение о том, какие поверхности создавать, должно следовать обдуманной последовательности: начинать со встроенных UI блоков для инженерных аудиторий, интегрироваться с ITSM когда не-инженерам нужно запрашивать автоматизацию, создавать специализированный портал только когда ITSM оказывается недостаточным.

Интеграции и уведомления замыкают петлю, которую открыл контракт асинхронного ответа Главы 7. Оркестратор создаёт результат рабочего процесса; уровень представления доставляет его аудитории, запустившей действие, через канал, который они уже используют. Двунаправленная синхронизация ITSM, коллбэки вебхуков и push-уведомления - это не удобные функции. Это то, что делает автоматизацию видимой для людей, которые от неё зависят.

Кампусный сценарий показал это на практике: один рабочий процесс, три аудитории, две поверхности представления. ServiceNow обслуживал более широкую организацию как собственная поверхность представления, напрямую вызывая API платформы и отображая статус через знакомые обновления тикетов. Специализированный портал обслуживал инженерную и комплаенс-аудитории: сетевой инженер проверил чистый интерфейс утверждения, ограниченный заявками их команды, а аудитор запросил составную запись об изменении, собранную из оркестратора, источника истины и собственного журнала авторизации уровня представления. Один уровень API применял модель доступа для обоих. Платформа перестала быть невидимой.

Когда уровень представления на месте, Часть 2 охватила все семь строительных блоков фреймворка NAF. Следующая глава обращается к единственному блоку, на который вся эта автоматизация в конечном итоге воздействует: саму Сеть, рассматриваемую в Главе 9.

💬 Found something to improve? Send feedback for this chapter