add some contents on incident-runbook

Author: FIghtingforme

content/incident-runbook/_index.md

@@ -7,47 +7,76 @@ type: "docs"
 
 
 
-###
+## OSI排查通用版
+### 确认故障半径：
 
-- 突然遇到了问题：不能git push了，开始排错。。
+- **动作：** 询问报障人（终端用户）。
+    
+- **逻辑：** 是你一个人打不开，还是你们整个部门打不开？（区分是“单点终端故障”还是“核心交换机/出口路由故障”）。
+    
+    - 是只有 ERP 打不开，还是连百度也打不开？（区分是“内网业务宕机”还是“外网链路中断”）。
 
-- 原来是忘了提交了。。。。
 
-- git因为网速问题，添加代理:
+###  Step 1：L1-L2 物理层与链路层排查（底座校验）
 
-```
+_确认范围后，先从最底层的**网卡和局域网**开始。_
 
-标准化处理流程：配置 Git 本地代理
-第一步：确认你的本地代理端口
-打开你正在使用的代理软件，查看它的本地 HTTP 代理端口或局域网代理端口。
+- **命令行执行：** `ipconfig /all` (Windows) 或 `ifconfig` / `ip a` (Linux)
+    
+- **排查逻辑：** 
+1. 检查网卡是否获取到了正确的 IP 地址。如果是 `169.254.x.x`，说明 DHCP 服务挂了或者网线物理断开（L1）。
+2. **命令行执行：** `arp -a`。检查 ARP 表。如果获取不到网关的 MAC 地址，说明根本没连上核心交换机，存在 VLAN 划分错误或 IP 冲突（L2）。
 
-如果你使用的是类似 Clash/FlClash 的工具，默认端口通常是 7890。
 
-如果你使用的是基于 VLESS/Xray 的客户端（如 v2rayN），默认端口通常是 10808 或 10809。
+### Step 2：L3 网络层排查（路由连通性测试）
 
-第二步：在 Git Bash (MINGW64) 中设置代理
-假设你的代理软件运行在本地 127.0.0.1，端口是 7890。请在当前的 Git Bash 终端中执行以下命令（请根据你的实际端口修改数字）：
+_底座没问题，开始测试数据包能否跨网段路由。_
 
-Bash
-# 配置 HTTP 和 HTTPS 代理
-git config --global http.proxy http://127.0.0.1:7890
-git config --global https.proxy http://127.0.0.1:7890
-(注意：即使你的目标地址是 https 的 GitHub，代理协议依然写 http:// 即可，这是本地代理客户端的标准接收协议。)
+- **第一步：Ping 网关。** `ping <网关IP>`。不通则找本地网络组，查楼层交换机。
+    
+- **第二步：Ping 目标服务器。** `ping erp.company.com` 或 `ping <服务器IP>`。
+    
+- **第三步：路由追踪。** 如果 Ping 目标不通（Request Timeout），立刻执行 `tracert -d <目标IP>`（Linux 下用 `traceroute -n`）。
+    
+    - **目的：** 精准抓取数据包死在了哪一个路由节点。是死在公司的核心防火墙，还是死在跨机房的专线上，一目了然。
 
-第三步：验证配置并重新执行拉取
-执行以下命令确认代理已生效：
 
-Bash
-git config --global --get http.proxy
-确认无误后，重新执行添加子模块的命令：
+### Step 3：L4 传输层排查（安全策略与端口探测）
 
-Bash
-git submodule add https://github.com/imfing/hextra.git themes/hextra
-这次流量将通过你的代理隧道走，通常 3 秒内即可 Clone 完毕。
+_能 Ping 通服务器，不代表服务能用！Ping（ICMP）是三层协议，而业务走的是四层（TCP/UDP）。_
 
-```
+- **命令行执行：** `telnet <服务器IP> <端口>` （例如 `telnet 192.168.1.10 8080`），或者用 PowerShell的 `Test-NetConnection -ComputerName <IP> -Port <端口>`。
+    
+- **排查逻辑：** 如果三层通，但四层 Telnet 失败，绝对是以下两种情况之一：
+    
+    1. 服务器本机的防火墙（iptables/firewalld）或云上的安全组**没放行该端口**。
+        
+    2. ERP 系统的后端进程死掉了（比如 Tomcat 或 Node.js 崩溃），导致**端口根本没监听**。
+
+
+### Step 4：L7 应用层排查（域名解析与服务状态）
+
+_如果四层端口通，但浏览器依然报错，进入应用层逻辑排查。_
+
+- **第一步：DNS 校验。** 执行 `nslookup erp.company.com`。看解析出来的 IP 是不是真实的服务器 IP，排除内网 DNS 劫持或配置错误。
+    
+- **第二步：HTTP 报文探测。** 执行 `curl -I http://erp.company.com`。
+    
+    - 报 `502 Bad Gateway`：Nginx 正常，但后端的 Java/Python 业务挂了。
+        
+    - 报 `404 Not Found`：网络全通，是开发把路径写错了或者发版失败。
+        
+- **第三步：登录服务器（提权操作）。** SSH 连上服务器，执行 `tail -f /var/log/nginx/error.log` 或者 ERP 的业务日志，直接锁定具体报错代码。
+    
 
+### Step 5：故障闭环（SRE 核心精神）
 
+- **动作：** 恢复服务后，更新知识库（SOP/Wiki），并配置监控告警（比如在 Prometheus 里加一个探针）。坚决杜绝同样的故障发生第二次。
+
+
+
+
+---
 ---