Управление активами приложений и служб для команд разработки
Before you start, this guide covers:
What does application and service asset management for application development teams mean.
Why service context, application dependencies, and configuration data matter for engineering teams.
How Service Collection supports developer workflows with Assets, a CMDB, Data Manager, and service relationships.
A practical walkthrough example from service modeling to incident and change context.
Service Collection products referenced: Jira Service Management, Assets, Customer Service Management, Rovo
Reading time: 9 minutes
Разрабатывайте и эксплуатируйте приложения с более полным контекстом службы
Управление активами приложений и служб имеет решающее значение для команд разработки приложений, поскольку современные цифровые продукты зависят от целой сети приложений, служб, сред, инфраструктуры и сторонних компонентов.
Когда информация о приложениях, зависимостях, владении и вспомогательных системах разбросана по заявкам, облачным консолям, электронным таблицам и несистематизированным базам знаний, у команд снижается видимость влияния изменений, рисков инцидентов и работоспособности служб.
Отсутствие такого контекста может замедлить поставку и повысить вероятность сбоев или неверного определения причин неполадок.
Приложения для разработчиков и служба управления активами объединяют этот контекст в надежной общей модели. С помощью Service Collection команды могут отслеживать элементы конфигурации приложений и служб, связывать их с задачами по разработке, понимать взаимосвязи в стеке и быстро определять владельцев.
Это помогает командам разработки приложений безопаснее вносить изменения, быстрее решать инциденты, сокращать затраты на координацию, а также с большей уверенностью создавать и эксплуатировать надежные сервисы.
Что такое управление активами приложений и служб?
Управление активами приложений и служб — это практика отслеживания жизненного цикла, владения и зависимостей приложений и служб для улучшения операционной прозрачности. Подключая приложения к инфраструктуре, такой как реляционные базы данных, веб-службы, микрослужбы или облачные среды, команды получают контекст службы, необходимый для снижения риска инцидентов и ускорения развертывания.
Она объединяет несколько тесно связанных возможностей:
Управление конфигурацией службы: поддержание точной информации о службах, приложениях, базах данных, API, облачных ресурсах и связях между ними.
Отслеживание Активов и конфигураций: организация систем и компонентов, которые поддерживают поставку программных приложений и производственные операции.
Процессы управления службами: применение этого контекста к инцидентам, изменениям, запросам, утверждениям и отчетности.
В Service Collection структуру для этих данных обеспечивают Assets. Assets — это ваша CMDB, в которой хранятся все записи о конфигурации и их взаимосвязи за определенное время. Это помогает командам понять не только то, какие компоненты существуют, но и как они связаны между собой.
Затем диспетчер данных Assets из Service Collection помогает повысить качество данных, консолидируя и сверяя записи из нескольких источников, прежде чем команды начнут использовать их в работе.
Почему управление активами приложений и служб важно для разработчиков
Когда информация о приложениях и компонентах разбросана по электронным таблицам и изолированным системам, становится трудно получить четкое представление о том, какие приложения использует компания, как они применяются и, что особенно важно, что именно перестает работать при внесении изменений.
Assets из Service Collection предоставляет вам структурированную CMDB с возможностью отправки запросов, которая объединяет все данные о ваших приложениях и компонентах в одном месте, заменяя разрозненные электронные таблицы динамичным связанным реестром.
Assets от Atlassian централизует ваш каталог приложений и служб в единой структурированной CMDB с возможностью поиска, заменяя разрозненные электронные таблицы и изолированные инструменты динамическими, связанными записями. Это решение позволяет отслеживать зависимости между приложениями, компонентами и инфраструктурой и напрямую связано с рабочими процессами Jira Service Management. Благодаря этому команды всегда знают, какими ресурсами располагают, кто за них отвечает и на что повлияют изменения.
Быстрая оценка последствий изменений. Команды могут понять, какие приложения, среды или зависимые сервисы могут быть затронуты, еще до развертывания изменения.
Улучшение реагирования на инциденты: ответственные специалисты могут быстро определить владельца службы, вышестоящие и нижестоящие зависимости, а также вероятную затронутую инфраструктуру.
Сокращение переключения контекста: разработчики и операторы могут получать доступ к контексту службы и активов непосредственно в рабочих процессах Jira Service Management.
Повышение ответственности за службу: команды могут упростить поиск и ведение данных о владении, ответственности за поддержку и зависимостях.
Повысьте доверие к службам приложений и операционным данным: диспетчер данных Assets помогает согласовывать записи из инструментов в облаке, инструментов обнаружения и внутренних систем, создавая более точный источник достоверных данных.
Улучшение взаимодействия с командами по эксплуатации. Общий контекст конфигурации помогает командам разработки и эксплуатации одинаково понимать ситуацию при внесении изменений и во время инцидентов.
Как Service Collection поддерживает разработку с учетом приложений и сервисов
Service Collection помогает командам разработки и эксплуатации добавлять данные конфигурации в рабочие процессы, где они наиболее важны. Вместо того чтобы хранить модели служб отдельно от повседневных задач, команды могут связывать приложения, службы и зависимости непосредственно с запросами, инцидентами и изменениями.
Создайте ориентированную на сервисы CMDB с помощью компонента Assets
С помощью модуля Assets команды могут определять схемы объектов для компонентов, важных для поставки и эксплуатации программного обеспечения и приложений, а затем сопоставлять инфраструктуру и реляционные базы данных. Это могут быть бизнес-сервисы, приложения, среды, API, базы данных, очереди, облачные ресурсы, репозитории и команды поддержки.
В CMDB эти элементы конфигурации можно связывать с помощью отношений, которые отражают фактический принцип работы сервисов. Например, приложение для взаимодействия с клиентами может зависеть от шлюза API, кластера базы данных, облачной инфраструктуры и ответственной команды. Эта связанная модель становится полезной, когда командам нужно быстро оценить последствия.
Best practice: start with one or two critical application services and the dependencies that matter most for incidents and changes. A lean, service-centric CMDB is usually more useful than a large model nobody maintains.
Используйте диспетчер данных Assets, чтобы повысить качество данных
Данные приложений и служб часто поступают из множества источников: облачных платформ, инструментов обнаружения, электронных таблиц, внутренней документации и инженерных систем. Если эти источники противоречат друг другу, команды теряют доверие к модели.
Диспетчер данных Assets помогает объединять, очищать и сверять данные из нескольких источников для создания более надежной операционной записи. Это упрощает нормализацию правил именования, сокращает количество дубликатов и позволяет выявлять пробелы до того, как они повлияют на инциденты, аудиты или утверждения.
Для команд инженеров и команд по работе с платформой это означает больше уверенности в вопросах владения службами, записях о средах и данных о зависимостях.
Сопоставьте бизнес-сервисы с сервисами приложений и ресурсами, чтобы оценить влияние инцидентов и изменений.
Jira Service Management позволяет командам связывать запросы или изменения с объектами активов непосредственно из заявки. Это означает, что инцидент можно связать с затронутым приложением или службой, а в запросе на изменение можно указать среду или инфраструктуру, которых оно касается.
После связывания у ответственных и утверждающих будет больше контекста. Они могут видеть, какая служба задействована, кто является ее владельцем, какие другие компоненты могут быть затронуты и ведется ли уже работа над связанными задачами.
Ускорьте поиск и устранение неисправностей с помощью контекста взаимосвязей
Запись о службе сама по себе полезна. Запись о службе, связанная со своими зависимостями, гораздо эффективнее. Данные о взаимосвязях помогают командам быстрее перейти от формулировки «что-то сломалось» к предположению «причиной может быть эта конкретная зависимость».
Например, если работа веб-приложения ухудшилась, команда может проверить связанную базу данных, поставщика услуг аутентификации, очередь и облачную среду, чтобы сузить область расследования. Такое общее представление также может помочь в совместном устранении инцидентов, предоставляя командам разработки и эксплуатации единую карту службы.
Используйте автоматизацию для поддержания операционных рабочих процессов.
Автоматизация помогает командам работать с контекстом службы и конфигурации без лишних действий вручную. Команды могут запускать триггеры для уведомлений, распределять заявки, создавать последующие задачи или обновлять записи на основе изменений в статусе или связанных объектах.
Ниже представлены распространенные примеры таких команд:
Маршрутизация инцидентов на основе выбранной службы или ответственной команды
Создание последующих задач при изменении критической зависимости
Уведомление заинтересованных лиц об инцидентах, затрагивающих высокоприоритетные сервисы
Связывание стандартных эксплуатационных проверок с определенными средами или компонентами
Пошаговый пример: от модели службы к ускоренной оценке, поиску первопричины и устранению инцидента
Вот практический пример того, как управление активами приложений и служб может работать в Service Collection с Jira Service Management и Assets.
Сценарий
Команда платформенных инженеров поддерживает внутренний портал для разработчиков и несколько приложений, предназначенных для клиентов. Ответственность за службу частично задокументирована, но информация о зависимостях противоречива и разбросана по диаграммам, облачным инструментам и знаниям команды.
Когда происходят инциденты, ответственные тратят слишком много времени, чтобы выяснить, что изменилось и какие компоненты затронуты.
Шаг 1. Определите модель службы
Команда создает схему инструмента Assets, чтобы представить в своей CMDB ключевые элементы конфигурации, включая бизнес-сервисы, приложения, среды, базы данных, API и ответственные команды. Они начинают с одной ценной службы приложений и составляют карту ее самых важных зависимостей.
Они определяют такие связи, как:
Приложение зависит от службы API.
Служба API зависит от кластера базы данных.
Приложение работает в производственной среде.
Платформенная команда отвечает за инфраструктуру среды выполнения.
Шаг 2. Консолидируйте исходные данные с помощью диспетчера данных
Команда использует диспетчер данных, чтобы объединить записи из инвентарных списков облака, внутренних таблиц и существующей документации по службам. Дублирующиеся названия приложений сверяются, отсутствующие владельцы помечаются, а устаревшие записи удаляются перед публикацией в рабочую модель.
Outcome: the team now has a cleaner, more trustworthy service model rather than relying on competing versions of the truth.
Шаг 3. Подключите модель к рабочим процессам Jira Service Management
Команда добавляет поля Активов в рабочие процессы инцидентов и изменений, чтобы инженеры и операторы могли выбрать затронутую службу или элемент конфигурации. При создании нового инцидента ответственные специалисты могут сразу увидеть связанное приложение, его владельца, среду и соответствующие зависимости.
Это сокращает время, затрачиваемое на базовые вопросы для сортировки обращений, и помогает командам раньше привлекать нужных специалистов.
Шаг 4. Используйте модель во время инцидента
Зарегистрирован инцидент в связи с повышенным числом ошибок в приложении для клиентов. Специалист по реагированию связывает затронутую службу в Jira Service Management и просматривает связанные элементы конфигурации. Они видят, что приложение зависит от общего API аутентификации и кластера базы данных.
Недавнее изменение уже связано с API аутентификации. Эта подсказка помогает команде быстро сузить область расследования и привлечь нужных ответственных, не действуя наугад.
Шаг 5. Улучшите планирование будущих изменений
После инцидента команда начинает использовать те же взаимосвязи служб при проверке изменений. Прежде чем развертывать обновления, они могут заранее определить, какие зависимые сервисы могут быть затронуты, и скоординировать свои действия с нужными командами.
Как это выглядит на практике
Этап | Чем занимается команда | Операционная ценность |
Моделирование службы | Создайте объекты служб, приложений, сред и зависимостей в модуле «Активы» | Создает удобную CMDB для разработки и эксплуатации |
Повышение качества данных | Используйте диспетчер данных для сверки данных из нескольких систем. | Повышает достоверность данных о владении и зависимостях |
Подключение рабочих процессов | Связывайте сервисы и элементы конфигурации с инцидентами и изменениями | Предоставляет командам контекст там, где они уже решают задачи |
Ускоренный разбор задач | Использование зависимостей во время инцидентов | Сокращает время на изучение и эскалацию. |
Эффективное планирование изменений | Проверьте затронутые сервисы и компоненты перед внедрением | Повышает осведомленность о рисках и улучшает координацию |
Как подойти к внедрению
Если вы создаете эту возможность для команд инженеров или разработчиков приложений, поэтапное развертывание обычно работает лучше всего.
Начните с одного критически важного приложения или одной критически важной службы, которые часто упоминаются в инцидентах или изменениях.
Определите минимальный полезный набор элементов конфигурации и связей.
Используйте диспетчер данных, чтобы повысить качество исходных данных перед широким масштабированием.
Сначала добавьте контекст Активов в рабочие процессы инцидентов и изменений, где это создает непосредственную операционную ценность.
Постепенно расширяйте CMDB по мере того, как команды доказывают полезность и удобство обслуживания модели.
Good first milestone: make it easy for a responder or approver to answer what service is affected, what supports it, who owns it, and what else may be impacted.
В центре внимания: Lucid Motors
[Активы — это] абсолютно незаменимая часть нашей инфраструктуры Jira, и, честно говоря, я не знаю, как можно заниматься разработкой оборудования в Jira, не отслеживая это оборудование в том же разделе. Потому что, когда мы пытались сделать это с помощью разрозненных инструментов для отслеживания оборудования… в наших системах не было заложено никакой возможности для отслеживания. И если вы пытались делать всё это в других инструментах, то и в этом нет никакой гибкости. Так что мы действительно нашли то, что нам подходит.
Фелипе Луизи, старший руководитель по продукту, Lucid Motors
Часто задаваемые вопросы
Что такое управление активами приложений и служб?
Управление активами приложений и служб — это практика отслеживания приложений, служб, зависимостей, сред, элементов конфигурации и прав владения в рамках единой связанной модели. Это дает командам разработки и эксплуатации надежный контекст для инцидентов, изменений, запросов и планирования служб.
Как Assets помогают командам по разработке приложений?
Assets предоставляют структурированную CMDB для моделирования приложений, API, баз данных, сред, облачных ресурсов и команд, которые ими владеют. Команды могут связывать этот контекст с инцидентами и изменениями в Jira Service Management, чтобы быстрее оценивать влияние, распределять задачи и устранять неполадки.
В чем разница между CMDB и реестром активов?
Реестр активов содержит записи о том, что существует, в то время как CMDB также фиксирует, как элементы конфигурации связаны друг с другом и поддерживают службу. Активы могут выполнять обе функции, храня сведения о приложениях и службах вместе с их зависимостями, информацией о владении и операционном контексте.
Как команды могут улучшить качество данных приложений и служб?
Используйте диспетчер данных Assets, чтобы объединять, очищать, нормализовать и согласовывать записи из нескольких источников перед их публикацией в рабочей модели. Начните с данных, необходимых для критических инцидентов и изменений, а затем расширяйте их по мере того, как модель службы докажет свою пользу и удобство в обслуживании.