Gdev Blog

Gdev 博客

0%

发表于：

背景 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

四层分析模型
第1层：症状层 (Symptom Layer)
   ├─ 用户感知：响应慢、超时、错误
   ├─ 业务指标：QPS下降、成功率降低
   └─ 核心问题：WHAT（发生了什么）
   
第2层：表现层 (Manifestation Layer)
   ├─ 技术指标：GC耗时、CPU使用率、线程数
   ├─ 资源状态：内存占用、连接数、文件描述符
   └─ 核心问题：WHERE（发生在哪个层面）
   
第3层：原因层 (Cause Layer)
   ├─ 直接原因：内存泄漏、锁竞争、外部依赖慢
   ├─ 触发条件：流量高峰、定时任务、数据累积
   └─ 核心问题：WHY（为什么发生）
   
第4层：根因层 (Root Cause Layer)
   ├─ 代码缺陷：资源未释放、算法效率低
   ├─ 设计缺陷：架构不合理、容量规划不足
   ├─ 流程缺陷：缺乏监控、发布不规范
   └─ 核心问题：HOW（如何从根本上避免）

1. 症状层应该观察哪些信息？

系统化的症状观察应覆盖以下五个维度，每个维度回答一个子问题：

发表于：

Java 线上问题处理操作指南

一、整体排查大纲

1. 总：故障定性与目标

  • 明确故障现象：CPU飙升 + 内存飙升 + 服务不可用（Java实例，Spring微服务）
  • 确定目标优先级：止血（恢复业务）→ 保留现场 → 根因定位 → 永久修复
  • 建立问题分类框架（参考文档中的“排查方向”）：
    • 应用程序本身（代码缺陷、JVM参数、资源使用）
    • 上下游系统（流量突增、依赖故障）
    • 机器/容器环境（资源争抢、网络、入侵）
    • 第三方调用（作为被调方流量突增，或作为调方依赖雪崩）

2. 分：按阶段逐步深入

阶段一：快速止血（恢复业务）

  • 决策：摘流 or 重启？保留现场 or 立即恢复？
  • 操作：摘除异常实例，确认业务恢复

阶段二：现场数据收集（证据链构建）

  • 需要什么信息？为什么？
  • 权衡：哪些数据必须取，哪些可能加重故障

阶段三：假设驱动分析（定位根因）

  • 基于文档的常见故障类型，建立假设清单
  • 用多维度数据交叉验证，逐步缩小范围

阶段四：解决与验证

  • 临时措施（重启、调参）与永久修复（代码、配置）
  • 验证问题解决，监控恢复

阶段五：复盘与优化

  • 避免同类问题，提升系统韧性

3. 总：总结核心原则

  • 证据链优于直觉
  • 止血优先于分析
  • 多维度交叉验证
  • 工具是手段，思路是核心

二、详细排查思路与思考过程

阶段一：快速止血（恢复业务）

思考：

发表于：

前言

在软件系统日益复杂的今天，性能问题的排查已成为工程师的核心能力之一。然而，很多人面对问题时，往往陷入“头痛医头、脚痛医脚”的困境——看到GC慢就调GC参数，看到CPU高就加机器，却很少思考问题的本质。

发表于：

Java 运维诊断实践指南：从零命令依赖到高效问题定位

一、背景与目标

1.1 为什么需要这篇指南

在生产环境中，Java 应用的问题诊断往往面临两难：

  • 公司内网环境：安全合规要求严格，无法直接执行 jstack、jcmd 等诊断命令
  • 个人项目环境：可以自由使用命令，但缺乏系统化的诊断方法论

本指南旨在帮助中高级 Java 开发工程师建立一套不依赖命令的运维诊断体系，同时保留个人项目的灵活诊断能力。