試作品の先に必要なインフラを定める

生成されたシステムから始める

架空の試作プラットフォームを考えます。Webコンテナー、マネージドPostgreSQLデータベース、公開URLを作成します。サンプルレコードで業務フローが正しく動きます。大きな実装に資金を投じる前に機能を評価できるため、有用な結果です。

次に会社は、機密の契約書を保存し、従業員のIDプロバイダーを使いたいと考えます。必要なシステムは変わりました。コンテナーのデプロイが成功しても、認可、承認済みのデータ処理、復旧可能性、サービスの責任者は確認できません。

開発プラットフォームが提供する機能は、それぞれ異なります。実際のサービスと設定を調べてください。すべての試作ツールに同じ制限があるとも、有名なクラウド名なら会社のポリシーを満たすとも考えないでください。

分野	確認する問い	求める証拠
ID	誰がログイン、管理、デプロイを行えるか？	ID連携、ロールの対応付け、アクセス停止のテスト
ネットワーク	どのサービスとデータ保管先が通信できるか？	ネットワーク設計と検証済みのアクセスルール
データ	各コピーをどこで処理し、保存するか？	データフロー図、サービスの利用条件、設定
シークレット	認証情報をどう渡し、ローテーションするか？	シークレットへの参照、アクセスルール、ローテーション手順
提供	レビュー済みコードをどうリリースにするか？	保護されたパイプラインと成果物の同一性
復旧	何を、どの制限内で復元できるか？	復旧目標と、測定した復元演習
運用	誰が障害に対応し、保守費用を確保するか？	サービス責任者、監視、インシデントの連絡経路、予算

これらには、既存の社内サービスを使えます。アプリごとに新しいID管理システムや監視プラットフォームを作る必要はありません。承認済みの機能につなぎ、不足する点を記録します。

AWS Well-Architectedは、運用、セキュリティ、信頼性、性能、費用、持続可能性を一緒に考えます。動くデプロイ構成は、アーキテクチャ評価の一部でしかないと確認するうえで役立ちます。フレームワークを確認してください。

開発、テスト、本番のリソースを特定します。どのIDが境界を越えられるかを定めます。承認されたデータ処理手順なしに、便利なプレビュー環境へ本番レコードをコピーしてはいけません。

外からのアクセスだけでなく、外向きの接続も調べます。非公開のデータベースでも、アプリを通して公開のログサービスへ情報を送ることがあります。コーディングエージェントのモデル呼び出しも、別に評価すべきフローです。

クラウドアカウント、DNS、証明書、暗号鍵、請求契約を誰が管理するか記録します。退職する従業員の個人アカウントに依存するプロジェクトには、アプリのコードが残っていても、管理責任の問題があります。

マネージドデータベースの提供者が基盤サービスを運用し、組織が利用者、データアクセス、スキーマ変更、保存設定を管理する場合があります。正確な分担はサービスと契約によって異なります。明示的に確認してください。

契約管理アプリでは、架空の条件で復元演習を行います。実際の復旧時間を測定し、失われる可能性のあるデータを特定します。結果を業務要件と比較します。「バックアップ有効」というチェックボックスは、同じ証拠にはなりません。

アクセス停止もテストします。架空の従業員をIDの情報源から削除し、意図したアクセス変更を確認します。設計には、有効なセッション、管理者ロール、自動化用のIDも含めます。

インフラの定義、環境設定、パイプライン、アプリのコードは、連携して変更する必要があります。エージェントは実際の対象環境に合わせて計画すべきです。そうしないと、ネットワーク、ID、管理責任の要件に合わないデプロイ構成を生成する可能性があります。

ここで、プラットフォームエンジニアリングとソフトウェアファクトリーが結び付きます。プラットフォームは、サポートする機能と境界を提供します。提供システムは、それらを使い、証拠を作り、運用への明確な引き継ぎを保つ必要があります。次にプラットフォームエンジニアリングを確認してください。