ワークロードの運用上の卓越性のトレードオフ Power Platform
運用上の卓越性は、明確なチーム標準、理解された責任と説明責任、顧客の結果への配慮、およびチームの結束の実装を通じて、作業負荷の品質をサポートします。 これらの目標の実装は DevOps が根源で、プロセスの差異を最小限に抑え、人的エラーを削減し、最終的にはワークロードの価値の収益を高めることが推奨されています。 その値は、ワークロードのコンポーネントによって提供される機能要件に対してのみ測定されるわけではありません。 チームが改善に向けて努力して提供する価値でも測定されます。
ワークロードの設計フェーズ中、および継続的な改善手順が実行されるそのライフサイクル全体を通じて、 運用上の卓越性の設計原則 と 運用上の卓越性の設計レビュー チェックリスト の推奨事項に基づく決定が、他の柱の目標と最適化にどのように影響するかを考慮することが重要です。 特定の決定は、一部の柱には利益をもたらすかもしれませんが、他の柱にとってはトレードオフとなる可能性があります。 この記事では、ワークロード アーキテクチャと操作を設計するときに、ワークロード チームが遭遇する可能性のあるトレードオフの例について説明します。
運用の効率性と信頼性のトレードオフ
トレードオフ: 複雑さが増す。 シンプルな設計が構成ミスを最小限に抑え、予期しない相互作用が減少させるため、信頼性はシンプルさを優先します。
安全な展開戦略では、多くの場合、アプリケーション ロジックとワークロード内のデータの間に、ある程度の上位互換性および下位互換性が必要です。 複雑さが増すとテストの負担が増加し、ワークロードのデータの複雑さや整合性の問題が発生する可能性があります。
高度に階層化、モジュール化、またはパラメータ化された構造では、ワークロードのコンポーネント間の相互作用が複雑になるため、偶発的な構成ミスが発生する可能性が高くなります。
運用に役立つクラウド設計パターンでは、シークレット ストアの使用や依存関係の取得など、追加のコンポーネントの導入が必要になる場合があります Application Insights。 コンポーネントが追加されると、システム内の相互作用ポイントが増加し、誤動作や構成ミスの可能性が高まります。
小さな段階的な変更を導入することはリスクを軽減するための手法ですが、ユーザーはそれらの小さな変更がより頻繁に本番環境に配信されることを期待しています。 展開によってシステムが不安定になる可能性があるため、展開の速度が上がると、このリスクも高まります。
週あたりの展開などのベロシティ メトリックで自らを測定し、より速いペースで変更を導入できる自動化を使用する文化では、短い期間で多くの展開を実行する可能性も高くなります。
制御ポイントと観測ポイントの数を減らして操作を簡素化するために密度を高めると、誤動作や誤った構成によって不安定なイベントの影響が増大するため、可用性リスクが増大する可能性もあります。
運用の効率性とセキュリティのトレードオフ
自動化やカスタム コントロール プレーンなど、ワークロードを取り囲み、その操作をサポートするコンポーネントも、定期的なセキュリティ強化とテストの対象に含める必要があります。
日常的な操作、計画外の操作、緊急操作により、作業負荷との接触点が増加します。 ゼロ トラスト アプローチでは、これらのプロセスを脆弱性と見なし、ワークロードのセキュリティ制御と検証に含める必要があります。
システムの監視プラットフォームは、ワークロードに関するログとメトリックを収集します。これは、情報開示の貴重なソースとなる可能性があります。 したがって、ワークロードのセキュリティを拡張して、データ シンクを内部および外部の脅威から保護する必要があります。
ビルド エージェント、外部化された構成、および機能トグル ストアはすべて、セキュリティを必要とするアプリケーションの表面領域を増加させます。
小さな段階的な変更や「最新の状態を維持し、最新の状態を維持する」取り組みによって導入頻度が高くなると、ソフトウェア開発ライフサイクル (SDLC) でのセキュリティ テストが増えます。
監視プラットフォームは、あらゆる種類のデータを取り込んで、ワークロードの正常性と動作に関する分析情報を得ます。 チームが監視データの忠実度を高めようとすると、ソース システムのデータ マスキングなどのデータ分類制御が監視プラットフォームのログやログ シンクにまで及ばないリスクが高まります。
管理を容易にするために、共有環境とデータ リソースに異なるアプリケーション コンポーネントを共存させると、セグメンテーションを取り消す、ロールベースのセグメンテーションの達成が困難になります。 共存するコンポーネントでもワークロード ID を共有する必要がある場合があり、これにより権限の過剰な割り当てや追跡可能性が欠ける可能性があります。
システム全体のすべてのログを統合ログ シンクに収集すると、クエリやアラートの作成が容易になります。 ただし、そうすると、必要な監査制御を使用して機密データを扱うための行ベースのセキュリティを提供することが困難になったり、不可能になったりする可能性があります。
ロールとその割り当ての詳細を減らして属性ベースまたはロールベースのセキュリティの管理を簡素化すると、権限が不適切に広範囲になる可能性があります。
運用の効率性とエクスペリエンスの最適化のトレードオフ
多大なリソースを必要とするユーザー エクスペリエンスの開発は優先順位が低くなる可能性があり、その結果、ワークロード ユーザーが必要とする使いやすさ、インタラクション、ビジュアル デザインがエクスペリエンスに欠ける可能性があります。
ユーザー インターフェイスの開発では、反復と出荷サイクルが高速化されることが多く、チームのSDLCプロセスに負担がかかる可能性があります。
運用の卓越性とパフォーマンス効率のトレードオフ
- ワークロードの監視フレームワークでは、アーキテクチャ内のコンポーネントがログとメトリックを作成、収集、ストリーミングするための時間とリソースを割り当てる必要があります。 これらのデータ ポイントは、信頼性、セキュリティ、パフォーマンスに関して効果的なアラートと監視を可能にするのに役立ちます。 計測のレベルが上がると、システム リソースへの負担も増加する可能性があります。
- 段階的な改善の理想をサポートするために「時間の経過に伴う独立した変更」アプローチをサポートする一部のクラウド設計パターンでは、追加コンポーネントのトラバースにより遅延が発生する可能性があります。