Development Environments = Production

多くの場合、アプリケーションやワークロードを中心に環境を構築します。多くの企業のIT組織では、チームが新しいプロジェクトをサポートするために新しい環境を導入します。このような状況では、開発環境が「最初の」環境であると考えられます。そのため、環境が早ければ早いほど、チームが実験できる「自由度」が高くなります。

プロジェクトの初期段階では、開発者は開発環境においてリスクを取る余裕があります。しかし、プロジェクトがリリース日に近づくにつれ、開発環境の安定性は、アプリケーションプロジェクトを時間通りに提供するために重要になります。

開発環境がダウンすると、プロジェクトが遅れてしまいます。開発環境を本番環境のように扱うことはあまりありませんが、実際にはそうなのです。SLAは同じではないかもしれませんが、時間の経過とともに重要な環境になっていきます。Kubernetesのような新しいプラットフォームを導入する場合、マルチテナンシーのような複雑な要素が加わります。これは、複数のプロジェクトが、ネームスペースによって論理的に分離されているとはいえ、同じ環境を共有することを意味します。開発に支障が出れば、複数のプロジェクトに影響が出る可能性があります。

このような懸念を考慮すると、「環境」を環境そのもの（または環境を支えるプラットフォーム）のレンズを通して見ることは価値があります。すなわち、プラットフォームはアプリケーションとして扱うことができ、またそうすべきです。そのため、環境はユーザー（開発者）に提供されるものとして扱われる必要があります。最初の環境は、アプリケーションの開発環境であってはならず、何か別のものが必要です。この「別の何か」を表す言葉としてよく耳にするのが「サンドボックス」です。このサンドボックスとは、要するにプラットフォームの開発環境のことです。

Sandbox Before Development

最初に導入する環境は、運用サンドボックス（呼び方は自由）です。これは運用チームの開発環境です。パブリッククラウドを使うにしても、OpenShiftのようなプラットフォームでプライベートクラウドを構築するにしても、Hardwareを使うにしても、運用サンドボックスは必ず存在します。

オペレーションチーム（モダンなSREをベースとしたオペレーション、または従来のオペレーション）が最初に取り組むべきユースケースの1つは、次のようなものです。どうやって開発環境を作るのでしょうか？