JIRA と AWS Lambda による DevOps ワークフローの自動化

Jira と AWS Lambda の統合で価値を最大化する方法 

TechOps チームのエンジニアの 1 人が「Value++」という用語を作り出した。これは、さまざまなコーディング言語の「増分」を表す省略演算子を参照している。また、これはチームとして行うべきこと、つまり常に価値を追加することのモットーでもある。

日々の業務の中で、私たちが真剣に「価値」と感じていることがいくつかあります。

• 説明のないJIRAチケットに回答する
• 「顧客には問題Bがあります」とありますが、その文では顧客名と問題の詳細の両方が省略されています。
• 何度も何度も手作業で作業する

LogicMonitor では、TechOps チームに要求されるタスクのほとんどは、JIRA チケットの形で行われます。新しいアプリケーションの展開準備が整っている場合や、顧客アカウントの名前変更が必要な場合があります。また、新しい顧客アカウントをデモ環境から本番環境に移行するなどの運用タスクにも対処する必要があります。

LogicMonitor は急速に成長しているため、私たちは常に作業を自動化して効率化を図っています。AWS Lambda 関数、API 呼び出し、JIRA チケットを通じて、DevOps タスクの一部を自動化することにしました。これにより、チームはキューに表示される既存のタスクを追跡し、より重要なことに時間を費やすことができます。

それは「価値++」です。

自動化のためのプロジェクトと問題の種類を理解する

まず、特定の JIRA プロジェクトと問題タイプをロックダウンして、タスクを他の項目と区別し、自動化したいタスクごとに個別の問題タイプを作成する必要がありました。これにより、整理が容易になり、特定のチケットを作成できるユーザーと作成できないユーザーをロックダウンできます。

このブログでは、よりシンプルなユースケースの 1 つである、アカウント名の変更の自動実行について説明します。

シンプルなソリューションでワークフローを効率化: 単純で愚かな

この大まかな Lucidchart (下記) は、私たちが行ったことの基本を示しています。5 分ごとに、CloudWatch イベント ルールが Lambda 関数をトリガーします。関数は JIRA API 呼び出しを行ってチケットのリストを取得します。これらのチケットを使用して必要な情報を取得し、LogicMonitor 内のバックエンド サービスに後続の API 呼び出しを行って、名前の変更などの特定のアクションを実行します。Lambda は、タスクの完了時にチケットをアクティブに更新して閉じます。まず最初に、どのチケットを探すべきかを知る必要があります。

AWS Lambda から直接 JQL クエリを実行する

JIRA クエリ言語 (JQL) は、JIRA で問題を検索する最も柔軟な方法の 1 つです。JIRA REST API で JQL クエリを使用して、問題タイプが「アカウント名の変更」である特定のオープン チケットを検索します。これにより、関連するチケットのリストが返されます。

    エンドポイント= "https：// jira_url / rest / api" jql_issuetype = "issuetype = 'Account Rename'" jql_project = "project = 'TechOps Request'" status = "status = Open" jql =（ "jql =" + jql_project + "+ AND +" + jql_issuetype + "+ AND +" + status）r = session.get（endpoint + "/ 2 / search？" + jql％locals（）、headers = headers_jira）response = json.loads（r.text）応答中の問題の場合["issues"]：customer = issues ["fields"] ["customfield_10001"] target_name = issues ["fields"] ["customfield_14673"]

オープンチケットのリストを取得して、それらから重要な情報を収集できるようにする必要があります。その中には、カスタムフィールドの形式のものもあります。

Jira のカスタム フィールドを使用してワークフローをカスタマイズする

ユーザーはカスタムフィールドを作成しますが、これはJIRAではデフォルトでは利用できません。私たちの特定のユースケースでは、顧客名、ターゲット名、名前変更日などのいくつかのフィールドを作成しました。上記のコード例から、JIRA API内ではフィールド名だけを指定できないことがわかります。 カスタムフィールドID. 

AWS Lambda を使用したイベント駆動型自動化の採用…ほとんどの場合

通常、Lambdaでアプリを構築する場合、Lambda関数やイベントソースなどのコンポーネントがあります。イベントソースは、Lambda関数内のコードで処理するためのイベントを発行するAWSサービスです。この場合、JIRAチケット作成時に名前の変更を実行することは、 ポスト機能 と APIゲートウェイ。 ただし、顧客は独自のメンテナンスウィンドウとアカウント名の変更を希望する時間を持っています。顧客は土曜日の午前4時にアカウント名を変更したい場合があります。 my 個人的なメンテナンス（スリープ）ウィンドウ。回避策として、 Lambda スケジューラとしての CloudWatch イベント.

today = datetime.datetime.today（）-datetime.timedelta（hours = 7）desired_date = datetime.datetime.strptime（issues ["fields"] ["customfield_16105"]。replace（ "-0700"、 ""）、 " ％Y-％m-％dT％H：％M：％S。％f "）今日の場合> desired_date：create_rename（customer、target_name）

CloudWatch イベントは 5 分ごとに実行され、Lambda 関数をトリガーします。関数は最初に、現在の時刻がカスタム フィールドの名前変更日から解析した値 (上記のコードを参照) を超えているかどうかを確認し、その後関数を続行できるようにします。

ツールを組み合わせてシームレスな自動化を実現

この時点で、必要な情報を収集しました。バックエンドの LogicMonitor サービスに API 呼び出しを行うことで名前の変更を実行できますが、このブログではそのコードは示しません。ただし、JIRA チケットを状態ファイルとして扱うことも必要です。同じオープン チケットを繰り返し取得し続けることは避けたいものです。ここで、別の JIRA API 呼び出しを使用して、チケットを別のワークフロー ステップ (例: 「オープン」から「進行中」) に移動します。ただし、カスタム フィールドと同様に、特定の遷移 ID が必要です。これは、 既存のプロジェクトワークフローの編集。 JIRAチケットのステータスをプログラムで更新できるようになりました。

def changeStatus（key、id）：jira_request = {"transition"：{"id"：id}、 "fields"：{"resolution"：{"name"： "Done"}}}エンドポイント= "https：// jira_url.com/rest/api "r = session.post（endpoint +" / 2 / issue /％（key）s / transitions？expand = transitions.fields "％locals（）、data = json.dumps（jira_request）、 headers = headers_jira）return r.text

インテリジェントな自動化による人的ミスの削減：人から人を救う

かつて、チームにとって顧客の名前変更は非常に骨の折れる作業でした。アカ​​ウント名変更ランブックの Confluence のリビジョン履歴を振り返るのは、20 年ぶりに地下室を掃除するようなものです。非常に時間がかかるだけでなく、プロセスには Puppet を停止し、理由は不明ですが、Ruby と Bash スクリプトの両方を同時に実行する必要がありました。アプリケーションの再起動が必要な場合もありましたが、常に必要というわけではありませんでした。成長していく中で、唯一のスケーラブルなソリューションは、反復的で手作業が多く、しばしば気が遠くなるようなタスクを自動化することです。これにより、顧客により良いサービスを提供でき、日常的な作業を回避できます。 革新的なものを受け入れる.

最後にもう1つ、そしてこれが最も重要な部分ですが、他の人による手動入力を必要とするものを自動化したい場合、人間の愚かさ…つまり…エラーを考慮する必要があります。 バリデーターと条件 これと戦うために。

さらに、気の利いた警告メッセージは「価値++」です。

© LogicMonitor 2025 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。