この記事は関連記事の1本目です。
このシリーズでは、AWSからJiraに自動でインシデントチケットを作成する仕組みを、
実務でありそうな具合に作成していきます。
自身のナレッジとどなたかの参考になれば幸いです。
この記事で書くこと（第1回）
- なぜ「監視 → 自動起票」が必要なのか
- CloudWatch アラーム/ Step Functionsの失敗通知
- SNS → Lambda → Jira Rest APIという構成
-
CloudWatchとStep Functionsを同じLambdaで処理できる設計
→本数を増やしてより汎用性を持たせるため - 次回以降で何を書くか（全体像）
1. まず、何を作りたいのか？（ゴール設定）
- 障害が発生しても、メール通知や監視ツールコンソール上でしか分からない
- 運用担当者が障害検知後、手動でチケットを作成している
- 障害通知が頻発した場合、Jiraがスパム状態になる
現場でありそうな課題をあげてみましたが、こういう問題は
自動化で大きく改善できる
今回作る「自動インシデント管理パイプライン」
CloudWatch アラーム FAILED / Step Functions Execution FAILED
↓
SNS Topic
↓
Lambda(共通インシデント変換レイヤー)
↓
Jira REST API
↓
チケット作成 / コメント追加 / 優先度判定
この流れでの自動化を実装して課題を解決していく。
- CloudWatchやStep Functionsも同じLambda1本で処理できる
- 既存チケットがあればコメント追記してチケット乱立を防止
- Alerts → Jira → チケット上での障害管理
2. アーキテクチャ全体図(簡易版)
3. 設計ポリシー
3-1. Lambdaは１本にまとめる
AWSの CloudWatch・Step Functions・ECS・Batch などは
イベント形式がすべて異なります。
とはいえ、やりたいことは共通で「イベントを受けて Jira に課題を作るだけ」です。
そこで Lambda は 1本に集約し、最初にイベントを**共通フォーマット（incident）**へ正規化します。
この正規化レイヤーは「どのサービスのイベントでも同じ形の incident を返す」役割を持ち、
実際には CloudWatch・Step Functions といったサービスごとの変換ロジックを内部で切り替えています。
最終的に Jira 側は incident の共通フィールドだけ を見て処理できます。
3-2. Secrets Managerを使う
JiraでRESTAPI通信するにはトークンを利用して通信を行います。
発行したトークをLambdaの環境変数で持つのはセキュアではないです。
そこでSecrets Managerを使うことでセキュアに扱うことが可能となります。
- IAMポリシーで厳密にアクセス制限できる
- ローテーションできる
- Lambdaはキャッシュして高速化できる
3-3. Jiraに送る本文（ADF）はJSON
JiraはMarkdownではなく**ADF（Atlassian Document Format）**を内部で使います
➤使い方（例）
{
"type": "doc",
"version": 1,
"content": [
{ "type": "heading", "attrs": {"level": 2}, "content": [{"type":"text","text":"Alarm Info"}] },
...
]
}
Markdownを送ってもJiraではそのまま文字列として出してしまう
4. 第1回の続き：各回のロードマップ
第2回
Jira / AWSの事前準備（Secrets / IAM / SNS）
- Secrets ManagerのJSON
- IAM ポリシー
- SNS Topic設計
- Jiraトークン発行とcurlテスト
第3回
CloudWatch 専用 → 最小実装でまず起票を成功させる
- urllib3の設定
- Secrets読み込み
- 最小jira Issue作成API
- Lambdaテストイベント
第4回
自動起票の実装
- CloudWatch / Step Functions を統合する“共通インシデント変換レイヤー
- 重複防止(JQL)・コメント追記・優先度決定
- JQL検索による冪等性
- コメント追記の機構
- Priority判定