Posted by 26 апреля 2024 года выпущен новый релиз (v.3.15.90) программной платформы мониторинга и управления цифровыми активами «Центральный Пульт» (SAYMON), разрабатываемой компанией «РОССИННО». В этом релизе традиционно были развиты и усовершенствованы отдельные функциональные возможности, элементы базового веб-интерфейса и серверной компоненты, исправлены обнаруженные ошибки, доработана документация.
Улучшения базового веб-интерфейса
Базовый веб-интерфейс программного комплекса «Центральный Пульт» – это лицо продукта и основной инструмент работы пользователей разных ролей и полномочий. Присущие веб-интерфейсу качество и высокая отзывчивость, адаптивное представление информации в разных доступных режимах отображения, интуитивно понятные общие принципы и инструменты работы с информацией, гибкие возможности настройки, использования дополняющих функционал расширений – все это позволяет удовлетворять имеющиеся потребности и повышать лояльность пользователей.
Несмотря на перечисленные положительные черты, функциональное совершенствование и улучшения веб-интерфейса “Центрального Пульта”, нацеленные на предоставление новых возможностей и повышение удобства работы пользователей, постоянно продолжаются. Далее представляются сведения об изменениях и доработках, вошедших в обсуждаемый релиз, в том числе и в отношении веб-интерфейса.
Возможность сортировки объектов по времени и длительности в табличном виде
Информация выводится на главном экране веб-интерфейса программного комплекса в соответствии с вариантом, выбранным в панели режимов отображения. Доступен богатый набор режимов со своими особенностями и пользовательскими историями предпочтительного использования – стандартный вид, геокарта, табличный вид, вид подробной информации, сетка, окно информации и облегченные режимы.
В табличном виде дочерние объекты и связи между ними представляются в виде таблицы с возможностями установки фильтра по состояниям объектов, сортировки объектов по столбцам, изменения набора отображаемых столбцов и порядка их следования.
Ранее сортировка объектов в таблице была возможна только по столбцам “ID” (идентификатор объекта/связи), “Состояние” и “Имя”. В новом релизе добавлена возможность сортировки объектов также по столбцам “Время” и “Длительность”, что позволяет видеть в верхней части таблицы объекты, недавно сменившие свое состояние и более оперативно реагировать на возникающие проблемы.
В столбце “Время” выводится момент перехода объекта в текущее состояние, а в столбце “Длительность” – продолжительность нахождения объекта в этом состоянии.
Добавление нового функционала управления объектами в панели инструментов – “Добавить сюда”, “Перенести сюда”
Основа информационной модели программного комплекса – граф, представляющий взаимосвязанную иерархию объектов. Объект представляет собой элемент инфраструктуры, в отношении которого выполняется мониторинг. Объекты могут быть соединены друг с другом с помощью связей, которые отражают физическое или логическое соединение между ними, а состояние связи (как и объекта) является результатом мониторинга.
Объекты в системе могут иметь неограниченное число как дочерних, так и родительских объектов, образовывая многоуровневые иерархические структуры. При работе со сложными структурами полезно иметь разнообразные и удобные в использовании механизмы управления подчинением и переподчинением объектов.
Изменить родительский объект и положение объекта в иерархии можно с помощью веб-формы на вкладке “Параметры объекта” секции “Параметры” (при активации вида подробной информации об объектах и связях на главном экране веб-интерфейса). Переподчинение объектов возможно также путем их перетаскивания в стандартном виде с главного экрана в панель навигации.
В новом релизе появилась дополнительная возможность управления подчинением и переподчинением дочерних объектов – с помощью кнопок “Добавить сюда” и “Перенести сюда” на панели инструментов (в правом верхнем углу окна).
Добавление нового родителя для дочернего объекта предполагает выделение в панели навигации объекта, который должен выступать в роли родителя, нажатие кнопки “Добавить сюда”, выбор в открывшемся диалоговом окне дочернего объекта из списка и нажатие кнопки “Добавить”. В результате у дочернего объекта появится новый родитель, будет автоматически активирован режим “мультиродителя” (если не был настроен ранее), при этом все уже существовавшие родители сохраняются.
Замена родителя для дочернего объекта выполняется путем выделения в панели навигации объекта, который должен выступать в роли нового родителя, нажатием кнопки “Перенести сюда”, выбором в открывшемся диалоговом окне дочернего объекта из списка и нажатием кнопки “Перенести”. Выбранному дочернему объекту будет назначен новый родитель, при этом объект потеряет всех ранее имевшихся родителей.
Отображение значения по умолчанию в поле “Период проверки” секции “Мониторинг”
Проверки состояния наблюдаемых объектов в программном комплексе осуществляются с помощью выбранного и специальным образом настроенного типа сенсора. Существуют встроенные (стандартные) и пользовательские сенсоры (оформляемые через собственные скрипты и передаваемые им аргументы, которые настраиваются через веб-интерфейс). Настройка сенсоров производится в секции “Мониторинг”, доступной в виде подробной информации об объектах и связях на главном экране веб-интерфейса.
Среди индивидуальных для конкретного типа сенсора набора описывающих полей наиболее часто фигурируют – агент (имя агента с указанием идентификатора и пути к нему в иерархии), тип проверки (сенсор, на основе которого будет осуществляться проверка), таймаут (время, в течение которого агент будет ожидать результатов выполнения проверки с момента ее запуска) и период.
Агент – специальная программа, устанавливаемая на виртуальный/физический сервер или иной узел сети и осуществляющая выполнение проверок, сбор и передачу информации на сервер системы.
Период в наборе полей трактуется как временной промежуток, через который агент начнет выполнение следующей проверки после получения результатов предыдущей. Ранее значение периода устанавливалось вручную пользователем, что требовало от него специфических знаний об особенностях выбора периода для того или иного типа проверок и могло приводить к некорректным настройкам мониторинга.
В актуальном релизе для всех встроенных типов проверок в веб-форме отображается индивидуальное значение по умолчанию, которое система использует в отсутствие назначенного пользователем.
Обновление встраиваемого виджета с графиками с добавлением нового функционала
“Центральный Пульт” как развитая система мониторинга и управления цифровыми инфраструктурами, имеет богатый функционал визуализации накапливаемой информации в разных формах для наглядного представления и использования в работе дежурными сменами, администраторами системы, аналитиками и экспертами, управленческим персоналом.
В программном комплексе реализован регулярно пополняемый и совершенствуемый функционально набор виджетов, которые можно настраивать, связывать с объектами и отображать в веб-интерфейсе системы. Примеры доступных типов виджетов – “график”, “круг”, “радиальная”, “кольцо”, “счетчик”, “кнопка”, “IFrame” и др.
Тип виджета IFrame позволяет встраивать в веб-интерфейс содержимое сторонних ресурсов, отдельные функциональные страницы и low-code расширения программного комплекса. В виджет могут быть интегрированы страницы с авариями, журналом событий, журналом пользовательских сессий и графиками, при необходимости, дополненные параметрами адресной строки HTTP-запроса, влияющими на отображение данных и представление панели с элементами управления.
В системе можно настроить страницу с графиками, визуализирующими метрики одного или нескольких объектов, которую можно использовать при встраивании в виджет IFrame или для генерации PDF-отчета. В пользовательской документации подробно описаны особенности настройки отображаемых метрик, основные и дополнительные параметры URL, элементы управления, возможности сохранения пользовательских настроеки в представлении с заданным именем.
В актуальном релизе был произведен ряд доработок с добавлением к встраиваемым виджетам с графиками нового функционала.
В расположенный в верхней части страницы набор элементов управления графиками была добавлена строка поиска (в выпадающем списке графиков), которая позволяет отбирать графики по контексту в их названии.
Кнопка в правом верхнем углу набора элементов управления графиками предназначена для экспорта текущей страницы в формате PDF. Ранее в структуру экспортируемого файла включались временной период, тип агрегации и все открытые графики. В новом релизе этот набор дополнен табличными данными (см. далее, при их отображении на экране во время экспорта).
Нажатие на добавленную в набор элементов управления конкретным графиком кнопку 
Возможность скрытия столбцов в журнале событий
Журнал событий (Event Log) реализует в программном комплексе функции просмотра, фильтрации и поиска в потоках “пойманных” агентом и направленных на сервер SNMP-трапов, MQTT-сообщений от поддерживающих протокол MQTT-устройств и датчиков, а также просмотра общей истории состояний всех объектов системы. Интерфейс журнала позволяет оперативно переключаться между этими информационными потоками.
Обстоятельное описание особенностей получения и обработки в “Центральном Пульте” первичных событий (полученных из контролируемых контуров инфраструктуры и сервисов) и вторичных событий (потока классифицированных интерпретаций состояний объектов), а также доступных возможностей и общих принципов работы с журналом событий было сделано в пресс-релизе к версии v.3.14.89 программного комплекса.
Фильтры и элементы интерфейса журнала событий можно настраивать с помощью параметров адресной строки в HTTP-запросе. В разных сценариях использования журнала может быть востребована различная информация о событиях, специфицируемая наборами описывающих ее столбцов с соответствующими данными.
В новом релизе в список доступных для использования был добавлен параметр hideColumns, который позволяет скрыть отдельные столбцы из таблицы. Со списком возможных значений, индивидуальных для разных режимов отображения журнала, можно ознакомиться в разделе “Идентификаторы столбцов таблицы”. Стоит заметить, что этот параметр применяется и при экспорте данных таблицы.
Скрытие поля “Активен до” для внешних учетных записей (LDAP, Keycloak)
Программный комплекс “Центральный Пульт” поддерживает различные востребованные на практике методы аутентификации, как “внутренние” (по имени пользователя и паролю, по ключу), так и “внешние”, эксплуатируемые в организациях при доступе к корпоративным информационным системам и сервисам – с помощью сервера службы каталогов LDAP и сервера Keycloak, широко используемого для реализации модели Single Sign-On.
Настройки пользователей осуществляются в разделе “Управление пользователями и группами” окна конфигурации системы. В наборе полей, описывающих основные настройки пользователя на вкладке “Общие”, ранее в независимости от задействуемого метода аутентификации в числе других присутствовало поле “Активен до”, позволяющее назначить дату, после которой пользователь не сможет аутентифицироваться в системе.
Для внешних учетных записей этот функционал неприменим, поскольку управление такого рода параметрами выполняется на стороне соответствующего сервера (LDAP, Keycloack). В связи с этим, в актуальном релизе поле “Активен до” не отображается и недоступно для назначения.
Улучшения и изменения в конфигурации сервера
Сервер является ключевым компонентом в архитектуре программного комплекса “Центральный Пульт” и представляет собой набор микросервисов, которые осуществляют обработку и анализ поступающих данных мониторинга. В состав серверной части, помимо микросервисов, входят HTTP-сервер nginx и REST-сервер, отвечающий за обработку REST-запросов от клиентов по API.
Конфигурация сервера производится в расположенном в структуре файловой системы текстовом файле /etc/saymon/saymon-server.conf, состоящем из набора разделов и соответствующих им параметров, с помощью которых задаются значения настроек сервера.
Приведение в соответствие модели активных и исторических аварий
Авария в процессах мониторинга цифровых активов – это незапланированное событие в ИТ-инфраструктуре, которое привело или может привести к прерыванию или снижению качества предоставления услуги потребителю и помешать бесперебойной работе бизнеса. Обнаруживаемые системой мониторинга аварийные ситуации подлежат обязательной регистрации и классификации с последующей реакцией на них в автоматическом или ручном режиме.
Наличие возможностей по отслеживанию и контролю жизненного цикла аварий позволяет оценивать качество работы ответственных технических служб, формировать базу знаний по возникающим проблемам для использования в будущем диспетчерами, оперативными дежурными и экспертами в целях сокращения времени реакции и устранения, автоматизации действий по восстановлению и предупреждению негативных ситуаций.
В программном комплексе “Центральный Пульт” аварии могут быть сгенерированы с помощью назначения условий перехода состояний объектов или условий генерации аварий. Зафиксированные аварийные ситуации отображаются в табличном виде на странице аварий в ассоциации с объектами мониторинга и с разделением на активные и исторические.
В представляемом релизе была приведена в соответствие модель активных и исторических аварий, что позволило реализовать единое представление обоих разделов в веб-интерфейсе, не терять полезную информацию при переносе активных аварий в историю, привести в порядок экспортируемые данные.
Во-первых, в авариях были разделены понятия “критичность” и “погашение”. Уровни критичности используются при настройке условий генерации аварий, выполняемой в соответствующем разделе окна конфигурации системы. Пользователю с необходимыми правами предоставляются возможности изменять уровням аварий название и цвет отображения, добавлять новые или удалять ранее созданные уровни.
Погашение аварии приводит к ее перемещению в список исторических аварий (по умолчанию это происходит через две минуты после погашения) и может выполняться автоматически (при выполнении необходимых условий) или вручную (через контекстное меню аварии).
Ранее информация об уровне критичности и статусе аварий размещалась в одном столбце, при этом в активных авариях “погашение” заменяло “критичность”, и информация о критичности для погашенных аварий становилась недоступной. В истории аварий факт погашения не отображался, так что пользователю нужно об этом знать и быть внимательным в отношении того, с каким списком производится работа.
В новом релизе программного комплекса поля “Статус” и “Критичность” были разделены, что позволяет всегда видеть в таблице как уровень критичности, так и факт погашения аварии. В разделе с активными авариями в добавленном столбце “Статус” фиксируется факт погашения (контекст “Cleared” на зеленом фоне) и/или показывается значок “корзина” (для удаленных аварий), а в поле “Критичность” указывается соответствующий аварии уровень критичности. В таблице с историческими авариями в поле “Статус”, очевидно, может присутствовать только контекст “Cleared”.
Во-вторых, данные по активным авариям теперь полностью переносятся в коллекцию истории вместе с идентификатором (ID). Это позволило не терять связь аварий с комментариями и находить аварии в истории по их ID.
Ранее комментарии к авариям можно было просматривать (а также добавлять) только в разделе “Активные аварии”. В новом релизе возможность просматривать комментарии появилась и для исторических аварий – последний комментарий показывается в новом столбце “Комментарий” таблицы, а полный список комментариев доступен в модальной форме, вызываемой из контекстного меню аварии (при этом добавление новых комментариев и удаление существующих запрещено).
И, наконец, подтверждения активных аварий при погашении стали переноситься в исторические аварии и отображаться в добавленном столбце “Подтверждено”, что дает возможность узнать каким пользователям и когда было совершено это действие.
Возможность блокировки IP-адреса пользователя при неудачных попытках аутентификации
Команда разработки программного комплекса “Центральный Пульт” уделяет повышенное внимание вопросам обеспечения информационной безопасности при работе с системой и ее компонентами. Во всех последних релизах систематически появляется новый функционал, нацеленный на повышение уровня защищенности.
Так, в предыдущем релизе для защиты от попыток подбора пароля к системе была добавлена возможность блокировки аккаунта пользователя в случае нескольких неуспешных попыток аутентификации.
В новом релизе появилась возможность блокировки IP-адреса пользователя при заданном количестве неудачных попыток входа в систему. Управление функцией осуществляется в разделе Server.block_by_ip файла конфигурации сервера, имеющем следующий вид:
“block_by_ip”: {
“enabled”: true,
“attempts”: 3,
“block_period”: 30000
}
Параметр enabled определяет, включен ли функционал блокировки IP-адреса пользователя (значения true/false), attempts – количество попыток, приводящее к блокировке и block_period – время, на которое следует заблокировать IP-адрес (в миллисекундах).
В случае блокировки пользователя, при попытке входа в систему ему будет показана следующая ошибка:
Ошибка! (38) Cлишком много неудачных попыток входа в систему, повторите попытку через несколько секунд
Доступность возможности удаления собственной учетной записи только при включенном параметре серверной конфигурации server.user.auth_enabled
Функционал управления пользователями и группами является неотъемлемым компонентом любых программных систем и приложений, предполагающих аутентификацию и разделение прав пользователей.
В веб-интерфейсе программного комплекса “Центральный Пульт” основная работа с пользователями и группами производится в соответствующем разделе окна конфигурации системы. Администратор имеет возможность добавлять и удалять пользователей и группы, изменять настройки доступа пользователей к объектам и права на операции, задавать фильтры журнала событий, просматривать журналы активности и изменений пароля пользователями.
Пользователь без расширенных прав по работе с системой может изменить связанный с учетной записью email, отображаемое имя, язык интерфейса, сменить пароль для входа в систему.
Ранее обычным пользователям можно было удалить свою учетную запись. Такая функция в корпоративных контурах обычно недоступна по соображениям безопасности. В новой версии программного комплекса появилась возможность отключить этот функционал. Удаление собственной учетной записи теперь доступно всем пользователям только, если для параметра Server.user.auth_enabled серверной конфигурации задано значение true. Таким образом, возможность удалить собственную учетную запись включается (или отключается) одновременно с возможностью самостоятельной регистрации.
Возможность отключения аутентификации по API-токену
Аутентификация пользователей в программном комплексе “Центральный Пульт” при работе по REST API может производиться несколькими способами – базовая аутентификация с помощью логина и пароля, аутентификация на основе сохраненного идентификатора сессии (например, в cookie) или с помощью API-токена.
Последний метод предполагает получение API-токена в окне конфигурации системы веб-интерфейса (в составе ссылки для авторизации), который можно использовать в запросах к API комплекса. Следует заметить, что данный метод работает только для “внутренних” учетных записей программного комплекса и недоступен для “внешних” (LDAP, Keycloak).
В актуальном релизе метод аутентификации с помощью API-токена может быть запрещен. Параметр серверной конфигурации Server.user.auth_token_enabled отключает возможность аутентификации с помощью токенов. Параметр конфигурации веб-приложения authTokenEnabled (файл /etc/saymon/saymon-client.yaml) отключает в веб-интерфейсе программного комплекса на вкладке “Общие” раздела “Управление пользователями и группами” окна конфигурации системы отображение поля “Ссылка для авторизации”.
Добавление нового встроенного состояния объекта – CRITICAL
В информационной модели программного комплекса все объекты и связи между объектами находятся в определенных состояниях с соответствующей интерпретацией и цветовым выделением в веб-интерфейсе. Состояния могут меняться в процессе мониторинга в зависимости от получаемых данных согласно заданным условиями перехода состояний. Соотношение цветов и состояний можно настроить, а также расширить стандартный набор состояний в окне конфигурации системы в разделе “Список состояний”.
Список состояний по умолчанию ранее включал в себя такие состояния как CREATED (объект создан), WORKING (объект в работе), OVERLOADED (объект перегружен), ALARM (авария на объекте), DOWN (объект не функционирует) и др.
Выявленная в процессе эксплуатации комплекса проблема состояла в невозможности при генерации аварий по состоянию объекта выполнить “маппинг” вида “один-к-одному”. В новом релизе для решения этой проблемы в список было добавлено еще одно состояние – CRITICAL (критическая авария). Теперь по умолчанию, при переходе объекта в это состояние должна автоматически генерироваться авария с уровнем ALARM.
Исключение поддержки локальных JMX-проверок
Сенсоры в программном комплексе ответственны за выполнение проверок, результаты которой отображаются в веб-интерфейсе для связанного объекта. Среди широко набора доступных сенсоров – “Процесс по имени”, “Выполнение программы/скрипта”, “Удаленный порт”, “SNMP Get”, “WMI-сенсор”, “HTTP-сенсор”, “JMX-сенсор”, “MQTT-сенсор”, “Бинарный протокол” и ряд других.
“JMX-сенсор” позволяет получать данные о работе Java-приложений, поддерживающих технологию JMX (Java Management Extensions, управленческие расширения Java). В настройках сенсора допускается указать один из двух типов соединений – локальный (обращение осуществляется по ID процесса) и удаленный (соединение по IP-адресу или имени хоста и номеру порта). В актуальном релизе поддержка локальной JMX-проверки была отключена.
Возможность хранения метрик в СУБД VictoriaMetrics
Базы данных временных рядов (Time Series DataВase, TSDB) представляют собой специализированное ПО, которое оптимизировано для хранения и обслуживания временных рядов с помощью связанных пар времени и значения и обеспечивает существенные преимущества в производительности по сравнению с реляционными СУБД и NoSQL СУБД, базирующихся на модели данных “ключ-значение”. Среди известных реализаций концепции TSDB – OpenTSDB, InfluxDB, Prometheus, VictoriaMetrics, Graphite, TimescaleDB (расширение PostgreSQL), Apache Druid, AWS Timestream, Elasticsearch, Grafana Loki и некоторые другие.
В базовой архитектуре “Центрального Пульта” в качестве хранилища временных рядов задействована СУБД OpenTSDB, в которой хранятся накапливаемые в процессе мониторинга числовые метрики, используемые при анализе данных и построении графиков.
Реализация интеграций с другими TSDB повышает гибкость и адаптируемость программного комплекса, предоставляет возможности встраивания в существующие корпоративные контуры, получения данных от эксплуатируемых систем мониторинга и работы с ними в едином интерфейсе.
Ранее в программном комплексе была реализована (но не описана в документации) интеграция с InfluxDB, обеспечивающая возможность хранения метрик объектов в этой СУБД. Теперь, помимо InfluxDB, появилась возможность использовать для хранения метрик открытую, высокопроизводительную, масштабируемую СУБД VictoriaMetrics.
Настройка хранения метрик объектов в VictoriaMetrics предполагает загрузку и установку данной СУБД с помощью докер-контейнера и последующую настройку конфигурации сервера “Центрального Пульта”.
Настройка осуществляется путем добавления в конфигурационный файл сервера системы секции tsdb_extensions, которая представляет собой массив конфигураций дополнительных баз временных рядов:
“tsdb_extensions”: [
{
“name”: “victoria”,
“enabled”: true,
“config”: {
“promAddr”: “http://<vitoriametrics_host>:8428”
}
}
]
Параметр name задает здесь имя (тип) базы данных (в данном случае необходимо использовать victoria), enabled – включение/выключение интеграции, config – конфигурация для подключения к БД (протокол, хост и порт).
Исправление ошибок
Согласно одному из хорошо известных разработчикам законов Мерфи, “в любой программе есть ошибки”. Ничего удивительного, программы (пока еще) разрабатывают люди, которым свойственно ошибаться.
“Центральный Пульт” представляет собой сложный, многокомпонентный и объемный продукт, так, суммарный размер файлов программного кода ядра превышает 20 МБ. Вполне естественно, что в процессе эксплуатации, в условиях постоянного расширения числа пользователей, в коде периодически выявляются ошибки.
В новом релизе были обнаружены и исправлены следующие ошибки:
- ошибка, из-за которой при добавлении графика в объекте сохранялись некорректные данные
- ошибка, из-за которой дополнительное условие “длительность” не работало при анализе более одной метрики
Разработка документации по REST API на русском языке
Наличие качественной, детальной и актуальной документации – обязательный атрибут развитых программных решений. Команда “Центрального Пульта” (SAYMON) всегда уделяет должное внимание этому направлению – разрабатывает, актуализирует и публикует в открытом доступе двуязычную документацию по платформе.
Ссылки на сайты с документацией:
- документация по платформе на русском языке – https://docs.cpult.ru
- документация по платформе на английском языке – https://docs.saymon.tech
- документация по REST API на русском языке – https://api.cpult.ru
- документация по REST API на английском языке – https://api.saymon.tech
Для удобства пользователей и разработчиков доступны светлая и темная темы оформления сайтов с документацией.
Программный комплекс “Центральный Пульт” имеет систематически расширяемый открытый API категории REST, позволяющий выполнять стандартные методы для работы с информацией на базе протокола “JSON over HTTP(s)”. Абсолютное большинство операций и действий, доступных в веб-интерфейсе комплекса, могут быть выполнены с помощью API (при наличии необходимых прав).
“Центральный Пульт” использует открытую библиотеку Socket.IO для имплементации Comet-сервера, задействуя кастомные события библиотеки для обновления данных в системе в режиме реального времени. Socket.IO реализует основанное на событиях двунаправленное соединение между браузером и веб-сервером комплекса с низкими задержками.
В процессе работы над новым релизом была подготовлена отсутствовавшая ранее документация по REST API на русском языке, которая, как и английская, содержит список запросов, доступных в REST API, описание событий Socket.IO и практическое руководство с примерами решения типичных задач с помощью API.
Команда SAYMON и интеграторы выполняют довольно много дополнительной работы, которая в результате принимает форму отдельных модулей. По модулям часто появляются отдельные материалы, а развиваются модули в своем темпе. Часто группы модулей вместе с основным платформенным продуктом – программной платформой “Центральный Пульт” – образуют комплексные решения отдельных технологических или отраслевых решений.
Примером такого решения является система автоматического определения конфигурации IP-сети L2/L3, построенная на модуле NETSCAN компании IPGURU. Идея, состоящая в том, что профильные команды смогут наилучшим образом подготовить, реализовать и развивать профильные решения будет развиваться и далее. “Центральный Пульт” продолжит улучшаться как платформа и усилит объединяющую функцию путем структурирования процессов обмена задачами и решениями на базе каталога решений SAYMON.
Следите за нашими новостями, публикациями в блоге и включайтесь в партнерство!