负责公司直播+AI互动课堂系统的端到端DevOps体系建设，覆盖代码提交至生产部署全流程自动化，支撑日均10万+并发直播课的稳定迭代，推动研发、测试、产品跨团队DevOps文化落地

• 主导设计基于GitLab CI/CD + Argo CD的双流水线体系，针对直播推流服务高可用要求拆分“功能验证-性能压测-灰度发布”三阶段，集成Prometheus+Grafana实现部署实时监控，将单次生产部署时间从45分钟缩至12分钟，季度故障次数下降60%
• 核心参与AI互动课堂微服务容器化迁移，选用K8s进行资源编排，通过kube-state-metrics定位java服务堆外内存溢出问题，优化JVM参数并引入Sidecar容器监控GC状态，迁移后服务可用性从99.5%提至99.95%，资源利用率提升35%
• 重点优化跨团队CI/CD协作流程，推动研发接入SonarQube代码质量门禁（强制“圈复杂度≤15”“单元测试覆盖率≥80%”），同时打通测试环境Argo Rollouts渐进式发布能力，让测试团队实时验证灰度版本用户反馈，需求交付周期缩短25%
• 搭建基于ELK Stack的日志分析平台，针对直播课卡顿痛点设计“用户ID+直播间ID+时间戳”关联索引，结合Fluentd采集多服务日志，将问题定位时间从2小时缩至15分钟，支撑客服团队月均卡顿投诉量下降40%

负责公司K12在线题库系统DevOps基础建设，搭建自动化部署与监控体系，支撑系统从单体架构向微服务转型，保障百万级用户日常使用稳定性

• 独立搭建Jenkins CI/CD流水线，实现Java单体应用编译、单元测试、Docker镜像构建、阿里云ECS部署全自动化，将每日批量部署时间从2小时压至30分钟，减少运维人力投入40%
• 推动引入Zabbix作为基础设施监控工具，针对MySQL主从数据库慢查询配置日志采集与告警规则，定位索引缺失问题并优化，数据库QPS从1200提至2500，系统响应时间下降30%
• 设计实施基于Nginx加权轮询的灰度发布方案，将新版本流量从5%逐步提升至100%，配合日志验证功能正确性，将版本回滚率从15%降至3%
• 编写《DevOps操作手册》并推动团队培训，覆盖Jenkins维护、Zabbix告警处理、Docker镜像管理等，将新运维人员上手时间从1周缩至2天

负责公司官网及内部OA系统运维，逐步引入自动化工具减少重复劳动，探索DevOps实践支撑业务增长

• 自学Python编写服务器巡检脚本，将每周人工巡检CPU、内存、磁盘改为每日自动运行并生成HTML报告，将故障预警时间提前50%，减少非计划停机30%
• 推动官网从静态页面迁移至WordPress动态网站，搭建LAMP环境并配置Nginx反向代理实现动静分离，将首页加载时间从3.5秒缩至1.8秒
• 参与内部OA系统Docker化尝试，将PHP应用打包为Docker镜像实现快速部署与扩容，支撑员工从500人增长至1200人的并发访问，未增加服务器数量
• 协助研发搭建Git仓库并制定权限规则，推动代码提交规范落地，减少合并冲突次数，提升研发协作效率

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

• 项目背景：随着公司直播电商业务日活突破500万，原有基于Elasticsearch的链路追踪系统出现严重性能瓶颈——全链路查询延迟超8秒，月存储成本高达120万元，且因数据冗余导致故障定位成功率仅65%。我的核心目标是重构系统性能底座，建立科学的数据生命周期管理机制，支撑业务侧“秒级排障”的需求。
• 关键难题与技术：1）原有ES集群因无序写入和索引膨胀导致查询慢，传统分库分表无法解决海量时序数据的检索效率问题；2）数据保留策略一刀切（全存30天），无效数据占比达40%；3）多业务线标签体系混乱（如“用户ID”“商品ID”命名不统一），导致过滤条件命中率低。我选择ClickHouse作为冷热数据存储引擎（适配链路数据的列式存储与批量查询特性），结合Flink实现实时数据路由，同时引入“业务优先级+流量特征”的动态标签标准化方案。
• 核心行动与创新：1）主导设计“热数据（7天）存ClickHouse、冷数据（30天+）存OSS”的分层架构，用Flink根据请求频率（QPS≥1000的接口）和错误率（≥5%的链路）自动打标，将高价值数据留存热层，低价值数据归档冷层；2）优化ClickHouse索引策略，针对“traceID”“serviceName”“userId”等高频查询字段建立跳数索引，同时合并冗余的tag字段（如将“appVersion”“clientId”整合为“clientInfo”复合标签）；3）推动研发侧统一标签规范，新增“businessPriority”（业务优先级）标签，支持动态过滤低优先级链路（如测试环境的灰度请求）。
• 项目成果与价值：1）链路查询延迟从8秒降至1.2秒，故障定位成功率提升至92%；2）月存储成本从120万元降至42万元（降低65%）；3）支撑双11大促期间10万+并发链路的实时排查，未发生因追踪系统延迟导致的客诉；4）输出《分布式链路追踪系统数据管理规范》，成为公司全产品线的标准方案，我个人也因此晋升为运维开发组技术负责人。

容器化微服务集群全自动化运维平台研发项目

• 项目背景：公司从传统虚拟机部署全面转向Kubernetes，但初期依赖脚本和零散工具（如kubectl、Helm），存在“部署靠人工核对配置”“故障需手动排查”“扩容响应慢”等问题——单次微服务部署耗时超2小时，故障恢复平均30分钟，支撑不了业务快速迭代的需求。我的目标是构建“部署-监控-自愈”一体化的自动化平台，将运维从“救火”转向“预防”。
• 关键难题与技术：1）多环境（开发/测试/预发/生产）的配置差异大，容易出现“测试通过、生产报错”的问题；2）故障自愈依赖固定规则（如CPU≥80%重启Pod），无法处理复杂场景（如数据库连接池泄漏导致的偶发错误）；3）需与现有监控系统（Prometheus）、日志系统（ELK）打通，实现告警事件的自动流转。我选择K8s CRD（自定义资源定义）扩展平台能力，结合Ansible做配置管理，用随机森林算法训练故障预测模型。
• 核心行动与创新：1）设计“业务应用”CRD，封装部署所需的镜像、资源配置、环境变量等信息，通过模板引擎动态渲染多环境配置（如生产环境副本数是开发的2倍），实现“一次定义、多环境部署”；2）搭建故障知识库，收集过去1年的故障案例（如“MySQL慢查询导致API超时”“Redis缓存击穿”），提取特征（如QPS波动、错误日志关键词）训练随机森林模型，提前15分钟预警潜在故障；3）与监控团队合作，打通Prometheus Alertmanager，将告警事件映射为平台自愈动作（如“CPU高”触发扩容、“错误率超5%”触发Pod重启），并通过Webhook通知研发侧。
• 项目成果与价值：1）微服务部署效率提升70%（单次部署≤20分钟），配置错误率从15%降至2%；2）故障恢复时间从30分钟缩短至5分钟内，全年减少因运维延迟导致的营收损失约200万元；3）平台支持500+个微服务实例的自动化运维，运维人力投入降低30%（从8人减至5人）；4、平台成为公司核心运维工具，我也因此获得当年“公司技术创新奖”。

• 大二观察到毕业生离校时大量教材被废弃，而新生购书支出占生活费12%，便发起校园书籍教材循环计划。为解决传统二手书交易效率低的问题，我们开发微信小程序实现扫码估价、预约取件功能，并说服快递中心以成本价承接物流。
• 通过建立翻新消毒标准打消卫生顾虑，项目年流通教材1.2万册，累计为同学节省书费38万元。这段经历让我从商业小白成长为能设计闭环模式的实践者，项目不仅获省级创业金奖，更被纳入学校官方服务体系延续至今。