部署后继续对服务负责

定义用户依赖的服务

部署让软件可用。运维则让它在用户、依赖、流量和要求变化时持续有用。代码生成器不能消除这些持续工作。

对于虚构客户导出，用户需要的不只是能访问的页面，而是在可接受时间内，以所需格式获得获准记录。服务还必须阻止访问其他组织的数据。

发布前指定负责人。如果服务承诺涵盖非正常工作时段的响应，记录由谁负责。供应商可以承担部分工作，但组织仍需要清楚的决策与沟通路径。

选择能支持行动的信号

服务级别指标（SLI）衡量已定义的服务行为特性。服务级别目标（SLO）为该指标在规定期间内设定目标。根据用户需要和运维能力选择目标。

Google 的 SRE 指南解释了这一方法，以及如何用错误预算支持可靠性决策。不要在未确认含义时照搬其他服务的目标。参见 SLO 指南和错误预算策略示例。

对于导出功能，定义符合条件的请求怎样才算成功。区分预期拒绝与系统故障。记录排除项，防止仅通过隐藏困难请求来改善指标。

不要为了提高可见性而记录完整导出内容。只收集诊断问题所需的最少信息，并保护其访问。

准备事件响应

决定谁协调、谁调查、谁沟通。小团队可以合并角色，但职责必须清楚。保留观察和操作记录。

Google 的事件响应指南在技术缓解措施之外，也强调协调和沟通。即使技术修复正确，用户仍可能不知情，多名响应人员也可能作出冲突修改。参见事件响应。

智能体可以在获准数据边界内汇总日志或比较假设。但不能因为事件紧急，就授予不受限制的生产权限。对于例外访问，使用明确的升级处理路径。

演练恢复并为维护投入资源

用有代表性的虚构数据测试恢复流程。明确代码回滚无法撤销什么，包括已删除记录或已发送消息。记录恢复服务所需的时间和信息。

分配持续工作：依赖更新、访问权限复核、适用时的证书续期、容量变化和文档修正。服务如果没有维护能力，上线预算结束后，待履行职责就会持续积累。

事件结束后，选择针对已观察原因的改进，并将其关联到实现和验证。这使生命周期闭环：运行证据改变团队下一步规定和构建的内容。