世の中にはたくさんの環境が存在しますね。開発環境、ステージング、プロダクションが多いですが、他に QA 環境や負荷試験専用、脆弱性診断専用なども存在する組織もあることと思います。

さらにそれらが、アプリケーション、インフラ（ワークロードからネットワークまで）、CI/CD パイプラインなどで分かれており、複雑なことこの上ないですね。

例えば、Rails アプリのステージング環境はどのインフラに設置するといいのか？ということを考える上で、それぞれの環境の定義をはっきりするといいのでは？と考えたのでその考えを書いてみます。

普通に考えると、アプリケーションのステージング環境はステージングのインフラに設置することが多そうですね。

その場合、アプリケーションの配信やバージョン更新など、環境が備える各種機能は下位のインフラの稼働率に影響します。

ステージングのインフラの稼働率はどうなっているでしょうか？保守体制は？SLI/SLO は？ほとんどの場合決まってないことの方が多いですね。

SLI/SLO が決まっていない場合、期待SLOは各レイヤの担当者の暗黙の期待によって決まります。

アプリケーション開発者は、ステージングは使いたいときに動いていてほしい、壊れてもいいけど2時間程度で復旧してほしいと期待している一方、インフラ担当者は、ステージングが壊れていたら空き時間で直せそうなら直そう、今週は忙しいので来週にやろう、と考えている可能性もあるかもしれません。コストの関係でプロダクションほどリッチな監視をステージングでは実施していないということもあるでしょう。

その場合、期待 SLO にズレが生じているため、アプリケーション開発者は使いたいときに使えない、インフラ担当者は不確実性の高い更新検証がおいそれとできないなど、お互い不幸なことが起こることがあるかなと思います。

プロダクション以外でも、適切な SLO を定義して、SLO が一致した環境をそれぞれで活用すると、このコンフリクトは発生しなそうです。

簡単な解決方法として、アプリケーションのステージング環境はプロダクション環境のインフラに設置する、インフラの開発環境を用意して、インフラのステージングはプロダクションに近い SLO で運用するといったことが考えられます。環境分離や SG などのセキュリティ上できないことが多いと思いますが、SLO の一致という点では有効です。

SLO が一致していれば、例えばアプリケーションのプロダクションのトラフィックの一部を、ステージングのインフラで動かして稼働状況を確認する、ということもできると思います。

ここで言及している SLI/SLO の実体として、例えば MTTR を用いるのは良いかもしれません。本番インフラの 目標 MTTR は 15m, ステージングは MTTR 3h, 開発環境は MTTR 1w など。

他にも、MBTF を SLI にするのも良いと思います。MBTF の SLO を低く設定することで、カオスエンジニアリングを定常的に実施するといったことがインフラ担当者の判断で出来そうです。

とりとめもないですが、おしまい！