如何解决生产问题

在我的工作中,我发现办公桌上出现的大部分问题是“嘿,您做的这件事坏了”或“嘿,您处理过的这件事正在紧张。” 99%的时间,我不知道他们为什么要问这种行为!

但是,我认为我有一个很棒的解决问题的方法,我认为这是成功的关键。 也许某些敏捷的作者可以在这里接受这些概念,我们可以开发出解决问题的正式方法。

预防措施

作为专业人士,我们应该接受不可避免的生产问题。 您将在代码中创建缺陷,并且无需进行大量测试就可以消除它们。 代码匆忙,服务器崩溃,磁盘出现故障以及数据中心过热。 接受发生生产问题这一事实非常重要,但是最重要的是,您需要为它们进行计划。 正如我最喜欢的一位财务顾问所说:“这些事件是否会发生并不重要; 这仅仅是它们何时会发生的问题。” 计划您的一周/月,并安排几个小时来调查奇怪的行为,崩溃或用户投诉。

您的开发人员必须随时待命。 我发现开发人员代码的简洁性与他的职业生涯中是否必须待命之间有着密切的关系。 不必铲自己的小玩意儿的人就不会在预防问题上有利益! 事情就是这样,可拨打的电话用于紧急情况。 应该理解的是,如果该问题现在暂时没有发生,那么就不必立即解决它。 经常使用寻呼机来延长员工的工作时间! 如果您到了要看代码的地步,则可能应该同意写一本500页的文章,让整个团队早上都对这个问题感到不适。 此外,如果用户在深夜打电话报告他们几个小时前未能报告的问题,则它有可能等到白天。 保护通话中的电话非常重要,请保存在草地上着火的时候

使用错误追踪系统! 这是如此明显,令我惊讶的是有多少家公司没有这个。 当事件发生时,用事件更新错误报告。 保持事件记录非常重要……当您向管理层建议他们给您时间解决问题时,记录进行危机诊断所花费的时间是非常宝贵的资源!

保留应用程序清单。 让您的开发人员为每个应用程序创建一个Wiki条目,该条目具有以下信息:

  • 需要运行哪些配置文件
  • 连接到哪些数据库
  • 读什么表
  • 与哪些EIS系统交互
  • 使用什么队列/主题名称
  • 什么用户名用于与上述系统进行交互
  • 日志所在的位置
  • 已知问题!

不要低估此信息的重要性! 在您的SDLC中,您应该有一个步骤可以更新上述信息!

好的,我正在通话。 电话响了。 我该怎么办?

您的第一步应该始终是对症状进行准确的描述。 然后,您必须将问题范围缩小到能够:按需复制或预测下一次发生的时间。 例如,如果您有一个B2B Web服务,并且使用者在抱怨发送SOAP错误,那么您的第一步应该是让他们转储引起问题的XML请求。 如果最终用户在单击链接时抱怨错误消息,则应让他们复制链接并截取屏幕截图。 我称此为“缩小问题范围”。 这是最重要的步骤。 它不是可选的,除非知道问题所在,否则不要继续在系统上工作! 您可以通过进行任意更改来轻松使情况恶化,并且随机解决某些未知问题的可能性非常大。

如果导致问题的最终用户不可用,或者另一端的人不愿意提供您要求的信息怎么办? 我认为这是最好的策略,问他们他们希望您如何进行。 让他们完全完成而不中断。 也许他们在做某事,或者有另一种选择。 或者,也许他们在左领域,如果它向左领域倾斜,请向他们解释您无法解决您不了解且无法重新创建的问题。 不要害怕坚持自己,它需要信息来解决问题!

好吧,让我们开始吧。 已经晚了,我想回去睡觉

在将问题缩小到非常具体的故事或用例之后,就该开始工作了。 首先,将生产服务器的日志复制到本地计算机上。 如果在进行故障排除时滚动日志,则可能永远找不到根本原因。 接下来,将与问题有关的所有数据复制到数据库之外,并以文本格式与日志文件一起存储。 这可能意味着对应用程序的配置表,用户的配置文件行以及他们尝试访问的数据进行快照。 如果您认为相关,请复制它! 如果您认为无关,请复制它! 最后,记下应用程序的版本,服务器的错误修正级别以及服务器上可用的库的版本号。 ew!

接下来的事情是买铅笔和纸。 您应该写下您所采取的步骤和时间,更重要的是您要写下来的原因。 必须在执行步骤时完成此操作,但不必太冗长。 例如:

“ 3:12 am注意到日志文件包含许多事务超时,这意味着连接池可能被锁定。 重新启动应用程序服务器”

此项分为三部分,第一部分是观察,第二部分是分析,第三部分是纠正措施。

那么,您如何发现问题呢?

是时候使用您在预防措施部分中所做的应用程序清单了。 可以说日志报告在数据库中找不到该用户。 由于您已经缩小了问题的范围,因此只需参考库存并作为应用程序进行连接,然后继续查找用户。 如果找不到它们,则问题已解决(暂时)! 您的清单将准确告诉您从哪个表和数据库检索此信息。

但是,如果您什么都没找到怎么办? 好吧……您还需要更多一些。 筛选日志文件和数据库条目。 您是否看到任何看起来不合适的东西? 由于您已经缩小了问题的范围并重现了该问题,因此您可以尝试使用其他用户来重现该问题吗? 如果最终用户再次创建问题时实时跟踪日志,该怎么办? 您可以在框架(Spring,Hibernate等)中启用调试日志记录吗? 您可以在非生产环境中重现该问题吗? 如何在系统执行时启用远程调试和逐步调试? 如何清理临时文件或删除JSP编译目录? 系统是否已用完磁盘空间? 最后,老式的重启可以解决问题吗?

宿醉

因此,您昨晚在电话中待了一两个小时,第二天除了迟到外还做什么? 在离开家之前,请随身带上铅笔/纸。 打开您的错误跟踪系统,或向所有者发送电子邮件,并包含原始投诉,日志,数据库条目以及最终解决问题的内容。 将您的快速笔记记录在票证中。 最好在隔天完成此操作,然后再忘记解决问题的方式以及做出决定的原因。

如果您遵循此条目中的每个步骤,则可以毫无问题地向管理层全面报告错误之处和解决方法。 这些信息对于修补客户的任何问题至关重要。 如果有任何障碍,它也可以用于CYA! 最后,我希望这将使您成为一个解决问题的专家,准备编写更好,更简单的代码( 使用SLF4J编写大量调试语句 )。

参考: The Code Mechanic博客上的JCG合作伙伴 Jonathan 如何解决生产问题

相关文章 :


翻译自: https://www.javacodegeeks.com/2011/09/how-to-solve-production-problems.html

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值