加快生产中故障排除速度的7种调试技术 _故障排除

为应用程序提供生产支持是软件开发最具挑战性的方面之一。开发人员被分配到维护团队, 并致力于修补应用程序中的错误。但是, 如果发生生产中断, 它们也可以随时待命, 在这种情况下, 它们可以使应用程序尽快恢复正常运行。
本文旨在提供一组精选的建议, 以便你可以防止生产中的错误并更快地发现问题。在生产中处理这些应用程序是一项复杂的任务：通常, 没有可用的文档, 或者应用程序已在旧技术堆栈中编写, 或者两者都有。培训课程很少, 通常会打电话给你不了解的应用程序提供支持。
许多开发人员没有在生产环境中处理应用程序的经验。生产环境中会发生一系列问题, 这些问题会导致错误和中断, 通常会给公司造成数千乃至数百万美元的收入损失。而且, 由于大多数开发人员没有暴露于环境中, 因此他们不断犯一些错误, 这些错误又会导致这些问题。通过从生产经验中学到的技巧, 可以使你的工作减轻痛苦。
提示1：删除或自动运行应用程序所需的所有配置。
【加快生产中故障排除速度的7种调试技术】要在新服务器上安装软件, 需要多少配置？过去, 每次团队中有新开发人员时, 有时可能需要三天才能完成。安装该应用程序将需要许多步骤, 这些步骤必须手动执行。随着时间的流逝, 软件会演变为新版本, 与这些说明不兼容, 当然, 说明通常不会更新。突然之间, 你花费的时间超过了不必要的时间, 仅仅是为了启动和运行应用程序。
随着容器化的到来, 提供一种使应用程序立即启动并运行, 零配置的方法变得更加容易, 并且具有额外的好处, 因为Docker映像是自包含的, 因此你可以以更低的成本运行可能会遇到使用不同版本的操作系统, 语言和框架的问题。
同样, 简化开发人员设置, 因此不需要花费很多时间就可以启动和运行, 包括IDE设置。开发人员应该能够在30分钟内从零变成英雄。
当发生生产问题时, 有时可能没有你最好的专家(例如, 假期或病假), 并且你希望遇到问题的任何人都能迅速解决。
提示2：不要掉进技术堆栈陷阱。
使用的技术越少越好。当然, 有时候, 你必须使用正确的工具来完成工作。但是, 请注意不要过多使用” 正确的工具” 。如果过多饮水, 甚至会导致严重的健康问题。添加到技术堆栈中的每种新语言和框架都必须经过明确定义的决策过程, 并仔细考虑其影响。

不要仅仅因为需要StringUtils类而添加新的框架依赖项。
不要仅仅因为你需要编写快速脚本来移动文件而添加全新的语言。

当库变得不兼容或在框架本身或在其传递依赖项上发现安全威胁时, 大量依赖项会使你的生活陷入困境。
此外, 请记住, 增加的堆栈复杂性给团队寻找和培训新开发人员带来了挑战。人们开始在其他公司中担任新职位, 而你必须找到新职位。工程团队的员工流失率非常高, 即使在那些享有出色津贴和工作与生活平衡待遇的公司中也是如此。你希望尽快找到新的团队成员。在技??术堆栈之上添加的每项新技术都会增加寻找新候选人的时间, 并有可能使新员工的费用越来越高。
提示3：日志记录必须引导你找到问题, 而不是淹没你无用的详细信息。
日志记录与注释非常相似。有必要记录正在执行的所有关键决定以及调试技术中要使用的所有信息。这并不简单, 但是只要有一点经验, 就可以确定几种可能的生产中断情况, 然后输入必要的日志记录至少可以解决该问题。当然, 日志记录会随着代码库的发展而变化, 具体取决于出现的问题类型。一般而言, 你应该将80％的日志记录在最重要的20％的代码上-这将是最常使用的部分。例如, 重要信息是传递给方法的自变量的值, 子类的运行时类型以及软件做出的重要决定, 也就是说, 它处于十字路口时选择左或右。
提示4：处理意外情况。
非常清楚地映射出代码的假设。如果某个变量应始终包含值2、5或7, 请确保其为枚举类型, 而不是int类型。大型生产中断的头号来源是当某个假设失败时。每个人都在错误的地方寻找问题, 因为他们认为某些事情是理所当然的。
假设应明确记录在案, 并且对这些假设的任何失败都应引起足够的警报, 以使生产支持团队可以迅速纠正这种情况。还应该有代码来防止数据进入无效状态, 或者至少在这种情况下创建某种警报。如果某些信息应存储在一个记录中, 而突然又有两个记录, 则应发出警告。
提示5：复制客户遇到的问题应该很简单。
最困难的步骤之一就是始终复制客户面临的问题。很多时候, 你将花费95％的时间来尝试复制问题, 然后在你复制问题的那一刻, 修补, 测试和部署只需几分钟。因此, 应用程序架构师应确保复制问题非常简单快捷。之所以发生这种情况, 是因为要达到客户所处的相同状况, 开发人员必须进行大量的应用程序配置。存储了许多记录, 这些记录一起加深了客户的处境, 问题是作为开发人员的你必须准确猜测客户的所作所为。有时, 他们执行了一系列步骤, 其中只有最后一步。
此外, 客户将以业务术语解释问题, 开发人员必须将其翻译为技术术语。而且, 如果开发人员对应用程序的使用经验较少, 他们甚至不知道缺少的细节, 因此他们将不知道要求提供这些细节。将整个生产数据库复制到你的机器是不可行的。因此, 应该有一个工具可以从生产数据库中快速导入仅少量模拟情况所需的记录。
假设客户的” 订单” 屏幕有问题。你可能需要导入一些他们的订单, 他们的客户记录, 一些订单明细记录, 订单配置记录等。然后, 你可以将其导出到Docker实例中的数据库中, 启动该实例, 就像这样, 看到客户正在看到的相同的东西。当然, 所有这些操作都应谨慎进行, 以确保没有开发人员可以访问敏感数据。
提示6：将断点放在应用程序中的位置应该很明显。
如果有” 客户” 屏幕, 则应该有一些” 客户” 对象, 你可以在其中放置断点以在该屏幕上调试问题。有时, 开发人员陷入抽象热潮, 并提出了一些关于如何处理用户界面事件的非常聪明的概念。取而代之的是, 我们应该始终依靠KISS原则(保持简单, 稳定, 愚蠢), 并在每个UI事件中都有一个易于定位的方法。同样, 对于批处理作业和计划的任务, 应该有一种简便的方法来确定放置断点的位置, 以评估该代码是否正常工作。
提示7：确保所有外部依赖项都已明确记录在案。
理想情况下, 请在源代码管理系统中的README文件中执行此操作, 以使文档不会丢失。记录所有外部系统, 数据库或资源, 这些外部系统, 数据库或资源必须为应用程序正常运行所必需。另外, 请注意其中哪些是可选的, 并添加有关如何在它们为可选且不可用时进行处理的说明。
超越调试技术在创建新功能或为系统提供维护时遵循这些建议后, 生产支持将变得更加容易, 并且你的公司将花费更少的时间(和金钱)。如你所知, 在排除生产错误和崩溃时, 时间是至关重要的-可以节省的每一分钟对底线都有很大的影响。编码愉快！