#概要
今回は皆さん大好き承認機能付きのProcess Workflowを作成したので、そちらをご紹介します。
まずWorkflowの説明をします。
1, Windows Agentからサービスを監視し、Downを検知
2, サービスの再起動スクリプトの実行承認を依頼する
3, 承認された場合Workflowでサービス再起動が自動で実施される
4, 自動対応内容がアラート/チケットにコメントされる
皆さんの環境でこのWorkflowを再現したい場合、以下の説明から作成もできますが、
後日、APIPOSTでサクッと作成出来る方法を投稿しますので、そちらのほうが簡単かもしれません。
#各タスクの説明
画像の各タスクをWorkflowの流れと一緒に順に説明します。
※原則記載の無い設定項目はデフォルト値です。
###startevent(アラート発生)
アラートのcomponentのフィールドの文字列が”Print Spooler”であった場合、
このWorkflowを開始する。
項目 | 値 |
---|---|
Name | ServiceAlert |
ID | 自動入力 |
Configuration | Alert |
Configuration2 | Created |
Filter Criteria | $component = "Print Spooler" |
###User Task(承認申請)
タスクチケットを作成します。
言い換えますと、承認申請がタスクという種類のチケットで作成されます。
項目 | 値 |
---|---|
Name | ObtainApproval |
ID | 自動入力 |
Subject | サービス再起動承認依頼 |
Description | 下記サービスが停止中です、再起動のためワークフローの承認をお願いします。$ServiceAlert.alert.resource.hostName , $ServiceAlert.alert.component
|
Priority | high |
Assignee | 任意(承認者にするのがいいと思います。) |
※ここにない項目はデフォルトで構いません。
###(Taskチケット)
予めCustom Formで承認対応用のフィールドを用意しておきましょう。
(Custom Formの詳細はこれだけでとても長くなるため省略します。)
Setup>Service Desk>Custom Forms>Task
項目 | 値 |
---|---|
Formの種類 | Drop-down list |
Display Label | Actions |
Is editable? | 有効 |
Dropdown Options 1 | Deny(※横のボックスも同じ内容を入力) |
Dropdown Options 2 | Approve(※横のボックスも同じ内容を入力) |
###(承認作業)
承認者が内容を確認し、承認します。
要件
「承認する = Workflowを先にすすめる」という事になるのですが、
その条件として、この作成されたTaskチケットのステータスを「Resolved」にする必要があります。
これはOpsRampのドキュメントに書いていないので要注意です。(2021/12/03現在)
合わせて、事前に作成した「Action」のフィールドは「Approved」を選択しましょう。
###Exclusive Gateway(承認された場合のみ次のタスクを実行する)
Taskチケットを更新したことにより、先に進むことが出来るようになりました。
次に待ち構えているのは条件分岐です。
下記の設定で、Taskチケットの「Action」のフィールドは「Approved」の時だけ
関所を通す設定を入れていきます。
これ勘違いしやすいのですが、分岐のFunctionであるExclusive Gatewayには
分岐の条件を入れる項目はありません。分岐の条件を入れるのはそこから伸びている
棒線矢印の中に入れていきます。
1, Exclusive Gateway
項目 | 値 |
---|---|
Name | Get Responce |
ID | 自動入力 |
2, Global Connect その1(矢印の棒線)
項目 | 値 |
---|---|
Name | Deny |
ID | 自動入力 |
3, Global Connect その2(矢印の棒線)
項目 | 値 |
---|---|
Name | Approve |
ID | 自動入力 |
Condition | $ObtainApproval.task.Actions = "Approve" |
###Script Task(プロセスを再起動する)
承認が通っているため、Downしたプロセスをスクリプトで起動させます。
これによって対象のアラートは復旧します。
今回はOpsRamp上で用意したスクリプトを動かします。
項目 | 値 |
---|---|
Name | RestartService |
ID | 自動入力 |
Configuration | Agent |
Script Category | 任意 |
Script Name | 任意 |
Resource Id | $ServiceAlert.alert.resource.uuid |
Imputs-Service Name | $ServiceAlert.alert.component |
※このスクリプトはOpsRamp内で作成し、スクリプトのImputのパラメータを
仕込んであります。ですので、通常はパラメータなければImput入力項目は
出てきません。
###Service Task(アラート/インシデントチケットに自動対応実施のログを残す)
最後にスクリプトを実行したということをアラートとインシデントにコメントして残します。
このService TaskはOpsRampUIから取れるアクションの一部を自動で実施してくれます。
ドロップダウンから選択するだけなので、スクリプト等がなくても簡単に実行できるので楽ちんです。
1, アラート
項目 | 値 |
---|---|
Name | AddAlertComment |
ID | 自動入力 |
Service | Platform Service |
Task | Post Alert Comment |
AlertID | $ServiceAlert.alert.uuid |
Comments | 自動化ワークフローによりサービスの再起動を実施しました。承認者: $ObtainApproval.task.assignedTo.loginName |
2, インシデント
項目 | 値 |
---|---|
Name | UpdateIncident |
ID | 自動入力 |
Service | Platform Service |
Task | Update Incident |
Response | 自動化ワークフローによりサービスの再起動を実施しました。承認者: $ObtainApproval.task.assignedTo.loginName |
それぞれこの様にポストされました。
アラート
インシデントチケット
以上です。