JSM & オペレーション（opsgenie）統合に おける権限と運用の最適化

Transcript

1. 株株株株 Brillio JSM & オペレーション（opsgenie）統合に おける権限と運用の最適化 複雑な概念の整理と、自動化されたワークフロー の実現について
2. 背景： Jira Service Management (JSM) に Opsgenie (Operations機能) を統合したことで、管理すべき概念が増加。 現状の混乱ポイント： • 「グループ」「プロジェクトロール」「Opsチーム」「Opsロール」が混在し、それぞれの役割 範囲が不明確。 • 「JSM側で権限をつけたのに、通知が飛ばない/チームルール内に入れない」といった 問題が発生 整理目的： • Atlassian仕様に基づき、概念を整理する。 • 監視ツール連携、自動化、Playbookを含む運用フロー全体像を可視化する。 01 現状の課題と複雑性
3. 複雑さを解くカギは、するにはシステムが3つの層に分かれた権限管理していること を理解することにある。 02 権限管理の階層 階層 該当機能 管理対象・役割 1. Jira Cloudアカウント 層 Access / 管理ハブ アイデンティティとログイン ユーザーそのものと、所属する「グループ」を管理する大元の 層。 2. JSMスペース （プロジェクト層） Jira Service Management チケット管理とプロセス ITSM業務、SLA、Automation、Playbook等を管理。「プロジェク トロール」でチケット操作権限を制御。 3. Operation （Opsgenie層） Operation機能 障害通知、通知元との結合（Integrations） アラート対応、オンコールスケジュール、結合、メンテ設定等 管理。「チーム」が主役
4. 03 Jira Cloud全体の構造と管理レイヤー Atlassian プラットフォーム（admin.Atlassian.com） 1.グローバル設定（組織全体） ユーザ管理 / SSO / セキュリティ / 請求 Jira Cloud（統合UI） 2.Jira製品設定（全プロダクト共通） 画面 / ワークフロー / 権限スキーム/ アプリ管理 Jira Software （開発 ・ スクラム） Jira Service Management （JSM） （ITSM ・ ヘルプデスク） Operations（旧 Opsgenie） （アラート・オンコール等） 4. Operations 設定画面 オンコール ・ 統合 ・ メンテ… スペース（旧プロジェクト）の世界 3. ソフトウェアスペース設定 ボード設定 / ツール連携 3. サービス管理スペース設定 SLA / 自動化 / リクエストタイプ 設定…
5. JSM内にOperationsは、統合されているものの管理については 目的が異なるため管理方法も異なる。 04 JSMロールとOpsチームの違い JSMプロジェクトロール Operationロール 目的： チケット（課題）の作業権限管理。 できること： チケットの閲覧、コメント、ステータス変更、SAL閲覧 など 注意点： ここに属していても、アラーム通知は届かない 目的： インシデント発生時のメンバー、チーム権限管理。 できること： オンコールシフトへのアサイン、通知ルールの受取、ア ラートのAck/Close等 注意点： オンコールやエスカレーションはチーム単位で管理され、 実際の対応はユーザー（人）が行う ※両者の権限は自動では同期しません。運用フローとして明示的に管理する必要がある。
6. 05 概念構造図（全体イメージ） ユーザーA （運用担当） ユーザーB （閲覧者） グループ：スペースA/B [製品制限：User（agent）] グループ：スペースA [製品制限：Customer] ロール：Service Desk Team （チケット対応） ロール：Service Desk Team （チケット対応） ロール：閲覧者 （チケット閲覧のみ） 2.JSM スペース（プロジェクト）層 （スペースごとのロール割り当て） スペースA スペースB インシデントチケットA 課題・タスクチケットB 3.Operation（Opsgenie）層 （通知） Operationアラート ルーティング 所属 ロール割当 対応・更新 閲覧 対応・更新 1.JiraCloudアカウント層 （製品アクセス権限とグループ） スペースA用 [スケジュール/通知] 監視ツール （例：Zabbix） Integrations （アラート受信・JSM） アラート作成 ユーザーB チームA
7. 06 複数スペース運用におけるグループ設計 【課題】 標準グループのみの運用 【解決策】 自作グループの活用 ✕ 標準グループ （jira-servicemanagement-users） [各PJの全メンバー] スペースA ロール：Agent スペースB ロール：Agent 各スペース設定 ・ 「JSMを使える人」 = 「全スペースの担当者」になってしまう ・スペースごとの細かいアクセス制御ができない ・管理対象スペースが増えていくと管理が行き詰まる 自作グループA （Aシステム） [5名] スペースA ロール：Agent スペースB ロール：Agent 各スペース設定 ・ 「役割」ごとに箱（グループ）を作ることで整理 ・スペースが増えてもグループを割り当て管理 ・セキュリティと運用効率の両立が可能 自作グループB （Bシステム） [10名] アクセス不可 （セキュア） 全員アクセス可 （情報漏洩リスク） 適切な人のみ アクセス
8. 07 Operation独自の権限体系 「通知対象」と「操作権限」が分離。チームにいるだけでは操作できない点に注意 Operations 設定 Operation ユーザー チーム Opsロール ・ アラートルーティング先 ・ オンコールスケジュール ・ エスカレーションポリシー ・ アラート操作権限 ・ 設定変更権限 （Jira管理画面で作成） 通知単位 ロール割当（操作権限付与） 【重要】 チーム所属 ≠ 操作権限 チームに所属していても、適切なOpsロールが 割り当てられていないとアラート操作等はできない
9. 08 統合フロー&権限構造図（詳細） ユーザーA （運用担当） ユーザーB （閲覧者） グループ：スペースA/B [製品制限：User（agent）] グループ：スペースA [製品制限：Customer] ロール：Service Desk Team （チケット対応） ロール：閲覧者 （チケット閲覧のみ） 2.JSM スペース（プロジェクト）層 （スペースごとのロール割り当て） インシデントチケットA 自動起票 （Integrations） 所属 ロール割当 （作業担当者） 1.JiraCloudアカウント層 （製品アクセス権限とグループ） Automation （チケット内自動化： ステータス更新等） Playbook （運用標準化・トラッキング） 連動 対応・更新 閲覧 スペースA ロール割当 （閲覧者） 自動更新 プロセス開始 3.Operation（Opsgenie）層 （通知） Operationアラート ルーティング スペースA用 [スケジュール/通知] 監視ツール （例：Zabbix） Integrations （アラート受信・JSM） アラート作成 ユーザーB チームA
10. 09 JSMとOperationsの連携フロー 監視ツール （Zabbix / CloudWatch等） Operations（旧Opsgenie） アラート・オンコール JSMスペース インシデントチケット管理 Automation （自動化ルール） アラート発報（Integration経由） アラート作成 & 担当チームへ通知 アラート作成イベントをトリガー インシデントチケット自動起票 1. アラート発報からチケット起票まで 2. ステータス更新（Automation等で実装） アラートを「承認（Ack）」 ステータス変更イベント チケットステータスを「進行中」へ変更 ※Jira Softwareとは異なり、 JSMは標準のSync機能は利 用できない。Automationでの 設定が必要 例：担当者が対応開始 アラートを「クローズ」 チケットを「解決済み」へ変更 ステータス変更イベント 例：JSM側で解決
11. 自動化された運用フロー 10 運用の実装（自動化とセキュリティ） 外部連携と自動化： ・監視ツールからのアラートをOperationで受けるにはIntegrationsでJSMと統合 ・JSMのAutomation機能がトリガーされ、指定のスペースにインシデントチケットを自動起票 標準化とトラッキング： ・起票されたチケットに Playbook を関連付けることで、対応プロセスを標準化し、対応状況を 可視化・振り返り可能な形でトラッキングできる。 セキュアなアクセス管理： ・スペースの閲覧者、管理者は「グループ」単位でロールに割り当て、関係者外からのアクセス をセキュアに制限する。
12. 運 用 の た め の ベ ス ト プ ラ テ ィ ク ス 11 運用のためのベストプラティクス 1. 権限管理は「グループ」を基本とする • 個人に直接プロジェクトロールを割り当てず、 Jira Cloud のグループをプロジェクトロー ルに割り当てることで、権限管理の一元化と運用負荷の低減を図る。 2. Operationは「チーム」を軸に • オンコールや通知設定は、個人ではなく「チーム」に対して設定する。 3. メンバー追加フローの確立 • 運用メンバーが増えた際は、「Jiraのグループへの追加」と「Opsgenieチームへの追加」 の2作業が必須であることをマニュアル化、自動化する。