devops-troubleshooter
快速调试生产环境故障
通过AI引导的调试、日志分析和系统化故障排查方法，快速诊断并解决生产环境故障。
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "devops-troubleshooter". My Kubernetes pods are getting OOMKilled frequently. Memory limits are set to 512Mi but the application uses Java.
Résultat attendu:
这是一个常见的Java on Kubernetes问题。JVM堆内存只是内存占用的一部分。以下是我的评估：
**立即执行的操作：**
1. 检查实际内存使用：`kubectl top pods`
2. 查看JVM标志：确保-Xmx设置适当（通常为容器限制的50-75%）
3. 考虑使用Kubernetes downward API将JVM内存设置为匹配容器限制
**根因：** Java进程使用堆+元空间+线程栈+原生内存。512Mi的限制与默认JVM设置会导致OOMKills。
**推荐修复：**
```yaml
resources:
limits:
memory: "1Gi"
env:
- name: JAVA_OPTS
value: "-XX:MaxRAMPercentage=75.0 -XX:+UseG1GC"
```
**预防：** 添加80%阈值的内存使用率告警。
Utilisation de "devops-troubleshooter". We are seeing intermittent 504 errors from our load balancer. The backend services appear healthy.
Résultat attendu:
这可能是由几个因素造成的。让我引导您完成故障排查步骤：
**立即调查：**
1. 检查后端响应时间：`curl -w '%{time_total}' http://backend/health`
2. 查看负载均衡器访问日志中的时间模式
3. 检查连接队列是否积压
**常见原因：**
- 后端响应时间过长（检查是否有慢数据库查询）
- 空闲超时设置过于激进
- 负载均衡器与后端之间的keep-alive配置错误
- TLS握手延迟
- 健康检查干扰流量
**后续步骤：**
1. 在负载均衡器上启用详细日志记录
2. 添加后端延迟百分位的自定义指标
3. 检查问题是否与特定请求模式或时间相关
您想让我帮助调查这些具体领域中的哪一个？
Audit de sécurité
SûrPrompt-only skill with no executable code. Static analysis scanned 0 files (0 lines) and detected 0 security issues. This is a pure text-based skill that provides debugging guidance through structured prompts. No risk factors present.
Score de qualité
Ce que vous pouvez construire
生产环境事件响应
获取从初始评估到根因分析的即时诊断和解决生产环境中断的指导。
Kubernetes集群调试
排查Kubernetes环境中的Pod故障、网络问题、服务网格问题和资源限制。
性能优化
通过日志分析、分布式追踪关联和系统性能分析建议来识别性能瓶颈。
Essayez ces prompts
My production service is experiencing [describe issue: high latency/errors/outage]. I have [describe available data: logs from X, metrics from Y]. Help me diagnose the root cause.
I have a Kubernetes pod in [CrashLoopBackOff/Running state] with the following events: [paste kubectl describe output]. The logs show: [paste relevant logs]. What should I investigate?
I'm seeing this error pattern in my [ELK/Loki/cloud logs]: [paste error messages and timestamps]. The error started [when]. Help me correlate these logs and identify the root cause.
We had an incident where [describe incident]. Timeline: [paste timeline]. The following systems were affected: [list]. What systemic issues contributed to this failure and how can we prevent recurrence?
Bonnes pratiques
- 在形成假设之前，始终收集日志、指标和系统状态，以避免误诊
- 从最简单的解释开始，只有在排除后才升级到复杂原因
- 记录所有调查步骤和发现，用于事后分析和知识共享
Éviter
- 在没有先在受控环境中重现问题的情况下对生产系统进行更改
- 忽略似乎与主要问题无关的错误信息和症状
- 关注症状而非根因，导致日后失败的临时修复