SAP BTP 生产运维与监控实践，从 Go Live 到退役的完整闭环

这几天我正在整理一个 SAP BTP 生产系统的上线检查清单，越整理越感觉，很多项目真正的风险并不在开发阶段，而是在应用已经推到生产环境之后。代码能跑起来只是开始，真正考验团队能力的地方，是上线窗口怎么定，权限怎么发，日志怎么查，告警怎么收，费用怎么管，系统出了问题谁来接，业务高峰期能不能稳住，某个服务不再使用时又能不能干净退场。

在 ABAP On Premise 时代，我们习惯了 SM21、ST22、SM37、ST05、ST12、SICF、/IWFND/ERROR_LOG、/IWBEP/ERROR_LOG 这一套工具链。到了 SAP BTP，思路发生了变化。系统不再只是一个单体 ABAP 系统，常见架构会把 SAP S/4HANA、SAP BTP Cloud Foundry、Kyma runtime、SAP Cloud Integration、SAP Build Work Zone、SAP Fiori Launchpad、SAP Cloud Identity Services、SAP Cloud ALM、SAP Alert Notification service、SAP Cloud Logging、SAP Job Scheduling Service 串在一起。监控对象从单一事务码里的错误记录，扩展成用户体验、服务健康、接口调用、后台任务、身份认证、费用消耗、平台可用性、自动化处置、退役清理这些连续环节。

这篇内容围绕 SAP BTP Operations and Monitoring 展开，不把运维当成上线后的附属工作，而是把它视为架构设计的一部分。做 Clean Core 时，我们常强调标准系统少改、扩展上云、接口清晰、升级安全。可如果扩展上了云，却没有可观测性、没有告警、没有成本边界、没有退役机制，那只能算把复杂度换了一个位