主导公司混合云平台（AWS+阿里云+自研私有云）的稳定性建设、成本精细化管控及自动化运维体系迭代，覆盖从基础设施编排到应用层容灾的全链路运维，对核心业务（电商交易、会员系统）的云平台可用性负责

• 针对核心交易链路跨AWS与阿里云调用延迟高（120ms）的问题，主导使用AWS CloudWatch全链路追踪与阿里云ARMS应用监控联动，结合自研拓扑分析工具定位到跨云VPC peering路由策略不合理导致的丢包，通过调整BGP Anycast节点部署与路由优先级，将跨云延迟降至40ms以内；同步优化云厂商间的 peering 连接带宽（从1Gbps扩容至2Gbps），全年核心链路故障时长从11小时压缩至1.5小时，支撑双11大促期间交易成功率提升至99.98%
• 牵头梳理全公司云资源 inventory（覆盖AWS EC2/S3/RDS、阿里云ECS/OSS/RDS、私有云OpenStack节点），使用Python开发自动化资源回收脚本（集成AWS Lambda与阿里云函数计算），结合“30天未使用”标签策略，每月自动回收闲置EC2实例（月均15台）、未释放EBS卷（月均8TB）及空闲OSS Bucket（月均3个），年云资源成本降低28%（约120万元）
• 推动私有云平台自动化能力升级，采用Terraform实现OpenStack节点（计算/存储/网络）的Infrastructure as Code（IaC）编排，将新节点部署时间从4小时缩短至30分钟；引入Argo CD搭建应用配置漂移检测体系，关联GitLab CI/CD pipeline，实现配置变更实时校验与回滚，配置变更成功率从92%提升至99.5%，减少因配置错误导致的业务中断事件80%
• 设计跨云双活容灾架构（AWS北京 region + 阿里云杭州 region），针对核心MySQL数据库采用AWS DMS与阿里云DTS实现双向数据同步（延迟<1秒），结合自研故障切换脚本（基于Shell+API调用），实现RTO<3分钟、RPO<10秒；通过年度灾备演练（模拟AWS北京region电源中断），验证容灾切换流程有效性，满足金融级容灾合规要求

负责公司AWS云平台（us-west-2、cn-north-1 region）日常运维，涵盖EC2、S3、RDS、CloudFront的全生命周期管理，支撑电商主营业务的大促活动与常态化运营

• 为应对618大促流量峰值（预测12万QPS），使用AWS Auto Scaling Group结合CloudFormation模板实现EC2实例弹性扩容，基于过去3年大促流量趋势优化扩缩容策略（提前30分钟启动预热实例），大促期间支撑峰值QPS 13.2万，实例CPU利用率保持在60%-75%的健康区间，可用性达99.99%，未出现因容量不足导致的业务中断
• 解决S3存储成本高企问题（月均存储费用占比25%），通过S3 Intelligent-Tiering自动将冷数据（30天未访问）迁移至Glacier Deep Archive，结合CloudFront CDN优化静态资源（图片/JS/CSS）分发，将图片平均加载时间从2.5秒降至0.8秒，同时月存储成本降低15%（约35万元）
• 处理RDS MySQL主节点宕机事件（因可用区网络波动），优化故障转移策略：将只读从节点迁移至同region的另一可用区，设置同步超时阈值为10秒，故障转移时间从5分钟缩短至1分钟，且数据一致性达100%；后续推动RDS多可用区部署标准化，覆盖所有核心数据库实例
• 搭建AWS云监控体系，用CloudWatch Alarms整合EC2 CPU/内存/磁盘使用率、RDS连接数/慢查询、CloudFront缓存命中率等指标，自定义Dashboard实现“全局-业务线-实例”三级可视化；报警响应时间从15分钟降至5分钟，全年处理12起潜在故障（如EC2磁盘满容、RDS连接泄漏），均未影响业务

协助维护公司阿里云平台（cn-hangzhou region）基础设施，包括ECS、OSS、RDS的日常监控、故障排查与容量管理，支撑公司官网与小程序的业务运行

• 排查ECS实例（ecs.t6-medium）频繁重启问题（日均2次），通过阿里云日志服务（SLS）采集系统日志与dmesg信息，定位到Linux内核（4.19版本）的OOM Killer机制误杀进程（因内核漏洞导致内存统计偏差），升级内核至5.4版本并打补丁后，3个月内无重启事件，实例稳定性提升95%
• 优化OSS静态资源访问速度，启用跨区域复制功能将资源同步至华北2（北京）区域，结合CDN节点覆盖全国，将用户平均访问延迟从300ms降至150ms；同步设置OSS生命周期策略，将超过6个月的资源转存至归档存储，月存储成本降低10%
• 协助搭建RDS MySQL监控体系，用CloudMonitor设置慢查询报警（执行时间>1秒）与连接数阈值（>80%最大连接数），每周生成慢查询报告并推动开发优化，累计优化5个高频慢查询（如订单列表查询），将查询时间从5秒降至1秒，数据库QPS提升25%
• 参与官网小程序大促保障，提前1周检查ECS实例CPU使用率（峰值70%），扩容20台t6-large实例；大促期间官网访问量提升5倍，无 downtime，可用性达99.9%，支撑活动GMV突破1000万元

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

• 星途直播作为公司核心业务，承载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万元。这段经历让我从商业小白成长为能设计闭环模式的实践者，项目不仅获省级创业金奖，更被纳入学校官方服务体系延续至今。