В этом разделе рассмотрим концепции и компоненты более высокого уровня, необходимые для построения успешной платформы сетевой автоматизации. Я хочу выделить здесь несколько разделов и моментов.
Человеческое и деловое взаимодействие
Инструменты и технологии, которые попадают в этот раздел, предназначены для непосредственного предоставления интерфейсов автоматизации, которую мы создаем для сети. Это такие вещи, как наши приложения для управления ИТ-услугами (ITSM), а также платформы для чата и общения. ChatOps — это термин, который часто используется в отрасли и продолжает набирать обороты в автоматизации сетей. Интеграция с чат-платформами позволяет бизнесу передавать сетевые данные и рабочие процессы в каналы, по которым уже ведутся разговоры. Возможно, что еще более важно, эти возможности позволяют сделать автоматизацию нашей сети доступной для заинтересованных сторон вне сетевых групп напрямую.
Управление данными
Если бы я выбрал один-единственный раздел в своем выступлении, чтобы назвать его наиболее важным, это был бы этот раздел. Что касается автоматизации сети, то в отрасли недостаточно говорится о данных. Как и в любой другой вертикали в технологическом пространстве, данные лежат в основе всего, что мы делаем, и автоматизация сети не исключение. По мере роста сообщества автоматизации сети появляется понимание концепции использования Источника истины (SoT), который является авторитетной системой записи для определенной области данных. Эта последняя часть является ключевой, потому что на самом деле мы можем (и реально имеем) иметь несколько источников истины, которые не пересекаются. Например, наши IPAM и DCIM могут быть разными системами, потому что они управляют разными доменами данных. Это действительно до тех пор, пока у нас не более одного инструмента IPAM или DCIM, поскольку именно отсюда происходит фраза «Единый источник истины»,
Тем не менее, наличие множества различных систем создает собственные проблемы. На первом этапе каждой системе в нашем наборе инструментов для автоматизации сети потенциально потребуется ссылаться на множество различных систем, чтобы получить данные, необходимые для выполнения автоматизации. Что еще более важно, это тесно связывает клиента с источником данных и форматом. Чтобы бороться с этим, мы стремимся реализовать уровень агрегации между источниками истины и системами, потребляющими их данные. Эта агрегация служит нескольким важным сценариям использования.
Во-первых, он создает единую стеклянную панель для доступа ко всем данным из наших различных авторитетных систем, что позволяет нашим инструментам ссылаться на одно место. Во-вторых, агрегатор реализует уровень трансляции данных, который преобразует данные, поступающие из каждого источника с истинным значением, в абстрактную модель данных. Эта модель данных намеренно удаляет любые особенности данных или их структуры, которые делают их идентифицируемыми с любым поставщиком или исходной реализацией.
При этом мы переходим к третьему пункту, который заключается в том, что агрегатор взаимодействует с различными источниками настоящих систем подключаемым способом. Реализуя адаптер, агрегатор понимает данные и формат, поступающие из отдельного источника истинного значения, и способы преобразования данных в соответствии с абстрактной моделью данных. Это позволяет агрегатору легко реализовать поддержку различных источников реальных платформ, так что они могут быть заменены в любое время. Если вы хотите сменить поставщика IPAM, все, что вам нужно сделать, это создать (или взаимодействовать с NTC) адаптер для агрегатора, который понимает, как выглядят данные, поступающие из нового IPAM.
Мониторинг, оповещение и видимость
Может показаться немного странным говорить о мониторинге и предупреждениях в контексте автоматизации сети, но мы делаем больше, чем просто управление конфигурацией. Фактически, суть этой темы сосредоточена вокруг концепции «автоматизации с замкнутым циклом» или создания контура обратной связи в платформе автоматизации, которую мы создаем. В видео вы услышите, как я говорю о платформе автоматизации как о стеке, и с одной стороны мы перемещаемся вниз по стеку к реальной сетевой инфраструктуре, но с другой стороны, события выходят из сети и возвращаются вверх по стеку. . Действительно, эти события приходят в традиционных формах опроса SNMP, сообщений системного журнала и т. Д. Они также могут иметь новые формы, такие как показатели временных рядов и потоковая телеметрия. Мы также пересмотрели уровень хранения и обработки, чтобы реализовать более современные базы данных временных рядов, которые позволяют помечать точки данных метками метаданных, что открывает двери для более интеллектуальных запросов и визуализации. Говоря о визуализации, мы хотим предоставить заинтересованным сторонам бизнеса сетевые данные, и мы хотим делать это в режиме самообслуживания с помощью современных инструментов панели мониторинга. Опять же, это случай предоставления бизнесу сетевых данных и рабочих процессов.
Возвращаясь к механизму хранения, нам нужно вывести эти сетевые события из их разрозненных хранилищ для мониторинга и передать обратно в платформу автоматизации. Мы делаем это с помощью механизмов обработки правил, которые утверждают бизнес-логику на основе метаданных, которые прикреплены к собранным точкам данных. Как только потоки событий возвращаются в нашу платформу сетевой автоматизации, наша петля обратной связи начинает обретать форму. Теперь мы можем создавать автоматизированные рабочие процессы исправления, которые позволяют инженерам сосредоточиться на реальном проектировании и архитектуре, а не на устранении неполадок и устранении известных повторяющихся событий. В ситуациях, когда необходимо участие человека, платформа может, по крайней мере, собирать важный контекст из сети в качестве формы сортировки первого уровня,
Операционные модели
Последняя тема, которую я хочу затронуть, — это идея о том, что ни одна платформа автоматизации сети никогда не сможет удовлетворить потребности всех сетей и организаций. Более важные выводы из этого выступления — различные компоненты, которые входят в архитектуру платформы, которая наилучшим образом соответствует вашим потребностям. Это правда, что компания A может иметь возможность приобрести готовый продукт автоматизации у поставщика и быть совершенно счастливой, в то время как компании B может потребоваться полностью индивидуальное решение в течение более длительного периода эволюции.