Kacam.net

Troubleshooting

CPU 打满,QPS 一点没涨

CPU 从 40% 打到 95%,QPS 一点没涨,而且昨天没有发布。

Copy the prompt, then pick a model. It plays the interviewer and asks you through it scene by scene instead of handing you the answer.

On a phone with the app installed, the system opens the app directly. Links cannot open external apps inside WeChat — open it in a browser first.

「CPU 高」不等于「算得多」。第一步永远是把它拆成三份,拆完再看火焰图,看完再猜原因 —— 顺序反过来是这类问题上最常见的时间浪费。

这一份还想让你记住另一句:「没有发布」不等于「没有变更」。配置中心、开关、灰度规则、DNS、证书、上下游的策略——这些都能在一行代码都没改的情况下改变系统行为,而且多数公司的发布记录不覆盖它们。

所以问变更的时候要问全。怎么问全,你自己试试。

★★★★☆ · about 30 min · Tests: user / sys / iowait 先拆开、火焰图、什么算「变更」

The move this one drills

Cause vs effect Reach for the right tool Hunt the change

Have you done this one?

Sign in to mark this one as practised — next time you come back you'll see when you did it.

Notes from people who did this one

Nobody has written yet. After you run it, say what came out of the conversation — which scene stumped you, which conclusion you changed afterwards.

Sign in to write a note.

How to use this

It gives you the scene (what the service is, the symptom, when it started, the blast radius) and then goes quiet. You ask questions, request metrics, logs, packet captures, propose hypotheses — it answers from a truth you cannot see.

**It is not allowed to volunteer where to look next.** If you don't ask, it doesn't say — even if you circle for ten minutes. That's deliberate: in real life nobody stands next to you saying "maybe check the flame graph". Troubleshooting *is* the skill of knowing what to ask.

How to start

  1. Pick one, open it, copy the prompt.
  2. Paste it into a brand-new conversation.
  3. It gives you the scene and stops — **now it's your turn to speak.**

Four commands you can call out at any time

  • 给个方向 give me a direction, not the answer (counted in the tally)
  • 公布真相 reveal the truth and wrap up
  • 换一个 start over with a different incident
  • 复盘 wrap up now and print the review card

Three traps

  • Don't read the truth at the end first — that ruins the whole thing.
  • Don't start by guessing the cause. Establish the scope first (how much, which part, when it started); scope tells you whether this is a code problem or an environment problem.
  • Every scene has planted false leads: an unrelated deploy at the same time, metrics that are effects rather than causes, the textbook suspect waiting for you. The wrap-up tells you how many questions you spent on each.

Start with the P99 one — its diagnostic chain is the cleanest. Then "only some machines", whose lesson is the most reusable of all. Save the intermittent timeout for later: its answer lives outside your own system. The report mismatch needs no systems knowledge at all.