负责公司核心交易、用户行为、日志三大类数据库集群的全生命周期管理，主导分布式数据库架构升级与自动化运维体系搭建，统筹跨部门数据库技术协作，保障日均10亿+请求、PB级数据量的数据库集群稳定性与成本效率。

• 主导完成MySQL向TiDB的分布式架构迁移项目：针对电商大促期间单库QPS突破8万导致的性能瓶颈，通过分析sysbench压测报告与慢查询日志（使用pt-query-digest定位TOP 100慢SQL），设计分库分表策略并重构应用连接池逻辑，迁移过程采用TiDB Lightning离线导入+增量Binlog同步方案，实现零数据丢失；迁移后集群读写QPS峰值提升至15万，存储成本降低40%，大促期间故障率从0.8%降至0.1%。
• 构建数据库自动化运维平台：基于Python开发部署脚本（集成Ansible Tower），实现从实例创建、参数配置、备份恢复到监控告警的全流程自动化；对接Prometheus+Grafana监控体系，自定义30+核心指标（如InnoDB Buffer Pool命中率、锁等待时长），结合机器学习算法预测容量峰值，提前72小时触发扩容提醒，全年避免因资源不足导致的业务中断事件12起。
• 优化多活容灾架构：针对华东-华南双数据中心同步延迟问题（原平均50ms），通过调整TiKV Region分裂策略与Raft Group副本分布，结合Zabbix自定义告警规则（设置延迟阈值30ms触发熔断），将同步延迟稳定控制在10ms以内；主导完成两地三中心容灾演练，RTO从2小时缩短至15分钟，RPO从5分钟降至30秒，通过信通院数据库容灾能力四级认证。
• 制定数据库开发规范与培训体系：梳理《慢查询优化手册》《索引设计指南》等6份技术文档，组织跨部门技术培训20场，推动业务侧SQL写合规率从65%提升至92%；建立SQL审核平台（集成Yearning），拦截高危操作（如无索引全表扫描、大事务）占比从35%降至8%，年减少生产环境故障30+次。

负责金融支付、会员服务两条核心业务线的数据库运维，支撑日活500万用户的交易与数据查询需求，重点推进数据库高可用改造与性能调优，保障SLA全年99.99%。

• 完成支付核心库从单集群到主备+读写分离架构升级：针对支付回调接口响应超时问题（原P99延迟200ms），分析发现从库负载不均衡（热点更新导致），通过调整GTID复制拓扑为级联复制，结合ProxySQL动态路由读请求，将主库CPU使用率从85%降至60%，接口P99延迟优化至80ms以内，支撑双11支付峰值1.2万笔/秒。
• 解决历史数据归档与查询性能矛盾：会员行为日志库累计数据量达800TB，常规查询耗时超30秒；设计冷热数据分层方案（使用TiDB TiFlash列存引擎存储历史数据），结合CronJob定时任务将3年以上数据迁移至归档库，查询平均耗时降至5秒内，同时节省主库存储成本35%。
• 主导数据库监控体系重构：替换原有Zabbix监控为Open-Falcon+Prometheus混合架构，新增InnoDB死锁检测、临时表使用量等20+关键指标，通过Grafana定制业务看板（如订单成功率关联数据库锁等待时长），实现故障根因定位时间从40分钟缩短至10分钟，全年重大故障响应效率提升70%。
• 推动数据库安全合规建设：梳理《敏感数据访问规范》，通过MySQL Enterprise Audit插件监控高危操作（如DROP TABLE、导出全表数据），结合Vault管理数据库账号密码，完成等保三级测评中数据库安全项零缺陷通过；全年拦截未授权数据查询事件5起，避免用户隐私泄露风险。

负责电商主站商品、订单、促销活动三类MySQL数据库的日常运维，支撑日均300万UV的业务需求，重点完成数据库日常监控、故障排查与基础优化，保障系统7×24小时稳定运行。

• 搭建数据库基础监控体系：使用Nagios+Percona Monitoring and Management(PMM)部署监控节点，配置QPS、连接数、慢查询数等15项核心指标告警阈值，结合企业微信机器人实现7×24小时告警推送；上线首月即捕获3次主库连接数暴涨事件（因业务代码未释放连接），通过调整wait_timeout参数与增加连接池最大连接数，避免业务中断。
• 优化大促期间数据库性能：针对618大促前商品详情页查询QPS预计增长200%的问题，使用sysbench模拟压测发现InnoDB Buffer Pool命中率仅65%，通过扩容Buffer Pool大小（从64G调整至128G）与优化热点商品缓存策略（将TOP 1000商品缓存至Redis），大促期间查询响应时间稳定在200ms内，未出现超时告警。
• 解决慢查询导致的数据库负载过高：通过pt-query-digest分析慢查询日志，定位到订单列表接口存在无索引的全表扫描SQL（执行耗时超5秒），协调开发团队添加复合索引（覆盖order_status、create_time字段），优化后该SQL执行时间降至50ms内，主库CPU使用率从75%降至55%，月均慢查询量下降80%。
• 完成数据库备份策略优化：原全量备份每日1次（耗时4小时）+ 增量备份每小时1次，占用存储空间3TB/月；调整为基于Binlog的物理备份（使用Percona XtraBackup），结合Restic压缩归档，将备份时间缩短至1.5小时，月存储成本降低50%，同时验证备份恢复RTO≤2小时，满足业务容灾要求。

星途游戏云原生全生命周期运维平台研发及规模化落地项目

• 星途互娱核心游戏业务从传统IDC向阿里云K8s集群迁移过程中，面临运维工具碎片化（分散在Jenkins、Zabbix、自建CMDB等系统）、故障排查耗时（平均45分钟/次）、发布效率低（单服务部署需15分钟）等问题。我作为平台核心设计者，目标是打造覆盖“部署-监控-故障自愈-容量规划”的云原生全链路运维平台，支撑10+款月活千万级游戏的稳定运营。
• 项目核心挑战有两点：一是混合资源管理——部分老游戏仍运行在OpenStack虚拟机，需统一纳管K8s Pod与传统VM的资源视图；二是故障根因定位慢——游戏故障常涉及“客户端-网关-逻辑服-数据库-第三方支付”多链路依赖，传统日志检索无法快速关联异常。
• 针对混合资源问题，我设计了“资源抽象层”技术方案：基于OpenAPI封装K8s与OpenStack的底层接口，向上暴露统一的“虚拟机/容器”资源模型，同时用Ansible Tower实现两类资源的配置同步，解决了跨环境的运维一致性；针对故障定位，我主导引入“链路追踪+日志关联”体系——用Jaeger采集全链路调用 trace，结合ELK Stack的Logstash插件将trace ID注入应用日志，开发了“故障溯源引擎”，支持输入用户投诉的“登录失败”症状，自动关联数据库慢查询、API响应超时、缓存穿透等根因。
• 项目上线6个月内，支撑完成12款游戏的全量云原生迁移：部署效率提升60%（单服务部署降至6分钟内），故障平均排查时间缩短至8分钟以内，全年减少因运维响应慢导致的用户流失营收约200万元。我个人主导了平台70%的核心模块开发（资源管理、故障自愈），并输出《星途云原生运维平台操作规范》，成为团队标准。

星途CDN智能缓存优化系统研发项目

• 星途互娱游戏分发依赖第三方CDN厂商，但存在两大痛点：一是缓存命中率波动大（日均70%-80%），突发流量（如新游上线）易导致源站带宽峰值超标；二是缓存策略依赖人工经验，无法适配不同游戏的内容热度变化（如MMORPG的大地图资源 vs 休闲游戏的轻量化素材）。我作为运维开发负责人，目标是构建“数据驱动的CDN缓存智能调整系统”，降低源站压力与带宽成本。
• 项目难点在于“实时性与准确性平衡”：CDN节点分布全球20+地区，需秒级采集流量、缓存命中、用户地域等数据，同时机器学习模型需准确预测不同游戏的“热点内容生命周期”（如某皮肤的上线热度期）。
• 我从三方面突破：1）数据 pipeline 搭建——用Flink实时消费CDN厂商API的流量日志，清洗后将“内容URL、访问频次、地域分布”等指标写入ClickHouse；2）模型优化——针对游戏内容“短周期热点”特点，放弃传统LR模型，改用LightGBM融合“内容类型、上线时间、用户画像”特征，预测内容的“未来2小时访问量”；3）自动化执行——开发Python脚本对接CDN厂商的管理接口，根据模型预测结果动态调整节点缓存TTL（如预测某资源未来1小时访问量将上涨50%，则延长TTL至2小时）。
• 系统上线后，CDN缓存命中率从75%提升至88%，源站带宽成本每年降低约300万元；同时支撑了《星途纪元》上线时峰值日活1200万的活动，未出现因CDN缓存失效导致的源站宕机。我主导了数据采集模块与模型落地脚本的开发，还优化了特征工程（新增“游戏版本更新时间”维度），使预测准确率从72%提升至85%。

• 因痛心于年轻人对历史的疏离，我在B站创立「古人脱口秀」栏目，用职场梗解构历史事件（如《雍正皇帝的KPI保卫战》）。通过设计「颠覆认知-史料佐证-现代共鸣」三幕剧本模板，单期视频最高收获1.7万条弹幕互动。
• 两年间栏目播放量突破180万，作品被多地中学选为教学素材。这段经历磨砺出将学术内容转化为大众语言的能力，也让我理解到真实用户反馈才是创作者的指南针。