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
