当一个新的平台团队开始通过强制工作流推进路线图时，由于文档质量不足，开发者体验反而下降。正如 Davide de Paolis 在 Dev Summit Munich 分享的演讲《The Road to Compliance》中介绍的那样，最终的成功来自简化治理、优先处理真正重要的问题，并通过预防、检测和沟通逐步推进合规。共情、聚焦以及共同目标推动了成功落地。
De Paolis 表示，当建立专门的平台团队的需求变得明确后，该组织通过从产品团队中召集具有丰富开发经验、熟悉 DevOps 和云技术背景的成员，组建了这样一个团队。团队目标远大，制定了服务目录的路线图，并规划建设内部开发者平台以及云卓越中心。
然而，这些变化也带来了摩擦。De Paolis 解释说，开发者突然需要面对新的工作流、多个 AWS 账号以及一些不熟悉的概念：
他们过去习惯使用一个账号，权限范围更广，也更加宽松。现在他们需要切换上下文、更新配置，并学习新的技能。
与此同时，文档通常很长、过时，而且难以查找。因此，开发者频繁提交请求，并对开发者体验下降表达不满。De Paolis 表示：“没有人喜欢被居高临下地告知该做什么。”他指出，安全团队和平台团队经常会陷入这种误区。强制采用很少有效，而围绕共同目标达成一致才真正有效。
一个具体例子是资源标签管理。此前的一次标签推广行动失败，导致资源归属、成本分摊以及治理流程长期处于不一致状态，并且大量依赖人工处理。De Paolis 的团队重新启动了这项工作，并采用了不同的方法：先简化。他们减少了所需标签的数量，并通过 AWS Tag Policies 和 Service Control Policies 对标签进行标准化，验证输入内容并阻止创建未标记资源。同时，他们还使用 AWS Security Hub Resource Tagging Standard 检测已经存在但不符合要求的资源。
通过结合预防、检测和通知机制，团队以更小的影响和更高的参与度引入了标签管理。De Paolis 认为：
先进行通知，然后进行温和的约束，最后才进入更严格的强制执行阶段。这种方式已经被证明可以复用于其他内部合规工作。
其中一个关键经验是保持聚焦。平台团队和安全团队可以做很多事情，但不可能同时完成所有事情。De Paolis 解释说，定义一个最小可行治理模型，并优先处理真正对业务重要的问题，是至关重要的：
如果你有成千上万个安全问题，你需要从某个地方开始。关注那些重要且紧急的问题，但不要忽略那些重要但暂时不紧急的问题，否则它们最终会演变成危机。
分享背景信息和目标也被证明非常关键。当团队理解合规措施与公司成功以及客户信任之间的联系后，他们更愿意支持这些措施，甚至会主动将其纳入自己的路线图。
De Paolis 表示，合规是一段旅程。它需要时间、耐心、共情以及大量沟通。当合规被融入日常工作流程，并被视为共同责任时，效果最好：
透明度、共情以及渐进式推进，与技术本身同样重要。当团队认为合规能够帮助他们在清晰的检测机制和合理的约束下更快、更安全地交付工作时，采用自然会发生。
他总结道，变化过程中总会经历混乱阶段，但最终结果值得付出。
InfoQ 就他们的合规实践之路采访了 Davide de Paolis。
InfoQ：你们如何利用技术策略在组织中实现合规？
Davide De Paolis： 我们将策略视为护栏，而不是手铐。目标是让符合规范的路径成为最简单的选择。我们使用 AWS 原生工具，例如 Service Control Policies、AWS Config、Security Hub 和标签策略，将预期要求直接编码到平台中。
不过，仅靠策略本身并不能创造合规。关键在于如何引入这些策略。我们重视透明度、共同责任，以及围绕“为什么这么做”的清晰沟通。在可能的情况下，我们更倾向于依靠自动化检测和渐进式执行，而不是突然进行强制阻断。结合内部客户思维，这会让合规成为团队自然认同的一部分。
InfoQ：你们采用了什么方式推广标签管理？效果如何？
De Paolis： 最初，我们把标签看作“只是一些元数据”，认为只要定义规则，团队自然会采用。但事实并非如此。只有当标签与开发者关心的结果明确关联时——例如成本可见性、资源归属和责任追踪——它才能真正成功。
我们从一组最小化、明确要求的标签开始，并通过基础设施即代码以及平台默认配置，让标签更容易应用。我们首先关注可见性，让团队知道缺少什么标签，以及为什么这些标签重要。之后，我们才通过策略引入更强的约束。当团队意识到标签是一种赋能工具，而不是官僚流程后，采用率明显提升。
InfoQ：你们如何沟通变化，并与团队协作？
De Paolis： 沟通本身就是平台的一部分。我们会在实施之前解释背景和影响，并提前沟通，避免团队感到意外。
对于较大的项目，我们采用 Tour of Duty 模式，让工程师暂时加入平台团队（或者反过来），从而获得实际反馈，并帮助将相关背景信息带回产品团队。我们还使用 RFC、内部文档以及实时问答会议，并根据反馈持续调整。
最重要的是，我们将变化定义为协作，而不是强制执行。这种转变帮助我们从“平台团队对抗产品团队”的关系，转变为共同承担责任。
原文连接：
https://www.infoq.com/news/2026/07/platform-that-helps-developers/
