Charles Humble与金融时报前工程启用技术总监Sarah Wells交谈。他们讨论了技术总监的角色，探讨了什么是开发人员启用（AKSA为开发人员经验/DevEX和开发人员生产力），DevEx工具的例子，运行一个内部技术会议，她即将出版的书和阅读建议。
关于采访对象
Sarah是一位技术领导者、咨询师和会议发言人，专注于微服务、工程启用、可观察性和devops。她在产品、平台、SRE和devops团队中拥有超过20年的开发者、首席工程师和技术总监经验。
萨拉在英国金融时报工作了十多年，领导其转型为一个真正的云原生组织，发布代码的频率是原来的250倍，并接受自主授权的团队。
她目前正在为O'Reilly写一本关于微服务成功的书。这本书涵盖了技术、文化和组织方面的挑战，你需要应对这些挑战，才能从基于微服务的架构中获得最大收益。
提到的资源
Matthew Skelton和Manuel Pais的《团队拓扑》
Sarah Wells的《WTF is Alert Fatigue》
Sam Newman的《Building Microservices, 2nd Edition》
Nicole Forsgren Jez Humble和Gene Kim的《Accelerate》
Camille Fournier的《经理之路》
Atul Gawande的《Checklist Manifesto》。
完整的文字记录
简介
查尔斯-汉博。
大家好，欢迎来到黑客组织，这是WTF is Cloud Native的播客。团队的播客。我是Charles Humble，Container Solutions的主编，今天和我一起的是Sarah Wells。Sarah是一位技术领导者、顾问和会议发言人，主要关注微服务、工程启用、可观察性和DevOps。她在产品平台、SRE和DevOps团队中拥有超过20年的开发者、首席工程师和技术总监经验。她在《金融时报》工作了十余年，领导其转型为一个真正的云原生组织，发布代码的频率约为250倍，并接受自主授权的团队。她目前正在为O'Reilly写一本关于实现微服务成功的书。莎拉，欢迎来到节目。
萨拉-韦尔斯。
嗨，很高兴能参加这个节目。谢谢你邀请我。
Charles Humble。
我想问你，因为你在FT，这显然是一份报纸，当你离开时，他们有没有为你做一个头版？
萨拉-韦尔斯。
他们做了。说实话，当你离开FT的时候，最好的福利之一就是有人会写很多故事，实际上我的故事是印在适当的FT纸上的，它实际上是在印刷厂被印出来的。所以我有几张这样的纸。是的。
查尔斯-汉伯。
哦，那真是非常非常好。
萨拉-韦尔斯。
在报社工作，有两件事情是非常好的，就是你没有想到的事情。一个是主页。另一件是你从来没有买过任何包装纸，因为每一件送给别人的礼物都是用FT纸包装的。
你是如何得到技术总监的职位的，当你到了那里，你是如何发现的？
查尔斯-汉伯。
绝对是太棒了。我在介绍中说，你从开发人员到首席工程师，再到技术总监，我真的想关注最后一个转变，即首席工程师到技术总监的转变，部分原因是这是一个相当大的进步。我认为这是其中一个角色的性质可能发生很大变化的地方。我只是好奇地想知道，我想很多听这个播客的人可能都在那种经理的晋升道路上。那么，你是如何得到这个角色的，当你到达那里时，你是如何发现它的？
萨拉-韦尔斯。
我同意，这是一个相当不同的事情。而且我认为一般来说，首席工程师是一个个人贡献者的角色。在FT，它并不完全是。所以我作为首席工程师的角色，是领导内容发布平台的，所以我确实有一些直线管理的责任，我所做的事情可能看起来像一个微型的技术总监的角色。所以我非常幸运，组织的那部分工作方式，让我接触到了很多能够帮助我晋升的东西。因为，标准的首席工程师角色，你主要考虑的是技术战略等问题。而当你晋升为技术总监时，你会更多地考虑到组织方面的事情，我想。我已经有了一些这方面的经验。
萨拉-韦尔斯。
但对我来说，发生的方式是，有一个提案，是由现有的一个主管发出的，内容是我们要如何在FT做非工作时间的支持。我的团队已经做了一段时间的时间外支持，并研究如何最好地做到这一点。我看到了这个提案，并得到了相当多的反馈。我得到的反馈太多，以至于我不再在谷歌文档上写评论，而只是创建了我自己的提案。我没有意识到的是，已经有一些人在考虑作为运营和可靠性的技术总监的角色。因此，几乎是意外地，我肯定把我的帽子放在了这个圈里，因为我只是对这个领域的一些问题非常明显地感兴趣，希望得到解决。通过学习如何运营和管理一个由微服务构建的新系统的团队，使我处于一个非常好的位置，可以升任技术总监，以解决整个FT的一些问题。
将DevOps文化引入FT是一种什么样的体验？
Charles Humble。
这有点像谈话中的题外话，但我记得你谈到了在一个成熟的组织中转向DevOps的一些问题，即 "你建立它，你运行它 "的文化。所以在一个有成熟的IT团队的组织中。我记得你说过，让每个人都随叫随到不一定实用。我可能有年幼的孩子，或者我可能是一个老年亲属的照顾者，或者我的生活中可能有其他事情发生。我认为，如果我加入了Netflix或其他公司，我事先知道这是一种文化，这是一回事，但我感兴趣的是，你是如何将这种文化引入像FT这样的现有机构的。
萨拉-韦尔斯。
是的，我认为如果你想让开发人员对他们的系统出现的问题进行某种程度的升级，我认为你应该这样做。如果你特别是在构建微服务，但我认为一般来说，如果你知道你最终将不得不支持它，你就会以不同的方式构建。我认为，如果你要这样做，你必须想出一个办法，让人们根据自己的需要，永久或暂时地脱离它。如果你不能组成一个轮值表，你就有问题了。在FT，我们一般都能做到这一点，但有时你不得不退一步说，我们没有很多人愿意为这个做支持。这是否意味着有一个更重要的问题？当然，在我自己的小组中，在内容发布方面，当我们想开始做非工作时间的时候，我们问了所有的开发人员，是什么让他们对在最佳努力的基础上注册做这件事感到犹豫。
萨拉-韦尔斯。
很多让人担心的事情都是架构。所以有一种感觉，就是我们使用的这个特定的数据存储，真的很难支持，而且我们认为这不是适合我们的解决方案。因此，事实上，我们确实改变了我们使用的数据存储，以便人们感到更舒适，能够支持它，以防出错。因此，我认为不强制要求它是有帮助的，因为它可以帮助你识别出你有什么东西是人们不希望支持的。我认为，只有在人们不经常被叫的情况下，你才能做一个最佳努力类型的非工作时间轮值。
你能描述一下FT的架构吗？
查尔斯-汉博。
是的，我非常同意这一点。实际上，我认为这是一个非常重要的事情，需要关注。现在你提到了数据存储，这让我们对FT的架构有了一点印象。我倾向于认为FT是非常面向Java的，但我推测随着你们变得更加云原生，它在架构上变得更加多样化。你能告诉我们一些情况吗？
萨拉-韦尔斯。
是的，它非常多样化。所以编程语言，有很多团队在使用Node。也有使用Go的人。所以Go更倾向于用于后端服务，所以API。有相当数量的Python，倾向于用于做更多基础设施的团队。很少有Java。我不认为有任何真正活跃的Java开发，但可能有一点，但仍有Java在生产中运行。所以我们的一些微服务架构，FT的一些微服务架构最初是用Java编写的。所以其中一些仍然存在。一般来说，它是基于AWS的，但也有一些东西在其他云上。在FT有很多应用程序是在Heroku上运行的。所以把很多责任交给了Heroku，而不是要从头开始建立一切。因此，它是相当多样化的，当你试图为所有这些团队提供支持和建立工具时，这是一个有趣的挑战。
是什么促使你转到开发者支持领域？
查尔斯-汉伯。
这实际上为我们提供了一个非常有用的切入点，即我想谈的下一件事，你从技术总监的角色转到了开发人员启用领域，工程启用。是什么促使你这么做的？这是你想进入的事情吗？
萨拉-韦尔斯。
更多的是我已经有几个团队在我的小组里，为工程团队建造东西。我们只是增加了一些其他的团队，所以最终所有为其他工程师制造东西的团队都属于我是技术总监的一个小组。因为如果你要尝试，我认为，做开发人员的生产力工具，做工程启用，它有助于有一个共同的方法来处理一切。因此，让每个人都成为一个小组的一部分，意味着我们可以决定我们应该把精力集中在哪里，以及我们将如何去做它。因此，例如，我们可以说，我们想把所有的文件放在一个地方，以便每个人都能找到它。我知道这听起来很明显，但实际上随着时间的推移，你最终会发现文件到处都是。你会发现有些人在使用一种格式，有些人在使用不同的东西。我们希望能有一个共同的东西。因此，你可以去运行一个搜索和一套文件，找到你需要的所有信息。
萨拉-韦尔斯。
所以这就是背后的意义。所以，在FT有一个现有的小组，是为工程师做事的小组和为FT普通员工做事的小组的混合体。因此，我们把它们分开，我认为这让两个小组都真正了解了谁是他们的利益相关者。
你能定义一下什么是 "开发者能力 "吗？
Charles Humble。
我们也许应该暂停一下，澄清一下术语，因为我们正在谈论工程启用，但还有其他经常使用的术语，比如开发者生产力或开发者经验/DevEx。这些术语是否可以互换？它们的意思是一样的吗？还有，当你谈论工程启用时，你是什么意思？这到底是什么？
Sarah Wells。
所以我认为它们是非常相似的，我想我可以很好地互换使用它们。我认为它是指你为产品开发团队编写工具和平台来做事情的地方。当然，我认为如果你是在一个组织内，我可能会谈论工程启用。而如果我是一家开发工具的公司，然后卖给人们，我可能会说是开发人员的生产力，但我认为这都是同样的事情。这是一种认识，虽然我们可以用微服务架构这样的东西快速发展，但你要尝试为每个人提供一个构建服务的基础，这样你就不必在很多地方重复同样的工作。
Charles Humble。
是的。我还认为，也许可以减少一些小的摩擦点。哦，我需要两分钟来启动一个集群，如果我们能加快这个速度，我就不会一直被打破流动状态，或者，我的意思是，你刚才提到的文档，这是一个经典。去寻找，哪里有这个的API文档。我找到正确的了吗？它是最新的吗？以及所有这些东西。所以我认为这其中肯定有一部分，就是消除这些小的摩擦点。这不是很有魅力的工作，但它是一种重要的工作，我想。
萨拉-韦尔斯。
我认为基本上，如果你希望你的产品开发团队提供商业价值，你希望有一个新功能的工作流，那么你希望使他们做的大部分事情，他们可以做，而不必与外部团队协调。因此，如果你看一下《团队拓扑》，我认为这是一本很好的书，谈论的是团队如何相互合作，你真的想让大多数事情都是自助式的，有据可查，建立有趣的工具。事实上，这可能是相当酷的，想想我如何解决这个问题，使其他团队可以做他们需要的事情，同时我们仍然保持对风险和成本的控制水平，这是我们作为一个公司想要的？那么，你在多大程度上让人们去做事情？
萨拉-韦尔斯。
所以，我非常喜欢FT的一件事，就是支持FT的DNS的团队写道，我们在三四年前迁移到了一个新的DNS供应商。他们采用了 "基础设施即代码 "解决方案。因此，要对DNS进行修改，基本上是在repo中进行修改，然后提出一个PR，该团队就会批准拉动请求。但他们与客户交谈，并说，你喜欢什么？你不喜欢什么？人们说，嗯，这真的很好，但我经常在等人批准，而且这是一个相对低风险的变化。因此，他们分析了他们所有的拉动请求，大约有150个，他们确定了某些模式，即事情总是在没有任何讨论的情况下被批准。他们研究了创建自动批准的规则，这样就真正加快了进程，因为他们看的是风险很低的东西。
萨拉-韦尔斯。
你正在删除DNS配置的整个部分，或者你正在添加一个全新的部分，或者他们可以识别可能有安全影响的事情，并立即将其发送给安全团队的人，以便他们可以立即批准它。我喜欢这一点，因为它真的超越了基础设施的代码，变成了你在考虑如何在不引起太多风险的情况下加快人们的速度。因此，80%的时间，它是好的。20%的时候，你要和团队讨论，解释你要做什么，并确保它没有风险。
你是如何在FT建立开发者授权团队的？
查尔斯-汉博。
你是如何在FT建立开发者支持团队的？
萨拉-韦尔斯。
我们有很多团队都在这个领域工作。当我们把这个团队组织起来的时候，我们利用这个机会研究了一些事情，我认为在任何组织中，经过一段时间后，由于历史原因，你有一些事情并不在正确的位置。因此，当你试图对每个团队说，你们是做什么的？你可能会发现，他们说，好吧，我们做这个，但我们也有其他三个服务，由于某种原因，我们拥有。因此，我们做了一些移动的事情，但我们试图确保我们的每个团队都有明确的责任，你可以解释为什么这是一个单一的事情。所以有一点，与我一起工作的许多不同的人做了一些分析，你需要做什么来为人们提供一个平台。我们比较了每个人放在一起的东西，并思考，是否有任何差距？是否有任何差距，我们也没有解决特定的问题？
萨拉-韦尔斯。
然后，一旦我们组建了这些团队，我们就给他们很大的自由，让他们想办法解决什么问题。因此，我们鼓励团队与他们的客户交谈，找出哪里有问题。我非常渴望，因为我们成立了这个新的小组，试图解决一些以前难以解决的问题，因为他们不在组织的同一个部分。有时你需要很多团队一起工作，以解决一个问题。如果他们在不同的小组，他们可能没有相同的优先事项。这时我可以说，好吧，这将是我们的一个优先事项。因此，我们正在寻找，例如，在钥匙轮换方面，我们有一个政策，每隔一段时间自动轮换钥匙。对很多产品团队来说，这感觉是件麻烦事。而且令人惊讶的是，它经常与生产问题联系在一起。因为你会发现有人轮换了一把钥匙，但他们不知道这把钥匙还在其他地方使用，而且他们没有轮换那个版本的钥匙。而当他们禁用旧的钥匙时，其他的东西就坏了。
萨拉-韦尔斯。
因此，我们研究了如何使这个过程更加顺畅，人们会被告知这个过程正在发生，我们也许可以把一个消息放在一个队列中，然后他们可以使用这个消息，使整个过程自动化。
你能给我举一些其他的例子，说明你作为开发能力的一部分所建立的工具吗？
Charles Humble。
你能不能给我一些其他的例子，也许是你作为开发能力的一部分所建立的一些工具？给我们描述一下你所做的那些事情吧。
萨拉-韦尔斯。
我想说的是，你要做的一件事是，你要让人们有能力看到他们在某些方面的表现。所以你想让他们了解。如果你有你希望所有团队做的护栏，如果你能向人们展示他们在这方面做得如何，那就很好。因此，我们有一个相对早期的工具，它已经存在了几年，我们建立的工具被称为SOS，即系统可操作性得分。但基本上，我们正在寻找提高我们运行簿的质量。因此，当一个系统出现问题时，是否有一个像样的运行手册，向人们解释在哪里可以找到代码，在哪里可以找到日志，他们可以做什么样的故障排除？因此，这就是我们对各种可用的领域进行评分的地方。我们已经有了一个叫做BizOps的系统，它是一个有效的系统注册表和关于我们所有系统的信息图表，这是一个基本的东西，当你有微服务时，你需要知道你有什么以及谁拥有它。
萨拉-韦尔斯。
但SOS会查看运行手册的信息并自动评分。我们可以汇总这些信息，所以我们可以显示一个团队在他们所拥有的所有系统中的表现，以及不同的开发人员小组的表现。因此，我们认为这是一个小的游戏化，这可能是相当好的。我们确实发现，一些团队变得非常有竞争力，他们喜欢这样，他们想达到100%的覆盖率，他们想告诉其他团队他们比他们做得更好。所以这是一个方面。
萨拉-韦尔斯。
但是，在我们创建这个系统之前，我们还没有意识到，如果你有一个组织，就像金融时报所做的那样，使用目标和关键结果来计划工作，关键结果需要是可衡量的。因此，我们只是给了每个人一个简单的方法来衡量他们是否在改善能够操作他们系统的某个方面。因此，产品团队会说，我们要在本季度将我们的SOS得分提高25%。因此，鼓励人们，它向他们展示了他们可以产生影响的地方，并鼓励他们这样做。因此，我认为洞察力通常是非常有用的，但我认为你必须非常谨慎，不要试图把太多的数据卷进一个分数，因为它可能没有意义。试图汇总太多信息可能没有意义，但我认为能够显示许多不同的方面，使人们能够看到他们是如何做的，真的很好。所以这就是一个例子。
萨拉-韦尔斯。
所以我认为，那些能促使你遵守我们期望你做的事情的东西，以及那些能让你作为一个团队看到你在某些方面做得如何的东西，真的很有用。然后，用于解决你所遇到的常见问题的自助服务工具，我认为是一个非常重要的方面。我喜欢你采用Unix风格的理念，即你可以把许多小工具组合在一起，以解决一个问题。因为这意味着人们不必使用所有的东西，但他们可以根据需要使用许多不同的部分。
你认为当你在建造一条铺设好的道路时，什么是重要的？
查尔斯-汉伯。
然后有了这个，我认为你有点走向这个铺路或金光大道的想法了。这些术语，我认为是Netflix的一种普及。你认为当你在建造一条铺设好的道路时，什么是重要的？
萨拉-韦尔斯。
是的。所以我认为，对我来说，做一条铺路的路或一条金光大道的事情是，它与思考建立一个平台的老方法不同，因为它不是，这是你的大平台，你要把你的代码部署到这里。它更多的是，这里有一大堆东西，可以帮助你快速前进，但它不是强制性的，如果你想走弯路，我们有一个方法。所以这个想法是，你铺好这条路，沿着铺好的路走很容易，它会为你做一切事情，但你可以走非公路。只是你将不得不在丛林中砍伐，这意味着对你来说将是更难的工作。而你可能会选择这样做，但你应该明白，有些事情你是要做的。
萨拉-韦尔斯。
所以这个想法是，如果你在铺好的路上，它应该只做需要的一切。但是，如果你决定我不打算使用现有的工具部署到AWS，你将不得不确保有日志聚合，有监控，并且我们有意识地注意安全和任何其他可能存在的护栏。因此，我喜欢这个想法，在铺好的道路上，你已经定义了离开道路意味着什么。我喜欢它不是强制性的，因为我认为它使那些正在铺设道路的团队思考他们是否正在建造客户想要使用的东西。
如果不强制采用，你如何推动你正在建造的工具的采用？
Charles Humble。
但是，如果不强制采用，你如何推动采用你正在建造的工具？
萨拉-韦尔斯。
我认为通过建立一些能解决人们问题的东西。因此，如果你所建立的东西不能使人们更容易在交付商业价值方面取得进展，而且他们不使用它，那么就有一个问题，你为什么要建立它。在一个公司里，你应该能够建立一些对你的客户真正有用的东西，因为他们就在你身边，你只需要为那个公司和那个组织解决一个问题。因此，如果你考虑到所有那些在那里建立开发者工具的团队，他们向人们出售工具，他们必须努力找到适合一系列公司的市场。但是，如果我在FT构建一些东西，我可以构建一些非常定制的东西，我已经知道FT存在的东西。举个微不足道的例子，我只需要考虑支持使用GitHub的源码控制，因为他们正好有这样的系统。
萨拉-韦尔斯。
所以我认为你应该能够建立一些对你的客户有用的东西，但是你必须在这些团队中有一个产品思维，这意味着你要了解问题所在，而且你还需要有这样的认识：人们可以说，哦，是的，这听起来不错。但是，除非你承诺他们真的会使用你建造的东西，否则你可能没有解决他们的问题。我认为很容易说，是的，这听起来不错。你真正想要的是有人说，这听起来很好，我们承诺在下个季度或本季度花一个月时间采用它，那就更好了。
当你决定建立什么工具时，实际的过程是什么？
查尔斯-汉伯。
当你决定建立什么工具的时候，实际的过程是怎样的？开发人员会向你提出这个问题吗？你是否坐下来与作为你的客户的各种开发人员进行访谈，并试图弄清楚他们的痛点在哪里，以及你建立什么？你是怎么做的？
萨拉-韦尔斯。
所以这是一个混合的东西。因此，有时主要的工程师或我的小组内的人将说，我认为这是一个问题，我们应该研究它。而我们也可以做这件事。总是有一个元素，那就是我们要花多长时间来解决一个特定的问题？是否有一些我们认为有价值的东西实际上不需要我们花那么长时间？我们也许应该看看这个。我们与我们的客户团队谈了很多，在很多不同的层面。因此，FT的很多其他团队都会有开发人员聚会或某种地方，开发人员在那里讨论问题。如果我们能定期去参加这些会议，我们就能听到人们正在苦苦挣扎的事情，并思考，哦，这是否是我们可以解决的问题？当你开始得到一个愿意倾听的声誉时，人们就会来告诉你这个问题很重要。
萨拉-韦尔斯。
你也可以看看人们在个人的开发团队中正在做什么，看看这是否是你可以采用的东西，并使其更加可用，更加广泛，因为一个团队可能建立一个非常好的工具。对这个团队来说，要想让它成为通用工具，让每个人都能使用它是非常困难的。但你作为一个中央工程使能团队可以做到这一点。因此，我们会寻找人们喜欢的、他们已经建立的、他们认为好的东西，我们也可以考虑把这些东西变得更加通用。
你认为在一个组织中引入工程启用功能的正确时间是什么？
Charles Humble。
如果我们能更上一层楼，你认为在一个组织中引入工程使能功能的正确时机是什么？
Sarah Wells。
我认为这是关于你看到很多人试图解决同样的问题。因此，我认为即使是在一个从事特定系统工作的群体中，你也会发现有一些人在试图建立更多的基础设施和支持性的东西，在它下面。因此，如果你正在建立一个单体，你有几个团队，会有几个人在建立构建管道的工具，以及与供应商的各种互动，等等。当它开始增长时，你会有一些事情，你不希望在每一个小组中解决它。因此，你不希望在每个小组中都要解决与DNS的互动。因此，你自然会有一些团队存在，支持组织的其他部分。而在这一点上，这些团队正在做一些能够实现工程的事情。
萨拉-韦尔斯。
我只在一个有250名开发人员的组织中得到过这方面的经验。但我认为，一旦你有足够多的人在工作，那么抽象出一些需求并将其交给其他团队是有意义的。你开始考虑工程启用，即使你没有一个完整的小组在做这个工作。但我认为，一旦你有了几百人，一旦你在构建微服务，而且你足够大，人们不知道其他团队在做什么，有这些共同的支持功能是很有用的。
你为什么决定引入内部开发者大会？
查尔斯-汉伯。
回想一下你在FT的时间，你做的另一件事是帮助引入了他们的内部开发者会议。因此，我很想知道你是如何开始做这件事的。是什么促使你建立这个会议，以及这个经验是怎样的？你在做这件事时有什么发现？
萨拉-韦尔斯。
大概七八年前，我和其他几个来自FT的首席工程师一起去参加一个会议。这真的很有趣，因为当我刚开始参加金融时报的会议时，我们并不领先于游戏。所以我们经常去参加一个会议，然后想，哇，这真的很有趣。我想知道我们是否可以使用这项技术。但是，我们第一次去参加一个会议，人们正在谈论一些东西，我们想，哦，实际上这是关于微服务的，我们已经有点知道。然后我还意识到，我从与FT的其他主要工程师的交谈中得到了最大的价值，而这些人我每天都不和他们交谈。因此，在走廊上，只有FT的其他工程师是非常有价值的。所以我和一个同事，Rob Godfrey说，我们应该开一个内部会议。
萨拉-韦尔斯。
那会很好，因为我们可以分享我们都知道的东西。而且，这可能会帮助团队了解其他团队所受到的限制。我们当时向首席技术官建议，他只是说，是的，很好。让我们在三周内完成它。所以我们说，能不能给我们一点时间来组织这个活动？然后我们有几个月的时间，我们组建了一个主要由首席工程师和交付人员组成的小组。我们举行了第一次内部会议，从那时起，FT每年都有一次会议，它们非常不同，它们相当程度地反映了首席信息官或首席技术官正在寻求关注的问题。因此，第一次会议在很大程度上是基于小组的。我们认为我们没有足够的人愿意站起来说话，小组讨论不那么令人生畏，我们让他们讨论各种主题，并就某一特定主题进行发言和讨论。
萨拉-韦尔斯。
到了后来的会议，更多的是混合了闪电讲座、长篇讲座，我们做了非会议的会议。他们一直非常受欢迎。这就是我们有一个开放的时段，任何人都可以建议一个主题。任何人都可以选择去加入关于该主题的讨论。这是在查塔姆大厦的规则下进行的。因此，你不会特别引用任何人的话，但你会得到一些非常有趣的讨论的东西。
萨拉-韦尔斯。
我喜欢内部会议的原因是，这是一个机会，可以认识到你有很多人有非常有趣的事情要讲。这也是我作为领导为事情定下基调的一个机会。所以我肯定会把事情记在心里。几年前，由于大流行病的原因，我们举办了第一次完全在线的版本，实际上效果非常好。第一个小时是人们讲述关于生产中出错的故事。我想讲这些故事，因为我认为这是一个真正的高能量，他们很有趣，让每个人开始。但同时，作为金融时报的运营主管，负责这方面的工作，我想让人们明白，这很好。事情会出错。一般来说，人们会提供帮助，一切都会得到解决。因此，这是在传递一个信息，即这是正常的。这很正常。我希望你能告诉我，如果你认为有什么东西坏了。
查尔斯-汉伯。
实际上，我是这个的忠实粉丝。我非常喜欢有效地庆祝失败，因为如果你想成为一个学习型组织，如果你想让人们进行实验和尝试，这可能是很好的。但是，如果实验有时不失败，那么进行实验就没有意义。有时它不会像你想的那样工作，而我们都会犯愚蠢的错误。我们都做过，在错误的Unix命令行窗口或其他地方输入错误的东西，不小心关闭了一个集群或删除了一些东西。我的意思是，在我的职业生涯中，我已经做了很多这样的事情，我相信你也有。这并不罕见，但我注意到在公开会议上，而不是在内部会议上，人们都不谈论这些东西。他们不会说，这一切都出了可怕的错误，我做了这个愚蠢的事情。我认为这是一种耻辱。就像我们给人的印象是，我们都是无懈可击的，是完美的，并设定了不合理的期望。实际上，在我的职业生涯中，许多我学到最多的东西都是我在某些方面搞砸了。
萨拉-韦尔斯。
真正的标准是，在操作上，没有人故意这样做。如果有人在生产中掉了一张桌子，那是因为你没有足够的护栏来阻止他们犯这个错误。如果你是一个初级或中级工程师，你丢了一个生产数据库，你想要的是一个高级开发人员去 "很好，现在这将是一个很好的例子，告诉你我们如何从备份恢复我们的数据。"
萨拉-韦尔斯。
因此，首先，只是对内部会议进行总结，我认为内部会议是一个非常好的地方，可以展示你希望人们拥有和相信的文化。在事情的操作方面，我非常强烈地感觉到，你希望人们理解，每个人都会这样做，我们不是要把问题归咎于某人。我们是要解决这个问题，然后研究如何保护人们，使其不可能再犯这种错误。
萨拉-韦尔斯。
当我接手FT的运营工作时，我希望真的不再有任何关于开启事件数量的衡量标准。我希望人们能说有一个潜在的问题。我甚至不知道这是否是一个问题，但我会告诉你，因为我知道，如果我们超过一定数量的事件或类似的东西，它不会影响我们的奖金。我认为让人们相信，当事情出错时，你可以告诉我们，每个人都会犯错，实际上生产事故最初至少是人们去的很多情况，并不真正确定这里发生了什么，但我要去看看这件事，看看是否与此有关。
查尔斯-汉伯。
我认为这是一个奇妙的洞察力。当你在衡量某件事情，并将其作为衡量团队业绩或奖金或其他东西的方式时。这很容易产生意想不到的后果或不正当的激励。例如，如果你衡量生产中的实例数量，然后在生产中发生了一些事情，这对工程师来说是非常诱人的，我只是悄悄地修复它。我不会记录它，因为这样它就不会显示在生产实例的指标板或其他什么地方。
萨拉-韦尔斯。
我也认为，我们并不擅长考虑它的统计问题。我只是在工信部从来没有想过，一个月比前一个月多出两起事件，除了统计学上的波动之外，还有什么别的原因。所以我不太明白这个价值。当我们发言说，嗯，应该有一些衡量标准。你应该有一些东西，而不是凭直觉说我们在生产中运行系统的能力方面处于一个更糟糕的状态。我认为有趣的是，有多少次我们不得不在某人不在工作时给他打电话。因为我认为这意味着出了问题，而一线支持人员无法根据他们得到的信息来解决这个问题，我们不得不给某人打电话，打扰他们。我想这是一个有趣的追踪。
萨拉-韦尔斯。
我也不希望有一个真正意义上的，我们必须在X分钟内修复它，因为我认为这不一定能帮助你有那种压力感，哦，我的上帝，如果我没有在半小时内修复它，这一瞬间就会被算作一个大失败。我认为每个人都一直在努力做这件事。我认为你想要的是，有人在管理事件，进行沟通，并鼓励开发人员思考他们可以做些什么来减轻影响，因为我的经验是，开发人员喜欢了解出了什么问题，并修复它。但有时你可以在不了解整个事件的情况下做一些缓解措施。也许你会说，好吧。我们认为也许在欧盟地区有一个问题，让我们故障转移到美国以外的地区。有时，这将解决你的问题，同时你要弄清楚发生了什么事。有时它不会。但它可能不会损害它，还有类似的事情。
萨拉-韦尔斯。
所以我可以谈很多关于操作方面的东西，因为我只是发现它真的很有趣，尝试并专注于我们想要什么行为，我们希望人们有什么感觉？安娜-希普曼（Anna Shipman）在金融时报的小组引入的一件事，我非常喜欢，就是影子的想法。因此，那些还没有信心在下班后获得支持的人，比如他们不想在出错时被上报，可以加入一个影子轮值表，这样，当人们在下班后被联系时，他们也会联系影子轮值表上的人，他们可以在没有压力的情况下加入，成为试图解决问题的人。人们真的发现，看着其他人如何解决这个问题，而不觉得有任何压力需要他们去做，这让人感到安心。因此，我们会向任何想要加入的人开放事件电话和渠道，这样他们就可以看到正在讨论的内容，这样他们就可以看到正在发生的事情，他们就可以了解它。我认为这对人们来说真的很令人放心。
在网上举办会议是什么感觉？
查尔斯-汉博。
是的，当然。我想快速跳回到你之前说的事情，你把技术会议搬到网上，作为大流行病的一部分。那是怎样的经历？你是如何做到的？
萨拉-韦尔斯。
嗯，我真的很喜欢它。我真的很喜欢在网上进行。我想，当我们把这个项目放在一起时，我们试图考虑如何利用它来给人们一个机会，与不在他们直接团队中的人交谈。因为在大流行病中，我仍然看到我团队中的每个人，但我并没有真正看到我团队以外的人。我认为让人们进行这种互动会非常好。所以，我认为......。当然，我们又回到了那个特殊时期的非会议会议。
萨拉-韦尔斯。
所以它的好处是空间的限制。所以你可以同时进行多场会议，因为你不需要在金融时报预订会议厅，也不需要把人放在那里。在产品和技术方面形成了一种很好的文化，任何时候只要有人在做产品和技术简报，就会有很多人在边栏里聊天，你可以期待。而这实际上感觉非常好。我们鼓励这样做，鼓励人们发表评论和参与。我认为这很好。
查尔斯-汉伯。
你说的这个互动性真的很有意思。正如你所知道的，Container Solutions举办网络研讨会，事实上，你做了一个关于警报疲劳的研讨会，我们会在节目笔记中链接到这个研讨会，因为它是一个很好的情节。我们还举办了一些会议。WTF is SRE?以及 "云原生 "是什么？到目前为止，所有这些活动，至少在我的时间里，都是在网上进行的，我们在这些活动中得到了非常好的互动，但我也做过其他的网上活动，这不是真的。这有点像坐在一个房间里，独自交谈。我不知道我的老板卡拉和她的团队在活动方面有什么神奇之处，能让这种互动性发生。但如果能知道就好了。你有什么想法吗？
萨拉-韦尔斯。
是的，我认为当你在一个人们相互认识的组织中时，这很有帮助。而且，如果你有一些人总是带头，也会有帮助。我在金融时报工作的一些人，我可以保证他们会参与到聊天中，他们会鼓励其他人说话，他们只是带来了这种参与。因此，如果其他人在想，他们想说些什么，但他们有点害怕，他们会这样做，因为其他人已经说过一些事情了。我想有几个人在他们的谈话中加入了一些东西，鼓励人们参与进来。
萨拉-韦尔斯。
我参加过几次在线讲座，有时很难得到很多互动。作为一个正在演讲的人，很难得到那种感觉，无论人们是否参与你所说的内容。我认为这特别困难，因为你看不到任何人的脸。有时，人们在在线会议上不打开视频也没关系，但当你发言时，要知道你是否只是在说一些大家都觉得很无聊的东西，这真的很困难。所以能得到这样的反馈很好，是的，我喜欢这样。绝对是这样的。
查尔斯-汉伯。
是的，我发现在我所做的少量在线讲座中，我发现这真的很难，因为我会根据房间里的反应来调整我所说的内容。比如，好吧，我想我已经失去了他们。对。我最好给你多一点背景。或者哦，好吧。这让人发笑。也许我们会把幽默程度调高一点。所以，不管是什么，你都要从观众那里得到一点好处。我发现，对我来说，我在网上做的时候没有这种感觉，我发现这真的很困难。
萨拉-韦尔斯。
我认为这真的很难。我真的很感谢有几个人打开了他们的相机，并且有明显的反应。这真的很可爱。我认为，如果你参加一个在线会议，并且你能自如地打开你的视频，并且你想点头，你就能对谈话的能量产生很大的影响。但我在现实生活中的会议上也会这样做。如果我认识的人是第一次做演讲，我会坐在前排，全程微笑和点头，因为我认为当你知道有人在那里互动，看着你，并说，是的，这很好，这让人感觉不那么可怕。
查尔斯-汉伯。
是的，当然。我做的第一个大型讲座，不是一个主题演讲，但它是在1000人面前的主题演讲台上。有一个我在会议上认识的人坐在前排，她有那种非常响亮的笑声。我说了一句话，她就笑了起来，你觉得你的自信水平提高了。这就像，好吧，至少有人觉得这很有趣，而且这很有帮助。
萨拉-韦尔斯。
是的，我做过很多演讲，但你总是很紧张。当你开始时，你总是很紧张。我一般会发现，当我讲到五分钟的时候，我的肩膀就会放松，因为我已经找到了自己的节奏，而且我通常会从人们那里得到足够的反馈，认为，哦，是的，有人认为这很有趣。对于一个在线会议来说，我认为这很难。所以，是的，我认为找到一种方法来鼓励人们以某种方式进行互动。另外，如果你想一想，在人们与你交谈时聊天的整个想法，感觉很奇怪，因为在现实生活中的会议，你要等待，最后再问问题。
查尔斯-汉伯。
这里有一个完整的另一个话题，实际上我很想深入研究，因为我认为它很吸引人，但我们没有时间了。但只是简单的说一下，当我们转向网上的时候，显然是很匆忙的，在大流行的逼迫下，我们基本上看了在现场会议上发生的事情，抓住了谈话的部分，因为那是相对容易做到的，并将其转移到网上，相对来说没有什么变化。我认为我们刚刚开始思考网上和现场的互动模式可能会有什么不同，但这真的只是一个非常、非常初级的阶段。这很有趣。
你对你的书有什么计划？
查尔斯-汉博。
不幸的是，如果我们现在试图谈论它，我们将结束，我怀疑是世界上最长的播客集，这可能是一个错误。在我们结束之前，我确实想问你关于你的书。你正在为O'Reilly写一本关于微服务的书。你能不能告诉我们这本书什么时候出版，以及为什么要再写一本关于微服务的书？我们不是已经有很多这样的书了吗？你要谈的是什么，是我们以前没有谈过的？
萨拉-韦尔斯。
这本书可能会在明年第一季度出版。我现在正在写这本书。这本书叫做《促成微服务的成功》。它实际上是关于，如果你想成功地建立一个微服务架构，它不仅仅是关于技术。这是关于你的组织结构和你的文化。现在有一些关于微服务的优秀书籍。我认为有很多人关注你如何接近它，架构和一切。但我的经验是，当你正在运行它们的时候，当你进入这个领域几年后，它是什么样的？因为我们已经到了这样的地步，现在有些系统已经存在了五、六年，是建立在微服务之上的。你如何继续保持对它们的建设，并维护它们，使它们保持良好的状态？因为你希望通过微服务拥有的东西之一是，你不必停止和开始，完全从头开始，你能够更换系统的组件，改进它们，只是保持整个事情的发展。
萨拉-韦尔斯。
所以我认为我在工信部学到了很多关于构建和运营微服务的知识，我想把它们写出来与大家分享。因为我认为，如果有人说，"你知道你需要在早期真正做什么吗？这件事"。比如，从字面上看，你找到与一个事件相关的所有信息的能力，不管是通过在所有日志上有一个交易ID的日志聚合，还是你在做追踪，你都需要这个能力。你需要有能力来追踪正在发生的事情。类似这样的事情。
对于那些可能与你有类似职业道路的听众，你会推荐什么阅读材料？
查尔斯-汉伯。
这听起来很不错。我在想，Sam Newman有很多书，他的《构建微服务》，现在已经是第二版了，这是一本非常棒的书，讲述了如果你在考虑微服务架构，你需要知道的基础性的东西。包括信息隐藏，无处不在的语言，所有这些。这是一本非常棒的书，真的很推荐，但你是对的。我不认为真的有什么关于，现在你已经有了一个微服务架构，并且你要长期运行它。那是什么样子的？我真的很期待在你的书出来后读到它，希望是在明年年初。同时，你会向那些与你有类似职业道路的听众推荐什么阅读材料？
萨拉-韦尔斯。
啊，所以有三本书是我经常向人们推荐的。我担心这听起来，就像他们是大家共同推荐的书。首先，《加速》这本书非常好，它讲述了作为一个软件开发组织，高绩效意味着什么？它是什么样子的？
萨拉-韦尔斯。
团队拓扑结构。当我读到这本书的时候，我就有一种真实的感觉，是的，这很有意义。这是我们已经找到的方向，有不同类型的团队的想法，你如何互动的想法很重要，你希望互动的方式不会限制每个人停下来一起工作很长一段时间。你希望能够合作，而不必步调一致地做事情。所以这两本书都是非常好的书。
萨拉-韦尔斯。
如果你是一个正在参与管理的人，Camille Fournier写的《经理人之路》真的很好，可以帮助你。这本书真的很棒，因为它从你现在正在管理一个人开始。好吧，现在你在管理一个资深的人，你在管理一个经理。因此，它有这样一个步骤，即成为一名经理所需要的东西。这些书我都有一份，可以借给别人看。
萨拉-韦尔斯。
在软件开发领域之外，我想有几本书是我要推荐的。Atul Gawande的《清单宣言》。他谈到在医学界，他们试图找出如何能有一个相对低成本的干预措施，使人们在医疗情况下更有可能做得很好，特别是手术。他们把目光投向了航空业，事实上，在航空业，长期以来一直存在着检查清单的想法。核对表并不告诉你需要做的一切，但它们提醒你可能忘记的重要事项。他们在医学上也是这样做的，这也是真正可以应用于软件的东西。
萨拉-韦尔斯。
所以，如果一个外科团队彼此介绍自己的名字，那么被手术的人就会有更好的结果。原因在于权力的差异。因此，从字面上看，如果护士知道外科医生的名字，他们就更有可能对外科医生说 "你要切错腿了"。我知道这听起来...这种情况发生了。因此，基本上是关于你能做什么，这意味着你更有可能拥有正确的检查和平衡的地方？因此，检查表上是否有一些东西说，我们做一个检查点，每个人都很高兴，我们都明白这个行动的特殊情况。因此，我认为对于软件开发来说，你也可以从中学到很多东西。你如何只是提供一些东西，提醒人们他们可能忘记的事情？每个开发人员都知道如何进行构建、测试、部署周期。他们可能会忘记什么重要的事情，然后我们可以把它放在一个检查清单上？我认为这很好。我们在FT也有一个工程检查表。
Charles Humble。
这是一个非常有趣的选择。谢谢你，萨拉。我将在这一集的节目说明中包括所有这些资源的链接。我还要感谢莎拉-韦尔斯在这个月加入我的 "黑客机关 "播客节目，她来自WTF is Cloud Native?的团队。
萨拉-韦尔斯。
很好。非常感谢你。我很喜欢这个节目。
