数据驱动的Devops:提高速度和规模的关键

今天我在Launchable，所以我们在做我们专注于测试，帮助测试进行得更快所以我要提一下我现在在这个背景下正在做的事情，因为这是我所看到的东西的自然延伸。自动化在软件开发中走了很长一段路，你知道，当我开始Jenkins时，它只是一个人们每晚运行构建和每晚测试执行的地方。所以这仍然需要10-15年的时间来发展自动化。但一开始简单的事情很快就变得越来越大，越来越复杂。我相信你每天都有这样的压力。
所以，你知道，很多公司不能再在晚上进行调整，建设和测试，对吧?人们有，你知道的交付管道，可能看起来像这样，从构建和测试开始，QA环境中的开发阶段，所有这些东西。但实际情况不是这样的，真正的情况是这样的。还有很多自动化要复杂得多，你知道，这里那里的电子邮件交流，一些隐含的过程等等。所以有时候你知道，我觉得这个过程的各个部分都是脚本化的，没有人为干预的自动运行，但总的来说，它们仍然是由人组合在一起的。有时试图从这些微观自动化中理解整个画面。
有时感觉就像观察一个蜂箱，我们试图通过观察单个蜜蜂来了解一个蜂箱。这相当困难。所以，你知道，在看到这么多公司，在这种大规模的自动化，大规模的软件交付中挣扎之后，我开始觉得有两种公司。对吧?当谈到软件开发时。
一个是驴,另一个是独角兽,他们看起来相同或相似的但他们执行完全不同,所以我一直在想,思考是什么让这种差异,我认为的一个关键优势,将这两种公司在我看来是他们如何使用数据的软件开发过程改进他们的练习,所以我想这些花30分钟观察这些实践有什么区别,以及为什么我认为这是一个关键的部分。所以,你知道,因为我为自己感到骄傲的推动自动化软件开发行业向前我扮演了一个角色,但你知道,尽管所有这些自动化生产大量有价值的数据,在大型我觉得这些东西只是扔掉,失败的事情时才会被人调查控制台或者为了理解失败了,现在,我没有个人故事,但我听说在人们丢弃的电子垃圾中，稀有金属、黄金和其他贵金属的浓度更高。然后，从地下开采出的原矿，这意味着，撇开体积和密度不谈，开采电子垃圾可能比开采金矿更有意义。所以，我认为数据中发生了类似的事情。现在这些东西基本上都被扔掉了，但实际上对这些东西有宝贵的见解。
公司，我觉得团队已经设法弄清楚了，把它用于积极的用途，似乎从中获得了很多价值。让我讲得更具体一点。所以，想象一下你在这家公司的这种情况，你在这家公司工作，有数百名工程师在从事数十个这类项目，他们都在一个共享的Jenkins基础设施上构建和测试。所以，你知道，在这种规模下，你不应该对他们在AWS上花费数十万美元感到惊讶。只是为了提供一个完整的和必要的存储空间来执行所有这些领域和测试工作量。所以，作为典型的硅谷初创公司，它的成本并不是个问题，直到有一天，它才成为一个问题。于是，这家公司开始转向IPO模式，于是首席财务官被聘用，他注意到的第一件事就是他的公司花了很多钱，数十万美元。那么它是什么呢?它究竟有什么必要?有什么办法能把它剪掉吗?这些实际上都是有效的问题，但事实证明，在这个基础设施上工作的人没有办法回答它，因为它只是一个巨大的基础设施，每个人都把大量的工作量放在它上面，所以在这种情况下，应该发生的是，如果在项目层面上提供成本的可见性，那么反过来， that would allow developers to be aware of the trade-off that they are making and then that information can help them make the right call. And so, this place had three separate machine types for different kind of workloads. So let’s say for the sake of brevity code in small, medium and large.
显然，越大的机器运行起来就越快，但是它们要花更多的钱。想象每个测试工作负载都带有一个滑动条。这就是说，根据你选择的实例这些是需要的时间，这是代价。这让他们能够做的事情是，例如，一些不经常运行的事情，比如一个晚上，执行的时间并不重要，所以他们可能愿意选择更长的时间。让我们假设运行一些东西进行验证，这是人们正在等待的东西，然后，你知道，为了不让人们等待，花一点额外的钱来更快地得到反馈可能是值得的，所以这些是他们可以做出的正确的权衡。在没有这些信息的情况下，开发人员有其他的事情要担心，所以他们会自动地选择一个更大的。每当出现问题的第一个迹象，人们就会发现一些东西，让我们在更大的机器上运行这个程序，然后继续。这些就是造成错误激励结构的原因。这是一个很简单的例子，系统已经知道的很小的信息可以在核心结构中产生不同。
这些事情在很多地方都在发生。让我们看另一个例子，这是一个更大的公司。成千上万的开发人员在本质上致力于嵌入式系统，这就是我的想法。对于DevOps团队来说，这个地方已经达到了惊人的规模，所以它是一个DevOps团队提供运行、构建和测试的基础设施。我说的不仅仅是Jenkins，所有的支持机制，这里的源代码是如此之大，以至于他们不得不想出一些聪明的Git，向前探测方案，只是为了让克隆足够快。这就是我们谈论的规模，这些人面临的问题是当构建失败时，当我说构建，或者当测试失败时。需要通知谁?因为有时候基础设施会出问题，比如网络，测试数据库或者QA环境出了问题，然后大量的东西开始出问题。这些是DevOps团队想要了解的基础程序，有时失败是在应用程序中，假设是编译器错误，测试失败是因为断言不成立。这些就是工程师应该注意的错误。 And getting this information right, getting this, you know getting who to notify right that’s actually pretty important, because the infrastructure program is not something the app developers can work on. When you get the failure saying this infra didn’t work out, then it cost the credibility of the DevOps team in the eyes of the app engineers, right? Nobody wants to feel like their build and tests are running in a crap place, that the results are not trust worthy.
但这就是正在发生的事情，或者我能想到的最简单的解释方法，叫狼来了，你不想成为那个在狼不在的时候叫它的男孩。所以他们想要做的就是他们已经做过的，所以当我访问那里的时候，他们已经部署了解决方案。你知道，因为，令人惊讶的影响，所以他们注意到这些不同的失败模式出现在不同类型的错误中，对吧?这是有意义的，所以他们只是部署一些非常简单的东西，比如正则表达式模式匹配日志文件的最后30行或沿着这些行进行匹配。他们只是部署了一些很好理解的正则表达式，当它符合这个形式时，就会让基础设施团队回来，或者反过来。
所以这种非常基本的解决方案结果却产生了惊人的影响。这是一个非常大的项目，他们遇到了另一个团队，他们反过来部署了贝叶斯滤波器，这本质上就像，我猜我猜你可以说这是一个混乱的统计使用水平。所以这个想法是，这是相同的技术，当时垃圾邮件过滤器正在使用，特别是在人们在自己的mac上运行主客户端，而不是使用Gmail的日子。所以你知道这个系统本质上是非常聪明的，系统发送邮件是基于它的判断，它发现了故障，它决定发送给应用程序开发人员或基础设施人员，对吧?这个通知包含一个按钮，上面写着“不关我的事”。所以当基础设施人员收到这封邮件时，按下这个按钮，它不仅会将通知重定向给应用程序开发人员，而且还会告诉系统，这封邮件，这种失败模式是针对应用程序工程师的，而不是相反，所以基于这种来自人类的输入，过滤器可以逐渐变得更聪明，它的有效性被这个垃圾邮件过滤器证明了，所以它确实有效。这是一项很好理解的技术，看看日志文件这肯定是很多人都能想到的。但是，通过掩盖应用程序开发人员不应该看到的问题，利用这种巨大的影响来保持DevOps团队的高可信度。
这是一个很好的例子,数据正在产生积极的影响,或许更重要的是,我认为这种数据使用的组织水平,我发现是非常,非常重要的,现在很多人,我今天跟从业者在许多方面他们明白需要做什么,但他们通常是沮丧,β是正确的工作是由组织没有得到优先的我相信你们中的一些人同样感到沮丧。在某种意义上，我认为挫折是合理的，但在某种意义上，解决挫折的领导者是一项更容易的工作，那就是帮助你周围的人，他们几乎从定义上来说没有你那么精通技术。帮助他们理解这项工作的重要性实际上是DevOps领导者的工作。
因为是数据和随之而来的故事帮助其他人看到你看到的问题，当然，就像你是主题专家你不需要那种数据来证明自己，但其他人需要那样。这是每个组织工作的基础，对吧?你需要说服你周围的人，你需要影响你周围的人，这样才能把他们团结在你的事业背后。仅仅告诉他们是行不通的，你需要使用数据。数据也很重要，因为它能帮助你把精力用在正确的地方，对吧?让你诚实。你认为这是一个可以产生影响的地方是一回事，但我们要确保事实确实如此，否则这与盲目的信仰并没有什么不同，我认为作为工程师，我们都为理性思考、生产力等等感到自豪。我们应该认识到这一点的重要性。数据的重要性不仅仅止于此，数据还可以帮助你展示你的工作的影响。
对于一个组织来说，没有什么比这样说更难的了:“我们现在需要一百万美元的投资，我们可能会在未来两年内得到任何结果，也可能不会。”很难找到的故事,如果你可以使用数据给你周围的人,你的影响,那只会让你更容易让更大的影响在很多方面我认为数据是连接业务人员的共同语言和主题专家像我们我觉得有时候因为我们看到这个问题,我们看到的问题思考问题你面对显然有时我觉得,我们往往忽视了用别人能理解的方式交流的重要性。换句话说，你需要得到的是这样的画面，你有一个想法，你有一个软件工厂，这些机器，你有这个过程，把这些想法变成一个功能软件，所以我们要做的是观察这个工厂是如何运作的，然后利用这些信息随着时间的推移来改进工厂本身。对吧?一次一个，持续不断，我想这就是主题。这个主题在其他行业,如不明白,比如制造业,在某种意义上我想说的是这种想法同样也适用于软件工程如果你看看这个程序,如果你看这是一个练习然后应该不足为奇,机器学习可以发挥着越来越大的作用在这种学习和提高的过程,一些公司已经在这么做了,让我稍微谈一下这个问题。
这是另一家公司，一家更大的公司，你在DevOps团队，你有一个巨大的代码库，它是模块化的，有组织的，有维护的，所以它不是意大利面，但它是一个巨大的代码库。这就像概念依赖，你可以把它打印在纸上，然后，这种系统，测试它们非常昂贵和耗时，但你改变了一些东西，效果非常大，所以这个软件一直在增长，因为你的业务是成功的，你试图解决的问题，挑战是如何削减软件交付过程的成本和时间。团队所做的第一步是基于依赖的编译，假设底部的四个菱形是文件，中间的方块是模块，橙色的圆圈是测试。多亏了组织良好的构建系统你可以创建这种依赖关系图，基于此如果你知道最左边的文件，左下角的文件已经改变了。
通过使用选择依赖项信息，您可以自动确定需要重新构建和重新测试的软件图子集，在本例中是一个模块和两个测试。就像右边的东西，你可以放心地推断它们不需要测试。这让他们有了一段时间。现在让我指出，我所见过的大多数团队甚至都没有做过这种级别的分析工作。很常见的是，人们每次都从干净的、新鲜的和划痕开始运行任何东西。他们在这个过程中花费了大量的时间和金钱，但无论如何这不是我想强调的，真正令人惊讶的是接下来的步骤，所以你知道这种静态分析的时间是有特定类型的测试，比如集成测试，基本上取决于其他所有东西，因为根据定义，他们一起测试一个更大的系统，所以这些测试最终会一直受到影响，所以你只能从选择的依赖项中获得这么多的速度提升。所以他们采取的下一步是我认为的预测测试选择。因此，他们在一个模型上训练并部署了一台机器，该模型观察发生了什么变化，并预测将运行的测试有用的子集。这家公司生产10的5次方，10万次变化一个月10万次变化的数量级他们拿出1%然后训练模型。 And then that was apparently enough to make useful prediction and the impact was pretty impressive, so they reported that this model selects only a third of the tests compared to the select based approach. And every time you stop running some tests, you worry about the degradation slipping through. But they reported that this model only misses just 0.1% of the changes. So 99.9% of the time this one third of the test is all the regression that you need.
这可以将数据库成本削减一半，想象一下，这个地方我不知道它花了多少钱，我们肯定有数百万，能够将成本削减一半，然后利用获得反馈的时间，这是非常惊人的。所以我认为这对我来说很清楚，我有点兴奋这种预测测试失败概率的方法有很多用处。在我自己的Jenkins程序中，你知道，每次我对代码库做一行更改，我都必须等待pr评估完成，这需要整整一个小时。这是一段漫长的等待。我看到一些公司做得更糟。然后您知道您有一个地方，一些大型集成测试只在夜间运行，甚至不太频繁。所以，很自然地，这些测试得到的程序出现得很晚，所以想象一下，你可以做类似的事情，这就像预测每个测试用例的失败，然后不是按照它们的自然顺序运行我们可以对高概率测试进行排序，然后按这个顺序运行。
因此，通过这样做，您增加了测试立即失败的机会，而开发人员的反馈对于让工作继续进行非常有用。所以你不需要等整个测试结果出来，你只需要知道你的第一个失败，然后，这种排序就会给你。或者你可以更进一步，然后忽略慢速失败测试，然后专注于更高的测试，它可以创建一个更小的自适应子集。这就是我选择Launchable的原因这也是我现在在这家公司一直在做的事情如果你们觉得这个项目很有趣，我很乐意和你们多谈谈，一起工作。然后我们从这个预测测试选择的对话转到另一个机器学习的用法，这是另一家公司。
你在一个大的SRE团队中，你看到数百个微服务被部署到你管理的生产环境中，这里的速度大约是每个应用程序每天一个部署。也就是说要部署上百次。这是一家非常棒的软件开发公司。我和大多数人一样，我说这家公司在交付过程中是百分之九十三，百分之五，没有很多公司达到这种复杂的水平，但你也可以想象，在这种SRE团队中，你可能会感到有点不知所措。因为如果有不好的事情发生，你就会陷入困境，但是一直都有很多事情在变化。就像你需要一些指导，你需要一些帮助来达到这一点，这样你就可以更快地降低风险或控制损失。所以他们做了一些类似的事情，他们训练了一个模型，基于过去一年的40000次部署，我相信其中100次是失败的。我想再次指出，我想我在第三个地方画了第三个地方，部署的失败率只有1 / 400，这非常惊人，但他们实际上并不满意，他们试图做得更好。不管怎样，他们训练了这个模型，然后这个模型可以预先预测99%的故障，而虚警率为5%。这意味着他们的模型，这是一个有风险的部署，然后有5%的时间这是一个虚假的警报，就像什么都没有发生一样。
但是插件可以捕获99%的程序，这已经是很久以前的事情了。这就是他们报告的原因。但也许更重要的是，如果你想想他们所做的事情的影响。因此，基于这种数据，他们能够了解到，例如，这些中断发生在部署中，开发人员估计这是较低的风险。而且，当开发人员批准部署的时间非常短时，宕机往往会发生得更多。换句话说，当变化是匆忙的。然后他们还能协调部署失败就像长寿一样，换句话说，更长的旧代码更有风险，然后你可能会看着这些东西说，好吧，我们已经知道这些东西了但实际上，我认为你错过了重点。
这有点像量化，是的，你可能从定性上知道，但从定量上说，你可以把数字和成本放在这个东西上，这实际上是很大的改变。例如你可以说每个月代码泄漏它增加部署失败的可能性我不知道,1%之类的,我不知道这个公司发现的数字,但是能够显示一些作业和任命,数字和能够量化的业务影响这些东西,突然,它不保理,你一直想做或喜欢,或者你一直想做服务。现在不要担心，只是相信谈话的主题。这很简单，就像一个数字计算。这才是真正能让整个组织运转起来的东西。好了，时间快到了，让我来总结一下。
因此，我认为这些故事之间的联系，这些大型软件开发公司似乎能够采取的实践实际上比小公司要先进得多。现在我曾经认为有一个工程师，一个小型灵活的软件开发团队是最好的软件开发团队，他们可以产生巨大的影响，有点像大卫对歌利亚。现在，在我看到这些东西之后，我开始觉得实际上一些歌利亚实际上比最好的大卫更快更灵活。在这个问题上，我要暂停一下。我并不是说每个大公司都像独角兽一样，这里有很多驴。但我的意思是，你认为是什么在起作用，似乎数据起着关键作用，所以在这一点上，这就是我想留给你们的想法。非常感谢大家的收听，祝大家接下来的节目愉快。