2022.09 — 2026.06 / 工作总结
四年，责任半径是怎么外扩的
从「接需求做功能」走到「盯数据、做治理、能兜底」的后端——四年里把一条赛事门店 SaaS 的 C 端流量做到 4–5 倍，并在 2025 下半年开始承担架构级工作（独立部署、主从拆分、数据库治理）。
关于脱敏：本页所有内容已做对外脱敏处理——
公司内部产品线名已替换为行业通用角色描述，内部服务与库表代号已泛化，
人名替换为角色。公开技术栈与第三方产品名称保留（这是能力证明，不是机密），
收入类数字改为量级描述，运营类量化成果保留原值。
其中「2025 月维度轨迹」「主题分布」「关键里程碑」延展自 IMA 知识库 2025 年月度日报与工作事项汇总。
910 天
实际到岗工作日
自然日 1379 天（2022.09—2026.06，日报实计）
70 项
累计交付的项目与需求（截止 2026.10）
2022—2025 经三年总结核定 70；2025.07 起结合日报持续增量
150+ 项
近半年处理事项
2025.12—2026.06 归并 25 模块（5 条业务线）
4 年
同一家公司持续投入
2022.09 至今
12 维
能力自评维度
均值 2.42 → 3.42
6 件
可讲成完整 STAR 的代表作
另有 5 件没做成的
2025 月维度轨迹：功能 vs 基建怎么切换
每根柱是当月工作投入占比，从日报汇总里抽出来的
TRAJECTORY
1月
2月
3月
4月
5月
6月
7月
8月
9月
10月
11月
12月
功能 / 业务
架构 / 基建
看这根曲线就明白延展在哪：上半年（1–6 月）是功能密集期（推荐起量、内容审核、支付体系），
下半年（7–12 月）基建占比一路抬到 60%（独立部署、数据库治理、定时任务关停），
到 2026 上半年又把这套能力平移到 AI 推荐与作者迁移。这条「先打功能、再补地基」的节律，是从三年工作总结里看不出来的。
按年主线：业务重心是怎么迁移的
不是换了几个需求，是责任半径在变
YEARS
2022
打地基
问卷导入部署、赛事公众号推送、今日赛事落地页、世界杯专题、赛事积分榜入库
执行者：把需求落地
2023
铺开
CRM 后台部署上线、线下汇付支付设计、赛事营销活动、大数据埋点设计、女足世界杯专题、支付会员权益一二期
独立负责模块，开始做设计
2024
深水区
企微 SaaS、新版比赛分析页、奖金计算器滚动、App 推送、memcached 内存治理、赛事数据源切换
接复杂需求，开始排查线上疑难
2025
推荐 + 支付
赛事情报 / 指标数据产品、时长卡与权益、微信收付通、立减金、首单折扣、社区业务线独立部署
跨业务线协同，做支付体系
2026
架构治理
业务与数据剥离、Redis 主从、MongoDB 跨大版本升级、6 台+ MySQL 全表扫描治理、定时任务关停
架构与性能负责人
这条线的意义：不是「换了几个需求」，而是责任半径在逐年外扩——从功能 → 模块 → 业务线 → 架构。
2025 工作主题分布
按事项归类，不是按工时——更能看出重心
THEMES
支付与订单体系20%
数据统计与埋点17%
推送与消息12%
推荐与作者运营14%
数据库与性能治理16%
内容/情报模块13%
部署与运维8%
支付与订单（20%）+ 数据统计（17%）+ 数据库与性能治理（16%）三者合计过半，
正好对应下半年「功能转地基」的节奏——支付是上半年收口的功能，统计与治理是下半年铺开的基建。
关键里程碑：从打功能到做架构
橙色=功能/业务，蓝色=架构/基建
MILESTONES
2025 H1功能 / 业务
推荐业务起量
推荐（头部作者）推送与粉丝定时任务上线，推流体系跑通
2025-03功能 / 业务
内容审核体系
接入第三方内容审核，敏感信息过滤与 B 端头像/公告扫描
2025-06功能 / 业务
支付体系搭建
订单号统一 partner 区分、情报支付/周卡/分成比例，全链路打通
2025 H2架构 / 基建
社区业务线独立部署
业务 + 四套存储剥离，变现接口独立域名与独立 Web 服务器
2025-2026架构 / 基建
数据库体系化治理
6 台+ MySQL 全表扫描 P0–P3 分级，MongoDB 跨版本升级，StarRocks 迁移
2026 H1功能 / 业务
AI 智能推荐 / 专家内容迁移
新增多个服务商账号、PGC 榜单、头部作者数据迁移与推荐
关键成果（可量化）
能写数字的地方都写了，有前后对比的标出来
OUTCOMES
C 端日均 UV
1 万
→
4–5 万
+350%
2024.01 → 2025.06，4–5 倍；期间经历欧洲杯 / 世俱杯等大赛流量
B 端店铺海报日均使用
500 家
→
2000 家
×4
2024.01 → 2025.06，4 倍
推荐业务流水
周末日均稳定在数万元量级
2024.10 接手推荐业务后逐步起量，随赛事波动
首单折扣活动
单日订单占比 40–50%
支付转化抓手，做了 1 期与 2 期倒计时
立减金功能
促活 2025 人
从调研老优惠券系统，到设计并实现
高耗时接口治理
3 个接口纳入优化
用户初始化 29708ms、榜单查询 14463ms、活动榜单 8674ms
数据库治理
6 台+ MySQL 全表扫描分级
输出 P0–P3 报告；内容统计宽表单次扫描近 49 万行定级 P0
监控类 SQL 占比
98.4%
发现绝大多数慢查是监控 / 元数据类 SQL，据此做降频与预聚合改造
十二维能力成长
自评均值 48.3 → 68.2（+19.9）
GROWTH
增幅最大
仍然是短板
长的不只是写代码，更是把事往前推的能力。理论短板正是后来去考系统架构师的动因。
技术栈图谱
哪些是主力，哪些只是用过
STACK
| 域 | 技术 | 程度 |
|---|---|---|
| 语言 / 框架 | PHP（跨版本迁移中）、Laravel 8、自有 AppFramework | 主力，四年 |
| 关系型存储 | MySQL（跨版本迁移、索引优化、慢查治理） | 主力，含架构级治理 |
| 缓存 | Redis（主从、大 Key、读写分离、session 治理）、Memcached（内存异常治理） | 深度 |
| 文档型 | MongoDB（跨大版本升级、readPreference 修复、复合 / 稀疏索引） | 深度 |
| 分析型 | StarRocks（统计分析库迁移）、ClickHouse 类 bitmap 聚合 | 近两年 |
| 消息 / 通信 | MQTT 订阅、长连接轮询、异步队列、埋点同步改异步 | 有架构演进经验 |
| 支付 | 汇付、微信支付 / 收付通、支付宝、苹果内购、立减金、首单折扣 | 全链路 |
| 推送 | 极光推送（限流治理）、微信模板消息、企微 | 深度 |
| 运维监控 | Linux、Nginx、Apache、Prometheus 接入、定时任务治理、Git | 深度 |
| 第三方对接 | 微信生态、飞书（多维表格同步）、第三方赛事情报、字节赛事、网易易盾审核 | 广度 |
| AI 提效 | 用 AI 辅助开发、统计脚本生成 | 自评 2.0，仍在爬坡 |
业务域分布
近半年 150+ 事项 按 5 条业务线归类（2025.12—2026.06 归并 25 模块）
DOMAINS
数据统计
最重
日维度 47 字段、赛事数据千万级统计、比赛维度、作者分成、活动统计、飞书同步
门店 SaaS（B 端 + C 端）
重
性能优化、情报模块大迭代、头部专家迁移、AI 智能推荐服务商
内容业务线 / 支付
重
独立部署、支付体系、首单折扣、立减金、订单号统一
社区业务线
中
全球球员挖掘、全网方案搜索、单场解读、赛果预测、Redis 大 Key
系统优化 / 运维
中
数据库治理、定时任务关停、安全加固、监控接入
六件代表作 · 完整 STAR
按「有量化结果 + 有技术深度 + 有影响面」三条筛出来
HIGHLIGHTS
S
01 · 赛事数据同步架构三次演进
S
赛事数据是多业务线的地基，丢一次就是全站事故。
T
保证数据不丢、不延迟、可切换。
A
三年做了三代：① HTTP 主动拉取入库 → 发现同步推送 + 埋点请求打满，改异步；② MQTT 订阅接收 → 出现 2 次赛事数据丢失；③ 长连接定时器轮询 → 数据源切换到新的上游供应商，稳定运行至今。
R
每一代都是针对上一代的真实故障做的，最终形态沿用至今。
唯一一个能同时体现「架构演进 + 故障驱动 + 长期负责」的案例，比任何单一功能都有说服力。
A
02 · 社区业务线独立部署
S
单体架构里的一条业务线，和其它线互相拖累，也无法独立变现。
T
让它能独立部署、独立变现。
A
拆分预测模型 / 球员挖掘 / AI 机器人 / 单场解读 / 统计五大块业务；剥离 MySQL、MongoDB、Redis、Memcached 四套存储；变现接口独立域名、独立 Web 服务器。
R
从单体中切出一条可独立部署、独立变现的业务线。
证明我能做「拆」，不只是「加」。
A
03 · 会话存储 memcached 内存异常打满
S
全站登录态受影响，影响面最大。
T
从现象定位到根因。
A
排查到 memcached 升级后执行 flush 命令，再逐项排查禁用函数，最终收敛到升级动作本身。
R
解决后沿用至今，后续未再复发。
典型的「现象在 A、根因在 B」的排查案例。
A
04 · Redis 架构调整与飙升排查
S
三个核心业务服务共用 Redis，内存与连接压力集中。
T
拆读写、降压力。
A
配置从库与主从关系，完成三个核心服务的短连接切换；后续又定位「Redis 飙升」是大数据埋点异步队列堆积导致内存上涨，并做优化。
R
读写分离落地，内存上涨的根因被消除。
一次架构改造 + 一次根因排查，两件事串在一条线上。
A
05 · 数据库性能治理（面，不是点）
S
慢查是救火式地修，反复出现，修不完。
T
把「点上的优化」变成「面上的治理」。
A
6 台+ MySQL 全表扫描 SQL 分析，输出 P0–P3 分级报告；发现 98.4% 是监控 / 元数据类 SQL；内容统计宽表单次扫描近 49 万行定级 P0；访问日志库 visit_data 过亿行做实时聚合改造；MongoDB 跨大版本升级。
R
从「救火式修慢查」升级为「体系化治理」。
这是从「能干活」到「能定标准」的分界线。
A
06 · 支付体系搭建与统一
S
多业务方支付链路分散，订单号与对账口径不统一。
T
统一起来，且要能扩展新的营销玩法。
A
汇付线下支付设计 → 微信收付通 → 苹果内购兼容 → 立减金 → 首单折扣（1 期 + 2 期倒计时）；订单号统一加 partner 区分业务方；支付宝通知延迟捡漏从 5 分钟改到 3 分钟。
R
首单折扣单日占订单 40–50%，立减金促活 2025 人。
支付是最不能出错的地方，四年里没有出过资金事故。
没做成的五件事
这部分公开反而加分
MISSES
✕
企微 SaaS 平台
上线后未使用
开发周期最长、损失最大——前期产运调研不足
✕
赛事宣传·全国赛事票上传
上线没一会夭折
需求验证不足
✕
汇付商户进件申请
未上线夭折
商务条件未谈拢
✕
CRM 标签管理
上线后未使用
没有落到具体使用场景
✕
苹果推荐内购支付
上线后未使用
场景与渠道不匹配
共性是前期产运调研不足——技术上都能做，但没人用。这件事之后我做需求前会先问一句「谁在什么场景下，多久用一次」。
证书与下一步
补短板的具体动作
NEXT
全媒体运营师证
2023-11-22
已取得
演出经纪人证
2025-07-01
已取得
下一步
→
积极参与晋升，争取成为团队里能扛架构的人
→
抽身统计和基础需求的泥沼，多参与设计和复杂功能思考
→
补齐软件开发理论短板（自评仅 2.5）
可直接复制的自我介绍
投递 / 沟通时直接用，已脱敏
COPY
数据版自我介绍
四年后端，主 PHP。在一家体育赛事 SaaS 从零做到多条业务线的核心开发： · 把 C 端日均 UV 从 1 万做到 4–5 万，B 端店铺日均使用从 500 家做到 2000 家 · 接手推荐业务后，周末日均流水稳定在数万元量级 · 后期转向架构治理：主导一条业务线的独立部署（业务 + 四套存储剥离）、Redis 主从读写分离、MongoDB 跨版本升级、6 台+ MySQL 全表扫描治理 · 累计交付 70+ 个需求（截止 2026.10），近半年 150+ 个事项（2025.12—2026.06 归并 25 个模块）
我最能讲的三件事
- 赛事数据同步做了三代架构（HTTP → MQTT → 长连接轮询），每一代都是被真实故障推着改的
- 会话存储 memcached 内存打满的排查——从现象到禁用函数，最后落到根因
- 把数据库治理从「救火式修慢查」做成「P0–P3 分级体系」
我也愿意讲没做成的
企微 SaaS 平台是我投入周期最长、最后没有用起来的项目。归因是前期产运调研不足，不是技术问题。这件事之后我做需求前会先问一句「谁会用、用在哪」。