2026年6月13日，正在运行的Web服务突然无法访问。
起初，这看起来像一个简单的服务器重启问题。
但实际上，这是一次相当深入的网络故障，涉及Linux内核更新和Cilium eBPF数据路径。
有趣的是，这次故障并非由人工一步步分析解决。
本次故障响应是一个案例，Claude连接到远程服务器，检查状态，执行命令，分析日志，缩小原因，甚至执行了恢复操作。
人类所做的只是在关键时刻批准了危险操作。
服务名称、域名、IP、服务器名称、节点名称等敏感信息已用*屏蔽。
但分析原因所需的内核版本则原样标示。
三行摘要
服务器重启后，Web服务无法访问，但SSH连接和Kubernetes集群状态看起来正常。
Claude直接在远程服务器上执行命令，依次分析了Gateway、Cilium、NodePort、tcpdump和内核历史，最终判断问题是6.8.0-124-generic内核与Cilium 1.18.3组合的eBPF数据路径问题。
通过启动到旧内核6.8.0-111-generic，服务立即恢复，Claude甚至固定了GRUB默认启动内核以防止再次发生。
1. 故障的开始：服务器活着，但Web服务死了
最初的症状很简单。
网站无法打开。
curl https://***/
# curl: (28) 连接在15007毫秒后超时起初，看起来服务器本身已关闭。
bash scripts/test-connection.sh
# ssh: 连接到主机 ***.***.***.*** 端口 22: 操作超时检查Tailscale状态后确认服务器处于离线状态。
***.***.***.*** ***-server linux active; relay "***"; offline, last seen 2d ago到目前为止，一切都很简单。
服务器已关闭，看起来重新启动就能解决问题。
但即使重启服务器后，Web服务仍然无法访问。
SSH连接是可行的。
服务器资源也在正常范围内。
load average: 0.87
CPU idle: 87%
Memory free: 12GB
Disk usage: 12%
Failed systemd services: 0所有Kubernetes节点也处于Ready状态。
kubectl get nodes
# ***-control-plane Ready 204d
# ***-worker Ready 204d
# ***-worker2 Ready 204d从表面上看，服务器是正常的。
但用户看到的Web服务却已停止。
在这一点上，Claude并没有简单地判断“服务器正常”。
它开始根据服务流量实际通过的整个路径来查看故障。
2. 结构并非简单的Web服务器
本次环境并非仅仅运行一个Nginx的简单结构。
整体结构大致如下：
외부 사용자
↓
도메인 ***
↓
공인 IP ***.***.***.***
↓
물리 서버 ***
↓
Docker
↓
kind 기반 Kubernetes 클러스터
↓
Cilium Gateway API
↓
내부 웹 애플리케이션也就是说，可能发生故障的点很多。
可能的候选如下：
DNS 문제
공인 IP 문제
호스트 방화벽 문제
Docker 네트워크 문제
Kubernetes Service 문제
Cilium Gateway 문제
Envoy 문제
eBPF 데이터패스 문제
백엔드 애플리케이션 문제
Linux 커널 문제如果由人工直接查看，可能会相当纠结从哪个点开始检查。
但Claude开始按层次划分状态。
它依次检查了服务器本身是否正常、Kubernetes是否正常、Gateway是否正常、NodePort是否正常，以及实际数据包进入到哪里。
3. 本次故障响应中人类的角色
本次案例中重要的一点是，Claude不仅仅是提供了建议。
Claude直接连接到远程服务器，执行命令，解释输出结果，并接着执行下一个检查命令。
人类的角色是有限的。
사람:
- 위험한 작업 승인
- 재부팅 같은 주요 조치 승인
- 최종 결과 확인
Claude:
- 원격 서버 상태 점검
- Kubernetes 상태 점검
- Cilium Gateway 상태 분석
- IP Pool 문제 확인 및 복구
- NodePort 구간 테스트
- tcpdump 기반 패킷 분석
- Envoy 메트릭 확인
- 커널 변경 이력 추적
- 이전 커널 부팅 조치
- GRUB 기본 부팅 커널 고정
- 장애 기록 정리也就是说，本次响应更接近于“Claude像AIOps代理一样诊断并恢复故障的案例”，而不是“操作员通过询问Claude解决问题的案例”。
当然，并非所有操作都完全无人监督。
重启、GRUB更改等影响系统的操作都经过了人工批准。
但故障分析和恢复流程本身是由Claude主导的。
4. 第一个原因候选：Cilium Gateway地址未分配
Claude首先检查了Cilium Gateway的状态。
kubectl -n kube-system get gateway cilium结果如下：
NAME CLASS ADDRESS PROGRAMMED AGE
cilium cilium False 204d状态为PROGRAMMED=False。
这意味着Gateway尚未准备好接收外部流量。
检查详细条件后，原因是AddressNotAssigned。
Gateway waiting for address也就是说，Gateway未能获取要使用的外部IP。
Claude立即检查了Cilium LoadBalancer IP Pool的状态。
kubectl get ciliumloadbalancerippool
# 未找到资源IP Pool资源已消失。
在此环境中，Cilium Gateway需要使用特定的公网IP，因此如果没有IP Pool，Gateway将无法获取外部地址。
Claude找到了现有配置并重新应用了IP Pool。
apiVersion: "cilium.io/v2alpha1"
kind: CiliumLoadBalancerIPPool
metadata:
name: "cilium-pool"
spec:
blocks:
- cidr: "***.***.***.***/32"再次检查Gateway状态。
kubectl -n kube-system get gateway ciliumNAME CLASS ADDRESS PROGRAMMED AGE
cilium cilium ***.***.***.*** True 204dGateway恢复正常状态。
到此为止，问题似乎已经解决。
但Web服务仍然超时。
Claude并未在此停止分析。
它判断：“Gateway地址问题已解决，但如果用户流量仍然失败，则说明还有其他问题。”
5. 分段测试：哪里是正常的
接下来，Claude开始将网络路径分段。
它以NodePort 30080为基准，改变源地址进行测试。
| 测试段 | 结果 |
| 工作容器内部 → 自身 30080 | 正常 |
| 其他Kubernetes节点 → 工作节点 30080 | 正常 |
| 物理服务器主机 → 工作容器 30080 | 超时 |
| 外部用户 → 域名 HTTPS | 超时 |
这个结果非常重要。
Kubernetes内部通信正常。
节点间通信也正常。
后端应用程序也并非完全停止。
问题出在从主机外部进入容器的路径上。
Claude根据这个结果大大缩小了故障范围。
애플리케이션 자체 문제 가능성 낮음
Kubernetes 내부 네트워크 문제 가능성 낮음
노드 간 통신 문제 가능성 낮음
호스트 → 컨테이너 NodePort 처리 경로 문제 가능성 높음
Cilium/eBPF 데이터패스 문제 가능성 상승防火墙也进行了检查。
ufw status
# 非活动IP转发也已开启。
sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 1从主机到容器的ping也正常到达。
因此，很难将其视为简单的防火墙问题或完全的路由中断。
6. 决定性证据：SYN到达，但没有SYN-ACK
Claude接下来使用了tcpdump。
它在工作容器的网络命名空间内捕获了30080端口。
nsenter -t $WORKER_PID -n tcpdump -ni eth0 'tcp port 30080'然后，它尝试从主机连接到30080端口。
tcpdump结果如下：
01:18:53 IP ***.***.***.***.51640 > ***.***.***.***.30080: Flags [S]
01:18:54 IP ***.***.***.***.51640 > ***.***.***.***.30080: Flags [S]
01:18:55 IP ***.***.***.***.51640 > ***.***.***.***.30080: Flags [S]这里的核心只有一个。
SYN数据包到达了容器的eth0。
但是没有SYN-ACK响应。
TCP连接通常按以下顺序开始：
Client → Server : SYN
Server → Client : SYN-ACK
Client → Server : ACK这次，只有第一个SYN反复出现。
没有来自服务器的SYN-ACK响应。
也就是说，数据包并非完全没有到达。
数据包到达了目的地附近。
但是，在容器内部的网络处理路径中，没有正常生成响应。
Cilium利用eBPF在内核级别处理数据包。
使用Gateway API时，流量会经过Cilium的eBPF路径，然后转发到Envoy。
Claude也检查了Envoy指标。
listener-insecure downstream_cx_total = 0尝试连接时，计数器没有增加。
也就是说，数据包在容器的eth0上可见，但没有到达Envoy。
此时，原因候选已大大缩小。
애플리케이션 문제 아님
DNS 문제 아님
단순 방화벽 문제 아님
Kubernetes 내부 통신 문제 아님
Envoy까지 트래픽이 도달하지 않음
Cilium eBPF 데이터패스 또는 커널 네트워크 처리 경로 의심7. Cilium重启也未能解决问题
可能是Cilium的临时状态问题，因此Claude重启了Cilium相关组件。
kubectl -n kube-system rollout restart ds/cilium
kubectl -n kube-system rollout restart ds/cilium-envoy但症状依然如故。
Gateway状态为PROGRAMMED=True。
Kubernetes内部通信也正常。
但外部传入流量仍然超时。
此时，Claude提出了这个核心问题：
재부팅 전에는 정상인데,
재부팅 후 장애가 발생했다면,
재부팅으로 인해 실제로 바뀐 것은 무엇인가?这个问题是决定性的。
配置没有改变，应用程序也没有改变。
通过重启新应用的是内核。
8. 真正的原因候选：内核更新
检查了当前内核版本。
uname -r
# 6.8.0-124-generic检查了重启历史。
last reboot -F结果如下：
Sat Jun 13 00:03 boot 6.8.0-124-generic
Tue May 19 13:04 boot 6.8.0-111-generic之前使用的是6.8.0-111-generic内核。
但本次重启后，已升级到6.8.0-124-generic内核。
还检查了内核安装历史。
grep "install linux-image" /var/log/dpkg.log2026-06-04 install linux-image-6.8.0-124-generic总结如下：
6월 4일:
- linux-image-6.8.0-124-generic 자동 설치
6월 4일 이후:
- 서버는 계속 기존 커널 6.8.0-111-generic으로 운영
6월 13일:
- 서버 재부팅
- 새 커널 6.8.0-124-generic으로 부팅
- Cilium eBPF 경로에서 외부 트래픽 처리 이상 발생
- 웹서비스 타임아웃这类故障的原因和症状之间存在时间差。
内核已于6月4日安装。
但实际应用是在6月13日重启之后。
从运维人员的角度来看，可能会觉得“今天什么都没改，为什么会出故障？”
但实际原因是在几天前通过自动更新进入，并在重启时激活的。
Claude将这一点确定为故障原因候选。
9. 恢复：启动到旧内核
最快的恢复方法是回滚到故障前正常运行的内核。
Claude配置系统在下次启动时使用旧内核。
grub-reboot "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-111-generic"
reboot此操作涉及系统重启，因此在人工批准后进行。
启动后，检查了内核版本。
uname -r
# 6.8.0-111-generic等待Kubernetes节点和Cilium组件正常启动后，再次进行测试。
curl http://127.0.0.1:30080/收到了正常响应。
也检查了外部域名。
curl -L https://***/结果是HTTP 200。
HTTP 200服务已恢复。
这实际上是确认原因候选的时刻。
在6.8.0-124-generic上，外部流量未能通过Cilium eBPF路径正常处理，而回滚到6.8.0-111-generic后服务恢复正常。
10. 防止再次发生：固定GRUB默认内核
但不能就此结束。
grub-reboot是一次性设置。
下次重启时如果再次启动到6.8.0-124-generic，同样的故障可能会重复发生。
为了防止再次发生，Claude将GRUB默认启动内核固定为6.8.0-111-generic。
grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-111-generic"
update-grub也进行了配置检查。
grub-editenv listsaved_entry=Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-111-generic现在，即使在下次重启时，也会默认启动到6.8.0-111-generic内核。
但这只是临时措施。
固定到旧内核可能会错过最新内核的安全补丁。
因此，从长远来看，需要进行以下后续工作：
- Cilium 업그레이드 검토
- 6.8.0-124-generic 또는 이후 커널에서 재현 테스트
- Cilium eBPF 관련 설정 검토
- 커널 자동 업데이트 정책 재검토
- 재부팅 전후 외부 헬스체크 자동화
- 운영 노드 재부팅 전 사전 검증 절차 마련11. 从AIOps角度看本次故障
本次故障并非简单地“Claude告诉我答案”的案例。
Claude实际上在远程服务器上检查状态，执行命令，解释日志，并自主地继续进行下一个检查点。
从AIOps的角度来看，它更接近以下流程：
1. 장애 감지
2. 서버 접속 상태 확인
3. Kubernetes 상태 확인
4. Gateway 상태 확인
5. 누락된 IP Pool 복구
6. 사용자 증상 재확인
7. NodePort 구간별 테스트
8. tcpdump로 패킷 흐름 확인
9. Envoy 메트릭 확인
10. Cilium 재시작
11. 재부팅 전후 커널 변경 확인
12. 이전 커널로 복구
13. GRUB 기본값 고정
14. 장애 기록 작성在此过程中，人类并非直接设计和执行所有命令。
Claude进行判断并执行。
人类只批准了高风险操作。
这表明AIOps可以超越简单的监控或警报自动化水平。
12. Claude特别擅长的部分
12.1 快速缩小故障范围
起初，可能的根源太多了。
DNS
방화벽
Docker
Kubernetes
Cilium
Gateway
Envoy
eBPF
Linux 커널
애플리케이션但Claude通过分段测试缩小了候选范围。
Kubernetes 내부 정상
노드 간 통신 정상
호스트 → 컨테이너 NodePort 실패
SYN은 도착
SYN-ACK 없음
Envoy까지 미도달
재부팅 후 커널 변경最终，原因候选被缩小到内核+Cilium eBPF数据路径组合。
12.2 将tcpdump结果与故障原因关联起来
tcpdump中只出现SYN而没有SYN-ACK是重要的线索。
Claude并没有简单地以“看到数据包”来结束这个结果。
它进行了如下解释：
패킷은 목적지 네트워크 인터페이스까지 도착했다.
하지만 TCP 응답이 생성되지 않았다.
따라서 단순 라우팅 단절이나 방화벽 차단보다는 수신 처리 경로가 의심된다.
Cilium eBPF 또는 Envoy 전달 경로를 확인해야 한다.由于这种解释，避免了不必要的DNS、TLS和应用程序分析。
12.3 追踪重启应用的变更
本次故障的核心是重启。
重启前正常，重启后发生故障。
Claude根据这一差异检查了内核历史。
uname -r
last reboot -F
grep "install linux-image" /var/log/dpkg.log并发现了内核从6.8.0-111-generic变为6.8.0-124-generic的事实。
这是决定最终恢复方向的关键线索。
12.4 从恢复到防止再次发生
故障响应中常见的错误是认为“一旦恢复就结束了”。
但Claude在一次性启动到旧内核后并没有停止。
它固定了GRUB默认值，以防止在下次重启时再次发生同样的问题。
grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-111-generic"
update-grub它将恢复和防止再次发生分开处理。
13. AI直接管理服务器的优点
本次案例清楚地展示了基于AI的远程服务器管理的优点。
首先，故障响应速度加快。
Claude看到命令结果后立即继续进行下一个检查点。
大大减少了人工搜索和思考的时间。
其次，它能结构化复杂的层次。
即使在物理服务器、Docker、Kubernetes、Cilium、eBPF、Envoy交织的环境中，它也能按层次分离问题。
第三，它能解释命令结果。
不仅仅是列出命令，它还分析了结果的含义。
第四，恢复后文档化变得容易。
故障响应过程本身被整理得便于记录。
本文也是根据Claude执行的工作流程整理的。
第五，它可以发展为可重复的Runbook。
本次程序可以作为未来故障响应自动化的基础。
서버 상태 확인
Kubernetes 상태 확인
Gateway 상태 확인
NodePort 구간 테스트
tcpdump 패킷 확인
커널 변경 이력 확인
복구 커널 선택
재발 방지 설정14. 注意事项：赋予AI所有权限是危险的
本次案例的成功并不意味着可以无限制地赋予AI对生产服务器的所有权限，这是危险的。
特别是以下操作，必须经过批准程序：
reboot
grub-reboot
grub-set-default
update-grub
kubectl delete
kubectl rollout restart
iptables
tc
sysctl本次Claude主导了故障分析和恢复，但重启或GRUB更改等高风险操作仍由人工批准。
现实的运营模式如下：
일반 조회 명령:
- Claude가 자유롭게 수행
상태 변경 명령:
- Claude가 제안 및 실행 준비
- 사람 승인 후 실행
위험 명령:
- 사람 승인 필수
- 가능하면 롤백 방법 확인 후 실행AIOps的核心并非完全消除人类。
而是让AI执行大部分实际工作，但在危险决策时设置批准门槛。
15. 本次故障中吸取的教训
首先，即使服务器活着，服务也可能死亡。
即使SSH连接正常，CPU和内存正常，用户访问的Web服务也可能失败。
其次，AI可以相当深入地追踪复杂故障的原因。
在本次案例中，Claude不仅是简单的日志摘要，还关联分析了Gateway、Cilium、NodePort、tcpdump、Envoy和内核历史。
第三，重启后发生故障，必须检查内核变更。
uname -r
last reboot -F
grep "install linux-image" /var/log/dpkg.log第四，基于eBPF的网络对内核更新敏感。
Cilium积极使用内核的eBPF功能，因此内核更新可能会影响网络数据路径。
第五，赋予AI执行权限时，必须明确批准边界。
即使AI自动执行查询和分析，重启或更改启动设置等操作也应基于批准进行处理，以确保安全。
总结
本次故障始于一个简单的网站无法打开的问题。
但实际原因并非Web服务器或应用程序。
服务器重启应用了新内核6.8.0-124-generic，在此环境下，Cilium 1.18.3的eBPF数据路径被判断为未能正常处理外部流量。
Claude连接到远程服务器，检查状态，恢复Gateway问题，测试NodePort段，用tcpdump分析数据包，追踪内核历史，然后回滚到旧内核6.8.0-111-generic以恢复服务。
人类所做的只是批准了主要的危险操作。
本次案例展示了AIOps不仅限于警报摘要，还能实际执行服务器故障诊断和恢复过程的可能性。
当然，在生产服务器上赋予AI执行权限时必须谨慎。
但如果建立适当的批准体系和权限边界，AI可以扮演更接近实际运维代理的角色，而不仅仅是辅助工具。
本次故障是确认这种可能性的一天。
发表回复