MVPが本物のプロダクトになるとき何が変わるか

この移行は運用の話であって、設計の話ではない

本番移行は書き直しだと身構えるチームが多いのですが、たいていそうではありません。十人を捌いていたコードは、数百人でもさほど文句を言いません。変わるのは、停止に代償が伴い、顧客より先に誰かが気づかねばならなくなることです。

揃えておくもの

復元したことのあるバックアップ。 試していないバックアップは信念であってバックアップではありません。使い捨て環境へ復元し、所要時間を計ってください。

クラッシュだけでなく、症状への警報。 効いてくる障害は、たいていプロセスの死ではありません。キューの増大、成功率の低下、静かに止まったジョブです。

無停止でデプロイでき、切り戻せること。 必要になった日には、後半のほうが前半より重要です。

責任者がいること。 形だけの当番表ではなく、不都合な時間に何かが壊れたとき誰が見るのか、という明確な答えです。

たいてい作り直しが要るもの

レート制限、金銭が動く処理の冪等性、そしてMVPが信頼できる単一ユーザーを前提にしていた場合のアクセス制御。この三つはほぼ必ず挙がります。

大事なローンチの前にやる

いずれも、必要性を証明する障害の最中よりも、静かな一週間のうちに足すほうが安く済みます。