findscripter 何时使用
适用：线上服务宕机/抖动、性能劣化、告警触发，需要在分布式系统中快速止血、定位根因并防复发。典型场景——Pod 频繁重启或 OOMKilled、间歇性 504/502 网关超时、微服务链路性能瓶颈、DNS/服务发现失败、数据库死锁或连接池耗尽、CI/CD 流水线失败与 GitOps 回滚、证书/认证授权故障。
不该用（负边界）：
- 纯业务代码逻辑 bug、单元测试或本地单机开发调试——属应用开发域，不在此。
- 非运维域问题（如纯前端样式、数据建模需求）。
- 缺少日志/指标/链路访问权限或环境信息时——先停下索要输入，不要凭空臆测。
步骤
遵循「先全面取证，再形成并验证假设」的纪律，优先快速恢复同时兼顾系统完整与安全：
- 评估影响：按影响面与范围确定紧急程度（用户面/数据面/范围）。
- 收集数据：汇总日志、指标、链路追踪与系统状态（current state），做多服务日志关联。
- 形成并逐一验证假设：以最小系统扰动逐条排除，考虑级联/雪崩失败场景。
- 立即止血：先恢复服务（扩容、回滚、重启、摘流），同时规划永久修复。
- 充分记录：为事后复盘留存证据与时间线。
- 加监控告警：补齐缺失的监控/告警，使同类问题可主动发现。
- 规划长期改进：架构层防复发。
- 沉淀知识：runbook、文档、团队培训。
- 无指责复盘（blameless postmortem）：识别系统性改进项。
指令
- 先澄清目标、约束与必需输入，再动手。
- 先取证（日志/指标/链路）再形成假设，禁止跳步。
- 修复以最小扰动落地，兼顾长期稳定性。
- 修复后补充主动监控与告警以防复发。
- 输出不能替代环境内的验证、测试与专家评审；缺权限/安全边界/成功判据时停下询问。
常用排障命令与切入点：
- Kubernetes：
kubectl get/describe pod、kubectl logs --previous、kubectl top pod、事件与就绪/存活探针；排查 Init/Sidecar 容器、资源限制、CNI 网络、PV 存储。 - 网络/DNS：
dig、nslookup查解析与传播；tcpdump、Wireshark、eBPF 工具做抓包与延迟分析；核对网络策略与安全组、负载均衡（ALB/NLB）。 - 可观测：Prometheus/Grafana 看指标，ELK/Loki 查日志，Jaeger/Zipkin/OpenTelemetry 看分布式链路并做跨服务关联。
- 性能/资源：CPU/内存/磁盘 I/O/网络利用率分析；定位内存泄漏、CPU 热点、GC、OOMKilled、CPU 限流。
- 数据库：查询执行计划与索引、连接池耗尽、主从复制延迟、死锁。
- CI/CD：构建失败/依赖/测试，ArgoCD/Flux GitOps 问题与回滚流程。
- 云平台：AWS CloudWatch、Azure Monitor、GCP Cloud Logging 各自的日志与 CLI。
示例
- 排查 K8s Pod 高内存导致频繁 OOMKilled 与重启的根因。
- 分析分布式链路追踪数据，定位微服务架构中的性能瓶颈。
- 排查生产负载均衡间歇性 504 网关超时。
- 调查 CI/CD 流水线失败并实现自动化排障/回滚。
- 数据库死锁导致应用超时的根因分析。
- K8s 集群中影响服务发现的 DNS 解析问题排查。
注意事项
- 先取证后假设：未掌握日志/指标/链路前不下结论，避免误导性操作。
- 最小扰动验证假设，警惕级联失败——一个修复动作可能引发新的雪崩。
- 止血与根因分开推进：先恢复服务，再做永久修复，二者都要记录。
- 复盘对事不对人（blameless），目标是系统性改进而非追责。
- 任何修复都需在目标环境内实测验证，本技能产出不替代环境特定的测试。
互见
- 性能剖析与压测类技能（应用 profiling、容量规划）。
- Kubernetes 部署与 GitOps 运维类技能。
- 监控告警体系搭建（Prometheus/OpenTelemetry）类技能。
采编自 sickn33/antigravity-awesome-skills（MIT 许可）。