Работаем с Atlassian Service Desk, получаем максимум от плагина Riada Insight — отчёт со встречи Atlassian User Group
Привет! Сегодня публикуем отчёт со встречи Atlassian User Group, которая проходила у нас в офисе. Вместе с инженерами, менеджерами и разработчиками стека Atlassian обсудили внедрение Atlassian Service Desk, возможности работы с отчётами в ней и плагин для управления активами Riada Insight. Под катом — видеозаписи митапа и ссылки на фотоотчёт со встречи.
Современные тенденции говорят, что нужно не только автоматизировать процессы работы над заявками, но и строить self management системы для поддержки пользователей. Система Atlassian Service Desk — как раз про это. И ей на митапе было посвящено два доклада.
«Переход на Atlassian Service Desk», Ольга Мухаметзянова, Авито
Ольга рассказала, как мы в Авито запускали Atlassian Service Desk для внутренних проектов. В частности, как переходили на неё с других тикет-систем, побеждали почтовые уведомления, настраивали систему апрувов и оповещений пользователей. Посмотрите видео, если перед вами стоят подобные задачи.
«Отчёты Atlassian Service Desk», Ольга Николаева, Toolstrek
Продолжила встречу и разговор про Atlassian Service Desk Ольга Николаева из Tollstrek. Получилась беседа с гостями митапа об отчётах в системе: как они помогают быстрой перестройке процессов, когда про них нужно начинать думать (желательно — до планирования и запуска системы) и как включать измерения в процесс.
«Riada Insight в Jira — что, как и зачем», Антон Чемлев
Антон рассказал о плагине Riada Insight для Jira, который является одним из плагинов, которые позволяют управлять активами (asset management) в Jira. Поделился опытом настройки Riada Insight и его использования. И рассказал, как выжать из плагина максимум.
Ссылки и фотоотчёты
Плейлист со всеми видео с мероприятия можно найти здесь.
Фотоотчёты мы выложили в фейсбуке и вконтакте.
Чтобы следить за следующими мероприятиями коммьюнити, присоединяйтесь к нему тут: Atlassian User Group Moscow.
Встроенное в Jira управление ресурсами и конфигурациями
Insight дает наглядное представление всех зависимостей, чтобы вы могли управлять ресурсами, элементами конфигурации (CI), быстро разрешать инциденты и минимизировать риски, связанные с изменениями.
Встречайте Insight for Jira Service Management
Управление ресурсами и конфигурацией для высокоскоростного ITSM
В отличие от устаревших баз данных CMDB, Insight обладает гибкой и открытой структурой данных. Это позволяет командам контролировать любые ресурсы, необходимые в процессе управления запросами на обслуживание, инцидентами и изменениями.
Наладьте взаимодействие между командами разработчиков и операционными командами
Прогнозируйте влияние изменений на дальнейшую работу, чтобы команды по разработке и операционные команды могли управлять рисками и выполнять более частые и эффективные развертывания. При возникновении инцидентов Insight предоставляет больше контекста для быстрого их разрешения.
Обеспечьте видимость ваших систем
Ищите и отслеживайте ресурсы для планирования, проведения аудитов и проверки проектов на соответствие требованиям. Получите полное наглядное представление своей инфраструктуры для выявления и решения основных проблем.
Организуйте оперативное обслуживание высшего уровня в командах любого типа
Выясняйте потребности клиентов и оперативно отвечайте на запросы, связывая ресурсы непосредственно с задачами. Ваши команды, будь то команда по ИТ, работе с персоналом, юридическим вопросам или любая другая, могут использовать гибкую структуру данных Insight для управления любым ресурсом.
Возможности Insight CMDB
Автоматизация
Автоматически назначайте заявки ответственным лицам или командам и уведомляйте соответствующих заинтересованных лиц о предстоящих событиях, таких как продление лицензий.
Запросы
Выполняйте запросы к объектам Insight для проведения аудита, управления затратами и выявления причин проблем.
Discovery
Выявите ресурсы и элементы конфигурации с поддержкой IP, а также их ключевые атрибуты и зависимости. Регулярно запускайте Insight Discovery, чтобы поддерживать актуальность информации и отслеживать любые изменения.
Интеграции
Интегрируйте Jira Service Management Data Center с инструментами сторонних разработчиков, включая поставщиков облачных услуг, Jamf, SCCM и других CMDB.
Импорт
Импортируйте файлы CSV и JSON. В Jira Service Management Data Center импортируйте LDAP, базу данных и пользователей Jira. Используйте REST API для расширений.
Отслеживание
Просматривайте детальную хронологию всех изменений, внесенных в ресурсы и элементы конфигурации, одним нажатием кнопки для проверки соответствия требованиям или выявления проблемы.
«Insight позволяет сохранять предсказуемость, а также планировать лицензии и затраты на программное обеспечение».
Дамир Прусак, вице-президент по инжинирингу
Часто задаваемые вопросы
Общие вопросы
Подробные сведения о возможностях Insight в зависимости от используемого плана см. в этой сравнительной таблице.
Да. Объекты Insight можно связывать с задачами Jira Software или Jira Work Management, если в этом же экземпляре присутствует активная лицензия Jira Service Management Premium или Enterprise.
Перемещение базы данных CMDB в Jira Service Management:
Автодока здоровой инфраструктуры: сравниваем 3 инструмента
Эпопея с автодокументацией началась у нас неспроста: 300 разработчиков, 500 репозиториев и 400 сервисов — все живет на 600 хостах и использует 600 баз данных. Изменения происходят настолько часто, что ручной поиск данных в наших масштабах — та еще морока. При этом раньше никакого общего хранилища с актуальной информацией о владельцах проектов, о конфигурациях хостов и связанных с проектами сервисах не было. Расскажу, как мы вконец устали от квестов, перешли на сторону автодоки и почему выбрали в помощь Insight.
Меня зовут Юля, я руковожу командой SRE. Помимо стабильности сервисов, моя команда занимается поддержкой инструмента, который нам позволяет за этими сервисами следить. Это отдельное приложение, генерирующее документацию по всей нашей инфраструктуре.
В 2018 году, когда я только пришла в компанию в роли девопса, мне дали для погружения в процессы простую задачу: допилить скрипт локального разворачивания проектов, чтобы он корректно работал под macOS. То есть скрипт уже был, он успешно работал для Linux-окружения. Его нужно было просто адаптировать, подправить пару регулярок, настроить сеть, дописать инструкцию — совсем не сложно. Я довольно быстро сделала правку в самом инструменте, и казалось, что нет никаких проблем. Но дальше 15-минутная на первый взгляд задача растянулась на 3 месяца.
После того, как я внесла правки в скрипт раскатки, нужно было добавить мелкие изменения во все проекты, которые он поддерживал: поменять директорию монтирования, поправить сеть. Однотипные простые правки, примерно пять строк. Но в каждом проекте. Я их сделала, сформировала пулл-реквесты и застряла. Потому что изменения надо было с кем-то согласовать. Нельзя же совать людям в мастер коммиты без предупреждения. Особенно если работаешь в компании первую неделю. Так что возник вопрос: где и как искать владельца сервиса?
Найти владельцев проектов: старт квеста
Первое, что пришло в голову — README-файлы. Я уже видела к тому моменту, что ими принято пользоваться в Skyeng, поэтому там и попыталась найти нужную инфу. И в большинстве случаев это получилось, но еще выяснилось, что у значительной части проектов README-файлов просто нет, а у некоторых не заполнен владелец или он уже изменился, а файл не актуализировали.
Дальше я пошла за советом к коллегам, ведь девопсы настраивают всем деплои, следят за тестингами и наверняка в курсе всего. С какими-то проектами они мне помогли, но со многими были в таком же тупике, что и я.
После этого начались извращённые методы: я заглянула в GitHub actions. В некоторых местах можно было найти каналы для алертинга, где-то были указаны имена. Несколько человек нашла таким способом.
Потом решила спросить последнего и основного контрибьютора репозиториев — тоже не сильно помогло. Порой эти люди уже и не работали в компании.
Совсем отчаявшись, я пришла к QA, ведь они тестят все фичи и должны знать главных по проектам. Они скинули мне статью в Confluence, где были собраны все интересующие меня проекты с владельцами. Его составляли для тестирования примерно такой же задачи, как моя, буквально за пару месяцев до этого. Сначала я очень обрадовалась, что решение проблемы найдено. Но вскоре оказалось — процентов на 30 эта статья уже не актуальна. Компания быстро растет и многое изменилось за эти два месяца.
В общем, я сделала все, что могла. Познакомилась чуть ли не со всей компанией, но глобально вопрос так и не решила. Мерж и раскатка этих коротких правок заняли три месяца только потому, что не удавалось в адекватное время найти ответственных.
Уже тогда стало понятно — процесс надо менять
В принципе, проблема с поиском владельцев решилась бы, будь у нас четкий регламент по README-файлам.
Но есть ещё пул вопросов, которые возникали у других участников нашей команды:
Как найти сервис по серверу. Например, мы собираемся выкатить обновление на сервер, которое приведет к даунтайму. Надо предупредить владельцев о работах, согласовать тестирование после работ или выяснить безопасное время для обновления.
Как найти зависимые сервисы. Проводим работы на каком-то сервисе и хотим знать, что потенциально может пострадать от наших действий, чтобы предупредить или проверить работоспособность.
Как найти сервисы с доступом к базе. Решили перевезти базу на другой хост, но как узнать, какие сервисы к ней обращаются, чтобы поправить в них url для обращения или логины / пароли.
Как найти сервис по IP, если в логах видно, что сервис неправильно себя ведет.
Как отследить прогресс по большим задачам. У нас недавно был большой проект по «докеризации» всех сервисов. Как понять, насколько продвинулись по задаче, сколько времени еще нужно на проект? Или нужно раскатить новую фичу на все проекты. Как проверить, кто уже раскатил, а кому нужно напомнить о задаче?
Почти все вопросы упираются в первый и ключевой: как найти владельца?
Составленные вручную документы устаревают раньше, чем их успевают прочитать? Нужна автодокументация
Автодокументация — это скрипт плюс источники данных, из которых скрипт сможет сгенерить документацию. И источники данных первичны. Информаци о релизах не получится, если деплой делается путем git pull на хосте. Не будет документации по пользователям и их учеткам в разных системах, если эти учетки заводятся стихийно вручную и нигде не учитываются. Поэтому прежде, чем садиться писать код, нужно найти эти самые источники данных.
Для Skyeng основными источниками данных стали:
README-файлы, где мы договорились делать краткое описание проектов и указывать их владельцев.
Репозиторий Ansible, где указаны все конфигурации серверов.
Репозиторий с пайплайнами, где про каждый проект записано: какой репозиторий, куда выкатывается, по каким правилам, какие переменные мы ему передаем.
Из этой информации мы сформировали автодокументацию по первым трем сущностям:
Далее мы расширили и список источников данных, и список сущностей в автодокументации. Например, стали парсить факты Ansible, дашборды в Grafana, ресурсы в Qrator, информацию по доменам и еще много всего. Но в этой статье я хочу рассказать о самом начале нашего пути, так что обо всем по порядку.
Дальше иногда я буду называть автодокументацию техкартой — внутри мы зовем ее именно так.
Сначала наводим порядок в README-файлах
Самое главное, что мы сделали — ввели регламент по заполнению README-файлов на всю компанию. Это был большой проект с поддержкой CTO и с огромной помощью административных ассистентов. Каждая команда получила задачи на заведение в своих проектах README-файлов с определенной структурой: название сервиса, краткое описание и ответственные.
Здесь заголовок верхнего уровня — это title проекта. Дальше указано краткое описание проекта.
Изначально это был ручной процесс. Мы провели несколько итераций, приходили с задачами дозаполнить README, для контроля формировали списки проектов, которые никто себе так и не забрал. И даже несколько заархивировали, обнаружив, что они уже по факту мертвы.
Важно сказать, что делать скрипты для формирования автодокументации, которые работали бы с этим форматом файлов, мы начали немного раньше общей деятельности по заполнению README. Это позволило командам сразу видеть ценность от того, что они выполняют эти задачи: их проекты появлялись в техкарте, у них было корректное описание. Мы прямо по техкарте проверяли статус выполнения задач по заполнению README.
По мере развития автодокументации мы стали генерировать обязательные блоки скриптом. Еще сделали скрипты, которые автоматически обновляют содержимое README при смене владельцев сервисов, и скрипты, которые сообщают, что данные потеряли актуальность. Под именем сотрудника в README теперь лежит ссылка на профиль человека в Slack и ему можно сразу написать в личку.
Чем больше людей узнавали о том, что у нас есть техкарта, тем чаще коллеги сами напоминали ответственным обновить README. Так что со временем эта система стала самобалансирующейся и уже не требует пристального внимания.
В репозитории Ansible и в репозитории с пайплайнами у нас изначально был порядок, никаких мер отдельно предпринимать не пришлось. Просто договорились, что формат описания не меняем без предупреждения.
Теперь можно писать скрипты для сбора информации
В нашем случае скрипт сбора автодоки состоит из трех ключевых групп классов:
Парсер — основная часть скрипта. Это класс, который знает всего две вещи: где взять инфу и как ее распарсить в самый простой вид типа «поле => значения».
Например, парсер знает, что в файле inventories/_clusters.yml лежит инфа по кластерам, и в каком она формате. Он достает ее и передает дальше.
Такой парсер есть под каждый источник информации и он занимается только «своим» источником. Некоторые парсеры ходят в API, например, в Grafana или Amazon, какие-то в базу, какие-то — парсят репозитории.
Все, что отдают парсеры, складывается в общую «коробочку» — это по сути массив слабоструктурированной информации, который потом передается дальше.
Затем наступает очередь обработчиков.
Техкарта состоит из сущностей и связей между ними, а сущности состоят из полей. Поле — это любая характеристика сущности. Так, на первом этапе сущностями были хосты, базы, сервисы. У сервисов могут быть поля: название, описание, владелец, репозиторий, тип деплоя и так далее.
Обработчик пишется отдельно для каждого поля техкарты. Это тоже короткий скрипт, который знает только две вещи: какого типа данные он должен отдать и как их собрать из слабо структурированных данных, которые лежат в «коробочке» с прошлого этапа.
Вот так это выглядит:
У этого скрипта есть тип (в данном случае это булево поле), название для внутренних нужд и заголовок — для визуализации.
Они в свою очередь доставят информацию в место назначения.
Где хранить структурированную информацию?
Мы попробовали несколько вариантов — аппетиты росли по мере внедрения фич. Благодаря описанной выше структуре кода мы получили достаточно гибкое решение, которое может без проблем «запушить» автодокументацию в разные места в зависимости от потребностей.
Вариант 1. GitHub
На первом этапе задачи (мы же делали по факту пилот и надо было еще проверить, выстрелит ли идея) нам нужно было что-то простое и с минимальными затратами времени и сил. Мы немного подумали и решили, что GitHub — идеальное место для «быстро и дешево».
И выглядело это примерно так.
Точно так же выгрузили информацию по сервисам: какие базы используют, кто владелец, куда писать по проблемам. Между хостами и сервисами настроены ссылки.
Это был настоящий прорыв после полного хаоса, это было (не побоюсь этого слова) счастьем. Многие рутинные процессы по поиску и сопоставлению информации сразу же упростились в разы.
У подхода с репозиторием есть очевидные минусы: таблицу нельзя фильтровать, из-за ограничений гитхаба таблицы достаточно узкие и мы получаем либо мало инфы, либо огромный скролл, поиск на странице возможен только по Ctrl+F.
Проблемы обострились, когда мы решили добавить больше полей: люди начали пользоваться автодокументацией и постоянно приходили запросы на добавление новых полей. Какие-то команды заинтересованы в одних данных, какие-то — в других. В конце концов у нас получилась очень длинная таблица с горизонтальной прокруткой, причем закрепить первый столбец нельзя и ты никогда не можешь быть уверен — ту ли строку ты сейчас читаешь, которую собирался?
Лицензирование Insight for Jira Service Management и цены на продукт
Важные изменения в продуктах Server и Data Center
Компания Atlassian прекратила продажу новых лицензий Server, а 2 февраля 2024 г. прекратит поддержку продуктов Server. При этом Atlassian продолжит инвестировать в продукты Data Center с несколькими ключевыми улучшениями. Узнайте подробнее о том, какое значение это имеет для вас.
Общие вопросы
Недавно компания Atlassian приобрела фирму Mindville. В феврале продукт Mindville Insight начали предлагать в комплекте с решением Jira Service Management Data Center. Теперь возможности управления конфигурациями и ресурсами (вместе с приложением Discovery) будут доступны в составе решений Jira Service Management Cloud Premium и Enterprise.
С помощью Insight команды могут отслеживать свои ресурсы, элементы конфигурации и другие активы, чтобы получать наглядное представление о важных взаимосвязях между приложениями, сервисами и базовой инфраструктурой, а также о других ключевых зависимостях.
Благодаря Insight ИТ-команды могут:
Решение Insight работает на базе Jira, благодаря чему у команд появляется простой и быстрый способ связать ресурсы и элементы конфигурации с запросами на обслуживание, инцидентами, проблемами, изменениями и рабочими нагрузками. Попробуйте Insight — это несложно — и он быстро принесет пользу!
В отличие от устаревших баз данных CMDB, Insight обладает гибкой и открытой структурой данных. Это позволяет командам управлять ресурсами любого вида, которые необходимы для поддержки принципов ITSM. Отдел кадров, отдел продаж и маркетинга, юридический отдел, административно-хозяйственный отдел и другие подразделения могут использовать Insight для отслеживания своих ресурсов и других активов, а также для управления ими.
Server — продажа новых лицензий Server будет прекращена 2 февраля 2021 г. (включая приложение Insight — Asset Management Server), а 2 февраля 2024 г. прекратится поддержка существующих лицензий. Поэтому приложение и (или) возможности Insight не будут включены в предложение Jira Service Management Server. Тем не менее, пользователи, у которых есть лицензия на приложение Insight, могут продолжать продлевать ее действие и использовать ее до 2 февраля 2024 г., когда ее поддержка будет прекращена. К этому времени рекомендуется сделать выбор в пользу Jira Service Management Cloud или Data Center.
Data Center — начиная со 2 февраля 2021 г. приложение Insight — Asset Management будет интегрировано в Jira Service Management Data Center 4.15. Insight Discovery можно будет загрузить бесплатно из Atlassian Marketplace. Пользователи, использующие Jira Service Management 4.14 или более раннюю версию этого продукта, смогут бесплатно загрузить приложение Insight — Asset Management из Atlassian Marketplace.
С 31 марта 2021 г. все функции Insight будут включены в тарифные планы Jira Service Management Premium и Enterprise. Благодаря этому в Insight появятся новые возможности, в том числе импорт данных из Insight Discovery (доступно для бесплатной загрузки в Marketplace), улучшенная интеграция данных Insight в задачи Jira, расширенные возможности автоматизации и многое другое. Подробнее см. раздел «Возможности» далее на странице.
Начиная с этой даты приложение Insight — Asset Management Cloud больше не будет доступно для покупки. 31 марта 2022 г. поддержка существующих пользователей этого приложения прекратится.
Возможности должны появиться в течение недели после объявления 31 марта. Перейдите по этой ссылке, чтобы узнать больше о том, как настроить возможности управления ресурсами и конфигурациями в Jira Service Management.
Подробнее о разнице между версиями Server/Data Center и приложением Insight — Asset Management Cloud, которое можно найти в Atlassian Marketplace, читайте здесь.
Дополнительные вопросы можно направлять в службу поддержки клиентов или представителю отдела продаж.
Cloud
С 31 марта 2021 г. продажа приложения будет прекращена.
Через год, 31 марта 2022 г., прекратится поддержка приложения и оно будет отключено. К этому моменту пользователи должны будут перенести свои данные из приложения в интегрированную версию Insight for Jira Service Management Premium или Enterprise.
Подробная информация приведена в разделе «Миграция».
Доступ к Insight будет автоматически предоставлен вашему экземпляру Cloud в момент запуска без дополнительной платы. Компонент Insight ориентировочно должен появиться в течение недели после 31 марта 2021 г.
Если вы уже используете приложение Insight — Asset Management Cloud, ваши данные НЕ будут автоматически перенесены в новое интегрированное решение Insight for Jira Service Management.
В настоящее время ведется разработка возможностей экспорта и импорта схем, с которыми пользователям станет проще переносить данные из приложения в новое интегрированное решение Insight for Jira Service Management Premium или Enterprise. Подробная информация приведена в разделе «Миграция».
Лицензирование версии Cloud
Да, всем пользователям Jira Service Management Premium и Enterprise можно будет предоставить доступ к Insight. Однако сначала нужно будет настроить права доступа к схемам объектов, чтобы разрешить пользователям просматривать их.
Нет, продукт Insight доступен только при использовании Jira Service Management на условиях планов Premium или Enterprise. Чтобы получить доступ к Insight, у вас должна быть оформлена подписка на один из этих планов.
Нет. Чтобы получить доступ к возможностям Insight, необходима лицензия Jira Service Management Premium или Enterprise. При наличии этой лицензии объекты Insight можно использовать в проектах Jira Software и Jira Core (см. вопрос ниже).
Если у вас уже есть активная подписка на приложение Insight — Asset Management Cloud, размещенное в Marketplace, вы можете продолжать использовать приложение Insight с Jira Software или Jira Core (даже без лицензии Jira Service Management Premium или Enterprise) до 31 марта 2022 г.
Да. Объекты Insight можно связывать с задачами Jira Software или Jira Core, если в этом же экземпляре присутствует активная лицензия Jira Service Management Premium или Enterprise.
В интерфейсе просмотра задач пользователи Jira Software/Jira Core смогут просматривать связанные объекты и атрибуты объектов.
Просматривать диаграмму объектов и обновлять объекты Insight, связанные с задачей Jira Software/Jira Core, смогут только пользователи, включенные в лицензию Jira Service Management Premium или Enterprise и лицензию Jira Software/Jira Core.
Получить доступ к базе данных Insight могут только пользователи, включенные в лицензию Jira Service Management Premium или Enterprise и получившие необходимые права от администраторов.
После 1 мая 2021 г. любое использование автономных приложений Insight будет регулироваться Условиями использования Atlassian Cloud, и на него будут распространяться положения Политики конфиденциальности Atlassian. Эти документы замещают Лицензионное соглашение с конечным пользователем Mindville и Политику конфиденциальности Mindville.
На решение Jira Service Management Premium и компонент Insight для Cloud распространяются юридические положения Условий использования Atlassian Cloud и Политики конфиденциальности Atlassian.
Оплата версии Cloud
Продукт Insight будет доступен бесплатно всем, кто оформит подписку на план Jira Service Management Premium или Enterprise. Цены приведены здесь.
Мы не предлагаем скидки, однако лицензия на приложение Insight — Asset Management будет бесплатной после даты следующего продления действия. Лицензия продолжит бесплатно действовать до 31 марта 2022 г., когда будет прекращена поддержка приложения.
Если вы решите понизить уровень лицензии до версии Jira Service Management Free или Standard, вы больше не сможете бесплатно получать доступ к приложению Insight.
Вам нужно будет перенести данные из автономной версии приложения Insight в интегрированную версию до 31 марта 2022 г. (подробная информация приведена в разделе «Миграция»).
Пользователи приложения Insight Cloud должны перенести свои данные в решение Jira Service Management Premium или Enterprise прежде, чем поддержка приложения будет прекращена (31 марта 2022 г.). Чтобы вам было проще выполнить этот перенос, мы помогаем вам несколькими способами.
Подробную информацию о датах продления и продолжительности пробного периода можно узнать, открыв свою страницу платежей (перейти на нее можно из настроек администрирования сайта) после 31 марта 2021 года.
Инструкции по переносу данных из приложения Insight App в решение Jira Service Management Premium или Enterprise описаны здесь.
Вы можете понизить уровень плана в любое время. Для этого в Jira Service Management перейдите в раздел Settings—>Billing—>Manage Subscriptions (Настройки—>Платежи—>Управление подписками) и нажмите Change Plan (Изменить план). Следует помнить, что после прекращения увеличенного пробного периода Jira Service Management Premium вам будет выставляться счет за автономное приложение Insight, пока его поддержка не будет прекращена.
Пользователи Jira Software или Jira Core могут продолжать оплачивать лицензию на приложение Insight Cloud и продлевать ее действие до 31 марта 2022 года, когда его поддержка будет прекращена.
Всем текущим пользователям приложения Insight рекомендуется попробовать Jira Service Management Premium. Чтобы активировать увеличенный пробный период, сначала нужно запросить пробный период использования Jira Service Management Premium, а затем обратиться в компанию Atlassian для продления этого пробного периода.
Возможности версии Cloud
Нет, продукт Insight в Jira Service Management Premium и Enterprise обладает одинаковыми возможностями, но в план Enterprise включены дополнительные возможности Jira Service Management, с которыми можно ознакомиться здесь.
Insight Discovery — это бесплатное приложение, которое можно загрузить из Marketplace и использовать с Insight на сайте, на котором есть пользователи, включенные в лицензию Jira Service Management Premium или Enterprise.
Оно не будет взаимодействовать с приложением Insight — Asset Management Cloud, так как у последнего нет необходимого средства импорта для чтения данных.
Подробная информация о приложении Insight Discovery приведена на этой странице.
Продукт Insight, входящий в состав планов Jira Service Management Premium и Enterprise, будет поддерживать механизм импорта и нормализации, аналогичный тому, что был ранее доступен в версиях Server и Data Center.
При запуске будет реализована поддержка следующих типов импорта (в дальнейшем число типов импорта и интеграций будет расти):
Объединение данных и переход на Cloud
Перевести Jira Service Management Cloud с плана Standard на план Premium можно в любое время на странице управления подписками своего сайта Atlassian Cloud или связавшись с представителем отдела продаж.
Вопросы, связанные с переходом на подписку Enterprise, направляйте представителю отдела продаж.
Инструкции по импорту и экспорту схем Insight, с которыми пользователям станет проще переносить данные из приложения Insight — Asset Management Cloud в Insight for Jira Service Management Cloud Premium или Enterprise, находятся здесь.
Вы можете продолжать использовать приложение Insight — Asset Management Cloud до 31 марта 2022 г., поэтому переходить на интегрированную версию сразу необязательно. После 31 марта 2022 г. у вас больше не будет доступа к данным в старой версии приложения.
Вы можете продолжать использовать приложение Insight — Asset Management до 31 марта 2022 г.
После этой даты поддержка приложения будет прекращена, а содержащиеся в нем данные больше не будут доступны.
