title: 现场故障处理流程
author: Gamehu
tags:
  - LMT
categories:
  - 工作
date: 2024-3-29 21:12:00
---
<div class="tag-container">
  <span class="main-tag">离职系列</span>
  <span class="sub-tag">第三篇</span>
</div>
<div class="article-quote">
离职系列，想想这几年在公司的成长，在这做个记录。此篇主要谈谈LMT时，整理的现场故障处理流程。
</div>

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 %}