Проектирование автоматизации сетей в масштабе on Designing Network Automation at Scale

01 - Императив автоматизации

Mon, 10 Nov 2025 00:00:00 +0000

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

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

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

02 - Принципы проектирования

Sun, 30 Nov 2025 00:00:00 +0000

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

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

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

03 - Архитектурное мышление

Wed, 10 Dec 2025 00:00:00 +0000

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

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

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

04 - Источник истины

Sun, 15 Feb 2026 00:00:00 +0000

4. Источник истины#

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

05 - Исполнение

Sat, 01 Nov 2025 00:00:00 +0000

5. Исполнение#

Плейбук работал безупречно месяцами: десять коммутаторов доступа в лаборатории, два минуты от начала до конца, чистые результаты каждый раз. Когда команда решила развернуть его на полный инвентарь из 800 коммутаторов, никто не ожидал проблем. Первые 600 устройств обновились без единого сбоя. Затем задание замедлилось. Потом зависло. RADIUS-сервер, внезапно получивший 150 одновременных запросов SSH-аутентификации, начал отклонять подключения. Ansible завис на 150 устройствах прямо посреди выполнения. Инженер остановил задание.

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

Предисловие

Sat, 01 Nov 2025 00:00:00 +0000

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

💬 Found something to improve? Send feedback for this chapter

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

Mon, 12 Jan 2026 00:00:00 +0000

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

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

07 - Оркестрация

Fri, 20 Mar 2026 00:00:00 +0000

7. Оркестрация#

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

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

08 - Уровень представления

Sat, 28 Mar 2026 00:00:00 +0000

8. Уровень представления#

Автоматизация VLAN работала уже шесть недель. Сетевая команда гордилась результатом. Каждое утро от прикладных команд поступало три-четыре новых заявки на обслуживание, и оркестратор обрабатывал их без единого нажатия клавиши кем-либо из сетевых инженеров. Развёртывания выполнялись. Коммутаторы настраивались. Сеть работала исправно.

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

09 - Сеть

Sun, 29 Mar 2026 00:00:00 +0000

9. Сеть#

Автоматизация VLAN три недели работала в лаборатории. Три коммутатора, по одному каждого вендора, все рабочие процессы проходят. Команда была уверена в результате. На первом production-прогоне 23 из 800 коммутаторов кампуса дали сбой. Все HPE. Все работающие на версии прошивки, которую никто не задокументировал.

Плейбук проверял ответ об ошибке от каждого устройства после отправки конфигурации VLAN. На современной прошивке HPE уже существующий VLAN возвращает код ошибки duplicate-vlan. На этой старой версии прошивки то же условие возвращало vlan-exists. Плейбук был написан так, чтобы обрабатывать duplicate-vlan как сигнал идемпотентности, означающий “это уже существует, всё в порядке”. Он не был написан для обработки vlan-exists, поэтому воспринимал этот ответ как сбой. Треть парка HPE сообщила об ошибке. Откат выполнился чисто. Тикет прикладной команды оставался открытым ещё три часа, пока сетевая команда вручную проверяла, какие коммутаторы были реально настроены, а какие нет.

10 - Платформенная инженерия и CI/CD

Mon, 01 Jan 0001 00:00:00 +0000

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

💬 Found something to improve? Send feedback for this chapter

11 - Масштабирование и надёжность

Mon, 01 Jan 0001 00:00:00 +0000

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

💬 Found something to improve? Send feedback for this chapter

12 - Безопасность, управление и соответствие требованиям

Mon, 01 Jan 0001 00:00:00 +0000

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

💬 Found something to improve? Send feedback for this chapter

13 - Культурный сдвиг

Sun, 19 Apr 2026 00:00:00 +0000

13. Культурный сдвиг#

Приглашение на встречу пришло в четверг. Тема: “Обновление структуры сетевой команды”. Хорди проработал сетевым инженером пятнадцать лет. У него был CCIE. Он пережил три поглощения, две консолидации NOC и один инцидент с маршрутизацией BGP настолько серьёзный, что он превратился во внутренний учебный кейс. Он решил, что речь пойдёт об изменениях в штате.

Он ошибся.

Его руководитель объяснил, что сетевая команда реорганизуется под Platform Engineering. Название команды изменится на Network Automation Platform. Работа будет развиваться: меньше ручного провижининга, больше создания и эксплуатации систем автоматизации, которые занимаются провижинингом. Новое описание должности уже было написано. Оно называлось “Network Platform Engineer”.

14 - Автоматизация как продукт

Tue, 05 May 2026 00:00:00 +0000

14. Автоматизация как продукт#

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

15 - Автоматизация с замкнутым контуром

Mon, 01 Jan 0001 00:00:00 +0000

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

💬 Found something to improve? Send feedback for this chapter

16 - Самовосстанавливающиеся сети

Mon, 01 Jan 0001 00:00:00 +0000

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

💬 Found something to improve? Send feedback for this chapter

17 - Автономные сети

Mon, 01 Jan 0001 00:00:00 +0000

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

💬 Found something to improve? Send feedback for this chapter

Об авторе

Sun, 10 May 2026 00:00:00 +0000

Об Кристиане Аделе#

Staff Network Developer в CoreWeave | Барселона, Испания

Кристиан Адель построил свою карьеру в области разработки программного обеспечения для автоматизации сетей. Он является признанным экспертом в этой области с большим опытом проектирования и внедрения решений по автоматизации сетей в масштабе.

Контакты#

GitHub: chadell
LinkedIn: christianadell
Twitter: @chadell0

Опубликованные книги#

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

Network Programmability and Automation, 2nd Edition

Network Automation with Nautobot

Modern Network Observability

Network Automation Cookbook, 2nd Edition

Конференции и участие в сообществе#

Кристиан является активным докладчиком на крупных конференциях по сетевым технологиям:

Правовая информация

Sat, 01 Nov 2025 00:00:00 +0000

Правовая информация#

Уведомление об авторских правах#

Содержимое этого сайта, включая текст, диаграммы и примеры, является интеллектуальной собственностью автора и распространяется по лицензии Creative Commons «Атрибуция — Некоммерческое использование — Без производных произведений» 4.0 Всемирная (CC BY-NC-ND 4.0).

Вы можете свободно:

Делиться — копировать и распространять материал на любом носителе или в любом формате при надлежащем указании авторства

При соблюдении следующих условий:

Атрибуция — Вы должны указать авторство Christian Adell Querol, предоставить ссылку на лицензию и указать, были ли внесены изменения.
Некоммерческое использование — Вы не можете использовать материал в коммерческих целях.
Без производных произведений — Вы не можете изменять, преобразовывать или создавать производные произведения для распространения.

Важные замечания