インスタンスのアップグレードに関する FAQ - よくある質問Issue この記事では、インスタンスのアップグレードに関するよくある質問への回答と、関連する一般的な問題の緩和について説明します。 この情報は、初期設定のインスタンスに適用されます。インスタンスに存在するカスタマイズはリストされた動作に影響を与える可能性があるため、各セクションの下のリンクを確認して、ほとんどの情報にアクセスしてください。 セルフホスト/オンプレミスのお客様は、この KB も参照してください KB0598275 - セルフホストのお客様のアップグレードのベストプラクティス 1.ServiceNow サポートでアップグレードの変更をスケジュール/変更/キャンセルする方法を教えてください。2.パッチ適用プログラムとサポート終了アップグレードプログラム KB3.アップグレードに関して従うべきベストプラクティスは何ですか？4.ServiceNow サポートの変更でアップグレードが開始されず、開始予定時刻を過ぎたのはなぜですか?5.アップグレードを予行演習する最善のプロセスは何ですか？6.アップグレードの実行時間はどれくらいですか？7.アップグレード中、インスタンスで何が発生しますか？8.アップグレード前にアドホックバックアップを行うことはできますか？9.アップグレード後にデータが破損した場合、データを復旧するために何ができますか？10.アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？11.アップグレード中はどのようにユーザーを制限しますか？12.ServiceNow テクニカルサポートはアップグレードを監視できますか?13.ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？14.アップグレードをロールバック/ダウングレードできますか?15. 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。16.スキップされたレコード数が準本番インスタンスと異なるのはなぜですか？17. アップグレードサマリーレコードとアップグレード履歴レコードの間でスキップされた更新の数が異なるのはなぜですか？18. アップグレードの進行中にキャンセルすることはできますか？19.スキップされた更新レコードを確認してその解決を追跡するにはどうすればよいですか?(新機能パリ&アフター機能)20.P+インスタンスで予定されているアップグレードを通知する方法21.カスタマイズされたレコードを OOB に戻し、アップグレード可能性のための更新セットを介して転送する22.アップグレード中に、適用されたワークアラウンドが固定された OOB レコードで上書きされるようにする方法23.以前のアップグレードのアップグレードサマリーレポートを表示できますか? 1.ServiceNow サポートを使用してインスタンスのアップグレードをどのようにスケジュール/変更/キャンセルしますか? KB0541128 - インスタンスのアップグレードを管理およびスケジュールする方法を参照してください。 インスタンスアップグレードのタイムスロットがありません。 2.パッチ適用プログラムとサポート終了アップグレードプログラム KB KB0696901: ServiceNow パッチ適用プログラムに関する FAQKB0610454: 提供終了 別名 サポートされていないリリースファミリー アップグレード FAQKB0828060: インスタンスステータス「サポート終了間近」についてKB0598977: サポートされていないリリースの定義 3。アップグレードに関して従うべきベストプラクティスは何ですか？ ドキュメントのこの章では、アプリケーションのアップグレードのベストプラクティスについて説明します。 インスタンスのアップグレード。 YouTubeチャンネルのこのビデオにも興味があるかもしれません。新しいリリースへのアップグレード 4.ServiceNow サポートの変更でアップグレードが開始されず、開始予定時刻を過ぎたのはなぜですか? ServiceNow サポートの変更の開始予定により、ServiceNow インスタンスレコードでインスタンスに割り当てられた WAR バージョンをいつ変更する必要があるかが決まります。 アップグレードは、1 時間間隔 (OOB) で実行されたインスタンスの「可能なアップグレードの配布に関するアップグレード/チェック」ジョブによってトリガーされます。このジョブは、割り当てられた WAR バージョンについて、ServiceNow インスタンスレコードを 1 時間ごとにチェックします。割り当てられた新しい WAR バージョンを検出すると、新しい WAR バージョンをダウンロードします。 注意: ServiceNow サポート変更の開始予定時刻からインスタンスでトリガーされるまでに、インスタンスのアップグレードには最大 1 時間かかる場合があります。 実際の作業開始時間は、インスタンスで実際のアップグレードがトリガーされると、ServiceNow サポートの変更で更新されます。 インスタンスの下記の URL にアクセスすることで、アップグレードジョブを確認できます。 (Paris より前)：/sys_trigger_list.do?sysparm_query=name%3Dupgrade (Paris 以降)：/sys_trigger_list.do?sysparm_query=nameLIKEpossible%20upgrade&sysparm_view= Paris 以降 「アップグレード」ジョブは「可能なアップグレードの配布のチェック」に置き換えられました。 「アップグレードスクリプトのチェック」ジョブは「可能なアップグレードのデータベースのチェック」に置き換えられました。 「可能なアップグレードのためのアップグレード/配布の確認」ジョブで、システム ID の値が空であることを確認してください。値がある場合は、「--None--」が選択されていることを確認してください。 システム ID のハードコーディングは推奨されるアプローチではなく、選択したノードが (AHA の場合はセカンダリ DC から) ファーノードである可能性があり、アップグレードが長時間実行される可能性があります。 アップグレードジョブによって WAR ファイルがダウンロードされ、このジョブがトリガーされたノードがアップグレードされます。その後、このノードが再起動され、2 番目のジョブ「アップグレードスクリプトのチェック/可能なアップグレードのデータベースのチェック」がシステム起動時にトリガーされ、アップグレードが継続されます。これらのジョブはどちらもワーカースレッドで実行されます。 ServiceNow サポート変更の「予定開始時間」を過ぎた後に「可能なアップグレード/可能なアップグレードの配布の確認」ジョブの次のアクション時間を変更することは、問題が発生する可能性があるため、推奨されるアプローチではありません。 変更の「予定開始時間」は、このジョブの実行時間の約 10 ～ 15 分前に計画してください。または、変更の「予定開始時間」の 2 〜 3 時間前に [次のアクション時間 (分)] を調整して、変更の開始の代わりに数サイクル正常に実行することもできます。 5.アップグレードを予行演習する最善のプロセスは何ですか？ 製品アップグレードのETA/動作を取得することは非常に重要です。 正しいタイムライン/動作を記録するには、次の 2 つのオプションがあります。 (デフォルトは [除外])、[添付ファイル]、[監査とログ]、および [除外リストに指定されたテーブルを除外] を含む (除外リストで指定されたテーブルを除外) 本番から SUBPROD への完全クローンを開始してから、SUB 本番インスタンスをアップグレードします。上記のテーブルはインスタンスで最も大きな部類のテーブルであり、このテーブルへのインデックス作成やスキーマ変更には合計アップグレード時間のかなりの部分を要するため、これらのテーブルを含めることは非常に重要です。除外された場合、その時間を予定されたアップグレードアクティビティに含めることはできません。London 以降、クローン作成中に、タスクテーブルのデータ量を選択できます (デフォルトは 90 日)。正しいタイムラインを分析するにはフルタスクテーブルが必要であるため、必ず [フル (Full)] を選択してください。SUB PROD インスタンスが正確なレプリカになるように、SUB PROD インスタンスへのバックアップの復元 を要求します。準本番環境をアップグレードできます。これにより、アップグレード実行時間の正確な ETA がわかります。 アップグレードの予行演習を複数回実行する必要があります。SUB PRODでアップグレードの適切なテストを行うと、PRODのアップグレードは正常に行われ、予期しない問題を調査するためのサポートを利用できます。利用可能なオプションについては、 Now Support ヘルプセンター にアクセスすることをお勧めします。 6.アップグレードの実行時間はどれくらいですか？ これはより広範な質問であり、これに対する ETA を提供することはできません。組織固有のカスタマイズによってどのインスタンスも異なり、アップグレード時間はインスタンスのデータ/カスタマイズの範囲に応じて異なります。予行演習はこの情報を取得できる唯一の方法です。 7.アップグレード中、インスタンスで何が発生しますか？ アップグレード中でもユーザーはインスタンスにログオンし、通常通り作業できます。影響は最小限に抑えられ、ユーザーが接続しているノードがアップグレードされると、ユーザー接続が 1 回リセットされます。 レコード作成および作成されたレコードはアップグレードによる影響を受けません。アップグレードで変更されるのはスクリプトとスキーマだけです。 1 つのノードがノードをアップグレードし、スキーマ/DB のアップグレードをトリガーすることでプロセス全体を実行します。並行して、他のノードでアップグレードを実行し、アップグレード後にノードが再起動され、接続がリセットされます。 したがって、ノードが再起動されると、ノードは新しいバージョンになり、データベースのアップグレードが完了するまでDBは新しいバージョンになりません。レコード作成が中断されることはありませんが、アップグレード中はユーザーを制限することをお勧めします。そうすることで、システムは利用可能なすべてのリソースをアップグレードアクティビティに使用することができます。 8.アップグレード前にアドホックバックアップを行うことはできますか？ 残念ながら、アドホックバックアップを実行するオプションはありません。プライマリ DB とセカンダリ DB (利用可能な場合) 用に別々にバックアップを取ります。 バックアップサイクルは、毎週の完全バックアップと毎日の差分バックアップで構成され、14〜28日(保持ポリシーに基づく)のバックアップを提供します。バックアップはすべてディスクに書き込まれます。テープは使用されず、バックアップが外部に送信されることはありません。お客様のライブデータに適用されるコントロールはすべて、バックアップにも適用されます。ライブデータベースでデータが暗号化されている場合、バックアップでも暗号化されます。 詳細については、記事「 本番環境を含む ServiceNow インスタンスのバックアップ要求」を参照してください 。 バックアップと保持の詳細については、ホワイトペーパー「 Delivering Performance and Scalability and Availability on the ServiceNow Cloud (ServiceNow クラウドでのパフォーマンス、拡張性、可用性の実現))」で説明しています。 データのバックアップとリカバリ 9.アップグレード後にデータが破損した場合、データを復旧するために何ができますか？ お客様のデータは ServiceNow が保護します。PROD でデータ破損が発生する可能性が最も低いシナリオでは、PROD インスタンスを TEMP インスタンスにポイントインタイムリストアして、PROD インスタンス上のデータを TEMP インスタンス上のデータ比較のためにその特定の時間 (特定の分) に戻すことができます。 ポイントインタイム復元は、インスタンスを利用可能な最後のバックアップまで復元し、指定された残りのデータを bin ログ/トランザクションログから再作成することで実行されます。このプロセスは、最後のバックアップ以降にインスタンスで実行された INSERT/DELETE/UPDATE の量によっては、長い時間を要する可能性があります。bin ログの自動保持期間は、本記事の執筆時点では 4 日間です。 PIT 復元は複数のチームを巻き込む手作業のプロセスであり、危機的な状況に陥ったときに開始されます。フェイルオーバー/リカバリ/切り戻し/ロールバック方法として扱うことはできません。 注: 本番環境では PIT リストアを直接行わず、フォワードでのみ修正します。PIT リストアは、TEMP/SUBPROD インスタンスでのデータ比較とデータリカバリにのみ使用されます。 TEMP インスタンスにデータを取得したら、これを使用して POST アップグレード バージョンと PRE アップグレード バージョン間のデータを比較し、データ復旧計画で作業できます。変更管理プロセスを介して個々のケースに基づいてデータを分析および復旧するためのSOPを定義しているため、障害を解決できます。 前方修正とバックアップからの復元 非本番/準本番インスタンスでのデータの損失または破損 KB では、復元を開始するために使用できるさまざまなシナリオとセルフサービスの自動化について説明します。この前に、開発作業を必ず保存してください。 10.アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？ 更新セットのプレビュー/コミットおよびプラグイン/アプリのインストールは、アップグレード中は利用できません。「Info MessageUpdate set preview and commit are unavailable because the system is currently upgrading. (情報メッセージ更新セットのプレビューとコミットは、現在システムをアップグレードしているため、利用できません。アップグレードモニターについては、ここをクリックしてください」。 これは、アップグレードの完了 (変更のクローズ) 後に再開されます 影響の詳細については、次の記事を参照してください。 KB0622951 - データベースのアップグレード中に影響を受ける機能 アップグレード中にいずれかの統合が機能しない場合、そのジョブが「アップグレードセーフ」としてリストされていない可能性が高くなります。 後遺症についてコメントできないため、アップグレード中に変更しないことをお勧めします。 カスタムスケジュール済みジョブを「アップグレードセーフ」に設定しないでください。このフィールドはアップグレードの妨げにならないように理由があります。 11.アップグレード中はどのようにユーザーを制限しますか？ アップグレード中にユーザーを制限するための OOB オプションはありません。 ユーザーを制限するためのいくつかのワークアラウンドとカスタマイズ方法があります。開発者/パートナーと一緒に行ってください。カスタマーサポートの範囲外となります。 利用可能ないくつかのオプションを紹介します。 インスタンスにシングルサインオンが実装されている場合は、SSO/SAML のポータル/ID プロバイダー経由でアクセスを制限できます。カスタムスクリプトを実行して、変更/アップグレード期間の前にログインしているすべてのユーザーをログアウトさせることもできます。また、ローカルアドミンアカウントを作成し、アドミンユーザーのみが SAML/SSO ログインをスキップしてインスタンスのローカルアカウントでインスタンスにアクセスできます。 アドミンロールのユーザーのみにインスタンスへのログインを許可します**この記事のすべてのスクリプトは提案にすぎず、お客様は展開する前にこれらのカスタマイズを慎重にテストする必要があります。 12.ServiceNow テクニカルサポートはアップグレードを監視できますか? アップグレードは自動化されたプロセスであり、ひとたび開始されると、アップグレードをファストトラックすることはできません。 アップグレード中に発生する機能/運用面の問題については、アップグレードが完了するまで待つ必要があります。アップグレード中に発生したほとんどの問題は、アップグレード後に修正されます。アップグレード中には、コース中に新しいフィールドや機能が追加および削除される不確定要素が多数あるためです。 毎秒最大 150 行がバックエンドで作成されるため、バックエンドの localhost ノードログからアップグレードを監視することは現実的な方法ではありません。 アップグレードを監視する最善の方法は、アップグレード モニターウィンドウを使用することです。前述の理由から、カスタマーサポートもこのウィンドウを使用してアップグレードを監視します。詳細については、アップグレードモニターの概要 を参照してください。 アップグレードモニターには、実行時の残りのプラグイン数、アップグレード内容に関する推定、プラグインごとの残っているレコードの推定が示されます。 「sys_update」は、アップグレード中に各アクティビティの期間が格納される非常に重要なテーブルです。したがって、更新/アップグレードがスタックしていると思われる場合は、SUB PROD DRY RUN (PROD のフル クローンの場合のみ) でこのテーブルを探して、PROD アップグレードと比較するための大まかな見積もりを取得できます。 特定のケースでは、テクニカルサポートは、SUB 本番リハーサル中に追跡および修正された、以前に報告されたアクティブな問題のアップグレードを監視し、アクティブなケースを介して顧客に伝達されます。 上記の理由で、テクニカルサポートがアップグレードを監視するためのプレースホルダーケースを作成することはお勧めしません。当社には機能ごとに異なるモジュールと SME チームが存在します。プレースホルダーケースは個々の問題に対して個別のチームで対処する必要があるため、アップグレード監視には有効ではありません。 アップグレード中/アップグレード後に問題が発生した場合は、 Now Support ヘルプセンター にアクセスしてサポートを受けることをお勧めします。その特定の問題についてサポートいたします。 インスタンス/インフラ固有のリソース制約の問題に対して、常にプロアクティブな監視を実施しています。リソースの制約が発生した場合は、自動アラートが作成され、これを修正するための個別のチケットとして、これらの問題についてお客様と協力します。当社の監視ソリューションは、イベント発生時に反応し、必要に応じて適切な措置を講じるため、カスタマーサポートのプロアクティブな監視が不要になります。サポートエンジニアがインスタンスでプロアクティブな監視を実施する場合、これは数時間ごとに定期的に行われるため、イベントの見逃しや、外部要因による十分な速さでの対応に繋がる可能性があります。これらの理由から、ServiceNow カスタマーサポートでは自動監視システムを利用しています。ServiceNow Monitoring - 概要とインサイト の詳細については、こちらをご覧ください。 13.ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？ ノードは、ユーザーが DB にアクセスするためのプレースホルダー JVM に過ぎません。ノードに関するデータはなく、ノードがダウンしてもインスタンスへの影響はなく、これを自動的に解決するための自動監視とルールが設定されています。 分類されるまで、ユーザートラフィックはすべて利用可能なノードに回されます。 アップグレード中にいずれかのノードで問題/ダウン/障害が発生していることに気づいた場合は、アップグレードの変更が自動クローズされるまでお待ちください。これには、アップグレードサマリーレポートが生成されてから最長で 20 〜 30 分かかります。 問題が解決しない場合は、カスタマーサポートにご連絡ください。当社が手作業でノードをアップグレードするか、新しいバージョンの新しいノードを起動し、古いノードを無効にします。 14.アップグレードをロールバック/ダウングレードできますか? 残念ながら、異なるファミリにアップグレードした場合は、ロールバックを実行できません。ロールバックできるのはパッチアップデートのみです。 カスタマーサポートが変更管理を介して本番のロールバックを開始する場合は、これをサブ本番でテストして、意図した結果セットが得られていることを確認する必要があります。 このために、PROD を SUB PROD に復元し、ロールバックを試して意図した結果セットを取得しているかどうかを確認し、顧客の確認を取得してから、PROD で実行します。 注意: ロールバックでは、スキーマの削除 (テーブルまたは列、インデックスの削除は問題ありません)、再ペアレント化/列の昇格、テーブルの切り捨て、テーブル/列の名前変更、列タイプの変更、または列幅の減少は記録されません。 これらはロールバックから除外され (除外リスト)、構成できません。 ServiceNow では、アップグレード後や偶発的なアップグレード後に予期しない致命的な問題が発生した場合に 前方修正 をお勧めします。 修正の転送:重大な問題に対して個々のケースを作成し、各 SME チームが優先度に基づいて作業できるようにします。これらのケースについては、アップグレードの変更の詳細を記載してください。 この KB はデータ損失コンテキストからのものですが、このシナリオでもスコープは類似しており、 前方修正をお勧めします。前方修正とバックアップからの復元 また、データ回復オプションの詳細については、「アップグレード後にデータが破損した場合、データを復旧するために何ができますか？ 上記の詳細については、ドキュメントを参照してください。 ロールバックと削除の復旧 ロールバックでは、ロールバック前のバージョンに設定されたプロパティ「glide.war.no_upgrade」が作成されます。このプロパティが存在すると、インスタンスがそのバージョンにアップグレードされないようになります。 London 以降、インスタンスアドミニストレーターは以下をトリガーできます。 パッチのアップグレードまたはプラグインのアクティブ化のロールバック アップグレードロールバックメカニズム インスタンスのダウングレードは、どのインスタンスでもオプションではありません。インスタンスが SUB 本番インスタンスの場合は、下位バージョンの本番/インスタンスからクローン/復元できます。これにより、クローン/復元後の自動化で、ターゲットインスタンスが同じバージョンのソースインスタンスと一致するようになります。 非本番/準本番インスタンスでのデータの損失または破損 KB では、復元を開始するために使用できるさまざまなシナリオとセルフサービスの自動化について説明します。この前に、開発作業を必ず保存してください。 15.更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。 次の記事は、PROD でのアップグレード後に再利用できる SUB PROD インスタンスのスキップされたレコードのレビューをキャプチャする手順に役立ちます。 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法 更新セットは、インスタンスのアップグレードログから処分、解決、コメントなどをキャプチャしません。 新しいインスタンスで更新セットをコミットしたら、ハウスキーピングのために、これらのログエントリ (必要な列) を、インポートセットを使用して転送する必要があります。 Paris 以降、これは変更されており、これを実現するには KB を見つけてください。スキップされた更新レコードの解決のトラッキング:Paris バージョンでのアップグレード関連の変更点 Tokyo+から変更され、より多くの機能が追加され、アップグレード後の多くのアクティビティを自動化できるKBを見つけてください アップグレードプランモジュールのFAQ(Tokyo+) 「プランのアップグレード」モジュールは、複数の本番スタックが複数のビルダーインスタンスで同じ apprepo を使用するため、同じ組織にリンクされている組織ではサポートされていません。 16. スキップされたレコード数が SUB PROD インスタンスと異なるのはなぜですか? そのような比較は、同一条件の場合にのみ可能です。インスタンスが同期していない場合、レコードの数はインスタンス間で異なります。 この問題は、本番環境と準本番環境の間でカウントが異なる場合に発生します。これは、SUB PRODがPRODのフルクローンではない場合(ログ/監査が除外された可能性がある)に発生します。「アップグレードを予行演習する最善のプロセスはどれですか？」を参照してください。 KB0955553:スキップされたレコード更新の解決トラッキング:Paris バージョンでのアップグレード関連の変更点をご覧ください。 17. アップグレードサマリーレコードとアップグレード履歴レコードの間でスキップされた更新の数が異なるのはなぜですか？ 詳細については、この記事を参照してください:スキップされた更新の数が "アップグレードモニターでのアップグレードサマリーレポート" と "アップグレード履歴でのスキップされた更新ウィジェット" と "sys_upgrade_history_log からのグループごとの処分" テーブル間で不一致 アップグレード中に何が起こったかをまとめたリストを取得するのに最適な場所は、テーブルsys_upgrade_history_logと「処分」によるグループ化です 18. アップグレードの進行中にキャンセルすることはできますか？ インスタンスでトリガーされたアップグレードを正常にキャンセルすることはできません。アップグレードサイクルで実行し、アップグレード後の問題は ServiceNow サポートチケットを介して対処する必要があります。 利用可能なオプションについては、 Now Support ヘルプセンター にアクセスすることをお勧めします。 19.スキップされた更新レコードを確認してその解決を追跡するにはどうすればよいですか?(新機能パリ&アフター機能) KB0955553:スキップされたレコード更新の解決トラッキング:Paris バージョンでのアップグレード関連の変更点をご覧ください 。 20.P+インスタンスで予定されているアップグレードを通知する方法 自分のインスタンスで予定されているアップグレードを通知する方法。 21.カスタマイズされたレコードを OOB に戻し、アップグレード可能性のための更新セットを介して転送する この KB を確認してください カスタマイズされたレコードを OOB に戻し、アップグレード性のための更新セットを介して転送 22.アップグレード中に、適用されたワークアラウンドが固定された OOB レコードで上書きされるようにする方法 この KB を確認してください。アップグレード中に、適用されたワークアラウンドが固定 OOB レコードで上書きされるようにする方法 23.以前のアップグレードのアップグレードサマリーレポートを表示できますか? はい、できます。アップグレードモニターモジュールをクリックすると、常に最新のアップグレードに移動します。ただし、以前のアップグレードのサマリーレポートを表示するには、アップグレード履歴モジュールを開いてアップグレードレコードを開くと、フォームに関連リンクが表示されます。 アップグレードサマリーレポートを表示します。 これにより、指定したアップグレードのサマリーレポートが開きます。