明確な目的を持つオフショアステージング

リリースを検証し、証拠を残す

小規模チームがレポート API を変更する場面を想像してください。有用なリハーサルでは、認証済み読み取り、互換性のあるデータベース移行、キュー済みエクスポート、以前のサポート対象アーティファクトを確認します。これは実例となるワークフローであり、顧客の結果や PrivacyNodes のデプロイサービスではありません。

アーティファクト、構成スキーマ、重要なランタイムバージョンを意図したターゲットと整合させてください。データセットサイズやワーカー同時実行数など、意図的な差異を記録します。機能リハーサルの合格は、本番パフォーマンスを確立したり、ダウンタイムのないリリースを保証するものではありません。

本番への影響を環境外に保つ

別のデータベースロール、キュー、出力先を使用してください。メールはキャプチャシンクへ、Webhookは制御されたレシーバーへルーティングし、その特定の動作が実行されるまでスケジュールされた処理を無効にしてください。合成アカウントは本番データや資格情報にアクセスできないようにする必要があります。

命名規則は分離ではありません。アプリケーションがどの宛先にアクセスでき、どのIDがホストを管理できるかを確認してください。共有ホストのステージングは、プロセス名が異なっていても、競合と障害を共有します。

Dev 1 を保証ではなく問いとして使う

Dev 1 は 1 vCPU、2 GB RAM、30 GB ストレージ、月間 1 TB 転送量で開始します。集中したAPIやコンパクトな機能リハーサルの計画候補になり得ます。すべてのスタックがこの範囲に収まると仮定せず、アプリケーション、ホスト、テストデータベースを測定してください。

例示的な 2,000 MiB のワークシートでは、ホストツール用に 400、API用に 500、テストデータベース用に 500、リリースの重複用に 300、不確実性用に 300 を予約するかもしれません。これは既に名目上の 2 GB 割り当てに対して厳しく、同時実行ワーカーは除外されています。それでも要件を検証できる場合はテストステージを順次実行するか、より大きな構成を選択してください。予約を削除して無理に収めないでください。

ワーカーを同時実行する必要がある場合、または移行に現実的な大規模データセットが必要な場合は、比較してください App 2。Dev 1 + 1 GB RAM は割引前で月額 $7.50 ですが、ベースCPUは同じままです。追加RAMは、CPUバウンドの負荷テストを別のプロファイルの代表にすることはできません。

昇格と停止の両方をリハーサルする

開始前に期待するテスト結果を記述してください：正しいアカウントアクセス、完全なエクスポート1回、互換性のある新旧リーダー。成果物と移行境界を記録してください。新しいコードが起動してもワーカーが失敗する場合は、昇格を停止してください。ポートが緑色でもリハーサルは完了しません。

スキーマ変更の場合は、互換性リリースと部分的に移行されたデータをテストしてください。新しいフィールドが権威になった後も、旧のみのライターが安全であると仮定しないでください。レビュー済みの復旧成果物を利用可能に保ち、破壊的な廃止は別の決定にしてください。

コストとクリーンアップを意図的に保つ

これらは現在のDev 1 ベース合計です。より長い期間は、同じリソース割り当てに対する一括前払いです。環境の役割と予算を決めた後で、期待する運用期間を選択してください。割引は、必要な容量や復旧計画を省略する理由にはなりません。

演習後、チェックと残りの差異を記録し、ポリシーに従って使い捨てデータを削除し、エクスポートを期限切れにし、一時アクセスを取り消してください。ワーカーやスケジュールされたジョブが本番を指したままになっていないことを確認してください。 境界チェックリスト を次の保守担当者への引き継ぎ記録として使用してください。