Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
В поддержке невозможно быстро понять, кому передать инцидент интернет-магазина. Есть большая инвентарная таблица оборудования, но в ней нет связи между пользовательским сервисом, приложением и ответственной командой. Предлагаемый подход — начать с модели, которая отвечает на вопрос дежурного, а не переносить всю инфраструктуру сразу.
Выберите один сервис с частыми обращениями и известной ответственной командой. Он станет контрольным примером модели. Попросите дежурного объяснить, какие сведения ему нужны в первые минуты инцидента. Всё остальное можно отложить: полезность небольшой схемы легче подтвердить, чем поддерживать огромный справочник неизвестного качества.
Модель и договорённости
Определите типы Сервис, Приложение и Команда. Для сервиса храните понятное имя, владельца, критичность и связь с приложением. Для приложения — технического ответственного и сведения, нужные для маршрутизации. Каждому атрибуту назначьте источник и владельца. Если никто не поддерживает поле, его наличие создаёт ложное ощущение достоверности.
Разделите владельца сервиса и техническую команду: это могут быть разные люди и разные обязанности. Для критичности укажите бизнес-смысл вариантов, чтобы она не зависела от субъективной оценки оператора. Не превращайте карточку объекта в место хранения паролей и иной информации, не нужной для маршрутизации.
Порядок внедрения
Создайте небольшую схему и внесите несколько реально используемых сервисов. Настройте связи вручную, проверьте их с дежурными и добавьте поле выбора сервиса в обращение. Только после подтверждения пользы подключайте импорт. Для каждой записи храните происхождение данных и дату последнего подтверждения владельцем, чтобы отличать факт от старой догадки.
Первые объекты заведите вместе с дежурным и владельцем сервиса. Для каждого покажите, как он будет выбран в реальном обращении и какую команду получит агент. Если оператору нужны дополнительные сведения для различения сервисов, исправьте отображаемое название или набор атрибутов. Не ускоряйте импорт, пока контрольные объекты остаются неоднозначными.
Проверки на реальных сценариях
Попросите агента найти команду для трёх известных инцидентов, начиная только с названия пользовательского сервиса. Проверьте пустого владельца, несколько приложений у одного сервиса и смену команды. Убедитесь, что пользователи формы видят только допустимые объекты и не получают лишние сведения о внутренней инфраструктуре через доступное поле.
Включите сервис с двумя приложениями и приложение, которое используется несколькими сервисами. Проверьте, понимает ли агент такие связи и не выбирает ли первую попавшуюся команду. Сценарий списанного сервиса должен исключать случайный выбор в новых обращениях, сохраняя понятную историю старых связей.
Ошибки и диагностика
Распространённый провал — тысячи импортированных объектов без единых идентификаторов и ответственных. Другая проблема — несколько похожих сервисов с одинаковыми названиями. Прежде чем расширять модель, устраните неоднозначность выбора и определите жизненный цикл записи. Технически заполненная CMDB не помогает, если агент не может отличить актуальный объект от выведенного из эксплуатации.
Если агент выбирает неправильный сервис, наблюдайте сам процесс выбора. Причиной может быть не отсутствие объектов, а неразличимые названия, устаревшие записи или недостаточный контекст в форме обращения.
Возврат и восстановление
Сохраните небольшую исходную выборку и настройки поля до подключения к рабочему потоку. При ошибке маршрутизации временно верните ручной выбор команды, сохранив объекты для разбора. Не удаляйте схему, на которую уже ссылаются обращения. Исправляйте связи с учётом истории: прошлое назначение может быть корректным на момент инцидента.
При отключении маршрутизации по Assets не стирайте уже выбранный сервис из обращений. Он полезен для анализа и последующего исправления связи. Для ошибочных назначений составьте отдельный список задач и подтвердите передачу правильной команде. Только после этого возвращайте автоматическое использование объекта в обработке новых обращений первой линии.
Приёмка и дальнейший контроль
Измеряйте долю обращений с определённым сервисом, время поиска ответственной команды и число объектов без владельца. Встреча с дежурными через месяц должна показать конкретные случаи, где модель помогла. Следующий тип объектов добавляйте ради подтверждённого вопроса эксплуатации, а не ради максимальной полноты схемы.
Для каждой записи договоритесь о проверке актуальности и реакции на смену владельца. Если сервис реорганизован, простое переименование может исказить историю обращений. Владелец модели должен понимать, когда обновляется существующий объект, а когда создаётся новая сущность с отдельным жизненным циклом.
Механизм продукта и применимость
Assets организует данные через схемы, типы объектов, атрибуты и связи. Для связи объекта с задачей используется специальное пользовательское поле объектов Assets; доступ к модели управляется отдельно.
Assets хранит модель объектов, но полезность CMDB зависит от ответственности за сведения. Начальный набор сервисов и команд в статье выбран ради маршрутизации поддержки. Если вашей команде нужны другие решения, сначала сформулируйте соответствующие вопросы, а затем добавляйте типы, атрибуты и связи.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу