#はじめに
前々回と前回の記事では、2021年12月 にリリースされた OASE v1.5.0で追加・強化された以下3つの新機能の「①ワークフローの実行」と「②インシデント管理機能の強化」を実際に動かしてみました。
本記事では新機能「③承認フローに対応」を動かしてみます。
①ワークフローの実行
②インシデント管理機能の強化
③承認フローに対応
※新機能「①ワークフローの実行」「②インシデント管理機能の強化」については、以下記事で紹介しています。
Exastro OASE ServiceNow連携機能を使ってみた「①ワークフローの実行」
Exastro OASE ServiceNow連携機能を使ってみた「②インシデント管理機能の強化」
OASEとは
**OASE:Operation Autonomy Support Engine** 「システム運用の自律化・効率化・省力化を支援するためのOSS」である。 OASE は他のシステムと連携することで監視からアクションまでの一連の処理を実施します。 ※[公式コミュニティサイト](https://exastro-suite.github.io/oase-docs/index_ja.html)より引用Service Nowとは
Service Now は、提供されるアプリケーション、データ、ビジネスロジック、セキュリティーモデルなどが単一のクラウドプラットフォーム上で稼働するように実装されており、計画から運用、サービス管理など、さまざまな業務がエンドツーエンドで完結する業務プロセスの実現をコンセプトとしている。各機能は、ITIL をベースに設計されている。 ※[Wikipedia](https://ja.wikipedia.org/wiki/ServiceNow)より引用Exastro IT Automation(=ITA)とは
ITA:IT Automation 「システム設定をデジタル化して一元管理するためのオープンソースのフレームワーク」である。 [ITAコミュニティサイト](https://exastro-suite.github.io/it-automation-docs/index_ja.html) [Exastro IT Automationをインストールしてみた(v1.8.0)](https://qiita.com/standsetx/items/53553a0f78edc3097812) [Exastro IT Automation クイックスタート (ver1.8.0)](https://qiita.com/y-masaya3210/items/68920237c03e5d4f4776)#システム構成と全体のシナリオ
全体のシステム構成図とシナリオは以下になります。
本記事では構成図の③部分の「承認フローの組み込み」を見ていきます。
シナリオ1:ワークフローの実行
OASEからService Now上で作成したワークフローをキック(実行)し、メールが通知されることを実現します。
シナリオ2:インシデント管理機能の強化
Service Nowのインシデントのステータス「NEW(起票)」「IN_PROGRESS(対処中)」「RESOLVED(解決済み)」「CLOSED(クローズ)」をディシジョンテーブルファイルを使って、インシデント起票からクローズまで一元で管理し、Service Nowでチケットが起票されていること確認します。
「IN_PROGRESS(対処中)」と「RESOLVED(解決済み)」の間に対処としてOASEとITAを連携し対象のサーバに対して対処(httpdの再起動)を実施します。
シナリオ3:承認フローの組み込み
シナリオ2の設定では自動的に対処を実施してしまうので、対処の開始前に承認フローを組み込むことにより対処前に実施してよいか事前確認できるようにします。
#事前準備
OASE、Service Now、Exastro IT Automationの事前準備として、インストールや下準備を行っていきます。
※Exastro OASE ServiceNow連携機能を使ってみた「①ワークフローの実行」の「事前準備」がすでに完了している場合は、対応不要になります。
###1.OASEのインストール
OASEのインストールを行います。
公式コミュニティサイト掲載のオンラインインストールマニュアルや
Qiita記事「Exastro OASE を最速でインストールする」をご参照ください。
###2.Service Now設定
2-1.Service Now開発者インスタンスの取得(インスタンス作成)
下記、Qiitaを参考にService Now開発者インスタンスの作成を行っていきます。
Service Nowは個人に無償で開発用インスタンスを提供しています。
Qiita記事「ServiceNow開発者インスタンスの作成」
2-2.メール送付設定
Service Nowの開発者向けインスタンスはデフォルトではメール送信が無効化されているので有効化にします。
Qiita記事「ServiceNow初期設定 メール送信を有効化する」
###3.ITAの設定
Exastro IT Automationをインストールしていきます。
公式コミュニティサイト掲載のオンラインインストールマニュアルや
Qiita記事「Exastro IT Automationをインストールしてみた(v1.8.0)」をご参照ください。
#シナリオ3:承認フローの組み込み
それでは、最後に新機能「承認フローに対応」を見ていきましょう。
###1.Service Nowの設定
対処開始とクローズ前に承認フローを組み込むために、Service Nowの機能「Flow Designer」を使用するので、設定を行っていきます。
Flow Designerを使用すると、プロセス所有者は自然言語を使用して、コーディングなしで承認、タスク、通知、および記録操作を自動化できます。
(※公式ドキュメント引用)
1.Flow Designerへの移動
Service Nowインスタンスのページを開き、画面左上のアプリケーションナビゲータから「flow designer」を検索して「プロセス自動化」下の「Flow Designer」を選択すると。「Flow Designer」のページに移行するので画面右上の「新規」⇒「フロー」をクリックします。
2.フロー名の設定
下画像の任意の「フロー名」を入力し、「送信」をクリックすると、非アクティブ状態のフローが作成できました。
3.トリガーの設定
今回作成する、フローの全体を最初に確認し、トリガーの設定を進めていきます。
3-1.トリガーの追加と設定
下画像の「トリガーを追加」をクリックし、トリガーの項目をプルダウンで「作成または更新」を選択します。
3-2.テーブルの選択
テーブルの検索から「incident」と入力し、プルダウンで「インシデント[incident]」を選択します。
3-3.条件の選択
プルダウン選択から、「ステータス」「変更」を選択します。
3-4.トリガー実行の条件選択
プルダウン選択から、「更新ごと」を選択し、完了をクリックします。
4.アクションの設定
4-1.条件セットの設定①
インシデントが新規作成された際に、インシデントの説明に特定の文言[APPROVAL_REQUAEST]がある場合に、以降のアクションを実行する条件セットを設定します。
インシデントの説明にはディジションテーブルの「ルール名」「申請発生事象」「対処概要」が表示されますので、本シナリオで使用するディジションテーブルの「対処概要」には[APPROVAL_REQUAEST]を入れておきます。
ディジションテーブルの全体詳細はOASEの設定時に紹介します。
シナリオ2で使用したディジションテーブルと起票されたインシデントの説明欄を確認してみると、
インシデントの「説明」にディジションテーブルの「ルール名」「発生事象」「対処概要」が入力されています。
画像を参照に「フローロジック」⇒「If」を選択後、以下表のように項目を入力し、「完了」をクリックします。
「トリガー >インシデントRecord」は画像のように画面右の「データ」からドラッグ&ドロップで入力します。
条件 | 条件1 |
---|---|
承認リクエストフラグがある場合 | 「トリガー >インシデントRecord」:「は次の値を含む」:「[APPROVAL_REQUEST]」 |
4-2.条件セットの設定②
新規作成されたインシデントのステータスが「新規」の場合に、以降のアクションを実行する条件セットを設定します。
ステータスの指定はディジションテーブルの「アクションパラメータ情報」にて「INCIDENT_STATUS=NEW」と入力することで指定可能です。
「フローロジック」⇒「If」を選択後、以下表のように入力し、「完了」をクリックします。
条件 | 条件1 |
---|---|
自動対処前の承認リクエストの場合 | 「トリガー > インシデントRecord > ステータス」:「次の値に等しい」:「新規」 |
4-3.承認フローの設定①
対処を実施する前の承認フローの設定を組み込みます。
4-3-1.アクション「承認フロー」を選択
画像のように、「アクション」を選択し、「承認を求める」を選択します。
4-3-2.アクション「レコード」を選択
画面右側の「データ」から「インシデント Record」をドラッグ&ドロップします。
4-3-3.「ルール」の設定
「別のORルールセットを追加」をクリックし、ルールの項目を増やします。
1つめのルールを「承認」に設定し、条件は「誰でも承認可能」を選択し、右のユーザのアイコンからユーザ「System Administrator」を選択します。
2つめのルールは「却下」に設定し、「すべてのユーザーによる却下」を選択し、右のユーザのアイコンからユーザ「System Administrator」を選択します。
4-4.条件セットの設定③
承認フローの承認結果によって分岐するようにif条件の設定を行います。
今回は承認フローの承認結果が承認された場合の設定を行います。
「フローロジック」⇒「If」を選択後、以下表のように入力し、「完了」をクリックします。
「3 > 承認ステータス」は画面右側の「データ」の下にある「3・承認を求める」を展開後に「承認ステータス」をドラッグ&ドロップします。
条件 | 条件1 |
---|---|
承認された場合 | 「3 > 承認ステータス」:「次の値に等しい」:「承認済み」 |
4-5.承認された場合のアクション設定①
前項番「4-4.条件セットの設定③」で設定したif条件で承認された場合のアクションを設定します。
4-5-1.アクション「承認フロー」を選択
画像のように、「アクション」を選択し、「レコードを更新」を選択します。
4-5-2.アクション「レコード」を選択
画面右側の「データ」から「インシデント Record」をドラッグ&ドロップします。
4-5-3.「フィールド」の設定
本シナリオで使用するディジションテーブルのアクションパラメータ情報を確認してみると、「WORK_NOTES_APPROVAL=APPROVED_ACTION」と設定しています。
「WORK_NOTES_APPROVAL」というのは、Service Nowに実装されているFlowDesignerを利用してOASEのアクション実行前に承認アクションを追加したい場合に必要な機能で、Service NowのIncidentの値と承認文言を紐づけます。
「+ フィールド値を追加」をクリックします。
その後「作業メモ」をプルダウン選択し、「APPROVED_ACTION」を入力し、「完了」を押下します。
4-6.条件セットの設定④
承認フローの承認結果が却下された場合の設定を行います。
※本設定以降は細かな操作手順は省略させて頂き、設定後の画像のみの紹介とさせて頂きます。
4-7.却下された場合のアクション設定①
4-8.条件セットの設定⑤
インシデントのステータスが「解決済み」の場合に、以降のアクションを実行する条件セットを設定します。
4-9.承認フローの設定②
クローズする前に承認フローの設定を組み込みます。
4-10.条件セットの設定⑥
承認フローの承認結果が承認された場合の条件セットの設定を行います。
4-11.承認された場合のアクション設定②
4-12.条件セットの設定⑦
承認フローの承認結果が却下された場合の設定を行います。
4-14.フローの有効化
以下のようにフローの作成が完了しましたら、画面右上から「有効化」を実行します。
###2.Webサーバ・Zabbix・ITAの設定
2-1.Webサーバの設定
Webサーバの設定はQiita「Exastro OASE でマッチポンプした話(Web+Zabbix構築編)」の「1.1. 監視対象の Web サーバ構築」の手順を実施します。
2-2.Zabbixの設定
Zabbixの設定はQiita「Exastro OASE でマッチポンプした話(Web+Zabbix構築編)」の「1.2. Zabbix 環境構築」の手順を実施します。
2-3.ITAの設定
ITA設定はQiita「Exastro OASE でマッチポンプした話(Web+Zabbix構築編)」の「1.3. Exastro IT Automation (ITA) 環境を構築」の手順を実施します。
###3.OASEの設定
※「ServiceNow Driver」「ITA Driver ver1」のアクション設定については、以下内容をご参照ください。
記事Exastro OASE ServiceNow連携機能を使ってみた「①ワークフローの実行」の「2-1.アクション設定」をご参照ください。
記事Exastro OASE ServiceNow連携機能を使ってみた「②インシデント管理機能の強化」の「2-1.アクション設定」をご参照ください。
3-1.ディシジョンテーブルにルールを登録
【使用メニュー】 「ルール」グループ / 「ディシジョンテーブル」メニュー
今回は下表のように設定しました。
■基本情報・権限
項目名 | 入力値 |
---|---|
ディジションテーブル名 | approval_test |
概要 | (空欄) |
権限の設定 | システム管理者 |
■条件式
条件名 | 条件式 |
---|---|
アラート | 正規表現に一致する |
ホスト | 含む |
■未知事象通知
項目名 | 選択 |
---|---|
未知事象通知 | メールで通知する&ServiceNowと連携する |
通知先メールアドレス | xxx@xx.co.jp(任意の通知先メールアドレス) |
ServiceNowDriver名 | action_servicenow |
3-2.ルールテーブルを編集する
ダウンロードしたディシジョンテーブルファイルを編集していきます。
今回使用するディシジョンテーブルファイルを見ていきます。
画像の①②の「CONDUCTOR_CLASS_ID」と「OPERATION_ID」には、以下のConductorとオペレーションのIDを指定します。
番号 | Condutor | Operation |
---|---|---|
① | Webサーバ高負荷対応 | Sorryページ切り替え |
② | Webサーバ高負荷戻し対応 | Sorryページ戻し |
今回は下表のように入力しました。
ルール説明 | アラート(正規表現可 一致) | ホスト(含む) | ルール名(必須) | 発生事象(必須) |
---|---|---|---|---|
1.Sorryページへ切り替え | More than 20 connections | target-web | 1-インシデント起票 | 【自動対処】大量アクセス発生 |
1.Sorryページへ切り替え | More than 20 connections | target-web | 1-処理中 | 【自動対処】大量アクセス発生 |
1.Sorryページへ切り替え | More than 20 connections | target-web | 1-コンテンツ置き換え | 【自動対処】大量アクセス発生 |
1.Sorryページへ切り替え | More than 20 connections | target-web | 1-処理完了 | 【自動対処】大量アクセス発生 |
1.Sorryページへ切り替え | More than 20 connections | target-web | 1-インシデントクローズ | 【自動対処】大量アクセス発生 |
2.通常コンテンツへの戻し | Less than 11 connections | target-web | 2-インシデント起票 | 大量アクセスの収束を確認 |
2.通常コンテンツへの戻し | Less than 11 connections | target-web | 2-処理中(承認あり) | 大量アクセスの収束を確認 |
2.通常コンテンツへの戻し | Less than 11 connections | target-web | 2-コンテンツ戻し | 大量アクセスの収束を確認 |
2.通常コンテンツへの戻し | Less than 11 connections | target-web | 2-処理完了 | 大量アクセスの収束を確認 |
2.通常コンテンツへの戻し | Less than 11 connections | target-web | 2-インシデントクローズ(承認あり) | 大量アクセスの収束を確認 |
対処概要(必須) | アクション種別 |
---|---|
インシデントをオープンします。 | ServiceNow(ver1) |
OASEによりSorryページに切り替えを行います。 | ServiceNow(ver1) |
ITAを実行しSorryページに切り替え中です。 | ITA(ver1) |
OASEによるSorryページの切り替えが完了しました。 | ServiceNow(ver1) |
インシデントをクローズします。 | ServiceNow(ver1) |
インシデントをオープンします。[APPROVAL_REQUEST] | ServiceNow(ver1) |
OASEにより通常ページに切り替えを行います。この対処に問題なければ承認をお願いします。 | ServiceNow(ver1) |
ITAを実行し通常ページに切り替え中です。 | ITA(ver1) |
OASEによる通常ページの切り替えが完了しました。 | ServiceNow(ver1) |
インシデントをクローズします。対処内容を確認の上、問題なければクローズ承認をお願いします。 | ServiceNow(ver1) |
アクションパラメータ情報 |
---|
SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=NEW |
SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=IN_PROGRESS |
ITA_NAME=ita1.8.1,CONDUCTOR_CLASS_ID=x,OPERATION_ID=x |
SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=RESOLVED |
SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=CLOSED |
SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=NEW |
SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=IN_PROGRESS,WORK_NOTES_APPROVAL=APPROVED_ACTION,WORK_NOTES_REJECTED=REJECTED_ACTION |
ITA_NAME=ita1.8.1,CONDUCTOR_CLASS_ID=x,OPERATION_ID=x |
SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=RESOLVED |
SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=CLOSED,WORK_NOTES_APPROVAL=APPROVED_CLOSE,WORK_NOTES_REJECTED=REJECTED_CLOSE |
※以下は共通の設定になります。
承認メールパラメータ情報 | リトライ間隔(必須) | リトライ回数(必須) | 抑止間隔(必須) |
---|---|---|---|
X | 1 | 1 | 1 |
抑止回数(必須) | 条件回数(必須) | 条件期間(秒)(必須) | 大グループ(必須) |
---|---|---|---|
1 | X | X | X |
優先順位(必須) | 小グループ(必須) | 優先順位(必須) |
---|---|---|
X | X | X |
3-3.Zabbix 監視アダプタの設定
【使用メニュー】 「システム」グループ / 「監視アダプタ」メニュー
画面右上の 「監視先の追加」 ボタンを押下し、監視先の設定の項目から、「ZABBIX Adapter ver1」 を選択します。
今回は下表のように設定しました。
項目 | 設定値 |
---|---|
名前 | Webサーバ監視 (任意) |
プロトコル | http |
ホスト/IP | ZabbixサーバのIPアドレス |
ポート | Zabbixの公開ポート |
ユーザ名 | Zabbixのユーザ名 |
パスワード | Zabbixのパスワード |
ディジションテーブル名選択 | approval_test |
突合情報 - アラート | description |
突合情報 - ホスト | hosts |
3-4.ディシジョンテーブルファイルのアップロード
前作業で作成したディシジョンテーブルファイルのアップロードします。
【使用メニュー】「ルール」グループ / 「ルール」メニュー
「ファイルを選択」ボタンよりファイルを選択し、その後[アップロード]ボタンをクリックする。
3-5.テストリクエストとルールの本番環境へ移行
ステージング環境で設定したルールが正確に動作するか確認し、問題なければプロダクション環境に移行します。
【使用メニュー】 「ルール」グループ / 「ルール」メニュー
画面上部から[テストリクエスト]を押下後、テストリクエストの各タブの設定を入力していき、「実行」をクリックします。
今回は下表のように入力しました。
【ディシジョンテーブルタブ】ディシジョンテーブル名選択 | アラート | ホスト |
---|---|---|
approval_test | More than 20 connections | ["target-web"] |
値に対して意図したルールがマッチすることを確認できたら、「閉じる」をクリックし、運用ステータスを「検証完了」にします。
運用ステータス「検証完了」にできましたらチェックボタンをクリックしルールをプロダクション環境へ移行します。
###4.動作確認
Qiita「Exastro OASE でマッチポンプした話(活用編)」の「6. 動作確認」を参考に動作を見ていきます。
4-1.監視対象の Web サーバへ高アクセスする
監視対象の Web サーバにアクセスし、完全にページが表示されたことを確認後に F5 キー を連打します。今回は、time=30 に設定してます。
4-2.Zabbixの動作確認
Zabbix 上でグラフを確認したところ、19:37:56 に 高アクセス時のトリガーが引かれたようです。
4-3.OASEのリクエスト履歴とアクション履歴の確認
OASEの画面から、リクエスト履歴とアクション履歴を確認してみます。
【使用メニュー】「ルール」グループ / 「アクション履歴」メニュー
初めのアクション「1-インシデント起票」のログ詳細を確認したところ、19:37:57 にイベントが発生していました。
4-4.ITAと監視対象の Web サーバの確認
ITAの動作とWeb サーバの状態を確認します。
【使用メニュー】メニューグループ「Conductor」 / メニュー「Conductor作業一覧」
ITAの動作を確認したところ、WebサーバのコンテンツをSorryページ切り替えるConductorが 19:38:35 に実行され、正常終了しています。
監視対象の Web サーバにアクセスすると、「Sorry. Please try again leter.」にコンテンツが切り替わっています。
4-5.Service Nowの動作確認
OASEのアクション履歴を確認すると、アクション「2-処理中(承認あり)」(Web サーバの通常ページに切り替え実施の承認)がアクション実行中となっていることがわかります。
数分後、Service Nowより承認依頼メールが届いたので、Service Nowの動作を確認していきます。
Service Nowインスタンスのページを開き、画面左上のアプリケーションナビゲータから「承認」を検索し、「セルフサービス」下の「自分の承認」を選択します。
表示されたページを確認するとステータスが「要求済み」のインシデントがありますので、クリックします。
開いたページを見てみると、インシデントが承認待ちの状態になっていることがわかります。
「承認」を選択してみると、ステータスが「承認済み」に変更されました。
4-6.残りの動作の確認
ITAを確認すると、WebサーバのコンテンツをSorryページから戻すConductorが 19:41:13 に実行され、正常終了しています。
監視対象の Web サーバにアクセスすると、高アクセス発生前のコンテンツに切り替わっています。
OASEのアクション履歴を確認すると、アクション「2-インシデントクローズ(承認あり)」(インシデントクローズの承認依頼)がアクション実行中となっていることがわかります。
数分後、Service Nowより承認依頼メールが届いたので、Service Nowの動作を確認していきます。
Service Nowにて「自分の承認」ページを確認するとステータスが「要求済み」のインシデントがありますので、前作業と同様に「承認」を選択します。
最後にOASEのアクション履歴を確認すると、全アクションが正常終了していることが確認できます。
これにて、シナリオ3の動作確認も終了になります。
#おわりに
今回はOASE v1.5.0で追加・強化されたService Now連携機能の一つ「承認フローに対応」を見てみました。
OASEはインシデント発生時に自動で対処を行いますが、承認者による承認が必要な場合ServiceNowを経由して承認フローを実現することができました。
インシデントの管理を担当する方は、承認の際にOASEの画面上またはServiceNowの画面上どちらでも可能のようなので承認メールが通知された際にServiceNowから承認すればOASEにアクセスする必要はなく自動対処することができるので運用の工数削減やオペレーションミス防止に活用できるように感じました。
冒頭でも記載していますが、残り2つの新機能については、以下記事で紹介しています。
Exastro OASE ServiceNow連携機能を使ってみた「①ワークフローの実行」
Exastro OASE ServiceNow連携機能を使ってみた「②インシデント管理機能の強化」
下記の関連リンクでOASE関係の記事をまとめてみたので、本記事と併せて見て頂ければ分かりやすいと思います。
#関連リンク
Exastro OASE Learn「Service Now連携_座学編」
Exastro Operation Autonomy Support Engine (公式サイト)
Exastro コミュニティサイト OASEドキュメント一覧
Exastro IT Automation (Exastro ITA公式サイト)
【随時更新】Exastroの参考になる記事をまとめてみた
Exastro OASE を最速でインストールする
Exastro OASE でマッチポンプした話(Web+Zabbix構築編)
Exastro OASE でマッチポンプした話(活用編)