インスタンスのアップグレードの検証と比較Issue インスタンスのアップグレードとパッチ適用には、計画、テスト、および検証が必要です。安全で効果的なアップグレードを行うために、本番インスタンスをアップグレードする前に、リリースノートを読み、アップグレード計画を作成し、非本番インスタンスでアップグレードをテストしてください。 ServiceNow ではスムーズなアップグレードを実現するための、ガイドラインを提供していますが、本番環境のアップグレードと下位環境のインスタンスのアップグレードではアップグレードの動作が異なる場合があります。 最も一般的に報告される問題の 1 つは、アップグレードによって、あるインスタンスでカスタマイズされたファイルが別のインスタンスと比較して影響を受ける理由です。このドキュメントでは、アップグレードエンジンがカスタマイズを識別する方法と、インスタンス間のアップグレードを分析する際の注意点について全体像を示します。 [顧客アップデート] テーブルと [記録時間] フィールド アップグレードによるカスタマイズの処理方法を先に進む前に、「顧客アップデート」テーブルをもう少し詳しく調べる必要があります。 「 顧客アップデート」テーブルは、インスタンスのカスタマイズを識別するためにアップグレードエンジンによって使用されます。システムで行われたすべての構成変更は、「顧客アップデート」[sys_update_xml] テーブルに時系列に記録されます。 [注意:「update_synch」属性が true に設定されている初期設定のテーブルに限定されます] このテーブル内のレコードの順序によって、アップグレードエンジンによるカスタマイズの評価方法が異なります。Jakarta より前は、更新は [更新日時] フィールドに基づいて順序付けられていましたが、Jakarta 以降は [記録日時] フィールドが使用されます。 [記録時間] フィールド:Jakarta 以降、[顧客アップデート] テーブルに [記録時間] という新しいフィールドが追加されました。このフィールドの解像度はミリ秒未満ですが、[更新日時] の解像度は秒です。そのため、まったく同じ秒に記録された 2 つの更新がある場合、[更新日] フィールドで並べ替えると、顧客の更新が正しく評価されない可能性があります。そこで登場するのが「Recorded at」フィールドです。 [記録時間] フィールドと並んで、[アップグレード時に交換] フィールドは、カスタマイズを元に戻すかどうかにおいて重要な役割を果たします。 [アップグレード時に交換] フィールド:レコードの除外されていないフィールドを変更すると、対応するレコードが顧客アップデート [sys_update_xml] テーブルに追加され、[アップグレード時に交換] フィールドが false に設定されます。 注意: レコードの除外されていないフィールドについては、「更新セットの管理」を参照してください。 アップグレードでカスタマイズを識別する方法 アップグレードによってファイルが影響を受けるかどうかを理解するには、アップグレードエンジンのロジックがどのように機能するかを理解する必要があります。以下は、アップグレードエンジンがカスタマイズされているファイルとカスタマイズされていないファイルを識別する方法の簡単な概要です アップグレードエンジンは、「顧客アップデート」テーブルを使用してカスタマイズを識別します。アップグレードエンジンは、ベースライン更新セットまたはリモート更新セットからのレコードを無視する、次のようなクエリでこのテーブルをクエリします。 これらのレコードは、各ファイルの [記録時間] フィールド (Jakarta 以降) と [更新日] (Jakarta 以前) に基づいてソートされます次に、アップグレードエンジンは、各ファイルの最新のレコードの [アップグレード時に置換] フラグをチェックして、アップグレードによってファイルが影響を受ける必要があるかどうかを決定します。[アップグレード時に置換] が true に設定されている場合、ファイルはアップグレードによって影響を受けます。そうでない場合は、アップグレードによってファイルは無視され、カスタマイズはそのまま残ります。 「アップグレード履歴」モジュールと「レビュー対象のスキップされた変更」 アップグレード履歴モジュールは、インスタンスに対して行われたすべてのアップグレードを追跡します。管理者は、モジュールを使用してアップグレードの競合を解決し、オプションでカスタマイズをベースシステムバージョンに戻して新しい機能を利用することもできます。 アップグレード履歴レコードは、実行されるアップグレードごとに作成されます。アップグレード履歴レコードを表示するには、[システム診断]> [アップグレード履歴] に移動し、アップグレードをクリックします。 次の情報が要約されます。 スキップされた変更主にカスタマイズにより生じた可能性のある、前回のアップグレードとは異なるスキップされたレコードの合計数。 スキップされた変更は、スキップされた手動結合の状態のレコード (変更の値が true) に、スキップされたエラーの状態のレコードの数とスキップされた異なるレコードの数を加算したものです。 注: システムのアップグレード中にカスタマイズが上書きされないように、アップグレードプロセスはカスタマイズされたオブジェクトをスキップします (更新を適用しません)。管理者の責任の 1 つは、カスタマイズによってスキップされた各更新を解決することです。スキップされた更新を解決するには、スキップされた各レコードの理由を確認してから、カスタマイズを結合するか、カスタマイズをベースシステムに戻します。 適用された変更このアップグレードで適用された変更の合計数。 適用された変更は、更新されたレコードと異なるレコードの合計に、削除されたレコード数 (変更の値が true) と挿入されたレコード数 (変更の値が true) を加算したものです。 処理された変更このアップグレード中に処理されたアイテムの合計数。処理された変更は、スキップされた変更と適用された変更の合計です。 このモジュールでは、アップグレードと、アップグレードによって適用およびスキップされた変更を確認します。 アップグレードのトラブルシューティング:アップグレードによってレコードが変更された理由 特定のファイルがアップグレードによって影響を受けるべきではないことに気付いた場合、確認する場所は [顧客アップデート] テーブルです。問題のファイルの [名前] に基づいて、ベースライン更新セットまたはリモート更新セットからのレコードを無視し、[記録時間] 順に並べて、このテーブルにフィルターを構築します。「Customer Updates」テーブルでファイル名「sys_script_725330019f22120047a2d126c42e70fa」をクエリする例を次に示します。 ご覧のとおり、[記録時間] が 2018-04-14 02:04:39 に設定されているファイルの最新バージョンでは、[アップグレード時に交換] フィールドは [true] に設定されています。最新のレコードが「true」に設定されている場合、アップグレードにより、アップグレード中にこのファイルのカスタマイズがすぐに利用可能な状態に戻ります。 その後、他のインスタンスで同じ手順を実行して、上記のクエリによって同じレコードが返されるかどうかを確認できます。通常、インスタンス間に不一致が見られるのは、これらのレコードが一致しない場合です。下位の環境では、「アップグレード時に交換」が、たとえば更新セットの最近のコミットによって元に戻されている可能性があるため、アップグレードの動作が異なります。 インスタンス間のアップグレードの比較 アップグレードのベストプラクティスの一環として、本番インスタンスのアップグレードは常に下位の環境でテストする必要があります。この下位環境は、本番インスタンス (大きなテーブルと添付ファイルを含む) の完全クローンである必要があります。 ただし、本番インスタンスのアップグレード後に、「レビュー対象のスキップされた変更」の数が、準本番インスタンスで表示されていたものと異なると報告される可能性があります。 インスタンス間 (たとえば、両方が同じバージョンにアップグレードされた場合のインスタンス A とインスタンス B 間) のアップグレードを比較するための詳細な手順を次に示します。 インスタンス A で、[システム診断] > [アップグレード履歴] に移動し、問題のアップグレードのレコードを開きます。関連リストには [アップグレードの詳細] タブがあります。次に示すように、クエリを右クリックしてこのリストを新しいウィンドウで開き、[新しいウィンドウで開く] を選択します。 これにより、この特定のアップグレードの [アップグレードの詳細] レコードが新しいウィンドウで開きます。「処分」の結果を「最新ではない」として除外[ファイル名] 列と [処理] 列のみを表示するようにリストをカスタマイズ結果を [作成日時] フィールドと [ファイル名] フィールド (昇順) でソートします。次のようになります。 結果レコードを Excel ファイルにエクスポートします ( エクスポート制限の調整が必要な場合があります。)他のインスタンス (インスタンス B のアップグレード) のアップグレードの詳細レコードをエクスポートする場合も同じ手順を実行し、そこから新しいシートで前に作成した Excel ファイルに [ファイル名] フィールドと [処理] フィールドをコピーします。次に、この Excel シートで VLOOKUP を使用して、インスタンス A とインスタンス B の間の処理を比較できます。 添付されたサンプル Excel ファイル。 このファイルを使用して、比較対象の 2 つのアップグレードで異なる "性質" を持つファイルを比較できます。Excelシートは次のようになります(リストされているファイルはダミーファイルであることに注意してください)。 性質が異なるレコードを特定したら、それぞれのインスタンスでそれらのファイルを確認し、最新のレコードに「アップグレード時に交換」フラグが設定されている場合は、「顧客アップデート」テーブルでそのファイルを検証します。Related Linksインスタンスのアップグレードを比較する上記の方法は手動プロセスであり、アップグレードの更新が期待どおりであったかどうか、およびそれらが異なっていた理由を特定するためにレビューが必要になることに注意してください。 アップグレードの準備スキップされたレコードと利用可能なすべての処理を処理する方法: アップグレードモニターモジュール:個々のインスタンスのアップグレード