LambdaとJIRAを使用したDevOpsタスクの処理

「バリュー++」

TechOpsチームのエンジニアのXNUMX人がその用語を作り出しました。 それは参照します さまざまなコーディング言語での「インクリメント」の省略演算子。 それはまた、私たちがチームとして何をすべきかというモットーでもあります…常に付加価値をもたらします。

ここに、私たちの日常業務で深刻な問題がいくつかあります。 「価値–」

  • 説明のないJIRAチケットへの回答
  • 「顧客には問題Bがあります」..ただし、顧客名と問題の詳細の両方がその文から省略されています
  • 手動で、何度も何度も物事を行う

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

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

プロジェクトと問題の種類

タスクを他のアイテムと区別するために、最初に特定のJIRAプロジェクトと課題タイプをロックダウンし、自動化するタスクごとに個別の課題タイプを作成する必要がありました。 これにより、整理が簡単になるだけでなく、特定のチケットを作成できる人とできない人をロックダウンできます。


この特定のブログでは、アカウントの名前変更を自動的に実行するという、より単純なユースケースのXNUMXつについて説明します。

単純な愚か者

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

LambdaからJQLをクエリする

JIRAクエリ言語(JQL)は、JIRAの問題を検索するための最も柔軟な方法のXNUMXつです。 「アカウントの名前変更」の発行タイプを持つ特定のオープンチケットを見つけるために、JIRA RESTAPIで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にはありません。 特定のユースケースでは、次のようないくつかのフィールドを作成しました。 customer名、ターゲット名 & r名前の日付. 上記のコード例から、JIRA API内では、フィールドの名前だけを指定することはできず、追加する必要があることがわかります。 カスタムフィールドID

上級者向けのヒント…醜いjsonのページを見たくない場合は、高度なJIRA検索バーに移動してフィールドの名前を入力することもできます。

イベントドリブンコンピューティング…ほとんどの場合

通常、Lambdaでアプリをビルドする場合、Lambda関数やイベントソースなどのコンポーネントがあります。 イベントソースは、Lambda関数内からコードによって処理されるイベントを公開するAWSのサービスです。 この場合、JIRAチケットの作成時に名前変更を実行すると、 ポスト機能APIゲートウェイ。 ただし、お客様には独自のメンテナンスウィンドウがあり、アカウントの名前変更を行うのに適した時間があります。 お客様は、アカウントの名前変更を土曜日の午前4時に行うことを希望する場合があります。 my パーソナルメンテナンス(スリープ)ウィンドウ。 回避策として、 ラムダスケジューラーとしての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分ごとに実行され、ラムダ関数がトリガーされます。 この関数は、現在の時刻がカスタムフィールドから解析した値を超えているかどうかを最初にチェックします renアメデート (上記のコードを参照)、そしてその場合にのみ、関数の続行を許可します。

それをすべてまとめる

この時点で、必要な情報を収集しました。 バックエンド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

人から人を救う

チームの顧客の名前変更は、以前は非常に困難な作業でした。 アカウント名変更RunbookのConfluence改訂履歴を振り返ると、20年後に地下室を掃除することに似ています。 非常に時間がかかることに加えて、何らかの理由で、パペットを停止して実行することを含むプロセスの雑多なものがありました…ルビーとbashスクリプト。 アプリケーションの再起動が必要になる場合がありましたが、常にそうとは限りません。 サイズが大きくなるにつれて、唯一のスケーラブルなソリューションは、反復的で手動の、そしてしばしば気が遠くなるようなタスクを自動化することです。 それは私達が顧客により良いサービスを提供することを可能にするだけでなく私達にありふれたものを迂回する機会を私達に与えます 革新的なものを受け入れる.

最後のヒント–これが最も重要な部分です–他の人からの手動入力が必要なものを自動化したい場合、人間の愚かさ…ええと…エラーを考慮に入れる必要があります。 必ず作成してください バリデーターと条件 これと戦うために。

さらに、機知に富んだ警告メッセージは 「バリュー++」