【混沌工程】故意破坏和混沌工程

在这一集中，Jason 与加拿大皇家银行的开发者宣传总监 Aaron Clark 聊天。 Aaron 分享了最初在 RBC 担任开发人员并从事早期云开发工作，然后过渡到他作为开发人员倡导者的角色的感觉。 Jason 和 Aaron 讨论了在组织内应用开源原则或“内部资源”的价值。他们的时间以继续教育和如何继续学习的讨论结束。

在本集中，我们将介绍：

• Aaron 谈到了作为开发人员的起步以及在 RBC 的云开发的早期阶段 (1:05)
• Aaron 讨论了向开发人员倡导过渡 (12:25)
• Aaron 确定了他在早期倡导开发人员时所取得的成功 (20:35)
• Jason 询问如何帮助开发人员完成长期维护项目或“可持续发展” (25:40)
• Jason 和 Aaron 讨论什么是“内部资源”以及为什么它在组织中很有价值 (29:29)
• Aaron 回答了“你如何使技能和知识保持最新？”这个问题。 (33:55)
• Aaron 谈论 RBC 的工作机会 (38:55)

参考链接：

加拿大皇家银行：https://www.rbcroyalbank.com

RBC 的机会：https://jobs.rbc.com/ca/en

成绩单

Aaron：我猜有些 PM 问过我的老板，“所以，Aaron 没有参加我们的平台状态会议，他并没有真正接受门票，也没有参加支持轮换。 Aaron 为云平台团队做了什么？”

杰森：[笑]。

Jason：欢迎收听 Break Things on Purpose，这是一个关于可靠性、学习和构建更好系统的播客。在这一集中，我们与加拿大皇家银行开发者宣传总监 Aaron Clark 进行了交谈。我们与他聊了聊他从开发人员到倡导者的旅程，在组织内应用开源原则（称为内部资源）的力量以及他继续学习的建议。

杰森：欢迎来到这个节目，亚伦。

亚伦：谢谢你邀请我，杰森。我的名字是亚伦克拉克。我是 RBC 的云开发倡导者。那就是加拿大皇家银行。从 2010 年 2 月起，我就在银行工作了……嗯。

Jason：那么，当你第一次加入银行时，你并不是开发者的拥护者？

亚伦：对。因此，我自 2019 年以来一直担任现在的职务。自 2017 年以来，我一直是云计划的一部分。早在 2010 年，我就以 Java 开发人员的身份加入。所以，作为一名开发人员，我的背景对 Java 非常重要。 Java 和 Spring Boot，现在。

我加入了皇家银行众多职能领域之一的一系列 Java 应用程序的工作。银行很大。这是人们有时难以掌握的事情之一。这是一个如此庞大的组织。我们大概有 100,000 名……是的，有 100,000 名员工，其中大约 10,000 名从事技术工作，因此开发人员、开发人员相邻的角色（如业务分析师和 QE）、运营和支持以及所有这些角色。

这是一个大组织。当你加入组织时，这是一件有趣的事情。因此，我加入了一个名为 Risk IT 的小组。我们只构建面向内部的应用程序。我在那里做了一堆东西。

我是一个多面手，我对 DevOps 的所有事情都感兴趣。我在 Risk 中设置了第一批 Hudson 服务器之一——嗯，在银行中，但特别是在 Risk 中——我在一边管理它，因为没有其他人在做，它需要做。在这样做了几年并从事了许多不同的项目之后，我偶尔只是，“我们需要这个项目成功，一开始就有一个良好的基础，所以亚伦，你在这个项目上做了六个月然后你正在做一些不同的事情。”这真的很有趣。同时，我总是担心这样一个问题，如果你不坚持很长时间，你永远不会知道你可能做出的错误决定的后果，因为你不必处理它。

杰森：[笑]。

亚伦：这就像我希望我在这里做出正确决定的另一面。它看起来很不错，人们似乎对此很满意，但我总是担心这一点。就像，在一个角色中工作了几年，你构建了一些东西，然后它在生产中，你正在运行它并且你正在处理，“哦，我做出了这个当时似乎是个好主意的决定.事实证明这是个坏主意。下次不要这样。”如果你不留在一个角色中，你永远不会学到这一点。

当我在风险 IT 部门工作了四到五年，所以我会与一群可能留在这个项目上的团队一起工作，他们会来问我问题。就像，我没有消失。在接下来的几个月或其他任何时间里，我都不会在那个项目上工作。然后我搬到了该组织的另一个部门，比如一个名为 Finance IT 的姊妹组，它运行某种类型的东西——为银行构建和运行总账。或者至少对于部分资本市场而言。

随着组织的移动，它变得模糊。团体合并和分散等等。那个小组，我实际上有一些有趣的东西，当我开始研究更多的东西时，比如云，看着云，银行开始引入云。所以，我仍然在应用程序开发方面，但我对此很感兴趣。我参加过 OSCON 之类的会议，开始听说和了解 Docker、Kubernetes、Spring Boot 之类的东西，我觉得这是一些非常简洁的东西。

我在银行早期的 Hadoop 集群之一上开发基于 Spark 的 ETL 系统。所以，我一直觉得，超级，超级幸运，我做了很多这样的事情，在所有这些新事物在组织中真正新生的时候就开始工作。我也得到了非常支持的领导。所以，就像我正在做的那样——持续集成服务器，它完全在旁边；我参与了一堆重用想法，我们有这个更大的群体；我们正在做很多类似的事情；让我们分享一些图书馆和类似的东西。那是在成为任何，比如，开发者倡导者或任何类似的东西之前，我正在从事这些工作。

基本上，我实际上得到了一年的资金来促进和从事重用活动。那就是——我学到了很多，我犯了很多错误，我现在，比如，告诉我在我目前的角色中做出的一些决定，但我正在做这一切，我几乎把它描述为我有点因为我在这个团队工作，所以对我现有的项目征税，但我还有这件事要做。而且我可能需要花一个上午的时间而不是为您的项目工作，因为我必须为某人维护这台构建机器。我得到了非常支持的领导。他们很棒。

他们认识到这些活动的价值，并没有真正争论我正在从预算中说我应该做的任何事情上抽出时间，这真的很好。所以，我开始这样做，我在金融部门工作，因为云团队开始经历改造——银行最初的新生云团队——我从应用程序开发端做云的事情，但同时在我的团队中，每当有什么令人惊讶的事情被打破，有人遇到紧急情况需要有人介入并聪明地解决问题时，那个人就变成了我。从这个意义上说，我遇到了很多干扰。很高兴成为那个开始工作的人，“哦，这东西需要拯救。帮助我们，亚伦。”

这太妙了;感觉真的很好，对，直到你花了很多时间做这件事，而你不能做你真正感兴趣的事情。所以，我实际上决定搬到云团队工作关于定义我们如何为云构建应用程序的方式，这真的是——这是一个非常好的时机。那是在银行的早期阶段，所以没有人真正知道我们将如何构建应用程序，我们将如何将它们放在云上，这种结构是什么样的？我必须做大量的阅读、研究和向其他人学习。一个关键的事情，比如，一个像银行一样行动缓慢并且在技术选择方面有点规避风险的非常大的组织，人们总是表现得好像这总是一件坏事。

有时是因为我们有时没有采用我们真正能从中获得很多好处的东西，但另一方面，当我们接触到很多这些技术和平台时，一堆锋利的边缘已经被打磨掉了。就像世界上的 Facebook 和 Twitter 一样，他们已经采用了它，他们已经发现了所有这些问题，并且像用胶带一样把它们粘在一起。他们发现，“哦，我们需要在这个系统中内置实际的，比如，安全性”，或者类似的东西，他们已经解决了。所以，当我们谈到它时，其中一些问题已经不存在了。我们不必与他们打交道。

在一个更保守的组织中，这是一个被低估的积极因素。所以，我们认为我们可以从中学到很多东西。当我们研究微服务以及类似 Spring Boot Spring Cloud 时，最初被引入组织的云部分主要围绕 Cloud Foundry。我们正在帮助一些初始应用程序团队构建他们的应用程序，我们可能过度设计了其中一些应用程序，从某种意义上说，我们正在证明构建这些应用程序并不迫切需要的模式。就像，您可能刚刚使用 Web 应用程序和关系数据库完成了它，它会很好。

但我们正在证明一些模式，你如何使用微服务和类似的东西构建更大规模的东西。我们了解了很多关于这样做太早的复杂性，但我们也了解了很多关于如何做到这一点的知识，以便我们可以教其他应用程序团队。这就是我加入的那种团队，我不是云上的平台操作员，但我正在与开发团队合作，与开发团队一起构建东西，以帮助他们学习如何为云构建东西。这是我第一次真正接触到银行的范围和规模。我曾在较小的小组中工作，当您开始与银行的较大部分进行互动时，您开始遇到的一件事就是，有多少孤岛，技术堆栈的多样性那种规模的组织。

比如，我们有使用 Java 的领域，我们有使用 .NET Framework 的领域，我们有很多 Python 的领域，我们有很多 Node 的领域，尤其是当组织开始构建更多的 Web 应用程序时。当你使用 Angular 构建东西并使用 npm 作为前端时，你也在使用 Node 在后端构建东西。无论这是否是一个好的技术选择，很多时候你都是在用你所拥有的东西来构建。即使在 Java 中，我们也会有团队使用 Spring Boot 构建，并且很多团队都在这样做，但是其他人对 Google Guice 感兴趣，所以他们正在构建——而不是 Spring，他们使用 Google Guice 作为他们的依赖注入框架。

或者他们有一个……比如，有大型机，对吧？您拥有庞大的技术堆栈，许多人仍在其中构建 Java EE 应用程序，并试图将其从 Java EE 的旧肮脏时代发展为更好的现代方式。一些技术对话是这样的，“好吧，你可以使用其他技术；没关系，但如果你正在使用它，而我们在这里使用其他东西，我们将无法互相帮助。当我解决问题时，我也无法真正帮助您解决问题。你必须用你的框架自己解决它。”

我曾经和一个在 Java 中使用 Vertex 的团队交谈过，我问他们：“你们为什么使用 Vertex？”他们说，“嗯，这就是我们团队所知道的。”我当时想，“从我们必须交付的意义上说，这是一个很好的技术选择。这就是我们所知道的，所以这就是我们知道我们可以成功的事情，而不是在尝试交付某些东西的同时在工作中实际学习新东西。”如果不是彻底失败，这通常是挑战的秘诀。

杰森：是的。所以，这听起来像是你进来的地方；如果所有这些团队都在做非常不同的事情，对——

亚伦：嗯嗯。

杰森：这有好有坏，对吧？这就是微服务的全部意义在于独立的团队，每个人都解耦，速度更快。但是，利用从一个团队到另一个团队的一些经验，并真正开始分享这些最佳实践，也有巨大的优势——尤其是在 RBC 规模的组织中。我猜这就是你现在在当前角色中发挥作用的地方。

亚伦：是的。这就是我们如何灵活地让人们在标准化的同时做出自己的选择，这样我们就不会出现这种巨大的蔓延，这样我们就可以在事物的基础上再接再厉？这开始是我开始真正参与社区事务并进行开发者宣传的地方。这实际上是如何发生的一部分——这是我非常幸运并且拥有优秀领导者的另一个案例——我作为云平台团队的一员工作，我曾经是一个特殊项目组，几个人离开了；我是最后一个离开的。就像，“好吧，你不能成为自己的部门，所以你是云平台的一部分。”但我不是运营商。我不接受支持轮换。

而且我表面上是在构建工具，但我主要是在做内部资源。这就是 RBC 内部资源社区开始发展的地方。我是innersource 社区的创始成员之一，并开始了这一进程。我们已经为云构建了一堆库，所以这些是内部源代码的第一批项目，我使用 OIDC 维护 Java 和 Spring 库。这有点早于 Spring Security 对 OIDC 的原生支持——所以 Open ID Connect——

我做了很多这样的事情，我支持试图采用该库的应用程序团队，我参与了其他一些早期开发人员体验的事情，你抱怨这件事作为开发人员很糟糕；为什么我们必须这样做？您被邀请参加 VP 的每周例会进行讨论，现在您正忙于尝试修复开发人员体验的某些部分。我正在这样做，我猜有些 PM 问我的老板，“所以，Aaron 没有参加我们的平台状态会议，他并没有真正接受门票，他也没有参加支持轮换。 Aaron 为云平台团队做了什么？”

杰森：[笑]。

Aaron：我的老板说，“嗯，Aaron 还参与了很多其他非常有价值的事情。”此时我正在做的另一件事是主持技术讲座系列演讲，这是一种内部会议式的讲座，我们从组织内部聘请专家，并尝试跨越我们发现的那些孤岛机器学习专家；来解释一下 TensorFlow 是如何工作的。来解释一下 Spark 是如何工作的，为什么它很棒。我们让这些专家来为 RBC 员工做内部演示。我正在这样做，并与我们拥有的联合组织者一起为运行该系列活动提供所有支持工作。

在年底，当他们启动一项新计划以真正专注于我们如何开始促进云采用，而不仅仅是人们到达平台并开始使用它并自己弄清楚时 - 你只能得到到目前为止——我的老板让我坐下来。他说。 “所以，我们真的很喜欢你一直在做的所有事情，所有这些社区的事情和类似的事情，所以我们现在要把它作为你的工作。”这就是我到达那里的方式。这不像我申请成为开发者倡导者。我一边做所有这些事情，突然之间，我 75% 的时间都花在了所有这些副项目上，这成了我的工作。

所以，这并不是最可复制的职业道路，但它是其中之一，比如，参与其中是找到你热衷的领域的好方法。所以，我改变了我的标题。只要您的经理批准，您就可以在我们的某些系统中这样做，所以我将我的头衔从非常通用的“高级技术系统分析师”更改为“开发者倡导者。”那时我开始做更多的研究，了解实际的开发者倡导者做什么，因为我想成为开发者倡导者。我想说我是开发者倡导者。

在组织中最长的时间里，我是公司里唯一拥有这个头衔的人，这很有趣，因为没有人知道该怎么处理我，因为我不像——我是不是——我不是导演，我不是副总裁。就像……但我也不只是一个普通的开发者。哪里——我不适合这个层次结构。这很好，因为人们不再担心什么是标题和类似的东西，他们只是听我说的话。因此，我确实会与开发团队进行设计咨询，确保他们知道自己在做什么，或者在他们开始使用云时意识到一堆陷阱。

我会建立很多样本，很多文档，做很多社区参与，所以去参加我们内部的活动，做很多这样的事情。我已经在做很多内源性的东西——演讲系列——但现在这是我的正式工作，它帮助我跨越了很多这些孤岛，并且非常横向地工作。这是我的工作与普通开发人员的不同部分之一，我的工作是涵盖与云有关的任何事情——至少是我觉得有趣的事情，或者我的老板告诉我需要工作的事情——以及任何地方的任何事情在接触的组织中。所以，一个用 Kubernetes 做事的开发团队，我可以去和他们谈谈。如果他们在资本市场上建立了一些可能有用的东西，我可以说，“嘿，你能把它分享到内部资源中，以便其他人也可以在这项工作的基础上发展吗？”

这真的很棒，因为我与所有这些其他团体建立了所有这些关系。在某种程度上，这也是云程序一开始就需要我做的。我向我的一位朋友解释说，这是我现在的工作。他们就像，“这听起来对你来说是一份完美的工作，因为你是技术人员，但你真的很擅长与人相处。”我想，“我是吗？我想我现在已经做了这么长时间了。”

随着我们越来越多地进行下去，另一部分是因为我与所有这些开发团队交谈，我没有被孤立，我对我正在使用的特定事物没有那么隧道，现在我可以与平台团队交谈并真正代表应用程序开发人员的观点。因为我不是在搭建平台。他们有他们的优先事项，他们有他们不得不担心的事情；我不必处理那个。我的工作是带来应用程序开发人员的视角。这就是我的背景。

我不是操作员；我不关心支持轮换，我不关心平台的一堆琐碎的事情和辛劳。有时，我的工作就是说，嘿，这份文档是善意的。我理解您是如何从平台团队的角度以及您优先考虑并想向人们解释的事情的角度来编写此文档的，但作为应用程序开发人员，我不需要构建在您的平台上运行的东西所需的信息以我能够消费的方式呈现。所以，我也喜欢向平台提供客户反馈说，“这件事很难”，或者，“你要求应用程序团队处理的这件事，他们不想关心关于那个。他们不应该关心这件事。”还有那种东西。

所以，我最终成为了这个人类路由器，有时平台团队会说，“你知道有谁在做这个，谁在使用这个东西吗？”或者找一个应用团队说，“你应该和那边的那个团队谈谈，因为他们也在做同样的事情，或者他们正在为同样的事情苦苦挣扎，你应该合作。”或者，“他们已经解决了这个问题。”因为我不了解我们使用的每一种编程语言，也不了解所有的框架，但我知道我向谁询问了 Python 问题，并且我会派团队去找那个人。然后，当我开始做这个社区工作时，其中的一部分实际上是建立社区。

最大的成功之一是，我们有一个名为“云采用”的 Slack 频道。这是每个人都去问他们的问题的地方，关于我如何做这件事来把东西放在 Cloud Foundry 上，把它放在 Kubernetes 上？我该怎么做呢？我不明白。有时我一整天都在上 Slack 频道，回答问题，非常乐于助人，并试图记录事情，试图了解人们在做什么。

这是我的一整天，有时。花了一段时间才习惯这实际上是来自开发人员背景的成功的一天。我习惯于建造东西，所以我觉得自己很成功，因为我建造了一些我可以向你展示的东西，我今天做到了。然后我会有几天和一群人交谈，但我没有任何东西可以给你看。就像，担任这个角色的困难部分。

但最大的成功之一是我们建立了这个不仅仅是我的社区。其他想要帮助人们的人，他们只是不同开发团队的开发人员，他们会看到我提出问题或回答问题，然后他们会知道答案并插话。当我开始承担更多任务时还有更多其他活动，然后我会去——我会回到 Slack 看看，哦，有一堆问题。哦，事实证明，人们能够自助。从建立社区的角度来看，这就是成功。

现在我已经通过 Tech Talks 完成了几次，包括一些开发人员体验工作，一些云采用工作，我在内部被问到，当我们围绕诸如此类的事情建立新社区时，你如何建立社区现场可靠性工程。我们将如何做到这一点？所以，我明白了——这感觉很奇怪，但这是我现在一直在做的事情之一。就像，这是一个巨大的角色，因为所有的范围。我可以和云中的任何人接触任何东西。

与角色以及银行相关的范围之一是，我们不仅拥有所有这些技术堆栈，而且我们还拥有非常非常多样化的技术敏锐度，其中有一些已经是 Kubernetes 专家的人。无论我做什么，他们都会成功。他们会弄清楚的，因为他们就是那种性格，他们会找到所有的信息。如果有的话，由于作为受监管银行的风险要求和合规要求，我们为管理我们的环境和保护环境而实施的一些限制，这些都会成为阻碍。有时我会解释为什么会有这些东西。有时我同意人们的看法。 “是的，很糟糕。我不想这样做。”

但与此同时，你会有他们只想进来、写代码、回家的人。他们不想考虑除此之外的技术。他们不一定要去自己学习东西。这不是世界末日。对于那些不断学习、不断涉足和修补的人来说，这听起来很奇怪，就像我一样，但你仍然需要人们保持开灯，同时完成所有其他工作。而那些乐于这样做的人，这也很有价值。

因为如果我担任那个角色，我会不高兴。一个快乐的人，比如，这对整个组织都有好处。但是他们需要学习的东西，需要向他们解释的东西，他们需要成功的帮助是不同的。那么，挑战之一就是弄清楚如何应对所有这些客户？有时甚至这些客户的答案是——这是关于我的角色的事情之一——就像定义是客户成功一样。

如果你试图放在云端的应用程序不应该放在云端，我的工作就是告诉你不要把它放在云端。把你放到云端不是我的工作。我希望你成功，而不仅仅是到达那里。我可能会在一个下午把你的东西放到云端，但如果我走开它就坏了，就像，你不知道该怎么做。所以，关于我们如何教人们自助服务，我们如何让我们的内部系统更加自助服务的很多事情，这些都是我现在所关注的事情。

范围这么大，我该如何管理自己的时间？就像，我需要弄清楚我没有将一千件事情向前推进一英寸，但我正在将事情完成。而且我正在学习，在不管理人员的同时，仍然委派并与社区合作，与更广泛的云平台团队合作，围绕我如何放手并帮助其他人做事？

杰森：所以，你提到了我认为非常有趣的东西，对，帮助人们完成目标的目标，对吧？而且我认为这是一件非常有趣的事情，因为我认为，在那个倡导角色中，通常会有这样的想法，比如，我会帮助你摆脱困境，然后你可以继续前进，而不知道他们在哪里'最终走向。这种联系又回到了你之前所说的关于作为一名开发人员开始的事情，你在那里构建东西，你只是，比如，释放它，[笑]你不会想到，你知道，那天二，操作，维护，持续的东西。所以，我很好奇，随着你在事业上的进步，当你从帮助人们中获得更多智慧时，当你帮助人们完成任务时会是什么样子，同样的心态是一个将运行相当长一段时间的应用程序。即使在短期内，你知道，如果这是一个短期的事情，但我觉得在银行，大多数事情可能有点长期存在。你如何平衡呢？您如何处理这个问题，帮助人们完成工作，但同时牢记他们必须这样做——这个应用程序必须保持生存并且必须维护？

Aaron：是的，很多都是——比如，我们使用的术语是可持续发展。其中一部分是消除摩擦，试图让开发人员能够专注于，我猜，行业中经常使用的术语是他们的内部循环。毫不奇怪，银行经常有很多摩擦很大的流程。有很多开放的票，等待事情。这是我与开发团队对话的部分，我问他们：“有哪些困难的事情？你不喜欢的东西是什么？你希望你不必做或关心的事情是什么？”

当你和他们交谈时，其中一些是在字里行间读出来的；与其说是采访他们。就像，任何类型的需求收集，通常不是他们说什么，而是他们说什么然后你看，哦，这就是问题所在；我们如何解决这个问题，以便人们可以到达他们需要去的地方？这种形式的反馈是我对我们建立的系统、我们在平台周围建立的流程、我们所研究的一些工具的一些反馈。我真的非常喜欢 Docker 和 Solomon Hykes 的理念，“包括电池但可拆卸”。我希望开发人员有一个高基线作为起点。

这部分来自我使用 Cloud Foundry 的经验。 Cloud Foundry 为很多事情提供了非常好的开箱即用的开发体验，“我只有一​​个 Web 应用程序。运行它。是 Nginx；这是一些 HTML 页面；我不需要知道所有的细节。让它去吧，把网址给我。”

我希望为应用程序团队提供更多这样的服务，因为他们有很高的工作基线作为起点。每个组织最终都会在他们拥有的地方构建这个——比如 Netflix：Netflix OSS 或带有 Finagle 的 Twitter——在他们拥有的地方，“这是我想要插入的周边部分，每个人都可以作为起点。我们如何提供安全保障？我们如何提供所有这些是应用程序团队主要关注的部分，他们必须做，我们知道他们必须做？”其中一些是只有在云上才开始出现的东西，并试图为应用程序团队提供更多的东西，这样他们就可以专注于业务，只在需要时才进入杂草。

Jason：当你在谈论这些框架时，你知道，拥有人们可以拥有的高质量或高基线工具，对，为他们配备一个不错的工具箱，我猜你的内部资源'正在努力也有助于促进这一点。

亚伦：哦，非常好。随着我们的发展和成熟，我们的内部资源组织，其中很大一部分也是其他团体，他们在那里找到了我们需要的东西。他们会说——它最初是，“我们建造了这个。我们会将其放入内部资源中。”但是你得到的是非常有针对性和特定于他们的团队的东西，也许其他人可以使用它，但如果不稍微弯曲它，他们就无法使用它。

而且我讨厌弯曲软件来适应它。这是其中一件事——在我们拥有现有流程的企业环境中，这是一件非常普遍的事情，我们需要采用它，然后将其弯曲直到它适合我们现有的流程，而不是采用某些工具使用的标准方法，因为我们不想改变我们的流程。这会变得很困难，因为你会遇到奇怪的边缘情况，因为我们弯曲了它，所以它正在做一些奇怪的事情。就像，嗯，那不是它的错。随着我们开始做更多的内部资源，更多的事情真正首先成为内部资源，团队意识到我们需要一起解决这个问题。

让我们一起开始工作，让我们将 API 设计为一个组。 API 设计真的非常非常难。以及我们如何使用共享库或服务来做事。作为一个团队，我们会看到更多这样的事情，更常见的事情是，“嗯，这是我们需要的东西。我们将在内部源中启动它，我们会让一些人使用它，他们将成为我们的测试版客户。我们会在没有真正专门针对应用程序和应用程序团队的需求的情况下通知它。”

因为他们都有特定的需求。这就是“包含但可移动”部分的用武之地。我们如何在我们拥有通用解决方案并且您可以插入您的细节的情况下可扩展地构建东西？而且我们仍然——就像，这不是一个容易的问题。我们仍在解决它，我们仍在努力解决它，我们正在做得更好。

很多问题只是我们如何才能日复一日、年复一年地改进，以使其中一些事情变得更好？甚至我们的持续集成和交付管道到我们的云，所有这些都在不断变化和不断发展。我们支持多种语言；我们支持不同语言的多个版本；我们正在谈论，嘿，我们需要开始采用 Java 17。我们的库或管道还没有这样做，但我们可能应该继续这样做，因为它已经发布了 - 什么 - 快一年了？并且真正致力于分解其中一些我们为当时需要的东西而构建的东西，但现在感觉有点死板。我们如何拉出碎片？

在 log4j CVE 和对行业的广泛影响之后，组织中的一大推动力是我们需要围绕软件供应链做更彻底的工作，围绕知道我们拥有什么，确保我们进行扫描和一切.这就是管道工作的用武之地。我正在就管道问题进行咨询，并提供大量客户反馈；我们有一个团队全职工作。但是做很多这样的事情并尝试为我们需要的东西而构建，但也不要将自己与更广泛的行业隔离开来。就像，从工具的角度来看，我的噩梦是我们限制事物，我们围绕安全或政策或类似的东西做出决定，我们将自己与更广泛的 CNCF 工具生态系统隔离开来，我们不能使用其中任何一个工具。这就像，好吧，现在我们必须自己构建一些东西，或者——我们永远不会像外部社区那样做。或者我们只会有一些糟糕的流程，没有人会高兴，所以要弄清楚所有这些。

杰森：是的。你提到的关于保持速度和拥有这些标准的一件事让我想起，你知道，类似于我之前的经历，基本上，我在一个我们说我们想开放的组织-source，我们使用了开源，这基本上意味着我们分叉了一些东西，然后对它进行了我们自己的奇怪修改。这意味着，就像现在，它不是真正的开源；这就像一个奇怪的、被黑客入侵的东西，你必须不断维护并努力让它与最新的东西保持同步。听起来你在一个更好的位置，但我很好奇，在跟上最新的东西方面，你是怎么做到的，对吧？因为你提到银行，显然慢了一点，采用更成熟的软件，但是你，对，你站在最前沿，你正在努力收集你可以使用的最佳实践和新技术银行，作为一个没有使用最新、最棒的东西的人，你如何做到这一点？您如何使这些技能和知识保持最新？

Aaron：我尝试阅读，我尝试腾出时间阅读 The New Stack 之类的东西，收听有关技术的播客。这是一个非常广泛的行业。我能跟上的只有这么多。这总是可以追溯到很久以前的对话之一，在那里我会与我的老板就我去参加会议的商业主张进行对话，并解释，比如，在一个组织中获取知识的成本是多少？虽然我们可以引入顾问，或者我们可以雇用人员，例如，当您雇用新人时，他们会带来他们先前存在的经验。所以，如果有人进来并且他们知道 Hadoop，他们可以提供有关 Hadoop 解决这个问题的信息和想法吗？也许，也许不是。

如果我对 Hadoop 或 Kubernetes 一无所知，或者……比如在我的工具中使用 Tilt 或 Skaffold 之类的东西，我不想在这个项目上打赌。这是我参加会议的收获之一，现在一切都是虚拟的，我实际上需要留出更多时间来观看视频。就像，没有那个专门的一周是一个问题，我只是断开了连接，我没有处理任何事情。当你在工作时，即使 KubeCon 或 Microsoft Build，我仍然在做我的日常工作，我收到 Slack 消息，而且我不觉得我可以忽略别人。我可能应该花更多的时间，但我如何保持最新状态的一部分。

它真的做了很多阅读和研究，做这样的对话，比如，我们邀请你去哪里的 DX Buzz……我解释了那个事件——它与内部扬声器相邻——我解释说因为我有积压的视频来自我没有看的会议，如果我让其他人和我一起吃午饭来观看这些视频，我必须看视频，因为我正在主持会议来讨论它，现在我至少会看一个月。事实证明，这在组织内部传播知识、与人交谈是一件非常成功的事情。而我做的另一部分，尤其是在工具方面，我仍然在构建东西。尽管我不像以前那样编写代码，但我带来了应用程序开发人员的观点，但我不再每天都编写代码了。

我总是说这会让我很痛苦。它不是。我仍然在想它，当我开始编写代码时，我一直在寻找如何改进这个设置？我怎样才能使用这个工具？我可以试试吗？这是否更好？这对我来说更顺畅，所以我不担心这件事吗？

然后在开发人员体验小组、我们的 DevOps 团队、我们的平台团队中更广泛地传播这些信息，并与这些团队讨论他们使用的东西。就像，我们在一个小组中使用 Argo CD，我没怎么接触过，但我知道他们有很多专业知识，所以和他们谈谈。 “你怎么用这个？这对我有什么好处？我该如何进行这项工作？我也怎么用？”

Jason：我认为这太不可思议了，[笑] 正如你一直在聊天的那样，你提到银行使用或正在使用的工具和技术有很多。两者兼而有之——这很有趣，就像银行里发生了很多事情一样；你如何管理这一切？但我认为这也非常有趣，因为它表明人们对找到正确的解决方案和找到正确的工具很感兴趣，而不是真正超级强烈地与一种特定的工具或一种固定的做事方式结合，我认为这很酷。我们在这里的时间即将结束，所以我确实想问你，在我们签字之前，亚伦，你有什么想要插入的东西，有什么想要宣传的吗？

Aaron：是的，云计划正在招聘大量人员。我们所有的平台团队都有很多职位空缺。我的云采用团队可能有职位空缺。所以，如果你觉得这家银行听起来很有趣——这家银行非常稳定；这总是一件好事——但是银行……关于银行的事情，我最初加入银行时说，“哦，我会在这里两年，我会感到无聊，我会离开，”和现在已经12年了，我还在银行。因为我提到了组织的范围和规模，所以总会有一些有趣的事情发生在某个地方。

所以，如果你对云平台的东西感兴趣，我们有一个巨大的云平台。如果你在——比如，你想做机器学习，我们有一个完整的组织。毫不奇怪，我们在银行拥有大量数据，并且有一个完整的组织来处理各种不同的事情，包括机器学习、深度学习、数据分析、大数据等。就像，如果你认为这很有趣，即使你不是专门在加拿大多伦多，你也可以在组织中找到一个有趣的角色，如果这会让你变得疯狂。

杰森：太棒了。我们将发布我们提到的所有内容的链接，这是一个吨。但是去看看我们吧，gremlin.com/podcast 是你可以找到本集节目说明的地方，我们将提供所有内容的链接。亚伦，非常感谢你加入我们。很高兴有你。

亚伦：非常感谢你邀请我，杰森。我很高兴我们必须这样做。

Jason：有关上述所有信息的链接，请访问我们的网站 gremlin.com/podcast。如果您喜欢这一集，请订阅 Spotify、Apple 播客或您最喜欢的播客平台上的 Break Things on Purpose 播客。我们的主题曲名为 Komiku 的《Battle of Pogs》，可在loyaltyfreakmusic.com 上找到。

本文：https://jiagoushi.pro/podcast-break-things-purpose-developer-advocacy-a…