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

今天我和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万次变化他们拿出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%之类的,我不知道这个公司发现的数字,但是能够显示一些作业和任命,数字和能够量化的业务影响这些东西,突然,它不保理,你一直想做或喜欢,或者你一直想做服务。现在不要担心，只是相信谈话的主题。它就像一个数字计算一样简单。这才是真正能改变组织的事情。好了，时间不多了，让我总结一下。
所以我认为连接这些故事的东西，这些大型软件开发公司似乎能够采取的这些实践实际上比小公司要先进得多。现在我曾经认为有一个工程师，一个小而灵活的软件开发团队是最好的软件开发团队，他们可以产生巨大的影响，有点像大卫对歌利亚。现在，在我看到这些东西之后，我开始觉得有些歌利亚实际上比最好的大卫更快更灵活。在这一点上，我要暂停一下。我并不是说每个大公司都像独角兽一样，这里有很多驴子。但我的意思是，你认为是什么造成了差异，数据似乎起着关键作用，所以在这一点上，这就是我想给你们留下的想法。非常感谢您的收听，祝您接下来的节目愉快。