掌握SAP BTP Cockpit：人人都能照做的简单步骤

SAP Business Technology Platform（BTP）Cockpit是一个网页控制台，您在这里运行自己的SAP云环境：账户、服务、用户、安全、已部署的应用和成本。如果您负责管理BTP、向它部署应用，或者审批它的账单，这个界面就是您要常驻的地方。

要进入它，请打开您所在区域的网关：https://emea.cockpit.btp.cloud.sap、https://amer.cockpit.btp.cloud.sap或https://apac.cockpit.btp.cloud.sap（SAP Learning）。您需要一个SAP用户ID，管理员可以帮您开通。试用账户使用https://cockpit.hanatrial.ondemand.com/trial/，有效期最长90天，30天后需要办理延期（SAP Developers）。

然后按下面的顺序完成设置。第一次摸索这个顺序，我花了好几天。大部分的麻烦，都来自把第四步放在了第一步之前。

一切都放在一个层级结构里。全局账户是您与SAP的合同，里面装着您购买的服务池。目录为子账户分组，比如按业务单元。子账户是真正干活的地方：每个子账户都有自己的区域、一个环境（如Cloud Foundry或Kyma）、自己的用户和自己的服务实例。

1. 全局账户您与SAP的合同，以及您购买的服务
   权利每个子账户从中取用的有限池子
2. 目录为子账户分组，例如按业务单元

• Finance-Dev开发，使用免费或小规格的方案
• Finance-Test测试，有自己的用户和角色集合
• Finance-Prod生产，上线之前设置好告警

BTP本身涵盖四个领域：应用开发与自动化、集成、数据与分析，以及AI。您在Cockpit里会遇到这四个领域，但多数项目从集成和S/4HANA的扩展开始。

这是我在一个新的全局账户上遵循的顺序。每一步都有天然的负责人。

1. 统一子账户结构和命名（平台负责人）。每个领域分开发、测试和生产，例如Finance-Dev、Finance-Test、Finance-Prod。
2. 连接您的身份提供商（安全负责人）。在添加任何一个用户之前先做这件事。
3. 按岗位职能定义角色集合（安全负责人），包括一个应急（break-glass）管理员集合。
4. 分配权利，先从最小的开始（平台负责人）。当某个团队能证明自己需要时，再追加。
5. 安装并配置Cloud Connector（基础设施团队），如果BTP需要访问本地部署的系统。
6. 开启告警和用量复核（平台负责人）。决定由谁看什么，多久看一次。
7. 把这一切记录在Cockpit之外（架构师）。结构、命名规则、权利的划分，以及每一项背后的理由。

子账户和权利

大多数团队就是在这里搞出一团乱麻，并且为此困扰好几年。

我曾合作过一位客户，有50多个随意命名的子账户，没人找得到东西。在项目中途去理清这些，非常痛苦。请先花一天时间，把结构画在纸上。如果您在多个区域运行，就在各区域之间镜像同样的结构，并用标签把相关的子账户归在一起。

**权利（Entitlement）**决定每个子账户可以使用哪些服务，以及用多少。您的全局账户拥有的是一个有限的池子。我从最小配置起步，按需扩大，这种做法让我的客户在没用上的服务上省下了数千美元。许多服务有免费方案，用来测试已经足够。

用户、信任和角色集合

如果您的公司已经有身份提供商，比如Microsoft Entra ID或Okta，就不要手工管理BTP用户。SAP推荐的路线，是使用一个SAP Cloud Identity Services租户，并在Security > Trust Configuration下把它连接到子账户。这个租户随后充当您企业身份提供商的代理。信任关系可以通过OpenID Connect自动建立。双因素认证和访问策略也就集中在一处。

角色集合是您分配给用户或用户组的一组角色。我的做法是：

1. 围绕岗位职能来建，而不是围绕个人。
2. 粗细要适中：具体到有意义，但不要细到要维护几百个。
3. 保留一个应急管理员集合，用于紧急情况。
4. 每个季度复核一次分配。人会换岗，却保留着原来的权限。

服务、实例和密钥

要创建服务实例，请在子账户中打开Services > Service Marketplace，选择服务，并选一个方案。方案同时决定能力和成本。请把您选择的设置保存在Cockpit之外的某个地方；出问题时您会用到。

把实例绑定到您的应用，BTP就会注入凭据。对于不是BTP应用的外部工具，请创建一个服务密钥。密钥要按使用者来命名，比如jenkins-deployment，而不是key1。

选择运行时

Cockpit提供三种主要环境。请对照团队的技能来选。

运行时	最适合	注意事项
Cloud Foundry	Java、Node.js和Python应用，包括SAP Cloud Application Programming Model（CAP）	成熟的默认选项；对大多数团队来说意外最少
Kyma	基于Kubernetes的原生微服务和事件驱动的扩展	需要许多SAP团队不具备的Kubernetes技能
ABAP环境	S/4HANA旁边的ABAP Cloud扩展	与ABAP开发人员天然契合；只能使用已发布的API

我见过项目因为开发人员要学一个符合架构规划、却不符合他们经验的新环境，而延误了好几个月。技术上更好、但您的团队构建不了的运行时，是更差的选择。

要部署到Cloud Foundry，先在manifest.yml里描述应用（内存、实例数、buildpack、环境变量），然后用CF CLI或流水线推送。Cloud Foundry会识别buildpack、绑定服务并设置路由。

把BTP连接到S/4HANA和其他系统

BTP上大部分工作是集成。下面是我设置得最多的几种模式。

场景	如何设置
本地部署或私有云版的S/4HANA	在您的网络里装Cloud Connector，在子账户里建一个目的地，再用OData或SOAP API
SuccessFactors之类的SAP云应用	目的地加Integration Suite或Event Mesh，扩展用CAP开发
Salesforce或Workday之类的非SAP系统	Integration Suite适配器，或自定义集成流
对外开放您自己的API	Integration Suite中的API Management：设计、发布、监控

Cloud Connector会向BTP开一条出站隧道，所以不需要入站的防火墙规则。只开放BTP真正需要的系统和URL路径。如果集成是您的主要用途，我写的SAP CPI文章更深入地讲了设计上的选择。

监控与成本控制

在需要之前，就把监控设置好。我每天早上喝着咖啡查看仪表板。这已经成了一种仪式，也让我躲过了不止几次“系统怎么挂了？”的时刻。

需要设置的内容：

1. 告警。 SAP Alert Notification service会把平台和应用事件发送到电子邮件、Slack或您自己的告警工具。我常用的设置，是关键应用走电子邮件，任何不能宕机的东西走Slack webhook。
2. 应用健康。 来自Cloud Foundry或Kyma视图的每个应用的响应时间和错误率。
3. 用量和成本。 每个子账户里的Usage Analytics，以及全局账户层面的Costs and Usage。用量数值每24小时刷新一次。

每个月都要删除没用的服务实例。在工作时间之外，把开发空间缩小规格。在续约之前，检查权利的消耗情况，因为没用上的配额是常见的超支来源。

自动化与自定义域名

在Cockpit里一路点鼠标，是无法规模化的。BTP命令行界面（btp CLI）和平台API，几乎可以把界面能做的事都写成脚本：创建子账户、分配权利、为开发人员开通环境。

在一次咨询中，我需要为12名新开发人员准备环境。我没有整天在Cockpit里点来点去，而是运行了我的脚本，然后去喝咖啡。等我回来，一切都准备好了。在一次咨询中，自动化部署把设置时间缩短了80%；把服务密钥和CF CLI接入流水线，则让部署从几个小时降到了几分钟。

对于面向用户的应用，自定义域名值得花功夫。它们是通过SAP Custom Domain service来配置的，而不是Cockpit里的某个菜单。在一个客户项目中，高管们立刻就注意到了更专业的观感。

1. 在统一命名规范之前就创建子账户。
2. 把角色分配给个人，而不是角色集合和用户组。
3. 在开发用的服务上，使用生产规格的方案。
4. 把告警拖到第一次宕机之后才做。
5. 没有记录账户结构及其背后的理由。Cockpit存的是“是什么”，从不存“为什么”。

卡在某个具体错误上？我写的BTP Cockpit问题指南讲了常见的那些。Clean Core指南则解释了BTP扩展在S/4HANA项目中的位置。

SAP BTP Cockpit是用来做什么的？

它是SAP Business Technology Platform的网页管理控制台。您用它来创建子账户、分配权利、管理用户和信任、创建服务实例、部署和监控应用，并跟踪用量和成本。

SAP BTP Cockpit的登录网址是什么？

请使用您所在区域的网关：欧洲、中东和非洲用https://emea.cockpit.btp.cloud.sap，美洲用https://amer.cockpit.btp.cloud.sap，亚太用https://apac.cockpit.btp.cloud.sap。试用账户使用https://cockpit.hanatrial.ondemand.com/trial/。登录需要一个SAP用户ID。

在SAP BTP中应该如何规划子账户结构？

从一开始，就把开发、测试和生产分别放进各自的子账户，并起一个让领域和阶段一目了然的名字，比如Finance-Dev和Finance-Prod。较大的组织会按业务单元再增加目录。先在纸上规划；服务一旦运行起来，这个结构就很难改了。

SAP BTP的四大支柱是什么？

SAP把BTP分成应用开发与自动化、集成、数据与分析，以及人工智能。多数项目从集成和S/4HANA扩展开始，等平台稳定之后，再加入数据和AI的用例。

如何把我的身份提供商连接到SAP BTP？

设置一个SAP Cloud Identity Services租户，并在Security > Trust Configuration下与您的子账户建立信任；OpenID Connect可以自动完成这一步。然后把您的企业身份提供商，比如Microsoft Entra ID或Okta，连接到这个租户。用户和双因素认证就在一处管理。

应该选哪个BTP运行时：Cloud Foundry、Kyma还是ABAP环境？

要与您的团队相匹配。Cloud Foundry适合Java、Node.js和Python应用，是最稳妥的默认选项。Kyma适合基于Kubernetes的原生微服务，但需要Kubernetes技能。ABAP环境适合ABAP开发人员，在S/4HANA旁边构建符合Clean Core的扩展。

如何把SAP BTP连接到本地部署的SAP系统？

在您的网络内部安装Cloud Connector。它会向BTP开一条安全的出站隧道，所以不需要改动入站防火墙。只开放BTP需要的系统和路径，在子账户的Connectivity下检查连接，然后创建供您的应用和集成流调用的目的地。在上生产之前，要把整条路径测试一遍。