明确原型之外的基础设施

从生成的系统开始

考虑一个虚构原型平台。它创建 Web 容器、托管 PostgreSQL 数据库和公开 URL。工作流使用示例记录时运行正常。这是有用的结果：人们可以先评估功能，再为更大规模的实现投入资金。

现在公司希望存储机密合同，并使用员工身份提供方。所需系统已经改变。容器部署成功，不能证明授权、获准的数据处理、可恢复性或服务责任已经落实。

不同开发平台提供不同能力。检查实际服务和配置。不要假设所有原型工具都有相同局限，也不要假设熟悉的云品牌就符合公司策略。

回答七个生产问题

答案可以利用现有企业服务。不必为每个应用新建身份系统或监控平台。接入获准能力，并记录剩余缺口。

AWS Well-Architected 将运维、安全、可靠性、性能、成本和可持续性一起考量。它提醒我们：部署能够运行，只是架构评估的一部分。阅读框架。

定义环境之间的边界

识别开发、测试和生产资源。明确哪些身份可以跨越这些边界。没有获准的处理流程时，不要为了方便，把生产记录复制到预览环境。

既检查入站访问，也检查出站连接。私有数据库仍可能通过应用向公共日志服务发送数据。编程智能体的模型调用，是另一条需要单独评估的数据流。

记录谁负责云账户、DNS、证书、加密密钥和计费关系。即使应用代码可用，如果项目依赖即将离职员工的个人账户，责任归属仍有问题。

测试职责划分

托管数据库提供方可能运维底层服务，而组织负责用户、数据访问、数据模式变更和保留设置。具体划分取决于服务和合同，应明确询问。

为合同应用进行一次虚构场景的恢复演练。测量实际恢复时间，识别可能的数据丢失，并与业务要求比较。一个标为“已启用备份”的复选框，不能提供相同证据。

也要测试员工离职后的访问撤销。从身份源移除一名虚构员工，验证访问权限是否按预期变化。设计中应包括活跃会话、管理员角色和自动化身份。

将基础设施与交付系统连接

基础设施定义、环境配置、流水线和应用代码需要协调修改。智能体应根据真实目标环境规划工作。否则，可能生成与网络、身份或责任归属要求冲突的部署。

这正是平台工程与软件工厂的衔接处。平台提供受支持能力和边界。交付系统必须使用这些能力、产生证据，并保留明确的运维交接。继续学习平台工程。