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