当生产中断时了解问题

场景：

• 您推动生产
• 推动打破了多件事
• 相同的构建没有破坏质量保证或开发
• 作为开发人员，您没有产品访问权限。
• 来自上层的压力很大，促使事情不断发展。

细节：

• 在Zend中由API驱动的PHP / MVC应用程序。
• 部署到几个服务器。

我的问题：

在调查时，可以说我有种直觉，认为出了什么问题。但是，我不确定。而且，当然，我无法测试生产中的东西。如果我有基于这种想法的建议修复程序，那么在理解问题所在之前，尝试并应用它并查看它是否有效是否明智？

尽可能多地获取有关问题的信息（日志文件等），然后将生产服务器回滚到工作状态。从开发人员的角度来看，这当然是痛苦的，但是很可能是给定的。

接下来，尝试看看是否可以在开发环境中重现该问题。如果可以，请对其进行修复，然后再次尝试释放。

如果无法重现，请查看是否可以添加更多诊断并在短时间内发布到一台服务器以获取有关该问题的更多信息。

如果不可能，那么请更仔细地研究生产环境与dev / qa环境之间的差异，并尝试使dev环境更接近生产环境。

如何以及你理解这个问题？您的直觉会使事情变得更糟的风险是什么？是否可以返回并在DEV / QA地区重现该问题？您可以如何同步DEV / QA区域以使其更接近PROD？也许您必须更改某些环境或数据库设置，也许您必须将PROD数据导入DEV，也许您必须更改一些调试设置。

通常，除非您可以确认在其他地区确实是正确的，否则我不建议您对PROD提出解决方案。我了解PROD中发生错误并且无法在其他任何地方重现时会出现的问题。到那时，您就可以查看DEV / QA和PROD之间还有什么不同，并专注于这些。以我的经验，通常是环境设置或某些配置有所不同，特别是对于PROD。而且我知道上面可能有很大的压力要解决此问题，因此有可能回滚到以前的工作状态，然后尝试在DEV中重现该问题，在DEV中提出解决方案，然后再尝试再次在PROD中？那就是我的建议。

取决于修复的种类。通常，没有出现在dev中的生产问题与数据库中的争夺有关。因此，应用一个更改数据库内容而不确定确切的“错误”的bug可能是大灾难的第一步。如果您可以轻松取回更改，则可以尝试一下。但是通常，如果您没有直接访问权限，则至少应有数据库的副本或整个服务器的副本以进行测试。具有正确特权的人仍然必须运行新代码，但至少没有数据丢失的风险。（但是有时数据库的大小或基础架构的复杂性会阻止这种设置）

这真的很困难，因为存在许多可能性，例如不同的设置，库和软件版本。

如果您对错误源的猜测是正确的，那么也许您可以先编写一段代码，然后用一些调试输出进行评估，然后再应用实际的错误修正。

假设Prod，QA和dev之间的代码和数据库相同，通常是配置问题或数据问题。

我先来看以下内容：

• 您的代码具有的所有日志记录数据。
• 检查事件查看器中是否有未处理的异常。
• 检查代表应用程序进度的数据，这些数据可以在数据库，文件等中。是否有意义？你期望的是什么？

一旦了解了所发生的情况，就需要将生产还原到工作状态，并在较低的环境中解决问题，直到修复并重新部署到生产中为止。

当您的环境是PHP时，我已经做了一个关于如何考虑Java的演讲：http : //www.infoq.com/presentations/maintaining-production-java-apps

核心问题是相同的-了解可能的问题来排除故障，例如：网络，文件系统访问，日志文件，死锁等。此外，还要知道如何提出正确的问题：“系统停机”-“您具体做什么？意思是：网页运行缓慢，是否存在特定的错误消息，是否存在超时”，等等。

另外，还有一些工具可以使故障排除更加容易：用于网络故障排除的Wireshark绝对是最好的选择，值得学习。其他取决于您使用的操作系统。对于Windows，来自SysInternal（现在是Microsoft的一部分）的任何功能都很棒。对于Unix / Linux，请查看truss / strace。

在访问生产时，操作组应该知道如何使用这些工具/技术，或者您有一个与他们一起的业务案例以学习如何使用它们。之后，他们需要一组特定的故障排除协议才能在出现问题时运行，因此您可以脱机进行分析。

简短的回答：如果您有选择的话，那不是。

长答案：如果您不了解问题，那么此补丁将涉及多个风险：

1. 您可能会破坏其他东西，甚至可能无法再现。
2. 您可以掩盖问题，使其更难以发现和重现（这使情况更糟）
3. 您正在抛弃潜在的国内经验-这些经验可以使您成为一名更好的程序员，同时又对您的公司更有价值（例如，潜在的未来加薪）。

另一方面，我认为先检查您假设的修复程序是否起作用，然后再进行进一步的挖掘，找出真正的原因或其他可能更好的方法来解决问题，这没有什么害处。