【公式手順＋α】Servicenowアップグレード前のチェックリスト

はじめに

ServiceNow は 半年ごとに新しいバージョンがリリース され、セキュリティや機能改善の観点から定期的なアップグレードが必要です。
しかし、準備不足のまま本番環境をアップグレードしてしまうと、以下のような事態に遭遇したり、悪影響を及ぼしたりするリスクがあります。

• 既存機能の不具合
• セキュリティの不備
• 業務停止やユーザー影響

ServiceNow の公式チェックリストは、あらゆる組織で共通に活用できる標準ガイドラインです。私たちはそれを尊重しつつ、さらに現場での経験から得た手順を追加して運用していく必要があります。

この記事では、公式のチェックリストを踏まえて 独自のステップや流れを組み込み、複数環境を活用するためのアップグレード前準備の手順 を整理しました。
アップグレード前に見直すべきポイントをまとめているので、参考指針として活用していただければ幸いです。

アップグレードの前提知識

ServiceNow は半年ごとにメジャーリリースを実施しており、各リリースにはサポート期間があります。新バージョンには新機能や仕様変更が含まれるため、 互換性のリスクが高く、アップグレードにはパッチ適用以上の検証と準備 が必要です。
アップグレードによって新機能・仕様改善・パフォーマンス強化を取り込むことができますが、影響を受ける部分を事前に把握することが重要です。
また、参考までに、私がこれまで実施したアップグレードは 1.5 時間前後で完了するケースが多いですが、環境の特性やバージョン差、データ量によって所要時間は変わる可能性があります。そのため、実施時は余裕を持ったスケジュールを確保することが望ましいです。

公式のアップグレード計画チェックリスト↓

環境構成の例

アップグレードを安全に進めるためには、複数の環境を役割分担して運用する構成が推奨されます。
以下はその一例です（本記事ではこの構成を前提に説明します）。

本番環境（Production)

• ユーザーが日常業務で利用する環境
• 最終的にアップグレードを適用する対象

開発環境（Development）

• 運用保守メンバー専用
• 現行バージョンで改修や単体テストを行う環境

UAT環境（User Acceptance Test)

• 運用保守メンバー＋ユーザーが利用
• 主にユーザー受入テストを行う環境

この構成を採ることで、

• UAT環境を通じてユーザーが安心して検証できる
• 本番アップグレード失敗時のリスクを最小化できる

などのメリットを得ることできます。

アップグレード前準備（チェックリスト）

以下は、アップグレードを安全かつ円滑に進めるために必ず確認しておきたい前準備ステップの一覧です。

インスタンスセキュリティの確認

公式ではセキュリティ遵守チェックまでは明記されていないようですが、セキュリティ基準に違反しているかどうかリスク評価することで、脆弱性を解消することができます。具体的には、isc_security_configurationsテーブルにおいてcompliance stateがnon-compliantであるレコードを抽出します。 該当レコードがある場合、設定項目の違反状態の確認、リスク評価、改修を実施し、compliance stateがnon-compliantにならないことを確認します。

Known Errorの確認

アップグレード対象バージョンには、 既知の不具合（Known Error）が確認されている 場合があります。事前に確認しておくことで、自社環境に影響する問題を把握し、回避策や検証計画に反映することができます。

該当アップグレードバージョンのKnown Error↓

開発環境へ本番環境をクローンバック & アップグレード

クローンバックをすることで本番環境のデータが開発環境に上書きされます。
本番環境と同じデータ・構成でアップグレードを試すことで、 テスト(開発)環境特有の差異を排除 することができます。
実際の業務データを使った検証が可能になり、次項目の検証において精度の高いテストができます。

Clone Admin Consoleを用いたクローンバック方法↓

アップグレードについて↓

基本検証および修正

UAT環境（現行版）と開発環境（アップグレード版）を比較し、ユーザー業務に沿った検証( 通常業務で利用しているワークフローが正しく動作するか、ユーザー画面に差異がないか )を実施します。修正が発生した場合は Update Set を作成して管理し、開発・UAT・本番環境に一貫して適用できるようにします。

スキップログの確認

アップグレード時にカスタマイズ済みレコードの競合により適用されなかった（スキップされた）レコードを確認し、必要に応じてマージや修正を行います。

UAT 環境へクローンバック & アップグレード

必要に応じて前項目で作成した 修正 Update Set を適用し、次項目のユーザーによる受入テストの整備をします。

ユーザーによるUAT環境の確認

実際のユーザーに通常業務を操作してもらうことで、技術検証だけでは見つからない業務上の不具合や操作感の差異を確認できます。本番リリース前にユーザー視点での動作保証を得ることで、安心してアップグレードを適用できる体制を整えます。

開発環境の最終クローンバック

公式ではクローンバック回数やタイミングは明確に記載されていませんが、 本番環境を直前にクローンして開発環境に保持しておくことで、アップグレード前の最新状態を確保できます。 万が一本番アップグレードで不具合が発生した場合でも、このコピーを参照して差分調査や復旧対応を迅速に行えます。
※ ServiceNowではアップグレード後のロールバック機能は存在しません。また、開発環境やUAT環境がない場合はServiceNowサポートに連絡すると復元可能のようですが、詳細については各自で確認することをお勧めします。

よくある注意点とトラブル回避

クローンバックを行うと、対象インスタンス上のデータが上書きされ、インスタンスに存在する独自のデータや Update Set が消えるため、必ず退避しておきましょう。
また基本検証では、ユーザーに成り代わって通常業務の操作やよく利用する画面を確認しましょう。あらかじめユーザー業務を把握して検証を行うことで、単なる機能動作チェックにとどまらず、実際の業務フローに即した不具合や差異を早期に発見することができます。さらに、確認内容を 基本検証項目として整理・管理 することで、検証の抜け漏れを防ぎ、継続的に品質を担保できます。

公式手順を補う実践上の工夫

公式手順には明確に記載がない、現場で効く本記事の +α対応 を以下にまとめます。

• インスタンスの設定違反を見つけて修正し、脆弱性を排除することでセキュリティ基盤を固める
  → インスタンスセキュリティの確認
• 基本検証フェーズでは、業務フローや UI 差異に注目して不整合を未然に防ぐ
  → 基本検証および修正
• 最終クローンバックは、アップグレード直後に安全網を残すための保険として機能する
  → 開発環境の最終クローンバック

まとめ

アップグレードを成功させるためには、事前準備と検証を丁寧に進めることが欠かせません。複数環境を活用し計画的に取り組むことで、業務への影響を最小限に抑え、安心して本番アップグレードに臨むことができます。
ぜひ自社の運用に合わせてチェックリストを取り入れ、より安全で質の高いアップグレード運用の策定につなげてください。

We Are Hiring!