翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
次の手順
このガイドでは、さまざまなシナリオにおけるさまざまなネットワークアクセスアプローチについて説明し、各アーキテクチャの利点と欠点について説明します。ネットワークアクセスアプローチの選択が単なるテクノロジーの議論ではない理由を理解する必要があります。ビジネスとテクノロジーの連携が不可欠です。次のステップと推奨事項は、現在の機能の評価、市場ニーズの分析、ガバナンスコントロールの実装を通じて、ネットワークアーキテクチャ戦略の評価と標準化に役立ちます。
現在のアーキテクチャと機能の評価
このガイドの自己評価フレームワーク、現在の規制要件、市場の現在の状態 (顧客と競合分析の両方の観点から) など、関連するデータソースに対して現在のネットワークアーキテクチャを確認します。例えば、 AWS Well-Architected フレームワーク
潜在的な例外、1 回限り、過去の製品決定を確認します。興味を持ってチャレンジし、その有効性を自動的に引き受けないでください。数年前の顧客要件は無効になる可能性があります。困難な前提は、アーキテクチャの複雑さを簡素化し、軽減する機会をもたらします。
簡単に説明すると、組織内のさまざまなロールが観察結果にアクセスして理解できるように文書化します。現在の状態がターゲット状態と異なる場所、ターゲット状態、影響、観測が行われたタイミングをキャプチャします。この情報を記録すると、組織は新しいデータに基づいて意思決定を行うことができます。
市場分析と顧客分析
市場トレンドに関するインサイトを収集します。コンシューマーが自分のような SaaS サービスにアクセスするために現在推奨される方法は何ですか? 顧客がいる場所にまだ出会っていますか? 顧客のコホートや行動は変化しましたか? エグゼクティブは、新しい市場、特定の規制要件を持つ地域、または新しい顧客層に向けて船を操縦しましたか? ビジネスモデルまたは運用モデルが変更されましたか? たとえば、サービスのホワイトラベル付けを検討していますか? 成長計画には、パートナーがそれらのパートナーとつながったときに顧客がサービスを利用できるように、パートナーと連携することが含まれていますか?
戦略的連携
現在の能力、現在のアーキテクチャ、市場、顧客を理解したら、戦略的調整会議を呼び出します。関連する製品、ビジネス、テクノロジーの利害関係者とともに、どの要件がまだ有効で、どの新しい要件を検討する必要があるかを問いかけます。不要になった要件を削除することで、複雑さを軽減する機会を見つけます。これは委員会による設計ではありません。エンジニアリングチームは実際のアーキテクチャと実装の詳細を準備し、所有する必要があります。ただし、この会議では、これが顧客や組織にとってのメリットを最大化する一連の要件である理由を明確にする必要があります。
標準化
顧客を惹きつけるには、サービスへの接続方法を自由に選択させようとするかもしれません。結局のところ、どのソリューションも技術的に機能し、それらをすべて管理および運用するための専門知識とリソースを持っている可能性があります。これは特定の時点までうまく機能しますが、ビジネス規模が拡大するにつれて、管理が困難になります。オブザーバビリティスタックは、複数のソリューションからのメトリクスをサポートする必要があり、サイト信頼性エンジニアもそれらを理解できる必要があります。接続アプローチごとにup-to-dateドキュメントが必要です。アプリケーションの主な変更は、提供するアクセスアプローチごとに評価する必要があります。アクセスアプローチごとに自動化とInfrastructure as Code (IaC) を記述して維持する必要があります。サービスへのアクセスを標準化しない場合の追加オーバーヘッドは、顧客に提供する柔軟性と照らし合わせて検討する必要があります。
意思決定の指針として北極星が必要な場合は、標準化をお勧めします。顧客が提供するサービスとやり取りする方法の標準化は、通常、組織全体の多くの成功メトリクスを改善するために実行できる 1 つの最も影響力のあるアクションです。標準化により、製品チームはサービスのコスト構造を理解し、データ駆動型の製品決定を簡単に行うことができます。運用チームは、事前定義された標準に従って開発、ロールアウト、運用される環境で、問題をトラブルシューティングし、トラブルシューティングプロセスの一部を自動化することが容易になります。これは、悪意のあるアクターによる異常、予期しない動作、またはアクションを検出するのに役立ちます。標準化により、技術的負債も削減されます。エンジニアリングチームが本番環境への変更をテストしてロールアウトするサイクルが少なくなります。また、市場投入までの時間を短縮し、セルフサービスオンボーディングの成功を向上させ、規制リスクを軽減することもできます。
したがって、現在実施されている可能性のある 1 回限りの確認もお勧めします。既存の顧客をサポートするのに費やす運用サイクルの数を定量化します。結果を履歴データと比較し、現在のアプローチが今後何年もスケールするかどうかを評価します。標準から逸脱する必要がある場合は、それらのリクエストの背後にある要件にチャレンジしてください。影響を評価し、直接的なメリットと長期的なコミットメントのバランスを取ります。
カスタマイズは避けられないが、標準と矛盾する場合は、責任共有モデルを検討してください。このモデルでは、製品は要求された変更から大きく保護され、カスタマイズは最小限の専用環境で行われます。例については、トランジット VPC アーキテクチャとの接続「」セクションを参照してください。
ガバナンス
規制要件と独自の内部標準に準拠するには、ガバナンスが不可欠です。適切なガバナンスを導入することで、標準を適用する場所と方法を制御できます。また、標準からの逸脱を検出し、必要な是正措置をリソース所有者に通知するためのコントロールを確立します。AWS Organizations、AWS CloudTrail、、および AWS ConfigAWS Control Towerは、 のワークロードの管理と管理 AWS のサービス に役立つ多くの のいくつかです AWS クラウド。
繰り返し
初期の作業から学んだことを使用して、将来整合性を保つために、軽量で反復可能なプロセスを設定します。入力が必要なロール、必要な頻度、データの精度、データの共有方法、およびデータに対して誰が対応するかを定義します。
