主导公司混合云平台（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万元

文娱业务低延迟高可用运维平台研发及规模化落地

• 项目背景：公司文娱业务（直播、长视频、会员系统）用户量年增长40%，现有运维体系存在工具碎片化（分散的监控、配置、自动化工具）、故障排查耗时（平均45分钟/次）、资源成本超支（年度服务器成本占比营收18%）等痛点。核心目标是构建统一运维平台，实现“高可用保障、低延迟监控、自动化运维”，支撑业务快速迭代。我作为运维开发负责人，主导平台整体设计、跨团队需求对齐及落地推进。
• 关键难题与技术方案：a) 多环境配置一致性难——传统手动配置易出错；b) 直播流低延迟监控缺失——传统Prometheus 60秒采集间隔无法满足端到端≤500ms延迟的实时追踪；c) 故障自愈覆盖不足——高频问题（如Pod重启、数据库连接池耗尽）仍需人工干预。针对性方案：采用Terraform+Ansible组合实现配置代码化；自研直播流延迟Exporter，整合CDN日志、应用埋点及网络探针数据，将采集间隔缩短至10秒；基于Python开发20+高频故障自愈剧本，联动告警系统自动修复。
• 核心行动与创新：牵头组织研发、产品、运营3轮痛点调研，输出《运维痛点清单》及需求文档；设计“配置管理-监控告警-自动化运维-成本分析”微服务架构（Spring Cloud）；带领5人团队完成Exporter开发、Terraform模板编写及自愈剧本调试；推动预发环境1个月灰度验证，再逐步推广至生产核心业务。
• 项目成果与价值：平台上线6个月覆盖80%核心业务，故障排查时间降至8分钟内，自动化率从35%提升至75%；年度服务器成本降低22%（约节省1200万元），支撑“暑期直播季”零重大故障，用户观看延迟降低15%。我个人主导的平台架构获公司“年度技术创新奖”，成为新业务运维标准底座。

短视频核心服务容器化迁移与弹性伸缩体系搭建

• 项目背景：公司短视频业务爆发（月活从1亿增至3亿），传统虚拟机部署存在资源利用率低（30%）、扩容慢（15分钟/次）、交付周期长（每周2个服务）等问题。核心目标是将feed流、视频上传等核心服务迁移至Kubernetes，构建弹性伸缩体系。我作为运维开发核心成员，负责容器化适配、弹性策略设计及迁移落地。
• 关键难题与技术方案：a) 老服务（Spring Boot 1.x）依赖本地文件系统及固定IP，迁移后服务发现失败、日志丢失；b) 流量波动大（热点事件QPS暴涨5倍），传统CPU指标HPA无法满足快速扩容；c) 迁移需保障业务连续性。解决方案：用Helm打包服务，定制化NFS解决文件依赖，通过Istio实现服务发现；构建多维度弹性指标（QPS+延迟+错误率+CPU），自定义HPA策略将扩容阈值从“CPU≥70%”调整为“QPS≥1万且延迟≥2秒”；制定“灰度迁移+回滚预案”，开发迁移状态监控面板。
• 核心行动与创新：对12个核心服务做容器化评估，输出《迁移可行性报告》及“先易后难”路线图；开发自动化工具将虚拟机配置转为K8s YAML，减少人工错误；压测验证伸缩效果，调整指标权重；推动研发优化代码（增加缓存、减少DB连接）提升容器性能。
• 项目成果与价值：3个月完成12个服务迁移，资源利用率从30%升至65%，扩容时间降至2分钟内；支撑峰值QPS从5万提至20万，无扩容故障；运维人力成本降低40%（原3人部署现1人自动化完成）。该弹性体系成为公司K8s集群标准配置，后续新服务默认采用。

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