DevOps百花齐放，DevOps无处不在，现在一切都与DevOps息息相关。但是我发现了一个没有人注意到的关于Deveops的新趋势。最近看很多人在做关于2021年DevOps发展趋势的文章，DevOps正在蓬勃发展。DevOps就是一切，现在一切都是DevOps。以下是当今呈爆炸式增长的DevOps趋势的部分列表：混合部署DataOps弹性测试生产测试GitOps微服务（当然）无服务器以云为中心的基础设施边缘计算基础架构即代码开发安全(DevSecOps)应用程序性能监控(APM)工具混合计算（HybridComputing）KubernetesFeatureToggles（特性切换）这个列表不胜枚举……但是看完所有这些文章后，我震惊了是的，没有人将“非侵入式生产调试”视为标准组件DevOps工具链。这就是我看到的DevOps趋势。那么什么是“非侵入式生产环境调试”呢？我们从头说起，当我们要调试生产环境中的问题时，我们最常用的方式就是——看日志文件。这个痛苦的、重复的过程是这样的：NastyError该死的，我没有足够的数据。让我在日志中添加几行BuildDeploy重现错误的步骤查看日志是否发现问题？否——回到第2步发现（经过几次长时间的尝试）——终于结束了你也可以选择远程调试器直接连接到生产环境，但很多时候，运维团队不允许这样做。出于安全原因，您不希望在断点处暂停执行并中断服务。非侵入式生产调试遵循可观察性工具的概念。这些是用于显示、分片和分块日志、指标和跟踪的APM（应用程序性能监控工具）。这就是可观察性。在不中断或干扰系统操作的情况下，了解您的系统正在发生什么（这样您就可以解决错误）。但是，在修复生产环境中的错误时，这些工具通常无法提供足够的数据。通常，他们可以获得的最详细信息是显示抛出异常的位置，以及堆栈跟踪和一些关于错误情况的一般元数据，例如浏览器或操作系统信息。通常此信息不足以找到错误。微服务和无服务器等现代软件架构使事情变得更加困难。想象一下，追踪一个导致Kubernetes集群中的节点崩溃的错误，而Kubernetes只是启动了一个新实例。或无服务器功能中的逻辑错误。当您调试这些问题时，证据会随着实例的销毁而消失。非侵入式生产调试使可观察性更进一步，在代码级别逐行显示应用程序行为，即使对于微服务和无服务器代码也是如此。这就是我们所说的代码级可观察性，它补充了DevOps无法从APM（应用程序性能监控工具）获得的可观察性。为什么我认为这是一个重要的趋势？你可以猜到为什么我如此痴迷于非侵入式生产调试。因为这就是我公司的基础，我们的看法在与潜在客户和客户会面时发生了显着变化。一年前，主持会议的同行是开发人员，尽管是高级开发人员或开发经理，但他们仍然是开发人员。DevOps工程师可能在会议室，但他们只是在会议期间坐在后排，只有在我们开始讨论软件如何影响或不影响生产系统时才会参与，还有更多关于安全、性能、部署的问题，等讨论。但是DevOps工程师对我们的生产调试器如何使用或如何处理它们并没有太多了解，至少DevOps人员没有。他们只是将其视为开发人员需要他们在生产中维护的另一种工具。在过去的一年里，重点已经明显转移。坐在会议室前排的DevOps工程师提出了更多问题，并开始意识到有效的生产调试如何显式地影响DevOpsKPI，即使实际上是开发团队中的工程师在做根本原因（rootcause）分析和提出建议或提交代码。DevOps团队开始更加关注生产调试。为什么DevOps工程师对生产调试感兴趣？部分原因是生产调试器也可以在QA和Staging等预生产环境中运行。DevOps工程师知道，能够在QA或登台以及生产环境中更快地调试和修复错误意味着它可以帮助改进DevOpsKPI：登台环境过滤掉更多错误（更低的变更失败率、更低的缺陷丢失率和更高的均值timebetweenfailures(MTBF))一个自动捕获并显示异常的生产环境调试器，不仅在错误发生时立即通知你，还会记录错误的完整执行流程，使你可以非常快速地了解你是否正在处理真正的错误或微不足道的错误，它们的严重性和影响（减少平均探测时间(MTTD)）。生产环境调试器大大减少了识别、分析和修复生产错误所需的时间（即平均恢复时间(MTTR)）。当我们开始谈论这个KPI时，坐在房间里的所有DevOps工程师都会坐起来，因为它反映了当生产中出现问题时服务将不可用的时间。我们知道这必然会发生，只需查看downdetector.com，一个记录网站不可用的检测站点，您就会明白我的意思。DevOps工程师和SRE意识到生产调试器更像是监控和代码可观察性，而不仅仅是开发人员工具。它还非常符合DevOps的反馈和协作原则，弥合了DevOps与开发人员之间仍然存在的鸿沟（许多组织中仍然存在）。借助生产调试器，开发人员可以直接从生产系统中获取所需的数据来排查错误。使用生产调试器，DevOps和开发人员可以直接协作来解决生产中的错误，这是快速修复错误和解决生产事件的催化剂。那么生产调试器是如何工作的呢？远程调试器生产调试并不是一个新概念。远程调试已经存在了一段时间，您可以在运行时注入断点，每次遇到断点时收集数据，然后立即继续该过程并重复。虽然这是一种获取生产数据的简单方法，但它具有侵入性并且会对性能产生重大影响，因此目前并未得到广泛使用。快照调试的另一种方式是快照调试。调试器会fork一份进程的副本（使用copy-on-write技术），然后通过检查副本进行调试。虽然此方法允许您检查调试过程的整个内存占用情况，但它也是侵入性的并且会给正在运行的主机带来很大的内存负载，因此可以创建快照的磁盘数量是有限的。检测现代生产调试器使用第三种方法——字节码检测。他们向执行不同功能的字节码添加检测，例如测量性能、捕获应用程序状态、捕获异常等。这就是APM多年来一直在做的事情。生产调试器更进一步。它使用与APM相同的技术，目标是解决错误和逻辑错误，而不是解决生产和预生产环境中的性能问题。由于人类无法阅读字节码，让我们看看如果我们在源代码中添加检测，字节码会是什么样子。代码如下：publicasyncTaskApplyBundleCode(stringcode){varcustomer=awaitProfileService.FetchProfile(User);varbasket=awaitBasketService.LoadBasketForCustomer(customer);varbundle=awaitBundlesService.FetchBundle(code);if(bundle.IsCustomerEligible(customer)){bundle.ApplyOn(basket);awaitBasketService.UpdateBasketForCustomer(customer,basket);}returnbasket;}加入检测后，可能看起来像这样：publicasyncTaskApplyBundleCode(stringcode){Telemetry.startTimer(“ApplyBundleCode”);Telemetry.logVariable(“User.Id”,User?.Id);varcustomer=awaitProfileService.FetchProfile(User);Telemetry.logVariable(“Customer.FullName”,customer?.FullName);Telemetry.logVariableAsJson(“Customer.Address”,客户?.地址）；varbasket=awaitBasketService.LoadBasketForCustomer（客户）；Telemetry.logVariableAsJson（“篮子”，篮子）；Telemetry.logVariable（“代码”，代码）；varbundle=awaitBundlesService.FetchBundle（code);Telemetry.logVariable("code",code);if(bundle.IsCustomerEligible(customer)){Telemery.log("bundle{0}eligibleforcustomer{1}",code,customer.FullName);bundle.ApplyOn(篮子);Telemery.log("abouttoupdatebasket");awaitBasketService.UpdateBasketForCustomer(客户,篮子);}else{Telemery.log("bundle{0}noteligibleforcustomer{1}",code,customer.FullName);}Telemery.endTimer("ApplyBundleCode");returnbasket;}调试检测代码也很有挑战性。大多数现代生产环境调试器需要先使用git找到生产环境中使用的确切提交，并从中构建与生产环境相同的二进制文件以进行调试。将所有正确的源文件与当前在生产环境中运行的文件相匹配并不总是那么容易，您还需要匹配一组构建和编译设置。那么第三方代码呢？一些工具通过反编译正在调试的生产代码来解决这个问题。这让生活变得更轻松，因为它消除了匹配源文件和反编译第三方代码以及遗留代码的要求。为什么非侵入式优于侵入式远程调试器非常具有侵入性，因为它们连接到主机应用程序并在实时运行的系统中放置断点。即使应用程序只是为了远程调试器收集数据而短暂中断，仍然存在许多生产系统无法容忍的重大稳定性风险。同样，快照调试器通过它使用的侵入式写时复制技术强加给正在运行的系统的内存开销可能会耗尽系统内存。例如，Microsoft的SnapshotDebugger默认为每分钟最多五个快照以避免抛出内存不足异常。仪器可以用生产调试器做什么？现代生产调试器所做的大部分工作都是基于不间断断点（也称为跟踪点）。在要获取数据的行上打断点（也就是跟踪点），让调试器插桩获取数据。您实际上可以做很多事情：动态日志记录：在代码中的任何位置记录数据，包括局部变量和方法参数的值。动态指标：就像动态日志一样，您可以从局部变量中提取应用程序级数据来衡量不同的指标。集成：您可以通过API将您测量的任何内容传播到第3方应用程序，而无需中断断点/跟踪点。因此，您可以创建Slack通知或将动态日志和指标数据传递到APM，您可以在APM中进一步对数据进行切片和分块，以漂亮的图形和图表查看它，并创建有意义的警报。除了使用不间断断点/跟踪点可以完成的工作之外，一些生产调试器还可以执行以下操作：抛出异常的值。时间旅行记录：一些生产环境调试器不仅捕获异常，还捕获导致异常的错误执行和应用程序数据的完整流程。这允许逐行调试异常，就像在开发环境的IDE中调试体验一样。那么谁是主要参与者呢？APM和可观察性已经存在了大约十年，并且有很多很棒的企业级产品。后来出现了现代生产调试工具，提供了查找错误根本原因所需的代码级可观察性。由于我本人来自Ozcode，因此在描述市场上主要的现代生产调试工具时，我不想冒有偏见的风险，所以请随意浏览以下站点并发表您自己的评论。https://www.rookout.com/https://lightrun.com/https://www.nerd.vision/https://oz-code.com/https://www.thundra.io/sidekick侵入式生产环境调试将成为DevOps工具链不可或缺的一部分任何新技术成为企业年度预算的标配项目都需要一段时间。APM已经存在，任何关注软件的企业都使用这些工具来管理、监控和排除其生产系统的故障。然而，DevOps专业人员现在意识到，在调试生产问题时，逐行挖掘代码，APM无法提供足够的调试数据。当您提供代码级可观察性、动态日志记录和跟踪以及时间旅行调试时，非侵入式生产环境调试器已被证明可以将生产调试时间减少多达80%。当停机成本高达每分钟5,600美元时，DevOps专业人员不能忽视这一实际业务成本。APM是决定当今需求的技术。用不了多久，非侵入式生产环境调试器的价值将成为企业必备的技术之一。DevOps革命拉近了运维人员与开发人员的距离。现在是该合作迈出下一步，进入调试领域的时候了。
