远程环境中不该重现问题的五个理由！

Posted 2021-06-16 程序员小捣

核心要点

● 开发团队花费大量的时间来修复有问题的代码。拥有正确的工具来减少缺陷解决过程的时间对开发团队快速推动项目来说是至关重要的。

● 诸如配置漂移、数据安全约束以及通常来说较为缓慢的企业流程这样的挑战限制了开发团队在寻找和解决产品问题时快速行动的能力。

● 开发团队目前用于观测和监视应用程序的工具是有用的，但是它们并不总能给与开发团队用于解决问题的各类正确信息。

● 在许多情况下，现代尖端生产调试工具可以让开发团队不再创建专门的缺陷再现环境，并且这些环境的创建和维护既昂贵又耗时。

● 生产调试工具与APM、日志记录和异常管理空间中的当前可观察性工具协同工作，使团队能够在不停止应用程序或不需要更改代码的情况下获得有关其应用程序在代码级别所做工作的详细信息。

BUG是软件开发过程中不可避免的一部分，同时也是开发团队在构建软件过程中耗时最多的一部分工作。

据Stripe的一项调查研究显示：开发人员每周花在调试和重构等维护工作上的时间超过17个小时，其中大约四分之一的时间用于修复错误代码。这导致每年近3000亿美元的生产力损失。

基于这个原因，必须保证开发的时间得到合理的利用并且他们能够使用有助于优化缺陷解决过程的工具。

大部分浪费的时间通常发生在大多数开发团队较为熟悉的一个特定场景中，即：在生产环境中发现了一个bug，但是开发人员发现他们的日志文件中没有正确的信息来帮助诊断这个问题。

团队要经历一个迭代周期，在构建中加入新的日志信息并推送出去，并最终选择将当前的生产构建部署到远程测试或暂存环境中，希望能够更轻松地再现问题。

这样做有时可能会奏效，但是有时候环境不太一样的话就无法充分地再现问题并使得问题得不到有效解决。在本文的其余部分中，我们将了解不应在远程环境中重现问题的一些原因。

原因一：配置漂移

当我们尽量使开发测试环境与生产环境保持一致时，配置漂移依然时有发生的。

如今，大多数团队都意识到，像基础设施代码和持续部署这样的过程可以极大地减少配置漂移，但即使有严格的实践，配置漂移通常也是不可避免的。

类似于对服务器的包更新、内存和CPU配置的差异，或者开发人员或测试人员在服务器上进行的手动更改之类的事情，都可能导致配置漂移。

与忙着在远程测试环境中部署应用系统来查找缺陷的根本原因相比，通过监视系统在本地环境中的运行状态来获得更多解决问题的线索，后者的做法要容易的多。

生产调试工具可以让团队更快地解决缺陷，而不必担心在缺陷在一个单独环境中的可复现性。

原因二：效率低下且费时

当下，很多团队都拥有自动化的构建和部署过程来自动化地创建或者拆除环境，但仍有很多团队缺少这一过程。无论你所在团队是哪一种情况，构建一个新环境都是非常费时的。

当开发团队不得不停下手上的工作等待新环境的启动时，就会发生上下文的切换，这无疑会导致生产率的降低。

在这些环境中部署新的构建可能需要几分钟到几小时，如果需要批准并且需要多个团队参与的话，甚至需要几天时间。

除了启动这些环境非常耗时之外，长时间运行这些环境所需的云或其他基础设施的花费也十分高昂。一般来说，由于成本的限制，大多数组织都不会制造生产环境的精确副本，这可能意味着某些难以复现的依赖于特定环境的缺陷在这些远程副本环境中仍然无法解决。

原因三：无法重现BUG

我们都曾遇到过这样的场景：你在生产环境中发现了一个BUG，你尽可能地从日志中收集更多的细节并尝试在测试环境中重现这个问题，但最终你空手而归。这个缺陷被标记为“不可复现”。

我们经常听到客户这样说：有些BUG无法解决，因为当应用程序在生产环境中运行时，你无法获得所需的信息，并且当你尝试在测试环境中重现问题时，BUG不会重现。

对于软件开发团队来说，由于无法复现的原因导致在生产环境中存在的BUG数月甚至数年都没有得到有效解决的情况，其实非常普遍。

在这种情况下，拥有合适的工具让你直接在命令行下对应用程序进行调试而无需修改代码或者重新部署应用程序，这样的工具对团队来说就变得至关重要。

原因四：数据约束

当试图在多个环境中复现同一问题时，测试数据管理必须有一个可靠的流程保障。测试数据对于BUG的复现是至关重要的，如果你的环境中没有正确的测试数据，那么BUG可能就不会复现。

由于生产数据集的规模巨大，团队必须通过测试环境来处理这些数据的子集。测试数据管理过程的目标是让团队可以方便快捷地获取生产数据的子集，并且通过这些子集可以复现BUG。

实际上，事情并不总是那么容易解决。因为很难知道测试数据的哪些属性可能会影响特定的BUG。此外，当跨环境使用数据子集时，处理PII数据时的数据安全性可能是一个重大挑战。团队需要通过屏蔽或生成新的相关数据集来确保它们符合公司数据隐私标准。

很多时候，需要大量的日志记录和实际调查才能发现数据差异是如何导致那些难以发现的BUG的。如果你不能轻松地按需管理和设置测试数据，那么尝试在远程环境中复现BUG时，团队将承受一系列不良后果。

原因五：正确的工具

俗话说，当你唯一的工具是锤子的时候，所有的问题都开始变得像钉子一样。跳出条条框框来思考问题，拥有合适的工具往往会让生活变得更轻松一些。

在尝试调试生产问题时，大多数团队所能想到的标准工具集是APM、日志和异常管理工具。虽然这些工具都很有用，而且都在特定的时间和地点下可供使用，但当开发人员想深入到在生产环境中运行的代码时，这些工具就不能提供所需的细节以弄清那些难以复现的BUG。

生产调试工具允许开发人员深入了解APM工具所不能捕捉的细节。

它们还允许从应用程序中按需收集日志或数据快照，但与传统的日志解决方案不同，这一切都可以在不编写代码或重新部署应用程序的情况下完成。拥有一个生产调试解决方案通常可以让开发人员在缺陷发生的时间和地点找到缺陷，而无需花费额外的精力来构建一个新的环境。

结论

目前，各类软件开发团队花费了太多的时间和金钱在远程环境中复现BUG。现有的一些用于监控和调试应用程序的工具起到了一定的作用提供了一定的价值，但是并不总能提供给开发人员识别和解决BUG的相关信息。

尽管创建缺陷复现环境有时对修复BUG来说不可避免，但是如果能让开发团队拥有正确的工具将事半功倍，毕竟与远程环境相关的约束和成本总是有限的。