Apr 19, 2026 · 7704 words · 37 min read

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

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

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

Он ошибся.

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

В тот вечер Хорди вернулся домой и поискал этот титул. Большинство результатов указывало на вакансии в облачных компаниях и инфраструктуре оркестрации контейнеров. Он читал час и понял, наверное, половину прочитанного. Он не писал Python-скриптов. Он не знал, что такое Git на самом деле. Он не был уверен, следует ли ему радоваться или бояться.

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

Эта глава о той трансформации. Не только Хорди, но и организации. Технологии, рассмотренные в Главах 1-12, не работают сами по себе. Они требуют людей с другими навыками, другими ролями и другими способами сотрудничества, чем традиционно развивала сетевая инженерия. Правильно выстроить технологию сложно. Правильно провести организационную трансформацию сложнее, и именно здесь чаще всего терпят неудачу инициативы по автоматизации.

13.1. Кризис идентичности#

Самая сложная часть культурного сдвига - это не изучение Git. Это отказ от идентичности, выстроенной на годах глубокого мастерства работы с Command Line Interface (CLI).

Сетевая инженерия выстроила свою профессиональную культуру вокруг экспертизы, которую ещё недавно было сложно приобрести и невозможно имитировать. Понимание конвергенции BGP в условиях сбоя. Отладка изменений топологии Spanning Tree в 2 часа ночи (и да, Spanning Tree по-прежнему активно используется в production). Чтение дампа пакетов и выявление тонкого несоответствия MTU прежде, чем прикладная команда успела дооформить тикет. Это сложные навыки, развиваемые годами практики, и они сформировали сильные профессиональные идентичности.

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

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

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

Этот сдвиг - от “я настраиваю сети” к “я строю системы, которые настраивают сети” - является культурной трансформацией в центре этой главы. Это не разрыв в навыках. Это разрыв в осмыслении.

flowchart LR
    classDef legacy fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef emerging fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    A["**Network Engineer** - Executes configuration - Deep device expertise"]
    B["**Network Platform Engineer** - Designs automation systems - Expertise embedded in code"]

    A -->|"framing shift"| B

    class A legacy
    class B emerging

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

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

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

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

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

13.2. Новые роли в автоматизированном мире#

Самый контрпродуктивный вопрос, который команда может задать при начале трансформации автоматизации, - это “какие рабочие места исчезнут?”. Более полезный вопрос: “какие роли создаются и что они требуют?”

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

Следующие роли последовательно появляются в командах, успешно завершивших переход.

Инженер сетевой платформы (Network Platform Engineer): Эта роль владеет платформой автоматизации как инженерным артефактом. Платформа включает проектирование схемы Source of Truth (SoT), конфигурацию конвейера выполнения, рабочие процессы CI/CD, проверяющие и развёртывающие изменения автоматизации, платформу сетевой наблюдаемости и контракты интерфейсов между блоками автоматизации. Инженер сетевой платформы является аналогом программного платформенного инженера, который запускает кластеры контейнеров или управляет внутренними инструментами разработчиков: они строят и поддерживают систему, которую другие инженеры используют для управления сетью. Эта роль напрямую связана с архитектурной работой из Глав 4-8 и паттернами платформенной инженерии в Главе 10.
Инженер сетевой надёжности (Network Reliability Engineer, NRE): Модель Site Reliability Engineering, разработанная для крупномасштабных программных сервисов, применима к сетевой автоматизации со значимыми модификациями. Роль NRE адаптирует принципы SRE к сетевым операциям: определение целевых показателей уровня сервиса (SLO) для конвейеров автоматизации, создание процессов реагирования на инциденты при сбоях автоматизации и поддержание бюджетов ошибок, балансирующих скорость разработки со стабильностью. Когда автоматизация с замкнутым контуром даёт сбой в 3 часа ночи, NRE - это человек, чья работа заключается в том, чтобы уже спроектировать инструкцию для этого режима сбоя.
Сетевой архитектор (Network Architect): Эта роль смещается дальше от устройств и ближе к намерению. Сетевой архитектор определяет, какой должна быть сеть: модели намерения в источнике истины, паттерны проектирования, которые будет применять автоматизация, политики, управляющие топологией и адресацией. Они проводят меньше времени в CLI устройств и больше - в проектировании схем, межкомандном архитектурном ревью и оценке того, как проектные решения ограничивают или открывают возможности для автоматизации. Глава 4 описывает уровень намерения, которым эта роль прежде всего владеет.
Сетевой инженер данных (Network Data Engineer): Автоматизация с замкнутым контуром, самовосстанавливающиеся сети и автономная эксплуатация (рассматриваемые в Главах 15-17) зависят от высококачественных операционных данных. Сетевой инженер данных строит и курирует конвейеры данных, питающие системы Observability, определяет схемы, делающие телеметрию применимой для действий, и владеет качеством данных, на которых основаны решения автоматизации. Эта роль связывает блок наблюдаемости из Главы 6 с паттернами замкнутого контура в Части 5.
Разработчик сетевой автоматизации (Network Automation Developer): Эта роль пишет сам код автоматизации: логику интеграции, оркестрацию рабочих процессов, фреймворки валидации и инструментарий, от которого зависит платформа. Разработчик сетевой автоматизации может быть программным инженером, внедрённым в сетевую команду и узнавшим достаточно о сетях для продуктивной работы, или сетевым инженером, освоившим достаточно разработки программного обеспечения для эффективности. Оба пути работают. Важное отличие от инженера сетевой платформы состоит в охвате: разработчик автоматизации поставляет конкретные возможности автоматизации; инженер платформы владеет системой, на которой работают эти возможности.

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

Традиционная роль оператора сокращается, но не исчезает. Исчезает повторяющееся исполнение: ручной провижининг, CLI-сессии для каждого тикета, рабочие процессы “человек как скрипт”. Базовое суждение (знание, когда что-то не так, выявление того, что пропустила автоматизация, принятие решения в неоднозначном инциденте) остаётся ценным и переходит в обеспечение качества и владение эскалацией, а не в рутинное исполнение.

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

flowchart LR
    classDef legacy fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef emerging fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    subgraph Legacy["Legacy Role Profiles"]
        direction TB
        L1[**Network Operator** - Manual provisioning - Device CLI mastery]
        L2[**Network Engineer** - Design and troubleshoot - Vendor expertise]
    end
    subgraph Emerging["Emerging Role Profiles"]
        direction TB
        E1[**Network Platform Engineer** - Automation platform - CI/CD and SoT ownership]
        E2[**Network Reliability Engineer** - SLOs and incident response - Error budgets]
        E3[**Network Architect** - Intent models - Design governance]
        E4[**Network Data Engineer** - Telemetry pipelines - Observability quality]
        E5[**Network Automation Developer** - Workflow and integration code - Validation frameworks]
    end
    L1 -->|evolves to| E1
    L1 -->|evolves to| E5
    L2 -->|evolves to| E2
    L2 -->|evolves to| E3
    L2 -->|evolves to| E4
    class L1,L2 legacy
    class E1,E2,E3,E4,E5 emerging

13.3. Путь трансформации навыков#

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

13.3.1. T-образный инженер#

Концепция T-образного инженера, представленная Тимом Брауном в IDEO и широко принятая в организациях, занимающихся платформами и DevOps, называет работающую модель. Глубокая вертикальная экспертиза в одной области, широкая горизонтальная грамотность в другой. Не симметрия. Не полная вторая специализация. Продуктивная асимметрия.

Сетевому инженеру на пути к инженеру сетевой платформы нужно достаточно программной грамотности, чтобы читать, отлаживать и изменять языки программирования (например, Python) и DSL (например, YAML), понимать рабочие процессы Version Control System (VCS), анализировать сбои конвейера CI/CD и участвовать в решениях по проектированию схем. Им не нужно проектировать структуры данных с нуля или оптимизировать сложность алгоритмов. Им нужна операционная грамотность в практиках программирования, а не вторая карьера в разработке программного обеспечения.

Программному инженеру, переходящему в сетевую автоматизацию, нужно достаточно сетевой глубины, чтобы понять, почему конвергенция BGP занимает то время, которое занимает, как распространяются изменения топологии Spanning Tree, что означает “в конечном счёте согласованный” в контексте распределённой таблицы маршрутизации и почему автоматизация, правильно работающая в лаборатории, может потерпеть неудачу в production из-за различий в реализации вендора. Им не нужен CCIE. Им нужно достаточно основы для информированных разговоров с сетевыми инженерами и для распознавания неправильности своих предположений.

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

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

Когда Хорди подал свой первый pull request по автоматизации, проверявший его программный инженер оставил одиннадцать комментариев: именование переменных, отсутствие обработки ошибок, тест, охватывающий только счастливый путь. Первым его инстинктом была защитная реакция. Он правильно настраивал сети пятнадцать лет. Вторым - закрыть вкладку браузера. Третьим - прочитать комментарии снова, медленно, как если бы они были ошибками интерфейса от незнакомого устройства. К третьему pull request’у он оставлял вопросы в комментариях вместо объяснений. Рецензент стал соавтором. Переход от эксперта к новичку и обратно к эксперту в новой области некомфортен. Но такова форма перехода.

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

13.3.2. Дискуссия об основах#

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

Основы не менее важны в автоматизированном мире. Они применяются по-другому. Инженер, не понимающий поведения конвергенции BGP, не может спроектировать надёжную автоматизацию BGP с замкнутым контуром. Инженер, не понимающий Spanning Tree, не может создать среду моделирования, точно воспроизводящую режимы сбоев production-топологии. Уровень автоматизации стоит поверх сети. Его корректность зависит от качества его модели поведения сети, а эта модель настолько хороша, насколько хорошо понимали базовые протоколы люди, её создавшие.

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

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

Специфические для автоматизации сертификации появились наряду с традиционными сетевыми треками, подтверждая горизонтальную ось T-образности: гигиена контроля версий, проектирование API, основы конвейера CI/CD. Они являются полезными дополнениями к глубине протоколов, а не заменителями.

13.3.3. Влияние ИИ на требования к навыкам#

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

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

Актуальный паттерн здесь - Поднадзорный коллега: относитесь к коду автоматизации, сгенерированному ИИ, так же, как к коду от компетентного, но младшего инженера. Проверяйте его. Тестируйте его. Понимайте его достаточно для отладки. Владейте им. В момент, когда автоматизация попадает в production-конвейер, она ваша, независимо от того, написали ли вы каждую строку.

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

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

13.3.4. Пути развития навыков#

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

Для сетевых инженеров, движущихся к ролям платформы и автоматизации: практическая стартовая последовательность - это основы Python с акцентом на чтении и отладке до написания, рабочие процессы и гигиена VCS, понимание конвейеров CI/CD достаточно для диагностики сбоев, и проектирование схем YAML и JavaScript Object Notation (JSON). Акцент должен быть на чтении и отладке существующего кода до генерации нового. Первым значимым рубежом является не “написал скрипт”. Это “отладил сбой чужой автоматизации и понял, почему это произошло”. Через шесть месяцев после начала перехода Хорди столкнулся именно с этим: сорокастрочный Python traceback в production-рабочем процессе, которого он не писал. Его первым инстинктом было переслать его программному инженеру в команде. Вместо этого он начал читать сверху, строка за строкой, как прежде читал таблицу маршрутизации. Специфическое для сети предположение, вызвавшее сбой, было на строке 23: жёстко закодированное ожидание относительно состояния BGP-сессии, которое имело смысл для любого, настраивавшего BGP вручную, и которое никому не приходило в голову как нечто, требующее теста. Он исправил это сам. Traceback перестал быть шумом. Он стал картой.
Для программных инженеров, переходящих в сетевую автоматизацию: практическая стартовая последовательность - это основы IP, один протокол маршрутизации, изученный достаточно глубоко для рассуждений о режимах сбоев, операционная модель доверия, делающая сетевых инженеров осторожными в отношении изменений (одна неправильная команда может вывести production-сеть из строя способами, которые ошибка в веб-приложении обычно не может), и опыт тени рядом с сетевыми инженерами во время production-инцидентов. Первым значимым рубежом является не “понимает теорию сетей”. Это “знает, чего боится сетевой инженер и почему”.

flowchart LR
    classDef net fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef sw fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef shared fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b

    subgraph Network["Network Engineering"]
        N1["Protocol expertise - Device behavior - Fault diagnosis"]
    end
    subgraph Overlap["Shared Zone"]
        O1["Automation design - SoT schema - Simulation fidelity - Change trust model"]
    end
    subgraph Software["Software Engineering"]
        S1["Code structure - Testing discipline - CI/CD pipelines"]
    end

    Network --- Overlap --- Software

    class N1 net
    class O1 shared
    class S1 sw

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

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

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

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

13.3.5. Практический инструментарий#

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

flowchart BT
    classDef foundation fill:#4a7fa5,stroke:#2d5f80,color:#fff
    classDef automation fill:#3a8a5a,stroke:#2d6b45,color:#fff
    classDef platform fill:#7a5a8a,stroke:#5d4570,color:#fff

    F["**Foundation Layer** - Git · Python · YAML"]
    A["**Automation Layer** - Ansible · Jinja2 · Netmiko/NAPALM · Nornir"]
    P["**Platform Layer** - SoT · Testing · Docker · Kubernetes · CI/CD"]

    F --> A --> P

    class F foundation
    class A automation
    class P platform

Фундаментальный уровень (начать здесь):

Git: Обязательная отправная точка. Коммит, ветка, pull request, разрешение конфликтов слияния. Всё остальное в платформе автоматизации зависит от гигиены контроля версий. Изучите это до любого инструмента автоматизации.
Python: Акцент на чтении и отладке существующего кода до написания нового. Первым рубежом является чтение traceback и понимание того, что он говорит, а не написание класса с нуля.
YAML: Язык конфигурации большинства инструментов сетевой автоматизации. Понимание структуры, отступов и типов данных необходимо для работы с Ansible, NetBox и большинством конвейеров CI/CD.

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

Уровень автоматизации:

Ansible: Наиболее широко развёрнутый инструмент выполнения в сетевых средах. Плейбуки, инвентарь, роли и приоритет переменных. Охватывает большинство случаев использования автоматизации провижининга и конфигурации.
Jinja2: Движок шаблонов, используемый с Ansible и большинством рабочих процессов генерации конфигурации. Понимание того, как шаблоны рендерятся на основе переменных данных, необходимо для управления конфигурацией в масштабе.
Netmiko или NAPALM: Netmiko обрабатывает автоматизацию SSH/CLI для унаследованных устройств. NAPALM предоставляет многовендорный уровень абстракции для устройств с поддержкой структурированных API. Один или оба появятся в большинстве существующих кодовых баз сетевой автоматизации.
Nornir: Python-нативный фреймворк автоматизации, обрабатывающий управление соединениями, выполнение задач и параллелизм по большому инвентарю устройств. Там, где Ansible абстрагирует Python, Nornir его раскрывает, делая его лучшим вариантом для сложных рабочих процессов, где требуется полный программный контроль.

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

Уровень платформы:

Источник истины: Наиболее распространённые реализации источника истины. Понимание проектирования схем, взаимодействия с API и того, как автоматизация читает из источника истины и записывает в него, связывает инструменты выполнения с архитектурной моделью из Главы 4.
Тестирование: Написание тестов для кода автоматизации. Первое значимое применение - не написание новых тестов, а понимание того, что покрывают существующие тесты и чего им не хватает.
Основы Docker: Достаточно, чтобы запустить локальную среду разработки, понять, что такое образ контейнера, и прочитать Compose-файл. Не оркестрация контейнеров, просто достаточно, чтобы не блокироваться настройкой среды.
Основы Kubernetes: Компоненты платформы автоматизации (оркестратор, API-шлюз, стек наблюдаемости) всё чаще работают как контейнеризированные рабочие нагрузки на Kubernetes. Инженеру не нужно управлять кластером, но чтение манифеста развёртывания, понимание перезапусков подов и умение проверять логи из работающего контейнера - это навыки, регулярно появляющиеся при отладке проблем платформы.
Конвейер CI/CD: Чтение и понимание определений конвейеров, диагностика сбоев конвейеров и знание того, где в конвейере произошёл сбой. Написание конвейеров с нуля приходит позже.

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

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

13.4. Продвижение принятия#

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

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

Пилот - это доказательство того, что автоматизация работает хотя бы для одного случая использования достаточно надёжно, чтобы команда ей доверяла. Критерий успеха - не охват или объём кода. Это доверие. Действительно ли команда использует эту автоматизацию вместо ручного процесса? Если ответ “в основном, но мы всё равно делаем это вручную для важных изменений”, пилот не удался.
Масштаб - это распространение автоматизации на большее количество случаев использования и инженеров. Критерий успеха - самообслуживание: могут ли инженеры, не строившие автоматизацию, использовать её без запроса к первоначальным авторам? Платформа, которую могут эксплуатировать только её строители, не масштабировалась. Она просто переместила ручную зависимость с CLI устройства на инструмент автоматизации.
Устойчивость - это автоматизация, переживающая своих первоначальных авторов. Критерий успеха - онбординг: может ли новый инженер понять, изменить и расширить существующую автоматизацию без необходимости объяснений от первоначальной команды? Если ответ нет, автоматизация является зависимостью от ключевых лиц с лучшим инструментарием.

13.4.1. Паттерны сопротивления изменениям#

Три паттерна сопротивления появляются достаточно последовательно, чтобы их назвать:

Паттерн Замороженного эксперта: инженер с наибольшим старшинством, опирающийся на глубокую экспертизу в ручном способе работы, становится самым громким критиком автоматизации. Это не иррационально. Их статус, карьерная траектория и профессиональная идентичность более угрожаемы изменением, чем у любого младшего инженера. Эффективный ответ - сделать их автором автоматизации, а не её аудиторией. Замороженный эксперт, проектирующий первый рабочий процесс автоматизации, заинтересован в его успехе. Замороженный эксперт, которому вручают готовую платформу и говорят использовать её, мотивирован находить её изъяны.
Паттерн Невидимого ROI: автоматизация, работающая правильно, не генерирует тикетов и не производит видимой активности. Видимыми являются только сбои. Команда, успешно автоматизировавшая провижининг VLAN, может месяцами получать никакого сигнала о том, что автоматизация приносит ценность, потому что сигналом были бы сотни тикетов, которые так и не были поданы. Противодействие этому требует намеренной инструментации: отслеживание времени провижининга до и после, подсчёт предотвращённых инцидентов, измерение улучшения Mean Time To Resolution (MTTR) и визуализация этих цифр для заинтересованных лиц, которые иначе видят автоматизацию только при её сбое.
Паттерн Чёрного ящика: автоматизация, используемая только инженерами, создавшими её, не потому что у других нет доступа, а потому что другие не доверяют тому, чего не понимают. Автоматизация производит правильные результаты, но не даёт понимания того, что она делает и почему. Другие инженеры обходят её, потому что ручной процесс, каким бы медленным он ни был, по крайней мере понятен. Ответ - встраивание прозрачности в саму автоматизацию: журналы аудита, пошаговые трассировки выполнения, чёткие сообщения об ошибках и режимы Dry Run, показывающие, что произойдёт, до того как что-либо случится. Доверие следует за пониманием. Система автоматизации, не способная объяснить свои собственные действия, не завоюет принятие за пределами своих авторов. Глава 2, раздел 2.1 заложила основу для построения доверия к автоматизации: качества понятности, предсказуемости и применимости - это не функции, добавляемые поверх работающей системы. Это то, что делает систему достаточно надёжной для использования.

13.4.2. Метрики принятия#

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

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

13.5. Поддержание платформы#

Достижение ступени “Устойчивость” на Лестнице принятия - это не конец проблемы. Автоматизация, достигшая production и заслужившая доверие, всё равно требует активной организационной поддержки для сохранения работоспособности по мере роста команды, старения кодовой базы и ухода инженеров, создавших её. Практики в этом разделе решают другую задачу, чем принятие: не как начать, а как продержаться.

13.5.1. Наследование DevOps и Agile#

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

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

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

Заимствование из культуры программной инженерии касается не принятия её словаря. Речь идёт о применении решений, заработанных через десятилетие аналогичных организационных задач. Режим неудачи, которого следует избегать, - это семантическое принятие: команды, переименовывающие свой процесс изменений в “CI/CD”, называющие квартальное планирование “спринтами” и объявляющие себя DevOps-организациями, сохраняя при этом каждую поведенческую привычку, которую эти движения были специально разработаны для разрушения. Сигнал - команда с конвейером автоматизации, по-прежнему требующим четырёхнедельного согласования в CAB для каждого изменения, которое конвейер мог бы выполнить. Словарь изменился. Культура - нет.

13.5.2. Новое управление изменениями#

Автоматизация не устраняет управление изменениями. Она его трансформирует.

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

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

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

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

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

13.5.3. Культура обучения и документации#

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

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

ADR - это короткий документ, обычно Markdown-файл, хранящийся непосредственно в VCS-репозитории рядом с кодом автоматизации, фиксирующий одно значимое решение: контекст, сделавший решение необходимым, рассмотренные варианты, сделанный выбор и вытекающие из него последствия. Формат был популяризирован Майклом Найгардом и широко используется в программной инженерии. Сообщество ADR поддерживает инструментарий и шаблоны на adr.github.io. GitHub рендерит Markdown нативно, что означает: ADR, зафиксированный в том же репозитории, что и автоматизация, всегда находится в одном клике от объясняемого им кода, версионирован вместе с ним и виден в истории pull request’ов. Когда инженер спрашивает “почему это структурировано именно так?” три года после ухода первоначального автора, ADR является ответом. Без него ответ либо “никто не знает”, либо реконструкция из git blame, редко являющаяся полной.

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

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

13.5.4. Захват знаний и открытый исходный код#

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

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

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

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

13.5.5. Этические и человеческие последствия#

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

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

Измерение ИИ обостряет этот вопрос. Когда система оркестрации на основе ИИ принимает решение о маршрутизации автономно (как описано в Главе 17), цепочка между человеческим намерением и сетевым действием включает уровень рассуждений, который нельзя полностью проаудировать так, как можно проверить детерминированный код. Система ИИ может прийти к правильному действию по причинам, не предвиденным развернувшими её инженерами. Она также может прийти к неправильному действию по тем же причинам. Когда автоматизация ошибается, вопрос “кто несёт ответственность?” становится подлинно трудным.

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

13.6. Межнаправленное сотрудничество#

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

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

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

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

13.6.1. Баланс управления и расширения полномочий#

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

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

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

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

13.6.2. Общие платформы против федеративной автоматизации#

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

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

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

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

13.6.3. Встроенное сотрудничество#

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

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

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

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

flowchart TD
    classDef shared fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef domain fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    SoT["Source of Truth - Cross-domain intent"]

    subgraph Domains["Domain Execution Layer"]
        direction LR
        NP["Network Platform"]
        SP["Security Policy Engine"]
        CP["Cloud Provisioning"]
    end

    Obs["Observability - Cross-domain telemetry"]

    SoT --> NP & SP & CP
    NP & SP & CP --> Obs
    Obs -.->|"feedback"| SoT

    class SoT,Obs shared
    class NP,SP,CP domain

13.7. Итоги#

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

Три темы являются основой главы:

Роли эволюционируют, они не исчезают. Переход от сетевых операций к платформенной инженерии - это карта трансформации, а не схема замены. Глубокие знания протоколов не становятся менее ценными в автоматизированном мире. Они применяются по-другому: от выполнения конфигурации к проектированию систем, правильно выполняющих конфигурацию. Пять появляющихся ролей, описанных в разделе 13.2, являются пунктом назначения, на который направлены пути T-образного развития навыков.
Принятие требует активного проектирования. Лестница принятия (пилот, масштаб, устойчивость) называет три этапа с различными критериями успеха. Преодоление первой ступеньки требует доверия, а не охвата. Преодоление второй требует самообслуживания. Преодоление третьей требует автоматизации, переживающей своих авторов. Паттерны сопротивления (Замороженный эксперт, Невидимый ROI, Чёрный ящик) являются предсказуемыми препятствиями с известными ответами (раздел 13.4.1). Поддержание этого принятия требует другого набора привычек: наследования DevOps и Agile, модели управления изменениями, откалиброванной по профилю риска автоматизации, документации, встроенной в саму автоматизацию, и захвата знаний, переживающего текучесть команды (разделы 13.5.1-13.5.4).
Межнаправленное сотрудничество является архитектурным, а не организационным. Проблема трёх королевств (NetOps, SecOps, CloudOps, работающих в отдельных силосах) не разрешается через добрую волю или мандаты управления. Она разрешается через общую архитектуру данных: единый источник истины с согласованной схемой, федеративный инструментарий исполнения, читающий из него, и встроенные кросс-функциональные отряды, владеющие стыками между доменами. Паттерн Вымощенной дороги является моделью управления, делающей это работающим без требования от всех команд сходиться на единой платформе.

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

Ссылки и дополнительное чтение#

The Phoenix Project, Джин Ким, Кевин Бер, Джордж Спаффорд (IT Revolution Press, 2013). Рассказ в формате романа о трансформации DevOps в ИТ-организации под давлением. Организационная динамика, конфликт между скоростью разработки и стабильностью операций и появление общего владения напрямую отображаются на динамику программ автоматизации, описанных в этой главе.
The DevOps Handbook, Джин Ким, Патрик Дебуа, Джон Уиллис, Джез Хамбл (IT Revolution Press, 2016). Практическое дополнение к The Phoenix Project: три пути (поток, обратная связь, непрерывное обучение), конвейеры развёртывания и безвиновные постмортемы. Разделы о наследовании DevOps в этой главе опираются на эти основы.
Team Topologies, Мэтью Скелтон, Мануэль Пайс (IT Revolution Press, 2019). Исчерпывающий фреймворк для проектирования структур команд вокруг быстрой доставки программного обеспечения. Концепции команд, ориентированных на поток, платформенных команд и команд поддержки напрямую переносятся в межнаправленное сотрудничество и встроенные модели отрядов, обсуждаемые в разделе 13.6.
Accelerate, Николь Форсгрен, Джез Хамбл, Джин Ким (IT Revolution Press, 2018). Подкреплённый исследованиями анализ того, какие организационные и технические практики предсказывают производительность доставки программного обеспечения. Четыре ключевые метрики (частота развёртывания, время до изменения, уровень сбоев при изменении, время восстановления) обеспечивают количественную основу для метрик принятия в разделе 13.4.2.
Change by Design, Тим Браун (HarperCollins, 2009). Представляет модель T-образного инженера и лежащий в основе неё подход дизайн-мышления. Фреймворг IDEO глубокой доменной экспертизы в сочетании с межнаправленной грамотностью является основой для путей трансформации навыков в разделе 13.3.

💬 Found something to improve? Send feedback for this chapter