オペレーショナル エクセレンスのトレードオフ
オペレーショナル エクセレンスは、明確なチーム標準の実装、理解された責任と説明責任、顧客の成果への注意、チームのまとまりを通じてワークロードの品質を提供します。 これらの目標の実装は DevOps に根ざしています。これにより、プロセスの分散を最小限に抑え、人的エラーを減らし、最終的にワークロードの価値の戻り値を増やすことをお勧めします。 この値は、ワークロードのコンポーネントによって提供される機能要件に対して測定されるだけではありません。 また、チームが改善を目指して提供する価値によって測定されます。
ワークロードの設計フェーズとそのライフサイクルにわたって継続的な改善手順が実行されるにつれて、 オペレーショナル エクセレンスの設計原則と、オペレーショナル エクセレンス の 設計レビュー チェックリスト の推奨事項に基づく決定が、他の柱の目標と最適化にどのように影響するかを検討することが重要です。 特定の決定は、一部の柱に利益をもたらす可能性がありますが、他の要素のトレードオフを構成します。 この記事では、ワークロード アーキテクチャと操作を設計するときにワークロード チームが遭遇する可能性があるトレードオフの例について説明します。
信頼性によるオペレーショナル エクセレンスのトレードオフ
トレードオフ: 複雑さが増しました。 シンプルな設計では構成ミスを最小限に抑え、予期しないやり取りが減るため、信頼性はシンプルさを優先します。
安全なデプロイ戦略では、多くの場合、アプリケーション ロジックとワークロード内のデータの間に、ある程度の前方互換性と下位互換性が必要です。 これにより複雑さが増し、テストの負担が増加し、ワークロードのデータの複雑さや整合性の問題につながる可能性があります。
コードとしての高度に階層化された、モジュール化された、またはパラメーター化されたインフラストラクチャでは、コード コンポーネント間の相互作用が複雑になるため、誤って構成が誤る可能性が高くなる可能性があります。
運用にメリットがあるクラウド設計パターンでは、外部構成ストアの使用やコンテナー化されたアプリケーション プラットフォームでのサイドカーデプロイの調整など、追加のコンポーネントの導入が必要になる場合があります。 追加のコンポーネントにより、システム内の相互作用点が増加し、障害や構成ミスの対象領域が増加します。
アジャイル開発とホスティングをサポートするように個別に進化するように設計されたワークロード コンポーネントは、サービス検出、または間接参照のレイヤーとしての DNS への依存関係を導入します。 サービス検出では、変更に対する応答性が不足している可能性があり、誤動作を診断するのが難しい場合があります。
小規模で増分的な変更をデプロイすることはリスクを軽減するための手法ですが、これらの小さな変更も運用環境に頻繁に配信されることが予想されます。 デプロイによってシステムが不安定になる可能性があるため、デプロイの速度が高まるにつれて、このリスクも高まります。
1 週間あたりのデプロイ数などの速度メトリックを使用して自身を測定し、より速いペースで変更を導入できる自動化を使用するカルチャも、より短い期間でより多くのデプロイを実行する可能性があります。
コントロールサーフェスと可観測性サーフェスの数を減らすことで操作を簡素化するために密度を高めることは、障害や構成の誤りによって不安定化イベントの影響半径が増加するため、可用性リスクが高まる可能性もあります。
オペレーショナル エクセレンスとセキュリティのトレードオフ
ワークロードを囲み、自動化やカスタム コントロール プレーンなどの操作をサポートするコンポーネントも、定期的なセキュリティ強化とテストのスコープ内にある必要があります。
ルーチン、アドホック、および緊急時の操作により、ワークロードとの接触ポイントが増加します。 ゼロ トラスト アプローチでは、これらのプロセスが攻撃ベクトルと見なされ、ワークロードのセキュリティ制御と検証に含める必要があります。
システムの監視プラットフォームは、ワークロードに関するログとメトリックを収集します。これは、情報漏えいの貴重なソースになる可能性があります。 そのため、ワークロードのセキュリティを拡張して、内部および外部の脅威からデータ シンクを保護する必要があります。
エージェントの構築、外部化された構成と機能の切り替えストア、サイド バイ サイド展開アプローチはすべて、セキュリティを必要とするアプリケーションの領域を増やします。
小規模で増分的な変更、または "最新の状態を維持する" 作業によって引き起こされる展開頻度が高いほど、ソフトウェア開発ライフサイクルのセキュリティ テストが強化されます。
監視プラットフォームは、すべての種類のデータを取り込んで、ワークロードの正常性と動作に関する分析情報を得ます。 チームが監視データの忠実度を高めようとすると、ソース システムのデータ マスクなどのデータ分類コントロールが監視プラットフォームのログとログ シンクに拡張されないリスクが高まります。
共有コンピューティング、ネットワーク、データ リソース内の異なるアプリケーション コンポーネントを併置して管理を容易にすることで、セグメント化を逆にしたり、ロールベースのセグメント化を実現しにくくしたりできます。 併置されたコンポーネントでは、ワークロード ID を共有する必要がある場合もあります。これにより、アクセス許可が過剰に割り当てられているり、追跡可能性が不足したりする可能性があります。
統合ログ シンクでシステム全体からすべてのログを収集すると、アラートのクエリと構築が容易になります。 ただし、これを行うと、必要な監査コントロールを使用して機密データを処理するために、行ベースのセキュリティを提供することが困難または不可能になる場合もあります。
ロールとその割り当ての粒度を減らすことで、属性ベースまたはロールベースのセキュリティの管理を簡素化すると、不適切に広範なアクセス許可が発生する可能性があります。
コスト最適化によるオペレーショナル エクセレンスのトレードオフ
オペレーショナル エクセレンスの柱では、生産性を低下させたり、ワークロードの投資収益率を危険にさらしたりするアクティビティは推奨されません。 配信アクティビティから焦点を移しているように見える推奨事項では、ワークロードとチームにとって長期的な最善の利益が考慮されます。 ワークロードが日の入り日に近い場合は、これらのトレードオフを引き起こす推奨事項に大きく投資しても意味がない可能性があります。
安全なデプロイプラクティスを実装すると、変更が比較的小さい場合でも、同時にデプロイされるリソースの数が増加する可能性があります。 これらのパターンでは、制御された方法でトラフィックをシフトできるように、アプリケーションまたはインフラストラクチャ コンポーネントの複数の同時実行インスタンスをデプロイする必要があります。 この増加は、不変のインフラストラクチャ アプローチを使用するワークロードでより顕著になります。
運用上調整されたクラウド設計パターンまたはワークロード自動化を実装するために、チームは追加のワークロード コンポーネントを導入する必要がある場合があります。 たとえば、デプロイの機敏性をサポートするために、ゲートウェイ ルーティング コンポーネントを追加できます。 より優れた構成管理をサポートするために、外部構成ストアを追加する場合があります。 テナント ライフサイクル イベントをサポートするために、コントロール プレーンを構築する場合があります。 これらのリソースは、運用前環境のコストにも影響します。
分離によって開発とテストのエクスペリエンスを向上させるために運用前環境の数を増やすと、リソースの数も増えます。 これらのリソースは、生産需要に対する供給に使用されず、ソリューションのコストを増加させます。
リソース数、SKU、データ量の観点から、運用環境との実稼働前環境のパリティを高めることで、品質保証プロセスが向上します。 パリティが増加すると、コストが増加します。
テレメトリ データは直接リソースではありませんが、可観測プラットフォームの有効性を実現するには、このデータを永続化する必要があります。 ほとんどの運用データ ストアには、インジェスト率とボリュームの組み合わせに基づく価格があります。 一般に、待機時間が短く、多様性の高いテレメトリの量が増えるにつれて、コストも増加します。 複数リージョンのデプロイの場合、これらの運用データ シンクはリージョンごとにデプロイされることが予想されるため、リソースごとのコストが要因になります。
健全で責任あるサポート構造とインシデント対応の作成と調整に時間を費やすワークロード チームは、ワークロードのユーザーに貴重なサービスを提供しています。 サポート作業が増加すると (たとえば、正式なオンコール ローテーションなど)、通常はビジネスの重要度が変化するため、これらのアクティビティのコストが増加します。 このコストの増加は、スタッフの増加の結果、または配信アクティビティからサポート機能に移行された注意の形で間接的に発生する可能性があります。
トレーニングは、ワークロード チームの個人的な継続的改善プロセスの重要な部分です。 このトレーニングは、個人エンリッチメント期間中に正式または自己指導することができます。 トレーニング時間が長くなるにつれて、ワークロードの直接開発に使用できる時間が減少します。 トレーニングに対する投資は、トレーニングがロールベースではないか、ワークロードまたはその将来に特に関連しない場合に減少します。
ワークロードの信頼性、セキュリティ、およびパフォーマンス効率を保護するための標準化された日常的な運用タスクは、定義、調整、実行に時間がかかります。 この時間は、配信に直接費やされることはありません。 これらのタスクの例としては、包括的な変更影響分析、変更制御プロセス、徹底的なテスト、パッチ管理の強化があります。 これらのタスクの頻度、包括的さ、運用上の負担が増えるにつれて、投資される時間も増加します。
ワークロード チームはツールとハードウェアを購入し、計画と設計、開発とテスト、監視など、ソフトウェア開発ライフサイクル (SDLC) 全体で実行されるアクティビティをサポートします。 この分野でのツールのマーケットプレースは拡大しています。 ツールは、通常、ツールの機能に対応するさまざまな価格ポイントで提供されます。 無料のオファリングを除き、これらのツールでは初期ライセンス コストが発生します。これは、シートごとまたはサイト全体の場合があります。 また、多くの場合、継続的なメンテナンス 契約も必要です。 新しいベンダー関係を確立する必要がある場合があります。 オペレーショナル エクセレンスの原則に関連する、予想されるツールまたはハードウェア支出の例を次に示します。
- 要件とバックログ管理
- アーキテクチャ設計ツール
- UI/UX 設計ツール
- コードと資産のホスティング
- コード開発環境とローコード開発環境
- オートメーション ツール
- 開発および品質保証ワークステーション
- 開発パイプラインとデプロイ パイプライン
- テストの実行と追跡
- 可観測性ツール
オペレーショナル エクセレンスとパフォーマンス効率のトレードオフ
ワークロードの可観測性フレームワークでは、アーキテクチャ内のコンポーネントが時間とリソースを割り当てて、ログとメトリックを作成、収集、ストリーミングする必要があります。 これらのデータ ポイントは、信頼性、セキュリティ、パフォーマンスに対して効果的なアラートと監視が可能であることを確認するのに役立ちます。 インストルメンテーションのレベルが上がるにつれて、システム リソースへの負担も増加する可能性があります。
ワークロードが安全なデプロイに使用する可能性があるブルー/グリーン デプロイなどの一部のデプロイ モデルでは、運用環境のアプリケーション プラットフォームに並列デプロイが導入される場合があります。 これらのデプロイでは、将来の需要を満たすのに十分な供給を提供したり、ロールバックをサポートするためにほとんど休止状態のデプロイを一定期間残したりするために、プリエンプティブ スケーリングが必要です。
多くのデプロイ モデルでは、ゲートウェイ ルーティング アクセス パターンを使用する必要があり、待機時間が発生する可能性があります。 この待機時間は、関連するフローのパフォーマンス 目標予算に対して引き出されます。
増分改善の理想をサポートする "時間の経過に伴う独立した変更" アプローチをサポートする一部のクラウド設計パターンでは、追加のコンポーネントのトラバーサルにより待機時間が発生する可能性があります。 この待機時間は、ゲートウェイ、メッセージング ブローカー、または破損防止レイヤーによって発生する可能性があります。
関連リンク
他の柱のトレードオフを調べる:
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示