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