開発チーム向けアプリおよびサービスの資産管理
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 を使用すると、チームはアプリやサービスの構成アイテムを追跡し、それらを開発作業に関連付け、スタック全体の関係を理解して、所有者をすばやく特定できます。
これにより、アプリ開発チームは、より安全に変更を行い、インシデントをより迅速に解決し、調整のオーバーヘッドを削減して、より安心して信頼性の高いサービスをビルドおよび運用できるようになります。
アプリおよびサービスの資産管理とは
アプリおよびサービスの資産管理とは、運用の可視性を向上させるために、アプリおよびサービスのライフサイクル、所有権、依存関係を追跡するプラクティスです。アプリをリレーショナル データベース、Web サービス、マイクロサービス、またはクラウド環境などのインフラストラクチャに接続することで、チームはインシデントのリスクを軽減し、デプロイを迅速化するために必要なサービスのコンテキストを得ることができます。
密接に関連するいくつかの機能を組み合わせています。
サービス構成管理: サービス、アプリ、データベース、API、クラウドリソース、およびそれらの関係に関する正確な情報を維持します。
資産および構成の追跡: ソフトウェア アプリの配信と本番運用をサポートするシステムとコンポーネントを整理します。
サービス マネジメント ワークフロー: そのコンテキストをインシデント、変更、リクエスト、承認、レポートに適用します。
Service Collection では、アセットがこのデータの構造を提供します。アセットは、すべての構成レコードと時間の経過に伴うそれらの関係を保存する CMDB であり、チームが何が存在するかだけでなく、コンポーネントがどのように接続されているかを理解するのに役立ちます。
チームが運用で利用する前に、Service Collection の Assets データ マネージャーが複数のソースからのレコードを統合および照合し、データ品質の向上を支援します。
開発者にとってアプリおよびサービスの資産管理が重要である理由
アプリとコンポーネントの情報がスプレッドシートやサイロ化されたシステムに分散していると、企業がどのアプリを実行しているか、それらがどのように使用されているか、そして重要な点として、何かが変更されたときに何に障害が発生するかを明確に把握することが困難になります。
Service Collection アセットは、すべてのアプリとコンポーネントのデータを 1 か所に集約する、構造化されてクエリ可能な CMDB を提供し、分散したスプレッドシートを、リアルタイムで接続されたレジストリに置き換えます。
アトラシアン アセットは、アプリやサービスのカタログを、構造化された検索可能な単一の CMDB に一元化し、分散したスプレッドシートやサイロ化したツールを、連携された最新のレコードに置き換えます。アプリ、コンポーネント、インフラストラクチャ間の依存関係をマッピングして Jira Service Management のワークフローに直接連携するため、チームは所有しているもの、その所有者、変更時に影響を受けるものを常に把握できます。
変更の影響をより迅速に評価: チームは、変更をリリースする前に、どのアプリ、環境、または依存サービスが影響を受ける可能性があるかを把握できます。
インシデント対応の改善: 対応者は、サービスの所有者、アップストリームおよびダウンストリームの依存関係、影響を受ける可能性のあるインフラストラクチャを迅速に特定できます。
コンテキスト スイッチの削減: 開発者とオペレーターは、Jira Service Management ワークフロー内で直接、サービスと資産のコンテキストにアクセスできます。
サービスのオーナーシップの強化: チームは、オーナーシップ、サポートの責任、および依存関係のデータをより簡単に見つけて維持できるようになります。
アプリ サービスと運用データの信頼性を向上: Assets データ マネージャーは、クラウド ツール、ディスカバリ ツール、および内部システムからのレコードを照合し、よりクリーンな信頼できる情報源に統合するのに役立ちます。
運用チームとのコラボレーションを強化: 共有された構成コンテキストにより、変更やインシデントの発生時に、エンジニアリングと運用が同じ理解に基づいて作業できるようになります。
Service Collection がアプリおよびサービスを意識した開発をサポートする仕組み
Service Collection は、開発チームや運用チームが、重要なワークフローに構成データを取り込むのに役立ちます。サービス モデルを日々の作業から切り離すのではなく、チームはアプリ、サービス、依存関係をリクエスト、インシデント、変更に直接関連付けることができます。
アセットでサービス中心の CMDB を生成する
アセットを使用すると、チームはソフトウェアやアプリの配信と運用に重要なコンポーネントのオブジェクト スキーマを定義し、インフラストラクチャやリレーショナル データベースをマッピングできます。これには、ビジネス サービス、アプリ、環境、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 を使用すると、チームはチケットビューから直接、リクエストや変更を資産オブジェクトに関連付けることができます。つまり、インシデントは影響を受けるアプリやサービスにリンクできる一方で、変更は関連する環境やインフラストラクチャを参照できるということです。
リンクされると、対応者と承認者はコンテキストをより詳細に把握できます。どのサービスが関連しているか、誰が所有しているか、他のどのコンポーネントが影響を受ける可能性があるか、関連する作業がすでに進捗しているかどうかを確認できます。
リレーションシップのコンテキストでトラブルシューティングの迅速化をサポート
サービス レコードはそれ自体でも役立ちます。依存関係と結びついたサービス レコードは、はるかに強力です。関連データは、チームが「何かに問題がある」という段階から「この特定の依存関係が原因かもしれない」という段階へ、より迅速に移行するのに役立ちます。
たとえば、Web アプリのパフォーマンスが低下した場合、チームはリンクされたデータベース、認証プロバイダー、キュー、およびクラウド環境をレビューして、調査を絞り込むことができます。その共有ビューは、開発チームと運用チームにサービスの共通マップを提供することで、インシデントのスウォーミングをサポートすることもできます。
自動化を活用して、運用ワークフローを円滑に進めます。
自動化により、チームは追加の手作業を行うことなく、サービスと構成のコンテキストに基づいて対応できるようになります。チームは、状態やリンクされたオブジェクトの変更に基づいて、通知をトリガーしたり、チケットをルーティングしたり、フォローアップタスクを作成したり、レコードをアップデートしたりできます。
一般的な例:
選択したサービスまたは所有チームに基づくインシデントのルーティング
クリティカルな依存関係が変更された際のフォローアップタスクの作成
インシデントが優先度の高いサービスに影響を及ぼした場合のステークホルダーへの通知
標準の運用チェックを特定の環境やコンポーネントに関連付ける
ウォークスルーの例: サービスモデルから、より迅速なインシデントのトリアージ、根本原因の特定、解決まで
ここでは、Jira Service Management とアセットを使用して、Service Collection でアプリとサービスの資産管理がどのように機能するかについて、実践的な例をご紹介します。
シナリオ
プラットフォームエンジニアリングチームは、社内開発者向けポータルと複数の顧客向けアプリをサポートしています。サービスの所有権は部分的に文書化されていますが、依存関係の情報は一貫性がなく、図、クラウド ツール、チームのナレッジに分散しています。
インシデントが発生すると、対応者は何が変更されたか、どのコンポーネントが関連しているかを把握するのに多くの時間を費やしています。
ステップ 1: サービス モデルを定義する
チームは、ビジネス サービス、アプリ、環境、データベース、API、および所有チームを含む、CMDB 内のキー構成アイテムを表すアセット スキーマを作成します。まず、価値の高い 1 つのアプリ サービスから始め、その最も重要な依存関係をマッピングします。
次のような関係を定義します。
アプリは 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 を構築する |
データ品質を向上させる | データ マネージャーを使用して、複数のシステムからのデータを照合する | オーナーシップと依存関係データの信頼性を高める |
ワークフローをつなげる | サービスと構成アイテムをインシデントと変更にリンクする | チームがすでに作業している場所でコンテキストを提供する |
トリアージの迅速化 | インシデント発生時に依存関係を使用する | 調査とエスカレーションの時間を短縮する |
変更をより適切に計画する | 実装前に、影響を受けるサービスとコンポーネントを確認する | リスク認識と連携を向上させる |
実装の進め方
エンジニアリングチームやアプリ開発チーム向けにこの機能を構築する場合は、通常、段階的なロールアウトが最適です。
インシデントや変更に頻繁に関わる 1 つのクリティカルなアプリまたはサービスから始めます。
最小限の有用な構成アイテムと関係のセットを定義します。
大規模に展開する前に、データ マネージャーを使用してソース データの品質を向上させます。
まず、即座に運用上の価値を生み出すインシデントおよび変更ワークフローに、アセットのコンテキストを追加します。
チームがモデルの有用性と保守性を実証しながら、段階的に 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 でハードウェアを追跡もせずに、同じスペースでハードウェア エンジニアリングをどのように行えるのか想像もつきません。分断されたハードウェア追跡ツールで追跡を試行したところ、当社のシステムには固有のトレーサビリティがありませんでした。それらの他のツールですべてを行おうとしても、俊敏性は得られないでしょうそのため、本当に自分たちに合ったものを見つけることができました。
Felipe Luisi 氏、シニア プロダクト マネージャー、Lucid Motors
よくある質問
アプリおよびサービスの資産管理とは
アプリおよびサービスの資産管理は、アプリ、サービス、依存関係、環境、構成アイテム、および所有権を連携されたモデルで追跡するプラクティスです。開発チームと運用チームに、インシデント、変更、リクエスト、サービス計画に関する信頼できるコンテキストを提供します。
アセットはアプリ開発チームをどのようにサポートしますか。
アセットは、アプリケーション、API、データベース、環境、クラウド リソース、およびそれらを所有するチームをモデリングするための構造化された CMDB を提供します。チームは、このコンテキストを Jira Service Management のインシデントや変更にリンクして、影響を評価し、作業をルーティングし、より迅速にトラブルシューティングを行うことができます。
CMDB と資産インベントリの違いは何ですか。
資産インベントリは何が存在するかを記録するのに対し、CMDB は構成アイテムが互いにどのように関連し、サービスをサポートしているかも記録します。アセットは、アプリとサービスのレコードを、それらの依存関係、所有権、および運用コンテキストとともに保存することで、両方の役割を果たすことができます。
チームはどのようにしてアプリとサービスのデータの品質を向上させることができますか。
Assets データ マネージャーを使用して、ワーキングモデルに公開する前に、複数のソースからのレコードを統合、クレンジング、正規化、および照合します。クリティカルなインシデントや変更に必要なデータから始め、サービス モデルが有用で保守可能であることが確認できたら拡張します。