ネットワークエンジニアをしている私ですが、昔はチケットの作成にうんざりさせられていました。リモートサイトでルーターが再起動したり停電が起こったりすると、そのたびに半日ほどをチケットの作成に費やす羽目になります。チケットを自動的に作成する方法があれば、どれだけ多くの時間を節約できたことかと思います。チケット作成でケースごとに異なるのは問題に関する追加情報を入力するコメント欄の内容のみで、あとは毎回同じです。
チケット作成は重要な作業ではありましたが、当時は自動化することなど考えられませんでした。上司には毎回のように、チケットにもっと詳しい情報を含めるよう言われていましたから、考えてみればこれは不思議な話です。チケットの確認が数カ月後になることは珍しくないうえ、チケットが作成されなかったり、必要な情報がほとんど含まれていなかったりすることもありました。
しかし現在では、企業はネットワークプラットフォーム、ソフトウェアのバージョン、稼働時間などの標準的な 一連のファクト をチケット作成中にデバイスから直接取得してデータマイニングを行っています。また、ネットワーク運用 (NetOps) チームは大量のチケットデータを予算の意思決定に活用しています。
たとえば、電源の問題により 400 件のネットワーク中断が発生していたとします。この場合、NetOps は年に 400 件のネットワーク中断を回避できるという事実の裏付けとともに、バックアップ用バッテリーの予算として 40,000 ドルを申請できます。情報に基づいてビジネス上の意思決定をする場合、このような指標を取得できることは非常に有益です。
このブログシリーズでは、人気の高いクラウドベース SaaS プロバイダーである ServiceNow からの変更要求を Ansible で自動化する方法について説明します。本稿はその第 1 回目となります。ServiceNow には、Ansible Playbook を使用するためのテストインスタンスを開発者に提供する、便利な機能が備わっています。本稿および続く各稿ではこの機能を利用します。ServiceNow Developers ポータルサイトで登録すれば、自分専用の開発者用インスタンスを無料で取得できます。
ServiceNow チケットの作成
Ansible のディストリビューションには、ServiceNow チケットのオープンとクローズを簡単に行うための snow_record モジュールが含まれています。このモジュールを使用するには、前もって Python ライブラリの pysnow をインストールしておく必要があります。
次に必要なのは、先ほど作成した開発者クラウドベースの ServiceNow インスタンスへの認証に使用するユーザー名、パスワード、インスタンスを取得することです。
注：以下に示すように、インスタンスは「instance: dev99999」のような形式です。
instance:_http://dev99999.service-now.com のような完全な URL ではありません。
change_request_vars.yml
---
#snow_record variables
sn_username: admin
sn_password: my_password
sn_instance: dev99999
#data variables
sn_severity: 2
sn_priority: 2
以下は、ServiceNow チケットを作成する Ansible Playbook の例です。
---
- name: Create ticket with notes
hosts: localhost
gather_facts: no
connection: local
tasks:
- name: include vars
include_vars: change_request_vars.yml
- name: Create a change request
snow_record:
state: present
table: change_request
username: "{{ sn_username }}"
password: "{{ sn_password }}"
instance: "{{ sn_instance }}"
data:
severity: "{{ sn_severity }}"
priority: "{{ sn_priority }}"
short_description: "This is a test opened by Ansible"
register: new_incident
- debug:
var: new_incident.record
ServiceNow API の活用
オープンするチケットの種類は table パラメーターで指定します。利用可能なその他のパラメーターを知りたい場合は、チケットの作成後に ServiceNow API から送信される JSON 辞書を参照するとよいでしょう。私は register でその辞書に変数名を作成し、debug を使用してターミナルで表示しています。以下のスクリーンショットは、その辞書の一部です。
これは、タスクの data セクションに追加できるパラメーターを確認するのに便利です。辞書に含まれるパラメーターの全部ではなく 1 つだけを表示するには、debug を次のように変更します。以下の例ではチケット番号を表示します。
- debug: var=new_incident.record.number
この変数 (var) は格納されているレジスター new_change_request からデータを取得し、record という辞書の number というパラメーターを表示します。
close_code、state、comments など、record 辞書の多くのパラメーターで同じことができます。
ServiceNow Web ポータルでの変更の確認
次に、ServiceNow の開発者インスタンスにログインし、左側のメニューバーから Change > All を選択します。変更要求が一覧に表示されます。
Ansible Playbook タスクにより、Short description が「This is a test opened by Ansible」、Priority が「2 - High」となっています。
ServiceNow チケットのクローズ
ここまで、ServiceNow チケットの作成手順を紹介してきました。次に、チケットのクローズ、すなわち解決について説明します。この操作を行うには、別の Ansible タスクで state パラメーターを指定します。ただ、state は record 辞書のパラメーターであると同時に snow_record モジュールのパラメーターでもあるため、扱いには注意が必要です。Ansible でこの多目的パラメーターを使用するときには気を付けてください。
以下は、チケット作成時の record 辞書の一部です。
この時点では、state は「-5」です。下の Ansible タスクを実行すると、この値が「-3」に変更され、チケットの state が「New」から「Authorize」に変わります。
---
- name: Modify a change request
snow_record:
state: present
table: change_request
username: "{{ sn_username }}"
password: "{{ sn_password }}"
instance: "{{ sn_instance }}"
number: CHG0030002
data:
state: -3
register: incident
- debug:
var: incident.record.state
ServiceNow では、チケットをクローズするには change_request が複数のステータスを経由する必要があります。各ステータスに対応する数値は、ServiceNow のドキュメントで確認できます。私のおすすめは、5 つの Ansible タスクを作成し、それらを使用してステータスを -3、-2、-1、0、3 の順で変更することです。ただし、これらの値は ServiceNow Kingston リリースのものであり、他のリリースではステータスの数値が異なる場合があることに注意してください。組織によっては上記とは異なる手順が必要になるかもしれませんが、この記事が基本的なポイントを押さえる役に立てばと思います。以上、Ansible Playbook を使ってチケットを作成する方法、およびラベルを指定してチケットをクローズする方法をご紹介しました。
次回をお楽しみに。パート 2 では、解析したファクトをチケットに追加する方法をご紹介します。
