问题排查复盘

5月份中旬一天晚上,业务需求上线后反馈,该业务对应的搜索功能有问题,晚上10点多开始排查,到凌晨2点,最后大致定位了问题,并行修改后恢复,虽然问题不是很大,但是当时上线的业务对业绩比较重要,当时公司很多大佬都在等问题的解决,亚历山大,最后定位到的问题很简单,就是下游某个服务超时,但是整体过程离奇曲折,特此记录,总结经验。
首先最大的问题,下游服务那么多,具体是哪个服务出问题导致了最后的问题,这个当下无法通过工具定位,是最大的问题,公司里虽然工具都有,链路工具tracing skywalking,日志工具elk,链路工具基本平时不使用,因为不好用,有些线程都没有串起来,所以当第一步无法定位大致的问题服务时,就靠大胆猜测,结果还猜错了,在错误的问题上折腾了一个小时。
第二,排查到出问题的下游链路时,由于接口没有对超时打日志,所以无法很明确的定位问题,只能临时继续加日志上线,另外,线上日志全部打开后,日志量太多导致有的被遗弃,没有收集起来,还得去机器上看日志。
最终虽然解决了问题,但是能看出来,这是一个工程问题,下次还是无法避免,所以我们要建设一些工具,另外,还需要体系化的建设排查问题的方法论。
1.工具:
tracing:要善于使用skywalking,在错误请求上把链路id打出来,根据链路id先定位大致的错误的服务。
logging:现在打日志是纵向的,开一个应用的日志,就把这个应用模块所有访问的日志都打出来了,只需要打印错误链路的日志,而且需要横向的在各服务上把错误链路的日志都打出来。
2.方法论:
首先做程序员代码就是最大的确定性,不能靠猜哪里有问题,再去看,猜其实是先有的手段无法满足定位,所以只能靠猜,这是下下策。最好的方式是通过metrics—>tracing—>logging的顺序分析问题,比直接去查日志更高效,首先得加上监控告警,通过告警发现问题,第二,通过tracing发现该问题发生在微服务链路的哪个环节,最后,在根据日志找到最根本的问题。

### 关于项目复盘案例分析 项目复盘是软件工程中不可或缺的一部分,它不仅帮助团队总结经验教训,还能提升未来项目的成功率。根据已有资料[^1],项目复盘可以分为三种形式:日常事件复盘、阶段性复盘以及全面复盘。 #### 日常事件复盘 当项目过程中出现特殊情况时,例如线上故障或其他突发事件,应及时进行复盘。这种即时性的复盘能够有效防止类似问题再次发生。通过记录和分析这些异常情况的原因及其解决方案,团队可以在后续工作中采取更有效的预防措施。 #### 阶段性复盘 在敏捷开发模式下,每次Sprint结束后都会举行回顾会议,这实际上就是一种阶段性复盘的形式[^3]。此类复盘有助于评估当前迭代的目标完成度,并讨论如何优化下一阶段的工作流程。借助这种方法论的支持,团队成员得以不断改进协作方式和技术实现路径。 #### 全面复盘 整个项目完成后,则需开展更为深入细致的整体性复盘活动。此时不仅要审视技术层面的成功与否,还需考量诸如资源分配合理性、沟通机制有效性等方面的内容[^1]。如此一来,便能全方位了解哪些因素促成了最终成果或者阻碍了预期目标达成。 ### 使用鱼骨图辅助复盘 为了更好地挖掘潜在问题根源所在,在实际操作过程中推荐采用鱼骨图这样的可视化工具来进行深层次剖析[^2]。通过对不同维度(如人员、设备、材料等)可能存在的隐患逐一排查,进而找到最核心的影响要素,并据此制定针对性改善策略。 ### 敏捷环境下的复盘特点 考虑到现代软件工程项目大多遵循敏捷原则展开运作,因此其特有的短周期交付特性决定了复盘频率相对较高且灵活多样[^3]。具体而言,除了常规意义上的里程碑节点外,任何有意义的小规模产出均值得被纳入考虑范围之内予以检视评价。 ```python def project_retrospective(project_phases, incidents): """ Perform a retrospective analysis on the given phases and any notable incidents. Args: project_phases (list): List of completed project phases. incidents (list): Notable events or issues that occurred during the project lifecycle. Returns: dict: Summary report containing insights from each phase and incident review. """ summary_report = {} for phase in project_phases: # Analyze each phase using appropriate metrics and feedback collection methods phase_analysis = analyze_phase(phase) summary_report[f'Phase {phase}'] = phase_analysis for incident in incidents: # Conduct root cause analysis for significant incidents RCA_results = perform_RCA(incident) summary_report[f'Incident {incident}'] = RCA_results return summary_report def analyze_phase(phase_details): pass # Placeholder function to simulate detailed phase evaluation logic def perform_RCA(event_data): pass # Placeholder function representing Root Cause Analysis process ``` 上述代码片段展示了如何基于给定的项目阶段列表与关键事件集合生成一份详尽的复盘报告框架。其中包含了针对各阶段表现状况的具体解析逻辑以及针对特定事故背后深层诱因探寻的过程模拟函数定义。 ### 结语 综上所述,无论是传统瀑布式还是新兴敏捷型软件开发生命周期里,适时适当地引入科学合理的复盘机制都是极为必要的举措之一。而像鱼骨图这样直观高效的图表类辅助手段则进一步增强了我们发现问题本质的能力,从而助力整体工作效率得到质的飞跃。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值