インスタンスのアップグレードに関する FAQ - よく寄せられる質問Descriptionインスタンスのアップグレードに関連してよく寄せられる質問と顧客の問題に対する回答をご確認ください。この情報は、out of box インスタンスに適用されます。インスタンスにカスタマイズが存在する場合、リストされている動作に影響を与える可能性があるため、各セクションの下のリンクにアクセスしご確認ください。 セルフホスト型/オンプレミスのお客様は、こちらの KB も参照してください KB0598275 - セルフホスト型のお客様向けのアップグレードベストプラクティス 1.ServiceNow サポートでアップグレードの変更をスケジュール/変更/キャンセルする方法は？2.パッチプログラムおよび提供終了アップグレードプログラムの KB3.アップグレードで従うべきベストプラクティスは何か？4.ServiceNow サポートの変更でアップグレードが開始されなかったのはなぜですか？また、アップグレードが開始予定時刻を過ぎたのはなぜですか？5.アップグレードの予行演習を行うのに最適なプロセスはどれか？6.アップグレードはどのくらいの期間実行されますか？7.アップグレード中、インスタンスでは何が起こりますか？8.アップグレードの前にアドホックバックアップを取得できますか？9.アップグレード後にデータが破損した場合、データを復旧するためのオプションはどれですか？10.アップグレード中にインスタンス/アプリケーションに影響する機能は何ですか？11.アップグレード中にユーザーを制限する方法は？12.ServiceNow テクニカルサポートはアップグレードを監視できますか？13.ノードのアップグレードが失敗した場合、またはアップグレードサマリーでノードが赤の場合はどうすればよいか？14.アップグレードをロールバック/ダウングレードできますか？15.更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法は？16.スキップされたレコード数が準本番インスタンスと異なるのはなぜですか？17.アップグレードサマリーとアップグレード履歴レコード間でスキップされた更新数の不一致があるのはなぜですか？18.進行中のアップグレードをキャンセルすることはできますか？19.スキップされた更新レコードを確認し、その解決を追跡するにはどうすればよいですか？ (新しい Paris & after 機能)20.P+ インスタンスで予定されているアップグレードを通知する方法21.カスタマイズされたレコードを OOB に戻し、アップグレード可能性のための Update-set を介して転送する22.適用されたワークアラウンドがアップグレード中に修正された OOB レコードで上書きされるようにする方法23.古いアップグレードのアップグレードサマリーレポートを表示できますか？ 1.ServiceNow サポートでアップグレードの変更をスケジュール/変更/キャンセルする方法は？ KB0541128 - How to manage and schedule instance upgrades インスタンスアップグレードのタイムスロットがありません 2.パッチプログラムおよびServiceNow EOL アップグレードプログラムの KB KB0696901 - ServiceNow パッチプログラムに関する FAQKB0610454 - EOL (別名：サポートされていないリリースファミリのアップグレードに関する FAQ 3.アップグレードに関して従うべきベストプラクティスは何ですか？ ドキュメントのこの章では、アプリケーションのアップグレードで従うべきベストプラクティスについて説明します：アップグレード インスタンスのアップグレード。 YouTube チャネルのこのビデオもご覧ください: 新規リリースへのアップグレード 4.ServiceNow 変更レコードの開始予定時刻にアップグレードが開始されなかったのはなぜですか？また、アップグレードが開始予定時刻を過ぎたのはなぜですか？ ServiceNow 変更レコードの開始予定によって、インスタンスのアサインされた WAR バージョンを ServiceNow インスタンスレコードで変更するタイミングが決まります。 アップグレードは、インスタンスの「アップグレード/可能なアップグレードのディストリビューションを確認」ジョブによってトリガーされ、1 時間間隔 (OOB) で実行されます。このジョブは、ServiceNow インスタンスレコードでアサインされた WAR バージョンを 1 時間ごとにチェックします。割り当てられた新しい WAR バージョンを検出すると、新しい WAR バージョンをダウンロードします。 メモ：インスタンスのアップグレードが、ServiceNow 変更レコードの開始予定時刻からインスタンスでトリガーされるまでに、最大 1 時間かかる場合があります。 実際の作業開始時間は、インスタンスで実際のアップグレードがトリガーされると、ServiceNow 変更レコードが更新されます。 インスタンスで次の URL に移動すると、アップグレードジョブを確認できます (Pre Paris)： /sys_trigger_list.do?sysparm_query=name%3Dupgrade (Paris+)：/sys_trigger_list.do?sysparm_query= nameLIKEpossible%20upgrade&sysparm_view= Paris から 「アップグレード」ジョブが「可能なアップグレードの配布をチェック」に置き換えられました。 「アップグレードスクリプトのチェック」ジョブが「可能なアップグレードについてデータベースをチェック」に置き換えられました。 「アップグレード/可能なアップグレードの配布を確認」ジョブで、システム ID の値が空白であることを確認してください。値がある場合は、[--なし--] が選択されていることを確認してください。 システム ID のハードコーディングは推奨されるアプローチではありません。選択されたノードが (AHA の場合はセカンダリ DC から) 遠方のノードになる可能性があり、アップグレードが長時間実行される可能性があります。 アップグレードジョブは WAR ファイルをダウンロードし、このジョブがトリガーされたノードをアップグレードします。その後、このノードが再起動され、2 番目のジョブ「アップグレードスクリプトのチェック/可能なアップグレードのデータベースのチェック」がシステム起動時にトリガーされ、アップグレードが継続されます。これらのジョブはどちらもワーカースレッドで実行されます。 ServiceNow 変更レコードの「開始予定時刻」を過ぎた後に「アップグレード/可能なアップグレードの配布を確認」ジョブの次のアクション時刻を変更することは、問題が発生する可能性があるため、推奨されるアプローチではありません。 このジョブの実行時間の約 10 ～ 15 分前に「開始予定時間」の変更を計画してください。または、[次のアクション時間 (分)] を変更の「開始予定時間」の 2 〜 3 時間前に調整して、変更の開始の代わりに数サイクルを正常に実行できるようにすることもできます。 5.アップグレードを予行演習する最善のプロセスは何ですか？ 本番アップグレードの ETA/動作を取得することは非常に重要です。 正しいタイムライン/動作を記録するには、次の 2 つのオプションがあります。 「添付ファイル」、「監査とログ」、および「除外リストで指定されたテーブルを除外」を含む (デフォルトは除外) 本番環境から準本番環境への完全クローンを開始します (除外のすべてのチェックボックスをオフにして含まれるようにします)。その後、サブ本番環境をアップグレードします。本番インスタンス。上記のテーブルはインスタンスで最も大きな部類のテーブルであり、このテーブルへのインデックス作成やスキーマ変更には合計アップグレード時間のかなりの部分を要するため、これらのテーブルを含めることは非常に重要です。除外された場合、その時間を予定されたアップグレードアクティビティに含めることはできません。London からは、クローン中にタスクテーブルのデータ量を選択できます (デフォルトは 90 日)。正しいタイムラインを分析するにはフルタスクテーブルが必要であるため、必ず [フル (Full)] を選択してください。準本番インスタンスを正確なレプリカにできるように、本番インスタンスのバックアップを準本番インスタンスへの復元を要求します。準本番環境をアップグレードでき、これにより、アップグレード実行時間の正確な ETA がわかります。 アップグレードは複数回ドライランを実行する必要があります。準本番環境でアップグレードの適切なテストを行うと、本番環境でのアップグレードは正常に完了し、サポートが予期しない問題を調査することができます。利用可能なオプションについては、 Now Support ヘルプセンター にアクセスすることをお勧めします。 6.アップグレードの実行時間はどれくらいですか？ これはより広範な質問であるため、ETA を提供することはできません。組織固有のカスタマイズによってどのインスタンスも異なり、アップグレード時間はインスタンスのデータ/カスタマイズの範囲に応じて異なります。この情報を取得する唯一の方法はドライランです。 7.アップグレード中、インスタンスで何が発生しますか？ アップグレード中も、ユーザーはインスタンスにログオンして通常どおり作業できます。影響は最小限に抑えられ、ユーザーが接続しているノードがアップグレードされると、ユーザー接続は 1 回リセットされます。 レコードの作成と作成されたレコードは、アップグレードの影響を受けません。アップグレードで変更されるのはスクリプトとスキーマだけです。 ノードをアップグレードしてからスキーマ/DB のアップグレードをトリガーすることで、1 つのノードがプロセス全体を実行します。これと並行して、その他のノードでアップグレードが実行されます。アップグレード後にノードが再起動され、接続がリセットされます。 したがって、ノードが再起動されると、ノードは新しいバージョンになり、DB はデータベースのアップグレードが完了するまで新しいバージョンになりません。レコード作成が中断されることはありませんが、アップグレード中はユーザーを制限することをお勧めします。これにより、システムは利用可能なすべてのリソースをアップグレードアクティビティに使用できます。 8.アップグレード前にアドホックバックアップを行うことはできますか？ 残念ながら、アドホックバックアップを実行するオプションはありません。プライマリ DB とセカンダリ DB (利用可能な場合) 用に別々にバックアップを取ります。 バックアップサイクルは、週次の完全バックアップと日次の差分バックアップで構成され、14 〜 28 日間 (保持ポリシーに基づく) のバックアップを提供します。バックアップはすべてディスクに書き込まれます。テープは使用されず、バックアップが外部に送信されることはありません。お客様のライブデータに適用されるコントロールはすべて、バックアップにも適用されます。ライブデータベースでデータが暗号化されている場合、バックアップでも暗号化されます。 詳細については、「本番を含む ServiceNow インスタンスのバックアップ要求」の記事を参照してください。 バックアップと保存の詳細については、このホワイト ペーパー「ServiceNow クラウドでのパフォーマンス、スケーラビリティ、および可用性の実現」で説明されています。 データのバックアップと復旧 9.アップグレード後にデータが破損した場合、データを復旧するために何ができますか？ データは安全に保管されます。本番環境でのデータ破損の可能性が最も低いシナリオでは、本番インスタンスを一時インスタンスにポイントインタイム復元するオプションがあります。これにより、本番インスタンスのデータをその特定の時間に戻してデータを比較できます (特定の分) を TEMP インスタンスに追加します。 ポイントインタイム復元は、インスタンスを利用可能な最後のバックアップに復元し、BIN ログ/トランザクションログから指定された残りのデータを再作成することによって行われます。このプロセスは、最後のバックアップ以降にインスタンスで実行された INSERT/DELETE/UPDATE の量によっては、長い時間を要する可能性があります。bin ログの自動保持期間は、本記事の執筆時点では 4 日間です。 PIT 復元は複数のチームが関与する手動プロセスであり、これは重大な条件で開始され、フェイルオーバー/復旧/切り戻し/ロールバック方法として扱うことはできません。 注意：本番環境で直接 PIT 復元を行うことはありません。前方修正のみを行います。PIT 復元は、一時/準本番インスタンスでのデータ比較とデータ復旧にのみ使用されます。 TEMP インスタンスのデータを取得したら、これを使用して POST と PRE のアップグレードバージョン間でデータを比較できます。また、個々のケースに基づいてデータを転送するための標準運用手順があります。 前方修正とバックアップからの復元 非本番/準本番インスタンスでのデータの損失または破損 KB では、復元の開始に使用できるさまざまなシナリオとセルフサービスオートマトンについて説明しています復元します。この前に必ず開発作業を保存してください。 10.アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？ 更新セットのプレビュー/コミットおよびプラグイン/アプリのインストールは、アップグレード中は利用できません。「システムが現在アップグレードしているため、情報メッセージ更新セットのプレビューとコミットは利用できません。アップグレードモニターについては、ここをクリックしてください。」」というメッセージが表示されます。 これは、アップグレードが完了した後に再開されます (アップグレード変更のクローズ) 影響の詳細については、次の記事を参照してください： KB0622951 - Features Impacted during the database upgrade アップグレード中に統合のいずれかが機能していない場合、ジョブが「アップグレードセーフ」としてリストされていない可能性が高くなります。 後作用についてコメントすることはできないため、アップグレードの過程で変更しないことをお勧めします。 カスタムジョブスケジュールを「アップグレードセーフ」として設定しないでください。このフィールドは、アップグレードを妨げないようにするためのものです。 11.アップグレード中はどのようにユーザーを制限しますか？ アップグレード中にユーザーを制限する OOB オプションはありません。 これを実現するためのワークアラウンドとカスタマイズがいくつかあります。これは、カスタマーサポートの範囲外で、開発者/パートナーとともに実装する必要があります。 利用可能なオプションは次のとおりです。 インスタンスに Single Sign-On が実装されている場合は、SSO/SAML のポータル/ID プロバイダーを介してアクセスを制限できます。変更/アップグレード期間の前に、カスタムスクリプトを実行して、ログインしているすべてのユーザーをログアウトすることもできます。また、ローカル管理者アカウントを作成すると、管理者ユーザーのみがインスタンスのローカルアカウントでインスタンスにアクセスでき、SAML/SSO ログインをスキップできます。 12.ServiceNow テクニカルサポートはアップグレードを監視できますか？ アップグレードは自動化されたプロセスであり、一度開始すると FastTrack アップグレードを行うオプションはありません。 アップグレード中に機能上/運用上の問題が発生した場合は、アップグレードが完了するまで待つ必要があります。アップグレード中には、コース中に新しいフィールド/機能が追加および削除される多くの流動的な部分があるため、アップグレード中に発生したほとんどの問題は、アップグレード後に修正されます。 バックエンドの localhost ノードログからのアップグレードの監視は、バックエンドで 1 秒あたり最大 150 行が作成されるため、非現実的なアプローチです。 アップグレードを監視する最適な方法は、[アップグレードモニター] ウィンドウを使用することです。前述の理由から、カスタマーサポートもこのウィンドウを使用してアップグレードを監視します。 詳細については、「アップグレードモニターの概要」を参照してください。 アップグレード モニターは、残りのプラグインの数、アップグレード対象の推定値、および実行時のプラグインごとの残りのレコードの推定値を示します。 「sys_update」は、アップグレード中に各アクティビティの期間が格納される非常に重要なテーブルです。したがって、更新/アップグレードがスタックしていると思われる場合は、準本番ドライランでこのテーブルを検索し (本番の完全クローンの場合のみ)、概算の見積もりを取得して本番アップグレードと比較できます。 特定のケースでは、テクニカルサポートは、以前に発生したアクティブな問題についてアップグレードを監視します。これらの問題は、準本番の予行演習中に追跡および修正され、アクティブなケースを介して顧客に通知されます。 上記の理由により、テクニカルサポートがアップグレードを監視するためにプレースホルダーケースを作成することはお勧めしません。当社には機能ごとに異なるモジュールと SME チームが存在します。プレースホルダーケースは個々の問題に対して個別のチームで対処する必要があるため、アップグレード監視には有効ではありません。 アップグレード中またはアップグレード後に問題が発生した場合は、 Now Support ヘルプセンター にアクセスしてサポートを受けることをお勧めします。特定の問題については、当社がサポートいたします。 インスタンス/インフラストラクチャ固有のリソース制約の問題について、常にプロアクティブな監視を行っています。リソースの制約がある場合は、自動アラートが作成されます。これらの問題については、個別のチケットとしてお客様と協力して修正します。当社の監視ソリューションは、イベントの発生時に反応し、必要に応じて適切なアクションを実行します。これにより、カスタマーサポートの積極的な監視の必要性がなくなります。サポートエンジニアがインスタンスでプロアクティブな監視を実施する場合、数時間ごとに定期的に行われるため、外部要因によってイベントが見落とされたり、十分に迅速に対応できなかったりする可能性がありました。これらの理由から、ServiceNow カスタマーサポートは自動モニタリングシステムを利用しています。詳細については、 ServiceNow Monitoring - 概要とインサイトの詳細を参照してください。 13.ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？ ノードは、ユーザーが DB にアクセスするためのプレースホルダー JVM にすぎません。ノードに関するデータはありません。ノードが停止してもインスタンスに影響はありません。自動モニタリングと、これを自動的に分類するためのルールがあります。 これがソートされるまで、すべてのユーザートラフィックは利用可能なノードに転送されます。 アップグレード中にいずれかのノードで問題/停止/障害が発生している場合は、アップグレードの変更が自動的にクローズされるまでお待ちください。これには、アップグレードサマリーレポートが生成されてから最長で 20 〜 30 分かかります。 問題が解決しない場合は、カスタマーサポートに連絡してください。手動でノードをアップグレードするか、新しいバージョンで新しいノードを起動して古いノードを無効にします。 14.アップグレードをロールバック/ダウングレードできますか？ 残念ながら、アップグレードが別のファミリに行われた場合、ロールバックを実行するオプションはありません。ロールバックできるのはパッチアップデートのみです。 カスタマーサポートが Change Management を介して本番環境でロールバックを開始する場合は、準本番環境でテストして、意図した結果セットが得られることを確認する必要があります。 このために、本番環境を準本番環境に復元し、ロールバックを試行して意図した結果セットが得られているかどうかを確認し、顧客の確認を得てから本番環境で実行します。 注意：ロールバックでは、スキーマの削除 (テーブルまたは列、インデックスの削除は問題ありません)、再ペアレンティング/列の昇格、テーブルの切り捨て、テーブル/列の名前変更、列タイプの変更、または列幅の減少は記録されません。 これらはロールバックから除外され (除外リスト)、構成できません。 ServiceNow では、アップグレード/偶発的なアップグレード後に予期しない壊滅的な問題が発生した場合に備えて、 前方修正を推奨しています。 前方修正：- 重大な問題の個々のケースを作成して、それぞれの SME チームが優先度でこれに取り組むことができるようにします。これらのケースについては、アップグレード変更の詳細について言及してください。 この KB はデータ損失のコンテキストからのものですが、このシナリオでもスコープは類似しており、前方修正をお勧めします。前方修正とバックアップからの復元 データ復旧オプションの詳細について アップグレード後にデータが破損した場合、データを復旧するために何ができますか？のセクションも参照する必要があるかもしれません。 上記の詳細については、次のドキュメントを参照してください： ロールバックと削除の復旧 ロールバックでは、ロールバック前のバージョンに設定された値を持つプロパティ「glide.war.no_upgrade」が作成されます。このプロパティが存在する場合、インスタンスはそのバージョンにアップグレードされません。 Londonから、インスタンス管理者はこれをトリガーできます：パッチのアップグレードまたはプラグインのアクティベーションのロールバック アップグレードのロールバックメカニズム インスタンスのダウングレードは、どのインスタンスでもオプションではありません。インスタンスが準本番インスタンスの場合は、バージョンの低い本番/インスタンスからクローン/復元することができます。これにより、クローン/復元後の自動化でターゲットインスタンスがソースインスタンスの同じバージョンと一致するようになります。 非本番/準本番インスタンスでのデータ損失または破損 KB では、復元の開始に使用できるさまざまなシナリオとセルフサービスオートマトンについて説明します。この前に開発作業を保存してください。 15.更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。 次の記事は、本番環境でのアップグレード後に再利用できる、準本番インスタンスのスキップされたレコードのレビューをキャプチャする手順について説明します： 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法 更新セットは、インスタンスのアップグレードログから処分、解決、コメントなどをキャプチャしません。 新しいインスタンスで更新セットをコミットしたら、ハウスキーピングの目的で、これらのログエントリ (必須列) をインポートセットを使用して転送する必要があります。 Paris から、これが変更されており、これを実現するための KB を参照してください。スキップされた更新レコードの解決追跡 - Paris バージョンのアップグレード関連の変更 Tokyo+ からはこれが変更され、さらに多くの機能が追加され、アップグレード後の多くのアクティビティを自動化できる KB を参照してください。 アップグレード計画モジュールの FAQ (Tokyo+) 16.スキップされたレコード数が準本番インスタンスと異なるのはなぜですか？ 比較できるのは同一条件の場合のみです。インスタンスが同期していない場合、レコードの数はインスタンス間で異なります。 この問題は、本番環境と準本番環境でカウントが異なる場合に発生します。これは、準本番環境が本番環境の完全クローンではない場合に発生します (ログ/監査が除外されている可能性があります)。「 アップグレードを予行演習する最善のプロセスはどれですか？」を参照してください。 KB0955553：Skipped Update Records Resolution Tracking - Paris Versionを参照してください。 17」を参照してください。アップグレードサマリーレコードとアップグレード履歴レコードの間でスキップされた更新の数が異なるのはなぜですか？ 詳細については、次の記事を参照してください：スキップされた更新の数が "アップグレードモニターでのアップグレードサマリーレポート" と "アップグレード履歴でのスキップされた更新ウィジェット" と "sys_upgrade_history_log からのグループごとの処分" テーブル間で不一致 アップグレード中にレコードに何が発生したかの統合リストを取得するのに最適な場所は、テーブル sys_upgrade_history_log および「処分」別のグループです 18.アップグレードの進行中にキャンセルすることはできますか？ インスタンスでトリガーされたアップグレードを正常にキャンセルすることはできません。アップグレードサイクルを実行し、ServiceNow サポートチケットを介してアップグレード後の問題に対処する必要があります。 利用可能なオプションについては、 Now Support ヘルプセンター にアクセスすることをお勧めします。 19.スキップされた更新レコードを確認し、その解決を追跡するにはどうすればよいですか？ (Paris 以降の機能) KB0955553: 更新レコード解決追跡のスキップ - Paris バージョンのアップグレード関連の変更を参照してください。 20.P+ インスタンスで予定されているアップグレードを通知する方法 自分のインスタンスで予定されているアップグレードを通知する方法 21.カスタマイズされたレコードを OOB に戻し、アップグレード可能性のための更新セットを介して転送 この KB を確認してください。 カスタマイズされたレコードを OOB に戻し、アップグレード可能性のための更新セットを介して転送 22.アップグレード中に、適用されたワークアラウンドが固定 OOB レコードで上書きされるようにする方法 この KBを確認してください。 固定 OOB レコードで上書きされるようにする方法 23.古いアップグレードのアップグレードサマリーレポートを表示できますか？ はい、できます。[アップグレードモニター] モジュールをクリックすると、常に最新のアップグレードに移動しますが、古いアップグレードのサマリーレポートを表示する場合は、アップグレード履歴モジュールを開き、アップグレードレコードを開き、フォームは [関連リンク] [アップグレードサマリーレポートの表示 (View Upgrade Summary Report)] になります。 これにより、そのアップグレードのサマリーレポートが開きます。 Release or Environment要求 準本番インスタンスを正確なレプリカにできるように、本番インスタンスバックアップの準本番インスタンスへの復元 を要求します。