负责公司混合云（阿里云+私有云）平台全生命周期运维，涵盖K8s集群管控、跨云资源编排、大促高可用保障及云成本优化，支撑电商业务峰值20万QPS的核心场景。

• 主导设计混合云K8s集群架构，基于Terraform抽象跨云资源模型，开发自定义Provider解决阿里云ECS与私有云OpenStack实例参数差异问题，实现‘一套代码多云部署’；集群部署耗时从4小时压缩至45分钟，多环境配置不一致故障率下降60%。
• 为应对双11流量洪峰，引入KubeFed实现跨AZ服务联邦调度，结合Prometheus自定义告警规则（覆盖节点负载、Pod驱逐风险等12类指标），并通过HPA+CA动态扩缩容；大促期间集群可用性达99.99%，较去年同期提升0.9个百分点，未发生因运维问题导致的业务中断。
• 推动云成本深度优化，基于AWS Cost Explorer与阿里云账单分析，将70%的EC2实例从按需付费转为3年预留+Spot混合模式，同步落地Karpenter自动扩缩容工具；年度云成本降低35%（约280万元），同时通过优先级队列+快速重建机制将Spot实例中断导致的业务影响控制在0.1%以内。
• 牵头搭建云原生可观测性平台，集成OpenTelemetry SDK采集指标/日志/链路数据，定制Grafana仪表盘覆盖商品详情、订单支付等90%核心链路；结合Thanos实现监控数据长期存储与聚合查询，故障定位时间从平均30分钟缩短至5分钟内，存储成本降低40%。

负责公司私有云平台（基于OpenStack改造）日常运维，支撑内部OA系统、商家SaaS服务及测试环境，聚焦稳定性保障与自动化能力构建。

• 核心参与‘OpenStack向K8s迁移’项目，制定分批次迁移策略（先非核心服务后交易类服务），使用Velero完成300+存量服务的无状态迁移，迁移后资源利用率从30%提升至60%，单服务运维人力投入减少50%；针对MySQL等有状态服务，开发Operator兼容旧存储卷挂载逻辑，确保业务零感知。
• 构建自动化运维流水线，基于Ansible编写角色模板（含CentOS初始化、Nginx/Tomcat部署、防火墙配置），集成Jenkins实现‘代码提交-测试-上线’全流程自动化；故障恢复时间从2小时缩短至15分钟，人工操作失误率下降85%。
• 优化监控体系，部署ELK Stack集中管理500+服务器日志，配置Logstash过滤规则提取‘支付超时’‘接口500错误’等业务关键词，结合Alertmanager设置分级告警（P0级5秒推送钉钉群）；重要故障发现时效从1小时提升至2分钟内，客户投诉率下降25%。

负责公司物理机与VMware虚拟化平台运维，保障研发测试环境及生产系统稳定，积累基础运维与问题排查经验。

• 主导搭建VMware vSphere虚拟化平台，规划8节点ESXi集群、vSAN分布式存储及VRRP网络策略，支撑500+虚拟机运行；通过HA（高可用）与DRS（动态资源调度）配置，年故障停机时间少于2小时，达到SLA 99.95%要求。
• 开发Python脚本自动化创建虚拟机模板（预装CentOS+GitLab+Jenkins），并集成到自研运维平台；测试环境交付周期从3天缩短至4小时，研发团队迭代效率提升30%。
• 建立容量管理机制，每周分析CPU/内存/存储使用趋势，结合业务上线计划预测资源需求；提前3个月完成服务器扩容，生产环境资源冗余率从40%降低至15%，年硬件采购成本节省约80万元。

星途直播平台全链路可观测体系重构与智能化升级项目

• 星途直播作为公司核心业务，承载1.2亿月活用户，原可观测体系存在“分散化”痛点——Metrics用Prometheus但无统一规范、Logs依赖ELK检索慢、Traces未打通跨服务链路，导致故障MTTR平均12分钟，严重影响用户体验。我的核心目标是主导重构覆盖Metrics、Logs、Traces的全链路可观测体系，将MTTR降低至5分钟内，同时支撑业务快速排查问题。
• 项目遇到三大关键挑战：1）跨50+微服务的链路追踪一致性差，TraceID传递无统一协议导致链路断裂；2）高Cardinality指标（如用户ID、直播间ID）导致Prometheus存储成本月均增长25%；3）Logs与Traces/Metrics无关联，排查时需手动匹配多系统数据，效率极低。我选择基于OpenTelemetry构建统一观测底座，用Thanos解决长期存储与查询性能，用Loki替代ELK实现日志标签化索引。
• 我的核心行动包括：1）牵头成立“可观测专项组”，联合研发、产品制定《OpenTelemetry接入规范》，改造12个核心服务SDK，强制注入TraceID并打通跨系统传递，解决链路断裂问题；2）设计“指标分层体系”——将指标分为基础资源、服务性能、业务转化三层，对高基数指标采用“哈希降维+定期聚合”策略，配合Thanos压缩存储，将Prometheus存储成本降低40%；3）整合Grafana搭建“故障排查一站式Dashboard”，联动Traces拓扑、Metrics趋势、带TraceID的Logs详情，实现“点击链路节点即可看关联日志与指标”。
• 项目成果显著：1）MTTR从12分钟降至2分40秒，故障定位效率提升76%；2）可观测覆盖度从60%提升至95%，所有核心服务、数据库、中间件均纳入监控；3）存储成本年降约35万元，同时支撑了“暑期直播节”等大型活动0级故障；4）业务侧直播卡顿率下降15%——通过可观测体系快速定位到转码服务CPU瓶颈，优化集群资源分配后支撑了单直播间100万并发观看。我个人也沉淀了《互联网直播场景可观测体系设计手册》，成为公司后续项目的参考标准。

星途直播弹幕系统高可用改造与弹性伸缩优化项目

• 星途直播弹幕系统承担着每场直播的实时互动需求，但在“年度盛典”“热门剧综直播”等场景下，常因并发量突增（峰值超10万QPS）出现延迟、节点宕机，导致用户互动率下降20%。我的目标是重构弹幕系统的高可用架构，实现“弹性伸缩+零感知扩容”，支撑百万级并发弹幕。
• 项目难点在于：1）弹幕服务虽无状态，但依赖用户在线状态服务（同步延迟达30秒），扩容时需等待状态同步，导致新节点无法立即承载流量；2）传统轮询负载均衡策略导致热点直播间节点压力过大，常触发熔断；3）K8s HPA的默认伸缩指标（CPU利用率）不准确，要么过度扩容浪费资源，要么扩容不及时导致故障。
• 我的解决路径：1）主导“状态剥离”改造——将用户在线状态从弹幕服务迁移至Redis Cluster，实现服务无状态化，扩容时仅需增加节点无需同步状态；2）改用Nginx Plus的“一致性哈希负载均衡”，基于直播间ID哈希分配请求，减少热点节点的压力；3）开发“自定义Metrics Adapter”——将“弹幕发送速率”“消息队列长度”等复合指标暴露给K8s HPA，实现“基于业务场景的精准伸缩”。
• 项目落地后效果明显：1）弹幕系统QPS从5万提升至20万，并发能力增长300%；2）扩容响应时间从5分钟缩短至1分钟，支撑了“年度盛典”直播的120万并发弹幕；3）弹幕延迟从2秒降至500毫秒以内，用户互动率提升22%；4）资源利用率提升35%——精准伸缩避免了30%的闲置节点成本。这个项目让我从“被动运维”转向“主动设计高可用架构”，也积累了处理“无状态服务状态依赖”的关键经验。

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