Dec 10, 2025 · 5174 words · 25 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["Представление"]
    end
	space:1

    space:7

    
    block:Observability:2
        columns 2
        %% ObsLabel["Observabilit"]:2
        ObservedState[("Наблюдаемое состояние")]:1
        ObservedLogic["Логика наблюдения"]:1
    end

	space
    
	block:Orchestration:1
		columns 1
		OrchLabel["Оркестрация"]:1
	end

	space
    
    block:Intent:2
        columns 2
        %% IntLabel["Intent"]:2
        IntendedState[("Целевое состояние")]:1
        IntendedLogic["Целевая логика"]:1
    end
    
    space:7

	space

    
    Collector["Сборщик"]:2
	space
    Executor["Исполнитель"]:2
	space
    
	space:7
	space:1
    
    block:layer4:5
        NetworkInfra["Сетевая инфраструктура"]
    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

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

Term "Намерение" not found: Определяет логику обработки и уровень сохранения Desired State сети, включая как конфигурацию, так и операционные ожидания.
Term "Исполнитель" not found: Охватывает фактические задачи, применяемые к сети для внесения изменений (обновления конфигурации) в соответствии с намеченным состоянием.
Term "Сборщик" not found: В отличие от Term "исполнителя" not found, этот компонент фокусируется на получении (чтении) Actual State сети.
Term "Наблюдаемость" not found: Сохраняет Actual State сети и определяет логику его обработки.
Term "Оркестратор" not found: Определяет, как задачи автоматизации координируются и выполняются в ответ на события.
Term "Представление" not found: Предоставляет интерфейсы, через которые пользователи взаимодействуют с системой, включая информационные панели, графические интерфейсы (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[Понять текущее состояние]:::phase1 --> B[Планирование пути автоматизации]:::phase2
    B --> C[Принятие лучших решений об инструментах и проектировании]:::phase3
    C --> D[Проектирование для интеграции]:::phase4
    D --> E[Коммуникация с заинтересованными сторонами]:::phase5
    E --> F[Постепенная эволюция]:::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[Намерение / Источник истины] --> B[Исполнитель] --> C[Наблюдаемость] --> D[Оркестратор] --> E[Представление]
    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[Сборщик] --> B[Наблюдаемость] --> C[Намерение / Источник истины] --> D[Исполнитель] --> E[Оркестратор]
    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, кампусная команда может владеть инвентарём коммутаторов, а команда безопасности может владеть данными политики брандмауэра. Модель Role-Based Access Control (RBAC) в SoT должна отображаться на эти границы владения. Запись в неправильном домене — это операционный инцидент, ожидающий своего часа.

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

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

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

3.4. Резюме#

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

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

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

💬 Found something to improve? Send feedback for this chapter