2. Принципы проектирования#

Команда сетевой автоматизации провела целых шесть месяцев, создавая систему, которой они действительно гордились. Она извлекала намерение из структурированной модели данных, генерировала конфигурации устройств через шаблонизатор, проверяла изменения по библиотеке политик и применяла их через NETCONF с полной поддержкой отката. Согласно архитектуре это было прочно. Демонстрация руководству прошла хорошо. Затем они передали её команде сетевых операций.

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

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

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

2.1 Формирование доверия#

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

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

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

Актуальность этой темы продиктована презентацией Damien Garros Building Trustworthy Network Automation на конференции Autocon3.

Для простоты выделим четыре базовые характеристики, которые нам необходимы:

• Term "Предсказуемость" not found: Согласованные, детерминированные результаты. Инженеры должны чётко знать, что произойдёт до нажатия кнопки запуска, и получать одинаковое поведение системы каждый раз.
• Term "Надёжность" not found: Корректная обработка ошибок и восстановление после сбоев. Обеспечение безопасного завершения операций (или отката) даже в неожиданных условиях и при масштабировании.
• Term "Удобство" not found: Интерфейсы, позволяющие инженерам проверять, анализировать и контролировать поведение системы без излишней сложности и с чёткими защитными ограничителями.
• Term "Понятность" not found: Система не должна быть “чёрным ящиком”. Ей необходимо раскрывать свои намерения, шаги, результаты и логику принятия решений таким образом, чтобы это формировало уверенность у людей.

graph BT
  %% ===== Middle Layer =====
  subgraph L2[**Качества**]
    direction LR
    B1[Предсказуемость]:::layer2
    B2[Надёжность]:::layer2
    B3[Удобство]:::layer2
    B4[Понятность]:::layer2
  end

  %% ===== Top Layer =====
  subgraph L1[" "]
    direction TB
    A[Доверие]:::layer1
  end

  %% ===== Connections: Behavior → Outcome =====
  B1 --> A
  B2 --> A
  B3 --> A
  B4 --> A

  %% ===== Styling =====
  classDef layer1 fill:#ffcccc,stroke:#b8860b,stroke-width:2px,color:#000;
  classDef layer2 fill:#ffe6cc,stroke:#4682b4,stroke-width:1.5px,color:#000;

Предсказуемость и детерминированное поведение становятся всё более актуальными по мере того, как технологии ИИ/МО проникают в область автоматизации сетей, привнося с собой элемент случайности.

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

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

Итак, с учётом этих характеристик, исследуем поддерживающие их принципы.

2.2 Принципы проектирования#

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

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

• Term "Идемпотентность" not found: Многократное выполнение одной и той же операции приводит к одному и тому же конечному состоянию. Этот принцип снижает побочные эффекты, устраняет неоднозначность, делает автоматизацию более понятной и безопасной для повторного запуска.
• Term "Транзакционность" not found: Изменения либо применяются полностью, либо не применяются вовсе (безопасный отказ). Исключаются любые частичные, несогласованных или “наполовину внедрённые” состояния. Это критически важно для предсказуемости сети и обеспечения возможности отката в масштабах всей инфраструктуры.
• Term "Управление_на_основе_намерений" not found: Система определяет желаемое конечное состояние, а не пошаговый алгоритм его достижения. Такой подход повышает предсказуемость, снижает когнитивную нагрузку на инженеров и делает систему более удобной в использовании.
• Дружественность к Term "Режим_симуляции" not found: Возможность увидеть, какие именно изменения будут внесены, до того, как они будут применены на реальном оборудовании. Повышает уровень доверия к автоматизации, позволяя инженерам проверять действия, визуализировать результаты и обнаруживать проблемы до того, как они затронут действующую сеть.
• Term "Версионирование" not found: Поддержка версионирования как данных, так и логики. Перемещение назад или вперёд во времени, восстановление предыдущих состояний, поддержание нескольких состояний параллельно. Усиливает предсказуемость и укрепляет надёжность.
• Тестируемость: Надлежащая тестовая среда необходима перед выполнением изменений в производстве. Улучшает надёжность и помогает инженерам понять поведение системы.

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

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

graph BT
  %% ===== Bottom Layer =====
  subgraph L3[**Принципы**]
    direction LR
    C1[Идемпотентность]:::layer3
    C2[Версионность]:::layer3
    C3[Транзакционность]:::layer3
    C4[Тестируемость]:::layer3
    C5[Режим симуляции]:::layer3
    C6[Управление на основе намерений]:::layer3
  end

  %% ===== Middle Layer =====
  subgraph L2[**Качества**]
    direction LR
    B1[Предсказуемость]:::layer2
    B2[Надёжность]:::layer2
    B3[Удобство]:::layer2
    B4[Понятность]:::layer2
  end

  %% ===== Top Layer =====
  subgraph L1[" "]
    direction TB
    A[Доверие]:::layer1
  end

  %% ===== Connections: Foundation → Behavior =====
  C1 --> B1
  C1 --> B4

  C2 --> B3
  C2 --> B2

  C3 --> B1
  C3 --> B2

  C4 --> B2
  C4 --> B4

  C5 --> B3
  C5 --> B4

  C6 --> B1
  C6 --> B3

  %% ===== Connections: Behavior → Outcome =====
  B1 --> A
  B2 --> A
  B3 --> A
  B4 --> A

  %% ===== Styling =====
  classDef layer1 fill:#ffcccc,stroke:#b8860b,stroke-width:2px,color:#000;
  classDef layer2 fill:#ffe6cc,stroke:#4682b4,stroke-width:1.5px,color:#000;
  classDef layer3 fill:#ccffcc,stroke:#228b22,stroke-width:1.5px,color:#000;

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

2.2.1. Управление намерением#

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

Распространённый вариант использования для начала автоматизации: скрипты или плейбуки, выполняющие простые действия. Поднять или опустить интерфейс, указав FQDN и имя интерфейса. Но это создаёт проблему. Каждый следующий человек, работающий с этим интерфейсом, не будет знать, каково его Desired State. Должен ли он быть поднят или опущен?

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

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

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

Таким образом, качество ваших данных Term "управления на основе намерений" not found напрямую определяет качество вашей автоматизации. Эта концепция тесно связана с Source of Truth (SoT) (SoT), который мы подробно рассмотрим в Главе 4.

Инфраструктура как код (IaC): Автоматизация на основе намерений является фундаментом Infrastructure as Code (IaC) - подхода, при котором к определениям сетевой инфраструктуры относятся как к программному коду. С IaC вы получаете управление версиями, процессы code review, тестирование и возможность относиться к изменениям инфраструктуры так же, как к изменениям программного обеспечения. Это связывает сетевую автоматизацию с лучшими практиками разработки ПО. IaC хранит шаблоны, инвентарь и намерение в виде файлов под управлением систем версионирования. Все изменения проверяются, тестируются и отслеживаются, а не применяются как разовые правки в CLI.

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

2.2.2. Идемпотентность#

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

Term "Идемпотентность" not found означает, что запуск одной и той же операции несколько раз приводит к одному и тому же конечному состоянию системы без непреднамеренных побочных эффектов.

Например, при автоматизированной настройке ACL, если мы определяем правило, мы ожидаем:

• Если правило не существует: оно добавляется на определённую позицию.
• Если правило уже существует: дубликаты не добавляются.
• Если позже добавляется другое правило: предыдущее остаётся нетронутым и не перемещается.

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

• Каково текущее состояние ACL?
• Является ли правило уже его частью?
• Если нет, какое различие нужно применить?

Без идемпотентности конфигурация может применяться в непредсказуемом порядке, влияя на воспроизводимость.

Идемпотентность применима часто применима к различным измерениям сетевой автоматизации. Например, при запросе IP-адреса через DHCP или из системы IPAM, понимающей соответствие между идентификатором запроса и результатом:

Рисунок 1: Пример идемпотентности (из доклада Damien Garros на Autocon3)

Как вы узнаете позже, для достижения идемпотентности предпочтительнее использовать Term "декларативные" not found модели вместо Term "императивных" not found. Определяйте конечное состояние, а не шаги. Это не означает, что использование императивного режима невозможно, но это сложнее.

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

2.2.3. Транзакционность#

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

Term "Транзакционность" not found — базовая концепция в базах данных, где несколько изменений применяются атомарно для поддержания согласованности. В сетях (распределённых системах) реализовать её ещё сложнее, хотя сама проблема не нова. В 2006 году NETCONF (RFC 6241) ввёл понятие общесетевого коммита. Он применяет изменения глобально на нескольких устройствах или полностью откатывает их при сбое валидации. Такая Term "атомарная_операция" not found предотвращает частичные состояния, когда одни устройства обновились, а другие — нет: один из самых кошмарных сценариев для инженеров при устранении неполадок. Однако не все платформы поддерживают NETCONF, и сложность интеграции существенно варьируется. Поэтому, хотя проблема теоретически решена, практическая реализация целиком зависит от вашей инфраструктуры.

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

Итак, в целом, как мы можем применять транзакционность к сетям? Это совокупность техник:

• NETCONF: Возможности управления сетью, поддерживающие распределённую координацию управления. Но поддержка очень ограничена.
• Транзакции на основе базы данных: Хранение изменений конфигурации в базе данных со свойствами ACID, затем их применение скоординированными пакетами с возможностью Rollback
• Очереди уведомлений об изменениях: Перехват всех предполагаемых изменений, их групповая валидация и последующее выполнение со скоординированным механизмом Rollback при сбое на любом из устройств
• Паттерны двухфазного коммита: Сначала подготовка изменений на всех устройствах (фаза 1), затем их одновременная фиксация (фаза 2) с Rollback, если при на втором этапе возник сбой хотя бы на одном устройстве
• Транзакционные журналы: Запись каждой попытки изменения с детализацией, достаточной для ручной или автоматической отмены частичных операций

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

Этот принцип естественным образом связан с Term "версионированием" not found: когда что-то идёт не так, вам нужно точно знать, в каком состоянии вы находитесь, чтобы откатиться к известной рабочей версии.

2.2.4. Версионирование#

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

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

В разработке программного обеспечения Version Control System (VCS), такие как Git, являются стандартной практикой (я не работал ни в одной среде без какой-либо формы VCS). Эти системы обеспечивают:

• Лёгкое сотрудничество: Несколько разработчиков вносят код и могут двигаться вперёд по разным веткам
• Путешествие во времени: Возврат к предыдущим точкам в истории, чтобы понять, что и когда изменилось
• Атомарная группировка: Несколько изменений файлов могут быть объединены в единое целое

Применение Term "версионирования" not found к сетевой автоматизации даёт значительные преимущества:

• Возможность аудита и отслеживания: Легко отслеживать, кто, что и когда изменил, делая систему прозрачной
• Сотрудничество между командами: Облегчает проверку изменений и обеспечивает командную разработку автоматизации
• Term "Атомарные_операции" not found: Связанные изменения в нескольких файлах могут применяться вместе, предотвращая частичные или неполные состояния
• Интеграция с CI/CD: Автоматизированные пайплайны могут запускать тестирование и валидацию при обнаружении изменений кода

Шаблоны конфигураций являются ярким примером данных, выигрывающих от версионирования. Одно изменение шаблона влияет на все производные конфигурации по всей сети, поэтому управление версиями в этом случае становится необходимым. В целом все данные должны храниться с поддержкой версий. Распространено хранение версионированных файлов YAML или JavaScript Object Notation (JSON), моделирующих данные любого типа, или данных с более сложными связями.

GitOps: Развивающийся паттерн, выводящий версионирование на новый уровень: репозиторий Git становится единым источником истины, а контроллер непрерывно сравнивает Desired State в Git с Actual State в сети, автоматически исправляя дрейф. Всё больше набирает популярность в сетевой автоматизации, особенно в облачно-нативных средах и средах с интеграцией Kubernetes.

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

2.2.5. Тестируемость#

Почему важна тестируемость: Автоматизация в масштабе всегда усиливает ошибки. Ошибка в плейбуке, затронувший одно устройство, локален и управляем. Но та же ошибка, применённая к 10 000 устройств, — это катастрофа. Тестирование — ваша страховка перед развёртыванием в производство.

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

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

В качестве удобного фреймворка здесь выступает пирамида тестирования:

graph BT
  %% Модульные тесты (base)
  U1["Модульные тесты<br/>(Качество данных, Логика)"]:::unit

  %% Интеграционные тесты
  I1["Интеграционные тесты<br/>(Симулированная среда)"]:::integration

  %% Сквозные тесты (top)
  E1["Сквозные тесты<br/>(Лаборатория, Валидация)"]:::enduser

  %% Links
  U1 --> I1
  I1 --> E1

  %% Styling
  classDef unit fill:#a6e3a1,stroke:#3b7a57,stroke-width:2px,color:#000;
  classDef integration fill:#89b4fa,stroke:#1e3a8a,stroke-width:2px,color:#000;
  classDef enduser fill:#f9e2af,stroke:#b8860b,stroke-width:2px,color:#000;

• Term "Модульное_тестирование" not found изолированно проверяют качество данных, базовую логику и специфическое поведение с использованием заглушек или фиктивных систем. Выполняются быстро и на раннем этапе помогают выявлявить фундаментальные ошибки.
• Term "Интеграционные_тесты" not found вводят сторонние системы в уже смоделированную (и упрощённую) среду. На раннем этапе различные компоненты автоматизации взаимодействуют друг с другом и имитируемыми вариантами сети, позволяя проверять точки интеграции (например, имитация Term "API" not found или Term "SSH" not found Term "CLI" not found интерфейса сетевого устройства).
• Term "Сквозные_тесты" not found проверяют поведение в максимально близких к реальным сценариях с использованием виртуализированных сетевых сред или лабораторий, имитирующих часть вашей производственной сети (мы более подробно рассмотрим эту тему в Главе 9).

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

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

Расширенные стратегии тестирования:

• Хаос-инжиниринг: Намеренное внедрение сбоев (отключение устройств, задержки сети) для проверки того, что ваша автоматизация и мониторинг обрабатывают их корректно (Netflix популяризировал этот подход с их Chaos Monkey).
• Тестирование на основе свойств: Определите свойства, которые всегда должны оставаться истинными (например, “BGP всегда должен сходиться в течение 30 секунд”), и пусть тестовые фреймворки генерируют сценарии для их проверки

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

2.2.6. Дружественность к пробному запуску#

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

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

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

Существуют инструменты, предоставляющие возможность Term "пробного,запуска" not found, но вы всегда можете создать свой, если это необходимо:

• Ansible: Флаги --check и --diff показывают, что было бы изменено
• Terraform: Команда terraform plan отображает разницу между текущим и Desired State
• Пользовательские сетевые API: Некоторые могут предоставлять режим “пробного запуска” или предварительного просмотра

Вот пример того, как выглядит эта видимость:

Вывод Ansible Diff

- description: Uplink to CoreSwitch1
+ description: Uplink to CoreSwitch2
  mtu: 9216

Вывод Terraform Plan

~ description = "Uplink to CoreSwitch1" -> "Uplink to CoreSwitch2"
  mtu          = 9216

Предварительный ответ пользовательского сетевого API

{
  "operation": "PATCH",
  "path": "/interfaces/Gi0-1",
  "changes": [
    {
      "field": "description",
      "current_value": "Uplink to CoreSwitch1",
      "proposed_value": "Uplink to CoreSwitch2",
    }
  ],
  "mtu": 9216
}

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

Расширенные концепции пробного запуска:

• Анализ воздействия: Помимо показа изменений, анализировать и сообщать о бизнес-воздействии (например, “Это временно затронет 10% трафика”)
• Поэтапные развёртывания: Реализовать пробный запуск в масштабе, постепенно развёртывая изменения на ограниченном подмножестве устройств изначально, проверяя воздействие перед полным его развёртыванием
• Симуляция сети: Комбинировать с инструментами тестирования сети для выполнения пробных запусков на реплике вашей производственной сети

2.3. Паттерны архитектурных решений#

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

2.3.1. Декларативный vs. Императивный#

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

• Term "Декларативный" not found автоматизация определяет желаемое конечное состояние, а система сама решает, как его достичь. Пример: “Я хочу, чтобы интерфейс Gi0/1 имел MTU 9000.” Движок автоматизации определяет текущее состояние и применяет только необходимые изменения. Этот подход фокусируется на желаемых результатах, отвечая на вопрос “ЧТО”.
• Term "Императивный" not found автоматизация задаёт точные шаги для выполнения. Пример: “Показать конфигурацию интерфейса, разобрать её, вычислить разницу и отправить точные CLI-команды в строгом порядке.” Этот подход фокусируется на конкретных действиях, отвечая на вопрос “КАК”.

Декларативные подходы естественно поддерживают Term "идемпотентность" not found, возможности Term "пробного_запуска" not found и Term "транзакционное" not found поведение, но требуют инфраструктуры и систем, способных это обеспечить.

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

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

Большинство современных фреймворков по автоматизации (Terraform, Ansible, Kubernetes или инструменты на основе Term "YANG" not found) стремятся больше к Term "декларативным" not found моделям, но при необходимости допуская Term "императивные" not found запасные варианты (например, модули raw в Ansible, прямой Term "CLI" not found, Netmiko).

Некоторые инструменты, такие как Ansible, могут функционировать обоими способами в зависимости от типа модуля. Сетевые модули (такие как cisco.ios.ios_interfaces) являются декларативными, тогда как ansible.netcommon.cli_command выполняет императивные команды. В приведённом ниже примере вы увидите оба подхода:

- name: Imperative vs. Declarative Approaches in Ansible
  hosts: switches
  gather_facts: no
  vars:
    interface_name: GigabitEthernet0/1
    new_description: Uplink to CoreSwitch2
  tasks:
    - name: Imperative - Execute exact commands
      ansible.netcommon.cli_command:
        command: |
          configure terminal
          interface {{ interface_name }}
          description {{ new_description }}
          no shutdown
          end
      # Repeating this task may add duplicates and fails idempotency

    - name: Declarative - Define desired state
      cisco.ios.ios_interfaces:
        config:
          - name: "{{ interface_name }}"
            description: "{{ new_description }}"
            enabled: true
        state: merged
      # Repeating this task is safe, it converges to the desired state

Имейте в виду, что при декларативном подходе вы перекладываете логику выполнения на внешнюю систему, но в некоторых сценариях это может быть недоступным вариантом. Обратите внимание на предыдущий пример: там используется модуль Ansible cisco.ios.ios_interfaces, реализующий логику, необходимую для обеспечения декларативного поведения.

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

2.3.2. Изменяемая vs. Неизменяемая инфраструктура#

Концепция: Вы разрешаете внесение изменений в инфраструктуру (сеть) на месте, или заменяете её полностью при необходимости изменений?

• Изменяемая инфраструктура: Традиционный подход, при котором вы заходите на устройства через Term "SSH" not found и напрямую модифицируете конфигурации (или модифицируете их через NETCONF, gNMI или любой Term "API" not found). Изменения применяются на месте.
  • Плюс: Менее разрушительно и куда меньше накладных расходов.
  • Минус: Сложнее отслеживать состояние, что повышает риск Term "конфигурационного_дрейфа" not found.
• Неизменяемая инфраструктура: Вы никогда не модифицируете работающую инфраструктуру. Вместо этого создаёте новую инфраструктуру с желаемыми изменениями, после чего на неё переключаете трафик и соединения. Этот подход широко используется в облаке (контейнеры, ВМ), но менее распространён в сетях.
  • Плюс: Предсказуемое состояние, легче тестировать, полностью устраняет дрейф конфигурации.
  • Минус: Требует сложной оркестрации, усложняет восстановление при сбоях и несёт большие накладные расходы на ресурсы.

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

2.3.3. Greenfield vs. Brownfield#

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

• Среды Brownfield существуют с унаследованными системами, ручными процессами, несогласованными конфигурациями и знаниями, доступными только немногим. Они куда сложнее, потому что вы автоматизируете сложность, которая никогда не предназначалась для автоматизации: несогласованные проекты, отсутствующие данные, устаревшие технологии, человеческие привычки и ограничения живого трафика. Но это наиболее распространённая среда.
• Среды Greenfield создаются с нуля на принципах “автоматизация прежде всего”. Здесь можно “чисто” реализовать все подходы: управление версиями с первого дня, декларативное намерение, чистые модели данных и комплексное тестирование. Это идеальный, но редкий сценарий.

Углубимся в детали: почему среды brownfield настолько сложны…

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

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

1. Частичный подход greenfield: Автоматизируйте новую инфраструктуру, постепенно рефакторируя унаследованные системы. Это показывает прогресс без погружения в максимальную сложность с самого начала.
2. Инкрементальный выбор цели: Сосредоточьтесь на частях сети, которые легче автоматизировать и которые дают быстрые результаты:
   • Выявление дрейфа конфигурации и его исправление для нескольких функций управления (AAA, NTP, SNMP)
   • Автоматизация настройки интерфейсов для определённого типа устройств
   • Стандартизация одной подсистемы перед расширением
3. Накопление импульса: Каждая маленькая победа демонстрирует ценность автоматизации и формирует доверие для её последующего финансирования и расширения

2.3.4. Разнообразие устройств и абстракция сервисов#

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

Два основных подхода:

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

Лучшая практика: Многоуровневый подход Большинство зрелых операций используют оба: вендорно-специфические драйверы снизу (один уровень на тип устройства), затем общий уровень абстракции выше. Это даёт вам преимущества сразу обеих стратегий.

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

2.3.5. Заблуждение об инструментах вместо проектирования#

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

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

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

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

2.3.6. Покупать vs. Строить#

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

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

При оценке принятия решения:

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

Это фундаментальное решение о проектировании, а не о закупках. Речь идёт о том, сколько настройки и контроля вам действительно нужно.

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

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

2.3.7. Управление автоматизацией#

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

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

Управление в этом контексте означает определение четырёх вещей:

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

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

• Авторизация выполнения: кто может запускать какое задание, в какой области действия при каких условиях. Это напрямую соответствует ролевому управлению доступом на уровне Выполнения (Глава 5) и уровне Представления (Глава 8). Модель управления должна быть выражена в средствах управления доступом инструментов, а не только в документе с политиками.

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

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

2.3.8. Почему эти принципы важны: обучение на ошибках#

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

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

Урок: Не автоматизируйте хаос, надеясь исправить его позже. Вместо этого:

1. Начинайте с процессов, которые вы понимаете и можете проверить
2. Автоматизируйте постепенно, обучаясь на каждом этапе
3. Рассматривайте каждый сбой автоматизации как возможность для обучения
4. Встраивайте защитные меры: ограничения скорости, механизмы отката, наблюдаемость и ограничение радиуса поражения
5. Разделяйте задачи, чтобы сбои в одной области не распространялись глобально

Обратите внимание, как это соотносится с подходом “Люди, Процесс и Технологии”, представленным в Главе 1.

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

2.4. Принципы разработки ПО#

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

Не все двенадцать принципов имеют равный вес в этой области. Четыре из них устраняют режимы сбоя, специфичные для автоматизации критически важной инфраструктуры: Принцип наименьшего удивления (автоматизация, ведущая себя неожиданно, разрушает операционное доверие, установленное в разделе 2.1, до того как оно успевает укорениться), Защитное и надёжное программирование (сети отказывают частичным, недетерминированным образом, который автоматизация должна предвидеть по замыслу, а не обрабатывать как исключения), Быстрый и видимый сбой (раннее обнаружение сбоев ограничивает радиус поражения до его масштабирования на устройства), и Разделение задач (структурный принцип, который фреймворк NAF в Главе 3 непосредственно воплощает — разделение намерения, логики выполнения и представления здесь не является общей хорошей практикой, это конкретная структура, которая сохраняет независимую эволюцию блоков). Оставшиеся восемь принципов служат стандартной гигиеной разработки ПО: правильные, важные и заслуживающие знания, но они не являются причиной, по которой конкретно сетевая автоматизация терпит неудачу или имеет успех.

Вдохновившись книгами Robert C. Martin’s “Clean Code” и “Clean Architecture”, мы разделим их на две категории:

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

Сосредотачиваясь на их применении к сетевой автоматизации, хорошие примеры этих принципов можно найти в этой серии блогов Network to Code авторства Ken Celenza.

2.4.1. Принципы чистого кода#

В этом разделе акцент сделан на том, как создаются программные компоненты.

Пишите код для читателей

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

DRY — Не повторяйся

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

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

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

Принцип единственной ответственности (SRP)

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

• Рендерер шаблонов конфигурации не должен также обрабатывать обнаружение устройств
• Рабочий процесс валидации не должен также выполнять изменения

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

Быстрый и видимый сбой

Старайтесь обнаруживать проблемы на раннем этапе и раскрывайте их чётко. В автоматизации:

• Проверяйте данные сразу при вводе (не ждите развёртывания)
• Делайте вывод Term "пробного_запуска" not found явным и очевидным
• Фиксируйте сбои с полным контекстом, а не расплывчатыми кодами ошибок
• Немедленно оповещайте операторов при возникновении проблем

Раннее выявление проблем снижает радиус поражения и время реагирования.

Безопасность

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

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

Мы глубоко рассмотрим вопросы безопасности и соответствия требованиям в Главе 12.

Принцип наименьшего удивления

Автоматизация должна вести себя так, как ожидают пользователи. Удивительное или контринтуитивное поведение подрывает доверие.

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

Защитное и надёжное программирование

Встраивайте повторные попытки, паттерны Term "Предохранитель" not found, Term "Компенсирующая_логика" not found и резервные механизмы. Распределённые системы отказывают - проектируйте с учётом этого, а не вопреки. Если устройство временно недоступно, повторяйте попытку с экспоненциальной задержкой, а не завершайте работу аварийно при первой же ошибке. всегда имейте план отката, когда изменение не удалось на полпути.

В сетевой автоматизации:

• Консервативная отправка: Убедитесь, что данные, отправляемые в API или устройства, соответствуют строгим схемам и контрактам
• Либеральное принятие: Будьте готовы обрабатывать вариации (например, атрибуты как целые числа или строки с преобразованием) для максимальной совместимости с различными версиями систем

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

2.4.2. Принципы чистой архитектуры#

Далее мы исследуем принципы, управляющие тем, как компоненты решения по сетевой автоматизации соединяются вместе.

KISS — Делай проще, глупец

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

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

В сетевой автоматизации это означает предпочтение простых Term "декларативных" not found подходов сложным императивным скриптам (когда это возможно), приоритет чёткости, небольших компонуемых компонентов, предсказуемого поведения и решений, которые другие могут легко понять (включая ваше будущее “я”).

Разделение задач

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

В сетевой автоматизации:

• Уровень данных: Сетевое намерение, хранимое как структурированные данные
• Уровень логики: Движки автоматизации и правила валидации
• Уровень представления: API, CLI, панели управления для операторов

Это разделение позволяет изменять способ взаимодействия операторов с автоматизацией, не затрагивая базовую логику. Это разделение напрямую соответствует строительным блокам NAF: уровень данных — это Источник истины (Глава 4), уровень логики охватывает Выполнение (Глава 5), Наблюдаемость (Глава 6) и Оркестрацию (Глава 7), а уровень Представления — это Глава 8. Глава 3 представляет полный фреймворк NAF.

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

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

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

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

Расширяемость

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

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

Минимальная связанность, максимальная связность

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

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

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

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

2.5. Резюме#

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

Эти качества поддерживаются шестью основополагающими принципами проектирования:

1. Управление намерением: Определите, чего вы хотите достичь, прежде чем — как этого достичь
2. Идемпотентность: Повторные выполнения дают согласованные результаты
3. Транзакционность: Изменения никогда завершаются частично - они либо завершаются полностью либо безопасно откатываются при сбое
4. Версионирование: Отслеживайте все изменения с полной историей и журналами аудита
5. Тестируемость: Проверяйте поведение перед развёртыванием в производство
6. Дружественность к пробному запуску: Предварительный просмотр изменений перед выполнением

Помимо этих основных принципов, мы исследовали паттерны архитектурных решений (декларативный vs. императивный, greenfield vs. brownfield, абстракция устройств) и принципы разработки ПО (чистый код и чистая архитектура), которые операционализирующие эти паттерны в реальных системах.

Эти принципы - не абстрактная теория: они конкретно реализованы в инструментах и фреймворках, которые вы будете использовать. На протяжении всей остальной части книги мы увидим, как архитектурное мышление (Глава 3) применяет эти принципы к более крупным системам, и как строительные блоки (Главы 4–9) операционализируют их.

Ключевые выводы:

• Начинайте с принципов, а не с инструментов
• Проектируйте для Term "предсказуемых" not found результатов, а не сложности
• Измеряйте и улучшайте непрерывно

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

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

💬 Found something to improve? Send feedback for this chapter