Lync Server 2013 での変更管理
トピックの最終更新日: 2014-08-18
IT 環境の変更は避けられません。 変更には、新しいテクノロジ、システム、アプリケーション、ハードウェア、ツール、プロセス、ロールと責任の変更が含まれます。 効果的な変更管理システムを使用すると、IT 環境に変更を迅速かつ最小限のサービス中断で導入できます。 変更管理システムは、システムの変更に関与するチームをまとめます。 たとえば、Office Web Appsを利用することを決定します。 これは、ユーザーがブラウザーでドキュメントを読み取って編集できるようにする統合 Lync Service アプリケーションです。 このサービスの実装は、運用環境に移行した後で、いくつかのチームが参加する必要があります。
テスト チームこのチームは、テスト サーバーで Office Web Appsをロードテストします。その過程で、運用サーバーの予想される使用パターンと予想されるパフォーマンスに関する情報を提供します。
Lync 管理者 このチームは、展開戦略を決定し、インストールを可能な限りスクリプト化します。 チームは、変更が運用環境にデプロイされていることを確認する責任を負い、その後の管理を担当します。 チームは、変更の効果を理解し、変更を運用環境に配置する前に手順に組み込む必要があります
ネットワーク チーム このチームは、インターネットから内部 Lync プール サーバーへのアクセスを許可するファイアウォール規則の変更を担当します。 また、利用可能な帯域幅が追加の負荷をサポートできることを確認するために、チームは Lync 管理者と協力する責任もあります。
セキュリティ チーム このチームはセキュリティを評価し、リスクを最小限に抑えます。 セキュリティ チームは、既知の脆弱性を確認し、セキュリティ リスクを最小限に抑えるのに役立つ必要があります。
ユーザー受け入れチーム このチームは、システムをテストし、改善のためのフィードバックを提供するユーザーで構成されています。
変更管理プロセスでは、各チームの責任を定義し、実行する作業をスケジュールし、必要なチェックとテストを組み込みます。 変更コントロールは、変更の複雑さと予想される影響によって異なります。 これらは、小規模な変更の自動承認、レビュー会議の変更、プロジェクト レベルの完全なレビューまでさまざまです。 これをより適切に説明するために、このセクションでは変更のグループについて説明します。
主な変更点 大きな変更はシステムにグローバルな影響を与え、さまざまなチームからの入力が必要になる場合があります。 この例として、Lync Server 2013 へのアップグレードがあります。 大きな変更は、多くのチームや、おそらく異なるシステムに影響します。 変更管理プロセスには、変更に関与するか、変更の影響を受けるチームに通知する 1 つ以上の変更レビュー会議が含まれる可能性があります。
重要な変更 大幅な変更には、計画、ビルド、および実装に重要なリソースが必要です。 変更の効果を確実に理解し、デプロイ手順をテストし、ロールバックとコンティンジェンシー計画を準備できるように、適切な変更制御を導入する必要があります。 大きな変更の例として、新しい累積的な更新プログラムをデプロイしています。
軽微な変更小規模な変更は、Microsoft Lync Server 2013 コントロール パネルを使用して特定の Lync ポリシーを変更するなど、IT 環境に大きな影響を与えるものではありません。
標準の変更 標準の変更は定期的に実行され、よく理解され文書化されています。 変更管理プロセスでは、手順に対するすべての変更を確認する必要があります。 コンテンツ データベースの作成やユーザーの追加などの定期的な変更には必要ありません。
次の変更管理の例では、異なるチームがどのように対話し、新しいサービス パックがデプロイされたときに実行されるアクションを調べます。 これらのアクションは、変更管理プロセスによって整理および管理されます。
変更要求を発生させる セキュリティ チームは最新のサービス パックを評価し、運用システムの可能性のある脆弱性を解決することを確認しました。 チームは、Lync Server を実行しているすべてのサーバーに新しい累積的な更新プログラムを適用するように変更要求を送信します。
Service Pack リリース ノート のレビュー Lync 管理者チームは、サービス パックのリリース ノートを確認して、システムへの影響を特定します。
一連のラボ テストが実行される Lync 管理者チームは、テスト環境内のサーバーでテスト更新を実行して、インストールされているアプリケーションやサーバー システムに影響を与えずにサービス パックを正常に適用できるかどうかを判断する必要があります。 運用環境で Lync Server とインターフェイスするサード パーティ製または内部的に作成されたアプリケーションがある場合は、これらのアプリケーションもテストする必要があります。 これらのテストを使用して、アップグレードの実行に必要な時間を見積もることもできます。
ユーザーに停止の通知を受け取る Lync 管理者チーム、通信チーム、またはユーザー ヘルプ デスクは、影響を受けるすべてのユーザーに、計画メンテナンス サイクルとサービスが利用できない期間について通知します。
Lync の完全バックアップは、アップグレード前に実行されます Lync 管理者チームは、サービス パックのインストールが失敗した場合に元のシステム状態に戻すために使用できる有効なバックアップがあることを確認する必要があります。 問題が発生した場合にこのシステムをすぐに使用できるように、バックアップをスタンバイ サーバーに復元することをお勧めします。
累積的な更新プログラムが展開されます Lync 管理者チームは、計画メンテナンス サイクル中にインストールを行います。
変更のタイミングの管理
作業の重複セクションの中断を回避するために、変更をスケジュールする手順を実装することをお勧めします。 たとえば、2 つのチームがどちらもシステムに対する軽微な変更を計画している可能性があります。 あるチームがプールに累積的な更新プログラムを適用し、別のチームがそのプールにレガシ ユーザーを移行している可能性があります。 どちらのチームも、他のチームが計画している変更の影響を受けず、各チームが他のチームが計画している変更について必ずしも認識していない可能性があります。 両方の変更が同時に発生した場合は、変更を実装する際に問題が発生する可能性があります。 また、変更が適用された後に問題が発生した場合 (たとえば、ユーザーの移行が失敗した場合)、ロールバックする変更を決定するのは困難な場合があります。 変更をテストして受け入れるために、IT と管理の間に定期的なメンテナンス期間を設定する必要があります。