Что такое жизнеспособность?
Если мы собираемся говорить о минимально жизнеспособном продукте для достижения ваших целей NetDevOps, нам нужно поговорить о концепции жизнеспособности в программном проекте. В частности, для наших сценариев использования NetDevOps под жизнеспособностью понимается продукт или решение, которое может обеспечить требуемый результат последовательно и в автоматическом режиме. Например, предположим, что ваша первоначальная цель — программно управлять резервированием и развертыванием VLAN на коммутаторах в ваших центрах обработки данных. Жизнеспособным решением этой проблемы было бы не просто зарезервировать VLAN, но также потребовалось бы развернуть конфигурацию на самих коммутаторах. Решение не будет считаться жизнеспособным, если будет достигнута только половина этой цели, возможно, просто назначение VLAN, но не конфигурация.
В качестве другого примера предположим, что вашей целью было создать отчет, в котором перечислены все сетевые устройства с несовместимыми конфигурациями AAA. Если вы создали решение, которое генерировало отчет, но также автоматически исправляло несовместимые конфигурации, вы создали жизнеспособное решение. Однако это не минимально жизнеспособное решение. Хотя исправление несовместимых устройств может быть логическим следующим шагом после их идентификации и сообщения о них, это не входит в первоначальную цель. И в результате вы выполнили работу, которая не входила в рамки или не планировалась для этого этапа проекта, и потенциально неправильно направили время и усилия, которые можно было бы лучше потратить на что-то другое.
Многие проекты, предпринятые инженерами, занимающимися сетевой автоматизацией и NetDevOps, быстро переходят ко второму примеру и пытаются «вскипятить океан». Я был виноват в этом в прошлом, и, получив возможность снова выполнить некоторые из моих первых проектов автоматизации, я бы резко сократил объем и сосредоточился на предоставлении краткого и успешного результата для одного варианта использования. Затем, когда я заложил основу для своего MVP, я смог развить этот успех для быстрого масштабирования для решения дополнительных вариантов использования или рабочих процессов.
Определение минимально жизнеспособного продукта
Признавая, что создание MVP и его итерация является успешной стратегией создания платформы и инструментов NetDevOps, один из часто задаваемых вопросов: «Как вы оцениваете минимально жизнеспособный продукт?» Хотя каждая сеть в чем-то отличается, вот несколько простых идей, которые помогут вам определить минимально жизнеспособный продукт для применения методологий NetDevOps в вашей сетевой инфраструктуре. Если вы уже хорошо освоили внедрение концепций NetDevOps в своей сети, возможно, каждый раз, когда вы смотрите на включение дополнительного рабочего процесса в свои процессы, учитывайте приведенное ниже и планируйте его соответствующим образом. Хотя это ни в коем случае не является авторитетным планом, он предназначен для представления некоторых идей и концепций, которые следует учитывать при размышлениях о минимально жизнеспособном продукте на пути к NetDevOps.
Начни с малого
Возможно, в вашей сети всего 50 устройств, а может быть, в вашей сети 50 000. В любом случае вы всегда должны начинать с малого. Выберите несколько сетевых устройств, которыми вы можете манипулировать по своему желанию. При определении того, что ваш минимально жизнеспособный продукт решит для данной проблемы, подумайте, без какой части сети вы могли бы жить. Если ответить на вопрос: «Что будет, если я отключу эти устройства?» заставляет вас потеть, вероятно, не запускайте на этих устройствах.
Если ваша цель, например, обеспечить соблюдение известной / золотой конфигурации на всех портах коммутатора, обращенных к пользователю, в вашей офисной среде, выберите то, что считается небольшим для вашей среды (может быть, одно офисное здание, этаж или даже шкаф), и начните с них.
Маленький — это не такой же простой
Оцените технологии, которые вам понадобятся для выполнения этого плана, и начните создавать их. Помните, что мы «начинаем с малого» и создаем минимально жизнеспособный продукт, не означает, что у нас нет потенциала для значительных усилий.
Возможно, вам понадобится:
- Приобретайте виртуальные машины Linux для промежуточных узлов, сред разработки и серверов приложений.
- Создайте / настройте инструмент CI / CD, такой, как Jenkins.
- Настройте локальный сервер Git для хранения вашего кода, конфигураций и любых других данных, требующих контроля версий.
- Проведите инвентаризацию устройства или Источника истины, например NetBox.
- Настройте сервер Ansible AWX для выполнения созданных вами сценариев.
Это не обязательно тривиальные шаги, в зависимости от вашей организации и имеющихся в ней навыков. Ориентация на небольшую группу устройств в вашем MVP и четкое определение требований позволит вам сосредоточиться на приобретении любых новых необходимых навыков по мере создания этой инфраструктуры.
Масштабирование быстро
Когда вы создали инструментальные средства для успешного управления портами коммутатора на вашей первоначальной партии устройств, вы можете начать расширять свою область действия, включив в нее дополнительные туалеты / этажи / здания во все возрастающих партиях. Я обнаружил, что, начиная с группы из 10–15 устройств и примерно удваивая это общее количество каждый раз, когда вы чувствуете себя комфортно для автоматизации против большего количества устройств, можно быстро передать даже самые большие группы устройств под управление инструментария NetDevOps.
Такая итеративная работа помогает укрепить уверенность в своих инструментах и инфраструктуре не только от вас самих или своей команды, но и от бизнеса в целом. Все слышали ужасную историю о том, что автоматизация сети вышла из-под контроля и обрушила бизнес, и эта организация клянется никогда больше не пробовать автоматизацию. Начав с малого и создав хорошо протестированный и заслуживающий доверия MVP, вы можете начать завоевывать доверие даже среди самых решительных ИТ-директоров.
MVP Включить тесты
Предположим, вы настроили инструменты для автоматического применения известной «золотой» конфигурации к портам коммутатора ваших пользователей; однако новая версия операционной системы сетевого устройства использует немного другой синтаксис. Откуда вы знаете, что это проблема, прежде чем нарушить доступ к сети для тысяч пользователей? Тестирование, тестирование, тестирование !
Даже если вы создаете что-то простое и небольшое, вы должны включать тесты как на уровне кода (модульные тесты), так и на уровне сети (интеграционное тестирование). Наличие хорошо продуманного, автоматизированного и полностью реализованного плана тестирования абсолютно необходимо для того, чтобы можно было доверять вашей инфраструктуре, процессам и рабочим процессам NetDevOps. Без тестирования вы просто надеетесь, что в вашей сети ничего не изменится, и все мы знаем, что это просто принятие желаемого за действительное.
Минимально жизнеспособный продукт
Построение решения с самого начала, как описано выше, может выходить за рамки вашего текущего набора навыков. Даже если у вас есть навыки или опыт, это может оказаться больше, чем у вас есть на все сразу. Разбив его на целенаправленные функциональные части и работая над минимально жизнеспособным продуктом, вы сможете быстро реализовать функциональность и быстро накапливать навыки на этом пути. На практике иногда это может быть не так четко, и вам, безусловно, может потребоваться скорректировать свои цели или задачи и увеличить масштаб проекта.
Имейте в виду, что даже если вам нужно умеренно увеличить масштаб вашего проекта за пределами первоначально запланированного MVP, вы все равно будете обеспечивать целенаправленный и успешный результат с измеримой ценностью для вашего бизнеса. После того как вы докажете свою эффективность NetDevOps своему бизнесу в целом с помощью минимально жизнеспособного продукта, они будут более склонны доверять вам автоматизацию более крупных и важных частей сетевой среды.