アップグレードに関する FAQ - よく寄せられる質問Description <!-- table.tocTable { border: 1px solid; border-color: #e0e0e0; background-color: #fff; } td { padding:4px; } --> この記事の目的は、アップグレードに関してテクニカルサポートによく寄せられるいくつかの質問に回答することです。これは一般的な情報です。補足質問がある場合は、テクニカルサポート宛てにチケットを作成してください。 インスタンスをカスタマイズすると、それに続く動作に影響を与える可能性があることに注意してください。この記事は、初期設定の機能に適用されます。 目次 1. Now Support では、アップグレードの変更をどのようにスケジュール/変更/キャンセルしますか？10. アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？2. パッチ適用プログラムとサポートが終了しているアップグレードプログラムに関するナレッジベース11. アップグレード中はどのようにユーザーを制限しますか？3. アップグレードに関して従うべきベストプラクティスは何ですか？12. アップグレードが完了するまで ServiceNow テクニカルサポートによって見守ってもらえますか？4. アップグレードが開始されなかったのはなぜですか？また HI 変更の計画開始時間を過ぎたのはなぜですか？13. ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？ 5. アップグレードを予行演習する最善のプロセスは何ですか？14. アップグレードをロールバックできますか？6. アップグレードの実行時間はどれくらいですか？15. 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。7. アップグレード中、インスタンスで何が発生しますか？16. スキップされたレコード数が準本番インスタンスと異なるのはなぜですか？8. アップグレード前にアドホックバックアップを行うことはできますか？17. アップグレードサマリーレコードとアップグレード履歴レコードの間でスキップされた更新の数が異なるのはなぜですか？9. アップグレード後にデータが破損した場合、データを復旧するために何ができますか？18. アップグレードの進行中にキャンセルすることはできますか？ 19. スキップされた更新レコードの確認方法と、その解決のトラッキング方法を教えてください (Pairs 以降の新機能)。 1. Now Support では、アップグレードの変更をどのようにスケジュール/変更/キャンセルしますか？ 「KB0541128 - インスタンスのアップグレードの管理およびスケジュール方法」を参照してください 2. パッチ適用プログラムとサポートが終了しているアップグレードプログラムに関するナレッジベース KB0696901 - ServiceNow パッチ適用プログラムに関する FAQKB0610454 - サポート終了：サポートされていないリリースファミリのアップグレードに関する FAQ 3. アップグレードに関して従うべきベストプラクティスは何ですか？ ドキュメントのインスタンスのアップグレードに関する章では、アプリケーションのアップグレードに関するベストプラクティスが示されています。 当社の YouTube チャンネルにあるビデオ「Upgrading to a New Release」もご覧ください。 4. アップグレードが開始されなかったのはなぜですか？また HI 変更の計画開始時間を過ぎたのはなぜですか？ インスタンスに割り当てられた WAR バージョンを HI インスタンスレコード内で変更する必要があるタイミングは、HI 変更の開始予定によって決まります。 アップグレードは、1 時間間隔で実行される (OOB) インスタンスの「アップグレード/可能なアップグレードの配布のチェック」ジョブによってトリガーされます。このジョブは、HI インスタンスレコードに割り当てられた WAR バージョンがあるかどうかを毎時間チェックします。割り当てられた新しい WAR バージョンを検出すると、新しい WAR バージョンをダウンロードします。 注意：インスタンスのアップグレードでは、HI/サポート変更の計画開始時間からインスタンス上でトリガーするまでに最長 1 時間かかる可能性があります。 実際の作業開始時間は、実際のアップグレードがインスタンス上でトリガーされたときに、HI 変更で更新されます。 インスタンスの下記の 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 番目のジョブ「アップグレードスクリプトのチェック/可能なアップグレードのデータベースのチェック」がシステム起動時にトリガーされ、アップグレードが継続されます。これらのジョブはどちらもワーカースレッドで実行されます。 HI 変更の「予定開始時間」を過ぎた後で「アップグレード/可能なアップグレードの配布のチェック」ジョブの次のアクション時間を変更することは、問題が生じる可能性があるため、お勧めできません。 変更の「予定開始時間」は、このジョブの実行時間の約 10 ～ 15 分前に計画してください。または、変更の「予定開始時間」の約 2 ～ 3 時間前に次のアクション時間 (分) を調整することで、変更を開始せずに、問題なく数サイクルを実行することができます。 5. アップグレードを予行演習する最善のプロセスは何ですか？ 本番環境のアップグレードの ETA/動作を把握しておくことは非常に重要です。 正確なタイムライン/動作を記録するための 2 つのオプションがあります。 「添付ファイル」、「監査とログ」、「除外リストに指定された除外テーブル」を含めて (デフォルトは [除外]) 本番環境から準本番環境への完全クローンを開始し (対象に含まれるように、[除外] のすべてのチェックボックスを外す)、その後、準本番インスタンスをアップグレードします。上記のテーブルはインスタンスで最も大きな部類のテーブルであり、このテーブルへのインデックス作成やスキーマ変更には合計アップグレード時間のかなりの部分を要するため、これらのテーブルを含めることは非常に重要です。除外された場合、その時間を予定されたアップグレードアクティビティに含めることはできません。 London 以降、クローン中にタスクテーブルのデータ量を選択できるようになりました (デフォルトは 90 日間)。正しいタイムラインを分析するにはフルタスクテーブルが必要であるため、必ず [フル (Full)] を選択してください。準本番インスタンスが厳密なレプリカになるように、本番インスタンスのバックアップを準本番インスタンスに復元するように要求します。準本番環境をアップグレードできます。これにより、アップグレード実行時間の正確な ETA がわかります。 アップグレードの予行演習を複数回実行する必要があります。準本番環境で適切にアップグレードをテストした場合、本番環境でのアップグレードも問題なく実行されます。予期しない問題については、24 時間 365 日利用可能なサポートで調査できます。 6. アップグレードの実行時間はどれくらいですか？ これはより広範な質問であり、これに対する ETA を提供することはできません。組織固有のカスタマイズによってどのインスタンスも異なり、アップグレード時間はインスタンスのデータ/カスタマイズの範囲に応じて異なります。予行演習はこの情報を取得できる唯一の方法です。 7. アップグレード中、インスタンスで何が発生しますか？ アップグレード中でもユーザーはインスタンスにログオンし、通常通り作業できます。影響は最小限に抑えられ、ユーザーが接続されているノードがアップグレードされるときにユーザー接続が 1 回リセットされます。 レコード作成および作成されたレコードはアップグレードによる影響を受けません。アップグレードで変更されるのはスクリプトとスキーマだけです。 1 つのノードをアップグレードしてからスキーマ/DB のアップグレードをトリガーすることで、そのノードがプロセス全体を実行するようになります。これと並行して、その他のノードでアップグレードが実行されます。アップグレード後にノードが再起動され、接続がリセットされます。 ノードが再起動されると、ノードは新しいバージョンになりますが、DB はデータベースのアップグレードが完了するまで新しいバージョンになりません。レコード作成が中断されることはありませんが、アップグレード中はユーザーを制限することをお勧めします。そうすることで、システムは利用可能なすべてのリソースをアップグレードアクティビティに使用することができます。 8. アップグレード前にアドホックバックアップを行うことはできますか？ 残念ながら、アドホックバックアップを実行するオプションはありません。プライマリ DB とセカンダリ DB (利用可能な場合) 用に別々にバックアップを取ります。 バックアップサイクルは 4 週間ごとのフルバックアップと、過去 6 日間の日次差分バックアップで構成されており、28 日分のバックアップを提供します。バックアップはすべてディスクに書き込まれます。テープは使用されず、バックアップが外部に送信されることはありません。お客様のライブデータに適用されるコントロールはすべて、バックアップにも適用されます。ライブデータベースでデータが暗号化されている場合、バックアップでも暗号化されます。 詳細情報はこちらを参照してください。 バックアップと保持の詳細情報については、次のホワイトペーパーを参照してください：Servicenow クラウドでのパフォーマンス、拡張性、可用性の実現 9. アップグレード後にデータが破損した場合、データを復旧するために何ができますか？ お客様のデータは ServiceNow が保護します。本番環境では最も起こりにくいと思われるデータ破損のシナリオで、本番インスタンスのポイントインタイム復元を一時インスタンスに対して実行するオプションが用意されています。これにより、本番インスタンスのデータを特定の時間まで戻し、一時インスタンスで (特定の時間 (分) と) データを比較することができます。 ポイントインタイム復元は、インスタンスを利用可能な最後のバックアップまで復元し、指定された残りのデータを bin ログ/トランザクションログから再作成することで実行されます。このプロセスは、最後のバックアップ以降にインスタンスで実行された INSERT/DELETE/UPDATE の量によっては、長い時間を要する可能性があります。bin ログの自動保持期間は、本記事の執筆時点では 4 日間です。 PIT 復元は複数のチームを巻き込む手作業のプロセスであり、危機的な状況に陥ったときに開始されます。フェイルオーバー/リカバリ/切り戻し/ロールバック方法として扱うことはできません。 注意：本番環境で直接 PIT 復元を行うことはありません。前方修正のみを行い、PIT 復元は一時/準本番インスタンスでのデータ比較とデータ復旧にのみ使用されます。 一時インスタンスにデータがあれば、それを使用してアップグレードの前後でデータを比較することができます。また、標準運用手順を使用して、個々のケースに基づいてデータを転送できます。 前方修正とバックアップからの復元 10. アップグレード中にインスタンス/アプリケーションで影響を受ける機能は何ですか？ 影響に関する詳細については、次の記事を参照してください：KB0622951 - Features impacted during the database upgrade アップグレード中にいずれかのデータ連携が機能していない場合は、ジョブが「アップグレードセーフ」としてリストされていない可能性が高いです。 後でどのような影響があるか分からないため、アップグレード中は変更しないことをお勧めします。 「アップグレードセーフ」はアップグレードを妨げないという理由で存在するフィールドであるため、カスタムスケジュール設定されたジョブに対して設定すべきではありません。 11. アップグレード中はどのようにユーザーを制限しますか？ アップグレード中にユーザーを制限するために利用可能な OOB オプションはありません。 ユーザーを制限するためのいくつかのワークアラウンドとカスタマイズ方法があります。開発者/パートナーと一緒に行ってください。カスタマーサポートの範囲外となります。 利用可能ないくつかのオプションを紹介します。 インスタンスに Single Sign-on が実装されている場合、SSO/SAML のポータル/ID プロバイダーを介してアクセスを制限できます。また、カスタムスクリプトを実行して、変更/アップグレード期間の前にすべてのログインユーザーをログアウトさせることもできます。ローカル管理者アカウントを作成することもできます。管理者ユーザーのみがインスタンスのローカルアカウントを使用してインスタンスにアクセスし、SAML/SSO ログインをスキップできます。 12. アップグレードが完了するまで ServiceNow テクニカルサポートによって見守ってもらえますか？ アップグレードは自動化されたプロセスであり、ひとたび開始されると、アップグレードをファストトラックすることはできません。 アップグレード中に発生する機能/運用面の問題については、アップグレードが完了するまで待つ必要があります。アップグレード中には多くの移動パーツが存在し、その過程で新しいフィールド/機能が追加および削除されるため、アップグレード中に発生した問題の多くがアップグレード後に自己修正されることが分かっています。 毎秒最大 150 行がバックエンドで作成されるため、バックエンドの localhost ノードログからアップグレードを監視することは現実的な方法ではありません。 アップグレードを監視する最善の方法は、アップグレード モニターウィンドウを使用することです。前述の理由から、カスタマーサポートもこのウィンドウを使用してアップグレードを監視します。詳細については、 「Upgrade Monitor overview」を参照してください。 アップグレードモニターには、実行時の残りのプラグイン数、アップグレード内容に関する推定、プラグインごとの残っているレコードの推定が示されます。 「sys_update」は、アップグレード中に各アクティビティの期間が格納される非常に重要なテーブルです。更新/アップグレードがスタックしたと思われる場合は、SUB PROD DRY RUN (本番環境の完全クローンであった場合) でこのテーブルを検索し、おおよその推定を取得して、本番環境のアップグレードと比較できます。 特定のケースでは、テクニカルサポートが、過去に発生し、準本番環境の予行演習中に追跡および修正されたアクティブな問題について監視し、検出された場合は、アクティブなケースを介してお客様に通知されます。 上記の理由から、アップグレードを監視するためにプレースホルダーケースをテクニカルサポートに対して作成することはお勧めしません。当社には機能ごとに異なるモジュールと SME チームが存在します。プレースホルダーケースは個々の問題に対して個別のチームで対処する必要があるため、アップグレード監視には有効ではありません。 アップグレード中に何らかの問題が見つかった場合は、24 時間 365 日対応のサポート番号にお電話ください。個別の問題に関してお客様をサポートすることができます。 13. ノードのアップグレードに失敗した場合、つまりアップグレードサマリーでノードが RED (赤) になっている場合、何をすべきですか？ ノードは、ユーザーが DB にアクセスするためのプレースホルダー JVM に過ぎません。ノードにはデータがありません。ノードがダウンしても、インスタンスには影響がありません。また、自動的に分類するための自動監視とルールが存在します。 分類されるまで、ユーザートラフィックはすべて利用可能なノードに回されます。 アップグレード中にいずれかのノードで問題/ダウン/障害が発生していることに気づいた場合は、アップグレードの変更が自動クローズされるまでお待ちください。これには、アップグレードサマリーレポートが生成されてから最長で 20 〜 30 分かかります。 問題が解決しない場合は、カスタマーサポートにご連絡ください。当社が手作業でノードをアップグレードするか、新しいバージョンの新しいノードを起動し、古いノードを無効にします。 14. アップグレードをロールバックできますか？ 残念ながら、異なるファミリにアップグレードした場合は、ロールバックを実行できません。ロールバックできるのはパッチアップグレードのみです。 カスタマーサポートが Change Management を介して本番環境でのロールバックを開始する予定の場合、当社はこれを準本番環境でテストして、意図した結果セットを取得できていることを確認する必要があります。 このため、本番環境を準本番環境に復元し、ロールバックを試して意図した結果セットを取得しているかどうかチェックし、お客様の確認を得てから本番環境でロールバックを実行します。 注意：ロールバックでは、スキーマの削除 (テーブルまたは列、インデックスの削除は OK)、親の再指定/列の昇格、テーブルの切り捨て、テーブル/列の名前変更、列タイプの変更、列幅の減少は記録されません。 これらはロールバックから除外され (除外リスト)、構成できません。 ServiceNow では、アップグレード後に予期しない壊滅的な問題が発生した場合は、前方修正の実施を推奨しています。前方修正とバックアップからの復元 データ復旧オプションの詳細については、次のセクションを参照する必要がある場合もあります: アップグレード後にデータが破損した場合、データを復旧するために何ができますか？ 上記の詳細については、次のドキュメントを参照してください：Roll back and delete recovery London 以降、インスタンス管理者はこれをトリガーできます：Roll back patch upgrades or plugin activations アップグレードロールバックのメカニズム 15. 更新セットを使用して、アップグレード後に元に戻されたカスタマイズをキャプチャする方法を教えてください。 次の記事は、本番環境でのアップグレード後に再利用できる、準本番インスタンスでスキップされたレコードのレビューをキャプチャする手順について説明します：How to use an Update Set to capture reverted customizations made after an upgrade 更新セットでは、インスタンスのアップグレードログから処分、解決、コメントなどはキャプチャ「されません」。 新しいインスタンスで更新セットをコミットしたら、ハウスキーピングのために、これらのログエントリ (必要な列) を、インポートセットを使用して転送する必要があります。 16. スキップされたレコード数が準本番インスタンスと異なるのはなぜですか？ そのような比較は、同一条件の場合にのみ可能です。インスタンスが同期していない場合、レコードの数はインスタンス間で異なります。 この問題は、本番環境と準本番環境の間でカウントが異なる場合に発生します。この状況は、準本番環境が本番環境の完全クローンではない (多くの場合、ログ/監査が除外されている) ときに発生します。詳細については、「アップグレードを予行演習する最善のプロセスはどれですか？」を参照してください。 「KB0955553：スキップされた更新レコードの解決の追跡 - Paris バージョンでのアップグレード関連の変更」を参照してください。 17. アップグレードサマリーレコードとアップグレード履歴レコードの間でスキップされた更新の数が異なるのはなぜですか？ 詳細については、次の記事を参照してください。スキップされた更新の数が "アップグレードモニターでのアップグレードサマリーレポート" と "アップグレード履歴でのスキップされた更新ウィジェット" と "sys_upgrade_history_log からのグループごとの処分" テーブル間で不一致 アップグレード時にレコードに起こったことを示す統合リストを取得するために最適な場所は、sys_upgrade_history_log テーブルとグループごとの「処分」です。 18. アップグレードの進行中にキャンセルすることはできますか？ インスタンスでトリガーされたアップグレードを正常にキャンセルすることはできません。アップグレードサイクルを完了させ、HI チケットを使用してアップグレード後の問題として対処する必要があります。可能な選択肢については、24 時間 365 日の電話サポートにお問い合わせください。 19. スキップされた更新レコードの確認方法と、その解決のトラッキング方法を教えてください (Pairs 以降の新機能)。 「KB0955553：スキップされた更新レコードの解決の追跡 - Paris バージョンでのアップグレード関連の変更」を参照してください。