通过本周我们被鲍比表加入了Firehydrant.io是一位世界知名的工匠，手工造成的事件响应服务，实际上与此相反;完全可复制，完全自动化。
Bobby向我们讲述了他和他的联合创始人在创建公司时走过的道路背后的一些动机，以及创造了自动事件响应需求的市场环境。
我们还谈到了DevOps和SRE之间的区别，微服务的优缺点，以及一个关于鸭嘴兽和消防栓的特别难忘的事件。
如果您发现燃烧需要分享您的思想或咆哮，请将它们喷洒在devrel@newrelic.com.。当你费尽心思给我们发送一些字节时，请考虑花点时间让我们知道你希望在未来听到的节目。尽管你将收到全部大写的火焰回应，请知道我们真诚地感兴趣的您的反馈;我们的目标是安抚。
享受这个节目!
乔纳：我今天加入了我的客人，鲍比表。你今天好吗，鲍比？
鲍比表:我做得很好，伙计。你好吗?
乔纳：我过得很好。我很想跟你谈谈Firehydrant.io.东西，具体射回。我对事件的反应非常好奇，因为我不是Devops Professional，我从来没有真正过。另外，在我们进入这一点之前，我想听听你。告诉我你是谁，你如何在这里结束。
鲍比表:我叫Bobby Tables。人们都这么叫我xkcd漫画，妈妈叫她的孩子一个SQL注射攻击。我的真名是罗伯特罗斯。以前从我的两个朋友开始炽肥病 - 我们都在Devops Space - 但我工作了即人力资源，我正在建立很多开发人员的工具。我在圣斯德队。在即，我在Digitalocean.在那之前，我在迅雷实验室在那家咨询公司做了很多很酷的事情。在我的生活中有很多开发工具，为自己和他人构建它是一段非常有趣的时光。
乔纳：我记得雷电。桑德波特是多久以前的事了?
鲍比表:我想我在霹雳实验室，六年前我想说。
乔纳：也许你和布莱恩·莱尔斯一起工作过?
鲍比表:我做到了。
乔纳：我记得雷霆实验室，因为你有很棒的贴纸。你一直以品牌为单位。在Thunderbolt，你真的很好的品牌，你也在炽热的燃烧品品牌。事实上，我记得最近在那里有一个Twitter交换的一集，最终有一个非常有趣的徽标。我想知道你是否想分享一个关于这个故事。
鲍比表:所以，我们以某种方式最终结束了Corey Quinn在推特上的评论我们发布到Twitter上的Corey，我们说：“如果您为炽肥物绘制徽标，我们将在我们的网站上剩下的时间来制作我们的徽标。”并且有一点交流。他说，“如果你实际上不这样做，不要说话。”我们说，“我们是认真的。”Corey最近发布了在他们的slack.org中发生的交换，它基本上说：“我需要你在消防栓上撒上撒尿的鸭子标志。”所以我们得到这个徽标，我想说，30分钟后，有类似的东西。我进入了我们的WordPress并上传了徽标和...
乔纳：你让鸭嘴兽在消防栓上撒尿…
鲍比表:我们所做的。
乔纳：作为你今天的标志?
鲍比表:我们所做的,是的。
乔纳：太奇妙了。
鲍比表:它有一个很好的笑声。这很有趣。我们认为这一刻在我们的心和公司附近。
乔纳：所以你要喝老式的?
鲍比表:我是。
乔纳：我要喝点苏格兰威士忌。这是我在New Relic上的三叶草行动课，当时他们在都柏林开设了办事处，我想那是他们在海外的第一个办事处。他们称之为三叶草行动。
鲍比表:那太棒了。
乔纳：所以你现在开始的公司，炽肥，多久以前你开始了？
鲍比表:FireHydrant的第一次承诺是在2017年9月。《消防栓》是从一个视频系列开始的，我想记录下从零开始构建应用程序的过程。它是一个Ruby on Rails应用程序。所以我记录了《消防栓》最初40个小时的制作过程。然后我有个朋友说，“嘿，你所创造的东西更有价值。”所以消防栓是一个帮助事故响应的项目。这一直是它的本意，但后来我在40个小时后就停止了录音，然后我有几个朋友一起玩。然后在2018年12月，我们筹集了一颗种子，我们作为一个全职团队开始了这个项目。所以我们来了，我们有一些很好的客户，我们正在帮助事故处理。
乔纳：你现在有多少人?你快速增长。
鲍比表:我们很漂亮。我们现在有16人。
乔纳：哇!那大概是一年半以前吧?
鲍比表:一年半前一点半。
乔纳：棒极了。为你拥有的想法筹集资金是什么样的？我有很多朋友谁做了这些初创公司。它似乎是您体验级别的软件工程师的一种道路。我只是不明白这个过程。你刚刚在Twitter上宣布，“嘿，有人给我100万美元。”你去哪里？
鲍比表:纽约市的几个投资者伸出援手，我甚至讲述了这个故事甚至讲述了这个故事，因为这么多的创始人都说他们必须在他们能够获得一项术语表之前与50名投资者交谈。我真的很幸运能够说我们有一个好主意，我们有一些非常热情的投资者，老实说，这就是我们如何提出它。
我们能够挖掘我们的网络过去筹集了一点资金，我们在那里有一些建议。我们通过整个过程引导，读了很多书 - 很多书 - 我们绝对试图在签署任何事情之前尽可能多地阅读。但我们真的很幸运。我们有一些我们可能会要求的最好的投资者。因此，工作台是我们的第一个投资者，然后是我们今年早些时候关闭的A系列，是Menlo Ventures，这是一家非常熟悉的公司。他们在优步，Roku，Warby Parker投资。所以我们觉得真的很幸运，我们正在解决一些非常酷的问题 - 我们只是保持愿景向我们前进。
乔纳：所以我看了一些你的一些博客文章。我认为你们的产品的作用是当你们的消防栓公司发生事故时。IO将由某些人发起，甚至在达到某个阈值度量时自动发起，并且它管理整个事件生命周期。所以，突然之间，人们开始得到正确的Slack信息，让正确的人知道系统宕机了，下一步该采取什么步骤。它向玩家呈现剧本和资源，帮助他们解决问题;试着重新启动这个，重新启动那个，设置这个应用程序的新实例。然后在最后，它将所有的一切打包成一个整洁的报告，然后你可以用它来对事件进行回顾分析。我怎么做什么?
鲍比表:那很棒。你想要营销角色吗？
乔纳：我在新遗迹已经三周了。
鲍比表:你刚刚加入了New Relic。这可能不是一个问题，是的，这是对消防栓的精彩描述。所以我们认为“消防栓”——就像它的名字一样——是帮助你灭火的工具。所以有很多的报警工具，它们接收到一个信号，然后把你叫醒。而这正是这些预警工具所要做的，它们做得很好。我和我的团队感到的一个痛苦是，一旦我醒来，现在怎么办?所以《消防栓》就是带着这个想法诞生的。你有一个烟雾探测器，当你闻到烟味的时候，你的烟雾探测器会把你叫醒，但它不会在那一点上帮助你。这只会让你走出家门，给别人打电话，让他们帮你解决问题。
鲍比表:当你想到街上的消防栓时，它并不直接负责放火。消防员负责放火，消防栓只是一个必不可少的工具。所以我们帮助您尽快组织合适的人。我们将为您的事件创建一个松弛频道。我们将创建一个缩放桥。我们甚至可以为影响受影响的服务的邮寄书来做的事情：这是您如何进行回滚，这是如何发送USR2信号来重新加载配置。您可以存储所有此类，而炽肥会使它真的，真的很容易访问。
如果有什么东西坏了，New Relic就会告诉你，“嘿，你的APM远远超过了阈值。”它会引起恐慌，你可能会忘记你的过程。工程师们只是想做正确的事。没有工程师会在事故响应过程中做任何会故意让事情变得更糟的事情。但是，他们可能会进入认知隧道，他们忘记创建一个Slack房间或更新状态页面I/O或更新我们的状态页面产品。这是常见的。
所以消防栓的想法是建立在如何我们能有相同的过程,每一次,我们会为你做这些在几秒钟,所以你可以做你擅长作为一名工程师,这是解决这个问题。
乔纳：我重申，这是一款出色的产品。曾在多次的位置,我得到一个PagerDuty警惕一些应用程序在我的责任范围技术的球员,但是我以前没有使用过经常或也许我新公司甚至如果我的一个经验丰富的工程师团队当我得到警报,我进入了一个我几个月都没有编写过的应用程序。我不记得所有的事情。我只是随便打听一下。拥有这些运行手册是很有价值的，在我看来，这是一个相对较新的创新。我敢肯定10年前就有人这么做了，但我觉得当我第一次进入这个行业时，这并不是一种普遍的做法。
和自那时以来,我们已经在DevOps的角度来看,这个词源于努力之间的桥梁开发人员或系统民间,,真的,是一样的:我们都朝着相同的目标,我们编写代码,我们都试图建立可复制的方式使用消防栓等工具。那么你认为这两者有什么区别呢?
鲍比表:是的，这个问题我在很多酒吧喝啤酒的时候讨论过很多次。所以我认为你听到的一个问题，或者你可以在谷歌上输入“DevOps”，你会在谷歌中看到“DevOps vs SRE”。我认为首先区分一下很重要。DevOps有很多不同的想法。这是围绕CI/CD的一些实践。这是关于构建工具的一些实践，可能会回滚给员工或提醒，这个过程就是围绕着这个。只是。这只是一堆想法。这就是SRE发挥作用的地方，它是这些思想的一个框架。如果你考虑一个面向对象的语言，谷歌有一个很好的演示。
sre实施devops。sre从devops继承。我认为这是一种很好的方法，可以分开devops与sre的想法。
乔纳：所以，网站可靠性工程是Devops原理的实施 - Devops是一系列想法，而SRE是实际的实现？
鲍比表:是的。
乔纳：所以从那个世界之外，我开始看到人们使用这个词SRE关于我开始听到Devops的时间 - 但大概是，这两个没有发生在串联中，他们呢？所以有一个关于Devops的基本书。有一本可能在标题中有“独角兽”的书？
鲍比表:是的。T独角兽项目:一本关于开发者、数字颠覆和数据时代繁荣的小说吉恩·金(Gene Kim)最近才出版。我认为凤凰城项目吉恩·金(Gene Kim)是一个更直接地——在虚构的意义上——谈论DevOps的人。这是一本好书。它讲述了一个可怕而现实的DevOps世界以及从一个非DevOps世界走向它的过程。我还没读过你提到的那本新书，独角兽Projec.T。
乔纳：我是误会，因为我开始去做会议。就在去年，我真的对这种东西感兴趣。看看Systems架构是令人着迷的，即我构建正在设计的应用程序的方式。我现在仍然是微服务的粉丝，小明特，微小的微服务。您可以到达的门槛......
鲍比表:纳米服务?
乔纳：纳米服务,是的。我认为人们在这里传达的信息过于复杂了，但我仍然喜欢让应用担负起一定的责任。这是用户居住的地方。这样设计一个系统。我有时会使用CRC卡，当我准备设置应用程序时，我会做这些思维导图。我觉得系统架构是非常相似的，但是在今天，当你在设计一个系统时，游戏场上的部件，你所拥有的乐高积木的数量是非常大的。
如果您查看描述在下面的应用程序的CNCF页面云本机计算基础我想那一页上应该有50个商标。我觉得它只是看到了爆炸性的增长。如果你使用Kubernetes生态系统，我想它就是这种云架构增长的晴雨表。这是爆炸。到明年，我们可能会有两倍的数量。
所以你有所有这些乐杆，你试图跟踪我和向我追踪 - 外面，因为它不是我的全职工作，因为它是你的 - 它看起来很难跟上。我宁愿尝试跟上JavaScript的生态系统。
鲍比表:这是一个很好的比较方法。有趣的是，你说乐高，因为我经常说这个，如果你去乐高乐园，站得很远，看起来他们用乐高制作的雕塑是有弧度的。但如果你离得足够近，仍然是锯齿状的线。如果你把手放在上面，还是会很不舒服。你还是不会想踩到那个雕塑的。
有了这些乐高积木，你现在就可以用这些零件来制作这些极其复杂的系统。但问题是你把它变成了一个极其复杂的系统。如果你没有一个框架或心态来真正管理这个系统——如果你没有建立一个成功的团队来管理这个系统——你几乎是注定要失败的。
我想很多Kubernetes的建筑和所有其他的CNCF项目;服务网正在成为一件大事，对吧?我只是有了另一层复杂性，你怎么画出一个请求是如何到达一个进程的呢?与16年前相比，这变得疯狂了，那时我用Apache和PHP监听5000端口，不管它是什么。只是太不一样了。
乔纳：过去，我不得不自己使用一个请求ID来缝合一个请求。我将在用户登录和获得请求ID的前端找到应用程序，如果我们有一个请求ID，我希望我们这样做，所以我没有关联的时间戳跨微服务。我还在搜索那个申请ID的记录并把它缝起来。现在这些都消失了。我们只是不断地构建抽象，让一切变得更简单。
鲍比表:我可以用炽料剂的经验说话。你几乎必须从现在开始建造这些东西。您必须拥有此架构，该架构将在负载平衡眩光下有一个请求ID，这将一直传播到Pub / sub中。诊断这些问题变得非常非常努力。这就是为什么面向服务的架构，虽然它对很多公司来说都是好的，但它可能不是真正的初创性。
我们开始使用模型。我从一个微服的建筑中获得了我的最后两家公司，我们说，“不，我们要做一个整形士，”因为如果有些事情突破，猜猜是什么？你只能在一个地方打破。所以，我们将去那里。
乔纳：面向服务的体系结构旨在解决困难。如果你还没有感觉到疼痛，那你就不知道该拔哪块。
鲍比表:正确的。我认为，关于体系结构的一个有趣的事情是，它应该遵循许多在良好的面向对象编程中使用的相同原则，但这一点谈论得还不够多。我们有坚实的原则。我们有领域驱动设计，单一责任原则。你谈论开闭关系，依赖倒置。但我们不会在建筑中谈论这些相同的概念，这是完全现实的。为什么我们不能有一个开-闭的系统，我们可以添加一个扩展系统功能的服务?为什么我们不能做一个利斯沃替代因为我们对这个服务有一个定义良好的API，所以我们需要让它更快一些，所以我们用go app交换它，但是因为它有相同的API签名，消费者并不关心。
我们对建筑和设计的讨论不够。我认为我们只是把服务扔到问题上，然后每次都以不同的方式重新设计端点——每次都是这样——最后我们就得到了这些意大利面条般的怪物。优步现在甚至在谈论这个。他们有一篇关于这个的新博客文章。我认为这是一种疯狂的风格，一个服务给三个工程师，而优步有成千上万的工程师。你能想象那样做吗?
乔纳：我无法想象在这家公司的工程团队里工作是什么感觉。我认为这与他们所经历的非常、非常快速的增长有关。他们在一夜之间爆发。他们生产了很多有趣的技术。他们有一个比较受欢迎的普罗米修斯后端。Prometheus是一个提取应用程序的应用程序。而不是我,当我处理支付客户鲍比表,而不是我调用一些指标端点和说,“嘿,鲍比只是付了10美元,”我只是写本地一些临时存储,和普罗米修斯出现每一分钟左右,把一个端点在我支付应用程序。它获取我记录的所有指标的所有数据，并存储它们。但是“普罗米修斯”项目并不是为了长期保存这些数据而设计的。它获取数据并将其放入后端存储中。 And优步M3.，我认为，是它的名称。这听起来对吗？
鲍比表:是的。M3听起来是正确的。
乔纳：这是它的后端之一。因此，Prometheus将使用Uber的M3开源项目来存储该数据长期。这些类型的技术 - 如果您查看可用于Prometheus的时间序列后端，现在有100个。我知道这亚博最新版直播是你正在做的事情的产品，有一个统一的产品用于处理事件响应。所以我的实际问题不是，“嘿，尊重你所有的竞争对手，为什么这不再是人们思想的最前沿？因为它是每个人都交织的东西，对吧？我曾经与经营书籍和系统一起工作过的每一个SRE，但它都是手工滚动的。他们都有定制的手工过程。而且你在一个盒子里发了一个整个过程。为什么不常见？
鲍比表:这是一个很大的问题。我认为炽料剂今天可以存在，因为我们已经标准化了这么多的其他东西。是的，事情已经变得更加复杂，Kubernetes已经开始肯定地占据了许多现代应用架构的构建方式。我认为每个主要财富100现在都表示他们正在尝试Kubernetes。我记得一些关于这个的文章，一些疯狂的统计数据。而且我在谈论这一点，因为我认为这是同样的方式，炽热剂可以在今天存在。
在过去的10到15年里，我们开始将很多东西标准化。容器之所以存在，是因为我们能够对格式进行标准化。Docker创造了这种标准化的、可移植的格式。没有这种标准化，Kubernetes会怎么做?因为所有这些定义良好的接口的抽象开始存在，Kubernetes能够进来并把这些东西捆绑在一起。
消防栓也是一样。我们有了DevOps，然后SRE开始在这个领域崭露头角。我认为很多组织都在从更结构化的角度考虑可靠性。然后我们也让人们在聊天工具上标准化。世界上很多人都转向了Slack。
乔纳：我百分之百地同意你。我知道你也是Rubyist的一员，所以我想花点时间来欣赏一下通过发表意见对社区有什么价值。我认为Rails做了一件令人惊奇的事情，它让很多程序员在同一时间朝着同一个方向前进。对于标准化，开放的遥测技术的改变是毋庸置疑的，我们现在有了一种报告指标的方法。我曾经使用New Relics的专有格式。我更希望有一个人人都能使用的指标格式，我们都能互操作，对吧?我觉得我们在DevOps生态系统和SRE生态系统中已经达到了一个临界点，我们现在正在学习标准化我们如何构建这些东西以及我们如何应对这些东西的价值。
如果我让你对未来做一些预测，一年后你的空间会是什么样子?一年后，我可以给你打电话让你上播客然后告诉你你错得有多离谱。
鲍比表:是的。我会喜欢这个，设定一个提醒。我有两种预测，我实际上没有在现场弥补。我一直在想这么多。One of them is that we’re going to hit a point where service-oriented architectures are becoming incredibly cumbersome and super complex to the point where we’re going to need to get away from Google Sheets as the de facto way of listing the services we’re running and who owns them. So I think that we’re actually going to see a lot of tools come into play for cataloging the services we’re running in production. Because there are a lot of challenges that come with running multiple services that are not just around engineering operations. It’s a question of, “How do you make this compliant?”
为了符合SOC要求，在部署时必须记录日志。您必须有一个部署日志。当你一天有100个服务部署多次时，这些信息去了哪里?什么是服务?然后人们开始转向多区域、多云，甚至——我们怎么知道这些服务在哪里运行?这是一个需要解决的挑战。很多公司只有YAML和GitHub存储库来表示这个目录，随着时间的推移，这是不够的。
乔纳：我认为这和你在事故反应中所做的特别相关。如果发生了意外，我想马上知道的是在过去24小时，或1小时，或10分钟内发生了什么变化。系统中发生了什么变化?因为我对电脑很了解，我知道如果你不惹它，它就会一直睡觉。永远不要改变任何事情，对吗?所以你必须找到这些变化。我认为服务发现和类似的事情对实现这一点非常重要。所以你对明年的预测是我们的生态系统中会有一些受欢迎的参与者或者一些项目会把服务发现做得很好。然后，以一种自以为是的方式，它开始成为主导的标准?
鲍比表:是的。初创公司和风险投资——尽管可能令人讨厌——确实是正在发生的事情的良好指标。如果你看看过去的6个月，很多服务目录初创公司的唯一职责就是列出你正在运行的服务和他们最近发生的变化。所以,它的发生。现在的挑战是，“如何定义服务?”我们将开始看到这个挑战。我希望CNCF或其他管理机构能给服务下个定义。负载均衡器不运行服务吗?如果您问我，我会说这是一个服务，因为您的客户不关心它是否在Amazon的ELB上，但它是您运行的服务。
我认为我们需要一个定义良好的服务版本，并有一个规范，一个关于服务的实际RFC。我认为随之而来的是——或者希望如此——我们需要一个通用的标签标准。标签到处都是。每一个主要的云提供商，每一个主要的指标消费者- new Relic就是其中之一-这些服务中的每一个都有标记和注释的方法。但是对于服务来说，没有定义说明键应该是什么，值应该是什么。所以我真的希望这能发生。我们要有人定义一组标准的标签。你可以叫它“CNCF标签项目”，不管我怎么说，它说的是服务的名称，服务的目的，它所支持的组件，拥有它的团队，以及沿着这些线的其他键值对。
如果你考虑提供的价值 - 如果我说我有这个键值系统，我可以在亚马逊中添加到我的elb，因为亚马逊支持标签，然后我在具有注释的kubernetes中掌握了我的部署引用，我have a metric that comes out and that has a key value pair—if I have a way to slice down all of those keys across the entire request cycle from ELB to deployment to metric, that enables a crazy amount of observability that we don’t have today. It’s cobbled together. So I think that we’re going to see a service catalog come out. And I think to make that a reality, we’re going to have to see a labeling standard come out. That will actually be a really interesting turning point for observability and linking that to the services that we’ve run in a standardized way.
乔纳：我认为这是一个明智的预测，我认为这是迄今为止最有可能发生在观察Mcobservface的简史。这现在是我们的第三集，这是一个非常荣幸。我们已经有许多预测，但现在你赢得了预测游戏。
鲍比表:也许我现在写出来是为了证明一点，然后说:“是的，确实发生了。”
乔纳：这应该是博客文章。虽然我们在这个问题上，你做了一个博客关于如何制作古老的，是对的吗？
鲍比表:我做到了。
乔纳：里面有火吗?你有没有用…你烧了你的…
鲍比表:我做了，从橘子的背面。我忘记了这个技术的名字，但是你可以在橘子上切下一个叫做“硬币”的东西然后在上面涂上一些火焰你可以从橘子里榨取一些油然后把它放进饮料里。这就给了它一个漂亮的橙色基调。
乔纳：我非常欣赏这一点。我觉得老式已经成为一个以某种方式成为开发商的饮料，但每个人都对此进行了意见。我知道从头开始制作自己的苦味的软件开发人员。我来自波特兰，我们在这里做那种东西，但仍然是手工制作的手工制作。但我认为人们应该进入我们的手工制作的事件反应，而且我真的很高兴你的公司存在。我会对这一集重复我的预测，这就是你将在一年内收到一半，最大一半，你将停止接听我的电话。但我真的很感谢你带着这个并与我一起播客。有一个真正的乐趣让你，鲍比。非常感谢你加入我们。
鲍比表:不，快乐就是我的。谢谢你伸出援手，我总是很乐意与社区交谈。而且我们的真正目标是让开发人员与我们的工具更幸福，所以如果我们能够继续这样做，这对我来说是胜利。
乔纳：我关心的是开发者的幸福。那是我余生想做的事。告诉我们在哪里能找到你?
鲍比表:
我没有说太多，但你可以在推特上找到我，@bobbytables。我也在上github.com/bobbytables.，很高兴与任何人聊天，如果我说的是有趣的。
乔纳：太棒了。非常感谢。我很快会再见到你的。
鲍比表:谢谢你。