在我们的第一个 "黑客组织 "播客中，Charles Humble与eBay的工程副总裁和首席架构师Randy Shoup交谈。他们讨论了eBay的架构是如何演变的，使用价值流图发现工程中的问题，衡量工程团队的速度，以及进行文化变革。
订阅。 亚马逊音乐| 苹果播客| 谷歌播客| Spotify关于受访者
兰迪花了二十多年时间建立分布式系统和高绩效团队，并曾在eBay、谷歌和Stitch Fix担任高级技术领导。他为首席技术官提供指导，为公司提供建议，并在可能的情况下使自己成为一个讨厌的人。他经常谈话，有时在关于软件的会议上，他对文化、技术和组织的关系感兴趣。他目前是eBay的工程副总裁和首席架构师。
提到的资源
加速》（Nicole Forsgren, Jez Humble and Gene Kim
）
流程框架- Mik Kersten博士
让工作清晰可见Dominia DeGrandis
项目到产品Mik Kersten
产品开发流程的原则Don Reinertsen
全文
介绍
Charles Humble：
大家好，欢迎收听 "黑客组织 "的第一集，这是容器解决方案的WTF is Cloud Native团队推出的全新播客。通过这个播客，我们的目标是将一些最有经验的软件工程领导人聚集在一起，与他们谈论他们的经验，包括建立和领导高绩效的软件工程团队等话题。我是Charles Humble，Container Solutions的主编，今天和我一起的是Randy Shoup。Randy花了二十多年时间在高绩效团队中构建分布式系统，并在eBay、谷歌和Stitch Fix等知名公司担任高级技术领导。他指导首席技术官，为公司提供咨询，并经常在会议上发言。他目前是eBay的工程副总裁和首席架构师。兰迪，欢迎来到节目。
兰迪-舒普：
谢谢你，查尔斯。能和你本人在一起真是太好了。我们已经认识很多年了，能成为你的第一位客人真是荣幸。
你和你的团队在eBay负责什么？
Charles Humble：
谢谢。你和你的团队在eBay负责什么？
兰迪-舒普：
就像你提到的，我是首席架构师，我是工程副总裁，我们内部称之为工程生态系统和经验。eBay有大约4000名工程师，我的团队建立了开发者框架、CI/CD管道、人们进行开发的环境、暂存等。我们做移动基础，实际上，我们也负责第三方开发者使用的外部API，以帮助我们的买家和卖家与eBay互动。但是，你可以广泛地认为它是eBay的开发者体验部分。
eBay的架构是如何演变的？
Charles Humble：
现在，eBay显然已经存在了较长的时间。它已经有26或27年的历史了，从架构上看，我认为它是J2EE--那个时期的Java企业。但显然，架构会随着时间的推移而演变。那么，你能给我们介绍一下目前的架构是什么样的吗？
Randy Shoup：
我们肯定还是有很多Java，但绝不是EE。我会告诉你这一点的。一直以来都是POJO。我将给你一个超级简短的历史。我们是啊，现在26岁了，27岁了。我们已经存在了一段时间了。第一个版本是创始人Pierre Omidyar，在1995年劳动节的三天周末。他用Perl写的。报价网站上的每个项目都是一个文件。没有数据库，所以它没有规模，也不打算这样做，他只是在搞这个叫做网络的新的酷东西。当时它甚至不叫eBay。下一代就是我们所说的V2，它是一个内置的C++。它经过多年的发展，几年的时间，称其为五、六、七年，在一个ISAPI DLL里有340万行代码，如果你理解很多这些词，你会缩手缩脚，但只要知道340万行代码，甚至不只是在一个进程中，甚至不只是在一个共享库中，而是基本上在一个单一的类中。
Charles Humble:
Woah!
Randy Shoup:
一个单一的类。就像你能想象的那样糟糕，那是更糟糕。V3是对它的现代化改造。那是在大约20年前的2002年开始的。那是在Java中进行的全面重建。不，是EE。它并不叫EE。那时候是J 2EE，但我们没有使用任何EJB的东西。我们很快就了解到，那是无法扩展的，因为Spring后来向我们展示了一切POJO、Servlets等等。你不会把它称为微服务。现在你会把我们所做的称为微服务，在当时，它更像是迷你应用程序。我们把这个单一的，整个eBay放在一个类别中，并把它分解开来，当时我们称之为200个不同的集群，好吧，"这个应用服务器集群服务于销售页面，另一个服务于购买页面，另一个服务于搜索页面，等等。"
你可以认为这是现代术语。你可以把它想成是按顶部的域名划分的，然后是一个共享数据库的海洋。如果你想的话，我们可以谈谈这个问题，但我们了解到，共享的部分并不是一个好主意。实际上，我们现在刚刚，实际上是在接下来的几个月里，摆脱了网站上V3的最后残余。但从那时起，我们已经有了整整两代Java的进一步改进，其中一个，我们非常有创意地称之为V4，它演变成我们内部称之为Raptor的东西，它是Spring，但不是Spring Boot。
Spring pre-Boot，相当单一，不是整个eBay在一个JAR中，而是整个区域在几个JAR中，而且非常紧密地耦合。大约10年前开始，然后从5年前开始，我们更现代的框架，我们超级有创意地称之为raptor.io，这是Spring Boot，所以就像在Spring生态系统中，非常可分离的可插拔的JARs。然后作为这一举措的一部分，大约五年前，我们基本上将整个前端转移到Node。现在你可以考虑 "让我们称它为10%的eBay，代表顶级的用户可见的用户界面。"这主要是Node，同样，为什么在浏览器和服务器之间来回使用同构的JavaScript，然后是后端，其中很多都是各种风味的Java框架。
Charles Humble：
你如何处理构成你的后端的各种不同的Java微服务之间的服务内通信？
Randy Shoup：
是的，同样，27年。我们有很多来回传递消息的方法。我们有一个相当好的传统的东西，我们在2006年建立的，内部名称并不重要。我们称它为商业事件系统或BES，但你可以把它看作是，我不会说它是Kafka，但它比你想象的更像Kafka。所有的消息都持久地存储在Oracle数据库中，但不管怎样，然后各个消费者，就像在Kafka生态系统中一样，我用的是Kafka的术语，但本质上有他们自己的指针进入消息，如果这有任何意义的话。不同的消费者可以在事件流的不同点上，如果这对你的听众来说是有意义的。我们也有Kafka，所以你可以想想我告诉你的多代核心堆栈。我们有多代的......还有一些应用在使用我们内部建立的那种传统的BES系统，然后现代的东西都是用Kafka建立的。
是什么促使你回到eBay？
Charles Humble：
改变一下话题，这是你在eBay的第二次工作。
是什么促使你回来的？
Randy Shoup：
我在18年前的2004年第一次加入，在那里工作了大约7年，我主要负责eBay的实时搜索引擎工作。我很乐意详细地谈论这个问题，但这可能不是这个播客的主题。这在当时是超级有趣和突破性的。在eBay工作了7年，然后离开，与另一位eBay同事共同创立了一家创业公司。没有人听说过它，所以我们属于99%的人，而不是唯一的人。正如你在介绍中提到的，在谷歌工作过，在Stitch Fix工作过，最近还在WeWork工作过，在这之间还有一些其他地方短期工作过。是的。然后就在两年前，现在的首席技术官是我当年的同事，他让我回来，基本上是为了解决产品开发速度的问题，至少我们内部是这么说的。
我们需要做更多的敏捷吗？是的。精益？是的。Dev Ops？是的。那时候有点转型eBay，我对，我爱eBay，超级感兴趣。也许我们会更详细地讨论我为什么回来，因为有几个原因。但我想回来做的事情是这样的，就是把eBay带入精益、DevOps和持续交付的现代世界。我觉得我有工具，因为我在其他地方看到过这样做，我的工具箱里有工具，能够提供帮助，而在10年前，我有我想要的感觉，但我没有触觉，不知道在那里会是什么样子，到那里会是什么样子，如果这有任何意义的话？
你回来后发现了什么问题？
查尔斯-汉伯：
是的，完全是这样。那你回来后发现了什么？我想象在26或27年后，会有一个合理的技术债务积累。这公平吗？
Randy Shoup：
是的。哦，完全公平。是的。当我在2020年6月回来时，正值大流行，所以实际上有一群我从未见过的人，我和他们一起工作了一年半以上。我相信这也是你的听众所熟悉的情况。希望这能改变。我做了精益人士所说的价值流图，同样，eBay是一个大地方，有4500个应用程序和服务，大约有4000名工程师。因此，我没有与每个人交谈，但我确实回来说，"嘿，我想解决这个问题，使eBay更快，"不管这意味着什么。"给我三个团队，就像一个抽样，我可以和他们交谈，而且是详细的交谈。对吗？"真的和他们一起走过。当某人有一个想法时，它是什么样子的，需要多长时间？这个想法变成客户在现实世界中实际使用的功能之间会发生什么？
同样，精益人士会把这称为价值流图或价值链。基本上，你只是从头到尾地看待这个系统，比如，"那么，从某人有这个想法到发生什么步骤？"一个想法变成一个项目，一个项目变成承诺的代码，承诺的代码变成网站上的一个功能，然后我们通过实验和分析之类的东西实时迭代这个功能。因此，我和团队一起从头到尾看了所有这些事情。我们在每个领域都发现了问题，对吗？
而且，就像你说的，27年的业务，我们已经积累了很多债务。我们积累了很多技术上的债务，很多组织上的债务，还有很多，我们总是以X方式做事，但这种方式是我们20年前的最佳做法。对吗？有很多改进的机会。因此，我们从头到尾审视了我提到的那些阶段，比如从规划想法到项目，软件开发是项目到代码，软件交付是代码到功能，然后发布后的迭代是我如何构建实验和分析的。
但是
，正如我所说的，每一个领域都有问题和机会。
但是，非常清楚的是，瓶颈，所以对于了解精益的听众来说，考虑约束理论，瓶颈绝对是在软件交付领域。平均而言，这4,000个应用程序和服务中，平均每个月部署一次或两次。因此，在上游有很多事情我想改变架构。我有一个首席架构师的头衔，你会认为我一进来就会说："让我们做所有这些架构上的改变。"相信我也想这么做，但公开和诚实的事实是，如果你每年只有12次机会，你就无法改变架构，如果这有任何意义的话，对吗？
那是一个很大的提升，"是的，让我们做大量的打字工作，然后像每个月，把它拿出来。"我只是在使用架构的例子，我们想做更快的实验。我们想更快地把功能提供给客户，所以在所有的空气领域，产品开发生命周期的软件交付部分是瓶颈，所以这就是我们去年的重点，我们在这方面做了一些真正的重大改进。
是什么造成了瓶颈？
查尔斯-汉伯：
就瓶颈而言，你能不能再细分一下是什么造成的？是否有太多的工作在进行中？是冗长的构建时间，还是太多的人工测试？是什么造成了这个瓶颈？
兰迪-舒普：
是以上所有的原因。我们一直在处理并继续处理的事情是改善我称之为开发人员的内部循环，比如改善开发人员的日常、每小时的生产力，所以这就是诸如构建时间、启动时间、PR验证时间、测试、更多的自动化测试、测试金字塔，对吗？我们传统上有大量的集成测试，这些测试是在流程的最后阶段进行的，费用很高，也很广泛，并试图慢慢地但肯定地将其移到左边。把所有其他的东西移到左边。将安全测试、可及性测试和性能测试移到管道的早期，拥有一个更好的CI/CD管道。我们已经有一段时间了，我们自己推出了一个，但我的团队建立和维护它，所以在使其更好方面有更多的投资。
因此，这是关于，在某种意义上的个人开发人员的生产力，很多这些领域，软件交付的一半是所有关于
...这是《加速》一书中的内容，变革的领先时间。在一个开发者提交了她的代码之后，从提交代码到它成为网站上的一个功能，中间有多长时间，发生了什么？有时，这是以周为单位的，但它不应该是。我所提到的那些事情也增加了一倍，所以更多的自动化测试，更多的向左移动的东西，如安全，但也有自动化部署，对吗？金丝雀部署，我很乐意谈论这个问题。我们引入了一种能力，这不是我们发明的，但我不知道是否有一个行业术语，我们称之为流量镜像，通常在只读的情况下，你向生产版本、旧版本和你想使用的新版本发射一个真实的生产请求，然后你比较结果，对吗？
你得到你的JSON响应并比较它们。因此，这是一种方法，A，超级容易知道我们是否改变了什么，B，工作起来就像那个东西是一个黑盒子。让我们想象一下，你没有测试，因为它是超级传统的，或者没有人投资于它。这仍然是一种技术，你可以用在任何事情上。无论如何，我们在所有这些领域都进行了投资，另一个相关的领域是在移动领域。当我到达时，我们正在做我们的移动iOS和Android应用程序。我们每个月发布一次，然后我向团队提出挑战，就我自己。我说，"嘿，让我们试着看看我们是否可以每周发布一次。"他们就说，"你疯了。这是我们冻结代码后发生的所有事情。"我就说："好吧，让我们研究一下这个过程是如何进行的，做更多平行的事情，做更多上游的事情，把更多的东西自动化。"
我对此感到非常自豪，因为最大的怀疑者是我的发布团队。几个月后，我们从每月发布一次到每两周发布一次。我们从去年1月开始，让我们称它为4月或5月，我们转为双周发布。他们认为，"嗯，这还不算太坏。"然后我们的大的老的扩展目标，人们认为是无法实现的，就是在年底前每周一次。然后我们刚刚做了一个，我们正在做这些双周发布，他们想，"让我们在7月尝试一个。让我们尝试每周发布一次，看看效果如何。"然后它就像，"这很好。"提前五个月，我们的扩展目标，人们认为我们无法实现，但我们做到了。
因此，从去年7月开始，我们一直是每周发布，这很了不起。很明显，我们向客户提供功能的速度快了很多很多。我们已经减少了交货时间，从以月计算到现在以天计算。但另一件事，正如你在加速书中所想象的那样，在DevOps的状态报告中，你会预测到，而且已经发生了，它完全改变了开发团队和产品团队的心理模式，因为他们不再急于让火车离开，而下一班火车一个月后才离开。
Charles Humble：
对。
Randy Shoup：
对？相反，这就像，"我们要努力在这个星期三完成。如果我们不能在本周三完成，我们将在下周三完成"。没有什么大不了的。再说一遍，你可以想象这对车队来说是多么大的压力，但也会提高质量。因为同样，没有人为了达到目的而比赛和偷工减料，这一点，公开和诚实。以前有一些激励措施，现在没有了。同样，当，不是如果，当我们发现发生在我们的应用程序中的问题时，软件是很难的，所以我们发现一个问题，有一个错误或某些用户不能做的事情，我们曾经有一个大的恐慌，就像，"哦，我们将有这个大的例外过程，我们必须在周期外发布。"而现在则是，"我不知道，你能等到星期三吗？因为那是即将到来的事情。"而我们现在实际上正处于这样一个过程中，这没什么大不了的。我喜欢它。
查尔斯-汉博：
这是一个深刻的转变，它是相当反直觉的。我的意思是，当我开始在大型的老企业IT部门工作时，不管是多少年以前，我们可能每季度发布一次，甚至一年两次或其他，所以如果你错过了发布，可能要等到3、4或6个月后才有下一次。你不希望这样做。对吗？所以你会匆匆忙忙地把东西放进去，然后会有一个漫长的代码冻结过程，这时每个人都在试图修复事情。但是，这个想法是，行动越快，质量就越高。当我第一次听到这个想法时，它似乎非常错误。我现在接受了，但我花了很长时间才想明白。
Randy Shoup：
查尔斯，即使对我们这些经历过的人来说，这也是令人难以置信的反直觉，就像我们甚至生活在这个世界上，它仍然是反直觉的，这种想法就像，好吧，"我想要提高质量。那么，我应该做的是放慢脚步，更努力地思考，在前期非常努力地思考，非常努力地尝试，并投入很多压力。"而事实证明，这正是错误的做法。就像，"嘿，让我们跑一场马拉松。让我们现在就开始吧。开始跑步。"不，你每天都要锻炼，你要慢慢地但肯定地努力达到它。我开始了我的职业生涯，我会把自己的日期说得超级清楚，因为在LinkedIn上很容易找到。我的职业生涯开始于1990年，在甲骨文公司工作，我没有在数据库上工作，但我在数据库上做了一个特别的查询工具。我们每年都会发布版本，
那是甲骨文的第六版。我记得那个版本发布了。这就是我说的年代。但无论如何，整个套件都会一起发布，就像有一个大的，我不记得了，1991年6月1日，所有这些东西都要发布。因此，是的，对于你的观点，这不仅是几个月的计划和几个月的，还有几个月的打字，但随后几个月的 "我们在这个代码冻结中没有改变任何东西，但它不工作。"三个月的格式，我在编，但可能没有错，让我们想象一下，这12个月中有4个月是这样的，"只要让我们认为在的功能和我们已经完成的功能像反正实际工作。"
这就是Nicole Forsgren的研究的伟大之处，它是DevOps状态调查的一部分，她在《加速》一书中表示，在速度和稳定性质量之间没有权衡，事实上它们是自我强化的。获得更快速度的最好方法是通过自动化和良好的实践投资于更高的质量，拥有良好质量的最好方法是投资于更快的速度。而这个洞察力，也是不直观的。我知道你知道这是较小的工作单位，较小的工作单位。为什么会有这样的事情？这是因为正如我们所讨论的，如果我发布了一年的软件，要稳定这个东西需要四个月。对吗？我们在过去的坏日子里就经历过这种情况。如果我们发布一天的软件或一小时的软件，如果它坏了，就没有那么多事情可以做。对吗？
Charles Humble：
对，是的。
Randy Shoup：
你可以通过检查，看看它，"这不会破坏这95件东西。我向你保证。"我看它就像，"这没有触及任何这些东西。"好的，所以正向的代码审查是超级容易的，因为它适合你的头脑，而反向的诊断，比如，"好的，当我错了或什么的，会有多少事情？我们只改变了两件事或一件事。"因此，A，很容易诊断出来，但B，不管我是否诊断出来只是把它卷回去，有什么大不了的，对吗？"哦，我的上帝，我们失去了兰迪的一个小时的工作。"就像，"我没问题。"
如果它能阻止客户有不好的体验，那么我们就能冷静地把它解决掉。对吗？这就是为什么 "加速 "指标是围绕速度、部署频率和变革的准备时间的，而且它们与稳定性或质量指标、变革失败率和恢复时间结合在一起。而这些东西都是自我强化的。在其中一些方面非常糟糕的组织在所有方面都很糟糕，而在其中一些方面非常出色的组织在所有方面都非常出色。
你如何在可独立部署的微服务和操作的复杂性之间找到平衡点？
Charles Humble：
对吗？我想一会儿再谈一下 "加速 "指标，但只是为了继续这个思路，这种部署速度的想法导致你进入高度分布式系统，所以那种独立部署的微服务类型单元或你想使用的任何术语，这很好，但有一个重要的权衡，那就是不同组件之间的互动变得越来越复杂。因此，你正在做的是，你正在用部署的速度与操作的复杂性做交易，我想，保持事情的运行变得更加困难。有时，你也会得到一些你不一定能预测到的服务之间的奇怪的相互作用。你把一个新的服务放进去，是的，这个服务的变化很小，但是它却在其他地方产生了某种奇怪的意外后果，而你却无法推理，因为它是在胶水代码中，而不是服务本身。你有这样的经验吗？
Randy Shoup：
一直都有？我知道你在你的问题中知道这一点，我是说，你知道这一点，是的。100%.你刚刚描述了分布式系统，是Lamport说的吗？"分布式系统的定义是一台我从未听说过的机器可以破坏我的东西。"
Charles Humble:
嗯，这不是一个事实。是的，绝对是。是Lamport。是的。
Randy Shoup：
我喜欢这句话，伙计，无论如何，他太聪明了。你所表达的100%，我再退一步说，你所表达的是一种权衡，从一个大部分是单体的系统，所有东西都在一个地方，很容易看到所有的互动，因为它们都在一个地方，到一些更多分布在，像你说的，微服务或单独可部署的组件，流程，再次，无论你想用什么词，服务。就像你说的，是的，它们之间的相互作用更加复杂，因此有更多的机会看不到它们。我想这是真的。此外，它不一定会使情况变得更糟。真正做面向服务的架构的组织也是如此，他们非常仔细地思考这些边界，eBay正在走向这一步，我是开诚布公的。但是当我在谷歌工作的时候，我在编故事，但是我在那里的时候，谷歌可能有一万个服务。作为一个服务所有者，我负责应用引擎的工程，也就是谷歌的平台即服务。
我们与大量的其他系统互动，但不是一万个。你跟着我。我们与几十个，小数目，几十个服务互动。因此，这就是我们的世界。我们的世界是那几十个服务，那些依赖我们的服务和我们依赖的服务。而我们只是需要确保这些互动是有意义的。你并不是真的在暗示查尔斯，但是没有在一个非常大的服务架构中工作过的人可能会认为这真的很让人难以接受。"哦，我的天哪，我怎么可能把成千上万的服务放在我的脑子里？"你不能这样做，你也不必这样做。没有人可以做到这一点，真的没有人。认知负荷太高了，所以作为一个服务所有者和服务的贡献者，你需要了解的是，哪些服务依赖于你，哪些服务依赖于你？
你发送和接收哪些信息
？就是这样。除此以外，还有其他更广泛的东西吗，这很有趣？是的。但大多数情况下，你不需要关心它。就像我们的日常生活一样；整个世界上有80亿人。但是我们并没有想到要和80亿人打交道。我们继续我们的生活，我们处理一些小数量的数百人或几十人或几个人的大流行病。即使整个生态系统有很多东西，我们作为人类个体对它的体验是相当有界限的。
使用加速指标
查尔斯-汉伯：
现在你提到加速指标，有时被称为DORA指标。你是否使用这些指标来衡量你在eBay处理开发者速度问题时所产生的影响？
Randy Shoup：
没错。是的。是的，这不是我说的，但这是个好词。我们把我们正在做的事情称为 "速度计划"。而且，正如我所提到的，我们做了价值流图，我们找出了大多数团队的瓶颈，我们确定它主要是在软件交付上，所以这很好，因为妮可做了近十年的研究，试图告诉我们如何解决这个问题，这很了不起。同样，正如我们提到的，各种命名的加速指标，DORA指标是四个，对吗？因此，两个速度指标，部署频率，和改变的准备时间，然后两个稳定性或质量指标，改变失败率，和恢复时间。因此，是的，我们正在使用这些指标来衡量我们的进展，我很乐意更详细地讨论这个问题。实际上超级简单，我们可以进入更多的细节，但在2021年，我们做了我们内部称之为试点的工作，我们一群人知道这将是工作，但我们不知道我们不知道eBay，如果这有任何意义？
我们与大约10%的团队合作，例如300、400名工程师横跨eBay的所有部分。搜索、销售、购买、运输和支付的团队，以及所有地方的跨部门的团队，关键是我们通过我们所做的所有工作，最终使他们的生产力翻倍。同样，改善构建和启动时间，改善他们的CI/CD基础设施，改善他们的做法。我们在我们的短语中与领域团队一起工作，如试点产品工程团队，他们对他们的流程做了大量的改变。他们告诉我们他们需要的工具和基础设施的东西，我的团队建立或合作改善工具和基础设施，这种合作关系非常有效。最重要的是，我们把团队的生产力提高了一倍，这是在保持团队规模和团队组成不变的情况下衡量的。
他们在错误修复方面产生的功能是他们以前的两倍。如果你使用Mik Kirsten的流程框架，这就是一个你称之为流程速度的指标，但基本上可以认为是东西比以前更快地通过整个产品开发周期。就加速指标而言，eBay当时和现在都是平均表现在这四个关键指标上的中位数，同样，每月部署一次或两次，准备时间为一周半。而现在，与我们合作的那些团队都是实实在在的高绩效者。而不是一个月两次，每周部署两次或三次，准备时间从10天降到两天，同样，我们继续前进，所以我们之前合作的那些团队将继续变得更好，希望在一天多次部署和一小时准备时间的道路上，这是行业领先的那些事情。
是的，我们肯定使用这些加速指标来注意机会领域，对吗？比如，"哇，看起来你的准备时间很高。"而且我们与团队一起加班工作，使之不感到责备。你知道我的意思吗？我们就像，"嘿，首先要开诚布公。"第一次的时候，团队就像，"等等，什么？你有一个大的老的，花哨的头衔，你进来告诉我，我不是很好。这感觉并不好。"但是，当你把它与 "我来自政府，我是来帮忙的 "结合起来时。而这在我的国家是一个笑话，但在你的国家是真实的，就像，"嘿，开放和诚实。"我们实际上有相同的目标。就像，"我希望你变得更好，我打赌你也是如此。"而且，"我在这里为你提供建议、工具和资源，以帮助你做到这一点。"
你从哪里获得数据？
查尔斯-汉伯：
你实际上是从哪里获得数据，以产生你的DORA指标的测量结果？
兰迪-舒普：
我很高兴你问这个问题，因为我真的想讲这个故事，我几乎忘记。当我来到eBay的时候，因为我也有一个建立开发者工具的团队，包括这些指标的仪表盘。我们当时已经有了一个仪表盘，我们在那里跟踪bug和其他各种事情。当时的领导非常自豪地对我说，"嘿，我们可以给你看这个吗？我们有一个指标，这个数字表达了，我忘了用什么词，但像生产稳定性。基本上，它是所有加速指标的组合。
他们并不熟悉加速指标，如果他们来给我这个数字，我是学数学的，所以他们给我看了公式，它有指数衰减，它的权重和所有这些东西，我想，"这甚至太复杂了
......我知道里面所有的希腊字母，但还是太复杂了，相反，如果我们把它分成这四件事，哦，顺便说一下，有一本书说这四件事实际上很重要。"
我们确实在测量，我们有一个仪表板，几乎在一年半前就开始了。我们做的第一件事是，因为我们有所有的数据，这是惊人的，我们只是把它放在一起的形式，我们按定义衡量加速指标。我们从哪里得到它们？我们用了GitHub。让我按顺序来做，部署频率。我们有自己的部署工具。我们知道我们什么时候在部署东西，所以我们可以知道这些东西什么时候开始和结束，我们可以知道我们在部署什么。而这是相对直接的。然后对于准备时间，我们在GitHub上查看工作何时开始，何时提交，或者在我们的定义中，何时打开PR？因为我们认为这意味着我们已经完成或我们认为已经完成。
我不是在说草稿的事，而是当开发者准备好了的时候，那就是应该开始计时的时候了。然后我们知道什么时候部署，对吗？这就是准备时间。然后改变失败率。实际上，我们现在有一个不完美的措施，我们衡量回滚。我们衡量的是，当我们推出了一些东西，然后我们又将其退回。实际上，我们将改进这一点，看看我们称之为P1的错误，这相当于你在加速定义中需要一个热修复或补丁的情况。我们还没有整合这一点。然后是恢复时间，也就是我们知道的部署发生的时间与回滚发生的时间或未来P1错误得到解决的时间之间的时间。这有意义吗，查尔斯？
你是如何管理文化方面的变化的？
查尔斯-汉伯：
是的，它是。这很完美。我想接着谈一下文化方面的问题。我们已经触及了这个问题，但基本上你所描述的是一种组织转型的形式。现在，这在很大程度上是Container Solutions在云原生转型方面所做的工作，我们帮助公司从向云的转变中获得好处，我们喜欢说，这确实是一种文化转型，至少和技术转型一样。你是如何发现这些文化方面的？例如，你是否得到了行政团队的认可？
兰迪-舒普：
这绝对是一个文化和行为的改变，在每一个层面。对吗？我提到了一点，不是太详细，但在个人团队层面，所以给他们提供工具和基础设施是一回事，从长期的功能分支（多年来我们一直默认的是基于主干的开发）转换到另一回事。对于单个开发团队来说，这是一个巨大的行为变化，现在我们正在衡量准备时间，公关提醒，对吗？比如，"嘿，你已经完成了你的代码，你正在等待Randy的审查。我不想让你等待，这是个问题。"诸如此类的事情，这就像文化和行为，在较低的水平。在更高层次的执行组织中，肯定也有文化上的转变。
Charles Humble:
这真的很有趣。听起来你已经得到了行政人员的支持，而且随着时间的推移，你也得到了开发人员的支持，因为你向他们展示了正在发生的事情，但在其他地方，你是否发现，获得这种支持的难度更大？
Randy Shoup：
等级制度的两端真正看到了问题和价值，我们仍在努力解决中间问题。每天生活在这些东西中的个人团队真的希望速度更快，对他们来说更容易。这一点是没有争议的。开发人员希望他们的内部循环是紧密的，并保持流动和其他的东西，然后执行官就像我曾经在的每个公司一样，"为什么它这么慢？"不，我从来没有发现一个公司的执行官认为我们的速度太快了。执行者们看到了问题，并对解决方案感兴趣。我们正在努力改变中间的文化，因为激励结构确实发生了变化，从 "让我们做大批量的大东西，并认真思考 "到 "让我们做小的实验，快速迭代"。
你下一步的重点是什么？
查尔斯-汉伯：
这自然导致了最好是我们的最后一个问题，因为我们不幸地时间越来越短。你能不能稍稍扩展一下你现在在eBay的重点是什么？
Randy Shoup：
是的，这很好。在今年2022年，我们将把这个 "试点 "从10%的eBay团队扩大到50%，所以我们正在做的大事是扩大这个项目的规模，把好处带给所有人或一半的人。我们正在讨论，让我们称之为300名工程师，现在我们正在讨论像1500或2000名工程师，所以这是一个很大的规模，它不能以同样的方式进行。对吗？它不能只是兰迪和我的伙伴，马克-温伯格在产品工程方面。我们不可能亲自与所有1500名工程师见面，所以我们正试图为那些已经相当好的团队扩大规模，那些参加试点的PM团队，他们还有一段路要走，对吗？
我们将继续与他们合作，消除他们更多的瓶颈
。
此外，我们还将产品开发周期的上游和下游从软件交付部分转移到了下游迭代和生产上。这是今年功能旗的一个主要重点，让我们的实验平台更加容易使用，以及更好的分析和更快的分析，不要等待几天才能得到结果，相反，尽量在几小时和几分钟内得到结果，然后再向上游发展。
我预测的下一个瓶颈都是关于eBay所说的规划，事实上，有一个词来形容这个问题，我想本身就是一个小问题，对吗？我们只是需要理解，我们不应该以季度和年份来思考，我们应该有季度和年份的愿景，但我们应该在几周和几天内执行，因此，围绕较小批量的文化转变，减少团队间的依赖。然后，你之前暗示过这一点，但每个团队都有太多的WIP，太多正在进行的工作，所以这也是一个非常反直觉的事情，告诉执行官，"你知道吗？如果我们不同时处理这么多事情，我们会走得更快"。他们就会说，"你在说什么呢？你这个懒惰的工程师。"就像，"不，不，请读读唐-莱纳森的这本书。"他们会说，"不，我不会读那本书的。"
但无论如何，还是那句话，这同样是违反直觉的，但试图减少WIP来增加流量。
Charles Humble:
Randy，非常感谢你。我可以和你聊上几个小时。我会把我们提到的所有书籍和其他资源的链接，包括Don Reinertsen的 "产品开发流程的原则 "放在节目注释中。我只想说，非常感谢你成为集装箱解决方案公司WTF is Cloud Native团队第一集 "黑客机关 "的第一位嘉宾。
Randy Shoup：
谢谢你，查尔斯。