Share via


データ運用チーム メンバーを編成する

クラウド規模の分析アーキテクチャは、一連の基本原則を使用して設計されています。

基本原則

  • セルフサービス対応: プロジェクト チームが独力で作業して、アジャイル開発方法を実施できるようにします。

  • ガバナンス: Azure プラットフォーム全体にガードレールを適用し、プロジェクト チームがアクセス許可内の機能だけを表示、変更、実行できるようにします。

  • デプロイの合理化: 組織内で一般的なポリシーを利用できるようにすることで、チームを迅速に拡大縮小したり、主要な設計と成果物の経験が少ないチームをサポートしたりできるようにします。

ロールとチーム

クラウド規模の分析全体で、水平方向にサイロ化されたチームから、アジャイルな垂直方向のクロス ドメイン チームに移行することが推奨されています。 データ運用チームはコントロール プレーンでのガバナンスの推進に集中するのに対して、データ アプリケーション チームは製品としてのデータの作成に集中します。 これは、アプリケーション開発により適したパターンへの組織上の変更を意味します。 たとえば、各アプリケーションに製品所有者がおり、その人物が要件を検討し、クロスドメイン チームと協力して製品を提供します。 この場合、製品は使用するデータです。

詳細については、Azure でのクラウド規模の分析のためのロールとチームに関する記事を参照してください。

デプロイと運用

デプロイ プロセスとデータ操作 (DataOps) モデルは、これらの基本原則の一部をサポートする重要な要素です。 組織には、原則に合わせるために次のガイドラインに従うことをお勧めします。

  • コードとしてのインフラストラクチャを使用します。
  • 社内の主要なユース ケースに対応するテンプレートをデプロイします。
  • GitHub のフォークとブランチに関する戦略が含まれるデプロイ プロセスに従います。
  • 中央リポジトリを維持し、データ管理ランディング ゾーンをデプロイします。

特定できる個別のスキルを持つ共同作成者は、プラットフォーム グループを確立して、データ プラットフォームのインフラストラクチャを一元的に管理し、データ管理ランディング ゾーンとさまざまなデータ ランディング ゾーン用の共通のデータ インフラストラクチャを構築してデプロイする必要があります。 また、プラットフォーム グループは、データ アプリケーション チームがデータ アプリケーションをキャプチャ、処理、保存、保守するのに役立つ、独立したテクノロジを構築、所有、提供することもできます。

チームは、サービスをセルフサービス方式で提供する必要があります。これには、ビッグ データの格納、製品データのバージョン管理、データパイプラインの整理と実装、データの識別不可能化などのためのツールを含めることができます。 これらの種類のツールは、ワークフローのボトルネックを最小限に抑え、新しいデータ製品を作成するためのリードタイムを短縮するための鍵となります。

プラットフォーム グループは、このセクションに記載されているベスト プラクティスに従って目標を達成する必要があります。 他のデータ製品チームは、今後予定されている記事のベスト プラクティスを使用して、データをテストおよび自動化する必要があります。

詳細については、Azure でのクラウド規模の分析のための DevOps 自動化に関する記事を参照してください。

次のステップ

Azure でのクラウド規模の分析のチームについて理解する