负责公司核心交易链路MySQL集群（支撑日均1.2亿订单量）的全生命周期管理，涵盖性能瓶颈攻坚、异地多活容灾架构设计、故障根因定位及研发侧数据库规范赋能，边界是保障数据库99.99%可用性与大促期间的弹性扩展能力

• 主导核心订单库（MySQL 8.0）大促前性能优化，面对QPS从8万飙升至15万时慢查询激增（占比12%）的问题，使用pt-query-digest分析慢日志定位到订单详情表联合索引失效及批量插入锁竞争；通过重构覆盖「订单状态+用户ID+创建时间」的复合索引，将批量插入改为分批次异步提交，慢查询率降至1.5%，大促期间数据库RT稳定在80ms内，支撑1.5倍预期订单峰值
• 设计华东-华南双机房异地多活架构，基于MySQL Group Replication实现跨机房数据同步，结合ProxySQL做读写分离与流量路由；解决同步延迟导致的脏读问题，通过调整group_replication_member_weight参数+启用半同步复制，将延迟从500ms压至50ms内，完成3次机房故障演练，RTO从45分钟缩短至12分钟，实现业务零宕机切换
• 推动数据库自动化运维体系建设，用Ansible整合部署/备份/监控流程，新库上线时间从4小时压缩至30分钟；引入Prometheus+Grafana搭建实时监控平台，自定义InnoDB缓冲池命中率、锁等待次数、复制延迟等指标，异常自动告警将故障定位时间从1小时缩至15分钟，全年数据库可用性达99.99%
• 赋能研发团队规范落地，主导制定《电商业务数据库设计手册》（含索引/分库分表/SQL编写规范），通过季度培训+技术评审，将研发侧慢查询占比从30%降至8%，减少生产环境非必要压力，间接提升应用响应速度20%

负责零售业务MySQL/Redis集群的日常运维，涵盖稳定性保障、性能调优及数据安全管控，边界是支撑日均3000万用户行为数据的存储与查询需求

• 重点优化用户行为日志库（MySQL 5.7）写入性能，面对日均2000万条日志写入导致的磁盘IO瓶颈（利用率85%），调整innodb_flush_log_at_trx_commit为2（结合每日全量备份）+启用binlog压缩，写入TPS从1.2万提升至3.5万，IO利用率降至60%，同时保证RPO<5分钟的数据可靠性
• 解决分库分表后跨库查询问题，针对16个分库的用户订单数据，用ShardingSphere构建中间件层实现跨库聚合查询与全局唯一ID生成；优化分布式执行计划，将跨库查询响应时间从2秒缩至300ms，支撑营销活动用户订单统计需求
• 完善数据安全体系，部署Percona Audit Plugin记录所有DML/DDL操作，定期开展数据脱敏演练（对手机号/身份证号做AES加密存储），全年未发生数据泄露，通过公司信息安全合规检查
• 主导处理一次生产宕机事故，分析错误日志发现是innodb_buffer_pool_size过小（8G）导致内存溢出，快速重启实例+扩容至32G，结合备份恢复1小时内数据，业务恢复时间25分钟；后续推动自动化参数调优脚本开发，避免同类问题复发

协助资深DBA完成内部管理系统数据库运维，涵盖MySQL集群部署、备份恢复、监控告警及简单性能优化，边界是保障系统7×24小时稳定运行

• 负责OA系统数据库（MySQL 5.6）日常运维，制定「每日全量+xtrabackup每小时增量」备份策略，全年备份成功率100%；模拟数据丢失场景验证恢复流程，确保RTO<30分钟
• 优化审批流程表慢查询，添加「审批人ID+审批状态+创建时间」复合索引，将查询时间从5秒缩至500ms，提升员工审批效率30%
• 搭建Nagios监控平台，监控MySQL连接数/CPU/磁盘空间，设置80%连接数阈值告警，全年及时处理3次连接数飙升问题，避免数据库宕机
• 参与schema变更管理，审核研发SQL变更的索引合理性与事务长度，将变更导致的线上故障从每月2次降至0次，保障系统稳定性

分布式链路追踪系统深度优化与成本管控项目

• 公司业务从单一电商扩展至本地生活、直播等多领域，微服务数量1年内从800个增至1800个，原有Zipkin链路追踪系统出现核心查询延迟超5秒、月存储成本破120万元的瓶颈，无法支撑跨团队故障定位需求。我的目标是重构系统架构，实现“高性能查询+低成本存储”平衡，并适配多业务线可观测性要求。
• 项目面临两大技术挑战：一是原有Elasticsearch集群因按服务名分索引无时间序列划分，导致热点数据集中、查询IO过高；二是冷数据无分层策略，30天以上trace数据仍占用核心存储。我选择以OpenTelemetry统一数据采集，替代原有Zipkin SDK降低开销；针对ES设计“时间+业务线”二级索引，结合索引生命周期管理（ILM）实现自动化冷热分离。
• 我主导三项关键行动：1）开发自定义OpenTelemetry Exporter，过滤内部心跳等无效trace，采集量降低35%；2）重构ES集群为“年-月-日”时间分片+业务线标签路由，查询时通过时间范围快速定位分片；3）搭建冷数据迁移pipeline，将超30天数据同步至阿里云OSS，通过ILM自动清理核心集群过期数据。同时搭建链路数据质量监控平台，实时告警数据异常。
• 项目上线后，核心查询延迟从5.2秒降至180毫秒内，支撑100+并发无压力；月存储成本降至72万元，降幅40%；跨团队故障定位时间从45分钟缩至15分钟内。该系统成为公司可观测性平台核心组件，支撑直播、本地生活业务快速上线，我个人主导了公司可观测性标准制定。

电商大促场景下容器化资源弹性伸缩系统研发

• 公司电商大促期间流量峰值达日常5-8倍，传统Kubernetes HPA依赖CPU、内存指标，存在响应滞后问题——常出现“流量来了资源没跟上”或“大促后闲置”。我的目标是从0到1研发融合多维度指标的弹性伸缩系统，支撑资源精准调度。
• 难点在于定义“合理伸缩触发条件”：单一指标无法覆盖业务场景，多指标融合易冲突。我收集近3年大促数据，分析得出“订单队列长度+库存变更率+CPU利用率”组合指标最反映业务压力。技术上以Prometheus采集指标，Grafana可视化，通过自定义控制器联动Kubernetes API实现动态扩缩容；同时设计“预扩容”机制，大促前1小时基于历史流量预测模型提前扩容20%。
• 我核心行动：1）开发多指标加权评分算法，整合订单、库存、CPU指标设定动态阈值（如订单队列超1000且库存变更率>5%触发扩容）；2）用LSTM算法训练大促前7天流量数据，预测下一小时请求量，误差<8%；3）编写Kubernetes Operator实现指标采集-决策-调整自动化闭环。过程中优化镜像预加热和节点亲和性，将Pod启动时间从45秒缩至15秒。
• 系统上线后，大促资源利用率从35%升至65%，节省200+台ECS成本；故障次数从12次降至2次；支撑618期间12万QPS峰值，订单成功率99.95%以上。该项目成为大促保障核心工具，我因贡献晋升资深运维开发，后续推动系统推广至其他业务线。

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