Начнем издалека. С момента появления сложных механизмов и систем не прекращается поиск оптимальной формы взаимодействия с такими системами, которая позволит, с одной стороны, полностью задействовать доступные возможности, с другой – максимально упростить это самое взаимодействие. Практически сразу стало очевидно, что две указанные цели почти всегда равны по важности, но противоположны по направлению – получить то и другое одновременно трудно, а зачастую невозможно. Современные телекоммуникационные сети как один из вариантов сложных систем с момента своего появления во второй половине ХХ в. продолжают искать этот трудноуловимый баланс.
В последние 20–30 лет сложились определенные стандартные практики, набор технологий и рынок решений для взаимодействия с сетевой инфраструктурой. Задачами такого взаимодействия традиционно считают автоматизацию процесса внедрения сетевой инфраструктуры и сетевых услуг, а также задачу оценки состояния сети или в привычных терминах – мониторинга. Здесь можно отметить возникшее многообразие различных систем класса NMS (Network Management Systems), которые отчасти решали поставленные выше задачи, но почти никак не адресовали задачу «сеть как платформа». А знакомая всем сетевым инженерам «командная строка» остается насколько функциональным, настолько же сложным интерфейсом управления.
На фоне этого мы наблюдаем другие факторы, влияющие на вектор развития сетевого управления. Сети перестали быть просто транспортом для информационного трафика, а все чаще воспринимаются и, что важно, используются как платформа для цифрового бизнеса. Ожидания бизнеса от сетей изменились, а сети в большинстве своем – нет.
Одним из таких ожиданий стало радикальное увеличение скорости внесения изменений в сеть. Еще десять лет назад никого по большому счету не волновало (в разумных пределах, конечно), сколько уйдет времени, например, на внедрение новых политик качества обслуживания на существующей сети: все, что укладывалось в «часы» или даже «дни», воспринималось как норма. К счастью или к сожалению, сегодня это уже не может быть нормой для большинства заказчиков с цифровой формой бизнеса.
Это подводит нас к концепции интенционно-ориентированных (англ. intention – намерение) сетей или, формулируя иначе, сетей, транслирующих бизнес-намерения в необходимые изменения сетевых настроек. Что такое намерение и как оно формулируется? Источником намерения можно считать любую внешнюю (по отношению к сети) систему или приложение, способное сформулировать свое намерение понятным для сети образом. В реальной жизни таким источником может быть бизнес-приложение заказчика, которое активно использует сеть для формирования цифрового продукта или услуги. Получателем намерения может являться как сама сеть, так и (что более вероятно и целесообразно) система управления сетью, которая, очевидно, становится ключевым элементом такой архитектуры.
Отсюда первое принципиальное отличие сетей нового типа от традиционного подхода на основе NMS: намерение подразумевает обязательный контроль его выполнения, а для этого должна существовать некая обратная связь, позволяющая оценить, насколько полученный результат соответствует первоначальным ожиданиям бизнес-приложения. Развиваем идею дальше. Обратная связь должна позволять автоматизированно предлагать и вносить корректирующие воздействия, если результат оказался несоответствующим, обеспечивая тем самым процесс, который можно назвать замкнутым циклом автоматизации. Здесь многие читатели могут вспомнить концепции саморегулирующихся систем и цепей. И вот сегодня мы подходим к состоянию, когда похожие принципы становятся необходимыми для сетевых инфраструктур.
Итак, в общих чертах мы обозначили ожидания и граничные условия в отношении интенционно-ориентированных сетей. Теперь попробуем разобраться, как может выглядеть решение, реализующее такой подход.
Первое, что нас должно заинтересовать: как оптимально сформулировать и передать намерение от бизнес-систем к сети? Вариант графического интерфейса отпадает сразу – хорошо для оперативного управления, но слишком медленно и не автоматизировано с точки зрения внешней бизнес-системы. Вариант командной строки тоже не подходит в силу своей сложности и явной ориентированности на взаимодействие с человеком, а не с приложениями. Остаются различного вида программные интерфейсы API.
Выбранный (или даже разработанный специально!) API должен поддерживать транзакционность, быть стандартизованным (хотя бы на уровне транспорта и синтаксиса), поддерживать асинхронность выполнения команд-намерений и быть функционально расширяемым. Пожалуй, самое главное требование к API – оптимальный уровень абстракции. Абстракция в данном случае подразумевает, насколько обобщенно мы можем сформулировать задачу, не спускаясь до деталей настройки и возможностей конкретных сетевых элементов, и при этом сохранить все нюансы нашего «намерения». Недостаточный уровень абстракции потребует значительных интеграционных усилий, а чрезмерный – ограничения в функционале.
Перечень требований для API можно продолжать, но индустрия в целом единодушна: лучшее, что смогли придумать для интенционного типа взаимодействия, − это стандартный интерфейс на основе REST и драфт-протокола RESTconf. Анализ возможностей REST позволяет довольно быстро понять, что предложить бизнес-приложению API, который будет формулировать запросы в формате, сходном с человеческим общением, насколько желательно, настолько же неэффективно. Вывод: процесс интеграции бизнес-систем с интенционно-ориентированной сетью – процесс двусторонний, в котором одинаковую заинтересованность должны иметь и бизнес, и ИТ-подразделения. Несмотря на красивую концепцию бизнес-намерения, разработчикам все же придется учитывать возможности и логику доступного сетевого API в своих приложениях.
Далее, сеть, предлагающая бизнес-приложениям свой API «намерений», должна отвечать ряду вполне конкретных требований. Как было отмечено, приложениям нет смысла взаимодействовать с каждым элементом сетевой инфраструктуры – такой подход элементарно не масштабируется. Поэтому точкой применения «намерения» должна выступать централизованная система автоматизации жизненного цикла сети. Такая система должна обеспечить получение и обработку «намерения» через API, а кроме того, трансляцию «намерения» в настройки всех сетевых элементов, на которые распространяется данное «намерение» и – главное − только на них. Здесь есть неочевидный, но крайне важный аспект: система автоматизации должна иметь возможность корректно оценить сферу применения «намерения». Например, если задача состоит в том, чтобы изменить SLA обслуживания для определенной группы пользователей, то система автоматизации должна «знать», к каким элементам инфраструктуры необходимо применить изменение сетевых политик в данный конкретный момент времени, а для этого, в свою очередь, нужно знать, к каким элементам подключены пользователи из указанной группы. Это становится возможным, в случае если система автоматизации эффективно реализует управление на основе контекстов.
Попытка найти адекватное и точное описание слова «контекст» приводит нас к Википедии (https://ru.wikipedia.org/wiki/Контекст ). Приведу пару ключевых выдержек:
- Конте́кст (от лат. contextus − «соединение», «связь») − законченный отрывок письменной или устной речи (текста), общий смысл которого позволяет уточнить значение входящих в него отдельных слов, предложений и т. п.
- Контекст − среда, в которой существует объект.
Примеряя такое описание на сеть, можно сформулировать смысл контекста как сетевого элемента, объекта, клиента, устройства и т. п. вместе со всеми элементами сетевой среды, с которыми этот объект взаимодействует на основе любого вида логических или физических связей. Другими словами, контекст полностью описывает окружение сетевого объекта и все его взаимосвязи с этим окружением.
Почему использование контекстов важно для интенционно-ориентированной системы автоматизации? Использование контекстов и контекстного анализа не только позволяет сразу определить сферу применения того или иного бизнес-намерения, но и дает возможность так же быстро и эффективно соотнести текущее (а иногда и будущее!) состояние сетевой среды по сравнению с ожидаемым состоянием. Если же возникают какие-то нештатные ситуации в сети, отслеживание каждого доступного контекста в сети в режиме, близком к реальному времени, позволяет системе автоматизации эффективно определить как корневую причину возникшей проблемы, так и то, какие участники сетевого обмена были затронуты этой проблемой и в какой период времени. Можно пойти еще дальше и расширить применение контекстов на сетевые приложения и клиенты, учесть при этом все динамически возникающие взаимосвязи и даже начать анализировать тенденции и аномалии, возникающие в отношении тех или иных сетевых контекстов, что может предупреждать о негативных тенденциях или аномалиях, которые еще не стали проблемой, но могут таковыми стать в ближайшем будущем. Здесь, конечно, понадобятся продвинутые технологии машинного обучения, но важно то, что все это становится возможным, если система автоматизации активно использует контекстный анализ. Это в определенном смысле Святой Грааль для традиционных систем мониторинга.
Справедливости ради отметим, что у интенционно-ориентированного подхода есть ряд отрицательных и положительных побочных эффектов. К отрицательным следует отнести необходимость изменить общий подход и культуру по управлению сетью, которые формировались не один десяток лет. Так, если позволить приложениям формировать «намерение» и при этом стараться полностью или частично сохранить все остальные привычные механизмы взаимодействия с сетью (CLI, традиционные NMS), то проблем не избежать. Интенционно-ориентированная система автоматизации в общем случае, скорее всего, не сможет корректно учесть изменения сетевых политик и настроек, совершенных параллельно через традиционный интерфейс взаимодействия. А если и сможет, то это явно повлияет на скорость обнаружения нежелательных сетевых изменений или нарушений политик. Другое негативное последствие − возможные ограничения в реализации целевой сетевой политики. Речь о том, что в традиционной сетевой среде такие задачи, как, например, сегментация, контроль доступа, обеспечение качества обслуживания и процесс подключения новых клиентов к сети, могут быть достигнуты несколькими вариантами сетевых настроек. Интенционно-ориентированная система в большинстве случаев позволит реализовать все те же задачи, но осуществит сетевые настройки оптимальным, с точки зрения вендора-производителя системы, образом, не оставляя тем самым пространства для маневра ИТ-подразделению. Но у этого «минуса» есть и обратная сторона: такой подход позволяет обеспечить полную унификацию конфигураций сетевых устройств для однотипных бизнес-намерений и свести к минимуму вероятность банальной человеческой ошибки при очередном внедрении того или иного сервиса, что очевидно положительно повлияет на стабильность и надежность сети, а также на возможности быстрого поиска причин отказов, если таковые возникнут. Иными словами: мы значительно снижаем риски, связанные с надежностью и безопасностью сети.
Что в итоге? Современный цифровой бизнес все чаще смотрит на сеть как на платформу для своих продуктов и услуг, а интенционно-ориентированные сети действительно отвечают новым, зачастую непривычным требованиям бизнеса и при этом обладают рядом дополнительных и уникальных возможностей, недоступных для традиционных систем автоматизации. Очевидно, внедрение и использование систем на основе намерений требуют от ИТ и бизнеса определенных усилий, в том числе изменения сложившейся в индустрии культуры взаимодействия с сетью. Но эти усилия обещают быстро окупиться, так как выявляют самые важные на сегодня вопросы на стыке интересов ИТ и бизнеса.
