开发者技术前线 ,汇集技术前线快讯和关注行业趋势,大厂干货,是开发者经历和成长的优秀指南。
Google 为什么把几十亿行代码放在一个库支付宝架构到底有多牛? 为什么还崩溃了?
The following article is from InfoQ Author 熊节
开发人员测试变更内容(属于流程中的常识性步骤,因此不做强调)。
代码审查(仅需要一名审查员,用于审查的时间一般也不长)。
将代码 push 至预生产环境。测试预生产环境。
在 push 至生产环境前重新审查变更清单。
在 push 至生产环境过程中重新审查变更清单。
在 push 至生产环境之后重新审查变更清单。
测试标准实践明确指出,飞行员必须妥善记录变更清单。
在团队日历当中安排 push 至生产环境的时间。
对 PR 进行审查与批准。
相关团队测试并批准各项变更。
由指定的测试人员确保所有测试用例均正常通过并符合要求。
提交申请与测试或者生产环境无冲突。
在台式机及移动设备上运行冒烟 / 回归测试。
发布流水线中无即时事故(build 失败)。
在此期间,不存在其他部署申请。
在 Slack 中通知部署已经开始。
按下“红色按钮”开始 push 至生产环境。
检查部署脚本日志以了解部署是否成功。
在台式机及移动设备上运行冒烟 / 回归测试。
以一小时为周期,监控所有日志及统计图表。
通知变更相关团队。
如果没有问题,在 Slack 当中宣布部署成功。
为什么会出问题?
本应以怎样的方式加以预防?
某公司在事后做了什么?
PR 当中包含对某行代码的微小变更,可能影响巨大,但相关描述非常模糊。
在同一 PR 当中,三分之一的程序流并未经过王二的实际测试,因为他觉得抽查当中没发现问题就够了。
代码审查员没有注意到这一微小的变更。
王二并没有在测试中检查这些即将受到毁灭性影响的日志(注意:公司当中根本没有质量保证人员这一职务)。
身兼测试人员与代码审查员两职于一身的王二没有注意到代码未发送记录请求的问题(注意:因为没有质量保证人员,所以代码审查员必然同时兼任测试人员)。
在 push 至生产环境后的监控环节当中,由于图表中的变化与其他长期记录相比非常微小,所以日志记录丢失问题没能被及时发现。
不存在对日志及图表的每日监控机制,因此没人第一时间注意到这个问题。
下一条部署至生产环境的 PR 同样没有正确遵循检查流程,且 / 或测试人员与第 6 条一样未能发现图表中的微小变化。
开发者技术前线 ,汇集技术前线快讯和关注行业趋势,大厂干货,是开发者经历和成长的优秀指南。