ServiceNowのTokyo Upgrade事例

ServiceNowのTokyo Upgrade事例

前回に引き続き ServiceNowの話題ですが、今回はServiceNowのバージョンとアップグレードについて紹介したいと思います。

ServiceNowのバージョンの考え方

ServiceNowは年に２回のメジャーバージョンアップをリリースしています。2022年では3月にSan Diegoというバージョンが、そして9月にはTokyoというバージョンがリリースになりました。ServiceNowではメジャーバージョンに地名が使われており、頭文字がアルファベット順になっています。(カッコ内はリリース時期)

Paris (2021 Q1)

Rome (2021 Q3)

San Diego (2022 Q1)

Tokyo (2022 Q3)

Utah (2023 Q1)

Vancouver (2023 Q3)

Washington (2024 Q1)

https://www.servicenow.com/success/instance-upgrades.html

Tokyo以降の地名については2024年にリリース予定のWashingtonまでは決まっているようですが、次のXが何になるのかはまだ公表されていないようです。なかなかXで始まるメジャーな地名が無いので気になるところです。

ServiceNowでは最新のバージョンと最新よりひとつ前のバージョンがサポートの対象となり、それ以前のバージョンはサポートの対象外となります。2022年12月時点ではTokyoと、ひとつ前のSan Diegoまでがサポート対象で、それ以前にリリースされたParis、Romeなどはサポート対象外となります。また、サポート対象のバージョンに関してはメジャーバージョンがリリースされた後でも定期的にパッチが提供され、自動的ににスケジューリング＆インストールされるようになっています。たとえば、Romeではリリース後も10回程度パッチが提供されました。

アップグレードのスケジュール

今回アップグレードする際に、ServiceNow社から新しいバージョンがいつリリースされるのか、という公式な事前のアナウンスは確認していた範囲ではありませんでした。８月にNow Supportに問い合わせたところ「9月1日にリリース予定」ということで、アップグレードの日程を組んだところ、２日を過ぎてもリリースが行われず、再度Now Supportに問い合わせたところ、いつの間にか9月21日に変更になっていたこともありました。

ServiceNowインスタンスをアップグレードする際には、本番ではない環境でアプリケーションの動作テストが必要です。そしてもし動作に不具合があればその対応ができるように、事前にある程度(最低でも１週間程度)のスケジュールを確保しておく必要があります。今回はリリース日程の変更によりアップグレードの対応日程を何度か組みなおす必要がありました。

実際にリリース日を迎えても、ServiceNowのオフィシャルサイトなどが更新されるのは、ServiceNow社があるカリフォルニア時間でリリース日を迎えた時のようで、日本やオーストラリアのように標準時より早いタイムゾーンからすると、公式にアナウンスがあって使用可能になるのはだいたい予定日の翌日くらいで考えておくとよいかもしれません。メジャーバージョンがリリース後、２つ前のバージョンは自動でアップグレードされますが、リリース後60日ほどはこれまで通り、使うことが可能です。

また、リリース後に動作チェックするのでは日程が足りないような場合には、公式リリースとは別に、Early Availability versionというリリース前段階のバージョンを利用することができます。こちらは、Now Supportからの申し込みが必要なのですが、申し込みをすると、公式リリース前にアップグレード版をインストールすることが出来ます。今回はこのEarly Availability versionでテストしている際に不具合を発見することができたので、大変助かりました。

アップグレードの方法

ServiceNowをアップグレードするには、インスタンスを管理するNow Support から行う必要があります。Now Supportのダッシュボードから Instances メニューをクリックすると、管理しているServiceNowインスタンスの一覧が表示され、この画面からアップグレードのスケジュールを指定することができます。アップグレードを行う日時については、好きな時間が選べますが、選択できるのは現時点より約２時間後からで、指定した時間がServiceNowの都合と合わない場合、後から自動的にスケジュールを変更されてしまうことがあるので、設定後に再度確認したほうが安心です。

アップデート処理

今回、RomeからTokyoへ、San Diegoを飛ばす形でバージョンアップを行いました。インスタンスのバージョンアップにかかった時間は約1時間半ほどでした。アップグレードの最中もServiceNowを使用することは可能ですが、トラブルを避けるためにはアップグレードはなるべくユーザーが触らないような時間帯に行うのがよさそうです。

https://docs.servicenow.com/en-US/bundle/tokyo-release-notes/page/release-notes/concept/rn-n-2-landing-page.html

Skip処理

アップグレードが完了すると、処理中に問題があった部分がSkipとして報告されます。Skipとはインスタンスをアップグレードする際に、ServiceNowのリリース時の状態と現状を比較し、差異がある場合にアップグレードをSkip（保留）するという仕組みになっています。管理者が、その差異をそのままにしておきたい場合にはSkipをRetain(保持)し、気にせずにアップグレードを適用する場合にはSkipをRevert(元に戻す)を選択します。

Skipについては Priority1 から Priority 5 に分類されるのですが、Priority 1 と Priority 2については一つ一つ確認することが推奨されています。今回はインスタンスごとに差がありましたが、約100件～400件の処理を行いました。ばらつきが大きかったのは、ServiceNow側で本来変更されていない部分を「変更された」と誤認したことが大きいようです。

アップグレードのトラブル

今回は本番サーバーをアップグレードする前にテスト用のインスタンスを用いて、アップグレードと動作確認を行うことができました。Tokyoにアップグレード後の動作確認中に、アプリケーションの特定の画面を開くと権限のエラーが発生するという現象が起き、この解決にはかなり苦労しました。

現象としては、ServiceNowのプラグインでインストールされる特定のRole（権限）が通常５つのサブRoleを持っているのですが、そのうち一つのRoleがアップグレードすると何故か消えてしまうというものでした。

対応としては、Now Supportに問合せチケットを発行し、こちらから現象の報告をし、サポートの担当から状況を確認する質問が返ってきて、それに回答して、などを何往復か繰り返す必要がありました。Now Support側でもインスタンスをコピーし、同じ手順でアップグレードしたところ現象が再現されることを確認し、最終的には、ServiceNow側のアップグレードの問題として認識してもらうことができました。こちらの問題に関しては、時期は未定ですが改善されたバージョンがいずれパッチという形でリリースされると思います。

また、サポートより消えたRoleを復活させるためのXMLの提供を受けることができました。

感想など

今回、初めてServiceNowのアップグレードを体験したのですが、ServiceNowという非常に大がかりな仕組みをこれだけの頻度でアップグレードしていけるServiceNowの力強さを感じました。そして、アップグレードの際のSkipという考え方もなかなかよく考えられていると思いました。正直に言うとアップグレードを行う前には「もっと多くの問題がでるのではないか」と思っていたのですが、予想していたほどには苦労せずにアップグレードを完了することができました。ServiceNowにはProblem管理の機能があり、これを使うと問題の報告、担当者へのアサイン、問題の解決、報告者へのフィードバックなどがスムーズに行えるようになっています。おそらく事前にServiceNow側でこの機能を使ってアップグレードに関しての問題解決を時間をとって十分にやられたのではないかと思います。

ServiceNow
https://www.servicenow.com/

ServiceNowのコンサル、開発、保守ならSazae – ITSM, HRSD, CSM…
https://sazae.com.au/ja/servicenow-ja/