ServiceNow のクローンに関する不明な問題と例

[JunshuO]

ServiceNow インスタンスのクローン作成は、開発、テスト、本番環境の維持に欠かせない要素です。これにより、アドミニストレーターは開発やテストのために本番データと構成を非本番インスタンスに複製できます。クローン作成プロセスは一般的に簡単ですが、あまり知られていない問題がいくつか発生し、中断を引き起こす可能性があります。これらの未知の問題を理解することは、クローン作成操作をスムーズに行うために不可欠です。

1. 構成データの意図しない上書き

問題: 本番インスタンスを開発インスタンスまたはテストインスタンスにクローンすると、ターゲット環境にのみ存在するカスタム構成や特定の設定が上書きされ、予期しない動作が発生する可能性があります。

例: 開発インスタンスに、まだ本番環境に展開されていないカスタムビジネスルールまたは統合があるとします。本番環境から開発環境へのクローン作成中に、これらのカスタマイズが本番環境構成によって上書きされ、その結果、作業が失われる可能性があります。たとえば、開発インスタンスのサードパーティサービスとの統合は、統合構成がサードパーティサービスを考慮していない本番設定で上書きされたため、クローン後に機能を停止する可能性があります。

ソリューション: 「テーブルを除外」機能を使用して、開発環境またはテスト環境に固有の特定の構成が上書きされないようにします。開発環境の変更を必ず文書化し、カスタム構成を定期的にバックアップしてください。

2. 環境間のデータの不整合

問題: 意図的または非意図的に特定のテーブルがクローン作成プロセスから除外されると、データの不整合が発生する可能性があります。これにより、ワークフローが壊れたり、テスト条件が不正確になったりする可能性があります。

例: 本番から開発へのクローン作成中にインシデント管理ワークフローに関連するテーブルが除外されると、インシデント関連データが同期されない可能性があります。これにより、開発環境で新しいインシデントワークフローをテストするときに本番環境の条件が反映されないため、不一致が生じる可能性があります。

ソリューション: クローンを作成する前に [除外テーブル] リストを注意深く確認し、重要なデータテーブルが含まれていることを確認してください。テストするプロセスまたはワークフローに不可欠なテーブルを除外しないでください。

3. 個人データまたは開発データの損失

問題: 本番インスタンスのクローンを作成すると、開発者メモ、テストレコード、非本番インスタンスに固有の個人用データや開発用データが失われる可能性があります。

例: 開発者は、アクティブなテストケースやプロトタイプ構成などの個人用の進行中のデータを開発インスタンスに保存できます。本番環境からクローンを実行すると、このデータが上書きされ、重要な開発作業が失われる可能性があります。たとえば、開発者が新機能のテストレコードを作成しても、クローン後にこれらのレコードが本番データに置き換えられ、不要なやり直しが発生する場合があります。

ソリューション: 個人データの損失を防ぐために、開発者はクローンの前に重要なデータをエクスポートし、その後再インポートする必要があります。もう 1 つのアプローチは、更新セットを使用してデータのスナップショットまたはバックアップを作成することです。

4. 統合と外部接続への影響

問題: 非本番インスタンスで構成された統合は、本番値によって上書きされるインスタンス固有の認証情報、トークン、または URL に依存する可能性があるため、クローン後に機能を停止する場合があります。

例: テスト環境は、特定のトークンまたは認証情報を使用して、テスト目的で別の外部 API に接続できます。本番環境からクローンを作成した後、開発環境が本番トークンまたは API URL を継承する場合があるため、外部サービスに接続しようとしたときに失敗する可能性があります。

ソリューション: 「テーブルを除外」機能を使用して、統合固有のテーブルが上書きされないようにします。または、クローン後に、非本番環境に合わせて API 認証情報またはトークンを必ず更新してください。

5. 通知ストーム

問題: メールアラートや SMS メッセージなど、本番環境で構成された通知が、クローン後に誤って非本番環境でトリガーされ、不要なメッセージが殺到することがあります。

例: インシデント更新のメール通知が本番環境でアクティブになっているとします。本番インスタンスを開発にクローンした後も、これらの通知はアクティブなままになり、開発インスタンスでテストしているときに、テストユーザーやアドミニストレーターが何百通もの不要なインシデントメールを受け取ることがあります。

ソリューション: クローンを作成する前に、常に非本番環境でメール通知と送信メールを非アクティブ化してください。ServiceNow には、クローン後に送信メールをオフにするようにカスタマイズできるクローン後スクリプトが用意されています。

6. セキュリティロールの不整合

問題: クローンプロセスは、ターゲット環境のロールベースのアクセス制御 (RBAC) を中断する可能性があります。開発インスタンスまたはテストインスタンスには存在しても本番環境には存在しないカスタムセキュリティロールまたは割り当てが上書きされ、セキュリティの不整合が発生する可能性があります。

例: 開発環境では、カスタムセキュリティロールによって、テスト目的で特定のテーブルまたはワークフローへのアクセス権が付与される場合があります。本番から開発へのクローン後に、このロールが上書きされたり失われたりして、開発者またはテスターの権限エラーが発生する可能性があります。

ソリューション: カスタムセキュリティロールを文書化してバックアップします。クローン後のプロセスを使用して、ターゲット環境に固有のロールとアクセス設定を手動で復元します。

7. クローン後スクリプトの失敗

問題: ServiceNow を使用すると、アドミニストレーターは、クローン後に自動的に実行されるクローン後スクリプトを構成して、通知の無効化、認証情報のリセット、構成の更新などのタスクを実行できます。ただし、これらのスクリプトが失敗すると、インスタンスが一貫性のない状態のままになる可能性があります。

例: 送信メールを無効にするように設計されたクローン後スクリプトは、構文エラーまたは古い API 参照が原因で失敗し、開発インスタンスでアクティブなメール通知が発生する可能性があります。これにより、テスト環境から意図しないメールが送信され、混乱が生じたり、ワークフローが中断されたりする可能性があります。

ソリューション: クローン後のスクリプトを定期的にテストして更新し、正しく実行されることを確認します。クローン後に検証ステップを自動化して、主要な構成 (通知や統合など) が適切に調整されていることを検証することを検討してください。

まとめ

ServiceNow でのクローン作成は、環境全体で一貫性を維持するための強力なツールですが、潜在的なリスクも伴います。アドミニストレーターは、構成の上書き、データ損失、統合の失敗などのあまり知られていない問題に注意することで、これらの問題の影響を軽減できます。プロアクティブな計画、除外リストの慎重な使用、クローン後の徹底的な検証により、すべての ServiceNow 環境でクローン作成プロセスを成功させ、スムーズに行うことができます。

---

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/unknown-issues-of-clone-in-servicenow-with-examp...。

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/unknown-issues-of-clone-in-servicenow-with-examp...。

[JunshuO]

ServiceNow インスタンスのクローン作成は、開発、テスト、本番環境の維持に欠かせない要素です。これにより、アドミニストレーターは開発やテストのために本番データと構成を非本番インスタンスに複製できます。クローン作成プロセスは一般的に簡単ですが、あまり知られていない問題がいくつか発生し、中断を引き起こす可能性があります。これらの未知の問題を理解することは、クローン作成操作をスムーズに行うために不可欠です。

1. 構成データの意図しない上書き

問題: 本番インスタンスを開発インスタンスまたはテストインスタンスにクローンすると、ターゲット環境にのみ存在するカスタム構成や特定の設定が上書きされ、予期しない動作が発生する可能性があります。

例: 開発インスタンスに、まだ本番環境に展開されていないカスタムビジネスルールまたは統合があるとします。本番環境から開発環境へのクローン作成中に、これらのカスタマイズが本番環境構成によって上書きされ、その結果、作業が失われる可能性があります。たとえば、開発インスタンスのサードパーティサービスとの統合は、統合構成がサードパーティサービスを考慮していない本番設定で上書きされたため、クローン後に機能を停止する可能性があります。

ソリューション: 「テーブルを除外」機能を使用して、開発環境またはテスト環境に固有の特定の構成が上書きされないようにします。開発環境の変更を必ず文書化し、カスタム構成を定期的にバックアップしてください。

2. 環境間のデータの不整合

問題: 意図的または非意図的に特定のテーブルがクローン作成プロセスから除外されると、データの不整合が発生する可能性があります。これにより、ワークフローが壊れたり、テスト条件が不正確になったりする可能性があります。

例: 本番から開発へのクローン作成中にインシデント管理ワークフローに関連するテーブルが除外されると、インシデント関連データが同期されない可能性があります。これにより、開発環境で新しいインシデントワークフローをテストするときに本番環境の条件が反映されないため、不一致が生じる可能性があります。

ソリューション: クローンを作成する前に [除外テーブル] リストを注意深く確認し、重要なデータテーブルが含まれていることを確認してください。テストするプロセスまたはワークフローに不可欠なテーブルを除外しないでください。

3. 個人データまたは開発データの損失

問題: 本番インスタンスのクローンを作成すると、開発者メモ、テストレコード、非本番インスタンスに固有の個人用データや開発用データが失われる可能性があります。

例: 開発者は、アクティブなテストケースやプロトタイプ構成などの個人用の進行中のデータを開発インスタンスに保存できます。本番環境からクローンを実行すると、このデータが上書きされ、重要な開発作業が失われる可能性があります。たとえば、開発者が新機能のテストレコードを作成しても、クローン後にこれらのレコードが本番データに置き換えられ、不要なやり直しが発生する場合があります。

ソリューション: 個人データの損失を防ぐために、開発者はクローンの前に重要なデータをエクスポートし、その後再インポートする必要があります。もう 1 つのアプローチは、更新セットを使用してデータのスナップショットまたはバックアップを作成することです。

4. 統合と外部接続への影響

問題: 非本番インスタンスで構成された統合は、本番値によって上書きされるインスタンス固有の認証情報、トークン、または URL に依存する可能性があるため、クローン後に機能を停止する場合があります。

例: テスト環境は、特定のトークンまたは認証情報を使用して、テスト目的で別の外部 API に接続できます。本番環境からクローンを作成した後、開発環境が本番トークンまたは API URL を継承する場合があるため、外部サービスに接続しようとしたときに失敗する可能性があります。

ソリューション: 「テーブルを除外」機能を使用して、統合固有のテーブルが上書きされないようにします。または、クローン後に、非本番環境に合わせて API 認証情報またはトークンを必ず更新してください。

5. 通知ストーム

問題: メールアラートや SMS メッセージなど、本番環境で構成された通知が、クローン後に誤って非本番環境でトリガーされ、不要なメッセージが殺到することがあります。

例: インシデント更新のメール通知が本番環境でアクティブになっているとします。本番インスタンスを開発にクローンした後も、これらの通知はアクティブなままになり、開発インスタンスでテストしているときに、テストユーザーやアドミニストレーターが何百通もの不要なインシデントメールを受け取ることがあります。

ソリューション: クローンを作成する前に、常に非本番環境でメール通知と送信メールを非アクティブ化してください。ServiceNow には、クローン後に送信メールをオフにするようにカスタマイズできるクローン後スクリプトが用意されています。

6. セキュリティロールの不整合

問題: クローンプロセスは、ターゲット環境のロールベースのアクセス制御 (RBAC) を中断する可能性があります。開発インスタンスまたはテストインスタンスには存在しても本番環境には存在しないカスタムセキュリティロールまたは割り当てが上書きされ、セキュリティの不整合が発生する可能性があります。

例: 開発環境では、カスタムセキュリティロールによって、テスト目的で特定のテーブルまたはワークフローへのアクセス権が付与される場合があります。本番から開発へのクローン後に、このロールが上書きされたり失われたりして、開発者またはテスターの権限エラーが発生する可能性があります。

ソリューション: カスタムセキュリティロールを文書化してバックアップします。クローン後のプロセスを使用して、ターゲット環境に固有のロールとアクセス設定を手動で復元します。

7. クローン後スクリプトの失敗

問題: ServiceNow を使用すると、アドミニストレーターは、クローン後に自動的に実行されるクローン後スクリプトを構成して、通知の無効化、認証情報のリセット、構成の更新などのタスクを実行できます。ただし、これらのスクリプトが失敗すると、インスタンスが一貫性のない状態のままになる可能性があります。

例: 送信メールを無効にするように設計されたクローン後スクリプトは、構文エラーまたは古い API 参照が原因で失敗し、開発インスタンスでアクティブなメール通知が発生する可能性があります。これにより、テスト環境から意図しないメールが送信され、混乱が生じたり、ワークフローが中断されたりする可能性があります。

ソリューション: クローン後のスクリプトを定期的にテストして更新し、正しく実行されることを確認します。クローン後に検証ステップを自動化して、主要な構成 (通知や統合など) が適切に調整されていることを検証することを検討してください。

まとめ

ServiceNow でのクローン作成は、環境全体で一貫性を維持するための強力なツールですが、潜在的なリスクも伴います。アドミニストレーターは、構成の上書き、データ損失、統合の失敗などのあまり知られていない問題に注意することで、これらの問題の影響を軽減できます。プロアクティブな計画、除外リストの慎重な使用、クローン後の徹底的な検証により、すべての ServiceNow 環境でクローン作成プロセスを成功させ、スムーズに行うことができます。