【AICon】 如何构建高效的 RAG 系统?RAG 技术在实际应用中遇到的挑战及应对策略?>>> 了解详情
写点什么

通用电气在平台工程上浪费 70 亿美元的教训

  • 2023-05-22
    北京
  • 本文字数:4740 字

    阅读完需:约 16 分钟

通用电气在平台工程上浪费70亿美元的教训

相关阅读:

一个价值 70 亿美元的教训!如何避免平台工程变成“大灾难”?

云原生趋势下的平台工程


想象一下某位大牛深入研究并实践平台工程,最后还失败了,后果会是怎样的呢?Steve Pereira 在这篇文章中总结了通用电气一个价值 70 亿美元的失败给我们带来的教训。

 

提到软件工程,我们经常讨论的是组织应该做哪些正确的事情——比如引入自服务、流或打造对齐流的团队,等等。但人们常常会忽视那些我们本来应该避免的事情。经常会有团队在做了正确的事情的同时还有很多错误的行为。怎么会这样呢?!

 

其实这种情况比你想的还容易出现!

 

今天我想分享一个案例,告诉大家组织在构建内部或行业平台——或任何大型系统时有哪些事情是不应该做的。案例中的这家公司做对了很多,结果还是跑偏了!这也是一个理想的研究案例,说明了为什么只凭良好的意愿、令人信服的愿景和大量资源是不足以取得成功的。糟糕的系统总能打败有能力的人员,如果我们不能找出所有要点并把它们全部打通,即便是小山一样的现金也会被挥霍一空的。

 

产出的结果是正面还是负面取决于做事的方式。做正确的事的效果比不上以正确的方式行事。Predix 案例就是一个很好的例子。

Predix 案例

Predix 是一个面向工业互联网的平台即服务。它聚合了来自各种传感器、IoT 设备和工厂设备的数据,为分析需求和多种应用程序提供支持。它的云服务是在 AWS 上构建的,并支持本地部署。

 

Predix 平台由世界上最大的公司之一——通用电气(GE)掌舵。有了这样的强力后台,你可能会认为这家公司的平台开发之旅会很顺利。不幸的是,事实并非如此。

设定远大的期望

当 GE 宣布 Predix 项目时,其诱人的承诺仿佛在业界投下了一颗重磅炸弹——它的目标是提供简单的物联网部署、基于状态的监控以及用于流式处理和批处理分析的统一平台。整个项目建立在 Cloud Foundry 之上并使用了企业级技术,这一切仿佛都注定了它会卓尔不凡。

为了了解项目的来龙去脉,我们先来看看项目是怎么启动的。GE Digital 的做法和我眼中当时硅谷的最佳理念是一致的,他们引进了《精益创业》一书的作者 Eric Ries。他们非常关注快速交付和部署之类的领域,同时遵守了一系列良好的技术实践。

 

与 Ries 的合作还帮助 GE 创建了自己的开发流程,称为 FastWorks。你可以将其视为混合了精益创业元素的经典精益思想的变体。

 

正如观察人士当时所指出的那样,GE 的方法论转型并非易事。该公司一直高度依赖六西格玛方法,意味着转型需要大量的培训工作,会带来巨大的企业文化变革。

 

为什么要开始如此漫长的旅程呢?Predix 可能只是一个激励因素——GE 希望充实其基础设施即服务和平台即服务产品,但它也希望能构建一个完整的数字生态系统来支持它们。他们看到了软件正在吞噬世界,并希望成为其中的一部分,而不仅仅是随波逐流。

 

他们的努力深入到了各个角落。他们甚至建立了自己的数据中心来打造端到端的价值链。建造一个数据中心并不是精益创业的典型实践——这是一笔巨大的开支,大多数公司都不想做这种尝试,但我们可以先给 GE 一点信心。毕竟这是一家大公司,所以也许这些计划并不算太过头。

 

问题是建设数据中心只是项目的要求之一。该公司还必须实现各种按需打造的基础设施流水线、应用程序脚手架、模板之类的特性,还要部署大量硬件、网络和各种各样的应用程序,其设计都是为了同一个目标:流畅的物联网开发体验。

这个问题涉及的领域太多了,所以对平台提出了更高的要求。例如,在开发物联网生态系统时,企业通常会开发各种定制硬件产品、用于性能监控的数字孪生系统以及支持自定义应用程序的各类工具。换句话说,物联网是一片广阔的天地——GE 需要全方位的分析能力,包括来自其工厂、客户设施、传感器原型流水线、监控信标和其他各种来源都需要集成到分析能力中。

 

你可能会觉得用一个平台来搞定这么多事情听起来负担太重了。你是对的,但他们要做的还不止这些。GE 还想出了一个好主意,就是创建一个市场,在里面向开发人员销售平台的各种产品,市场还支持合作伙伴根据白标条款转售自己的产品。与亚马逊一样,他们希望内部开发的工具链最终成为一个面向公众的平台。这听起来不错,但这样的市场并不是凭空冒出来的。

残酷的现实开始发力

我想说的是,当你开始创造任何东西时,首先要记住的是,创造它可能是你做出的最糟糕的决定。在开始创作之前,你需要克服许多障碍,因为几乎可以肯定没有人会关心你所创作的内容——除非你竭尽全力来激发别人的兴趣。

 

同样重要的是要记住,大多数数字化转型努力都会失败。无论我们是在谈论项目本身、投入数字化转型的资金和努力,还是对数字工作流、环境和平台的文化适应,这些努力往往都失败了,因为它们迫使组织冒险进入他们尚未探索的领域。

 

通用电气是否在某种程度上忘记了这些规则呢?其实情况更像是他们从一开始就没正经遵守这些规则。

 

通用电气是一家非常实体化的企业:它牢牢地扎根于实体世界,一直都是传统的工业制造企业,很少探索数字领域。

 

数字世界对这家公司来说是一个非常新的领域。因此,通用电气第一次就把所有事情都做好的可能性很小,特别是它似乎很依赖“只要你做出产品就会有人用”这种经常被现实否定的方法。

一个失败平台的时间线

我第一次听说这个项目是在 2015 年的 DevOps 企业峰会上。GE 的团队上台公开宣布他们打算建立一个平台并从错误中吸取教训——这是一个很好的开始,能让人知道事情在向哪个方向前进,也让他们赢得了信任。

快进到 2016 年,GE 的信心依然高涨。该公司甚至公开预测,到 2020 年,他们在这个项目上的努力将带来 150 亿美元的收入。

 

那么到 2020 年情况如何?考虑到他们的营收比上面这个数字少了大约 140 亿美元,说他们收入预测未达到目标并不夸张!

 

至此,该公司已经在顾问、营销、合作伙伴等方面花费了超过 70 亿美元。雪上加霜的是,通用电气的竞争对手并没有坐等该公司采取行动,建立平台。在我的研究中,我发现至少有 25 家物联网云平台供应商已经在 GE 本可以完全主导的领域中留下了清晰的足迹。

值得一提的是,通用电气采取了很多本应奏效的举措。不幸的是,这个故事中善意的开头却往往通向错误的结果。

大目标与次优实现

我首先注意到的一件事情是 GE 的愿景所针对的领域。他们清楚地传达了他们想做的事情,并且他们假设为工业互联网打造的云会找到一个受欢迎的市场,这并没有错。在我看来,问题在于这个愿景和目标与 GE 本身不一致。

 

GE 犯的错误可能是从“孤立”的角度看待其数字化进程——将其平台视为一个独立的实体,而不是整个公司业务的基础。该公司从未做出根本改变,从文化层面认可自己开发的平台,并开始用开发人员应有的方式行事。

 

这就像是普通人给自己定了一个减肥目标,但之后每天还在吃快餐——你的愿景与你过去的行为记录和当前的实践是不一致的。

 

这种差异还导致了一些重大的组织冲突,主要是很多良好的平台开发实践的思维方式与 GE 传统的精益制造风格之间的冲突。该公司还在圣拉蒙建造了一个大型设施来管理其开发团队——这里离旧金山很近,可以说是就在硅谷,但还不足以让新员工满意。

过度依赖外界帮助

同样值得质疑的是,通用电气是否对自身做了足够的投资:虽然它确实聘请了优秀的咨询团队来帮助其转型,但这些人最后不得不离开了。该公司根本没有投入足够的精力来创建弥补差距所需的内部能力和组织基础设施。任何现代化的举措都没了下文。新项目仅此一个。当你构建一个平台时,你构建的是一个有生命的东西,它不仅需要持续维护,而且需要持续改进——只要你在经营,这些工作就不会停止。

未能适应文化

在大多数情况下,构建这样的大型项目时,一开始只要做一些能开始学习经验的东西就行了,然后就是逐步探索。你必须根据反馈进行调整,并不断努力让利益相关者保持一致。

 

然而,当我深入研究 GE 这个案例时,我遇到了许多关于团队错位的故事——一些人追求效率和成本节约,而另一些人则专注于应对全新的市场或迎合最终用户。于是他们同时尝试的东西太多、太多了。

GE 当时该怎么做?

在与卷入这场惨败的人们交流时,我反复听到的一个问题是——组织孤岛非常常见。销售人员不知道现在是什么状况,开发人员不知道其他开发人员在做什么,等等。这导致每个小组都在朝着自己的方向发展,小组之间几乎没有有效的协作。

 

考虑到 GE 将 Digital 视为一项孤立的业务,而不是为这家公司所经营的一切业务打下数字基础,这种情况也并不奇怪。平台也是面临风险的。一个平台必须设法成为与它所服务的每个团队所使用的笔记本电脑或互联网访问一样重要的基础设施。它不仅是你所做工作的一部分,它还能为你所做的一切工作提供支持。

从一开始他们的机会就很渺茫,因为他们没有在有意义的背景下看到种种问题和机遇。我认为这在一定程度上是因为他们未能理解明确的定义与成果沟通的价值所在。他们真正想要构建的是什么,为谁构建?在你四处询问他人,并意识到每个人都会给你不同的答案之前,你总会觉得这个答案很简单,不言自明。当我为组织的这类大型项目提供咨询服务时,我喜欢引导他们走过一段结果映射的流程,从而明确项目愿景,并为所有相关人员提供明确的定义。这个初步的合作阶段能帮助我们看清为什么这个项目很重要,可能会遇到什么障碍,事情会怎样出错,以及如何建立有效的学习-讨论决策流程。在人们开始做出假设并开始自己的工作之前,有必要弄清楚我们都在努力实现什么目标,有哪些障碍,以及我们将要做什么事情!

我常用的另一种协作方法是价值流图,作图时要查看当今组织中发生的一切,并思考我们如何通过更有效的行动来实现所有目标。我们可以遍历价值流图并根据各个步骤所涉及的内容和花费的时间来构建每个步骤,这种方法可以帮助你更好地理解你可以或应该关注的重点。通过价值流图,你不仅可以获得关于组织当前正在发生的事情的数据,还可以绘制出组织的未来状态,这样每个人都能知道更好的流程是什么样的。这样你就可以构建更好的工作方式。你的未来状态可以包含你打算实现的所有平台改进,以及这些改进对工作流程的具体影响。

Wardley 映射在这里也很有用。它揭示了生态系统、问题格局或环境的本来面貌,让利益相关者更好地了解他们可以进行哪些调整来更接近目标。它不仅可以让你绘制所有棋子在棋盘上的位置,你还可以考虑如何移动它们,并以新的方式连接它们。Wardley 映射是理解特定变更和策略的价值的有效方法,比如说你可以用它来选择平台的某些部分是依赖现成的软件还是外包出去。

为了将所有这些实践包装到一个简单的框架中,我们可以通过三个视角来看待项目:价值、清晰度和流。

 

  • 价值:平台实现者应该为企业、客户和员工调整价值主张,给出引人注目的愿景。在传达这些目标时,他们需要避免给出互相矛盾的动机。

  • 清晰度:齐心协力调整大家的观点并进一步达成共识。接下来,你可以根据你所处的领域定制你自己的课程,并按需对其进行调整以适应新的学习内容。清晰度让每位贡献者都能始终如一地做出最佳决策。

  • 流:在响应反馈时需要理解你的工作流和约束。为了使这一切顺利进行,你需要将流作为首要考虑因素。你需要看看工程师们为了交付产品正在做什么事情,了解客户对交付的成果有什么期望,还要知道领导者为了适应和做出规划需要了解哪些内容。

亡羊补牢往往为时已晚,但如果你能从一开始就牢记这些概念,就不必等到下一个项目成功(或惨败),然后才通过项目经验来提升自己的平台工程技能。

 

记住:

 

  • 平台工程要成为你的工作支撑,它不是孤立的项目

  • 无论你走到了哪一步,都力求清晰透明——这样每天你都会有收获

  • 把大局看成一个系统——一个需要流动来交付结果的系统

  • 顾问在起步时很重要——但你也需要培养自己的各种能力

  • 从小处着手,努力学习和适应

 

作者简介:

Steve Pereira 是 Visible Value Stream Consulting 首席执行官。

 

原文链接

https://platformengineering.org/blog/how-general-electric-burned-7-billion-on-their-platform

2023-05-22 14:425908

评论

发布
暂无评论
发现更多内容

生产环境全链路压测建设历程 21:某快递 A 股上市公司的生产压测案例之彩蛋 2 中篇

数列科技杨德华

全链路压测 七日更

十、服务分解

Geek_28b526

6. 抹平差异,统一类型转换服务ConversionService

YourBatman

Spring Framework 类型转换 Converter ConversionService

HBC环保卫士系统搭建

Geek_a620db

使用 Serverless 创建一个简单的短网址服务

donghui

flask Serverless Lambda Store

指尖上的警务,打造微警务管理服务平台

t13823115967

智慧警务系统开发 微警务

物联网方面的竞赛有那些?

IoT云工坊

第十周作业总结

hunk

极客大学架构师训练营

架构师训练营第2期 第10周作业

月下独酌

极客大学架构师训练营

海纳百川无所不容,Win10环境下使用Docker容器式部署前后端分离项目Django+Vue.js

刘悦的技术博客

Python Docker 容器 镜像 部署

架构师训练营第2期 第10周总结

月下独酌

极客大学架构师训练营

深入解析SpringMVC核心原理:从手写简易版MVC框架开始(SmartMvc)

Silently9527

Java mvc springmvc

智能合约系统软件开发|智能合约APP开发

系统开发

掌趣电竞系统开发搭建

Geek_a620db

共享单车系统搭建

Geek_a620db

数据可视化平台搭建,警务实战平台大数据应用

t13823115967

数据可视化 可视化数据分析搭建 警务实战平台

架构师训练营 - 大作业一

lucian

关于Dubbo的原理

皮蛋

程序员的bug修复宝典

程序员 经验总结 bug修复

全1子串算法求解、单元测试的必要性论述 John 易筋 ARTS 打卡 Week 32

John(易筋)

ARTS 打卡计划 全1子串算法求解 单元测试必要性

多币种钱包app系统开发,数字货币交易所系统源码开发

vivo 互联网业务就近路由技术实战

vivo互联网技术

中间件 服务器 分布式路由

架构师训练营 第3期 第5周 作业和总结

ihiming

第 5 周作业提交

Binary

极客大学架构师训练营

数据库范式与反范式设计,是一门艺术

架构精进之路

数据库 范式

物联网目前的安全问题有哪些?

IoT云工坊

vivo 全球商城:订单中心架构设计与实践

vivo互联网技术

分库分表 服务器 架构设计

架构师训练营 - 大作业二

lucian

第 5 周学习总结

Binary

极客大学架构师训练营

面试官:说说操作系统微内核和Dubbo微内核?

yes

dubbo 操作系统 微内核

2020年物联网行业有哪些新趋势

IoT云工坊

通用电气在平台工程上浪费70亿美元的教训_软件工程_Steve Pereira_InfoQ精选文章