ServiceNowのUpgrade・パッチ適用実施にあたり、そもそもどんな影響があるのか、また何をすればよいのかをまとめます。
要点
ServiceNowのUpgrade・パッチ適用時には、既存業務（機能）への影響や、ユーザ側で行った設定変更（コンフィグレーション）・カスタマイズへの影響が考えられるため、次の対応を行う必要があります。
・変更内容の確認（リリースノートの確認）
・設定変更（コンフィグレーション）・カスタマイズとServiceNow社による変更とのコンフリクトの解消
・利用中の機能の動作確認（リグレッションテスト）
・（必要に応じて）バグの解消、既存業務を継続するための追加の設定変更（コンフィグレーション）・カスタマイズ
・（必要に応じて）新機能の検証
Upgrade・パッチ適用とは？
まず、ServiceNowにおけるパッチ・Upgradeとは？という方は、下記の記事を参照ください。
要点は下記の通りです。
・半年に1度新たな（メージャー）バージョンがリリースされ、新機能の追加や既存機能の変更が行われる
・各メジャーバージョンのサポート期間は2つ次のバージョンがリリースされるまで。そのため1バージョンはスキップしてアップグレードすることができる
・パッチはほぼ毎月のペースでリリースされ、既存機能の修正が行われる
Upgrade・パッチ適用ってどんな影響があるの？
ユーザの皆さんが最も気になるのは、Upgrade・パッチ適用でどんな影響が出るか、ということではないでしょうか。Upgradeやパッチ適用により、追加の費用を払わなくても新機能の追加や既存機能の改善を受けられますが、一方で既存業務や機能に影響を与える可能性があります。Upgrade・パッチ適用時に発生し得る影響を、利用者目線、運用者・開発者目線の2つで説明します。
利用者への影響
利用者への影響としては、次のようなものが考えられます。
・（実施時にインスタンスの利用を止める場合）システムが一定時間利用できなくなる
・Upgradeやパッチ適用内容にバグがあり、既存の業務が実施できない障害が発生する
・既存機能が変更され、既存業務が実施できなくなる / 業務のやり方を変える必要がある
・UIが変更される（新たなメニューが表示される、ボタンが追加される、項目の配置が変わる、など）
なお、Upgradeやパッチ適用によってインスタンスのデータが消失する、設定変更（コンフィグレーション）やカスタマイズした機能が消失する、といったことは理論上はあり得ますが、これまで私が見てきた事例でもServiceNow社に問い合わせた事例でも一度もありませんので、これについてはあまり心配する必要がありませんし、心配したところでどうにもなりません。（これが信頼できない場合、パッケージ製品を使わない方が幸せだと思います）
運用者・開発者への影響
運用者・開発者への影響としては、次のようなものが考えられます。
・（実施時にインスタンスの利用を止める場合）システムが一定時間利用できなくなる
・Upgradeやパッチ適用内容にバグがあり、既存の業務が実施できない障害が発生する
・開発UIが変更される、新たな開発画面が追加される
・Upgradeやパッチ適用の検証を実施するために開発環境や検証環境を凍結する場合、一定期間開発ができなくなる
・Upgradeやパッチ適用実施期間中に並行で開発、テストを行っている場合、開発環境のUpgrade後に開発中の機能のリグレッションテストが必要になる可能性がある
・ユーザ側で既に行った設定変更（コンフィグレーション）・カスタマイズとServiceNow社による変更との間でコンフリクトが発生し、対応が必要になる
パッチ・Upgradeをするときに何をしなきゃいけないの？
Upgrade・パッチ適用を実施する際には、上述の影響が考えられるため、事前に非本番環境で次の対応を行った上で、本番環境に対して適用するのが一般的です。
変更内容の確認（リリースノートの確認）
まずは、どのような新機能・機能改修があるかを知るために、リリースノートを確認します。リリースノートは膨大なので、機能別の変更点が載っているページから、利用している各機能に関する変更を見ていくと効率的です。また、軽微な変更についてはリリースノートに記載されないこともあることに注意が必要です。これらは後述のリグレッションテストでカバーします。
設定変更（コンフィグレーション）・カスタマイズとServiceNow社による変更とのコンフリクトの解消
Upgrade・パッチ適用を実施した際には、ユーザにより実施している設定変更（コンフィグレーション）・カスタマイズとServiceNow社による変更との間でコンフリクト（互いに矛盾する変更を行っている状態）が発生することがあります。コンフリクトが発生した場合は、次のいずれかの対応を行う必要があります。
① 標準の状態に戻す
ServiceNow社による変更を適用し、標準の状態に戻します。設定変更（コンフィグレーション）・カスタマイズを行っている機能については、パッチ適用やUpgradeで当該機能が変更されるたびにコンフリクトが発生し、対応を行わなければならない上に、機能改善の恩恵を受けられなくなる可能性があるため、可能な限りこの対応を行うことが望ましいです。
② 変更をマージする
ServiceNow社による変更を適用した上で、改めて現在行っている変更を実施することで、変更をマージします。基本的には標準に合わせ機能改善の恩恵を受けつつも、業務上どうしても変更が必要な部分（たいていはラベルなどのUI上の軽微な変更）を実施する対応です。この場合、パッチ適用やUpgradeで当該機能が変更されるたびにコンフリクトが発生することに注意です。
③ 現在の状態を維持する
ServiceNow社による変更を無視し、ユーザ側で行った設定変更（コンフィグレーション）・カスタマイズを維持します。UI上の軽微な変更などであればこの対応で問題ありませんが、ビジネスロジックなどでコンフリクトが発生した場合は、機能改善の恩恵を受けられなくなったり、公式ドキュメントに記載の動作との差異が生まれる可能性があるため、可能な限り①、②の対応を考えます。
なお、設定変更（コンフィグレーション）・カスタマイズの中でも、既存機能に対するものではなく、カスタムテーブルなど独自に作成したものについては通常コンフリクトは発生しません。
利用中の機能の動作確認（リグレッションテスト）
新機能の追加や既存機能の改修によって、これまで行っていた業務ができなくなったり、画面が変更に伴うマニュアルの書き換えが必要になる可能性があります。こうした影響を見つけるために、既存業務が実施できるかをテストします。
リグレッションテストをどこまでやるか、については企業によってポリシーが大きく異なりますが、シナリオテストの粒度で実施することが多いです。また、ServiceNowにはテストを自動化するAutomated Test Framework(ATF)と呼ばれる機能があり、Upgradeやパッチ適用のたびに行うテストについては最低限ATFで実装しておくことで、リグレッションテストが容易になります。
（必要に応じて）バグの解消、既存業務を継続するための追加の設定変更（コンフィグレーション）・カスタマイズ
リリースノートの確認、コンフリクトの解消、リグレッションテスト等で、バグが見つかったり、既存業務が継続できないことが分かった場合は、その解消を行うために、Upgradeの対応の一環で追加の設定変更（コンフィグレーション）・カスタマイズを行うことがあります。
（必要に応じて）新機能の検証
新機能・機能改修によってこれまでできなかったことができるようになったり、リリースノートを確認する中で新たに試してみたい機能が出てくることがあります。これらの検証も事前に検証用環境で行っておくとよいでしょう。
おわりに
以上です。次はUpgrade・パッチ適用をスムーズに進めるために事前に検討しておくべきことをまとめたいと思います。
コメント