展開失敗軽減戦略を設計するための推奨事項
この Power Platform Well-Architected Operational Excellenceチェックリストの推奨事項に適用されます:
| OE:11 | ロールアウト中の予期しない問題に迅速なリカバリーで対処する展開失敗軽減戦略を実装します。 ロールバック、機能の無効化、展開パターンのネイティブ機能の使用など、複数のアプローチを組み合わせます。 |
|---|
このガイドでは、展開の失敗に効果的に対処するために標準化された戦略を設計する際の推奨事項について説明します。 他のワークロードの問題と同様に、デプロイメントの失敗はワークロードのライフサイクルの避けられない部分です。 この考え方により、展開の失敗に対処するための適切に設計された意図的な戦略を立てることで、積極的に取り組むことができます。 このような戦略により、ワークロード チームはユーザーへの影響を最小限に抑えながら、障害を効率的に軽減できます。
このような計画がないと、問題に対する無秩序で有害な対応が生じる可能性があり、チームや組織の結束、顧客の信頼、財務に大きな影響を与えることがあります。
主要な設計戦略
場合によっては、開発プラクティスが成熟しているにもかかわらず、展開の問題が発生することがあります。 安全な展開プラクティスを使用し、堅牢なワークロード サプライ チェーンを運用することで、展開の失敗頻度を最小限に抑えることができます。 また、デプロイメントの失敗が発生した場合にそれを処理するための標準化された戦略を設計する必要もあります。
展開失敗軽減戦略は、次の 5 つのフェーズで構成されます。
- 検出: 失敗したデプロイメントに対応するには、まず失敗を検出する必要があります。 検出には、失敗したスモーク テスト、ユーザー レポート、監視プラットフォームが生成するアラートなど、さまざまな形式があります。
- 決定: 特定の障害タイプに対して最適な軽減戦略を決定する必要があります。
- 緩和策: 特定された緩和策を実行する必要があります。 軽減策では、フォールバック、ロールバック、またはロールフォワードの形式を使用できます。
- コミュニケーション: 緊急時の 応答 計画で要求されているように、問題を検出して解決する際には、利害関係者と影響を受けるユーザーに状況を知らせる必要があります。
- 事後検証: 非難のない事後検証により、ワークロード チームは改善すべき領域を特定し、学習内容を適用する計画を作成する機会が得られます。
以下のセクションで、これらのフェーズに対する詳細な推奨事項について説明します。
検出
デプロイメントに関する問題を迅速に特定するには、デプロイメントに関連する堅牢なテストと監視のプラクティスが必要です。 異常を迅速に検出するために、アプリケーション パフォーマンス管理ツールを使用し、インストルメンテーションを通じてログを記録することで、ワークロードの監視とアラートを補完できます。
スモーク テストやその他の品質テストは、ロールアウトの各段階で行う必要があります。 1 つの展開グループでのテストに成功しても、後続のグループでのテストの決定に影響を与えることはできません。
ユーザーの問題と展開フェーズを関連付けるテレメトリを実装できます。 これにより、特定のユーザーがどのロールアウト グループに関連付けられているかをすぐに特定できます。 このアプローチは、段階的公開の展開では特に重要です。これは、展開の任意の時点でユーザー ベース全体で複数の構成が実行される可能性があるためです。
ユーザーから報告された問題にすぐに対応できるように準備しておく必要があります。 実用的な場合は常に、サポート チーム全体が対応可能な勤務時間中にロールアウト フェーズを展開します。 適切なルーティングのために展開の問題をエスカレートする方法についてサポート スタッフがトレーニングを受けていることを確認します。 エスカレーションは、ワークロードの緊急対応計画に合わせて調整する必要があります。
決定
展開の問題に対する適切な緩和戦略を決定するには、次のような要素を考慮する必要があります。
使用する段階的公開モデルのタイプ。 たとえば、ブルーグリーン モデルやカナリア モデルを使用できます。 ブルーグリーン モデルを使用する場合は、ロールバックよりもフォールバックの方が実用的です。 更新されていない構成を実行するスタックに、トラフィックを簡単に戻すことができます。 その後、問題のある環境で問題を修正し、適切なタイミングで展開を再試行できます。
問題を回避するための任意の方法。 例としては、機能フラグ、環境変数、またはオンとオフを切り替えることができるその他の種類のランタイム構成プロパティの使用が挙げられます。 機能フラグをオフにするか設定を切り替えることで、問題を簡単に回避できる場合があります。 この場合、次のことができます。
- ロールアウトを続行します。
- フォールバックを回避します。
- 問題を発生させているコードを修正しながらロールバックします。
コードに修正を実装するために必要な労力のレベル。 コードを修正するための労力レベルが低い場合、特定のシナリオでは、ホットフィックスを実装してロールフォワードすることが適切な選択です。
影響を受けるワークロードの重要度レベル。 ビジネスクリティカルなワークロードは、ゼロダウンタイムの展開を実現するために、ブルーグリーン モデルのように常に並行して展開する必要があります。 結果として、この種のワークロードにはフォールバックが望ましい軽減戦略となります。
軽減策
以下は一般的な軽減戦略の一部です。
ロールバック: ロールバック シナリオでは、システムを最新の正常な構成状態に更新しました。
ワークロード チーム全体が「前回正常」の意味について合意することが重要です。この表現は、展開開始前に正常であったワークロードの最後の状態を指し、必ずしも以前のアプリケーション バージョンとは限りません。
ロールバックは、特にデータの変更に関連する場合は複雑になることがあります。 スキーマの変更により、ロールバックが危険になる場合があります。 これらを安全に実装するには、かなりの計画が必要になることがあります。 一般的な推奨事項として、スキーマの更新は追加的である必要があります。 レコードは新しいレコードに置き換えられるべきではありません。 代わりに、古いレコードを廃止し、廃止したレコードを安全に削除できるようになるまで、新しいレコードと共存させる必要があります。
フォールバック: フォールバック シナリオでは、更新されたシステムは運用トラフィック ルーティングから削除されます。 すべてのトラフィックは更新されていないスタックに送信されます。 この低リスクな戦略は、さらなる中断を引き起こすことなくコードの問題に対処する方法を提供します。
カナリア デプロイメントでは、インフラストラクチャとアプリの設計によって、フォールバックが簡単でなかったり、不可能になることもあります。 更新されていないシステムの負荷を処理するためにスケーリングを実行する必要がある場合は、フォールバックする前にスケーリングを実行してください。
問題のある機能をバイパスする: 機能フラグまたは別の種類のランタイム構成プロパティを使用して問題をバイパスできる場合は、ロールアウトを続行することが問題に対する適切な戦略であると判断できます。
機能のバイパスのトレードオフを明確に理解し、そのトレードオフを関係者に伝えることができる必要があります。 関係者は今後の計画を承認する必要があります。 関係者は、劣化状態での運用が許容できる期間を決定する必要があります。 また、問題のあるコードを修正して展開するのに必要な時間の見積もりと、その決定を比較検討する必要もあります。
緊急展開 (修正プログラム): ロールアウトの途中で問題に対処できる場合は、修正プログラムが最も実用的な緩和戦略となる可能性があります。
他のコードと同様に、修正プログラムは安全な展開手順に従う必要があります。 しかし、ホットフィックスを使用すると、タイムラインは大幅に加速されます。 環境全体でコード昇格戦略を使用する必要があります。 また、すべての品質ゲートでホットフィックス コードをチェックする必要もあります。 ただし、ベイク時間を大幅に短縮する必要がある場合や、テストを高速化するためにテストを変更する必要がある場合があります。 展開後できるだけ早く、更新されたコードに対して完全なテストを実行できるようにします。 品質保証テストを自動化すると、このようなシナリオでのテストの効率化に非常に役立ちます。
通信
インシデント発生時の混乱を最小限に抑えるためには、コミュニケーションの責任を明確に定義することが重要です。 これらの責任で、ワークロード チームがサポート チームや関係者、緊急対応マネージャーなどの緊急対応チームの担当者とどのように連携するかを確立する必要があります。
ワークロード チームがステータス更新を提供するために従う頻度を標準化します。 関係者がこの標準を認識し、いつ更新が行われるかを把握できるようにします。
ワークロード チームがユーザーと直接通信する必要がある場合は、共有に適した情報の種類と詳細レベルを明確にします。 これらのケースに適用されるその他の要件もワークロード チームに伝えます。
事後分析
事後検証では、例外なくすべての失敗したデプロイメントを 追従する する必要があります。 失敗した展開はすべて学習の機会となります。 事後検証は、展開および開発プロセスの弱点やインフラストラクチャの構成ミスを特定するのに役立ちます。
インシデントに関与した個人が改善できる点についての視点を共有する際に安心できるように、事後分析は必ず責任を問われないようにします。 事後検証のリーダーは、特定された改善を実施し、これらの計画をワークロード バックログに追加するための計画を フォローアップ する必要があります。
考慮事項と一般的な推奨事項
前回正常起動時の構成を簡単に展開できるように、展開パイプラインが個別のバージョンをパラメーターとして受け入れることができるようにします。
ロールバックまたはロールフォワード時に、管理プレーンとデータ プレーンの一貫性を維持します。 キー、シークレット、データベース状態データ、およびリソースとポリシーに固有の構成はすべて範囲内に含めて考慮する必要があります。 たとえば、前回正常起動時の展開でのインフラストラクチャ スケーリングの設計に注意します。 コードを再展開するときにその構成を調整する必要があるかどうかを判断します。
新しいデプロイメントと最後に正常に動作していたデプロイメントの違いが小さくなるように、まれに大規模な変更を行うよりも、小規模で頻繁な変更を行うことをお勧めします。
継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインで障害モード分析を実行し、軽減作業を複雑にする可能性のある問題を特定します。 ワークロード全体と同様に、パイプラインを分析して、特定の軽減タイプを試行するときに問題が発生する可能性がある領域を特定できます。
自動ロールバック機能を適切に使用します。
- Azure DevOps などの一部の CI/CD ツールには、自動ロールバック機能が組み込まれています。 この機能が具体的な価値を提供する場合は、使用を検討します。
- パイプラインを定期的に十分にテストした後でのみ、自動ロールバック機能を導入します。 自動ロールバックがトリガーされた場合に追加の問題が発生するほどパイプラインが成熟していることを確認します。
- 自動化によって必要な変更のみが展開され、必要なときにのみトリガーされることを信頼する必要があります。 これらの要件を満たすようにトリガーを慎重に設計します。
ロールバック中にプラットフォームが提供する機能を使用します。 たとえば、バックアップとポイントインタイムの復元は、ストレージとデータのロールバックに役立ちます。 または、仮想マシンを使用してアプリケーションをホストする場合は、元に戻す をインシデント直前のチェックポイントに復元すると役立ちます。
展開全体の失敗軽減戦略を頻繁にテストします。 緊急対応計画やディザスター リカバリー計画と同様に、展開失敗計画が成功するには、チームがその計画についてトレーニングを受け、定期的にプラクティスを実行する必要があります。 カオス エンジニアリングとフォールト インジェクション テスト は、デプロイメント緩和戦略をテストするための効果的な手法です。
Power Platform の促進
Microsoft Power Platform Build Tools for Azure DevOps を使用すると、 Power Platform で構築されたアプリに関連する一般的なビルドおよびデプロイメント タスクを自動化できます。
GitHub Actionsを使用すると、開発者は自動化されたソフトウェア開発ライフサイクル ワークフローを構築できます。 Power Platform Microsoft Power Platform の GitHub アクション を使用して、リポジトリにワークフローを作成して、アプリをビルド、テスト、パッケージ化、リリース、デプロイし、自動化を実行し、ボットやその他のコンポーネントを Microsoft Power Platform 上で管理できます。
ALM Accelerator は、継続的インテグレーション/継続的デリバリー プロセスを自動化するために設計された一連のアプリケーション、スクリプト、パイプラインで構成されるオープン ソース ツールです。
使用 パワーCAT Copilot Studio キット 副操縦士とテストを構成します。 Copilot Studio API (Direct Line) に対して個別のテストを実行することにより、副操縦士の応答が予想される結果に対して評価されます。
ソリューション内の 環境 変数 には、パラメータのキーと値が格納され、他のアプリケーション オブジェクトへの入力として機能します。 消費オブジェクトからパラメーターを分離すると、同じ環境内で、または他の環境にソリューションを移行するときに値を変更できます。
Power Platform 環境 では、ロールバックに役立つポイントインタイム リストア機能が提供されます。
Power Platform は、Azure Monitor エコシステムの一部である Application Insights と統合します。 この統合は以下に使用します。
Application Insights の Dataverse プラットホーム で取得された診断とパフォーマンスに関するテレメトリを受信します。 アプリケーションが Dataverse データベースおよびモデル駆動型アプリ内で実行する操作に関するテレメトリを受信するようにサブスクライブできます。 このテレメトリは、エラーとパフォーマンスに関連する問題の診断とトラブルシューティングに使用できる情報を提供します。
キャンバス アプリから Application Insights に接続します。 これらの分析を使用して問題を診断し、ユーザーがアプリで何を行っているかを把握できます。 より適切なビジネス上の意思決定に役立つ情報を収集し、およびアプリの品質を向上することができます。
Power Automate テレメトリ を Application Insightsに流入するように構成します。たとえば、クラウド フロー の実行を監視し、クラウド フロー の実行失敗に関するアラートを作成します。
Azureで使用するために、 Microsoft Copilot Studio copilot からテレメトリ データをキャプチャします Application Insights。 このテレメトリを使用すると、コパイロットとの間で送受信されるログに記録されたメッセージとイベント、ユーザーの会話中にトリガーされるトピック、トピックから送信できるカスタム テレメトリ イベントを監視できます。
オペレーショナル エクセレンス チェックリスト
完全なレコメンデーションのセットを参照してください。