Dec 10, 2025 · 4978 words · 24 min read

Примечание о переводе: Эта глава переведена с помощью ИИ на основе оригинала на английском языке. Мы стремимся к точности, однако некоторые нюансы могут отличаться от оригинала. Оригинал доступен на английском языке.

3. Архитектурное мышление#

В этой главе закладываются основы книги. Она объясняет, почему необходимо принять такой образ мышления, представляет эталонный фреймворк, предложенный Network Automation Forum (NAF), и показывает, как применять его в ваших проектах.

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

Но я твёрдо убеждён, что нужно понять ЗАЧЕМ, прежде чем ЧТО, поэтому сначала разберёмся в причинах использования архитектуры.

3.1. Почему важна эталонная архитектура#

“Свободны лишь образованные.” Эпиктет

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

Без чёткой эталонной архитектуры команды часто сталкиваются с предсказуемым набором проблем:

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

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

Что должен делать каждый компонент -> его обязанности
Как компоненты взаимодействуют -> их интерфейсы и потоки данных
Где можно делать выбор -> какие инструменты использовать
Где нужна согласованность -> как компоненты общаются друг с другом

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

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

3.2. Архитектура сетевой автоматизации#

Следовательно, нам нужна архитектура. Но обратите внимание на ‘A’ в названии раздела: существует не одна архитектура, а много. Архитектура — это просто эталонный фреймворк: способ структурирования мышления и направления согласованных решений. Я участвовал в трёх инициативах:

Эталонная архитектура Network to Code, коллективное усилие под руководством архитектурной команды NTC (в которой я участвовал четыре года), разработанное для поддержки эффективной и понятной сетевой автоматизации в широком диапазоне случаев использования.
Network Automation and Programmability 2nd Edition от O’Reilly, усилие по объединению всего содержимого книги с моими соавторами: Мэттом Освальтом, Скоттом С. Лоу и Джейсоном Эдельманом.
NAF Framework был общественным проектом под эгидой NAF, реализованным совместно с Вимом Хендериксом, Динешем Дуттом, Клавдией де Луна, Райаном Шоу и Дамьеном Гарро с целью помочь как новичкам, так и опытным практикам создавать решения по автоматизации структурированным, воспроизводимым способом.

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

Три подхода дополняют, а не конкурируют друг с другом. Краткое сравнение помогает прояснить, когда каждый наиболее актуален:

Архитектура	Основной фокус	Управление	Когда наиболее полезна
Эталонная архитектура NTC	Конкретный выбор инструментов и паттерны интеграции	Внутренняя для NTC, активно развивается	Команды, работающие с инструментами NTC, которым нужны предписывающие рекомендации по реализации
O’Reilly Ch14	Концептуальный фреймворк, связывающий темы программируемости	Опубликован, статичен	Читатели книги, желающие понять связь концепций автоматизации
NAF Framework	Стандарт взаимодействия с MUST/SHOULD/MAY для каждого модуля	Поддерживается сообществом, нейтральный к вендорам	Любая команда, желающая иметь общий ориентир для мульти-инструментных, мульти-вендорных сред

NAF Framework определяет контракты между блоками и оставляет выбор реализации открытым. Архитектура NTC заполняет эти выборы конкретными рекомендациями по инструментам. Если ваша команда использует инструменты NTC, оба подхода применяются одновременно без конфликтов.

NAF Framework предлагает следующую архитектуру:

block-beta
    columns 7
    
	space:1	
    block:layer1:5
        Presentation["Presentation"]
    end
	space:1

    space:7

    
    block:Observability:2
        columns 2
        %% ObsLabel["Observabilit"]:2
        ObservedState[("Observed State")]:1
        ObservedLogic["Observed Logic"]:1
    end

	space
    
	block:Orchestration:1
		columns 1
		OrchLabel["Orchestration"]:1
	end

	space
    
    block:Intent:2
        columns 2
        %% IntLabel["Intent"]:2
        IntendedState[("Intended State")]:1
        IntendedLogic["Intended Logic"]:1
    end
    
    space:7

	space

    
    Collector["Collector"]:2
	space
    Executor["Executor"]:2
	space
    
	space:7
	space:1
    
    block:layer4:5
        NetworkInfra["Network Infrastructure"]
    end
    
    Presentation <--> Observability
    Presentation <--> Orchestration
    Presentation <--> Intent
    
    Observability <--> Orchestration
    Orchestration <--> Intent
    
    Collector --> Observability
    Collector <--> Orchestration
	NetworkInfra --> Collector
    
    Orchestration --> Executor
    Intent --> Executor
    Executor --> NetworkInfra
    
    classDef darkStyle fill:#5a4149,stroke:#4a9eff,stroke-width:2px,color:#e8e8e8,font-size:20px,font-weight:bold
    
    class Presentation,NetworkInfra,ObsLabel,IntLabel,Collector,Executor,ObservedState,ObservedLogic,IntendedState,IntendedLogic,OrchLabel darkStyle

Эта архитектура содержит следующие блоки, используя определения из документа:

Intent (Architectural Block): Определяет логику обработки и уровень сохранения Desired State сети, включая как конфигурацию, так и операционные ожидания.
Executor: Охватывает фактические задачи, применяемые к сети для внесения изменений (обновления конфигурации) в соответствии с намеченным состоянием.
Collector: В отличие от Executor, этот компонент фокусируется на получении (чтении) Actual State сети.
Observability: Сохраняет Actual State сети и определяет логику его обработки.
Orchestrator: Определяет, как задачи автоматизации координируются и выполняются в ответ на события.
Presentation (Layer): Предоставляет интерфейсы, через которые пользователи взаимодействуют с системой, включая информационные панели, графические интерфейсы (ITSM) и инструменты Command Line Interface (CLI).

Эта архитектура не произвольна: она является естественным следствием применения принципов разработки программного обеспечения к сетевым операциям.

Фреймворк NAF призван помочь архитекторам сетевой автоматизации организовать свои решения, ссылаясь на функциональные возможности каждого модуля, и определяя MUST, SHOULD и MAY (в стиле RFC). Затем вы можете решить, как их реализовать для решения собственных задач.

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

Теперь мы рассмотрим различные блоки, чтобы представить их.

3.2.1. Намерение или Источник истины#

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

Архитектура называет это Намерением, но я сопоставляю его с другим популярным термином: Источник истины (SoT). Термин SoT иногда понимается неправильно, и я хочу начать с прояснения того, что такое SoT или Намерение (я буду использовать их как взаимозаменяемые на протяжении всей книги).

Как вы можете себе представить, это может охватывать самые разные данные: устройства, IP-адресацию, инфраструктуру датацентра (стойки, кабели), протоколы маршрутизации, виртуализированные сервисы, секреты, операционные ограничения, шаблоны конфигурации, а также абстракции сервисов и политик. Ключевым аспектом является то, что эти данные должны быть структурированы так, чтобы быть понятными машинам. Затем они должны поддерживать операции создания, чтения, обновления и удаления и быть доступны через стандартизированный, хорошо документированный Application Programming Interface (API), такой как Representational State Transfer (REST) или GraphQL.

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

В идеале этот компонент должен обеспечивать согласованное и унифицированное представление желаемого состояния, даже когда данные распределены по нескольким источникам данных. Эти источники данных, которые я называю Системами записей (SoR), являются фактическими владельцами данных. Таким образом, это одно из первых вещей, которое нужно прояснить: крайне редко бывает только один источник данных, но данные должны быть согласованными при консолидации. Управление данными — сложная тема, требующая функций управления данными, включая некоторые метаданные, такие как временные метки, происхождение данных, владение данными и периоды действия, для облегчения понимания этих данных и управления ими.

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

Если вы пытаетесь понять, какие реальные инструменты могут подойти для этой категории, вот несколько примеров: файлы CSV/YAML/JavaScript Object Notation (JSON), Git, NetBox, Nautobot, Infrahub, Infoblox или любые базы данных общего назначения.

Смотрите Главу 4 для глубокого погружения в создание и управление Источником истины.

3.2.2. Исполнитель#

Исполнитель отвечает за реализацию (запись) желаемого состояния из Намерения в фактическое состояние сети, взаимодействуя с сетью через различные интерфейсы, такие как SSH, NETCONF, gNMI/gNOI и REST API.

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

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

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

Аналогично Намерению, этот компонент должен предоставлять функции, такие как пробный запуск, транзакционные изменения и идемпотентность (через декларативные или императивные подходы), помогающие создавать системы автоматизации, на которые сетевые инженеры могут полагаться. Обычно именно этот компонент больше всего интересует сетевых инженеров (поначалу), поскольку именно он фактически “изменяет” сеть.

Инструменты, в основном подходящие для этой категории: Ansible, Terraform/OpenTofu, или любые скрипты, использующие библиотеки, такие как Netmiko, Scrapli или Napalm, или даже Kubernetes CRD (Custom Resource).

Перейдите к Главе 5 для изучения фреймворков выполнения, паттернов идемпотентности и стратегий реализации.

3.2.3. Сборщик#

Аналогично Исполнителю, Сборщик отвечает за получение фактических операционных данных из сети через различные интерфейсы и протоколы (те же интерфейсы, что и у Исполнителя, плюс другие, такие как SNMP, Syslog или другая телеметрия на основе потоков).

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

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

Примеры инструментов, подходящих для этой категории: Telegraf, Vector, gNMIc, PMACCT, goFlow, Akvorado или любые скрипты, использующие библиотеки для получения данных из сети.

Из-за тесной связи я рассмотрю Сборщик вместе со следующим строительным блоком, Наблюдаемостью, в Главе 6. Сборщик и Наблюдаемость архитектурно различны, но операционно неотделимы: каждое проектное решение о том, как собирать данные, определяется тем, что уровень Наблюдаемости должен обрабатывать. Рассмотрение их вместе сохраняет эту зависимость.

3.2.4. Наблюдаемость#

Тесно связанная со Сборщиком (во многих случаях рассматриваемая вместе с ним), Наблюдаемость принимает собранные данные, поддерживает их сохранение и предлагает программный доступ для поддержки расширенной аналитики, отчётности и рабочих процессов устранения неполадок, в идеале используя мощные языки запросов (такие как PromQL).

Данные из этого блока должны раскрывать значимые расхождения между Desired State и Actual State сети, генерируя события (или оповещения), которые могут запускать системы устранения.

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

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

В традиционном мониторинге сетей все функциональные возможности Наблюдаемости (и сбора данных) были интегрированы в одну большую коробку (такие инструменты, как Nagios, LibreNMS, Spectrum и т.д.).

В настоящее время всё большую популярность приобретают более разнообразные интегрированные системы: Prometheus и InfluxDB — популярные Time Series Database (TSDB), Elasticsearch и другие связанные системы для управления оповещениями (Alertmanager) и визуализации (Grafana, Kibana). Это привело к появлению нескольких популярных стеков: ELK, TIG или TPG.

Узнайте больше об архитектуре мониторинга, стратегиях оповещения и лучших практиках наблюдаемости в Главе 6.

3.2.5. Оркестратор#

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

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

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

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

Примеры: AAP или AWX (Ansible Automation Platform), Windmill или Prefect.

Место ИИ и агентов в архитектуре: Принятие решений с помощью ИИ находится преимущественно на пересечении блоков Оркестратора и Наблюдаемости. ИИ-агент следует циклу восприятие-логика-действие: он наблюдает состояние сети через блок Наблюдаемости, применяет рассуждение для определения необходимого действия и запускает Исполнитель через Оркестратор. Это отличается от традиционной роли Оркестратора (следование предопределённому рабочему процессу), но использует ту же инфраструктуру. Глава 7 (Оркестрация, раздел 7.2.7) рассматривает агентный подход как паттерн координации; Главы 15-17 исследуют его как основу для автономных сетей. Пока что думайте об агентной автоматизации как о подходе координации, который заменяет статические определения рабочих процессов динамическим принятием решений на основе модели.

Погрузитесь в Главу 7 для изучения дизайна рабочих процессов, событийно-управляемой автоматизации и платформ оркестрации.

3.2.6. Представление#

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

Традиционно для внешних пользователей это ограничивалось телефонными звонками или электронной почтой, а для сетевых команд — CLI.

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

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

Исследуйте пользовательский опыт, проектирование интерфейсов и паттерны интеграции в Главе 8.

3.2.7. Сеть#

И последнее, но не менее важное: нам нужно понять возможности сети для поддержки автоматизации, и сеть — это уже не просто устройства и кабели. В 2020-х годах виртуализация и облачные сетевые решения делают сквозную доступность (сеть) гибридной и разнообразной средой.

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

Возможности сети делятся на несколько категорий:

Интерфейсы и протоколы: Какие интерфейсы управления поддерживает ваша сеть? SSH CLI? NETCONF? gNMI? REST API? SNMP? Некоторые платформы поддерживают многое, некоторые — немного. Эти выборы напрямую ограничивают возможности Сборщика и Исполнителя.
Модели данных: Даже если устройство поддерживает gNMI, модели YANG, которые оно раскрывает, могут быть неполными. Например, ваше устройство может заявлять о поддержке gNMI, но не раскрывать конкретную конфигурацию, которой вам нужно управлять. Понимание этих пробелов критически важно при планировании.
Операционная зрелость: Более новые платформы могут иметь современные API, но недокументированное поведение. Более старые платформы могут быть стабильными, но полностью лишёнными API. Вам необходимо оценивать реальную зрелость, а не только маркетинговые характеристики.

Для эффективной поддержки автоматизации ваша сетевая инфраструктура в идеале должна предоставлять:

Среды разработки и тестирования: Как и разработка программного обеспечения, автоматизация требует безопасных мест для тестирования. Это может означать: лабораторные сети (часто дорогие и ограниченные), виртуальные сетевые среды (Containerlab, GNS3) или симуляторы вендоров (Cisco DevNet, Arista EOS-lite).
Согласованные интерфейсы: Если 90% ваших устройств поддерживают NETCONF, а 10% — только SSH, вам нужно либо стандартизировать, либо создать несколько Исполнителей. Каждое несоответствие увеличивает сложность.
Достаточная телеметрия: Если вы не можете получить нужные данные от своих устройств, Наблюдаемость становится бессмысленной. Убедитесь, что ваши устройства могут передавать телеметрию (потоковую телеметрию, SNMP, syslog) с необходимой гранулярностью и информацией.

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

Понимайте возможности сети, API устройств и тестовые среды в Главе 9.

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

3.2.8. Практический пример#

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

Проблема: Команда приложений подала запрос на новый сегмент приложения: новый VLAN, IP-подсеть, политику маршрутизации и зону контроля доступа в гетерогенной кампусной сети, работающей примерно на 800 коммутаторах доступа и распределения от Cisco, Arista и HPE. Команда операций должна выполнить это полностью без ручной работы через CLI на сотнях устройств.

Как архитектура может решить это:

Намерение (Источник истины): Сетевой инженер вводит новое определение сервиса в Nautobot: ID VLAN, подсеть, политику маршрутизации, шаблоны конфигурации для каждого вендора и группы коммутаторов, к которым это применяется. Это хранится как Desired State, единственное место истины для 800 устройств.
Orchestrator: AWX получает вебхук от Nautobot об изменении и запускает рабочий процесс выполнения, координируя шаги в правильном порядке и обрабатывая сбои для каждого устройства.
Executor: Плейбук Ansible читает из Application Programming Interface (API) Nautobot, генерирует конфигурацию для каждого устройства по вендору (Cisco, Arista и HPE требуют разного синтаксиса) и применяет изменения через NETCONF. Каждый запуск идемпотентен: повторное выполнение на уже настроенных коммутаторах не даёт изменений.
Collector: После развёртывания коллектор gNMIc подключается к каждому коммутатору и получает фактическое членство в VLAN, состояние интерфейса и записи маршрутизации.
Observability: Собранные данные поступают в Time Series Database (TSDB) Prometheus. Запрос сравнивает Desired State (из Намерения) с Actual State (от Collector). Коммутаторы, на которых отсутствует VLAN, раскрываются как метрики и вызывают оповещения.
Orchestrator: Когда срабатывает оповещение (“VLAN 210 отсутствует на access-switch-b3-07”), рабочий процесс AWX автоматически повторно запускает Executor на этом коммутаторе, повторно собирает данные и проверяет исправление.
Presentation (Layer): Информационная панель показывает все 800 коммутаторов, сгруппированных по зданию и вендору, выделяя соответствующие (✅) и отклонившиеся (❌). Команда приложений может отслеживать развёртывание без доступа к CLI. ИТ-операции могут запускать ручные исправления без написания кода.
Сеть: Успех этого процесса зависит от того, что фактически поддерживают устройства. На Cisco и Arista NETCONF работает чисто. Несколько коммутаторов HPE поддерживают только SSH CLI, поэтому для них предусмотрен отдельный путь Исполнителя — менее элегантный, но необходимый. Никакая архитектура не устраняет ограничения вендоров: она лишь делает их явными.

Ключевой вывод: Ни один инструмент не справился с этим в одиночку. Nautobot (Намерение), Ansible (Исполнитель), gNMIc (Сборщик), Prometheus (Наблюдаемость), AWX (Оркестратор) и панель Grafana (Представление) работали вместе. Архитектура предоставила ментальную модель для их интеграции.

Это то, что обеспечивает архитектурное мышление: систематическую, компонуемую автоматизацию.

На протяжении Части 2 (Главы 4-9) мы возвращаемся к этой же кампусной сети для глубокого изучения каждого строительного блока: SoT хранит определение сервиса VLAN (Глава 4), Исполнитель развёртывает его (Глава 5), Наблюдаемость отслеживает его (Глава 6), Оркестратор координирует полный жизненный цикл (Глава 7), уровень Представления раскрывает его различным аудиториям (Глава 8), и глава Сеть завершается предпроизводственным шлюзом на основе симуляции (Глава 9). Там, где примеры ссылаются на инструмент Источника истины, Nautobot и NetBox используются взаимозаменяемо; архитектурные паттерны одинаковы независимо от вашего выбора.

3.3. Как использовать архитектуру#

Теперь, когда вы понимаете различные строительные блоки архитектуры сетевой автоматизации NAF, вы можете задаться вопросом: “Как мне фактически начать с этим в своих проектах?”

3.3.1. Последовательный подход к внедрению#

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

flowchart LR
    A[Understand Your Current State]:::phase1 --> B[Plan Your Automation Journey]:::phase2
    B --> C[Make Better Tool & Design Decisions]:::phase3
    C --> D[Design for Integration]:::phase4
    D --> E[Communicate with Stakeholders]:::phase5
    E --> F[Evolve Incrementally]:::phase6

    classDef phase1 fill:#e0f7fa,stroke:#333,stroke-width:2px;
    classDef phase2 fill:#b2ebf2,stroke:#333,stroke-width:2px;
    classDef phase3 fill:#80deea,stroke:#333,stroke-width:2px;
    classDef phase4 fill:#4dd0e1,stroke:#333,stroke-width:2px;
    classDef phase5 fill:#26c6da,stroke:#333,stroke-width:2px;
    classDef phase6 fill:#00bcd4,stroke:#333,stroke-width:2px;

Фаза 1: Понять текущее состояние

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

Ваши данные разбросаны по нескольким системам?
Вы эффективно собираете состояние сети, или летите вслепую?
Как вы в настоящее время выполняете изменения? Вручную? Ситуативными скриптами? Организованными фреймворками?

Если вы обнаружите отличные возможности выполнения, но слабую наблюдаемость, вы выявили высокоприоритетную проблему для следующего решения.

Фаза 2: Планирование пути автоматизации

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

Если вы боретесь с дрейфом конфигурации, сосредоточьтесь на Намерении/Источнике истины и Выполнении.
Если вы не можете быстро обнаруживать проблемы, отдайте приоритет Сборщику и Наблюдаемости.
Если ваша автоматизация фрагментирована и ненадёжна, инвестируйте в Оркестрацию.
Если пользователи не понимают, как запрашивать изменения, улучшите Представление.

Расставляйте приоритеты по бизнес-воздействию, а не по архитектурной полноте.

Фаза 3: Принятие лучших решений об инструментах и проектировании

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

Какому архитектурному блоку это служит?
Хорошо ли интегрируется с другими компонентами?
Какие потоки данных между блоками мне нужны?

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

Фаза 4: Проектирование для интеграции

Понимание границ между компонентами помогает проектировать лучшие интерфейсы. Ключевой принцип: компоненты не должны знать внутреннее устройство друг друга.

Вашему Исполнителю не нужно знать, как Намерение хранит данные: ему просто нужен хорошо определённый API для запроса желаемого состояния.
Вашему Оркестратору не должно быть важно, используете ли вы Ansible или Terraform: он просто запускает выполнение и отслеживает результаты.
Вашей системе Наблюдаемости не нужно знать о внутреннем устройстве Сборщика: ей просто нужны чёткие метрики и события.

Эта развязка позволяет независимо развивать каждый компонент.

Фаза 5: Коммуникация с заинтересованными сторонами

Архитектура предоставляет общий язык для обсуждения автоматизации с различными аудиториями:

Руководству: “Мы укрепляем нашу позицию по Наблюдаемости для снижения MTTR.”
Своей команде: “Стандартизируем, как наш Сборщик отправляет данные в Наблюдаемость.”
Другим отделам: “Наш уровень Представления будет интегрироваться с вашим экземпляром ITSM.”

Чёткий архитектурный язык уменьшает путаницу и помогает получить поддержку.

Фаза 6: Постепенная эволюция

Архитектура позволяет заменять компоненты по мере изменения ваших потребностей:

Сегодня вы можете использовать Git как Источник истины, но завтра перейти на NetBox или Infrahub без полного перепроектирования рабочих процессов автоматизации, при условии сохранения чётких интерфейсов.
Вы можете начать с простого скрипта как Оркестратора, позже заменив его на AAP или Windmill.
Вы можете перейти с одной TSDB на другую в Наблюдаемости, не нарушая работу Сборщика.

Этот эволюционный подход минимизирует риски и позволяет учиться по ходу.

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

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

3.3.2. Распространённые ловушки, которых следует избегать#

Будем честны: вы будете делать ошибки. Но обучение на опыте других может сэкономить вам много боли. Вот распространённые ловушки:

Попытка реализовать всё сразу
Может возникнуть соблазн думать: “Если эта архитектура хороша, мне нужно идеально построить все семь блоков.” Это ведёт к масштабным, многолетним проектам, которые устаревают до своего завершения.
Лучший подход: Начните с одного или двух блоков, решающих вашу самую насущную проблему. Строите постепенно. Ранний успех создаёт импульс и поддержку.
Вера в “один инструмент для всего”
Некоторые вендоры заявляют, что их платформа делает всё. Хотя это может быть правдой, это часто означает:
- Вы привязаны к их способу делать вещи
- Вы не можете заменить компоненты позже
- Вы платите за функции, которые вам не нужны
Лучший подход: Выбирайте лучшие в своём классе инструменты для каждого блока, но убедитесь, что у них есть чёткие API и точки интеграции. Примите, что вам может потребоваться интегрировать 3-5 инструментов, но у вас будет гибкость.
Игнорирование сетевых ограничений
Вы проектируете красивый Исполнитель с использованием gNMI, но 30% ваших устройств поддерживают только SSH CLI. Или вы хотите потоковую телеметрию, но более старые платформы поддерживают только SNMP.
Лучший подход: Сначала разберитесь в возможностях вашей сетевой инфраструктуры. Эти ограничения формируют вашу архитектуру. Нельзя игнорировать физику, и нельзя игнорировать то, что ваши устройства реально умеют.
Предположение, что интерфейсы будут простыми
Вы говорите: “Исполнитель просто вызовет API Намерения для желаемого состояния.” Но Намерение использует NetBox с пользовательскими расширениями, а Исполнитель ожидает плоский YAML. Внезапно вы пишете уровни трансляции.
Лучший подход: Инвестируйте заблаговременно в чёткие, хорошо документированные интерфейсы. Используйте стандарты там, где это возможно (REST API, gRPC, чёткие определения схем). Хорошие интерфейсы обходятся дешевле сейчас, чем уровни трансляции — потом.
Создание пользовательских инструментов, когда хорошие уже существуют
Ваша команда решает создать пользовательский Сборщик, потому что “ни один инструмент точно не соответствует нашим потребностям”. Через шесть месяцев у вас 3 000 строк кода, поддерживающего собственные конвейеры телеметрии.
Лучший подход: Сначала оцените существующие инструменты (Telegraf, Vector, gNMIc). Они покрывают 80% случаев использования и проверены в бою. Настраивайте их или создавайте адаптеры при необходимости, но не строите с нуля.
Отношение к Наблюдаемости как к запоздалой мысли
Многие команды фокусируются на Намерении и Исполнителе, затем слишком поздно понимают, что не могут видеть, что фактически происходит в сети. Наблюдаемость добавляется в последний момент.
Лучший подход: Планируйте Наблюдаемость с первого дня. Какие метрики будете собирать? Как обнаруживать дрейф? Какие оповещения важны? Ответьте на эти вопросы до создания Исполнителя.
Забывание о пользователях
Инженеры создают мощный Оркестратор, но единственный способ взаимодействия пользователей с ним — команды CLI. Нетехнические пользователи запутываются; внедрение идёт плохо.
Лучший подход: Думайте о своих пользователях с самого начала. Какие интерфейсы им нужны? API? Веб-интерфейс? Интеграция с ServiceNow? Иногда уровень Представления определяет успех или провал внедрения.

Эти ловушки не теоретические — они паттерны из реальных проектов по автоматизации. Обучение на них сейчас сделает вашу архитектуру сильнее.

3.3.3. С чего начать#

Архитектура определяет семь блоков. Никто не реализует все семь одновременно. На практике два начальных паттерна охватывают большинство реальных развёртываний.

Паттерн А: Начало на основе конфигурации (наиболее распространённый)

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

flowchart LR
    A[Intent / SoT] --> B[Executor] --> C[Observability] --> D[Orchestrator] --> E[Presentation]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

Паттерн Б: Начало на основе видимости

Команды, чья главная боль — незнание текущего состояния сети. Начните со Сборщика и Наблюдаемости: сначала создайте конвейер данных, поймите, что фактически развёрнуто, затем добавьте Намерение и Исполнитель, когда у вас будет надёжная картина для развёртывания.

flowchart LR
    A[Collector] --> B[Observability] --> C[Intent / SoT] --> D[Executor] --> E[Orchestrator]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

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

Это отправные точки, а не чертежи. Ваши ограничения (существующий инструментарий, навыки команды, наиболее насущная боль) должны определять порядок. Ключевое — сознательно выбрать отправную точку, а не пытаться строить всё параллельно и не завершить ничего.

3.3.4. Владение блоками между командами#

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

Наиболее распространённая модель в средних и крупных организациях делится на две группы. Платформенная команда владеет самой инфраструктурой автоматизации: схемой SoT и API, средой выполнения Оркестратора, конвейером Наблюдаемости, уровнем Представления и общей инфраструктурой Сборщика. Это компоненты, от которых зависит остальная организация. Работа платформенной команды — поддерживать их надёжными, версионированными и доступными. Команда сетевых операций (или несколько доменных команд, по одной на технологическую область) владеет содержимым автоматизации: плейбуками, определениями рабочих процессов, намеченными данными и бизнес-логикой, работающей поверх платформы. Они потребляют платформу, а не обслуживают её.

Это разделение имеет последствия для того, как границы блоков переходят в границы команд. SoT — общий ресурс платформы, но разные команды имеют разные права на запись в него: команда IP-адресации может владеть данными IPAM; кампусная команда может владеть инвентарём коммутаторов; команда безопасности может владеть данными политики брандмауэра. Модель Term "rbac" not found SoT должна отображаться на эти границы владения. Запись в неправильном домене — это операционный инцидент, ожидающий своего часа.

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

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

Организационное измерение управления платформой автоматизации, включая то, как команды структурируются вокруг неё, как продуктовое мышление применяется к внутреннему инструментарию и как платформенные команды управляют контрактом с внутренними потребителями, подробно рассматривается в Главе 10 (Платформенная инженерия) и Главе 13 (Культурный сдвиг). Архитектурные выборы, сделанные здесь — особенно область RBAC SoT и владение рабочими процессами Оркестратора — непосредственно ограничивают организационные модели, описываемые в этих главах.

3.4. Резюме#

Архитектурное мышление необходимо для создания сетевой автоматизации, которая действительно работает. Так же, как модель OSI даёт нам послойный фреймворк для понимания сетей, эталонная архитектура помогает организовать и спроектировать системы автоматизации, которые обслуживаемы, масштабируемы и надёжны.

В этой главе был представлен NAF Framework, определяющий семь ключевых строительных блоков. Архитектура — не жёсткое предписание, а гибкий фреймворк. Используйте его для оценки текущего состояния, планирования пути автоматизации, принятия обоснованных решений об инструментах, коммуникации с заинтересованными сторонами, проектирования для интеграции и постепенной эволюции. Помните: цель — практическая автоматизация, решающая реальные проблемы, а не архитектурная чистота.

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

💬 Found something to improve? Send feedback for this chapter