Руководство по началу работы с функцией «Активы»

Шаг 3. Выбор данных для включения

Каждый экземпляр функции «Активы» уникален, так как каждой компании нужно отслеживать разную информацию. Функция «Активы» может хранить любую информацию, которую вам и вашей компании важно знать и понимать. Какие именно ресурсы или элементы конфигурации следует включить, зависит от того, чего вы пытаетесь достичь. В этом разделе содержатся наши рекомендации по выбору необходимых данных.

Определите проблему

Большинство инструментов применяют, чтобы решить какую-либо проблему, и функция «Активы» — не исключение. Может, вы хотели бы повысить скорость разрешения инцидентов, а может, изменения в определенной службе часто приводят к непредвиденным результатам, потому что вам сложно проследить зависимости службы.

Отыщите свою проблему и через ее призму определите все остальное: от людей, которых вы привлечете к работе, до ресурсов и информации, которые вы включите в базу данных. Проанализируйте проблему, чтобы понять, какая еще информация нужна сотрудникам, чтобы устранить эту проблему. На основе этой информации вы определите типы объектов.

Если сразу добавить слишком большой объем информации, проверить ее достоверность может быть нелегко. Поэтому не пытайтесь решить больше одной проблемы за раз. После решения первой проблемы базу данных функции «Активы» можно будет расширить для решения и других вопросов.

Отталкивайтесь от служб

Если вы планируете использовать функцию «Активы» для управления конфигурацией, советуем следовать принципу «сверху вниз», то есть начать со служб. Определите, от чего зависят эти службы (например, от приложений и хостов). Затем определите зависимости этих зависимостей и т. д. Так вы быстро составите карту служб, которая будет полезна при обработке инцидентов и запросов на изменение. Впоследствии вы сможете дополнять эту карту по мере необходимости, занося на нее и другие области.

Абстрагируйтесь от реальных предметов

Функция «Активы» позволяет определять необходимые вам объекты, и необязательно ограничиваться традиционными или даже материальными ресурсами. Бизнес-сервисы, например, не являются материальными ресурсами, но часто людям очень важно понимать их до мелочей. Вы можете привязать к сервису все его материальные и нематериальные зависимости, и тогда одного взгляда на объект бизнес-сервиса будет достаточно, чтобы полностью понять, как он работает.

Уровень абстракции может быть совершенно любым. В качестве примеров можно назвать объекты, описывающие важность для бизнеса, типы среды, подразделения/команды, местоположения и т. д.

Пример: классификация бизнес-сервисов

Представим, что всем вашим бизнес-сервисам при добавлении в функцию «Активы» присваивается тип объектов «Бизнес-сервис». Возможно, эти бизнес-сервисы стоит разделить на такие категории, как «Финансы», «Логистика», «Продажи», «Инфраструктура» и т. д. Для этого можно использовать атрибут в рамках типа объектов «Бизнес-сервис» или выделить для этих категорий собственный тип объектов «Категория сервисов».

Думайте о будущем и наращивайте базу постепенно

Имейте в виду все расширения, которые могут произойти в будущем. Это повлияет на то, какие данные будут включены, и на то, как эти данные будут структурированы.

Рекомендуется учитывать это, однако наращивать базы данных функции «Активы» постепенно. Очень непросто загрузить достоверные на 100 % данные для нескольких тысяч объектов за один большой релиз. Начните с малого и добавляйте новые атрибуты, объекты и схемы объектов по мере продвижения. Это гораздо проще.

Рекомендуется определить одну проблему, развернуть базу данных функции «Активы» для ее решения, а затем развивать базу при переходе к каждой следующей проблеме.

Предъявляйте реалистичные требования к точности данных

Стоит стремиться к тому, чтобы достоверность данных в любой момент составляла 100 %, однако в реальности это может быть недостижимо. Пока данные достаточно достоверны, чтобы приносить хоть какую-то пользу для бизнеса, это все равно дает вам преимущество. Многие проекты CMDB реализуются с задержкой или вообще проваливаются, потому что их исполнители пытаются добиться совершенства с самого начала.

Шаг 4. Загрузка данных в функцию «Активы»

На ввод данных вручную может уйти вся жизнь, если дело касается большой организации. Поэтому было создано несколько полезных инструментов.

Asset Discovery

Asset Discovery — это безагентный сканер, который собирает сведения о сетевых ресурсах (доступен бесплатно на Atlassian Marketplace). Вы можете выбрать, какие ресурсы и атрибуты будут включены в схемы объектов, а также создать собственные алгоритмы сканирования для поиска специализированных ресурсов. Сканер можно запускать по расписанию, чтобы он искал изменения и обновлял данные. При помощи правил автоматизации можно даже запускать задачи Jira, отправлять уведомления по электронной почте и выполнять другие действия в зависимости от обнаруженных изменений.

Средства импорта

Вы можете использовать средства импорта, чтобы загрузить данные из других источников. Правила импорта можно синхронизировать с расписанием, чтобы данные обновлялись тогда, когда это необходимо. Для каждого типа импорта необходимо определить, где хранятся данные и куда их следует сохранить в функции «Активы».

Импорт в CSV-файл

Если все ваши ресурсы содержатся в электронной таблице, например в Excel или Google Таблице, вы можете загрузить данные в функцию «Активы» с помощью средства импорта файлов CSV. Таким образом, у вас будет интегрированная и прозрачная система, в рамках которой вы сможете проводить связи между ресурсами и задачами и анализировать их влияние.

Импорт JSON

Вы можете импортировать объекты в функцию «Активы» из файла JSON, содержащего необходимую информацию.

Советы и рекомендации

Рекомендуется как можно чаще запускать Asset Discovery и средства импорта в период затишья. Подумайте, как часто данные будут изменяться и насколько они важны, чтобы определить необходимую регулярность запуска. Синхронизация должна чуть опережать изменения данных.

Asset Discovery позволяет применять разные алгоритмы сканирования с разной частотой, чтобы снизить потребление ресурсов, необходимых для поддержания данных функции «Активы» в наиболее актуальном состоянии.

Разделите данные между схемами объектов логически

Рекомендуется завести несколько схем объектов в соответствии с назначением данных или владельцем данных.

Если разделить данные между разными схемами объектов, повысится и удобство работы, и удобство сопровождения по сравнению с одной большой схемой. Команды (например, отдел финансов или кадров), которым нужна некоторая информация из функции «Активы», не следует заваливать информацией, которая не имеет для них значения. Кроме того, проще попросить конкретную команду регулярно проверять качество данных в одной конкретной схеме объектов, чем просить ее проверять только определенные части одной большой схемы объектов.

Объединяйте данные

Если у вас уже есть оптимальные в плане использования база данных или источник информации, а также процессы, предназначенные для их обновления, перемещать эти данные в функцию «Активы» не нужно. Вместо этого лучше создать копию важных данных с помощью интеграций и составить расписание, согласно которому эти интеграции будут запускаться для обновления информации в функции «Активы».

Функция «Активы» поставляется вместе с рядом средств импорта (см. предыдущий раздел). Они позволяют добавить информацию, необходимую для принятия решений, в функцию «Активы» или задачу Jira. При этом не придется вести две отдельные копии.

Иногда для этих импортированных данных создают отдельные схемы объектов, иногда их включают в состав более крупных схем объектов. Если данные будут использоваться для разных целей (например, и для поддержки ИТ, и для управления кадрами), целесообразнее включить их как отдельную схему объектов, вместо того чтобы привязывать их напрямую к схеме объектов ИТ и предоставлять доступ к этой схеме отделу кадров.

Если нет возможности использовать средство импорта, можно создать объект с атрибутом URL-адреса, который позволит сослаться на другую базу данных, содержащую дополнительную информацию. Этот вариант подходит, если вы хотите, чтобы агенты могли только просматривать информацию, а возможности поиска и составления отчетов на ее основе не требуются.

Не используйте одни и те же атрибуты повсюду

Если один атрибут используется для множества разных объектов и содержит повторяющиеся значения, часто целесообразнее превратить его в самостоятельный тип объектов. Например, можно создать атрибут «Поставщик» для таких типов объектов, как «Ноутбук», «Телефон», «Принтер», «Монитор» и т. д. Для каждого объекта понадобится ввести (или импортировать) имя поставщика конкретно этого ноутбука, телефона и т. д.

Вроде бы все в порядке, но создать тип объектов «Поставщики» и назначить каждого поставщика в качестве объекта этого типа было бы эффективнее, и вот почему:

• Может понадобиться не только имя поставщика, но и, например, контактный номер службы поддержки или ссылки на контракты. Вряд ли вам хочется прописывать эти сведения для каждого ноутбука и каждого телефона. Введите их один раз и привяжите к объекту-поставщику. Это также пригодится, если вы захотите часть работы по управлению поставщиками выполнять в Jira Service Management.
• Таким образом, у вас появится стандарт описания поставщиков, и благодаря этому проще будет составлять отчеты. Если нужно будет отчитаться о том, сколько запросов поступает в службу поддержки в отношении каждого поставщика, вам не придется беспокоиться, что в отчет попала не вся информация, потому что кто-то где-то написал название поставщика с ошибкой.
• Если поставщик проведет ребрендинг или какую-то информацию о нем нужно будет изменить, вам нужно будет обновить ее только в одном месте.

Эта рекомендация не ограничивается примером с поставщиком. Она актуальна для сред развертывания, подразделений, местоположений и степеней важности для бизнеса.

Шаг 6. Настройка пользовательских полей «Активы» для задач Jira

В этом разделе приведена информация о том, как настроить задачи Jira, чтобы связать их с объектами. Это может пригодиться, например, если нужно добавить затронутый бизнес-сервис в задачи, относящиеся к инциденту, добавить компьютер в задачу, относящуюся к запросу оборудования, или добавить ряд потенциально затронутых хостов в задачу, относящуюся к запросу на изменение.

Вместе с функцией «Активы» вы получаете доступ к новому специализированному пользовательскому полю. Это поле нужно настроить так, чтобы ему был назначен определенный набор объектов.

Шаг 7. Настройка автоматизации

В функции «Активы» используется новый набор связанных с объектами триггеров и действий автоматизации, с помощью которого можно настроить автоматическое выполнение различных заданий.

Приведем несколько примеров:

• изменение владельца или статуса ноутбука в рамках рабочего процесса запроса на обслуживание;
• изменение статуса частей инфраструктуры на «Затронуто инцидентом» при появлении задачи, связанной с инцидентом;
• автоматическое перенаправление задач Jira определенным сотрудникам на основании прикрепленных объектов;
• уведомление ответственных сотрудников, когда срок действия лицензии, контракта или гарантии подходит к концу.
  

Шаг 8. Выбор подхода к обеспечению достоверности данных

Важно поддерживать данные в актуальном состоянии, иначе команды будут в своей работе исходить из ложных предпосылок, а это может помешать быстрому разрешению инцидентов или привести к неверному результату после выполнения запроса на обслуживание.

Поддерживать актуальность данных в функции «Активы» можно несколькими способами. Большинство из них предполагает выполнение однообразной работы в автоматическом режиме.

1. Регулярно выполняйте проверку данных.
   Можно задать правила автоматизации для функции «Активы» таким образом, чтобы по расписанию уведомлять сотрудников о необходимости провести аудит данных. Такие напоминания помогают выполнять быстрые проверки правильности, чтобы поддерживать информацию о ключевых ресурсах в актуальном состоянии.
2. Регулярно выполняйте синхронизацию Asset Discovery, а также соответствующих средств импорта и интеграций.
   Недостаточно частая синхронизация функции «Активы» с внешними источниками данных является причиной возникновения большого объема устаревших данных. Подумайте, как часто изменяются данные во внешнем источнике и как часто они используются в Jira Service Management, чтобы определить оптимальную регулярность синхронизации. Если какие-то данные часто обновляются и на них регулярно ссылаются задачи, возможно, их нужно синхронизировать каждые 24 часа. Другие интеграции могут обходиться без синхронизации недели или даже месяцы.
3. Используйте правила автоматизации.
   Когда в задачах Jira принимаются решения, вследствие которых изменяются данные о ресурсах или конфигурации, это важно отразить в функции «Активы».

Например, если агент решает выдать пользователю новый ноутбук, потому что прежний сломался, эту информацию нужно занести в «Активы».

• У нового ноутбука нужно изменить владельца на автора запроса, а статус обновить на «В эксплуатации».
• У прежнего ноутбука нужно удалить владельца и заменить статус на «Поврежден».

Пока агент общается с автором запроса, вы можете зафиксировать подобную информацию и задать новые статусы и новых владельцев автоматически с помощью экранов изменения состояния и пост-функций инструмента «Активы».

Это всего лишь один из примеров. По ходу встраивания функции «Активы» в рабочие процессы Jira подумайте, какую информацию из задач может быть полезно передавать обратно в эту функцию. В идеале информация в функции «Активы» должна как можно реже обновляться вручную, потому что именно о подобных вещах проще всего забыть.