Nov 10, 2025 · 2565 words · 13 min read

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

flowchart LR
    subgraph Технические
        A[Отсутствие моделей управления на основе намерений]
        B[Хаотичная архитектура сетей]
        C[Мультивендорный хаос]
        D[Отсутствие тестовых сред]
    end
    subgraph Организационные
        E[Несоответствие квалификации]
    end
    A --> F[Страх изменений]
    B --> F
    C --> F
    D --> F
    E --> F
    F -->|ограничивает инвестиции| E
    F -->|замедляет прогресс в этом направлении| A

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

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

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

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

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

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

flowchart BT
    A[Люди] --> B[Процесс]
    B --> C[Технологии]

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

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

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

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

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

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

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

graph LR
    A[Ручные операции] --> B[Скриптовые задачи]
    B --> C[Автоматизация рабочих процессов]
    C --> D[Системы на основе намерений]
    D --> E[Автономные сети]

    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