撰写故障排除指南

故障排除步骤：在线客服页面无法发送消息

一、问题定义与适用范围
- 现象示例：
  - 点击“发送”无反应或按钮一直处于禁用/灰态。
  - 显示“发送失败”、“网络异常”或出现错误码（如 401/403/413/429/5xx、WebSocket 1006）。
  - 消息长时间停留在“发送中”状态。
  - 仅部分用户/浏览器/网络环境下可复现。
- 适用范围：Web 在线客服页面（含嵌入式插件、iframe、小程序内 WebView）。涉及 HTTP(S)/WebSocket 发送消息、表单校验、认证会话、CORS/CSRF、CDN/网关/WAF 等。

二、终端用户快速自助排查（建议优先执行）
1) 刷新与重试
- 刷新页面，重新登录账号，重新进入会话。
- 复制当前对话内容以免丢失，再尝试发送。

2) 网络连通性
- 切换稳定网络（有线/Wi‑Fi/蜂窝网络），关闭/更换 VPN 或代理。
- 访问其他网站确认网络正常。

3) 浏览器与环境
- 使用最新稳定版浏览器；尝试隐身/无痕模式或更换浏览器。
- 关闭广告拦截/脚本拦截/隐私增强插件后重试。
- 若客服组件在第三方域名的 iframe 中：临时允许第三方 Cookie 或在无痕模式下测试。

4) 会话与权限
- 确认已登录且会话未过期；退出登录后重新登录。
- 若组织策略限制对外聊天，联系管理员核对权限。

5) 输入与附件限制
- 检查必填项是否填写、消息是否超出字数或包含被过滤的敏感词。
- 附件大小、类型、数量是否超限；逐项排除（只发纯文本测试）。

6) 本地缓存
- 清除站点缓存与 Cookie，或用“强制刷新”（不建议清除全局数据）。
- 若是移动端 App 内置浏览器，关闭再重开 App。

7) 仍未恢复
- 记录时间、浏览器版本、网络环境、错误提示/截图，提交支持请求。

三、一线客服/运营初步核查
- 坐席是否在线、队列是否已满或暂停接入。
- 租户/项目是否到期、被冻结或超配额。
- 后台是否开启关键词过滤、敏感词拦截、限流策略；放宽后重试。
- 最新发布/配置变更后是否开始出现问题，回滚验证。

四、前端技术排查（开发/测试）
1) 复现与最小化场景
- 记录可复现最短路径；尝试最小输入（纯文本）、禁用非核心脚本重试。

2) 浏览器开发者工具
- Console：
  - 关注 JavaScript 异常、CSP 违规、Mixed Content、被扩展拦截（如 net::ERR_BLOCKED_BY_CLIENT）。
- Network：
  - HTTP 发送（REST/POST）：
    - 检查状态码与响应体：200/201（成功）、401/403（未认证/无权限）、412（CSRF 失败）、413/431（负载或头过大）、415/422（格式/校验失败）、429（限流）、5xx（服务端错误）。
    - 核对请求头和载荷：Content-Type、Authorization/Token、X-CSRF-Token、一致的 Referer/Origin、消息体大小与格式。
    - CORS：是否返回 Access-Control-Allow-Origin（匹配来源或“*”）、Allow-Credentials 配置与实际是否携带凭据。
  - WebSocket（若使用）：
    - 握手是否 101 Switching Protocols，URL 使用 wss，证书有效。
    - 断开码/原因：1006（非正常关闭，常见于网络/代理/WAF 阻断）、1008（策略拒绝）、1011（服务端异常）。
    - 是否有 ping/pong 心跳，是否被中间设备超时断开。
  - 反复“发送中”：
    - 检查是否请求未发出（按钮仍 disabled）、被队列阻塞、或响应被 Service Worker/缓存拦截。
- Application：
  - Cookie/SameSite：
    - 若在第三方 iframe 内，需 SameSite=None; Secure，否则第三方 Cookie 被阻止导致会话/CSRF 失败。
  - LocalStorage/IndexedDB：
    - 报错 QuotaExceededError 表示配额超限；清理后重试。
  - Service Worker：
    - 检查是否缓存了旧脚本或错误拦截 POST；尝试 skipWaiting/更新或临时注销后重试。

3) 表单与交互逻辑
- 按钮禁用条件是否被错误维持（async 验证未恢复、节流/防抖过度）。
- 客户端校验规则与服务端不一致导致前端拦截。
- 逐步关闭输入增强（富文本、表情、粘贴图片）定位触发点。

4) 嵌入与安全策略
- iframe sandbox 是否缺少 allow-forms/allow-scripts/allow-same-origin。
- Content-Security-Policy 是否允许对应 connect-src/script-src（含 WebSocket 端点）。
- postMessage 通道的 targetOrigin 与事件监听匹配是否正确。

五、后端/网关/基础设施排查（研发/运维）
1) 接口与依赖健康
- 检查消息发送 API/WebSocket 网关健康探针、错误率、延迟、限流命中。
- 下游依赖（消息队列、通知/审核服务、数据库）连通与资源使用情况。

2) 身份与会话
- 认证失败比例、Token/会话过期策略、时钟偏差导致失效。
- CSRF 校验是否放通正确来源；跨域场景的 Referer/Origin 白名单是否完整。

3) 网关与代理
- 反向代理/负载均衡对 WebSocket 的 Upgrade/Connection 头透传配置。
- 超时时间（空闲/首包/总时长）是否过短；是否对 POST 误缓存或压缩。
- 粘性会话（会话亲和）是否影响多步交互；CDN 对动态路径是否已绕过缓存。

4) 安全与合规
- WAF/安全策略是否拦截（关键字、请求率、User-Agent、国家/地区）。
- TLS/证书有效性；域名解析/DNS 健康。

5) 排障验证
- 使用 curl 直接调用发送接口（替换为真实地址与凭据），核对状态码/响应：
  - 示例：curl -i -X POST https://api.example.com/messages -H "Authorization: Bearer <token>" -H "Content-Type: application/json" -d '{"text":"test"}'
- 使用 wscat/等工具测试 WebSocket 握手与消息往返，排除前端因素。

六、常见错误与对应处理
- 401/403：未登录/权限不足。校验认证流程、Token 传递、跨域凭据。
- 412：CSRF 校验失败。检查 CSRF Token 注入与跨域策略。
- 413/431：消息体或头过大。降低消息/附件体积，优化 Cookie/头大小。
- 415/422：格式/校验错误。统一 Content-Type 与字段校验规则。
- 429：限流。调整限流策略、增加退避重试与用户提示。
- 5xx：服务端错误。回滚变更、扩容、查看异常日志与链路追踪。
- WebSocket 1006/1011：网络/代理断连或服务端异常。放宽超时与帧大小、检查 WAF/代理配置。
- 浏览器错误如 net::ERR_BLOCKED_BY_CLIENT（被扩展拦截）、ERR_CERT_*（证书问题）、NAME_NOT_RESOLVED（DNS）。

七、信息采集清单（用于提交支持/定位）
- 发生时间（含时区）、账号/租户、页面 URL。
- 浏览器与版本、操作系统、是否在 iframe 或 App WebView。
- 网络环境（公司内网/家庭网络/VPN/代理）、是否命中组织策略。
- 可复现步骤、是否对所有用户/仅部分用户发生。
- 错误提示/截图、浏览器 Console 日志、Network 失败请求详情与 HAR 文件。
- 相关请求的 Correlation/Request-ID（如有）。

八、临时替代方案与降级
- 提供备用联系方式（电话、邮件、工单）或离线留言。
- 前端启用降级路径：发送失败本地排队与重试、切换 HTTP 轮询替代 WebSocket、提示用户复制消息避免丢失。
- 后端放宽限流/过滤策略，延长会话与网关超时以缓解。

九、预防与改进建议
- 统一前后端校验与错误码规范，前端对常见错误提供明确可操作提示。
- 对跨域/iframe 场景采用 Token 认证或 Storage Access 兼容方案，避免第三方 Cookie 依赖。
- 加强可观测性：为发送链路埋点、日志关联 ID、告警阈值与仪表盘。
- 发布前在多浏览器、多网络、隐身模式及无插件环境做回归测试。

按照以上步骤从用户侧到系统侧逐层定位，可覆盖大多数“在线客服页面无法发送消息”的典型原因，并快速收敛问题范围。

故障排除步骤：新版本上线后移动端推送通知不触达

目标
定位并解决新版本发布后，移动端（iOS/Android）推送通知不达的问题，覆盖客户端配置、服务端网关、发送策略与数据链路。

一、界定问题与影响范围
- 影响平台：iOS、Android，或双平台。
- 受影响版本与渠道：App Store/TestFlight、Google Play/企业分发、灰度范围。
- 受影响人群：全部用户、特定地区/机型/网络、仅新装或仅升级用户。
- 推送类型：通知类（用户可见）、静默类（content-available/数据消息）、运营/系统消息。
- 现象细分：完全不达、部分不达、延迟显著、仅前台/后台不达、仅特定通知类型不达。

二、快速健康检查
- 平台状态：
  - Apple System Status（APNs）是否异常。
  - Google/Firebase Status（FCM）是否异常。
- 内部告警与发送量曲线：是否在新版本上线时间点发生显著变化。
- 网关返回错误码：抽样最近失败请求，查看APNs/FCM的响应原因。

三、客户端侧检查（App）
A. 通用（两端）
- 用户授权与系统设置：
  - 是否已请求并获得推送授权（用户可能在升级后撤销授权）。
  - 系统通知设置是否被关闭或被设为“摘要/免打扰/专注模式”。
- 设备令牌（Token）生命周期：
  - 新版本启动后是否重新获取到有效的推送令牌，并成功上报到业务服务端。
  - 令牌更新回调是否被正确处理（升级后令牌可能变更，旧令牌不可用）。
  - 日志中记录令牌值、上报结果与服务端确认状态。
- 发送与显示路径区分：
  - 数据消息（data-only）需要App前台或自建展示逻辑；若此前依赖系统自动弹出通知，升级后改为data-only会出现“已送达未显示”的现象。
- 版本差异检查：
  - SDK版本升级是否有初始化、权限或API变更要求。
  - 构建/配置文件是否切换（如不同环境的配置被打包进生产）。

B. iOS 专项
- 能力与签名：
  - Xcode工程是否开启“Push Notifications”能力。
  - app的aps-environment entitlement是否存在且为正确环境（生产包包含production）。
  - TestFlight/App Store 安装的包使用APNs生产环境；开发包使用沙盒环境。服务端必须与令牌环境匹配。
- 注册与回调：
  - didRegisterForRemoteNotificationsWithDeviceToken是否被调用并返回token。
  - 若未回调，检查注册时机、主线程调用、权限请求顺序。
- APNs 发送要求（服务端设置，客户端需确认bundleId等未改动）：
  - apns-topic必须与App Bundle ID一致。
  - apns-push-type必填（alert/背景为background），与消息类型一致。
  - 使用正确的APNs域名（生产或沙盒）与有效的身份凭据（p8/p12未过期、未替换团队/Key ID）。
- 静默推送（如使用）：
  - payload包含content-available:1，App开启“Remote notifications”后台模式。
  - iOS不保证静默必达；App被用户上划强退时静默不会唤起应用。

C. Android 专项
- Firebase/厂商通道初始化：
  - google-services.json是否与当前applicationId一致，且来自正确的Firebase项目。
  - 升级后应用包名（applicationId）是否变更；如变更，旧令牌无效，需要新令牌上报。
- 通知渠道（Android 8+）：
  - 使用的通知Channel ID是否存在且重要级别足够高（IMPORTANCE_HIGH/DEFAULT）。
  - 渠道一旦创建，重要级别无法通过代码下调或上调；若旧渠道级别过低，需要新建不同ID的渠道并引导用户打开。
  - 升级时是否误改了channelId，导致投递到未创建的渠道而不显示。
- 前后台与消息类型：
  - data-only消息在后台需由应用代码生成通知；如果升级后改为data-only且前台/后台逻辑未适配，会表现为不显示。
- 厂商/系统限制：
  - 电池优化、后台限制、系统自启管理是否阻断；针对国产ROM需加入白名单或使用前台服务策略。

四、服务端与推送网关检查
- 凭证与环境：
  - APNs私钥/证书是否过期，团队/Key ID是否更换；使用的APNs环境与令牌环境匹配。
  - FCM服务账号是否有效，HTTP v1/Legacy Key是否更替；项目ID、senderId与客户端一致。
- 目标选择与过滤：
  - 分群/标签/版本过滤规则是否误排除了新版本用户。
  - 设备去重、合并策略是否错误（如用旧token覆盖新token）。
- 发送参数：
  - TTL设置过短会导致离线用户未达。
  - collapse_key/apns-collapse-id是否误合并覆盖了后发通知。
  - 优先级设置是否过低（iOS background/Android normal可能延迟明显）。
- 错误码与响应：
  - iOS：校验APNs响应reason（如BadDeviceToken、Unregistered、MissingTopic、BadPriority、BadCollapseId等），对Unregistered/BadDeviceToken进行token失效回收。
  - Android/FCM：检查InvalidRegistration、NotRegistered、MismatchSenderId、Unauthorized、QuotaExceeded、MessageTooBig等；对NotRegistered清理无效token。
- 负载规范：
  - payload键名符合平台要求（iOS aps结构、Android notification/data结构）。
  - 字段编码合法，未超平台大小限制，未包含保留关键字冲突。

五、端到端验证步骤
- 单设备直推验证：
  - 选取一台升级后的真实设备，获取最新token（从客户端日志/调试面板）。
  - 通过后端控制台或命令行工具调用APNs/FCM直推该token，记录响应与messageId。
- 双通道对比：
  - 向同一设备同时发送notification消息与data-only消息，判断是“到达不显示”还是“未到达”。
- 日志采集：
  - iOS：使用Xcode查看控制台日志；过滤通知注册、令牌上报、通知回调。
  - Android：adb logcat过滤FirebaseMessaging、通知创建与显示；dumpsys notification查看渠道与拦截信息。
- 样本对比：
  - 对比旧版本与新版本同一设备/账号的到达率；锁定是否为版本引入问题。

六、基于平台的常见根因与修复建议
- iOS
  - 缺少或错误aps-environment entitlement、未开启Push能力 → 重新配置签名与能力，重新构建发布。
  - 使用了沙盒令牌却走生产APNs，或TestFlight使用生产APNs但服务端仍走沙盒 → 统一令牌/网关环境。
  - 未设置apns-push-type/apns-topic或与消息类型不符 → 按规范补齐并校正。
  - 版本中Bundle ID变更导致apns-topic不匹配 → 修正服务端topic或回退Bundle ID。
  - 静默推送未开启后台模式或用户强退 → 开启“Remote notifications”，调整策略并避免依赖必达。
- Android
  - 通知渠道ID变更或重要级别过低 → 保持原ID并在首次创建时设定正确级别，或创建新渠道并引导用户手动提高重要级别。
  - 由notification改为data-only但未在后台显示 → 在FirebaseMessagingService中实现通知展示逻辑，或恢复notification负载。
  - applicationId/项目配置不匹配 → 使用匹配的google-services.json并重新生成令牌。
  - 后台限制/电池优化导致延迟/不显 → 采用高优先级消息、前台服务、ROM适配与白名单引导。
- 服务端
  - 凭证过期或项目切换 → 更新APNs p8/FCM服务账号并验证权限。
  - 过滤规则/人群定义错误 → 校对版本/标签条件，放开限制验证。
  - TTL过短、错误collapse导致丢弃 → 延长TTL，合理设置collapse，避免覆盖关键通知。
  - 未处理失效token → 建立回执/错误码处理，清理无效token。

七、修复与回滚策略
- 快速修复优先级：环境/凭证错误 > 渠道/权限错误 > 负载/策略错误 > ROM/用户设置引导。
- 若为服务端配置/凭证问题：即时修复并重发关键通知。
- 若为客户端版本问题：
  - 能通过远端配置修复（渠道ID、展示策略）则下发热修/远端配置。
  - 无法热修则发布紧急修复版本；同时通过其他触达渠道进行用户告知。
- 建立临时观测：对修复后样本设备持续观测到达率、延迟、中位数和P95。

八、预防与发布前核对清单
- 令牌流程：升级后token刷新回调验证，token上报幂等与去重。
- 环境一致性：包类型与APNs/FCM环境匹配，凭证有效期监控。
- 负载合规：关键header（apns-push-type/apns-topic）、渠道ID存在且重要级别正确。
- 回执与错误码处理：自动清理无效token，异常告警。
- 端到端冒烟：CI/CD中包含真实设备/模拟器的直推用例（通知类与静默类），并校验显示。
- 监控看板：分平台/版本/渠道的送达率、退回码、延迟指标与阈值告警。

按上述步骤逐项排查，可快速定位是“未发送/被网关拒绝/到达未显示/设备受限”等不同类别问题，并采取相应修复措施。

故障排除步骤：应用接口响应超时，服务器 CPU 长期高于 90%

目标
- 快速恢复可用性，控制超时比例和延迟。
- 准确识别导致 CPU 升高与超时的根因（计算热点、线程池/队列饱和、GC、依赖慢、网络/内核、容器限流等）。
- 在定位期间减少进一步放大（重试风暴、排队膨胀）。

一、现象确认与影响评估（5–10 分钟）
- 确认证据：
  - 接口超时比例（例如超时数/总请求数）、关键延迟指标（p95/p99）是否与 CPU 升高时间一致。
  - 区分是服务端超时还是客户端超时（检查网关/Nginx 日志中的 request_time 与 upstream_response_time）。
  - CPU 指标维度：总 CPU、每核利用率、系统态/用户态占比、steal（虚机被争用）、iowait（受 I/O 影响）。
- 快速查看：
  - Linux: top 或 htop（确认占用最高的进程/线程），mpstat -P ALL 1（每核利用）、vmstat 1（r 队列、cs/s）、pidstat -u -t -p <pid> 1（进程/线程 CPU）。
  - 容器/K8s: kubectl top pod/node，kubectl describe pod（看 CPU requests/limits、是否存在 CPU 节流）。
  - 验证是否存在重试放大：网关/客户端的重试率、状态码分布（429/503/504）、同一请求的重复到达。

二、立即缓解措施（并行执行，优先止血）
- 在入口层启用或收紧：
  - 限流（基于并发或 QPS）、熔断（对高失败/高延迟下游快速失败）、超时与重试（上游重试次数≤2，并使用指数退避+抖动）。
  - 背压与排队上限（上游最大并发/连接数、应用内部队列容量）。避免无限排队。
- 快速扩容或降级：
  - 横向扩容实例；如果容器受限，临时提高 CPU limits 或去掉 CPU 限流观察是否节流导致。
  - 启用降级路径（缓存命中、关闭非必要计算、降级部分功能或字段）。
- 日志与审计：
  - 临时提高关键路径的日志采样或 APM 采样比，便于抓取慢请求样本；同时避免全量高频日志放大 CPU/IO。

三、系统级定位（确认 CPU 高的范畴和性质）
- 确定 CPU 类型：
  - 用户态高：多为应用计算、JSON 序列化/压缩、循环、锁竞争。
  - 系统态高：系统调用频繁、网络/磁盘中断、内核态复制或加解密。
  - 高 steal：宿主机超售或邻居干扰（云主机），需迁移实例或联系平台。
- 核心命令与信号：
  - top/htop 定位进程；top -H -p <pid> 查看热点线程；pidstat -t -p <pid> 1 观测线程 CPU 随时间变化。
  - mpstat -P ALL 1（是否单核打满）；sar -q 1 10（运行队列长度是否持续>核心数）。
  - 检查软中断/网络：观察 ksoftirqd 是否占用高；sar -n DEV 1（网卡包量）、cat /proc/softirqs。
- 容器节流（重要）：
  - cgroups v2: cat /sys/fs/cgroup/cpu.max；cgroups v1: cpu.cfs_quota_us / cpu.cfs_period_us。
  - cat /sys/fs/cgroup/cpu.stat（nr_throttled、throttled_time）判断是否因限额被节流，节流会导致排队増加与超时。

四、进程与线程级定位（找出热点与瓶颈）
- 线程视角：
  - Java: jstack -l <pid>（查找 BLOCKED/WAITING/大量相同栈）；jcmd <pid> Thread.print。top -H 配合线程 ID 转十六进制对照栈。
  - .NET: dotnet-counters monitor System.Runtime,Microsoft.AspNetCore; dotnet-trace collect；查看线程池队列长度、锁等待。
  - Go: 访问 /debug/pprof（cpu、goroutine、block）；go tool pprof 分析热点函数与阻塞点。
  - Python: py-spy top/record；关注 GIL 导致单核 100% 与 C 扩展热点；检查多进程模型。
  - Node.js: clinic flame 或 0x 定位同步阻塞、JSON 序列化、加密计算。
- GC 与内存相关（GC 暂停会间接致超时）：
  - Java: jstat -gc <pid> 1s，jcmd <pid> GC.heap_info；查看 Full GC 次数、暂停时间；分析 GC 日志。
  - .NET/Go：检查 GC 暂停与堆增长（dotnet-gcdump，pprof heap）。
  - 现象：高分配率、对象抖动、过大对象、无界缓存会加重 GC 并伴随 CPU 升高。
- 锁竞争/自旋与队列堆积：
  - 线程栈出现大量 synchronized/ReentrantLock、自旋 CAS 或阻塞队列等待。
  - 应用线程池/连接池满：请求排队、超时上升。检查池的 active/max、队列长度、拒绝/等待时间。

五、应用与外部依赖（链路级根因）
- 数据库：
  - 连接池占用与等待（如 HikariCP ActiveConnections、PendingThreads）；慢查询日志、索引缺失、N+1 查询。
  - 如果 DB 慢导致应用线程阻塞，应用 CPU 可能不高但延迟高；若在应用侧做大量结果集处理/序列化，CPU 也会上升。
- 缓存与外部 API：
  - 缓存命中率骤降、穿透/击穿；外部 API 延迟升高引发线程占用与重试放大。
- 序列化/压缩/TLS：
  - 大响应体或高压缩级别（gzip level 9）会显著耗 CPU；尝试降低压缩级别或只对大包压缩。
  - TLS 协商计算开销高时考虑开启会话复用、启用硬件/代理卸载。
- 网关/Nginx：
  - 查看 $request_time 与 $upstream_response_time 差值；4xx/5xx/499 比例；worker 连接与并发是否达上限。

六、网络与内核层面（当系统态 CPU 高或网络包异常）
- 观察软中断与包洪泛：ksoftirqd 占用高，sar -n TCP,DEV；ss -s 或 ss -ant state established 查看连接数和状态分布（SYN-RECV/ TIME-WAIT 异常）。
- 检查防火墙/iptables 规则过多引发匹配成本上升。
- DDoS 或重试风暴迹象：来源集中、短周期重试；在边缘开启限速/ACL/挑战验证。

七、配置校准：超时、并发与容量
- 服务端：
  - 线程池/事件循环：设置合理的 maxThreads/队列上限，避免无界排队；对阻塞与计算型工作负载分池（bulkhead）。
  - 超时：server 读/写/空闲超时与下游调用超时分层配置，确保总超时预算可控。
- 客户端与网关：
  - 重试策略：限定最大重试次数与总时间窗，使用指数退避与抖动；对非幂等请求禁用自动重试。
  - 连接池大小、最大并发请求数与目标实例数相匹配，防止队头阻塞。
- 容器与弹性：
  - CPU requests/limits 与负载相匹配；避免过低 limits 导致 cgroup 节流。
  - 自动扩缩容触发条件组合：CPU 利用率+p95 延迟/并发/队列长度，而非仅 CPU。

八、常见根因与对应修复指引
- 单核热点（JSON 序列化、正则、加密）：优化代码路径或并行化；降级压缩级别；冷热数据分离。
- GC 频繁或长暂停：减少对象分配；合理设置堆大小与代大小；选择合适 GC（如 G1/ZGC，需评估）；修复缓存无界增长。
- 线程池饱和与排队过长：增大池或拆分池；设置队列上限与快速失败；对慢操作异步化并限并发。
- 数据库慢/锁等待：加索引、重写查询、分页；提升连接池与数据库容量；避免 N+1；读写分离/缓存。
- 外部依赖慢与重试风暴：启用熔断与限流；合理超时与重试；本地/边缘缓存。
- 容器 CPU 节流：提高 limits 或去限；加副本；优化 CPU 密集型逻辑。
- 网络软中断过高：核间中断分发（RPS/RFS）、合理中断亲和；排查异常流量。

九、验证与复盘
- 在灰度环境复测修复措施，监控以下回落：CPU、p95/p99 延迟、超时率、错误率、线程池/连接池利用率、队列长度、GC 暂停。
- 恢复后复盘：补齐容量基线、SLO/告警、负载测试、性能回归测试与性能预算。

附：常用命令（Linux/K8s，按需执行）
- top, top -H -p <pid>, htop
- pidstat -u -t -p <pid> 1
- mpstat -P ALL 1, vmstat 1, sar -u 1 10, sar -q 1 10
- ss -s, ss -ant | awk '{print $1}' | sort | uniq -c
- jstack -l <pid>, jstat -gc <pid> 1, jcmd <pid> Thread.print / GC.heap_info
- py-spy top --pid <pid>
- go tool pprof http://host:port/debug/pprof/profile?seconds=30
- dotnet-counters monitor System.Runtime,Microsoft.AspNetCore
- kubectl top pod/node, kubectl describe pod, kubectl get hpa
- 查看 cgroup 节流：cat /sys/fs/cgroup/cpu.stat；cgroups v2 配额：cat /sys/fs/cgroup/cpu.max

执行以上步骤时，优先保护服务可用性，随后逐层缩小范围，最终用采样/火焰图/线程转储定位到具体代码路径或资源瓶颈，再实施针对性修复与容量治理。