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