devops-troubleshooter

专业DevOps故障排除专家,擅长快速事件响应、高级调试与现代可观测性技术。精通日志分析、分布式追踪、Kubernetes集群调试、性能优化及根因分析。专注生产环境故障处置、系统可靠性保障与预防性监控体系建设。适用于主动式调试、紧急事件响应及系统性故障排查场景。

作者

安装

热度:92

下载并解压到你的 skills 目录

复制命令,发送给 OpenClaw 自动安装:

下载并安装这个技能 https://openskills.cc/api/download?slug=sickn33-skills-devops-troubleshooter&locale=zh&source=copy

DevOps Troubleshooter - 生产故障智能排查助手

技能概述

DevOps Troubleshooter 是一款专业的生产事故响应和系统调试助手,精通日志分析、分布式追踪、Kubernetes 调试、性能优化和根因分析,帮助您快速定位并解决生产环境中的各类技术难题。

适用场景

1. 生产事故应急响应

当生产服务突然宕机、API 响应超时或用户投诉激增时,该技能可以引导您快速完成事故评估、数据收集、假设验证和应急修复,最大程度减少业务损失。支持从 CloudWatch、Azure Monitor、GCP Cloud Logging 等平台快速获取关键数据,并提供系统化的故障排查流程。

2. Kubernetes 和容器环境调试

针对 Kubernetes 集群中的常见问题,如 Pod 频繁重启 (OOMKilled)、CPU 节流、网络连通性异常、存储挂载失败等,提供专业的 kubectl 调试命令和诊断思路。支持 Docker、containerd、CRI-O 等容器运行时的问题定位,以及 Istio、Linkerd 等服务网格的流量和安全问题排查。

3. 微服务性能瓶颈分析

通过分布式追踪数据(Jaeger、Zipkin、AWS X-Ray、OpenTelemetry)定位微服务架构中的性能瓶颈,分析服务间调用链路、依赖关系和延迟分布。结合 APM 工具(DataDog、New Relic、Dynatrace)进行深度性能剖析,找出内存泄漏、CPU 热点、垃圾回收问题等根因。

核心功能

全栈可观测性分析

整合日志、指标、追踪三大支柱数据,从 ELK Stack、Loki/Grafana、Fluentd 等日志平台,Prometheus、Grafana、InfluxDB 等监控系统,以及各种 APM 和追踪工具中提取有价值的信息,进行多维度的关联分析,快速定位问题根源。

系统化故障排查方法论

遵循 SRE 最佳实践,采用"先收集事实再形成假设"的系统性方法,指导用户进行最小化影响的假设验证,并注重完整的文档记录和无责事后分析。不仅解决当前问题,还会建议添加监控告警以防止同类问题再次发生。

多云和混合云环境支持

覆盖 AWS、Azure、GCP 三大主流云平台以及混合云环境的调试场景,包括云服务特定问题、跨云通信故障、身份联邦问题、无服务架构调试等。同时支持 Terraform 状态问题、Ansible playbook 失败、Vault 集成等基础设施层面的故障排查。

常见问题

生产环境出现故障时,应该按照什么流程进行排查?

推荐的故障排查流程分为九个步骤:(1) 根据影响范围评估事故紧急程度;(2) 从日志、指标、追踪和系统状态收集全面数据;(3) 形成系统化假设并以最小影响方式验证;(4) 实施应急恢复措施,同时规划永久性解决方案;(5) 详细记录所有发现以便事后分析;(6) 添加监控告警防止问题复发;(7) 规划长期改进措施提升系统韧性;(8) 通过运维手册和文档共享知识;(9) 进行无责事后分析识别系统性改进机会。

Kubernetes Pod 频繁 OOMKilled 重启是什么原因?

OOMKilled 通常由以下原因引起:(1) 容器内存限制设置过低,无法满足应用实际需求;(2) 应用存在内存泄漏,持续增长直至超出限制;(3) JVM 堆内存配置不当,GC 无法有效回收;(4) 并发请求量突增导致内存峰值;(5) 缓存数据量超出预期。排查建议:使用 kubectl describe pod 查看事件,通过 kubectl logs 分析应用日志,必要时借助 kubectl exec 进入容器执行内存分析工具(如 top、ps、jmap),同时检查应用的内存配置和缓存策略。

如何使用分布式追踪定位微服务性能瓶颈?

分布式追踪通过追踪请求在微服务间的完整调用路径来定位性能问题。具体步骤:(1) 确保服务已启用 OpenTelemetry、Jaeger 或 Zipkin 等追踪组件;(2) 在追踪平台搜索高延迟或高错误率的 Trace;(3) 分析调用链路(Span)找出耗时最长的服务或操作;(4) 检查是否存在串行调用、重复调用或不必要的数据传输;(5) 结合应用日志和指标深入分析慢操作的根因;(6) 优化后通过追踪数据验证改进效果。常用技巧包括设置合理的采样率、添加关键业务标签、关注跨服务调用超时等。