計画立案チェックリストのアップグレード

ServiceNowインスタンスのアップグレードに関連するアクティビティを計画および追跡します。すべてのタスクを完了してアップグレードを成功させるために、アップグレード計画チェックリストで指示された手順に従ってアップグレードの追跡と計画を行なってください。

インスタンスの数やカスタマイズの状態などによっては、一部のオプション手順が適切でない場合があります。[N/A] 列で不要なものをマークします。

ヒント:

このチェックリストの PDF バージョンをダウンロードするには、ここをクリックしてください。

自己ホスト型のお客様向けの手順を完了するプロセスは異なる場合があります (インスタンスのクローンやアップグレードの要求など)。これらの違いは計画時に考慮する必要があります。

顧客名：
本番インスタンス名：	https://[instancename].service-now.com
その他のインスタンス名	https://[instancename].service-now.com https://[instancename].service-now.com

	説明	あり	いいえ	適用外
フェーズ 1 - リリースノートを読みアップグレードを計画する
1	対象の ServiceNow 機能リリースとパッチについては、製品とリリースのドキュメントに加えて「Yokohama リリースノート」を参照してください。 Yokohama 固有のアップグレードの考慮事項については、「様々な製品に関するアップグレード前後のタスク」を参照してください。
フェーズ 2 - 次の計画タスクを完了します。
2	アップグレードのスコープ内にある ServiceNow インスタンスを確認します。
3	インスタンスのホスティングモデルを確認します。たとえば、ServiceNow クラウド、オンプレミス、オフプレミスなどです。
4	Yokohama リリースノート およびその他のリリース資料に基づいて、アップグレード後に検証する必要がある新機能または重要な変更を決定します。
sn_callback.callback_max_retry_attempts	新しい製品リリースで導入された機能を有効または無効にする計画を確認します。
6	ブラウザサポートを確認して、ブラウザーの必須条件を確認します。たとえば、サポート対象のバージョンとタイプ、新しい UI バージョン向けの追加要件などです。サポート対象のブラウザーを自社の標準と比較し、ギャップを特定します。
7	クローン作成、アップグレード、テストのプロジェクト計画を作成します。
8	アップグレード前後で ServiceNow インスタンスの機能を検証するために必要なテスター、パワーユーザー、主要ステークホルダーのコアチームを特定します。
9	環境のクローン作成またはアップグレードのタイミングに影響を与える変更フリーズ期間の有無を確認します。たとえば、四半期末などです。
10	次の状況のうち、ServiceNow の非本番インスタンスに当てはまるものを確認します。 本番アップグレードが完了するまで開発とテストを停止できる。 アップグレード、修正、およびテストアクティビティを別のインスタンスで並行して実行する間、継続的な開発 (およびテスト) のアクティビティは非本番インスタンスで続行する必要がある。 本番インスタンスへの最終アップグレードが完了したら、本番インスタンスの非本番のインスタンスへの最終的なクローン作成は、本番アップグレードが完了するまで待機する。
11	統合テストに必要な他のシステムの可用性 (主要なリソースと環境) を確認します。
12	ServiceNow インスタンスを統合テストに使用する上で制限があるかどうかを確認します。たとえば、インターフェイスシステムを特定の ServiceNow テストインスタンスのみにアクセスするよう設定することなどです。
13	テストのスコープとアプローチを確認します。
14	すべてのコアインスタンス機能と統合のテストケースを含む、包括的なテスト計画を作成します。
15	テスト中に特定された不具合を追跡する方法を確認します。
16	以下を含む実装計画の詳細を作成します。 非本番インスタンスと本番インスタンスをアップグレードする順序とタイミング クローンを作成するインスタンス 統合テストに使用するインスタンス
17	環境のクローン作成またはアップグレードのタイミングに影響を与える変更フリーズ期間の有無を確認します。たとえば、四半期末などです。 責任者：ServiceNow またはお客様
18	既存の内部トレーニング資料、顧客インスタンスのナレッジベース記事、その他のサポートドキュメントを、アップグレードされたバージョンに合わせて更新する必要があるかどうかを判断します。たとえば、機能やユーザーインターフェイスの変更点などです。
19	オプション： ServiceNow 構成レビューをスケジュールします。このレビューでは、お客様の構成を ServiceNow のベストプラクティスに合わせて調整するための推奨事項を提示します。 注: サービス課金およびプロフェッショナルサービスの契約が必要な場合があります。
20	本番インスタンスでシステムクローンを作成し、開発インスタンスを [ターゲットインスタンス]として選択します。 影響を受けるユーザーと内部のステークホルダーに、(本番インスタンスの） クローン作成および非本番インスタンスのアップグレードの予定日時を通知します。 注: 本番インスタンスをできるだけ忠実に反映するシステムでテストすることが重要です。非本番インスタンスと本番インスタンスのサイズが同じ場合は、本番監査ログと添付データを含め、除外オプションの選択を解除していることを確認します。
フェーズ 3 - アップグレード構成を確認し、開発インスタンスのアップグレードをスケジュールする - Now Support
21	[可能なアップグレードの配布を確認 (Check distribution for possible upgrade)] スケジュール済みジョブの構成を確認して、実行頻度とタイミングを表示します。
22	[可能なアップグレードの配布を確認 (Check distribution for possible upgrade)] sys_trigger がアップグレードに向けて適切に設定されていることを確認します。
23	[可能なアップグレードについてデータベースを確認 (Check database for possible upgrade)] sys_trigger がアップグレードに向けて適切に設定されていることを確認します。
24	でアップグレードをスケジュールします。
25	該当する場合は、バージョンエンタイトルメントを要求します。
フェーズ 4 - 開発インスタンスのアップグレードを実行し検証を行う
26	アップグレードモニターを使用して、インスタンスのアップグレードを監視し、開発インスタンスのアップグレードが完了したことを確認します。
27	開発インスタンスのアップグレードが完了したら、アップグレードモニターでスキップされたレコードリストを処理します。
28	更新セットを特定します。
29	アップグレードの前後に、開発インスタンスでスモークテストを実施します。包括的なテスト計画を使用して機能テストを実行します。
フェーズ 5 - 該当する場合、テストインスタンスなど他の非本番インスタンスをアップグレードして検証する
30	本番インスタンスでシステムクローンを作成し、開発インスタンスを [ターゲットインスタンス]として選択します。
31	Now Support で非本番アップグレードをスケジュールし、アップグレード構成を確認します。
32	非本番インスタンスへのアップグレードが完了したことを確認します。
33	開発インスタンスにインストールされていたオプションのプラグインをすべてインストールします。
34	必要なカスタムアプリケーションとアップグレード後の修正スクリプトをすべてインストールします。
35	更新セットをインストールします。
36	機能テストを実行し、インスタンスのパフォーマンスを監視します。
フェーズ 6 - 本番インスタンスのアップグレードを準備する
37	更新セットですべての非本番インスタンスの不具合が修正され検証済みであることに対する、IT およびビジネスのステークホルダーのサインオフを確認します。 責任者：お客様
38	本番アップグレード後に ServiceNow インスタンスの機能検証に必要な主要ステークホルダーのコアチームを特定します。 責任者：お客様
39	アップグレード後の Day 1 サポートの範囲を確認します。 責任者：お客様
40	すべてのアップグレード手順、ロールと責任、コミュニケーション計画、主要な連絡先、Day 1 サポートの範囲などを含む本番アップグレード実装計画を作成します。 責任者：お客様
41	主要なステークホルダーおよびコアチームと一緒に、実装計画のウォークスルーとサインオフをスケジュールします。 責任者：お客様
42	組織の変更プロセスでの必要に応じて、変更レコードの承認を提出して取得します。 責任者：お客様
43	本番アップグレードの停止や新機能などの詳細を主要なステークホルダーとエンドユーザーに送信します。 責任者：お客様
44	アップグレードする前に、インスタンスのパフォーマンスをプロファイルします。
45	ServiceNow パフォーマンスホームページを使用して、アップグレード前にインスタンスのパフォーマンスを文書化します。
46	クローンで機能テストを実行し、インスタンスのパフォーマンスを監視します。
Phase 7 - 本番環境をアップグレードする
47	でアップグレードをスケジュールします。
48	該当する場合は、バージョンエンタイトルメントを要求します。
49	インスタンスのアップグレードを監視し、本番インスタンスのアップグレードが完了したことを確認します。
50	更新セットおよび、アップグレード後の修正スクリプトがあれば適用します。
51	ユーザー受け入れテスト (UAT) を実施して、インスタンスの検証およびテストを行います。本番アップグレード後にシステムが適切に作動し、主要な機能が利用可能であることをすべての主要なステークホルダーに確認します。