Gestão de recursos de aplicativo e serviço para equipes de desenvolvimento
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
Desenvolva e opere aplicativos com melhor contexto de serviço
A gestão de recursos de aplicativos e serviços é fundamental para as equipes de desenvolvimento de aplicativos, pois os produtos digitais modernos dependem de uma rede de aplicativos, serviços, ambientes, infraestrutura e componentes de terceiros.
Quando as informações sobre aplicativos, dependências, propriedade e sistemas de suporte estão espalhadas por tickets, consoles de nuvem, planilhas e conhecimento empírico, as equipes têm menos visibilidade sobre o impacto das mudanças, o risco de incidentes e a integridade do serviço.
Essa falta de contexto pode atrasar a entrega e aumentar a probabilidade de interrupções ou de uma solução de problemas mal direcionada.
Aplicativos para desenvolvedores e a gestão de recursos de serviço reúnem esse contexto em um modelo confiável e compartilhado. Com o Service Collection, as equipes podem monitorar itens de configuração de aplicativos e serviços, conectá-los aos tickets de desenvolvimento, entender as relações em toda a stack e identificar os responsáveis rapidamente.
Isso ajuda as equipes de desenvolvimento de aplicativos a fazer alterações mais seguras, resolver incidentes mais rápido, reduzir a sobrecarga de coordenação e fazer o build e operar serviços confiáveis com mais confiança.
O que é a gestão de recursos de aplicativos e serviços?
A gestão de recursos de aplicativos e serviços é a prática de acompanhar o ciclo de vida, a propriedade e as dependências de aplicativos e serviços para melhorar a visibilidade operacional. Ao conectar aplicativos à infraestrutura, como bancos de dados relacionais, serviços web, microsserviços ou ambientes em nuvem, as equipes ganham o contexto de serviço necessário para reduzir o risco de incidentes e acelerar as implantações.
Ele combina várias capacidades intimamente relacionadas:
Gerenciamento de configuração de serviço: manter informações precisas sobre serviços, aplicativos, bancos de dados, APIs, recursos de nuvem e as relações entre eles.
Rastreamento de ativos e configurações: organização dos sistemas e componentes que dão suporte à entrega de aplicativos de software e às operações de produção.
Fluxos de trabalho de gerenciamento de serviços: aplicando esse contexto a incidentes, mudanças, solicitações, aprovações e relatórios.
No Service Collection, os Recursos fornecem a estrutura para esses dados. Recursos é o seu CMDB que armazena todos os registros de configuração e seus relacionamentos ao longo do tempo, ajudando as equipes a entender não apenas o que existe, mas como os componentes se conectam.
O Gerenciador de dados de Recursos do Service Collection então ajuda a melhorar a qualidade dos dados consolidando e reconciliando registros de várias fontes antes que as equipes dependam deles operacionalmente.
Por que a gestão de recursos de aplicativos e serviços é importante para desenvolvedores
Quando as informações de aplicativos e componentes estão espalhadas por planilhas e sistemas isolados, fica difícil ter uma visão clara de quais aplicativos uma empresa executa, como eles são usados e, principalmente, o que quebra quando algo muda.
Os Recursos do Service Collection oferecem a você um CMDB estruturado e consultável que reúne todos os dados de aplicativos e componentes em um só lugar — substituindo planilhas dispersas por um registro ativo e conectado.
O Recursos da Atlassian centraliza o seu catálogo de aplicativos e serviços em um único CMDB estruturado e pesquisável, substituindo planilhas dispersas e ferramentas isoladas por registros ativos e conectados. Ele mapeia as dependências entre aplicativos, componentes e infraestrutura e se integra diretamente aos fluxos de trabalho do Jira Service Management, para que as equipes sempre saibam o que têm, quem é o responsável e o que é afetado quando ocorrem mudanças.
Avalie o impacto da mudança mais rápido: as equipes podem entender quais aplicativos, ambientes ou serviços dependentes podem ser afetados antes de implementar uma mudança.
Melhore a resposta a incidentes: Os responsáveis pela resposta podem identificar rapidamente o proprietário do serviço, as dependências anteriores e posteriores e a infraestrutura possivelmente afetada.
Reduza a alternância de contexto: Desenvolvedores e operadores podem acessar o contexto de serviços e recursos diretamente nos fluxos de trabalho do Jira Service Management.
Fortaleça a propriedade do serviço: As equipes podem tornar os dados de propriedade, responsabilidade de suporte e dependência mais fáceis de encontrar e manter.
Aumente a confiança nos serviços de aplicativo e nos dados operacionais: O Gerenciador de dados de Recursos ajuda a conciliar registros de ferramentas em nuvem, ferramentas de descoberta e sistemas internos em uma fonte de verdade mais limpa.
Promova uma colaboração melhor com as equipes de operações: O contexto de configuração compartilhado ajuda as equipes de engenharia e operações a trabalharem no ticket com o mesmo entendimento durante alterações e incidentes.
Como o Service Collection oferece suporte ao desenvolvimento com reconhecimento de aplicativos e serviços
O Service Collection ajuda as equipes de desenvolvimento e operações a levar dados de configuração para os fluxos de trabalho onde mais importam. Em vez de manter os modelos de serviço separados dos tickets do dia a dia, as equipes podem conectar aplicativos, serviços e dependências diretamente a solicitações, incidentes e mudanças.
Gerar um CMDB centrado em serviços com Recursos
O Recursos permite que as equipes definam esquemas de objeto para os componentes essenciais para a entrega e as operações de software e aplicativos e, em seguida, mapeiem a infraestrutura e os bancos de dados relacionais. Isso pode incluir serviços de negócios, aplicativos, ambientes, APIs, bancos de dados, filas, recursos de nuvem, repositórios e equipes de suporte.
Em um CMDB, esses itens de configuração podem ser vinculados por meio de relacionamentos que refletem como os serviços realmente funcionam. Por exemplo, um aplicativo voltado para o cliente pode depender de um gateway de API, um cluster de banco de dados, uma infraestrutura em nuvem e uma equipe proprietária. Esse modelo conectado se torna útil quando as equipes precisam entender o impacto rapidamente.
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.
Use o Gerenciador de dados de Recursos para melhorar a qualidade dos dados
Os dados de aplicativos e serviços costumam vir de vários lugares: plataformas em nuvem, ferramentas de descoberta, planilhas, documentação interna e sistemas de engenharia. Se essas fontes divergirem, as equipes perdem a confiança no modelo.
O Gerenciador de dados de Recursos ajuda a consolidar, limpar e reconciliar dados de várias fontes em um registro operacional mais confiável. Isso facilita normalizar as convenções de nomenclatura, reduzir duplicatas e identificar lacunas antes que afetem incidentes, auditorias ou aprovações.
Para as equipes de engenharia e plataforma, isso significa mais confiança na propriedade de serviços, nos registros de ambiente e nos dados de dependência.
Mapeie serviços de negócios com serviços de aplicativo e ativos para acessar o impacto de incidentes e mudanças.
O Jira Service Management permite que as equipes associem solicitações ou alterações a objetos de Ativo diretamente da visualização do ticket. Isso significa que um incidente pode ser vinculado ao aplicativo ou serviço afetado, enquanto uma alteração pode fazer referência ao ambiente ou à infraestrutura que ela envolve.
Depois de vinculados, os responsáveis pela resposta e os aprovadores têm um contexto melhor. Eles podem ver qual serviço está envolvido, quem é o responsável, quais outros componentes podem ser afetados e se algum ticket relacionado já está em progresso.
Apoie uma solução de problemas mais rápida com o contexto de relacionamento
Um registro de serviço por si só é útil. Um registro de serviço conectado às suas dependências é muito mais poderoso. Os dados de relacionamento ajudam as equipes a passar de “algo está quebrado” para “esta dependência específica pode ser a causa” mais rápido.
Por exemplo, se um aplicativo da web estiver degradado, a equipe pode analisar o banco de dados vinculado, o provedor de autenticação, a fila e o ambiente em nuvem para restringir a investigação. Essa visualização compartilhada também pode apoiar o swarming de incidentes ao fornecer às equipes de desenvolvimento e operações um mapa comum do serviço.
Use a automação para manter os fluxos de trabalho operacionais em andamento
A Automação pode ajudar as equipes a agir com base no contexto de serviço e configuração sem trabalho manual extra. As equipes podem acionar notificações, encaminhar tickets, criar tarefas de acompanhamento ou atualizar registros com base em alterações de estado ou objetos vinculados.
Exemplos comuns incluem:
Roteamento de incidentes com base no serviço selecionado ou na equipe responsável
Criar tarefas de acompanhamento quando uma dependência crítica é alterada
Notificar as partes interessadas quando incidentes afetam serviços de alta prioridade
Associar verificações operacionais padrão a ambientes ou componentes específicos
Exemplo de passo a passo: do modelo de serviço à triagem de incidentes, causa raiz e resolução mais rápidas
Aqui está um exemplo prático de como a gestão de recursos de aplicativos e serviços pode funcionar no Service Collection com o Jira Service Management e o Recursos.
Cenário
Uma equipe de engenharia de plataforma oferece suporte a um portal interno de desenvolvedores e a vários aplicativos voltados ao cliente. A propriedade do Serviço está parcialmente documentada, mas as informações de dependência são inconsistentes e estão espalhadas por diagramas, ferramentas de nuvem e pelo conhecimento da equipe.
Quando ocorrem incidentes, as equipes de resposta gastam muito horário tentando descobrir o que mudou e quais componentes estão envolvidos.
Etapa 1: Defina o modelo de serviço
A equipe cria um esquema de Recursos para representar os principais itens de configuração em seu CMDB, incluindo serviços de negócios, aplicativos, ambientes, bancos de dados, APIs e equipes responsáveis. Elas começam com um serviço de aplicativo de alto valor e mapeiam suas dependências mais importantes.
Elas definem relacionamentos como:
Aplicativo depende do serviço de API
O serviço de API depende do cluster de banco de dados
O aplicativo é executado em ambiente de produção
A equipe de plataforma é responsável pela infraestrutura de tempo de execução.
Etapa 2: Consolidar dados de origem com o Gerenciador de dados
A equipe usa o Gerenciador de dados para reunir registros de inventários em nuvem, planilhas internas e documentação de serviço existente. Nomes de aplicativos duplicados são reconciliados, proprietários ausentes são sinalizados e registros desatualizados são limpos antes da publicação no modelo de trabalho.
Outcome: the team now has a cleaner, more trustworthy service model rather than relying on competing versions of the truth.
Etapa 3: Conecte o modelo aos fluxos de trabalho do Jira Service Management
A equipe adiciona campos de Recursos aos fluxos de trabalho de incidente e mudança para que as equipes de engenharia e operação possam selecionar o serviço ou item de configuração afetado. Quando um novo incidente é criado, os responsáveis pela resposta podem ver imediatamente o aplicativo vinculado, o proprietário, o ambiente e as dependências relacionadas.
Isso reduz o tempo gasto com perguntas básicas de triagem e ajuda as equipes a envolver as pessoas certas mais cedo.
Etapa 4: Use o modelo durante um incidente
Um incidente foi relatado devido a erros elevados em um aplicativo voltado ao cliente. O(a) responsável vincula o serviço afetado no Jira Service Management e revisa os itens de configuração relacionados. Eles veem que o aplicativo depende de uma API de autenticação compartilhada e de um cluster de banco de dados.
Uma alteração recente já está associada à API de autenticação. Essa pista ajuda a equipe a restringir a investigação rapidamente e envolver os responsáveis certos sem precisar adivinhar.
Etapa 5: Melhorar o planejamento de mudanças futuras
Após o incidente, a equipe começa a usar os mesmos relacionamentos de serviço durante as revisões de mudança. Antes de lançar atualizações, eles podem ver quais serviços dependentes podem ser afetados e se coordenar com as equipes certas com antecedência.
Como é na prática
Estágio | O que a equipe faz | Valor operacional |
Modelar o serviço | Cria objetos de serviço, aplicativo, ambiente e dependência em Recursos | Cria um CMDB prático para engenharia e operações |
Melhorar a qualidade dos dados | Usa o Gerenciador de dados para reconciliar dados de vários sistemas. | Cria mais confiança nos dados de propriedade e de dependência |
Conectar fluxos de trabalho | Vincula serviços e itens de configuração a incidentes e alterações | Dá contexto às equipes onde elas já trabalham |
Fazer a triagem mais rápido | Usa relacionamentos de dependência durante incidentes | Reduz o tempo de investigação e escalonamento |
Planeje melhor as mudanças | Revisa os serviços e componentes afetados antes da implementação | Melhora a conscientização sobre riscos e a coordenação |
Como abordar a implementação
Se você estiver criando essa capacidade para equipes de engenharia ou de desenvolvimento de aplicativos, uma implementação em fases costuma funcionar melhor.
Comece com um aplicativo ou serviço crítico que aparece com frequência em incidentes ou mudanças.
Defina o conjunto mínimo útil de itens de configuração e relacionamentos.
Use o Gerenciador de dados para melhorar a qualidade dos dados de origem antes de escalar amplamente.
Adicione primeiro o contexto do Recursos aos fluxos de trabalho de incidente e de alteração, onde isso cria valor operacional imediato.
Expanda o CMDB gradualmente à medida que as equipes comprovam que o modelo é útil e sustentável.
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.
Cliente em destaque: Lucid Motors
[O Recursos é uma] parte absolutamente crucial da nossa infraestrutura do Jira, e, francamente, não sei como você poderia fazer engenharia de hardware com o Jira sem também rastrear seu hardware no mesmo espaço. Porque quando tentamos fazer isso com ferramentas fragmentadas de rastreamento de hardware… não havia rastreabilidade inerente aos nossos sistemas. E, se você tentasse fazer tudo nessas outras ferramentas, também não haveria agilidade nisso. Então, nós realmente encontramos algo que funciona para nós.
Felipe Luisi, Gerente de Produto Sênior, Lucid Motors
Perguntas mais frequentes
O que é a gestão de recursos de aplicativos e serviços?
A gestão de recursos de aplicativos e serviços é a prática de acompanhar aplicativos, serviços, dependências, ambientes, itens de configuração e propriedade em um modelo conectado. Ela fornece às equipes de desenvolvimento e operações um contexto confiável para incidentes, mudanças, solicitações e planejamento de serviços.
Como o Recursos ajuda as equipes de desenvolvimento de aplicativos?
O Recursos oferece um CMDB estruturado para modelar aplicativos, APIs, bancos de dados, ambientes, recursos de nuvem e as equipes responsáveis por eles. As equipes podem vincular esse contexto a incidentes e mudanças do Jira Service Management para avaliar o impacto, encaminhar o ticket e solucionar problemas mais rápido.
Qual é a diferença entre um CMDB e um inventário de recursos?
Um inventário de recursos registra o que existe, enquanto um CMDB também captura como os itens de configuração se relacionam entre si e dão suporte a um serviço. Os Recursos podem servir como ambos ao armazenar registros de aplicativo e serviço junto com suas dependências, propriedade e contexto operacional.
Como as equipes podem melhorar a qualidade dos dados de aplicativos e serviços?
Use o Gerenciador de dados do Recursos para consolidar, limpar, normalizar e reconciliar registros de várias fontes antes de publicá-los no modelo de trabalho. Comece com os dados necessários para incidentes críticos e mudanças e, em seguida, expanda à medida que o modelo de serviço se mostrar útil e fácil de manter.