Nov 10, 2025 · 2340 words · 11 min read

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

1. Императив автоматизации#

“Автоматизировать или не автоматизировать — вот в чём вопрос.”

С момента появления Software-Defined Networking (SDN) и DevOps инженеры спорят о том, является ли сетевая автоматизация необходимостью, роскошью или просто излишеством. Ответ? Зависит от ситуации. Гиперскейлеры в ней нуждаются: они начали в начале 2010-х, потому что у них не было выбора. Небольшим компаниям полная автоматизация может вовсе не понадобиться. Большинство сетей находится где-то посередине. Культура, навыки, зрелость инструментов, бизнес-приоритеты — всё это определяет скорость внедрения. Сегодня все эти факторы сходятся воедино. Автоматизация становится неизбежной.

Сетевая команда региональной логистической компании три года строила то, что они называли своей платформой автоматизации: Ansible-плейбуки для настройки VLAN, конфигурации BGP-соседей и укрепления устройств. Их код хранился в Git. Изменения проходили через взаимную проверку. Развёртывание занимало минуты вместо дней. По всем имевшимся у них меркам, автоматизация была сделана правильно.

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

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

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

1.1. Идеальный шторм#

Автоматизация больше не является опциональной. Гиперскейлеры имеют дело со взрывным ростом Искусственного интеллекта: сотни тысяч Central Processing Unit (CPU) и Graphics Processing Unit (GPU), взаимодействующих через высокоскоростной Ethernet. Предприятия и сервис-провайдеры жонглируют унаследованной инфраструктурой, новыми сервисами, расползанием облачных/локальных/граничных ресурсов и растущими затратами.

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

Вопрос больше не звучит “Нужно ли нам автоматизировать?”. Он звучит: “Почему мы ещё не сделали этого?”

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

Отсутствие моделей намерения: Сети описывались через конфигурации устройств, а не через вопрос “как сеть на самом деле должна себя вести?” Без чётких данных о намерении автоматизация остаётся хрупкой и ориентированной на устройства.
Запутанные, непоследовательные проекты: Автоматизация требует предсказуемости. Сети, полные исключений, ситуативных обходных путей и одноразовых решений, невозможно автоматизировать. Чистые, стандартизированные проекты побеждают.
Распыление вендоров: Смесь вендоров, платформ и сервисов означает постоянные головные боли с интеграцией.
Неправильные навыки: Мало инженеров знали как сети, так и разработку программного обеспечения. Этот разрыв делал автоматизацию сложной для качественного проектирования.
Страх перемен: Сети критически важны. Консервативное управление изменениями затрудняло обоснование автоматизации.
Отсутствие безопасных тестовых сред: У большинства команд не было надлежащих лабораторий, соответствующих производству. Безопасное тестирование автоматизации было практически невозможным.

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

flowchart LR
    subgraph Technical
        A[No intent models]
        B[Messy designs]
        C[Vendor sprawl]
        D[No test environments]
    end
    subgraph Organizational
        E[Wrong skills]
    end
    A --> F[Fear of change]
    B --> F
    C --> F
    D --> F
    E --> F
    F -->|limits investment| E
    F -->|slows progress on| A

    style F fill:#ffcccc,stroke:#cc0000,stroke-width:2px

Хорошая новость: к 2025 году большинство из них растворяются. Компании и вендоры движутся вперёд. Опрос о состоянии сетевой автоматизации Криса Грундемана (Network Automation Forum) показывает происходящий сдвиг. Тем не менее, единой волшебной формулы не существует. Сначала нужно понять образ мышления.

1.2. Как подходить к сетевой автоматизации#

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

1.2.1. Три столпа успеха#

Подобно пирамиде Маслоу (вам нужен прочный фундамент, прежде чем строить выше), каждый столп поддерживает тот, что выше него.

flowchart BT
    A[People] --> B[Process]
    B --> C[Technology]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc

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

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

1.3. Как выглядит реальность#

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

1.3.1. Понимание спектра автоматизации#

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

graph LR
    A[Manual Operations] --> B[Scripted Tasks]
    B --> C[Workflow Automation]
    C --> D[Intent-Based Systems]
    D --> E[Autonomous Networks]

    style A fill:#ffcccc
    style B fill:#ffe6cc
    style C fill:#ffffcc
    style D fill:#ccffcc
    style E fill:#ccccff

Ручные операции: Каждое изменение — это решение человека, выполняемое вручную через Command Line Interface (CLI). Быстро для одного инженера на знакомом устройстве, ненадёжно при любом масштабе. Сеть настолько согласована, насколько последователен последний, кто к ней прикасался. Следа аудита нет — только записи о входе в систему.

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

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

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

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

Части 1–3 этой книги формируют архитектурный фундамент для систем на основе намерений. Части 4 и 5 посвящены тому, что необходимо для шага к автономной эксплуатации. Большинство организаций сегодня находятся между скриптовыми задачами и автоматизацией рабочих процессов. Цель состоит не в том, чтобы перепрыгнуть вперёд: нужно строить каждый уровень на прочном фундаменте, чтобы следующий уровень не требовал перестройки предыдущего.

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

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

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

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

Гиперскейлеры

Берут проект и разворачивают его во все данные, необходимые для сетевого намерения: стойки, устройства, кабели, Internet Protocol (IP), оверлей, сети. Используют это для генерации Bill of Materials (BOM) и начальных конфигураций, подаваемых через Zero Touch Provisioning (ZTP) при подключении устройств.
Коррелируют данные наблюдаемости (метрики, логи, потоки) в события реального времени, обогащённые контекстом. Запускают рабочие процессы, устраняющие проблемы пользователей: отводят соединения при сохранении пропускной способности в рамках SLA.

Сервис-провайдеры

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

Предприятия

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

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

Эти решения могут быть простыми или сложными, но они разделяют общие паттерны. Эта книга анализирует эти паттерны и завершается сложными реальными примерами использования в Части 5 — Паттерны и примеры использования.

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

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

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

Попытка автоматизировать всё сразу: Начинайте с малого. Выбирайте варианты использования с высокой отдачей и низким риском, чтобы выработать уверенность и экспертизу.
Встраивание намерения внутрь инструментов: Когда соглашения об именовании, стратегии выделения IP-адресов и предположения о поведении вендоров живут внутри плейбуков и скриптов, а не в общем источнике ссылки, не существует единого описания того, как должна выглядеть сеть. Когда среда меняется, каждое встроенное предположение ломается сразу. Намерение принадлежит одному месту, разделяемому всеми компонентами автоматизации.
Недооценка качества данных: Автоматизация хороша ровно настолько, насколько хороши её данные. Инвестируйте в точность и согласованность с самого начала.
Создание без тестирования: Тестируйте и проверяйте перед развёртыванием в производство.
Автоматизация текущей сети вместо проектирования для изменений: Автоматизация, построенная вокруг текущей топологии, вендоров и соглашений об именовании, работает до тех пор, пока что-то не меняется. Перед созданием любого компонента автоматизации спрашивайте не “работает ли это сейчас?”, а “будет ли это работать, когда среда изменится?” Кодирование текущей сети в автоматизации создаёт технический долг, который накапливается каждый раз, когда бизнес развивается.
Создание для инженеров, которые это построили, а не для людей, которые этим пользуются: Платформа автоматизации, спроектированная только для команды, которая её создала, является единой точкой отказа. Команда приложений, отправляющая запрос на обслуживание, оператор, утверждающий ворота изменения, аудитор, просматривающий отчёт о соответствии — у каждого разные потребности, разная лексика и разные ожидания. Держать этих пользователей в голове с самого начала формирует каждое архитектурное решение: как структурирован API, как отображаются ошибки, как передаётся статус. Автоматизация, которую понимают инженеры, но которую не могут использовать потребители, будет тихо обходиться стороной.

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

1.3.3. Измерение успеха автоматизации#

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

Технические метрики:

Среднее время восстановления (MTTR): Насколько быстро вы можете обнаружить, диагностировать и устранить сетевые проблемы?
Процент успешных изменений: Какой процент сетевых изменений развёртывается без возникновения инцидентов?
Configuration Drift: Насколько согласованы конфигурации устройств по всей сети?
Скорость развёртывания: Насколько быстро вы можете внедрять новые сервисы или изменения конфигурации?

Бизнес-метрики:

Доступность сервисов: Являются ли сервисы, управляемые автоматизацией, более надёжными, чем управляемые вручную?
Производительность инженеров: Тратят ли команды больше времени на стратегическую работу в сравнении с операционными задачами?
Уровень соответствия требованиям: Насколько быстро вы можете проверить и устранить нарушения соответствия?
Использование ресурсов: Используете ли вы лучше сетевую ёмкость и производительность?

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

1.4. Резюме#

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

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

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

Спектр автоматизации простирается от ручных операций через скриптовые задачи, автоматизацию рабочих процессов, системы на основе намерений и автономные сети. Большинство организаций сегодня находятся где-то посередине. Эта книга строит архитектурный фундамент для уровня на основе намерений: Части 1 и 2 устанавливают почему и как, Часть 3 исследует, что меняется при масштабировании, а Части 4 и 5 изучают паттерны, позволяющие сделать шаг к автономной эксплуатации.

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

💬 Found something to improve? Send feedback for this chapter