Adidas 拥抱云原生和 AI，通过微服务迁移和平台工程提速。GenAI 试点显示 GitHub Copilot 提升 20% 效率，但架构和 DevOps 成熟度至关重要。关注价值流优化，可视化架构，用 Wardley Mapping 管理 300+ 微服务，实现业务增长。
译自：How Adidas Drives Engineering Success, Including With GenAI
作者：Jennifer Riggins
“你不会被工具或 AI 取代。你会被使用 AI 的人取代。”
作为 Adidas 数字和电子商务高级副总裁，Fernando Cornago 了解到，你不能等到一项技术被证明有效才去使用它。毕竟，像大多数实体店一样，这家顶级运动鞋品牌受到了 COVID-19 大流行的重创。
“我们不知道我们的消费者会在几个月后从哪里购买，”Cornago 在企业技术领导力峰会上反思道。但他确信技术将是解决方案的重要组成部分，就像过去四年让 Adidas 重回正轨一样。如今，数字销售额占收入的 20% 以上，并由一半的员工提供支持。
从云和微服务迁移到平台工程战略，再到现在的生成式 AI，Cornago 的团队确保 Adidas 始终是早期采用者——因此业务速度、流程和技术不会落后。在去年 9 月和今年 2 月的 ETLS 上，Cornago 都透露了 Adidas 对可衡量的 DevOps 转型和实验的承诺如何使他们能够与 500 名工程师及更多人一起试用生成式 AI。
早在 2021 年，Adidas 拥有 1,400 名工程师在网上商店工作。在全球零售业的艰难时期，这家德国运动服装公司决定削减几乎所有外部咨询公司，将工程团队减半，以专注于培养内部开发人员。
现在零售业已经恢复，数字分销商的销售额仍在以每年 10% 的速度增长，去年通过在线销售额实现了 50 亿美元的收入（总收入为 240 亿美元），覆盖了 80 多个国家/地区，每年为 10 亿消费者提供服务。在约一半的员工的支持下，他们的行动速度更快，每年发布 4,000 个版本，从想法到价值的实现速度提高了五倍。
可靠性也在提高，发布成功率达到 99%。正如 The New Stack 之前报道的那样，在 Adidas，稳定性定义为：
- 平均检测时间 (MTTD)。
- 平均恢复时间 (MTTR)。
- 收入影响。
因此，工程部门不衡量停机时间，而是衡量每秒损失的业务，2024 年因系统中断造成的净销售额损失仅为 0.18%。
Cornago 甚至更好地诠释了行业最喜欢的术语 10 倍工程，他说：“在我们的新架构中，每增长 10% 的销售额只会导致软件和运营成本增长 1% 到 2%，因此我们是为未来而构建的。”
Cornago 提供了六个经验，这些经验有助于实现这种可衡量的成功，并推动 Adidas 数字创新的下一阶段。
1. 快速转型。
他说：“我们需要我们的技术在区域和特殊时刻都能扩展。我们面向消费者，因此我们需要保持快速。”
Adidas 是首批连接到中国 TikTok API 的公司之一，该 API 很快占该市场收入的 30%。
2. 渠道打开大门。
Adidas 工程战略强调一种可组合的架构，该架构允许连接的生态系统利用许多渠道，而无需重新发明轮子。虽然 TikTok 在中国是一个非常成功的渠道，但在欧洲根本不是。但是，通过重用组件在新市场进行实验，可以减少在测试新渠道上浪费的工程时间。
事实上，自 2020 年以来，该公司已削减了 27% 的软件成本，同时发布率翻了两番。
“我不想和我们的工程师谈论效率，”Cornago 说。“我想谈谈如何最大限度地提高构建价值，而不是运行成本。”
他继续说，这项战略还将使 Adidas 能够采取下一步措施，使生态系统更加智能，因为不可能手动与 10 亿消费者建立联系。可组合架构也是公司通过数据和 AI 进行定位和个性化的重要组成部分。
3. 平台作为基础。
Adidas 被组织成平台域，包括基础设施、数据和平台工程团队本身。它也是平台即产品思维模式以及产品即平台思维模式的早期采用者，其中数据被视为产品。考虑到这一点，黄金路径的布局方式可以加快大多数团队的速度，并且仍然是可选的。
4. 价值流优化。
Cornago 将他的工程组织描述为“痴迷于最大化价值”——在消费者旅程的各个阶段，他们花了六年多的时间专注于价值流优化。
他说：“这是获得清晰的业务 KPI 的更简单方法，了解我们如何将消费者引入平台，将他们转变为会员，如何将他们与内容、产品（他们想要的东西）对齐，我们如何[处理]购买，我们如何交付产品，以及我们如何为他们提供最佳的客户服务。”
去年，从高层到下层都在进行价值流优化，包括容量分配的流量分配。他解释说：“将团队削减一半会迫使你做出选择，而且你不想在数据隐私等问题上削减太多。”
他们如何衡量流量？他说，在使用了这么多工具之后，他们回到了基础——衡量每个步骤完成任务所需的时间。并要求管理者根据数据分享每个季度三个目标。
5. 可视化架构
正如大多数企业面临的问题一样，Adidas 努力绘制其 300 多个微服务的分布图，以便为不同的市场实现那些渠道优先、即插即用的功能。
Cornago 的团队结合了 Wardley Mapping 和内部开发者门户，开发了一种用于可视化的“与业务的通用语言”，他们称之为 Capability Diamond。这种实践让工程部门对它拥有的每个可重用组件进行编目。然后，他的团队将这些组件组合成打包的业务能力，这些能力带有 API 和事件流，并位于可选的用户界面之后。
6. 拥抱变化
Adidas 是生成式 AI 的早期采用者，就像它之前采用平台工程和 DevOps 一样。为了为下一个重大的技术转变做好准备，Cornago 说，这需要一种拥抱实验和变革的文化。
“在 Adidas，它正在改变一切，”Cornago 谈到生成式 AI 时说。“在客户服务、支持、内容，当然还有工程方面。”
在 2024 年第一季度，Adidas 在 500 名工程师中推出了 GitHub Copilot AI 编码助手试点。即使在相对较短的三个月试用期内，对工程效率的影响也很明显。
当 Copilot 可用时：
- 65% 的工程师更快地完成了重复性任务。
- 61% 的工程师更快地完成了任何任务。
与所有开发者生产力计划一样，采用率是一项重要的衡量标准：
- 82% 的人使用 Copilot 进行日常编码工作，使用熟悉的语言。
- 59% 的人使用 Copilot 创建使用熟悉语言的重复代码。
- 62% 的人使用 Copilot 编写使用熟悉语言的测试。
Adidas 的 Copilot 试点中，高达 91% 的开发者表示他们觉得它很有用，并且不想在没有它的情况下工作，其中：
- 79% 的人使用 Copilot 创建新代码。
- 62% 的人使用它来更改现有代码。
- 61% 的人发现它在编写代码文档时很有用。
Cornago 说：“他们确实一致地报告说，他们的技能提高了 20% 到 25%。”“他们更快地实现了他们想要做的事情，无论是代码的更改、新例程的创建、新算法还是新功能。”
总的来说，大约三分之二的参与者使用 Copilot 创建的拉取请求比前一个季度没有使用 Copilot 时更多。最终，这转化为工程师报告说，他们在编码和测试方面的时间总体提高了 15% 到 20%。
Cornago 说：“你不可能把一个工具强加给我们的工程师。”“他们会找到一种不使用它的方法，而且它永远不会奏效。”
他绝不是在争辩说所有的 GenAI 都是万能药。在没有透露他们在 Copilot 之前尝试过哪种 GenAI 工具的情况下，他确实将其描述为一场灾难，90% 的开发者回应说他们是在浪费时间进行故障排除。
尽管如此，在最初的试点六个月后，大约 700 名 Adidas 开发者（约占工程组织的 85%）现在每天都在使用 GitHub Copilot。
无论你阅读哪份报告，开发者通常只有不到 30% 的时间用于编码和测试，这解释了为什么 GenAI 的胜利只带来了适度的整体生产力提升（即使编码方面的提升很显著）。
任何生成式 AI 开发者生产力策略都必须考察的不仅仅是这些活动。它必须考虑发现、分析、文档编写以及开发者生命周期的其他重要方面。Adidas 将花费在编码和测试上的时间称为 IDE 内时间 (Time in IDE)。与仅关注编码和测试优先级的 麦肯锡开发者生产力框架 不同，Adidas 正在尝试将开发者体验衡量为键盘操作时间 (Time on Keyboard)，其中包括 IDE 内时间和其他活动。Cornago 澄清说，键盘操作时间不包括团队仪式、会议和培训。
Adidas 花费了一个月的时间来跟踪七个团队（每个团队 10 名工程师）在四个不同领域、成熟度和技术堆栈上的“键盘操作时间”或“价值时间”。
“不仅仅是编码，还包括分析、设计、文档编写。这是开发者或工程师受雇所做的所有工作。这是他们喜欢的事情。当他们茁壮成长时，这就是他们正在做的事情，”Cornago 进一步定义了键盘操作时间。
“剩下的就是故障排除、处理与业务的错位、讨论角色和职责、试图找到不同文档之间问题的根本原因以及请求系统访问权限。所有这些浪费——‘烦人的时间’。”
Adidas 发现，其编码和测试时间占开发者时间的 36%，这让其他行业基准相形见绌。对此，他回应说：“我仍然认为这太低了。我对结果不太满意。”
然而，由于 Adidas 的键盘操作时间从 2018 年的 47% 转移到 2024 年的 65%，Cornago 说：“这个数字让我更自豪。”
当对开发者生产力进行分解检查时，Cornago 称之为高效、高产团队（他们每天超过 80% 的时间都花在“价值”时间上）与其他团队（不到一半）之间存在明显差异。
“与团队的资历、DevOps 旅程的成熟程度以及他们使用的技术的松散耦合和开放程度有非常明显的关联，”他说。根据该公司的季度调查，表现出色的团队也感觉与公司愿景的联系更加紧密。对于那些表现更好的团队来说，生成式 AI 的价值是呈指数级增长的，他说，不仅在代码和测试生成方面，而且在其在集成开发者环境中的集成方面，告诉他们该怎么做。
Cornago 说：“但老实说，如果你看看那些表现不佳的团队，他们表现不佳是因为我们不希望他们表现出色。”
IT Revolution 的创始人 Gene Kim 主持了这两次活动，他评论说，当您发现团队之间存在这种差异时，架构通常是区分因素：“我们知道，架构可以通过团队在不需要沟通、协调的情况下完成他们需要做的事情的程度来衡量，达到他们行动独立性的程度。”
Cornago 证实，这确实是造成这种差异的关键原因，有时也是队友的资历，包括团队在关键 DevOps 指标上的成熟程度，这些指标与架构相关。具体来说，他说这归结为架构如何支持 DevOps 实践，包括发布周期时间、发布数量、平均发布时间和平均恢复时间。
重要的是要强调他在整个会议中使用的语言。他绝不责怪这些团队，而是责怪他自己的团队为他们提供的系统、工具和流程。
“这不是工程师的错，”Cornago 说。“让我们明确一点，这是我们公司做出的决定，因为通常这些工程师在代码的某些部分工作，这是我们架构的一些单体组件，我们决定——由于规模经济，由于效率——不创建花哨的微服务来做到这一点。”
他继续以 Adidas 的全渠道中心订单管理系统为例，该系统将所有数字体验（包括应用程序、电子商务和营销）与物理世界分开，其中包括大约每六个月才接触一次的架构组件。像这样的系统不需要持续部署或微服务现代化。
“你越接近 ERP 或公司的核心流程，就越困难，”Cornago 说。“这很复杂，因为我们决定变得复杂。”
“我们不打算解雇任何 ERP 工程师。我们不会因为他们花费在编码上的时间而责怪他们，”他继续说道，“因为很明显，他们每次接触某些东西时，同一行代码可能会影响我们两到三个核心流程，例如财务对账、库存位置、补货。”
在急于采用生成式 AI 和其他闪亮的新技术时，不能忽视依赖于核心业务流程的受众。
Cornago说：“他们有时在封闭的生态系统中工作，不同的合作伙伴在采用GenAI方面处于不同的状态。并非所有人都将其API、代码库或IDE开放，以便自然或顺畅地使用GenAI。”
专注于AI生成的代码也无关紧要，因为这只占这些工程师花费时间的不到15%。他说，更重要的是，他的团队专注于改善他们的环境和组织流程。
最后，Cornago说：“拥抱变化，并改进我们的工作方式，比GenAI更有影响力。”