Спикер: Ушанов Илья, генеральный директор Gelarm. Компания Gelarm была основана в 2017 году. Сейчас в штате 17 человек. Часть команды находится в Москве, часть - в Пензе. Основные направления деятельности - это разработка программных продуктов для зонтичных систем мониторинга и хранилищ данных.
Команда начала собираться в 2008 году. И с 2008 года мы занимались разработкой зонтичных систем мониторинга и управления. В основном это были продукты компании IBM. Но также мы плотно поработали с Hewlett Packard, c Open Source решениями.
Если выделить наиболее интересные проекты, начатые после 2008 года, то среди них надо отметить построение зонтичной системы мониторинга для Мегафона на продуктах IBM. Покрывались все регионы РФ и все сегменты, в том числе и транспортный. Точно такой же по масштабу проект был реализован в компании Вымпелком, чуть меньший проект был реализован в компании Tele 2, в связи с тем, что у них инфраструктура попроще, т.к. у них транспортные каналы арендованы. Очень интересный проект мы реализовывали для ЦОДа. Мы организовали зонтичную систему мониторинга, которая по модели SaaS продавалась потом клиентам ЦОДа.
На основании накопленного опыта в 2017 году нашей командой было принято решение основать компанию и начать разработку собственных продуктов. У нас накопилось много опыта, хотелось этот опыт реализовать далее, но было трудно делать это в вендорских решениях. Мы вышли с инициативой к нашему руководству по разработке ПО, но, к сожалению, она не была поддержана, и поэтому в 2017 году мы создали собственную компанию, ушли в свободное плавание. На тот момент нам было страшновато, потому что мы уходили без конкретных клиентов, не понимали, как мы будем продавать, кому будем продавать наши продукты. Просто нам очень хотелось реализовать то, что мы себе нафантазировали, и то, что мы понимали, что можно сделать лучше.
В 2018 году была реализована первая версия нашего продукта GIMS Automation. Это один из модулей линейки GIMS. В 2019 году были реализованы первые версии GIMS Inventory и GIMS Monitoring. Какую задачу мы ставили перед собой изначально? Мы хотели сделать зонтичную систему мониторинга. Мы понимали, что эта система должна состоять из трех основных слоев. Это система инвентаризации. Нам в любом случае нужно было сделать собственную систему инвентаризации. Это модуль обработки событийной информации - модуль GIMS Monitoring. И модуль обработки метриковой информации. Чего нам очень не хватало в вендорских крупных продуктах, которые мы до этого использовали? Не было инструмента, который бы позволял в одной точке централизовано управлять процессами сбора событий, сбора метрик, интеграции системы инцидент-менеджмента, интеграции с плановыми работами, реализации процессов корреляции и т. д. и т. п. И этот инструмент мы реализовали. Это GIMS Automation. Он является центральным звеном всех наших продуктов. Он связывает все компоненты между собой и с внешней инфраструктурой заказчика.
Сейчас в линейку GIMS входят три продукта: GIMS Automation, GIMS Monitoring и Gims Inventory. Все три продукта бесшовно интегрируются между собой, сводятся в единый интерфейс, и, соответственно, процессно очень легко между собой интегрируются. GIMS Automation является центральным звеном, которое обеспечивает всю процессную часть связей с инфраструктурой заказчика. Это такие связи, как сборки событий от программного обеспечения, это интеграция системы инцидентов менеджмента, либо это получение данных из инфраструктуры заказчика, из источников, с тем, чтобы можно было переложить их куда-то дальше. И также GIMS Automation обеспечивает взаимосвязь компонентов между собой. В частности, GIMS Monitoring и GIMS Inventory для задач корреляции, когда мы на основании логического графа, который в Inventory хранится коррелируем события в специальной базе.
Посмотрим, как продукты применяются в рамках решений. Рассмотрим два решения: зонтичную систему мониторинга. Но полтора года назад мы открыли для себя новую нишу, где наши продукты также применимы. Это построение корпоративных хранилищ данных.
Начнем с зонтичных систем мониторинга. Основные задачи построения зонтичной системы мониторинга. К сожалению, мы часто сталкиваемся с тем, что многие к мониторингу относятся как к светофору. На стены вывели красивые картинки, посадили людей, которые разглядывают эти картинки. И когда где-то что-то замерцает, они решают, что с этим делать.
Сейчас мы с вами рассмотрим применение этих продуктов в рамках решений зонтичной системы мониторинга. Основные задачи, которые стоят перед нами при реализации зонтичных систем мониторинга это автоматическая инвентаризация инфраструктуры. Этот момент многие заказчики при построении системы мониторинга упускают, к сожалению. Невозможно построить качественный мониторинг без качественной системы инвентаризации. Если у вас нет инвентаризации, то единственное, что вы сможете добиться от мониторнинга, это действий, схожих с работой светофора. Он будет мерцать красными лампочками, но никакой автоматизации в работе техблоков вы не получите. Потому что нам важно, чтобы мониторинг получил огромные потоки событийной информации и затем по инвентарному графу вывел корневую причину. Т.е. если у нас падает, например, какой-то граничный маршрутизатор, чтобы мы понимали, какое оборудование за этим маршрутизатором. У нас упал маршрутизатор, а в результате мы получили 100 событий. И система мониторинга должна автоматически понять, как связано оборудование между собой по инвентарному графу и выявить корневую причину. И только когда этот процесс реализован, можно уже реализовывать процесс автоматического заведения инцидента. Почему крупные компании такие, например, как Мегафон, не могут себе позволить зонтичную систему мониторинга устроить как светофор? Потому что у них огромные потоки событий, сотни миллионов событий в сутки. 70% событий поступает днем. И только 30% ночью. И такие объемы невозможно перерабатывать вручную. Здесь необходима автоматическая обработка.
Многие заказчики пытаются к корреляциям событий подойти сразу. Не следует коррелировать сразу. Как показывает практика, в зависимости от специфики бизнеса банкинг это или телеком, или энергетическая компания, как правило есть набор корреляций, порядка 5-6, они закрывают 90% основных возникающих событий.
Также зонтичная система мониторинга должна позволять контролировать производительность инфраструктуры. Нужно сначала построить хороший перфоманс мониторинг и только после этого переходить к этапу контроля.
И самая важная задача, которая стоит перед зонтичными системами мониторинга – это контроль качества сервиса. По двум основным показателям. Это технические показатели сервиса – работоспособность сервиса и качество его работы. И SLA.
Перейдем к компонентам. Основные особенности компонентов Gims Monitoring. Он состоит из двух подмодулей: GIMS FOLT – компонент для обработки событийной информации. Основные задачи состоят в обеспечении дедубликации событий и их корреляции. GIMS Perfomance – это хранение метрик производительности. Какие особенности мы закладывали при проектировании этих модулей. Во-первых, очень много времени посвятили разработке архитектуры кластеров. Потому что нам очень недоставало в IBM и Hewlett Packard хорошей горизонтальной масштабируемости. Т.е. для обработки событийной информации постоянно приходилось создавать отдельные агрегационные пары и разводить данные различные агрегационные пары и потом логически думать, как эти данные собрать. Мы же добились очень хороших показателей, у нас агрегационный слой может включать в себя до 64 серверов. Решение, которое мы разрабатывали больше двух лет, оказалось очень простым и изящным.
Еще один момент, который нас не устраивал, и мы сразу поставили перед собой цель, чтобы разворачивание компонентов всей инфраструктуры происходило из одного интерфейса и оно бы не требовало очень высокой компетенции. Потому что при реализации проектов мы до этого замучились с разворачиванием, постоянным обновлением. Когда у вас огромная инфраструктура, восемь регионов, в каждом регионе у вас по два-три коллектора. В составе каждого коллектора по 10 серверов, и постоянно это все разворачивать и обновлять крайне неудобно. Поэтому мы исходили из условия, что все компоненты у нас должны разворачиваться из единого интерфейса. И это должно быть легко. Чтобы не требовало большой экспертизы, установить какие-то пакеты, открыть фейервол, чтобы в системе изначально были заложены плейбуки, которые позволяли бы на установленные чистые ОС легко и просто все это вытаскивать.
На Gims Monitoring возложена задача определения состояния сервиса. Классический инструмент, позволяющий определять состояние сервисов. Также реализованы классические инструменты - это список событий. Здесь мы не придумали ничего особенного, мы взяли то, что годами отработано компаниями IBM и Hewlett Packard, т.е. классический список событий, который позволяет фильтровать события, настраивать представления событий, настраивать инструменты для автоматизации работы с событиями. Также классический инструмент для анализа метрик производительности, он позволяет проанализировать метрики, которые собираются по различным объектам инфраструктуры, посмотреть их показания, проанализировать динамику на временном отрезке.
Компонент Gims Automation. Здесь стояли такие же задачи, как и для всех других компонентов, т.е. обеспечить хороший уровень кластеризации и разворачивания. Чтобы все разворачивания происходили из единого web-интерфейса. Задачи, которые мы ставили по функциональности перед Gims Automation. Он должен решать задачи для интеграции с объектами мониторинга, различными системами управления, системами плановых работ, системами управления инцидентами. Т.е. любая интеграционная часть с инфраструктурой заказчика, либо внутренняя.
По функциям. Все по классике. Есть источники данных, ими может выступать все, что угодно. Это могут быть традиционные базы данных, файлы, менеджеры очередей, какой-то интерфейс и т.п. Причем, когда мы делали инструмент, мы понимали, что находимся в состоянии догоняющих. Многие крупные вендоры уже не первый десяток лет разрабатывали коннекторы к различным системам. И мы понимали, что нам необходимо создать удобный инструмент, который позволит заказчикам и нам самим легко разрабатывать новые типы источников данных. И мы в систему заложили конструктор источников данных, который, если заказчику чего-то недостает, позволяет ему либо обратиться к нам с тем, чтобы мы разработали новый тип источника данных, либо сделать это самостоятельно.
Сценарий автоматизации настраивается в режиме скрипта. Фактически у вас есть источники данных, у которых есть наборы методов, и мы, при помощи этих верхнеуровневых методов можем работать с данными из источников. Но сценарий пишется на языке Piton. Можно использовать упрощенный лоукод Piton, а можно полноценный Piton использовать. Что это дает заказчикам и нам? Мы можем быстро делать весьма сложные сценарии, потому что библиотек Piton написано очень много под различные задачи. И все эти библиотеки можно брать и использовать в рамках сценария включая GIMS Automation.
Триггер. Здесь была немного нестандартная концепция, которую мы выбрали. В рамках классических систем, либо классических шин данных, триггеры как правило представляют собой нечто такое, что инициирует запуск сценария. У нас это то же самое. Но у нас триггеры это более расширенные. У нас триггер выступает рестовой афишкой. Мы можем создать активатор типа HTP, и у нас на кластере опубликуется Rest. И происходит обращение на эту афишку, инициируется запуск сценария, из сценария происходит обращение к источникам данных, происходит обработка информации и обратно в афишку возвращается. Может быть классический триггер, тогда запуск осуществляется по времени какого-то сценария. Может быть интеграция с Telegram ботом. Т.е. у нас есть активатор Telegram бот. Когда приходит команда из Telegram бота, инициируется запуск сценария, он отрабатывает, результаты возвращаются обратно в Telegram бот. Т.е. это некое расширенное понятие инициатора процесса. Самое главное это то, что мы придумали удобный конструктор, который позволяет встраивать в систему и настраивать различные триггеры.
GIMS Inventory. Основные модули - это конфигуратор модели данных. Здесь мы добились очень интересных вещей. Теперь возможно построение шаблонов сервиса. Также мы добились того, чтобы у нас можно вести учет ложных связей, тогда мы можем строить слоеный пирожок. Когда у нас есть кабель, внутри кабеля есть логические каналы и т.д. Также реализована кластеризация. Кластеры поддерживают до 64 серверов.
Конструктор модели данных включает в себя объекты, связи, сервисы, работы со справочником. Т.е. это инструмент, который позволяет описать элементарные модели. Это не обязательно ИТ, можно описывать гораздо шире. И у нас есть хорошие примеры, когда мы очень широко описывали инфраструктуру, начиная от пожарной сигнализации и закачивая конкретными ботами, которые используются в той или иной конструкции.
Работа с объектами инвентаризации построена при помощи двух инструментов. В табличном виде то, что наиболее привычно, когда мы можем очень быстро найти объекты по различным атрибутам, отфильтровать, отредактировать и т.д. Ну и по классике - это топология, когда мы можем проанализировать связанность объектов между собой.
Конструктор сервисов позволяет в ручном режиме настроить структуру сервиса.
Когда строится корпоративное хранилище данных, нам необходимо реализовать перекладку данных из источников в это хранилище с последующей обработкой. Мы посмотрели на эту задачу чуть шире и увидели, что помимо интеграции хранилища с любыми источниками данных, стоит еще следующая задача: автоматическое документирование структуры хранилища. Когда источников становится очень много, порядка 50-100 и более, аналитикам и разработчикам необходим четкий и понятный граф, который собирается в автоматическом режиме, с тем, чтобы можно было посмотреть, как выглядит структура источника, структура хранилища, через какие интеграционные сценарии связаны те или иные источники и сущности хранилища. И важно, чтобы все это собиралось в автоматическом режиме. Если этого не обеспечить, возникают проблемы: недопонимание аналитиков и разработчиков, потому что аналитики разработали спецификацию на интеграцию, разработчики реализовали, но не совсем так.
Хорошо, если это вовремя обнаружили. Мы же добились такой возможности, чтобы система сама автоматически собирала информацию о структуре источника, о структуре хранилища. Простраивается структура сущности источника, с каким сценарием он взаимосвязан. Причем, из этого сценария мы видим методы, какие вызываются каждым из источников данных. И какие входные/выходные параметры. Все это заложено в системе.
Это первый момент с точки зрения логики. Дальше можно шире смотреть на это. Мы в элементарную модель можем также в автоматическом режиме загнать информацию не только о логической связи данных, но и о том, на базе какого оборудования работает это хранилище. Т.е. серверы, сетевое оборудование, как между собой взаимосвязаны, какие приложения и где установлены и на этом оборудовании. Т.е. получить полный граф функционирования хранилища.