An audit of my own radar
Also in Chinese: 中文版
How the scores are produced
The method comes first, because without it the numbers are noise. Each depth score on the radar is derived from evidence density: the count and depth of flagship artifacts (incident write-ups with quoted evidence, measured results that survived re-measurement), the amount of methodology distilled out of the work (runbooks, debug trees, standing rules), and whether anything is publicly verifiable. It is explicitly not self-assessment.
The reason: a self-rated score carries no information for a reader. Self-ratings are uncalibrated across people, and the incentive to inflate is structural. An 82 backed by a certified migration is a claim you can audit; an 82 backed by confidence is a mood. Deriving scores from evidence also means they can be wrong in inspectable ways — the property that makes them worth publishing.
The nine domains, one paragraph each
Data & State — 82/90. Flagship: a ClickHouse-to-Doris migration of ~5.2B rows and ~3,700-column tables, certified 99.945% row-complete over the full unsampled dataset, with four non-obvious OOM classes and a livelock root-caused at engine level. Separately, a full-scale restore drill: 5.2B rows recovered from snapshot and verified by query. 82 is the tallest axis because the evidence goes deepest — into engine code. It is not 90 because the depth is concentrated in one engine family and the restore drill was episodic, not institutional.
Observability — 80/85. A multi-tenant monitoring platform (50 clusters, 1.2M active series) built and operated; forensic use of telemetry, including 74.7M rows of production query logs mined to reverse a table-design decision; latency decomposition that proved a suspected layer innocent. The gap to 85 is not tooling — it is SLO operation, covered under incident.
Distributed Systems — 78/88. Compute-storage separation argued as a trade (state concentrates rather than disappears) and then operated; a two-tier admission-control design whose safety never depends on its classifier being right; the finding that point-lookup latency was file-open-bound, not scan-bound. The distance to 88 is honest: I operate and reason about consensus and replication layers; I have not designed one.
Platform & Automation — 76/85. Controllers preferred over scripts, and the standard applied in reverse: a bespoke scaler collapsed to a single JSON-patch once the platform operator matured. An AI-agent triage harness and an agent control plane, plus upgrade automation. The gap: none of this has yet been operated as a product with users beyond my own team.
Incident & Reliability — 72/82. 20+ production P1/P2 incidents as primary on-call with MTTR around 30 minutes; two compaction incidents taken to engine-level root cause; a tail-latency investigation that ended in a timeout constant masquerading as physics. 72 scores response strength. What it deliberately does not include — because the record does not — is a season of SLO and error-budget operation. That is most of the distance to 82.
Infra & Capacity — 70/80. A four-layer IaC pipeline (image baking, orchestration, configuration, control-plane bootstrap); 50 clusters, 600+ nodes, 6 regions operated as primary on-call; capacity decisions from measurement, including proving scale-out useless before money was spent. One boundary stated plainly: my autoscaling-group and launch-template depth is consume-and-patch, not from-scratch fleet design.
Release & Change — 68/78. Production Kubernetes upgrades 1.24 to 1.29 across 50 clusters with zero incidents, per-cluster time cut from 18–21 hours with two people to 6–8 with one operator plus purpose-built automation; a dry-run render-diff that caught a chart upgrade silently resetting a serving pool from 4 replicas to 1. The gap: progressive delivery at the service level as routine practice, not as upgrade-project discipline.
Influence & Communication — 52/75. An internal training deck and guided onboarding for the monitoring stack; an alert-governance initiative; bilingual technical writing; one line-by-line audit that reversed a leadership decision on open-source scope. All real, all local. 52 says exactly that: the record contains persuasion and teaching, but no initiative I originated that crossed team boundaries with committed resources.
Security & Compliance — 40/65. The real work is agent-side: deny-by-default sealed tools, write attestation, blast-radius-tiered execution gates. The traditional face — IAM design, audit frameworks of the SOC 2 class — is essentially absent from the record. 40 is a statement of fact, not modesty.
A behavioral cross-check
The scores above were assigned top-down, from reviewing evidence. There is also a bottom-up signal produced independently: my on-call knowledge base, accumulated as a side effect of working incidents, not built for this site. It currently holds 21 documented investigations (more than 20 of them production P1/P2), 16 runbooks, 15 fast-triage cards, 7 debug trees, and 4 recurring root-cause patterns.
Tagging those entries by domain gives: incident 14, data 8, observability 6, infra 6, distributed systems 5, release 5, platform 2, security 0, influence 0.
Two honest notes on the denominator before reading anything into it. First, these are documented investigations — the counts measure documentation discipline as much as exposure. Second, “21 investigations” and “20+ P1/P2” overlap but are not the same series; investigations are the subset that got written down with evidence.
With those caveats, the cross-check holds. Incident leads by construction — it is an incident knowledge base. Among the subject-matter domains, data dominates at 8, matching data being the tallest radar axis; observability, infra, distributed systems, and release cluster in the middle, matching the mid-height axes; security and influence sit at zero, matching the two lowest axes. The radar shape and the triage record were produced by different processes, and they agree. If I had inflated any axis, this record is where the contradiction would show.