Presentation: Road to Compliance: Will Your Internal Users Hate Your Platform Team?

合规之路：您的内部用户会讨厌平台团队吗？- InfoQ

InfoQ 首页 演讲 合规之路：您的内部用户会讨厌平台团队吗？

文化与方法

在线 InfoQ AI 安全与隐私工程认证（8月26日）：在受监管环境中部署AI？

合规之路：您的内部用户会讨厌平台团队吗？

点赞

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

下载

• 演示文稿

40:01

摘要

Davide de Paolis 讨论了在不破坏开发者关系的前提下推进云基础设施合规的现实挑战。他以 Sevdesk 平台团队的实际重启案例为依据，解释了如何在 AWS 上实施“最小可行治理”，利用基于事件的 Slack 警报自动化策略反馈，并从严格强制转向高同理心、数据驱动的协作。

个人简介

Davide de Paolis 是工程经理、AWS 社区建设者、无服务器架构爱好者以及户外运动爱好者。他来自意大利，在二十多岁时通过在新西兰的一次人生转变的间隔年自学了软件工程。拥有20多年科技行业经验，自2013年以来一直居住和工作在德国。

关于会议

InfoQ Dev Summit 慕尼黑软件开发会议聚焦于高级开发团队当前面临的关键软件挑战。从20多位高级软件开发人员那里获得宝贵的实战技术洞察，与演讲者和同行交流，享受社交活动。

INFOQ 活动

• 2026年7月16日，东部时间下午1点 工程的智能时代：如何规范、构建、测试和运营AI驱动系统 演讲者：Juveria Kanodia - Harness 高级工程总监

• 2026年8月6日，东部时间下午1点 构建用于高风险事件响应的AI代理评估 演讲者：Brianne Bujnowski - Datadog AI 高级产品市场经理，Benjamin Barton - Datadog 高级软件工程师

• 2026年8月27日，东部时间下午1点 框架之下：为什么代理上下文是一个基础设施问题 演讲者：Boyd Stowe - Tacnode 创始解决方案架构师

演讲稿

Davide de Paolis：我是 Davide，平台团队的工程经理。我们负责云基础设施和云支出。最近，我们注意到一些令人担忧的趋势和成本上升。为了降低这些成本并提高安全态势，我们制定了一些必须遵循的指南和最佳实践，并要求所有项目在月底前应用这些措施。是的，如果您不进行这些更改，您的部署将会中断。不，我们没有时间与您的项目经理沟通，因为情况紧急。我们知道您有截止日期，我们也有截止日期。合规是公司的目标，我们必须共同面对。请随时升级问题。让我们在这里停止，退后一步。这不是一个好的开端，最终结果将会很糟糕。我是 Davide de Paolis，我在 Sevdesk 担任平台团队的工程经理，也是 AWS 社区建设者。当我不担任平台工程负责人时，我喜欢攀岩和听黑金属音乐。

Sevdesk 平台工程团队（基础工作）

/think

Sevdesk是一家成立于2013年的公司，总部位于奥芬巴赫。我们为中小企业和自由职业者开发会计软件。随着公司像初创企业一样迅速发展，目前我们已组建了约15个团队，涵盖数据、安全、平台和所有核心产品，团队规模约80至90名工程师，其中大部分为远程办公。6年前公司开始扩张时，平台团队负责基础设施的需求变得显而易见，最优秀且有DevOps和云工程背景的开发人员从产品团队中抽调出来，组建了平台工程团队。这个团队雄心勃勃，立即开始制定服务目录路线图，憧憬着构建一个内部开发者平台，并希望成为云卓越中心。当我加入公司时，发现有Confluence页面和大量文档，这给我留下了深刻印象。

存在一个问题。Sevdesk始终是一家云原生公司，从未有过本地部署或本地服务器。我们一直在AWS上使用EC2运行工作负载。该团队引入了EKS和Kubernetes集群，用于生产环境和开发环境，目的是将所有工作负载迁移并构建平台。在所有愿景和雄心壮志背后，他们也对供应商锁定感到非常担忧。尽管使用AWS，但他们并未充分利用AWS提供的服务。在这些集群上，他们开始引入大量第三方工具、服务、库和自研解决方案。使用Keycloak进行访问管理，用Rancher为开发者提供友好的Kubernetes界面，Longhorn用于弹性块存储，Harbor作为镜像仓库。所有这些工具的维护、补丁和更新工作消耗了大量时间，导致团队几乎没有时间专注于平台建设或为各团队开发可复用组件。最终团队因过度劳累而解散。

几个月后，另一个团队重新组建。我加入该团队的目标是重建并壮大团队，制定平台路线图计划。我们希望减轻团队负担。首先，我们升级了架构设置，因为公司规模在扩大，单一账户设置已无法满足需求。我们首先迁移到AWS组织架构，按照环境、团队、域名和部门（如安全、数据、备份等）创建了多账户体系。这样做的原因在于实现数据、基础设施和访问权限的隔离，可以限制对敏感数据的访问权限。如果一个账户遭到入侵，其他账户仍能保持安全。另一个原因是安全控制，可以根据特定应用定制策略，并根据环境进行调整。

你可以对沙盒账户的权限设置得宽松一些，例如允许开发人员随意操作，尝试所有服务。只有在他们通过原型阶段后，才限制访问权限或检查其他所有账户的细粒度权限。配额分配也是原因之一。因为AWS对每个账户上所有工作负载共享的服务和API设置了多项配额和限制，如果你有多个账户，可以降低触达这些限制的风险。然后是成本分配，它允许将可计费项目分开，并将特定成本分配给团队或负责人。这是我们最初引入的基础性工作。

云工程非常困难

随后，我们希望减轻团队负担并利用AWS的优势。我们将Keycloak替换为IAM和单点登录，Longhorn替换为EBS，Harbor替换为ECR，并引入Inspector以实现所有镜像的自动扫描。同时，我们与安全团队合作，部署了Security Hub、AWS Config和GuardDuty。效果非常显著，我们感到非常满意。当然，安全团队也非常高兴，因为所有内容都实现了原生集成。但我们引入了另一个问题。工程师们并不太高兴，因为云工程非常困难，且与软件开发存在显著差异。变更本身就很困难。我们在自己这边进行了所有这些更改，但这些更改需要反映在项目中，体现在项目的配置和开发人员的设置中。开发人员过去习惯于使用一个账户，直接推送至生产环境。现在他们需要在不同账户之间切换，需要将流水线从推送至Harbor改为推送至ECR。

更复杂的是，还需要修改流水线以实现镜像在不同账户之间的推送。我们基本上将大量工作推给了他们。他们还需要学习这些新技能，因为他们之前没有接触过这些内容，也不了解这些服务，必须设法掌握所有这些知识。鉴于之前团队的经验，我们投入了大量精力避免在初始会议中展示的问题。我们编写了文档，通过启动会议与团队沟通，专门建立了Slack频道来解答开发人员的问题。我们反复收到相同的请求，有时还会遇到一些尖锐的评论。"这简直是糟糕的开发人员体验。以前推送至生产环境或随意操作都非常简单，为什么现在要这么做？现在简直令人讨厌。" 我们这边的挫败感也在不断积累，因为必须反复回答这些问题。

我们不得不回应所有这些评论。我们一直在思考，为什么开发人员就是不明白。为什么他们不直接阅读文档？我们有文档，而且有很多。为什么他们还要不断提问？你无法看到这些内容，因为这当然属于内部文档，但你可以看到它的长度。这是来自我们Confluence页面关于标签策略的一个例子。非常长，过于详细，我认为也相当枯燥。更糟糕的是，许多地方已经过时。即使开发人员阅读了文档，他们也很可能仍然搞错。让我们以这个标签策略为例，讨论内部合规举措，以及我们如何在有或没有摩擦的情况下推进这些举措。对资源进行标签化其实并不复杂。这不过是一组标签，键值对，你只需定义所有者或服务的关键性、服务名称和一组值。例如，通过这份文档，如果我们记录了这些值，人们仍然可能拼写错误或选择不存在的值，因为这仅仅是一份文档。让我们以此为例，展示如何无摩擦地推进内部合规。

鼓励和加速变革（AWS的支持）

问题是，我们如何最有效地鼓励和加速变革，AWS又如何支持我们？需要考虑两方面，而这都与我们作为人类的特性有关。没有人喜欢被居高临下地对待，也没有人喜欢被告诉该怎么做。这正是安全团队和平台团队经常做的事情。平台团队远离一线，他们不受产品压力的影响。然而，他们有时会进入团队并说：“从明天起，你们不能再这么做，必须这样做。你们必须遵循我们的指南。我们知道事情应该如何处理。”当然，人们对此反应并不好。另一个问题是，这些变革非常困难。这就像改变生活方式，比如节食或锻炼。如果你被迫去做，很可能会失败。当然，我们谈论的是企业环境，有时我们必须做必须做的事，但仍然让员工参与进来，让他们分享共同的目标，这对成功至关重要。

我们如何加速变革，AWS又如何支持我们？AWS有许多原生集成的工具，使我们能够检查资源、通知人员，并在需要时强制执行合规措施。好消息是，这些机制是分开的。你可以先进行一轮通知，之后才开始严格实施。

我之前提到的AWS组织，是我们公司设立技术政策时最早引入的变更之一。技术政策非常简单，它只是一组标签和键的配置。在这里你看到的是Sevdesk所有者。这是我们真正关心的，理解服务的所有权，因为我们经历了许多转型、许多重组和一些工作负载。作为平台，我们甚至不知道谁在维护这些工作负载。Sevdesk所有者就是一个例子，对应的值是cloudcrew（我的团队）、team-a、team-b、orphaned（无主），原因就是如此。有些工作负载我们甚至完全不知道，它们根本没有所有者。我们希望在成本和事件方面进行监控，以便在需要时引起管理层的注意。这非常简单，你只需定义键和接受的值。

这并不会阻止你继续在没有标签的情况下进行部署。你可以部署。我无法使用不同的团队名称进行部署，但可以在没有标签的情况下部署。为了防止这种情况，我们有服务控制策略。服务控制策略是防止不当操作的防护措施。在我们的情况下，如果条件未满足（例如没有Sevdesk所有者），我们将拒绝创建集群、创建Lambda函数、创建数据库等操作。如你所见，配置相对简单，但也很繁琐，因为你必须非常细致地指定所有受影响的资源和具体操作。你需要说明，这项策略影响Lambda，包括创建函数、删除函数等操作。

需要强制执行什么？

我们开始构建这项服务控制策略，并通过小规模迭代逐步部署，直到发现策略存在长度限制（5000个字符）。是的，这不算大问题。我们将把策略拆分为多个策略，这甚至可能是个好主意，因为我们可以将一个策略专门用于我们维护的基础资源（这些资源变化不大），而另一个策略用于各团队部署的所有应用程序。也许我们还可以单独创建一个策略用于无服务器架构，这是我们使用但频率不高的功能。拆分策略很简单。不，因为账户和组织单元还存在服务控制策略数量的限制。这成为了一个问题。此外，不同服务之间还存在细微差异。某些服务没有标签功能。

一些服务使用请求标签，另一些使用资源标签。这确实非常耗时。于是我们停止了，决定改变策略，专注于重点对象。我们希望仅对成本贡献最大的服务实施合规性控制，也就是那些我们花费较多且使用频率最高的服务。我们不关心Elastic Beanstalk或任何我们不再使用的旧应用或服务。为了实现这一点，我们使用了一个名为Steampipe的工具，这是一个非常实用的小工具，允许通过SQL查询访问AWS API或其他任何云提供商的资源。如果现在重做，我可能会探索其他方法，比如使用Amazon Q和一些可用的MCP服务器，但当时Steampipe已经很好地完成了任务。我们明确了需要关注的重点，以满足合规性要求。接下来我们需要找出如何监控所有其他资源。

通知与强制执行

我们已经有了自己的策略，一个更简化的策略，并且已经准备好部署了。但让我们稍等一下，因为之前的团队在该策略上失败了。之前的举措在沟通方面仍然存在问题。当我们宣布想要重新制定并复兴标签策略时，我们表示这一次会有所不同。我们不会简单地推出一个会破坏一切的变更。我们希望与你们合作，希望让你们参与规划。我们会妥善通知你们。我们不确定是否能够兑现这个承诺，因为我们知道，随着服务控制策略的部署，部署过程可能会出现故障，但我们不知道这会带来多大的问题。我们不知道有多少资源不符合规范。了解这些信息、通知团队并制定计划是我们的责任。幸运的是，就在那时，AWS公开发布了资源标签标准，这是在Security Hub之上添加的另一种控制方式。

我们已经在使用Security Hub，安全团队也已经激活了基础基准和基础安全措施。我们只需添加标签标准，定义我们想要监控的标签。对于我们来说，关键的标签是所有者、服务、用户数据、重要性、保密性，而不是原始Confluence页面中列出的25到30个标签。那些标签是无关紧要的。这才是我们真正想要的。我们激活了标签标准，让Security Hub运行了一天。第二天，有多少资源不符合规范？很多，远远超出预期。这是一个令人不快的惊喜。更糟糕的是，这些不符合规范的资源中有很多是我们自己的。我的团队负责这些资源，因为作为平台团队，我们拥有大量集群、实例、角色、权限、安全组等，而所有这些都没有标签。显然，我们没有贸然推出这个策略是正确的，否则我们会遇到问题，更重要的是，这不会是一个好的示范。平台团队应该以身作则，告诉人们这是正确的方式，如果有人不遵守，那就需要委婉地指出。

现在我们知道了有多少资源不符合规范。我们如何通知团队？我们希望分析数据，然后通知团队，让他们规划如何为自己的资源添加标签。我们提出了两个想法。第一，每周发布关于遗留非合规资源的报告。我们知道所有未标记的资源，并分析它们，将它们分配给团队。然后通过Slack通知每个团队：“你们有X数量的资源未标记，请处理。” 第二周，我们可以说：“谢谢，你们正在改进，或者请再加把劲，计划一些相关工作。” 第二个想法是，一旦资源未被创建时就通过Slack发送警告，因为我们没有部署标签策略。团队确实可以继续部署没有标签的资源，但我们希望及时发现这一点。不幸的是，被安全应用捕获的资源数量如此之多，以至于最初很难从中找到有用的信息。

由于 AWS 在每次部署时会在后台部署其他资源，因此产生了大量噪音，资源数量实在太多。即使团队每天改进一两个资源，这种改进在整体占比中也几乎微不足道。我们提出，只需要一个脚本来解析所有信息，过滤噪音，清理数据，然后发送通知即可。

这看起来应该很容易？当然不是，因为主要问题之一是大多数资源都没有标签，也没有标明所有者。如果没有所有者信息，我们如何知道该通知谁？你可能会想到 AWS 自动添加到每个资源的“created by”标签。确实如此，它确实有效。但首先，这个标签属于个人，而不是团队或部门。其次，它仅在你从自己的机器或控制台使用自己的账户部署时才有效，而这正是我们不应该做的事情。如果你使用基础设施即代码（IaC）或使用流水线，你会发现“created by”标签实际上会是 GitHub runner 所假设的角色，这几乎没有实际用途。考虑到标签不一致、所有者信息缺失，我们需要从其他来源如 CloudTrail 或 CI/CD 系统中获取信息，最终我们决定依赖所有这些资源，脚本也因此变得更为复杂。

最终，我们提出了这个解决方案。我们利用 AWS Config（这是我们之前与 Security Hub 一起部署的功能），用于检测资源创建、修改或配置变更时的事件。通过这个过滤器，我们检查资源是否包含所有者标签。如果没有，EventBridge 会触发 Lambda 函数。Lambda 处理事件以确保信息可用。如果信息不可用，我们会检查流水线，因为部署遵循了流水线工作流。我们查看流水线，确定流水线仓库的所有者，从而推断出负责管理该资源的团队。所有信息被推送到队列中，队列触发另一个 Lambda 函数来聚合事件。然后，我们可以将这些事件推送到 AWS Chatbot（现已更名为 Amazon Q），即使这个服务与 AI 代码助手毫无关联。

接着，我们将信息推送至 Slack。为什么中间需要一个队列？想象一下每次部署，比如部署一个应用、Lambda、API Gateway、DynamoDB 和 S3，这涉及四个资源。我们不希望为每个资源加上 IAM 角色权限信息，发送四条消息，更不想发送六条消息来打扰用户。这就是为什么需要中间队列。通过队列，我们可以生成 Slack 通知，并立即追踪那些未添加标签的部署者，因为我们已经通知过大家正在制定标签策略，希望他们及时做出更改。如果他们没有更改，我们就能立即抓住他们。第二个脚本用于生成报告，原理类似，仍然依赖 EventBridge。这次 EventBridge 只是一个定时任务，每周触发一次 Lambda 函数。Lambda 从 Security Hub 获取数据。

然后它基本上执行相同的操作，检查值是否存在，如果不存在则从 GitHub 获取，接着将它们推送到报告生成器。报告生成器会将统计数据保存到 DynamoDB，与上周的数据进行对比，然后向团队发送信息，内容大致是：“非常感谢你们，你们真的在为我们的成功、为标签计划的成功做出贡献。”或者反过来：“真丢脸，你们没有尽到自己的责任。请立即改正。否则，三个月、六个月后，我们将真的开始强制执行，到时候问题就完全由你们负责了，因为我们已经尽了自己的一份力，我们已经尽力了。”

重复这一过程

有了这个机制，我们就能持续获得信息流和数据，这些数据帮助我们了解当前的进展、发现缺失的部分，并明确谁需要为此规划工作。这项计划的好处在于，如我之前所说，标签策略非常简单，但这一过程——告知、温和强制执行，再到正式强制执行——可以应用于任何内部合规计划。重复这一过程，或许只需调整脚本，但核心概念依然适用，适用于任何规模的公司。

如何实现清晰

这一切如何帮助我们，又如何帮助你？几年前之前团队失败的最大原因在于，公司发展速度过快，突然间他们感受到必须解决所有问题并实现内部合规的巨大压力。在短时间内试图解决太多问题，却只投入了有限的资源。他们让自己陷入供应商锁定的困境，但在我看来，这完全是另一回事。最重要的是，他们失去了对目标的专注，也失去了对人员的重视。出现了脱节，这正是导致挫败感和摩擦的根源。如何避免这种情况？产品团队、安全团队、平台团队可以做很多事情，但无法做所有事情。非常重要的一点是，开始定义一个最小可行的治理框架，明确当前对公司真正重要的事项，并专注于这些目标。

你无法解决所有问题。如果你在 Security Hub 中看到有 12,000 个安全漏洞，就必须从某个地方开始，建立优先级。依赖紧迫性、重要性、影响和工作量的指标至关重要。专注于那些既重要又紧迫的事项。在我看来，同样重要的是关注那些重要但不紧迫的事项，以免它们变成紧迫的问题。否则，你将始终处于被动应对问题的状态，而非主动解决问题。影响和工作量，我真的很讨厌“低垂的果实”这个说法，但事实确实如此。有些事情只需付出很少的努力，就能带来巨大的影响。专注于这些事项。分享目标和目的。改变是困难的。理解我们为什么要做这些事，或者为什么我们要对他人施加某些要求，以使事情更容易，这非常重要。因此，分享目标和目的至关重要。

如果人们理解这实际上是公司目标，而不是因为写在网站或内部文档中，而是因为这对成功至关重要，让客户知道我们有相关流程并正在遵循这些流程，他们就更有可能支持这些举措或将其纳入自己的路线图。接下来是迭代。基于反馈和变化的优先级进行小范围迭代。制定路线图非常重要，但平台团队的路线图通常包含任意的截止日期。我们决定要在12月之前完成所有资源的标签化。当然，我们不希望在季度末无法实现自己的目标。但同时，我们也不希望影响整个公司或阻塞部署，导致所有团队都抱怨无法进行下一次发布。理解这一点后，根据你拥有的数据做出数据驱动的决策，你会发现，我们原本希望在12月前完成，但仍有50%的资源未被标记。

这样做显然没有意义。你可以升级问题，可以邀请管理层对团队施加更多压力，但你仍然需要调整优先级。仅仅为了强行推进一切而造成混乱显然是不合理的。然后，转变沟通方式和工作方法。我们已经改变了沟通方式，主动向团队传达这些信息。我们通过Confluence、DevOps专家和定期会议，以更开放的方式进行沟通，面对面回答问题。我们引入了“职责之旅”或“嵌入式专家”机制。基本上，我们安排一名团队成员进入不同团队，协助他们，解释我们正在做的事情，说明我们如何执行工作，解释变更内容。有时甚至会为他们完成基础工作，以确保取得进展，然后他们就会看到我们是来帮助他们的。在一次演讲中提到，DevOps的思维是“你构建它，你运行它”，但我们的立场是：我们在这里支持你。你并不孤单。我很喜欢这句话。这基本上就是我们应该做的。将责任交还给他们，因为他们要为自己的项目负责，但作为平台团队，我们可以支持他们。我们应该支持他们。改变沟通方式和协作方式至关重要。

合规是一项旅程

合规是一项旅程，需要很长时间。它不会一夜之间实现，所需时间往往超出预期。为了实现所有目标，你需要识别快速胜利，建立势头。否则，我们会看到这样的情况：你一开始对新战略、新举措充满热情，与所有团队召开会议，完成全员培训，但随后出现其他优先事项。团队重组后，没人再谈论标签策略。这时你被迫改变优先级和截止日期，但不是因为真的出现了问题，只是因为人们稍微与问题脱节了。保持高势头，持续迭代，保持耐心，因为这需要很长时间。这需要大量沟通。人们可能会感到沮丧，你需要妥善处理。如果记住这一点，双方保持耐心和同理心，这将真正帮助你实现目标。改变初期可能显得混乱，但最终会变得美好。

参与者 1：从与开发者的交互角度来看，平台的用户体验方面，你们是否考虑过使用现成的组件（如 Backstage 或某种类型的 IDP）来提供这些洞察，还是出于其他原因选择自行开发？

Davide de Paolis：我们并没有选择自行开发。我们评估过 Backstage，但尚未做出决定。经过与团队、首席架构师和 CTO 的讨论后，我们认为现在引入 Backstage 这类解决方案还为时过早。目前，我们希望从标签策略入手，逐步修复一些安全漏洞。这与合规性无关，更多是因为我们作为平台需要将工作负载从旧账户迁移到基于 EKS 的新架构，并帮助团队拆分单体应用。我们通过提供 Terraform 支持和创建模块来协助他们。如果此时引入 Backstage 这类工具，会显著延缓我们的进度。不过，这确实是我们未来计划的一部分。随着团队规模扩大，我们一定会推进相关工作。

参与者 2：我的问题是，如果你们自身因某些法规（如欧盟法规）需要满足截止期限，而这些法规影响合规性时，你们如何平衡产品截止期限？又如何与团队沟通？

Davide de Paolis：如果我有截止期限？

参与者 2：欧盟方面有关合规性、安全性和风险等方面的法规正在逐步出台，这些法规的截止期限非常紧迫，因为一旦违反就会面临严重后果。

Davide de Paolis：在刚才的例子中，我指的是内部合规和内部治理。如果是审计和监管合规，那就是另一回事了。在那种情况下，必须明确告知团队没有其他选择。我们曾遇到过类似情况，比如使用会计软件时，公司会定期接受审计，这些审计会获得全公司的高度关注。在这些情况下，其他部门（如法律、财务、安全）也会施加更多推动。通常，平台需要向所有团队传达“必须修复”的要求。对于监管合规，通常有多个部门共同推动：法律、财务、安全等。我并不是说这更容易，但你们会获得更多支持和明确的授权。

查看更多带文字稿的演讲

录制时间：

2026 年 7 月 13 日

由

• Davide de Paolis

#### 相关赞助商

• 设计容错：如何在云中断期间保证数据访问

#### 相关赞助商

为您的备份、数据湖和 AI 提供智能云基础设施。来自 SoFi、Red Bull 和 Structured Web 的团队使用 Eon 来简化备份、大幅缩短恢复时间，并将数据转化为实时可搜索的资产，同时将备份成本降低高达 50%。立即了解更多信息 >

#### 本内容属于“文化与方法”主题

##### 相关主题：

• 文化与方法

• InfoQ Dev Summit 慕尼黑 2025

• 平台工程

• InfoQ Dev Summit

• 协作

• 文字稿

• 团队合作

• QCon 软件开发会议

• DevOps

• InfoQ

• 敏捷开发

• 相关编辑

• InfoQ Slack 上广受欢迎 基于代理的端到端测试提升 UI 自动化测试的韧性 Node.js 26：默认启用 Temporal API，V8 14.6 升级及一系列弃用警告 Java 新闻速递：严格字段初始化、GlassFish、GraalVM、JReleaser 和 RefactorFirst WordPress 7.0 发布：核心功能引入 AI 基础架构，全新现代化管理界面与设计工具 AWS 扩展 DevOps Agent：通过 AI 驱动的发布管理在生产环境前验证代码 人工智能驱动的未来：为每位工程师提供形式化方法