プロトタイプから本番ソフトウェアへ

プロトタイプは別の問いに答える

プロトタイプは、アイデアが機能しうるか、体験が追う価値があるかを問う。本番ソフトウェアは、実ユーザー、実データ、変化する要件、不便な時間のオンコールエンジニアに対して、アイデアが働き続けられるかを問う。これらの目標を混同すると、発見が遅れるか、隠れたリスクを出荷する。

プロトタイプからの学びを保て。ただしすべての近道を明示的にレビューしろ。ハードコードされた仮定、共有クレデンシャル、手動ステップ、欠けた所有、無制限コスト、回復できないデータを特定しろ。プロトタイプは証拠であり、自動的に最初の本番アーキテクチャではない。

運用境界を定義する

誰がプロダクトを使うか、どのデータを扱うか、どのアクションが不可逆か、どの外部サービスに依存するかを書き出せ。許容レイテンシ、可用性、サポート期待、保持、復旧を定義しろ。これらの制約は、人気で技術を選ぶより効果的にアーキテクチャを導く。

制約が許す限り、最初の本番システムを単純に保て。明確なデータモデルを持つモジュラーモノリスは、早すぎる分散サービスよりしばしば運用しやすい。分散は、測定されたスケーリング・所有・隔離・デプロイ問題を解くべきだ。

• 環境とクレデンシャルを分ける
• 反復可能なデプロイを自動化する
• バックアップを作り復旧をテストする
• レイテンシ、エラー、第三者コストの予算を設定する

安全でない状態を難しくする

すべての信頼境界でデータを検証し、サーバーで認可を強制し、秘密を守り、収集する個人情報を最小化しろ。最小権限のサービス身元を使い、アプリを再構築せずにクレデンシャルをローテーションしろ。通常の開発経路が安全な経路でもあるとき、セキュリティは最も強い。

管理ツールは顧客インターフェースと同じ注意に値する。機微なアクションには明示的権限、監査記録、適切な確認、有界なバッチ操作が要る。多くの損害インシデントは、正当な能力が間違ったスコープで使われるときに起きる。

デリバリーシステムを構築する

本番リポジトリは速いフィードバックが要る：整形、静的解析、型チェック、重要振る舞い周りのテスト、再現可能なビルド。デプロイは小さく、観測可能で、可逆であるべきだ。機能フラグは、所有と削除日があるとき、リリースと露出を分けられる。

ローンチ前に重要なユーザー成果を計装しろ。リリース識別子やリクエスト文脈のないエラー報告は、行動しにくい報告を生む。技術健全性とプロダクトシグナルを組み合わせ、チームが成功したデプロイと成功した体験を区別できるようにしろ。

準備状況は継続的だ

ソフトウェアが永久に本番準備完了になる単一の瞬間はない。トラフィックは増え、統合は変わり、チームは再編され、仮定は期限切れになる。インシデント、サポート要求、性能データ、プロダクト振る舞いを使い、システムを洗練しろ。

デモから耐久するプロダクトへの移行は、主に明示的責任の追加だ：データ、失敗、コスト、セキュリティ、リリース、ユーザーに対して。その責任が、小さなソフトウェアを依存可能にする。