Часть 2: Архитектурные строительные блоки on Designing Network Automation at Scale

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

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 сообщила об ошибке. Откат выполнился чисто. Тикет прикладной команды оставался открытым ещё три часа, пока сетевая команда вручную проверяла, какие коммутаторы были реально настроены, а какие нет.