【実務・中級編】RollbarのWebhooksとAWS Lambdaを活用した自動チケット起票システムの実装手順 – 運用監視・オブザーバビリティ活用バイブル

監視を「作業」にするな。Rollbar × Lambda で実現する「ゼロタッチ」インシデント管理術

エンジニアが最も無駄にしている時間は何か。それは、「エラーログを見て、それをコピーし、Jiraを開いて、チケットを作成し、担当者をアサインする」という、誰でもできるはずの退屈なルーチンワークだ。

オブザーバビリティの真髄は「監視すること」ではなく、「監視によって生まれた余白を、いかにプロダクトの価値創造に充てるか」にある。今回は、RollbarのWebhookをトリガーに、AWS Lambdaを介してJiraやNotionへ自動チケット発行を行う、現場の生産性を劇的に変える「ゼロタッチ・インシデント管理」の裏側を伝授しよう。

—

1. なぜ「自動起票」なのか:ノイズとシグナルの分離

RollbarのUIでエラーを見つめるのは、もはや時代遅れだ。我々がやるべきは、「Criticalなエラーのみを、アクション可能な形式でワークフローに流し込む」ことである。

現場で死ぬほど役に立つ設定の鉄則

  • 閾値の設定(Grouping Rules): 全てのエラーをチケット化してはいけない。ノイズは即座にアラート疲れを招く。「1時間で10件以上発生したCriticalなエラーのみ」のように、RollbarのGrouping設定で「シグナル」を精査せよ。
  • コンテキストの埋め込み: チケットには、単なるスタックトレースだけでなく、`Environment`, `User ID`, `Deployment ID` を必ず含めること。これが無いチケットは「ゴミ」だ。

—

2. 実装:Rollbar → API Gateway → Lambda → Jira/Notion

この構成の肝は、Lambdaを「接着剤」として使うことだ。

Lambda関数(Python)のベストプラクティス

以下は、RollbarのWebhookを受け取り、Jiraへチケットを飛ばすためのミニマムかつ堅牢なスクリプト例だ。

import json
import requests
import os

環境変数から機密情報を取得(SSM Parameter Store等で管理推奨)
JIRA_API_TOKEN = os.environ[‘JIRA_API_TOKEN’]
JIRA_URL = “https://your-domain.atlassian.net/rest/api/3/issue”

def lambda_handler(event, context):
# RollbarからのPayloadをパース
body = json.loads(event[‘body’])
data = body[‘data’][‘occurrence’]

# 必要なコンテキストのみ抽出
title = f”[Rollbar] {data[‘title’]}”
details = f”URL: {data[‘url’]}\nContext: {data[‘context’]}\nStack: {data[‘body’][‘trace’][‘exception’][‘message’]}”

# Jiraへのペイロード構築
payload = {
“fields”: {
“project”: {“key”: “PROJ”},
“summary”: title,
“description”: details,
“issuetype”: {“name”: “Bug”}
}
}

# チケット起票
response = requests.post(JIRA_URL, json=payload, auth=(“email@example.com”, JIRA_API_TOKEN))

return {“statusCode”: response.status_code, “body”: “Ticket Created”}

—

3. チームの生産性を底上げする「隠れたテクニック」

① Rollbarの「Keyboard Shortcuts」を使い倒せ

Rollbarのダッシュボードで `?` を押すとショートカット一覧が出るが、特に `j` (次へ) / `k` (前へ) と `a` (Ack: 承認) は指に覚えさせろ。これだけで、エラーのトリアージ速度が3倍になる。

② 神プラグイン:Slackでの「リアクション起票」

RollbarのSlack連携は必須だが、単に通知を流すだけではいけない。「特定のスタンプを押すとLambdaが起動してチケット化される」ような仕組みを構築せよ。

  • Slackの `reactions.add` イベントを拾い、RollbarのOccurrence IDをキーにチケット化する。これにより、不要なものはスルーし、重要だと感じたものだけを瞬時にチケット化できる。

③ 設定ファイル(terraform/json)の共有化

チーム設定はコード化(IaC)すべきだ。RollbarのProject Access Tokenや通知設定は、Terraformの `rollbar_project` リソースで管理し、リポジトリに含めること。

terraform で管理するRollbar設定例
resource “rollbar_project” “main” {
name = “production-app”
}

メンバー間で通知設定を共有する
resource “rollbar_project_access_token” “read_only” {
project_id = rollbar_project.main.id
name = “read-only-token”
scopes = [“read”]
}

—

4. 最後に:インシデント対応の初動を極める

多くのエンジニアが「エラー対応」を「作業」として捉えている限り、チームの成長は止まる。しかし、この自動化を導入すれば、「エラーが発生した瞬間、既にチケットが起票され、関連するログが添付され、担当者にメンションが飛んでいる」という状態が作れる。

これができれば、インシデント発生時の「何が起きたんだ?」という混乱の時間を、「どう修正すべきか?」という議論の時間に変換できる。

監視ツールを使いこなすのではない。ツールを使い倒して、エンジニアとしての思考時間を買い戻せ。 それこそが、真のオブザーバビリティ・エンジニアの姿だ。

タイトルとURLをコピーしました