本記事について
この記事は実際に検証してきた挙動を踏まえ、
Atlassianの設計思想 × 実際の挙動 × こういう要件ありそうだなを統合した内容とする。
記載して....すごくニッチで役立つ人は自分自身な気が
1. Operations（Opsgenie）の全体構造
Jira Service Management（JSM）
└ Operations（アラート管理機能：旧 Opsgenie）
└ 概要（各チームのメニュー）
├ On-call（オンコール）
├ Integrations（外部監視との連携）
├ Sync（Jira Software との双方向同期）
├ Heartbeat（死活監視）
├ policies（アラート生成後の処理ルール）
├ maintenance（アラート抑止）
└ ...
2. Integrations（統合）の種類と役割
2-1.Integrationとは
外部システム（AWSやAzure、WebAPI）とJSM Operationsのアラート機能を紐づける連携レイヤー
2-2.主な目的、できること
- 外部システムから”アラート”を受信する入口
- Alertの内容を書き換える / ルーティングする
- どのチームにルーティングするか
- どの優先度にするか
- どの対応者（Responder Team）を設定するか
- どのアラートプロパティを書き換えるか
- JSM（または外部システム）への”Outbound”
2-3.Integrationが存在する場所は２種類存在する。
- ➀ チーム側のIntegrations
- ➁ Jira管理者設定側のIntegrations（Global/Admin Integrations）
チーム側Integrationsの特徴
| 項目 | 内容 |
|---|---|
| 権限 | チーム管理者で操作可能 |
| アラートの流れ | 必ずそのチームへ届く（Responder team = そのチーム） |
| Alert Policy | 100% 発動する（チーム内アラートだから） |
Jira 管理者側（グローバル）Integrations の特徴
| 項目 | 内容 |
|---|---|
| 権限 | Jira 組織管理者のみ |
| アラートの流れ | Responder team（受信チーム）を明示的に指定しない限りどこにも届かない |
| Alert Policy | 🔸 Responder team がチームの場合 → 動く 🔸 Responder team が未設定 → 動かない |
3.Alert policies（アラートポリシー）の動作原則
Alert Policyは「チームに届いたアラートに対して発動する」
✅ ポリシーが動く条件
- アラートがそのチームに「届けられている」
- ポリシーのIF条件にマッチする
✅ ポリシーが動かない理由
- Integrationが「管理者側」で作られておりResponder Teamが空
- 他のチームへ送られている
- アラートのタグ / フィールドなどIF条件に合わない
4.Sync（双方向同期）について - なぜJira Software限定?
Syncが提供されている理由
アラート → Jira Software Issue / Issue状態 → アラートへ反映というDevOpsワークフローのため。
JSMには利用できないのはなぜ
JSMはIT運用・サービスデスク向けサービスであり、開発・バグのステータス管理ではないからと想定される。各チケットのSLAを管理する場合にはJSM側で実装する必要あり。
5.アラート → JSMインシデント作成全体像
検証した流れは以下で動作
CloudWatch → Integration（チーム / グローバル）→ アラート生成
↓
Alert policies（優先度変更・チケット作成・フィールド設定）
↓
JSM インシデント（Service project）を自動生成
➤CloudWatchアラーム
➤Intgration
➤Polices
➤アラート
➤JSMチケット
6.管理者側Integrationのアラートでもポリシーは動く？
例）“ops-team1”内にポリシーを定義している場合
| 条件 | ポリシーの動作 |
|---|---|
| Responder team が “ops-team1” になっている | 💯 動く |
| Responder team が空（未設定） | ❌ 動かない |
| 違うチームになっている | ❌ 他チームのポリシーが動く |
「どの Integration で作られたか」ではなく
“そのアラートがどのチームに届いたか” がすべて。
7.Heartbeat（死活監視）
Heartbeatは「定期的に信号が飛んでくること」を監視する仕組み
JSM Operations側で「〇分おきに特定のエンドポイントに死活監視」と決め、
その間隔で信号が返ってくればOK、一定時間以上、なければアラートを発砲
7-1.Heartbeat（死活監視）設定例
ポイントとして
➤Heartbeat設定画面例
7-2.想定される使われ方
- 定期バッチ処理（夜間バッチ）が実行されているか確認する
- 監視エージェントが落ちていないかをチェック
- ポーリングサービスが「生きているか」確認
JSMが定期的に外部へ送る機能ではなく外部から送ってもらう受け（Pull-in）型の監視
「監視の監視」に近い用途で使う
8.Maintenance（メンテナンス / アラート抑止）
Maintenance は「この期間、この対象のアラートを抑止する（または重み付けを変える）」ための機能。
8-1.用途
- 計画メンテナンス中に大量に発生するアラートを「本番障害」と混ぜない
- レポートや統計（MTTA/MTTRなど）を汚さない
- オンコール担当者に不要な運用を増やさない
8-2.適用対象
Maintenanceウィンドウは以下のような単位で指定可能
- 特定のIntegration
- 特定のPolicy
- 特定のSync
➤設定画面
