信頼性管理

本番サービスは開発/テストサブスクリプションには含まれていませんが、Azure Dev/Testサブスクリプションの他の段階を使って本番環境での信頼性を確保することもできます。

関連リソース:

• Azure Dev/Test offer documentation
• Enterprise Azure Dev/Test サブスクリプションの作成
• Azure for Visual Studio subscribers FAQ

組織のDev/Testサブスクリプションを利用する際は、どのように行うかを決めてください:

• 制御データ
• セキュリティとアクセスの管理
• 運用システムの稼働時間の管理

通常、本番環境に入る前に展開には共有、QA、統合、ステージング、フェイルオーバーなど複数の段階があります。 御社がこれらの段階をどのように定義するかによって、組織のDev/Testサブスクリプションの使用状況が変わることがあります。

顧客向けアプリケーションのようなミッションクリティカルなサービスを実行している場合は、開発/テストサブスクリプションは使わないでください。 Dev/Test サブスクリプションには、金銭的な補償を伴う SLA は付属しません。 これらのサブスクリプションは運用前のテストと開発を目的としています。

サイト信頼性エンジニアリング (SRE)

信頼性エンジニアリングと信頼性管理について理解を深めるために、SRM (Site Reliability Management: サイト信頼性管理)、つまり組織がそのシステム、サービス、製品に適切な信頼性を持続的に実現できるよう支援するエンジニアリング規範を考えてみましょう。

SRE と DevOps がどう違うのかという点については、その分野でもまだ結論が出ていません。 ある程度合意されている相違点としては、以下のようなことが挙げられます。

• SRE は、信頼性に焦点を当てたエンジニアリング規範である。 DevOps は、開発 (Development) 組織と運用 (Operations) 組織に関するサイロの解消に向けた動きから注目されるようになった文化的なムーブメントです。
• SREは職種名のこともあり得ます。例えば、 私はサイト信頼性エンジニア(SRE)です。 DevOps ではできません。
• SRE は杓子定規になりがちです。 DevOps は意図的にそうではありません。 ほぼ世界中に定着している継続的インテグレーションと継続的デリバリー、そしてアジャイルの原則は DevOps に最も近い。

SRE のプラクティスの詳細については、次のリンクを確認してください。

• SREの文脈
• 重要な SRE 原則とプラクティス: 好循環
• 重要な SRE 原則とプラクティス: SRE の人間的側面
• SRE の概要

サービス レベル契約

Enterprise Dev/Test の用途は、アプリケーションの開発とテストに限定されます。 このサブスクリプションを使用して、金銭的な補償を伴う SLA は得られません。

各種 Dev/Test サブスクリプションの使い分けを知る

Visual Studio サブスクライバー向けの月単位の Azure クレジットや、Enterprise Dev/Test サブスクリプション、開発テスト用の従量課金制プラン サブスクリプション (PAYG) など、個人やチームに合ったプランが簡単に見つかります。

個別のAzureクレジットは個別の開発およびテストシナリオに向けられており、エンタープライズ開発/テストサブスクリプションは大規模組織のチーム開発用に利用可能です。 利用可能なサブスクリプションオプションを確認し、開発やテストの要件に最適なものを判断してください。

個別のクレジット契約の管理

Visual Studio Azure単位は、個人の開発・テストやインナーループ開発のための個人特典です。 開発者間でクレジットをプールすることはできません。 クレジット サブスクリプションは Azure サブスクリプションではありますが、特別な Azure プランです。 クレジット サブスクリプションの管理は、他の Azure サブスクリプションと変わらないので、グループ内やチーム内で作業することができます。 クレジットカードを追加したり、企業向けの開発・テストサブスクリプションが自社の選定調達方法に割り当てられる場合は、個別の支出制限を解除できます。

開発者の内部ループ作業では、えてしてクレジットが使用されますが、いずれエンタープライズまたは組織の Azure Dev/Test サブスクリプション、つまり従量課金制を含むサブスクリプションに切り替わります。 このように、DevOps プロセスに従って進める中で、個人のクレジット サブスクリプションを使ってインナー ループを回すことができます。 DevOps の外部ループでは、運用環境以外のターゲットはエンタープライズの開発、テスト環境に配置され、運用ターゲットは運用環境に移されます。

クレジットサブスクリプション、エンタープライズ開発/テストサブスクリプション、PAYGサブスクリプションを管理し、それぞれ独自の階層を持つ 管理グループ を使って開発者をセグメント化しましょう。

あなたの組織のAzure Dev/Testが提供するサービスを利用する

組織の Azure Dev/Test サブスクリプションが必要な場合は、2 つのプランから選ぶことができます。

• 従量課金制 (PAYG) の開発/テスト (0023P)
• Enterprise Dev/Test (0148P)

それぞれのオプションには割引があり、Visual Studioのサブスクリプションが必要です。

各サブスクリプションオファーにより、事前に設定された仮想マシンを使ってクラウド上の開発・テスト環境でチームを立ち上げて稼働させることができます。 複数の Azure サブスクリプションを作成し、1 つのアカウントからそれらを管理します。 分離された環境を保ちながら、各プロジェクトまたは各チームに対する請求も分けることが可能です。

Enterprise Dev/Test サブスクリプションには、Enterprise Agreement (EA) が必要です。 開発テスト用の従量課金制プラン サブスクリプションは EA を必要としませんが、Enterprise Agreement アカウントで使用することは可能です。

なぜPAYGオファーとエンタープライズ開発/テストオファーを使うのか?

PAYG Dev/Test プランは、Visual Studio サブスクライバーとして使用する方に適しています。 個人用途向けのクレジット サブスクリプションとは異なり、PAYG はチーム開発に最適で、1 つのサブスクリプションを複数のユーザーが利用できます。 次の条件に当てはまる方には、PAYG Dev/Test プランが適しているでしょう。

• Enterprise Agreement を所有していない。 この場合、Visual Studio ライセンスで作成できるのは PAYG アカウントのみとなります。
• エンタープライズ契約を作成していますが、組織の契約を使わないサブスクリプションを設定する必要があります。 たとえば特別なプロジェクトがあって、独自のサブスクリプションが必要になった場合や、プロジェクトごとまたはチームごとに課金される分離された環境を作成しなければならない場合が該当します。
• IDは分離しておきたいです。 データ、リソース、アプリへのアクセスを保護するために、他の ID とは別に特定の ID が必要になる場合があります。