项目证据与指标盘点

本页是项目数字的唯一登记处；案例写法见项目深挖，简历用法和 JD 对齐见求职与面试流程。先填最小集，再写项目故事，不要先编话术再补数字。

一、为什么要盘点证据

高级岗位的项目回答不能只描述技术组件。每个结论都应尽量对应一种证据：业务目标、系统指标、设计文档、监控数据、线上故障、个人代码或跨团队决策。

无法获得精确历史数据时，可以说明估算范围和估算口径，不要编造看似精确的数字。

最小集：先填这 15 格

不要一次填满所有模板。先选 2～3 个主项目，各填 5 项；没有精确值时写“量级 + 口径 + 待核实”，不要编造精确数字。

项目	峰值 QPS	核心表数据量	核心接口 P99	MQ 最大积压	我的角色
审核系统
机审系统
消息/积分

填写口径示例：

• 峰值 QPS：网关近 30 天每分钟请求数最大值 ÷ 60；
• 核心表数据量：information_schema.TABLES 的 TABLE_ROWS 只用于量级，精确值用 COUNT(*)（从库/低峰执行）；
• P99：Prometheus histogram 近 7 天工作日 10:00～22:00；
• MQ 最大积压：消费组 lag 监控的历史最大值与恢复时长；
• 我的角色：写“主导设计/实现/参与”，并标出团队原有部分。

填完这 15 格，再补项目总表、3 个优化/故障案例和架构决策；顺序不要反过来。

二、项目总表

项目	时间	团队规模	我的角色	核心服务	用户/调用方	业务价值	主项目优先级
审核系统							P0
机审系统							P0
消息系统							P0
积分系统							P0
内容中心							P1
博客							P2

三、规模指标

为每个核心项目补充：

日请求量：
日任务/消息/交易量：
日活用户或调用方数量：
平均 QPS：
峰值 QPS：
核心接口平均/P95/P99：
错误率或失败率：
数据库总量和日增量：
核心单表数据量：
Redis 数据量和命中率：
MQ 正常吞吐和历史最大积压：
服务实例数量和规格：
上下游服务数量：
可用性/SLA（如果有）：

估算口径示例

• 日任务量可从业务日报、数据库日增量或 MQ offset 估算；
• 峰值 QPS 可从网关、APM、日志采样或实例数×单实例峰值估算；
• 数据量可用总行数、日增量和保留周期估算；
• 优化效果必须说明对比窗口、流量是否相近和是否存在扩容等干扰因素。

填写示例（虚构，仅示范格式）

日任务/消息/交易量：审核任务约 {日任务量} 条/天（口径：audit_task 表近 30 天日增量均值）
峰值 QPS：提交接口约 {峰值QPS}（口径：网关近 30 天每分钟请求数最大值 / 60）
核心接口 P99：{P99毫秒} ms（口径：Prometheus histogram，近 7 天工作日 10:00～22:00）
MQ 历史最大积压：{最大lag} 条，恢复耗时 {恢复分钟} 分钟（口径：消费组 lag 监控截图）

要点：每个数字后面写口径和时间窗口，面试时被追问“这个数怎么来的”能直接回答。

数据从哪里查

数据库日增量和表规模（MySQL）：

-- 近 30 天日增量（create_time 需有索引，建议在从库或离线库执行）
SELECT DATE(create_time) AS d, COUNT(*) AS cnt
FROM audit_task
WHERE create_time >= CURDATE() - INTERVAL 30 DAY
GROUP BY DATE(create_time)
ORDER BY d;

-- 表行数与占用空间估算（TABLE_ROWS 是估算值，只用于量级）
SELECT TABLE_NAME, TABLE_ROWS,
       ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024 / 1024, 2) AS size_gb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = '{库名}'
ORDER BY DATA_LENGTH + INDEX_LENGTH DESC
LIMIT 20;

-- 慢 SQL：开启 performance_schema 时按耗时排序
SELECT DIGEST_TEXT, COUNT_STAR, ROUND(AVG_TIMER_WAIT / 1e9, 2) AS avg_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

接口 QPS、P99、错误率（Prometheus/Grafana，以 Spring Boot Actuator + Micrometer 指标为例）：

# QPS（按接口）
sum(rate(http_server_requests_seconds_count{application="{应用名}"}[1m])) by (uri)

# P99（需开启 percentiles-histogram）
histogram_quantile(0.99,
  sum(rate(http_server_requests_seconds_bucket{application="{应用名}"}[5m])) by (le, uri))

# 5xx 错误率
sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
  / sum(rate(http_server_requests_seconds_count[5m]))

# 峰值：在 Grafana 中把时间范围拉到近 30 天，看 max 值；或用 max_over_time
max_over_time(sum(rate(http_server_requests_seconds_count[1m]))[30d:1m])

JVM 与线程池：jvm_gc_pause_seconds_*、jvm_memory_used_bytes、executor_active_threads、executor_queued_tasks；没有监控时用 jstat -gcutil {pid} 1000 10、jcmd {pid} GC.heap_info 现场采样。

MQ 吞吐和积压：

实验代码

# Kafka：查看消费组每个分区的 LAG
kafka-consumer-groups.sh --bootstrap-server {broker}:9092 --describe --group {消费组}

# Kafka：查看 topic 各分区最新 offset，两次相减 / 时间间隔 ≈ 生产速率
kafka-get-offsets.sh --bootstrap-server {broker}:9092 --topic {topic}
# 旧版本：kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list {broker}:9092 --topic {topic}

# RocketMQ：消费进度与 Diff（积压）
mqadmin consumerProgress -n {namesrv}:9876 -g {消费组}
mqadmin topicStatus -n {namesrv}:9876 -t {topic}

Prometheus 有 kafka-exporter 时：sum(kafka_consumergroup_lag{consumergroup="{消费组}"}) by (topic)。

Redis 数据量和命中率：

实验代码

redis-cli -h {host} INFO stats | grep -E "keyspace_hits|keyspace_misses"   # 命中率 = hits / (hits + misses)
redis-cli -h {host} INFO memory | grep used_memory_human
redis-cli -h {host} INFO keyspace
redis-cli -h {host} --bigkeys        # 大 Key 扫描，建议在从节点、低峰期执行

其他来源：网关/Nginx access log 按分钟聚合请求数、APM（SkyWalking/Pinpoint）的接口拓扑和慢调用、发布平台的实例数和规格、事故复盘文档、周报/日报中的业务数字。离职后拿不到系统数据时，以当时周报、复盘文档和自己的记忆为准，回答时说明是“量级估算”。

四、个人贡献证据

对每个项目回答：

我亲自设计的部分：
我亲自实现的核心模块：
我主导的技术评审：
我推动的跨团队事项：
我处理的线上故障：
我做的性能/稳定性优化：
我编写或完善的监控告警：
我沉淀的通用组件/规范：
团队原有方案中不是我设计的部分：

面试时明确区分“我”“我们团队”“已有平台”，可信度会更高。

填写示例（虚构，仅示范格式）

我亲自设计的部分：审核任务状态机和 {状态数} 个状态的流转校验
我亲自实现的核心模块：任务分配与超时回收，代码约 {代码行数} 行
我推动的跨团队事项：与 {上游团队} 统一回调协议，接入方从 {接入前} 个增加到 {接入后} 个
团队原有方案中不是我设计的部分：底层 MQ 集群和通用网关由基础架构团队维护

证据来源：Git 提交记录（git log --author="{姓名}" --since="{开始日期}" --stat）、技术评审文档、需求单/工单、值班记录和复盘文档。

五、优化案例模板

至少准备 3 个，优先选择不同瓶颈层次：应用/JVM、数据库/缓存、MQ/架构。

案例名称：
业务影响：
优化前指标：
目标指标：
最初假设：
实际证据：
根因：
临时止损：
长期方案：
为什么选择该方案：
替代方案及未采用原因：
如何压测/灰度：
优化后指标：
如何监控和避免回退：
我的具体贡献：

填写示例（虚构，仅示范格式）

案例名称：审核列表查询慢 SQL 优化
优化前指标：列表接口 P99 {优化前P99} ms，慢查询日 {慢查询数} 次
实际证据：慢日志 + EXPLAIN 显示 type=ALL，rows≈{扫描行数}，排序走 filesort
根因：查询条件 (status, create_time) 无联合索引，深分页 LIMIT {offset},20
长期方案：建联合索引 + 游标分页（WHERE id < {上一页最小id}）
如何压测/灰度：从库回放 {回放时长} 小时慢日志，按 {灰度比例}% 流量灰度
优化后指标：P99 {优化后P99} ms，对比窗口为上线前后各 7 天，流量差异 {流量差异}%
如何监控和避免回退：慢查询告警阈值 {阈值} ms，DDL/SQL 评审加入 EXPLAIN 检查

数据来源：优化前后在 Grafana 用同一 PromQL 和相同时间窗口截图；数据库侧用慢日志（pt-query-digest slow.log）对比次数和平均耗时；压测用 JMeter/wrk 报告。

六、故障案例模板

至少准备 3 个，避免所有案例都是慢 SQL。

故障现象：
发现方式：
开始时间和变化点：
影响用户和范围：
应急负责人和协作方：
第一步止损：
排查证据链：
最终根因：
恢复方式：
数据是否需要补偿：
恢复耗时：
长期修复：
新增监控/告警/演练：
复盘中发现的流程问题：
我的具体职责：

填写示例（虚构，仅示范格式）

故障现象：消息消费积压，用户通知延迟约 {延迟分钟} 分钟
发现方式：consumer lag 告警（阈值 {告警阈值} 条）
开始时间和变化点：{日期时间}，当天上线了消费端新版本
第一步止损：回滚消费端版本，临时扩容消费实例 {扩容前} → {扩容后}
排查证据链：lag 曲线与发布时间吻合 → jstack 显示消费线程阻塞在下游 HTTP 调用 → 新版本未设置超时
最终根因：下游接口无超时 + 同步调用，单条消费耗时从 {正常耗时} ms 升到 {异常耗时} s
数据是否需要补偿：无丢失，积压消费完后核对发送量与业务表一致
恢复耗时：{恢复分钟} 分钟
长期修复：统一 HTTP 客户端超时配置，消费逻辑异步化，增加消费耗时 P99 告警

数据来源：告警平台历史记录、发布平台变更记录、Grafana lag/耗时曲线、当时保存的 jstack/GC 日志、事故复盘文档。

推荐覆盖：

• CPU/GC/线程池问题；
• 数据库锁、慢 SQL 或连接池问题；
• Redis 热 Key、大 Key 或缓存失效；
• MQ 积压、重复消费或消息丢失风险；
• 下游超时、重试放大或发布配置问题。

七、架构决策模板

决策主题：
当时业务目标：
必须满足的约束：
候选方案 A：
候选方案 B：
候选方案 C：
比较维度：一致性/可用性/性能/成本/复杂度/团队能力
最终决策：
主要风险：
风险缓解措施：
上线验证：
实际结果：
现在是否仍会选择该方案：

填写示例（虚构，仅示范格式）

决策主题：积分扣减如何保证不超扣
必须满足的约束：峰值 {峰值QPS} QPS，不允许超扣，可接受最终一致的流水对账
候选方案 A：MySQL 条件更新 UPDATE ... SET balance = balance - ? WHERE user_id = ? AND balance >= ?
候选方案 B：Redis Lua 预扣 + 异步落库
候选方案 C：分布式锁 + 查询后更新
最终决策：A + 唯一幂等号，热点用户再做请求合并
主要风险：热点行锁竞争；缓解：按用户维度限流，监控行锁等待 {锁等待指标}
实际结果：上线后 {观察周期} 内对账差异 {差异笔数} 笔
现在是否仍会选择该方案：在当前量级下仍会；量级再上一个数量级时考虑方案 B

八、金融行业证据

如果投递金融行业，优先盘点：

• 幂等号、业务流水、账户流水；
• 余额/状态和流水的事实来源；
• 对账、差错处理、补偿和人工复核；
• 权限、审批、敏感字段、脱敏和审计；
• 规则/模型/配置版本及回滚；
• 灾备、故障恢复和数据恢复；
• 发布窗口、变更审批和操作留痕。

如果项目中没有相关实践，要诚实说明经验边界，再给出自己会如何设计。

九、项目追问矩阵

追问	审核	机审	消息	积分	内容中心
最大业务难点
最大技术难点
一致性方案
幂等方案
性能瓶颈
故障案例
数据和监控
技术取舍
最大技术债
重做如何改进

填写示例（虚构，仅示范格式）：单元格写关键词即可，例如“幂等方案”一格写成“业务唯一键 {业务键} + 唯一索引兜底 + 状态机前置校验”，详细内容放到对应的优化/故障/决策模板中。

十、验收标准

• [ ] 至少 3 个项目有可信的规模数据；
• [ ] 至少 3 个优化案例有前后指标；
• [ ] 至少 3 个故障案例有完整证据链；
• [ ] 每个主项目都能明确个人与团队贡献边界；
• [ ] 至少 2 个架构决策能够比较候选方案；
• [ ] 金融版简历能够找到正确性、审计、对账或稳定性证据；
• [ ] 所有简历项目描述都能经受“具体数字是什么”和“你亲自做了什么”的追问。