この記事は関連記事の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通信するにはトークンを利用して通信を行います。

JiraAPI トークン発行

発行したトークをLambdaの環境変数で持つのはセキュアではないです。
そこでSecrets Managerを使うことでセキュアに扱うことが可能となります。

IAMポリシーで厳密にアクセス制限できる
ローテーションできる
Lambdaはキャッシュして高速化できる

3-3. Jiraに送る本文（ADF）はJSON

JiraはMarkdownではなく**ADF（Atlassian Document Format）**を内部で使います

ADFリファレンス

➤使い方（例）

{
  "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判定