Подписаться
Читать в телеграм
Что такое DevOps/NetOps? Объясняем на автомобилях.
Когда компаниям необходимо DevOps/NetOps-решение?
Как мы разрабатывали собственный продукт?
Оживленная беседа в кабинете № 625
Заходишь в первую проходную длинного, кажется нескончаемого, здания на Большой Новодмитровской, 14. Тебя встречает уже знакомое лицо охранника за вертушками. Ныряешь налево — и вот ты у лифтов, прыгаешь в один из них.
Выходишь, идешь быстрым шагом по коридору, почти до упора. По правую руку видишь кабинет № 625. В нем происходит, наверное, самое хаотичное (в хорошем смысле этого слова) действо в центре сетевых решений — пресейл и продвижение.
Одинаковых пресейловых активностей, как и одинаковых проектов, не бывает. Это накладывает свой отпечаток на людей, которые задействованы в этом процессе. Со временем любой пресейл-инженер или BDM начинает походить на художника или писателя. Он ищет все новые варианты, подходы, решения, мозг трансформируется и начинает работать по-другому. Во взгляде человека уже видны сумасшествие и невозможность остановиться.
Кабинет № 625 наполнен именно такими людьми, и разговоры в нем имеют характерную окраску. Каждый из них — это битва и поиск: лучшего решения, технологии, способов продвижения, идей для стартапов (куда без этого). Любая новость в сообществе провоцирует бурное обсуждение или спор.
Тема цифровизации, а с ней и автоматизации процессов тоже не прошла мимо нас. Ох, знали бы вы, сколько побочных бизнес-идей родилось на этой волне. А главное — они были совершенно живыми и рабочими (дайте нам уже наконец инвестора 🙂 ).
Об одной из таких идей, которая в итоге воплотилась в собственный продукт, и пойдет речь в этой статье.
Сетевики — это новые программисты
Как говорил в свое время древнегреческий философ Гераклит: все течет, все меняется. Центры обработки данных давно перестали быть «серверными помещениями», в современных реалиях ЦОД — это основной ресурс для разработки новых продуктов компании.
Требования к Time-to-Market ужесточаются от года к году, ИТ-подразделение должно обеспечивать поддержку бизнеса на лету. Cетевиков это касается в полной мере: они ищут и изучают инструменты для повышения скорости и удобства своей работы, чтобы оперативно собирать информацию с оборудования. Например, нужны данные для разработки проектного решения: список IP-интерфейсов, начинающихся с определенных адресов, конфигурационные файлы, информация из таблиц маршрутизации и т.д. Классические инструменты мониторинга — это долго и неудобно. Нужны скрипты, которые избавят специалистов от рутины. Так сетевики отчасти становятся программистами.
Если ИТ-инфраструктура компании насчитывает более 100 серверов и 1000 виртуальных машин, при этом каждый день появляется несколько заявок на внесение корректировок в сеть, вручную инженеры не справятся. Высокая скорость изменений — один из основных драйверов использования DevOps/NetOps-решений.
Мы и до 2021 г. достаточно часто применяли написанные на Python скрипты и Ansible-библиотеки, чтобы облегчить процесс настройки и сбора информации с оборудования. Мы осознавали, что рано или поздно нас накроет волна DevOps/NetOps.
DevOps/NetOps — это подход, подразумевающий применение принципов и моделей DevOps к работе с сетями. Он позволяет разделить рабочий процесс на более короткие, быстрые спринты и заметно ускоряет рутинные операции — к примеру, установку обновлений и патчей.
Суть DevOps/NetOps
DevOps/NetOps — это комплекс инструментов и подход к управлению сетевой инфраструктурой. Представьте, что вы покупаете автомобиль у официального дилера, но можете приобрести его только в базовой комплектации: без красивых литых дисков, крепления для сноуборда, мощного сабвуфера и светло-коричневого кожаного салона. Вы наверняка будете расстроены. При этом есть автоателье, специалисты которого имеют опыт модернизации дефолтных машин под нужды и желания автовладельцев. Так и DevOps/NetOps предполагает максимальную кастомизацию сетевых решений под инфраструктуру компании. Чтобы понять, в чем главное преимущество этого подхода, нужно разобраться, как он работает.
Дано
Нужно оперативно настроить новый сервер, у которого будет доступ к определенному набору уже существующих серверов или виртуальных машин.
Классический подход к построению сети
Если делать все по старинке, придется создавать заявку в службу эксплуатации сети. Специалисты подключатся к каждому устройству и проверят их на наличие свободных ресурсов. Затем начнут создавать отдельную конфигурацию для нового сервиса и задавать определенные значения. Это необходимо сделать по цепочке на каждом устройстве. На все про все может уйти несколько дней.
Кроме того, подобные операции часто приводят к ошибкам, поэтому во многих компаниях их разрешено проводить только в «технологическое окно». Вкупе со сложной процедурой согласования это еще больше затягивает процесс.
Решение DevOps/NetOps
Подход DevOps/NetOps позволяет сразу узнать, есть ли в сети свободные ресурсы, и одним кликом развернуть необходимый автоматизированный процесс. К вечеру этого же дня можно будет протестировать связь на конечных точках, а на следующий — устанавливать сервер. Проверить работоспособность скрипта нужно будет только один раз, после этого его можно применять многократно. В результате риски остановки системы снижаются, согласования ощутимо упрощаются, а весь процесс ускоряется в несколько раз.
Собственный продукт? С чего вдруг?
У сетей есть отраслевая специфика: например, в финсекторе их архитектура почти всегда типовая, а перечень операций по сборке и настройке чаще всего идентичен. Возникает закономерный вопрос: почему бы не автоматизировать повторяющиеся операции? Для заказчиков это будет удобно, а для нас как для интегратора выгодно в плане сокращения издержек.
Одним из основных триггеров запуска внутреннего проекта по DevOps/NetOps стал тендер на доработку ПО крупного телеком-оператора.
На подобные решения уже есть спрос. Яркий пример — тендер российского телеком-оператора на десятки миллионов долларов. Заказчик сразу обозначил, что не хочет видеть у себя стандартные вендорские продукты для сетевой автоматизации и предпочитает решения DevOps/NetOps. Разработка такого функционала была четко прописана в конкурсном ТЗ. Этот тендер стал отправной точкой для разработки нашего DevOps/NetOps-решения.
НА ЗАМЕТКУ
Стоит ответить на закономерный вопрос: почему бы просто не использовать готовые вендорские решения? Во-первых, это дорого. Во-вторых, коробочные решения хороши, когда у вас моновендорный ЦОД, в котором нужно автоматизировать стандартные процессы. В противном случае придется ставить сразу несколько систем для сетевой автоматизации под решения разных производителей. К тому же их нужно будет интегрировать между собой с помощью подхода DevOps/NetOps или вручную.
Производители большинства коробочных решений стараются максимально доработать графический интерфейс своих систем. Они добавляют большое количество Dashboard, стараются показать пользователю внушительное число HealthCheck по различным сущностям внутри сетевой фабрики. Все это выглядит действительно красиво, но проработка этих блоков требует внушительных финансовых вложений. Подключаются дизайнеры интерфейса, анализируется и прорабатывается Customer Journey Map.
Также коробочные продукты от крупных производителей щеголяют возможностями ИИ: аналитика потоков трафика, превентивные меры по исправлению проблем на сетевой фабрике и т.д. Такие решения зачастую требуют подключения облачных вычислительных мощностей.
Или это может быть On-Premise-система, включающая несколько высокопроизводительных серверов. Для заказчика это означает потенциальные риски утечки данных (для облачного сценария) или возрастание стоимости решения (для On-Premise). При этом реальных сценариев бизнес-применения такого продукта заказчики пока не видят.
Великолепная четверка
Для создания магического фосфоресцирующего зелья под названием DevOps/NetOps нам понадобились следующие ингредиенты: владелец продукта, архитектор, разработчик и менеджер проекта.
Перед командой стояла задача создать продукт, который позволит автоматизировать развертку сетевой инфраструктуры без дублирования или «разрушения» существующего решения заказчика. Кроме того, в ПО нужно было заложить возможность доработки под оборудование любого вендора.
При разработке функционала MVP мы частично отталкивались от задач, стоявших перед телеком-оператором. Примеры приведены в табл. 1.
Итак, владелец продукта формулировал бизнес-задачу и обеспечивал back-log.
Архитектор формировал архитектуру ПО и ставил техническую задачу разработчику.
Разработчик создавал, сращивал и дорабатывал программные модули продукта.
Менеджер проекта координировал работу нашего стартапа и следил за тем, чтобы мы не пили слишком много смузи ;).
В результате синергии интеллектуальных способностей магов DevOps/NetOps за три месяца родился MVP. В его основу легли открытые инструменты — библиотеки Ansible и Python. Для работы ПО не требуются высоконагруженные БД, оно может быть развернуто и в классической, и в контейнерной микросервисной инфраструктуре.
Решение проверялось на оборудовании Cisco и Huawei. При этом наш продукт совместим с любым оборудованием заказчиков: библиотеки Ansible поддерживают практически все производители.
Jet DCF Automation. Система автоматизации управления сетевым оборудованием
Чтобы организовать в сети большого ЦОДа сегменты канального/сетевого уровня, обеспечить передачу и фильтрацию данных, на многочисленных устройствах нужно провести одинаковую настройку bridge domains, VRF, VXLAN, VLAN и т.д. Интерфейс MVP позволяет синхронно вносить эти изменения с помощью мастеров для настройки оборудования (рис. 1) и тем самым предотвращает ошибки администраторов.
Наше решение быстро встраивается в сетевой ландшафт — считывает с устройств существующие VLAN ID, VNI, bridge domain ID и работает с ними. Решения вендоров же строят свою собственную инфраструктуру, внося новые конфигурации в сетевое оборудование, стирая существующие предустановки. Поэтому в таких случаях нужен отдельный проект по миграции существующей сети и сервисов заказчика, который может длиться до нескольких недель.
Возможны несколько вариантов принудительного переконфигурирования сетевого оборудования. Например:
1. Для использования в SDN-ЦОД конфигурация коммутаторов полностью заменяется (переписывается) SDN-контроллером. Часто на коммутаторы инсталлируется специальный софт, не допускающий возможности ручной настройки администратором сети. То есть администратор все делает через интерфейс контроллера, а доступ к отдельным коммутаторам урезан и ограничен.
2. Конфигурация коммутаторов не переписывается, на них установлен обычный софт, но контроллер SDN загружает в коммутаторы свой набор логических сущностей (VLAN, VXLAN, VRF, bridge domain) в дополнение к уже настроенным.
Одно из несомненных преимуществ DevOps/NetOps — возможность управлять оборудованием нескольких вендоров из единого окна.
Этапы доработки MVP под задачи заказчика
В случае с MVP потребуется около 100–150 человеко-дней, чтобы разработать полноценное ПО, автоматизирующее 3–4 операции в сети заказчика. Это будет менее болезненно, чем ставить коробочное вендорское решение, поскольку мы не будем «ломать» или дорабатывать сетевую инфраструктуру, а постараемся в нее бесшовно встроиться.
Наш MVP придется по вкусу крупному бизнесу: операторам связи, банкам, а также промышленным компаниям и ритейлу. Примерная стоимость владения таким кастомизированным ПО в диапазоне 5 лет — порядка 80 000 долл. В случае с коробочным продуктом на круг выйдет около 130–250 тыс. долл.
Преимущества MVP
Бизнесовые
- Стоимость владения решением в диапазоне 5 лет в 2–3 раза ниже по сравнению с вендорским продуктом.
- Время настройки сети снижается с нескольких дней до часов.
Технические
- Бесшовная интеграция в ИТ-ландшафт.
- Возможность развертки и в классической, и в контейнерной ИТ-инфраструктуре.
- Совместимость с любым оборудованием (в основе ПО лежат библиотеки Ansible, которые поддерживают практически все производители).
- Управление оборудованием нескольких вендоров из единого окна, синхронная настройка сетевых устройств.
