见微知著：业务_技术双轮驱动的稳定性实践 - 林万境

见微知著：业务/技术双轮 驱动的稳定性实践 林万境 个人简介 林万境阿里巴巴资深技术专家 •十五年互联网行业技术架构、运维SRE体系建设老兵，早期就职游戏公司，经历了从刀耕火种到业务井喷下的运维自动化体系建设及落地； •先后就职UCloud、阿里云，经历了云技术快速发展的关键时刻，有丰富的云运维devops经验，长期专注互联网各行业技术运维、服务保障工作。 •聚焦电商、泛娱乐、游戏、教育、泛企业等行业客户，打造结合客户业务及云上最佳实践方案、赋能，擅长甲乙方视角行业架构、云实践、疑难问题攻坚等。 •掉过很多坑，填过坑也造过坑，避过坑，追求以“技术洞见”造就业务一片坦途。 业务/技术发展阶段及痛点 围绕问题的行业技术实践 大纲 SRE工程化稳定性体系建设 AI智能化实践引路 聊运维，先从一条曲线开始 业务/技术 时间/人 01 业务/技术发展阶段及痛点 业务/技术发展阶段及痛点 业务不间断业务模式多样 C/B端业务 故障影响重，处理被动架构容灾能力被挑战压测，故障演练 电商秒杀、发红包大促等场景游戏新项目上线、版更活动等大数据搜推，智能货柜 视频直播/点播场景 围绕上下游用户的技术支撑技术与业务拓展怎么融合 如何开放能力，业务如何互补 新兴技术 AI大模型 大算力，多模态技术在未来 技术转换快运维自动化 数实结合的转型实践 现有IT基础架构和云化架构融合高速公路上换轮胎能力 提高效率，实现自动化降低成本，TCO需求 故障自愈能力，前置价值 02 围绕问题的行业技术实践 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 从页游到手游，从IDC到云，游戏行业技术变革实践 网络游戏技术演进下的快稳准 1.0–端游为王阶段 业务演进，CS架构 2.0–页游快阶段 变革萌芽期，快速上线，IDC为主，ALLINON架构 3.0–手游竞争阶段 创业期上线快，加速云化，稳定 最最关键 4.0-手游格局阶段 大作精细化、新游运维、版更，稳定先进性，标准化 1996-2006 2007-2012 2013-2020 2021–2024 业务快速增长下，技术总在追赶 回到2009年，从一款爆款快速扩充上线说起，网页游戏盛起的年代，某游戏一夜爆火，日均开服量暴涨500%，传统运维模式问题挑战多，高速公路换轮胎。 IDC运维时代遇到的问题 •传统部署模式：IDC托管、现场装机、命令行方式部署 •传统操作系统：早期大量的windows系统 •传统游戏架构：LNMT架构，“ALLINONE” •数据灾难不可恢 •故障影响重，大R上门 •…… 1 先扛住再优化 2 人肉规范化、去windows化 运维自动化 3 脚本+CRT并发模式、Ansible 高可用化 备份容灾、架构优化 繁复是运维的耻辱，自动化是昂起的头颅 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 可能的问题 技术不可控 云上黑盒 排查效率低 新技术水土不服 业务快速增长下，技术总在追赶 2012年，运维在合服回收数据库的一次“dropdatabasexx”误操作带来的云认知和思考，故障不可避免，可怕的是只能依赖别人。 故障出现 云云网网络络 网络异常 系统底层 应用异常 数据异常 数据状态 快恢协助 变更异常 可能的场景 1.玩家游戏内操作卡，网络问题自排止步于现象 2.故障业损期，自查许久才发现自己没问题，联合云的排查大量串行 3.业务发展到一定阶段触发某些不可 知云产品瓶颈导致业务故障 4.数据误操作，本地没有实时备份 技术转化前提是稳定，技术结合是基础 进入云时代，让运维工作模式发生变化，云视角下的业务/技术结合是痛点，运维因子变多、范围变广，如何在云上更稳定是该时期最大的挑战。 云产品稳定≠业 务稳定性 通用最佳实践<业 务最佳实践 稳定性建设投入> 业务预期收益 三个矛盾三个坚持 云运维的本质是换位，从“车上看路”到“路上看车”的思维转变。 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 主动运营是稳定性的核心逻辑 治未病ICU 康复 故障跟踪健康管理架构梳理工具巡检性能压测 容量管理业务监控稳定评审故障演练技术保障 实施元件 事前先于故障，主动运营，规避问题 事中业务优先，业务逃逸 基于原子化工作形成结论化技术导向 事后以点带面，复盘总结 已知问题以点带面，由表及里辐射治理可能的隐患；架构梳理结合场景洞察技术隐患和实施最佳实践，主动巡检。 业务快恢能力，业务逃逸、技术容灾。关键依赖前置演练。 一个问题的结束只是开始，复盘总结不再重复出现。关键依赖actions落地。 系统性、工具化支撑主动运营 工程化支撑 技术保障标准化，从不确定实践提炼确定性 业务项目规模化后的技术保障诉求必然是规范化、标准化，保障结果必然是确定性、前置化，战前忙碌、战时平稳、战后归纳， 集团军模式遍地开花。 游戏衰退期 游戏稳定运营期 游戏开服上线期 游戏封测期 项目阶段 业务语言 游戏立项研发期 游戏事件 •版号申请 •游戏业务架构 •游戏开发语言 •游戏玩法 技术翻译 •上线玩家平台/区域 •云产品选型 •封测业务数据 •用云问题 •开服推广形式（直播/广告等） •预估DAU、PCU指标 •玩家次日留存，7日留存 •游戏内功能BUG情况 •充值情况 •游戏版更 •运营活动 •多游戏渠道拓展（云游戏/网页版） •配套游戏周边活动/粉丝见面会 •平台账号/安全治理 •游戏服活跃度下滑 •成本优化 反哺业务 标 准•定义保障级别 方 案•技术栈匹配 库•技术风险识别 技术语 言技术 交游戏业务信息收集表 付技术风险识别表 •项目档案沉淀 •架构及资源选型方案 •运维问题/需求 •技术风险识别 •架构风险识别 封测关键问题&需求汇总表 业务架构/云产品识别风险表 •核实项目关键信息 •制定上线计划及分工 •资源报备/开通 •监控建设方案 •配置基础监控 •业务全链路性能压测 •容灾方案设计与演练 •游戏业务风险预案 核心资源列表 云产品巡检表 压测/容灾演练报告 风险预案/降级预案 故障应急、稳定性治理、技术保障标准体系化，追求永不中断的游戏业务 技术封网 •安全防护方案 •资源风险巡检 •游戏业务风险巡检 •变更封网 •CDN预下载保障 •游戏开服应急响应 •OB上线复盘总结 监控大屏 云产品基础监控 机器人播报 •资源需求报备 •CDN预热保障 •数据库高效备份 •游戏版更应急 •云游戏资源管理 游戏版更checklist 运维月报告 AK巡检报告 云游戏资源报告 技术测试跟进报告 •AK治理 •业务稳定性建设 •Devops建设 •新技术需求功能测试 •资源在线扩容 Devops体系建设 重大活动保障 •资源TCO分析 •资源使用率指标巡检 •业务改造/技术调研 •项目下线支持 成本优化方案 业务技术改造建 议 字体 红色SS级及以上完成 黄色 字体 S级及以上完成 蓝色 字体 AB级及以上完成 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 电商进入弹性时代，高并发大促保障 电商规模化成本，弹性是技术最优解 电商流量拥有天然潮汐特性，IDC托管-属于最大资源供应形态，托管按需扩容-有储备的成本，相对于前两者云上弹性在供需关系、扩容时间上有显著优势。 储备成本N++ 1月++ 提效降本 电商红包秒杀的业务实践，早期保障往往从问题开始 双十一、双十二、店庆等多样性带来带宽波峰较为明显，服务压力是平常的数十、百倍甚至千倍，异常影响也是指数级。 秒级高并发 600+个LB 弹性主机横向扩展 公共DB 业务挑战 保障策略 实现价值 •业务高并发，并发可能带来不可知技术瓶颈 •业务架构耦合度较高，故障引发连带效应 •调整架构时间有限 •梳理业务运营思路和技术匹配逻辑 •LB的CPS性能压测，独享资源集群 •关键业务模块拆分，分散性能及单点故障，启用泳道隔离故障方案 •数据层CACHE缓存及分库、分表 •压测、降级预案准备，后续的架构优化落地 •红包活动保持每天至少300%的用户量增长，实现APP日活增量提升将近8倍 •架构能力优化，为后续打下技术基础 •打磨适配的保障常态化工作 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 全链路压测 异地多活 故障演练 线上管控 电商技术保障checklist 阶段 工作项 描述 验证情况 准备期 业务调研 保障目标，业务活动情况等 Y/N 架构梳理 应用架构、部署架构(业务流+数据流) Y/N 系统评估 业务体量预估映射为系统性能、容量目标 Y/N 规划期 保障团队组建 组成各部门甚至包括协同供应商联合保障团队 Y/N 环境构建 构建业务系统、或已有系统的改造 Y/N 实施期 全链路压测 压测环境构建，场景构建，单接口&单链路&全场景压测 Y/N 性能分析及优化 基于压测的性能分析、瓶颈优化实施，直至达到系统目标 Y/N 风险评估及优化 架构、可用性、安全等风险的评估及优化实施 Y/N 流量防护方案 对于超出系统容量业务的防护措施，即限流方案 Y/N 降级方案 主业务链路保护，可降级链路、服务、模块等方案及实施 Y/N 容灾方案 接入层、应用层、数据层，地域/单可用区级别的故障容灾方案实施 Y/N 预案演练 完成上述限流、降级、容灾等预防的演练 Y/N 收尾期 保障过程监控 资源监控、业务监控、告警播报方案等 Y/N 应急保障 临场应急 Y/N 复盘总结 保障总结报告，总结沉淀 Y/N 围绕问题的行业技术实践TIPS 见微知著 •快速变化的业务，运维大量时间投入在繁复被动支持工作 •当前运维能力有限（个人/团队） •故障较多，都是没见过的问题 •从0到1后，1到100只能靠堆人 •大量时间投入在故障应急，“坑”源源不断 •大型活动保障都是被动救火 •不出问题没人知道运维做了什么，“运维没有价值？” •架构推动不了研发改动，现状不允许 •保持SRE工程化思维，先扛住再优化，扛住是过程优化才是目标 •已知故障复盘，以点带面、举一反三 •主动运营，至少60%时间投入事前 •规范化、标准化、脚本化、工具化、自动化五步法则 •透过表象看本质；通过局部看整体；围绕现在看未来 •业务拆解技术动作，技术回归业务价值 •做稳定性一号位，从挨打到执鞭人转变 •没有绝对的高可用，只有价值互惠 03 SRE工程化稳定性体系建设 SRE工程化关键原则 、 •运维架构设计原则：架构N+1设计，可回滚、可禁用、可降级，实现多业务模块、多架构高可用； •可观测性原则：确保核心指标、核心链路可监控，通过采集业务指标日志、追踪等数据。开天眼在问题发生之前发现问题； •全链路压测原则：通过与可观测性、混沌实验能力的深度整合，实现模拟真实业务环境全链路压测，达到业务上线前的精准资源评估，主动发现潜在性能、版本缺陷等问题； •GOC应急原则：故障不可避免，需要不断去提升MTBF（平均无故障工作时间），降低MTTR（平均修复时间）。制定标准化GOC应急机制，保障事中快速发现、分析、定位与解决问题； •主动运维原则：故障探测、故障压测、故障演练、主动架构优化等事 前的大量混沌实验、故障预案，主动巡检、容量管理等工作，实现风险规避以及打造故障逃逸等能力； •自动化运维原则：DevOps、AiOps等方向，对人肉工作进行标准化、 规范化改造，从而实现自动化。 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 阿里巴巴稳定性保障体系 阿里巴巴云上业务稳定性保障全貌 04 AI智能化实践 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 AI的出现，会取代运维吗？ 基于大模型的应用场景 智能编码 ChatBI 知识库问答 AIOPS 广告营销 结构化数据 Chains 文档 Pro