#はじめに
前回の記事では、2021年12月 にリリースされた OASE v1.5.0で追加・強化された以下3つの新機能の1つ「①ワークフローの実行」を実際に動かしてみました。
本記事では新機能「②インシデント管理機能の強化」を動かしてみます。
①ワークフローの実行
②インシデント管理機能の強化
③承認フローに対応
※新機能「①ワークフローの実行」「③承認フローに対応」については、以下記事で紹介しています。
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)#システム構成と全体のシナリオ
全体のシステム構成図とシナリオは以下になります。
本記事では構成図の②部分の「インシデント管理機能の強化」を見ていきます。
シナリオ１：ワークフローの実行
OASEからService Now上で作成したワークフローをキック(実行)し、メールが通知されることを実現します。
シナリオ２：インシデント管理機能の強化
Service Nowのインシデントのステータス「NEW(起票)」「IN_PROGRESS(対処中)」「RESOLVED(解決済み)」「CLOSED(クローズ)」をディシジョンテーブルファイルを使って、インシデント起票からクローズまで一元で管理し、Service Nowでチケットが起票されていること確認します。
「IN_PROGRESS(対処中)」と「RESOLVED(解決済み)」の間に対処としてOASEとITAを連携し対象のサーバに対して対処(httpdの再起動)を実施します。
シナリオ３：承認フローの組み込み
シナリオ２の設定では自動的に対処を実施してしまうので、対処の開始前に承認フローを組み込むことにより対処前に実施してよいか事前確認できるようにします。
#事前準備
OASE、Service Now、Exastro IT Automationの事前準備として、インストールや下準備を行っていきます。
※Exastro OASE ServiceNow連携機能を使ってみた「①ワークフローの実行」の「事前準備」がすでに完了している場合は、対応不要になります。
###1.OASEのインストール
OASEのインストールを行います。
公式コミュニティサイト掲載のオンラインインストールマニュアルや
Qiita記事「Exastro OASE を最速でインストールする」をご参照ください。
###2.Service Now開発者インスタンスの取得(インスタンス作成)
下記、Qiitaを参考にService Now開発者インスタンスの作成を行っていきます。
Service Nowは個人に無償で開発用インスタンスを提供しています。
Qiita記事「ServiceNow開発者インスタンスの作成」
###3.ITAの設定
Exastro IT Automationをインストールしていきます。
公式コミュニティサイト掲載のオンラインインストールマニュアルや
Qiita記事「Exastro IT Automationをインストールしてみた（v1.8.0）」をご参照ください。
#シナリオ２：インシデント管理機能の強化
それでは、次は新機能の2つ目「インシデント管理機能の強化」を見ていきましょう。
今回はインシデントのステータス「NWE(起票)-IN_PROGRESS(対処中)-RESOLVED(解決済み)-CLOSED(クローズ)」をディジションテーブルで再現し、Service Nowでインシデント起票されていること確認していきます。
###1.ITAの設定
本シナリオでは「IN_PROGRESS(対処中)」と「RESOLVED(解決済み)」の間に対処としてOASEとITAを連携し対象のサーバに対して対処(httpdの再起動)を実施しようと思うので、ITAに対処(httpdの再起動)の設定を登録していきます。
今回はシンプルに適当な対象サーバに対して、httpdの再起動を実行するシナリオになるので
本記事では使用するPlaybookと実行するConductorのみ紹介させて頂きます。
その他の登録内容（「機器一覧」「オペレーション」「Movement」「作業対象ホスト」）については、Qiita記事「Exastro IT Automation クイックスタート (ver1.8.0)」をご参照ください。
今回使用するPlaybook
---
- name: Restart service httpd
service:
name: httpd
state: restarted
今回実行するConductor
###2.OASEの設定
2-1.アクション設定
アクション「ITA Driver ver1」の設定を行います。
ITA DriverはITAと連携してシステムに必要な処置を行うよう自動化設定ができます。
※「ServiceNow Driver」の設定については、記事Exastro OASE ServiceNow連携機能を使ってみた「①ワークフローの実行」の「2-1.アクション設定」をご参照ください。
【使用メニュー】 「システム」グループ / 「アクション設定」メニュー
画面右上から「アクション先の追加」を押下後に、アクション先から「ITA Driver ver1」を選択し、フォームに必要情報を入力し、「保存」ボタンを押下します。
今回は下表のように入力しました。
| 項目名 | 入力値(例) |
|---|---|
| 名前 | ita1.8.1 |
| バージョン | 1.8.1 |
| プロトコル | https |
| ホスト/IP | xxx.xx.xx.xx |
| ポート | 443 |
| ユーザ名 | administrator |
| パスワード | xxxxxxxx |
| プロキシ | http://proxy.example.com:xxxx |
2-2.ディシジョンテーブルにルールを登録
【使用メニュー】 「ルール」グループ / 「ディシジョンテーブル」メニュー
今回は下表のように設定しました。
■基本情報・権限
| 項目名 | 入力値 |
|---|---|
| ディジションテーブル名 | incident_management |
| 概要 | (空欄) |
| 権限の設定 | システム管理者 |
■条件式
| 条件名 | 条件式 |
|---|---|
| IDと等しい | 等しい(数値) |
■未知事象通知
| 項目名 | 選択 |
|---|---|
| 未知事象通知 | ServiceNowと連携する |
2-3.ルールテーブルを編集する
ダウンロードしたディシジョンテーブルファイルを編集していきます。
ルール「1_対処」の「アクションパラメータ情報」で指定している「CONDUCTOR_CLASS_ID」「OPERATION_ID」については、ITAのメニューグループ「Conductor」⇒メニュー「Conductor作業実行」にて確認できます。
今回は下表のように入力しました。
| ルール説明 | IDと等しい(等しい(数値)) | ルール名（必須） | 発生事象（必須） |
|---|---|---|---|
| test1 | 1 | 1_INCIDENT起票 | httpdプロセス停止 |
| test2 | 1 | 1_INCIDENT対処承認申請 | httpdプロセス停止 |
| test3 | 1 | 1_対処 | httpdプロセス停止 |
| test4 | 1 | 1_INCIDENT解決 | httpdプロセス停止 |
| test5 | 1 | 1_INCIDENTクローズ申請 | httpdプロセス停止 |
|対処概要（必須）|アクション種別|
|:---|:---|:---|
|HTTPデーモン再起動を行う|ServiceNow(ver1)||
|発生サーバに対してHTTPデーモンの再起動を行いますので、自動対処の承認をお願いします。|ServiceNow(ver1)||
|ITAによるHTTPデーモン起動を実施|ITA(ver1)||
|ITAの実行が正常に終了したので、インシデントステータスをRESOLVEDに更新する|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=1,OPERATION_ID=1 |
| SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=RESOLVED |
| SERVICENOW_NAME=action_servicenow,INCIDENT_STATUS=CLOSED |
※以下は共通の設定になります。
| 承認メールパラメータ情報 | リトライ間隔（必須） | リトライ回数（必須） | 抑止間隔（必須） |
|---|---|---|---|
| X | 1 | 1 | 1 |
| 抑止回数（必須） | 条件回数（必須） | 条件期間（秒）（必須） | 大グループ（必須） |
|---|---|---|---|
| 1 | X | X | X |
| 優先順位（必須） | 小グループ（必須） | 優先順位（必須） |
|---|---|---|
| X | X | X |
2-4.ディシジョンテーブルファイルのアップロード
【使用メニュー】「ルール」グループ / 「ルール」メニュー
「ファイルを選択」ボタンよりファイルを選択し、その後［アップロード］ボタンをクリックする。
2-5.テストリクエストとルールの本番環境へ移行
ステージング環境で設定したルールが正確に動作するか確認し、問題なければプロダクション環境に移行します。
【使用メニュー】 「ルール」グループ / 「ルール」メニュー
画面上部から[テストリクエスト]を押下後、テストリクエストの各タブの設定を入力していき、「実行」をクリックします。
今回は下表のように入力しました。
| 【ディシジョンテーブルタブ】ディシジョンテーブル名選択 | 【設定タブ】IDと等しい |
|---|---|
| incident_management | 1 |
下画像ように、値に対して意図したルールがマッチすることを確認できましたので、
「閉じる」をクリックし、運用ステータスを「検証完了」にします。
下画像のチェックボタンをクリックしルールをプロダクション環境へ移行します。
###3.動作確認
3-1.curlでリクエストを送る
今回実行するコマンドは以下になります。
今回リクエストを送信した時間は 11:44:04 になります。
curl -X POST -k "https://xx.xxx.xx.xxx/oase_web/event/event/eventsrequest" -H "accept: application/json" -d "{\"decisiontable\":\"incudent_manager\",\"requesttype\":\"1\",\"eventdatetime\":\"2021/11/11 00:00:00\",\"eventinfo\":[\"1\"]}" -H "Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxx"
3-2.アクション履歴の確認
「アクション履歴」画面から、送信したリクエストが確認できるので、ディシジョンテーブルやイベント情報が正しいことを確認します。
【使用メニュー】「ルール」グループ / 「アクション履歴」メニュー
図のように履歴が表示され、全ルールが正常に動作していることが確認できます。
それでは、ITAとService Now側の動作を確認していきましょう。
3-3.ITAの確認
グループメニュー「Conductor」⇒メニュー「Conductor作業一覧」を確認したところ、
2021/11/12 11:44:29 にhttpdの再起動が正常に終了していることが確認できます。
レコードの「詳細」をクリックすると、Conductorの実行結果の詳細が確認できます。
3-4.Service Nowの確認
Service Nowインスタンスのページを開き、画面左上のアプリケーションナビゲータから「インシデント」を検索して「インシデント」下の「すべて」を選択します。
オープン時間が 11:44:05 となっているインシデントがクローズされていることが確認できました。
インシデントを開いて確認してみるとインシデントのステータス「NEW-IN_PROGRESS-RESOLVD-CLOSED」をディジションテーブルで再現することができました。
以上、シナリオ２ではインシデント管理機能の強化されていることを体感できました。
#おわりに
今回はOASE v1.5.0で追加・強化されたService Now連携機能の一つ「インシデント管理機能の強化」を見てみました。
ディシジョンテーブルに定義したルールに合致するアラートが発生した際に、同一条件のルールをディシジョンテーブルを上から順に自動実行される機能を使うことで既知のアラートの対応を事前に設定を入れとけば自動対処できるので工数削減やオペレーションミスなどを防げるように感じました。
冒頭でも記載していますが、残り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 でマッチポンプした話(活用編)