经验分享:一位初级工程师如何在亚马逊五年时间内修复数百个Bug?


Curtis Einsmann在亚马逊的5年中已经诊断并解决了数百个错误。作为一名初级工程师,大型软件系统中的错误诊断具有挑战性。 下面是他的经验总结:
原因的诊断很重要。不成熟的解决方案使得问题持续存在,这些微小的缺陷很容易被开发人员忽略。诊断原因是修复的第一步。
清晰表达问题:

  • -预期会发生什么行为?
  • -是否有错误代码或屏幕截图?
  • -是否可以使用已知的标识符进行诊断?
  • -确切的时间(和时区)?

这种清晰性为我提供了一个具体的起点。
将所有书面交流都视为故事,这可能是对也可能是错。问题描述讲述了发生的事情。系统文档讲述了事情的运作方式。故事不是100%的真理。我怀着怀疑的态度阅读。事实是在代码和日志中
我确保我正在浏览正确的日志和代码提交。我避免了以下常见的令人沮丧的错误:
  • -读取错误的日志
  • -读取错误的时间跨度
  • -在与事件时间不一致的提交中浏览源代码

这样可以节省时间(和我的理智)。
我同时阅读日志和代码。日志告诉我执行了什么代码。该代码告诉我要查找哪个日志语句。我按已知的标识符过滤日志:请求ID、实体ID、用户ID。 此过程需要时间和耐心。
我会注意误导日志。堆栈跟踪和错误消息非常有用,只要它们与问题相关。有时候,现象欺骗了我。我跳进坑,把自己从大坑里拉出来。迭代之后,我会对发生的事情提出了一个假设。
我检验我的假设。这对于确认发生了什么是必要的。我使用alpha或beta环境。根据情况,这可以是手动测试和/或单元测试。如果被证明是错误的;回到日志。如果证明是正确的,是时候修复该错误了。
经过测试暴露后,我修复了该错误。错误修复是使用严格的TDD方法的绝好机会。我编写一个失败的测试,更改代码,并观察通过的测试。
我会在修复报告ticket中记录了详细信息:
  • -根本原因
  • -日志链接
  • -过滤器表达式或Linux命令
  • -相关指标
  • -我如何修复它保持记录。

它会帮助以后的同行遵循类似的流程。
我会为诊断期间遇到的痛点创建了积压任务:
  • -很难找到日志吗?
  • -日志不足或不正确?
  • -诊断乏味吗?
  • -为方便起见,

我们会编写运维脚本,这改善了长期的卓越运营。
这就是我诊断和解决大型软件系统中的错误的方式。