为应用程序提供生产支持是软件开发中最具挑战性的方面之一. 开发人员 是否被分配到维护团队，负责修补应用程序上的错误. 他们是, 然而, 在生产中断的情况下也可以随叫随到, 在这种情况下，他们会努力使应用程序尽快回到正轨.

本文旨在提供一组精心策划的建议，以便您可以防止生产中的bug, 并且更快地发现问题. 在生产环境中处理这些应用程序是一项复杂的任务, 没有可用的文档, 应用程序是在遗留技术堆栈中编写的, 或两个. 培训课程很少, 经常会被叫去为你所知甚少的应用程序提供支持.

许多开发人员没有在生产环境中处理应用程序的经验. 在生产环境中会发生一系列问题，导致错误和中断, 通常会给公司造成数千甚至数百万美元的收入损失. 此外, 由于大多数开发人员没有接触过环境，所以他们会不断犯一些错误, 反过来, 造成这些问题. 通过从制作经验中吸取教训，这些技巧可以让你的工作不那么痛苦.

技巧#1:删除或自动化应用程序运行所需的所有配置.

在新服务器上安装软件需要多少配置? 在过去, 有时候，每当团队中出现新成员时，这需要花费3天时间. 安装应用程序需要许多必须手动执行的步骤. 随着时间的推移, 软件进化出与这些指令不兼容的新版本, 当然, 指令通常不会更新. 突然之间，您花费的时间比仅仅启动和运行应用程序所需的时间要多得多.

随着 集装箱化, 提供一种立即启动并运行应用程序的方法已经变得容易得多, 没有配置，还有额外的好处, 因为Docker镜像是自包含的, 使用不同版本的操作系统时遇到问题的风险要低得多, 语言, 使用的框架.

同样的, 简化开发人员设置, 所以它不需要花费太多时间来启动和运行, 包括IDE设置. 开发者应该能够在30分钟内从零变成英雄.

当生产问题发生时，有时您最好的专家可能无法使用(例如.g., 假期或生病)，你希望你扔给谁的问题都能解决, 并迅速.

技巧2:不要陷入技术堆栈陷阱.

技术越少越好. 当然，有时候，你必须使用正确的工具来完成工作. 然而，要注意不要过度使用“正确的工具”.“即使是喝水，如果喝得太多也会导致严重的健康问题. 添加到技术栈中的每一种新语言和框架都必须经过一个明确定义的决策过程，并仔细考虑其影响.

• 不要仅仅因为需要一个 stringutil class.
• 不要仅仅因为需要编写一个快速移动文件的脚本来添加一种全新的语言.

当库变得不兼容，或者在框架本身或其传递依赖项上发现安全威胁时，大量的依赖项会使您的生活变得悲惨.

此外, 还记得, 堆栈的复杂性增加了为团队寻找和培训新开发人员的难度. 人们在其他公司担任新职位，你必须找到新的工作. 工程团队的人员流动率非常高, 即使是在那些享有丰厚福利和工作与生活平衡待遇的公司. 你想尽快找到新的团队成员. 每一项新技术都增加了寻找新候选人的时间，并有可能使新员工的成本越来越高.

技巧3:日志记录必须引导您找到问题，而不是用无用的细节淹没您.

日志记录与注释非常相似. 有必要记录所采取的所有关键决策以及调试技术中使用的所有信息. 这并不简单, 但是要有一点经验, 可以绘制出一些可能的生产中断场景，然后添加必要的日志记录来解决这个问题. 当然，日志记录会随着代码库的发展而发展，这取决于出现了什么样的问题. 一般来说, 您应该将80%的日志记录在最重要的20%代码上，这是使用最多的部分. 重要的信息, 例如, 参数的值是否传递到方法中, 子类中的运行时类型, 以及软件做出的重要决定, 当它处在一个十字路口的时候, 它可以选择左或右.

技巧4:处理意外情况.

非常清楚地描绘出代码的假设是什么. 如果某个变量应该总是包含值2, 5, or 7, 确保它是枚举类型, 不是整数. 大规模生产中断的首要原因是某个假设不成立. 每个人都在错误的地方寻找问题，因为他们认为有些事情是理所当然的.

假设应该明确地记录下来, 任何对这些假设的失败都应该引起足够的警觉 生产支持 团队可以迅速纠正这种情况. 还应该有代码来防止数据进入无效状态, 或者至少在这种情况下创建某种警报. 如果某些信息应该存储在一个记录中, 突然出现了两个记录, 应该发出警告.

提示5:应该直接复制发生在客户身上的问题.

最困难的步骤之一总是复制客户面临的问题. 很多次, 你将花费95%的时间试图重复这个问题, 然后你就可以复制它了, 补丁只需要几分钟, 测试, 和部署. 像这样, 应用程序架构师应该确保复制问题非常简单和快速. 很多这样的事情发生是因为, 以达到与客户相同的情况, 开发人员必须做大量的应用程序配置. 存储了许多记录，这些记录混合了客户所处的情况——问题是，作为开发人员的您必须准确地猜测客户做了什么. 有时，他们已经完成了一系列的步骤，他们只记得最后一个.

也, 客户将用业务术语解释问题, 开发人员必须将其转换为技术术语. 如果开发人员对应用程序的经验较少, 他们不会知道去询问缺失的细节, 因为他们还不知道失踪的细节. 将整个生产数据库复制到您的机器上是不可行的. 因此，应该有一种工具可以快速地从生产数据库中导入模拟情况所需的少量记录.

假设客户对订单屏幕有问题. 您可能需要导入他们的一些订单, 他们的客户记录, 一些订单详细记录, 订单配置记录, 等. 然后您可以将其导出到Docker实例中的数据库中, 启动该实例, 就像这样, 你看到的和客户看到的是一样的. 所有这些, 当然, 是否应该采取适当的措施来确保开发人员无法访问敏感数据.

提示#6:在应用程序中放置断点的位置应该很明显.

如果您有一个Customer屏幕, 应该有一些Customer对象，您可以在其中放置断点以调试该屏幕上的问题. 有时候开发者会陷入抽象狂热，想出一些非常聪明的概念来处理用户界面事件. 而不是, 我们应该始终遵循KISS原则(Keep it Simple), 圣-呃, 并且每个UI事件都有一个容易定位的方法. 同样的, 对于批处理作业和计划任务，应该有一种简单的方法来发现断点的位置，以评估代码是否正常工作.

技巧7:确保所有的外部依赖都被明确地记录下来.

在理想的情况下, 在源代码控制系统的README文件中这样做，这样文档就不会丢失. 记录任何外部系统, 数据库, 或者应用程序必须可用才能正常运行的资源. 也, 注意其中哪些是可选的，并添加关于如何处理它们的说明，当它们是可选的且不可用时.

超越调试技术

一旦在创建新功能或提供系统维护时遵循了这些建议, 生产支持将变得容易得多, 而且你的公司会花更少的时间(和金钱). 大家都知道, 在对产品错误和崩溃进行故障排除时，时间是至关重要的——节省下来的任何一分钟都将产生重大影响. 快乐的编码!