インスタンスのアップグレードに関する 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 Patching Program FAQsKB0610454 - End of Life aka Unsupported Release Family Upgrades FAQ 3.アップグレードに関して従うべきベストプラクティスは何ですか？ 弊社のドキュメント、インスタンスのアップグレードの章では、アプリケーションのアップグレードに従うべきベストプラクティスについて説明しています。 YouTube チャンネルのこちらの動画もご覧ください 新しいリリースへのアップグレード 4.アップグレードが開始されなかった理由と、ServiceNow サポートの変更で予定開始時刻を過ぎてしまったのはなぜですか? ServiceNow サポート変更の開始予定日によって、インスタンスの割り当てられた WAR バージョンを ServiceNow インスタンスレコードでいつ変更する必要があるかが決まります。 アップグレードは、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 以降 「アップグレード」ジョブは「可能なアップグレードの配布のチェック」に置き換えられました。 「アップグレードスクリプトのチェック」ジョブは「可能なアップグレードのデータベースのチェック」に置き換えられました。 [アップグレード/可能なアップグレードの配布を確認 (Upgrade/Check distribution for possible upgrade)] ジョブの Sys ID の値が空であることを確認してください。値がある場合は、「--None--」が選択されていることを確認してください。 システム ID のハードコーディングは推奨されるアプローチではなく、選択されたノードが (AHA の場合はセカンダリ DC から) 遠いノードである可能性があり、アップグレードが長時間実行される可能性があります。 アップグレードジョブによって WAR ファイルがダウンロードされ、このジョブがトリガーされたノードがアップグレードされます。その後、このノードが再起動され、2 番目のジョブ「アップグレードスクリプトのチェック/可能なアップグレードのデータベースのチェック」がシステム起動時にトリガーされ、アップグレードが継続されます。これらのジョブはどちらもワーカースレッドで実行されます。 ServiceNow サポート変更の「予定開始時間」を過ぎた後に「アップグレード/可能なアップグレードの配布を確認」ジョブの次のアクション時間を変更することは、問題が発生する可能性があるため、推奨されるアプローチではありません。 変更の「予定開始時間」は、このジョブの実行時間の約 10 ～ 15 分前に計画してください。または、変更の「予定開始時間」の 2 〜 3 時間前に次のアクション時間 (分) を調整して、変更の開始の代わりになり、数サイクルを正常に実行できるようにすることもできます。 5.アップグレードを予行演習する最善のプロセスは何ですか？ 本番アップグレードの ETA/動作を取得することは非常に重要です。 正しいタイムライン/動作を記録するには、次の 2 つのオプションがあります。 「添付ファイル」、「監査とログ」、および「除外リストに指定されたテーブルを除外」(除外のすべてのチェックボックスをオフにして含める) を含む本番 (デフォルトは EXCLUDE) を含む SUBPROD へのフルクローンを開始してから、SUB PROD インスタンスをアップグレードします。上記のテーブルはインスタンスで最も大きな部類のテーブルであり、このテーブルへのインデックス作成やスキーマ変更には合計アップグレード時間のかなりの部分を要するため、これらのテーブルを含めることは非常に重要です。除外された場合、その時間を予定されたアップグレードアクティビティに含めることはできません。London 以降、クローン作成中に、タスクテーブルのデータ量を選択するオプションがあります (デフォルトは 90 日)。正しいタイムラインを分析するにはフルタスクテーブルが必要であるため、必ず [フル (Full)] を選択してください。SUB PRODインスタンスを正確なレプリカにできるように、SUB PROD インスタンスへの本番インスタンスバックアップのリストアを要求します。SUB PRODインスタンスをアップグレードできます。これにより、アップグレード実行時間の正確な ETA がわかります。 アップグレードの予行演習を複数回実行する必要があります。SUB PROD でアップグレードの適切なテストを行うと、PROD でのアップグレードは正常に行われ、予期しない問題を調べるためのサポートを利用できます。利用可能なオプションについては、 Now Support ヘルプセンター で確認することをお勧めします。 6.アップグレードの実行時間はどれくらいですか？ これはより広範な質問であり、これに対する ETA を提供することはできません。組織固有のカスタマイズによってどのインスタンスも異なり、アップグレード時間はインスタンスのデータ/カスタマイズの範囲に応じて異なります。予行演習はこの情報を取得できる唯一の方法です。 7.アップグレード中、インスタンスで何が発生しますか？ アップグレード中でもユーザーはインスタンスにログオンし、通常通り作業できます。影響は最小限で、ユーザーが接続しているノードがアップグレードされるときにユーザー接続が 1 回リセットされます。 レコード作成および作成されたレコードはアップグレードによる影響を受けません。アップグレードで変更されるのはスクリプトとスキーマだけです。 1 つのノードがノードをアップグレードし、スキーマ/DB のアップグレードをトリガーすることで、プロセス全体を実行します。これと並行して、その他のノードでアップグレードが実行されます。アップグレード後にノードが再起動され、接続がリセットされます。 したがって、ノードが再起動されると、ノードは新しいバージョンになり、データベースのアップグレードが完了するまでDBは新しいバージョンにはなりません。レコード作成が中断されることはありませんが、アップグレード中はユーザーを制限することをお勧めします。そうすることで、システムは利用可能なすべてのリソースをアップグレードアクティビティに使用することができます。 8.アップグレード前にアドホックバックアップを行うことはできますか？ 残念ながら、アドホックバックアップを実行するオプションはありません。プライマリ DB とセカンダリ DB (利用可能な場合) 用に別々にバックアップを取ります。 バックアップ サイクルは、毎週の完全バックアップと毎日の差分バックアップで構成され、14 日から 28 日 (保持ポリシーに基づく) のバックアップを提供します。バックアップはすべてディスクに書き込まれます。テープは使用されず、バックアップが外部に送信されることはありません。お客様のライブデータに適用されるコントロールはすべて、バックアップにも適用されます。ライブデータベースでデータが暗号化されている場合、バックアップでも暗号化されます。 詳細については、「 本番環境を含む ServiceNow インスタンスのバックアップ要求」の記事を参照してください。 バックアップと保持の詳細については、次のホワイトペーパーを参照してください。 ServiceNow クラウドでのパフォーマンス、拡張性、可用性の提供 データのバックアップと復元 9.アップグレード後にデータが破損した場合、データを復旧するために何ができますか？ お客様のデータは ServiceNow が保護します。本番でデータが破損する可能性は極めて低いですが、本番インスタンスから TEMP インスタンスへの特定の時点の復元を実行するオプションがあります。これにより、本番インスタンスのデータを、TEMP インスタンスでのデータ比較のためにその特定の時刻 (特定の分) に戻すことができます。 ポイントインタイム復元は、インスタンスを利用可能な最後のバックアップまで復元し、指定された残りのデータを bin ログ/トランザクションログから再作成することで実行されます。このプロセスは、最後のバックアップ以降にインスタンスで実行された INSERT/DELETE/UPDATE の量によっては、長い時間を要する可能性があります。bin ログの自動保持期間は、本記事の執筆時点では 4 日間です。 PIT 復元は複数のチームを巻き込む手作業のプロセスであり、危機的な状況に陥ったときに開始されます。フェイルオーバー/リカバリ/切り戻し/ロールバック方法として扱うことはできません。 注意：本番環境で直接 PIT 復元を行うことはありません。前方修正のみを行い、PIT 復元は一時/準本番インスタンスでのデータ比較とデータ復旧にのみ使用されます。 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 のフルクローンの場合のみ) でこのテーブルを検索して、本番アップグレードと比較する大まかな見積もりを取得できます。 特定のケースでは、テクニカルサポートは、以前に提起され、SUB PRODの予行演習中に追跡および修正されたアクティブな問題のアップグレードを監視し、アクティブなケースを介して顧客に伝達されます。 上記の理由により、アップグレードを監視するためにテクニカルサポートのプレースホルダーケースを作成することはお勧めしません。当社には機能ごとに異なるモジュールと SME チームが存在します。プレースホルダーケースは個々の問題に対して個別のチームで対処する必要があるため、アップグレード監視には有効ではありません。 アップグレード中またはアップグレード後に問題が発生した場合は、 Now Support ヘルプセンター にアクセスしてサポートを受けることをお勧めします。弊社がその特定の問題についてサポートいたします。 インスタンスやインフラ固有のリソース制約の問題を常にプロアクティブに監視しています。リソースの制約がある場合は、自動アラートが作成され、これを修正するための個別のチケットとしてお客様と協力してこれらの問題に取り組みます。当社の監視ソリューションはイベント発生時に対応し、必要に応じて適切な措置を講じるため、カスタマーサポートの積極的な監視は不要になります。サポートエンジニアがインスタンスでプロアクティブな監視を実施する場合、これは数時間ごとに定期的に行われ、イベントを見逃したり、外的要因によって十分な速さで対応できなかったりする可能性があります。このような理由から、ServiceNow カスタマーサポートは自動監視システムを利用しています。詳細については、 ServiceNow Monitoring - Overview and Insight を参照してください。 13.ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？ ノードは、ユーザーが DB にアクセスするためのプレースホルダー JVM に過ぎません。ノードにデータはありません。ノードがダウンしてもインスタンスへの影響はなく、自動監視とルールにより、これを自動的に解決できます。 分類されるまで、ユーザートラフィックはすべて利用可能なノードに回されます。 アップグレード中にいずれかのノードで問題/ダウン/障害が発生していることに気づいた場合は、アップグレードの変更が自動クローズされるまでお待ちください。これには、アップグレードサマリーレポートが生成されてから最長で 20 〜 30 分かかります。 問題が解決しない場合は、カスタマーサポートにご連絡ください。当社が手作業でノードをアップグレードするか、新しいバージョンの新しいノードを起動し、古いノードを無効にします。 14.アップグレードをロールバック/ダウングレードできますか? 残念ながら、異なるファミリにアップグレードした場合は、ロールバックを実行できません。ロールバックできるのはパッチアップデートのみです。 カスタマーサポートが Change Management を介して本番環境でロールバックを開始している場合は、これを SUB PROD でテストして、意図した結果セットが得られることを確認する必要があります。 このために、本番をサブ本番に復元し、ロールバックを試して、意図した結果セットが得られているかどうかを確認し、顧客の確認を得てから、本番で実行します。 注意：ロールバックでは、スキーマの drop (テーブルまたは列、インデックスの drop は OK)、reparent / 列の promotion、テーブルの truncate、テーブル / 列の rename、列タイプの変更、列幅の減少は記録されません。 これらはロールバックから除外され (除外リスト)、構成できません。 ServiceNow では、アップグレードや誤ってアップグレードした後に予期しない致命的な問題が発生した場合に備えて 前方修正 (Fix Forward) を推奨しています。 前方修正(Fix Forward):重大な問題について個々のケースを作成し、それぞれの SME チームが優先的に作業できるようにします。これらのケースのアップグレード変更の詳細を記載してください。 この KB バックアップからの転送と復元の修正 ではデータ損失コンテキストからのものですが、スコープはこのシナリオでも同様であり、 先を見越した修正 することをお勧めします。 また、データ回復オプションの詳細については、「アップグレード後にデータが破損した場合、データを復旧するために何ができますか？のセクションも参照する必要があります。 上記の詳細については、ドキュメント「ロールバックと削除の回復」を参照してください。 ロールバックでは、ロールバック前のバージョンに設定された値を持つプロパティ「glide.war.no_upgrade」が作成されます。このプロパティが存在すると、インスタンスがそのバージョンにアップグレードされなくなります。 London から、インスタンスアドミニストレーターはこちらをトリガーできます。 パッチのアップグレードまたはプラグインのアクティブ化をロールバック アップグレードロールバックメカニズム インスタンスのダウングレードは、どのインスタンスでもオプションではありません。インスタンスがサブ本番インスタンスの場合は、以前のバージョンの本番/インスタンスからクローン作成/復元することができ、これによりクローン/復元後の自動化により、ターゲットインスタンスがソースインスタンスの同じバージョンと一致するようになります。 非本番/準本番インスタンスでのデータ損失または破損 KB では、復元を開始するために使用できるさまざまなシナリオとセルフサービスの自動化について説明します。その前に開発作業を保存してください。 15.更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。 次の記事では、本番インスタンスのスキップされたレコードのレビューをキャプチャし、本番環境でのアップグレード後に再利用できるようにする手順について説明します。 更新セットを使用して、アップグレード後に元に戻されたカスタマイズを取得する方法 更新セットは、インスタンスのアップグレードログから処分、解決、コメントなどを取得しません。 新しいインスタンスで更新セットをコミットしたら、ハウスキーピングのために、これらのログエントリ (必要な列) を、インポートセットを使用して転送する必要があります。 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 と [Group by "Disposition" (「処分」別にグループ化) です 18. アップグレードの進行中にキャンセルすることはできますか？ インスタンスでトリガーされたアップグレードを正常にキャンセルすることはできません。アップグレードサイクルを通して実行し、アップグレード後の問題があれば ServiceNow サポートチケットで対処する必要があります。 利用可能なオプションについては、 Now Support ヘルプセンター で確認することをお勧めします。 19.スキップされた更新レコードを確認し、その解決を追跡するにはどうすればよいですか?(新しいParisと機能後) こちらの KB を確認してください。Skipped Update Records Resolution Tracking - Upgrade related changes in Paris version 20.インスタンスで予定されているアップグレードを通知する方法 こちらの KB を確認してください。How to notify upcoming upgrade on your own instance. 21.カスタマイズしたレコードを OOB に戻し、アップグレード性のために更新セットを介して転送する方法 こちらの KB を確認してください。Revert customized record to OOB and transfer via Update-set for Upgradeability 22.アップグレード中に適用されたワークアラウンドが修正された OOB レコードで上書きされるようにする方法 こちらの KB を確認してください。How to ensure workarounds applied are overwritten with fixed OOB records during the upgrade 23.古いアップグレードのアップグレードサマリーレポートを表示できますか? はい、できます。アップグレードモニターモジュールをクリックすると、常に最新のアップグレードが表示されます。ただし、古いアップグレードのサマリーレポートを表示する場合は、アップグレード履歴モジュールを開いてアップグレードレコードを開くと、フォームに関連リンク [アップグレードサマリーレポートを表示] が表示されます。 これにより、特定のアップグレードの概要レポートが開きます。