文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
跟进步骤
跟进步骤
对于跟进线上反馈问题的策略,可以分四个步骤,依次是①预估影响范围,②测试定位问题,③开发修复,④问题复盘,下面具体来说一下这4个步骤:
步骤① 预估影响范围
- 作为跟进问题的首要步骤,预估的影响范围指导了后续的行动方针。影响范围大必修,功能高优必修,涉及金钱必修。
- 首先要清楚发生的问题或故障属于哪种类型。
- 梳理出功能的重要性或优先级,对应核心功能的故障,就必须短时间内能制定出解决方案来降低影响范围,同时必须保证敏感功能敏感信息的安全稳定。
- 判断影响范围时一般如果是面向用户的功能,尽可能地避免问题功能和用户接触,如果是作为上下游的功能可以尽快通知对应业务方做好规避并采取措施。
迅速
是这个环节的关键字,所以就得建立起良好的告警反馈体系,通过线上监控早一步先于用户发现问题。
步骤② 测试定位问题
- 功能上的问题都可以在测试环境重现,尽可能的模拟线上的情况,包括数据和配置,这样重现问题的概率会提高而容易定位。测试本身不影响用户数据时,也可以直接在线上操作。
- 在核实上报的线上问题时,不管是功能问题,性能问题,还是环境问题等,日志是作为定位问题重要依据,所以一般都会要求业务的日志要精,错误要告警到位,只有精准的业务日志,才会给业务系统的稳定运行提供有效的依据,通过排查日志的信息定位问题的原因也是最有效的手段。
- 资源性能上的问题可以通过监控告警的日志,以及一些常规的命令来获取信息对症下药。
- 定位到问题之后立即与开发沟通,确定能修复的时间并周知上报方。
步骤③ 开发修复
经过上一步,问题可以被分为可快速定位问题以及无法快速定位问题两种情况
能快速定位问题的,因为业务功能导致的问题,一般都会采取hotfix的方式,但对于像客户端尤其是app这种无法马上回收或者是发布版本的,可以通过后台配功能配置的方式将功能降级或关闭,除此之外有部分问题可以通过配置调整参数来规避的,也可以采取这方式将线上问题的影响范围减小
当不能快速地定位问题时,需要求责任人当机立断给出指示。
1)可以通过回滚版本的方式来规避问题, 这也是最有效且首选的方式,回滚版本可以切断问题发生的导火线,同时最原先稳定的业务最有保证的策略。
2)负载过高导致的问题,不是回滚版本就能处理的,这时候一般就是采用重启大法,重启之后继续观察资源的想像,一般都是因为新版本的一些问题导致资源死锁之类的,所以必要时回滚版本也会和重启大法配合使用。
3)硬件方面的问题,一般是扩容解决,先把资源加上去,之后再考虑优化性能的方案。
4)对于有进行功能配置的,还是可以先将功能关闭和降级,之后在测试环境继续定位,解决后进行发布即可。
将问题影响范围降到最低
是这个环节的关键字。
步骤④ 问题复盘
Issue Learning是测试人员的重要环节,有点像“温故而知新”,不想问题再次发生,以及相关同类问题的出现,因此通过复盘的手段总结经验,提升规避问题的意识以及线上问题的响应能力。
- 问题的原因追溯。 是人为导致的还是系统BUG,是遗漏BUG还是新引入的BUG,以及是否由于外部系统的数据流或者是组件等不兼容的问题导致。
- 处理问题的流程合理性考量。解决问题时会涉及到的业务影响需要及时Call Out,与业务放接洽好可以承受的结果,比如愿意用延期换稳定。
- 同类、共性的问题进行归类,方便查阅前车之鉴。
- 避免类似问题的发生。 线上对核心业务应有自动化测试遍历的用例,监控报警机制需要完善,报警信息需要完善,避免报警不及时并需要提升大家对报警的关注度。同时在系统架构上是否可以进行相关优化。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论