hexo-blog/source/_posts/故障排查流程.md

title: 现场故障处理流程 author: Gamehu tags:

• LMT categories:
• 工作 date: 2024-3-29 21:12:00 ---
  离职系列 第三篇
  离职系列，想想这几年在公司的成长，在这做个记录。此篇主要谈谈LMT时，整理的现场故障处理流程。

LMT团队对外最大的价值就是及时响应现场故障，有点Google SRE On-Call Engineer的感觉，但是现场问题往往较复杂或处理链条很长，所以必须要有一个相对标准且高效的流程，让各角色团队达成一致，从而能快速推进。

LMT主要职责

1. 快速响应告警，处理生产环境中的故障，对故障分级，同时保证SLA时效。

2. 故障排查

   1. 使用日志、指标和工具（如 fping、netdata、arthas 等）定位问题的根本原因。
   2. 执行临时修复措施（如回滚、重启服务）以恢复服务。
   3. 问题升级

3. 事后故障复盘

   1. 在故障解决后，组织处理人撰写事后分析报告，记录问题的根本原因、影响和改进措施。
   2. 预防，推动改进措施的实施，防止类似问题再次发生。

4. 协作与沟通

   1. 跟进每一个现场故障，与开发团队、产品团队和其他相关方协作，确保问题得到彻底解决。
   2. 在故障期间向利益相关者提供状态更新和预计故障关闭时间。

5. 知识库

   1. 和研发团队一起沉淀文档建立知识库，提升效率的同时培养人员。
      

现场故障处理流程

基于上面的职责，我梳理两个版本，0.5和1.0版本现场故障处理流程，主要在于先分清每个团队的职责，然后把现场故障能快速的流转起来，不管是否为疑难杂症，都做到万事有回响。

0.5版本

0.5版本用于建队初期，时间紧任务重，人员还未完全到位的情况。彼时LMT更多的是解决简单的问题以及跟进问题，大多问题的处理还是需要寻求原研发团队的支持故称接口人模式。 (故障组就是LMT) {% asset_img xc02.jpg %}

1.0版本

1.0版本是各核心模块人员配置到位，且各团队磨合期过了后，整理的，1.0版本流程重点主要在两方面：

1. LMT能独立解决大部分现场故障
2. LMT没法及时解决的需要有故障的升级路径，升级后LMT转为跟进故障处理情况并反馈一线。

{% asset_img xc.jpg %}

后续还有2.0版本，但是因为我已经不在LMT，且职责已经跟当初我建立时大相径庭所以我就不做梳理了。

最后

一定不要忘了还有 复盘与改进

1. 复盘

   • 使用标准的文档模板，由实际故障处理人记录问题的完整过程，总结根因
   • 复盘时共创改进措施，并每项都建立跟进人和时间

2. 预防措施

   • 举一反三，自查类似问题
   • 更新知识库
   • 加强相关人员培训

3. 填单 整个流程，为了各团队统一语言，所有过程记录我们要求都基于JIRA单，每个团队对应其流程节点，对JIRA单进行扭转和补充。 {% asset_img dz.png %}