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

个人简介 林万境阿里巴巴资深技术专家 •十五年互联网行业技术架构、运维SRE体系建设老兵，早期就职游戏公司，经历了从刀耕火种到业务井喷下的运维自动化体系建设及落地；•先后就职UCloud、阿里云，经历了云技术快速发展的关键时刻， 有丰富的云运维devops经验，长期专注互联网各行业技术运维、服务保障工作。•聚焦电商、泛娱乐、游戏、教育、泛企业等行业客户，打造结合客户业务及云上最佳实践方案、赋能，擅长甲乙方视角行业架构、云实践、疑难问题攻坚等。•掉过很多坑，填过坑也造过坑，避过坑，追求以“技术洞见”造就业务一片坦途。 业务/技术发展阶段及痛点 围绕问题的行业技术实践 大纲 SRE工程化稳定性体系建设 AI智能化实践引路 业务/技术发展阶段及痛点 业务/技术发展阶段及痛点 业务不间断 C/B端业务 业务模式多样 围绕上下游用户的技术支撑技术与业务拓展怎么融合如何开放能力，业务如何互补 故障影响重，处理被动架构容灾能力被挑战压测，故障演练 电商秒杀、发红包大促等场景游戏新项目上线、版更活动等大数据搜推，智能货柜视频直播/点播场景 运维自动化 技术转换快 新兴技术 数实结合的转型实践现有IT基础架构和云化架构融合高速公路上换轮胎能力 提高效率，实现自动化降低成本，TCO需求故障自愈能力，前置价值 AI大模型大算力，多模态技术在未来 围绕问题的行业技术实践 从页游到手游，从IDC到云，游戏行业技术变革实践 网络游戏技术演进下的快稳准 1.0–端游为王阶段 业务快速增长下，技术总在追赶 回到2009年，从一款爆款快速扩充上线说起，网页游戏盛起的年代，某游戏一夜爆火，日均开服量暴涨500%，传统运维模式问题挑战多，高速公路换轮胎。 I D C运 维 时 代 遇 到 的 问 题 •传统部署模式：IDC托管、现场装机、命令行方式部署•传统操作系统：早期大量的windows系统•传统游戏架构：LNMT架构，“ALLINONE”•数据灾难不可恢•故障影响重，大R上门•…… 先 扛 住 再 优 化人肉规范化、去windows化 运 维 自 动 化脚本+CRT并发模式、Ansible 高 可 用 化备 份 容 灾 、 架 构 优 化 业务快速增长下，技术总在追赶 2012年，运维在合服回收数据库的一次“dropdatabasexx”误操作带来的云认知和思考，故障不可避免，可怕的是只能依赖别人。 可能的场景 1.玩家游戏内操作卡，网络问题自排止步于现象2.故障业损期，自查许久才发现自己没问题，联合云的排查大量串行3.业务发展到一定阶段触发某些不可知云产品瓶颈导致业务故障4.数据误操作，本地没有实时备份 可能的问题 技术不可控 云上黑盒 排查效率低 新技术水土不服 技术转化前提是稳定，技术结合是基础 进入云时代，让运维工作模式发生变化，云视角下的业务/技术结合是痛点，运维因子变多、范围变广，如何在云上更稳定是该时期最大的挑战。 云 运 维 的 本 质 是 换 位 ， 从 “ 车 上 看 路 ” 到“ 路 上 看 车 ” 的 思 维 转 变 。 技术保障标准化，从不确定实践提炼确定性 业务项目规模化后的技术保障诉求必然是规范化、标准化，保障结果必然是确定性、前置化，战前忙碌、战时平稳、战后归纳，集团军模式遍地开花。 电商进入弹性时代，高并发大促保障 电商规模化成本，弹性是技术最优解 电商流量拥有天然潮汐特性，IDC托管-属于最大资源供应形态，托管按需扩容-有储备的成本，相对于前两者云上弹性在供需关系、扩容时间上有显著优势。 电商红包秒杀的业务实践，早期保障往往从问题开始 双十一、双十二、店庆等多样性带来带宽波峰较为明显，服务压力是平常的数十、百倍甚至千倍，异常影响也是指数级。 •业务高并发，并发可能带来不可知技术瓶颈•业务架构耦合度较高，故障引发连带效应•调整架构时间有限 业务挑战 •梳理业务运营思路和技术匹配逻辑•LB的CPS性能压测，独享资源集群•关键业务模块拆分，分散性能及单点故障，启用泳道隔离故障方案•数据层CACHE缓存及分库、分表•压测、降级预案准备，后续的架构优化落地 保障策略 •红包活动保持每天至少300%的用户量增长，实现APP日活增量提升将近8倍•架构能力优化，为后续打下技术基础•打磨适配的保障常态化工作 实现价值 围绕问题的行业技术实践TIPS 知著 见微 •保持SRE工程化思维，先扛住再优化，扛住是过程优化才是目标•已知故障复盘，以点带面、举一反三•主动运营，至少60%时间投入事前•规范化、标准化、脚本化、工具化、自动化五步法则•透过表象看本质；通过局部看整体；围绕现在看未来•业务拆解技术动作，技术回归业务价值•做稳定性一号位，从挨打到执鞭人转变•没有绝对的高可用，只有价值互惠 •快速变化的业务，运维大量时间投入在繁复被动支持工作•当前运维能力有限（个人/团队）•故障较多，都是没见过的问题•从0到1后，1到100只能靠堆人•大量时间投入在故障应急，“坑”源源不断•大型活动保障都是被动救火•不出问题没人知道运维做了什么，“运维没有价值？”•架构推动不了研发改动，现状不允许 SRE工程化稳定性体系建设 SRE工程化关键原则 •运维架构设计原则：架构N+1设计，可回滚、可禁用、可降级，实现多业务模块、多架构高可用；•可观测性原则：确保核心指标、核心链路可监控，通过采集业务指标、 日志、追踪等数据。开天眼在问题发生之前发现问题； •全链路压测原则：通过与可观测性、混沌实验能力的深度整合，实现模拟真实业务环境全链路压测，达到业务上线前的精准资源评估，主动发现潜在性能、版本缺陷等问题； •GOC应急原则：故障不可避免，需要不断去提升MTBF（平均无故障工作时间），降低MTTR（平均修复时间）。制定标准化GOC应急机制，保障事中快速发现、分析、定位与解决问题；•主动运维原则：故障探测、故障压测、故障演练、主动架构优化等事 前的大量混沌实验、故障预案，主动巡检、容量管理等工作，实现风险规避以及打造故障逃逸等能力；•自动化运维原则：DevOps、AiOps等方向，对人肉工作进行标准化、 规范化改造，从而实现自动化。 AI智能化实践 AI的出现，会取代运维吗？ 基于大模型的应用场景 AI在稳定性运维领域的应用 大模型基于运维目标的实现路径 数据采集与整合 机器学习模型 智能决策与自动化 基于深度学习、迁移学习、强化学习等技术，构建适用于运维的学习模型。这些模型的特点是参数量大、结构复杂，能够学习到数据中的深层次、非线性关系。如Transformer架构的模型，可以处理序列数据，适用于日志分析、时间序列预测等场景。 从多个数据源（如监控、日志系统、网络设备）收集结构化的（如数据库表）或非结构化的（如日志文件、指标等），这些数据需要被整合到一个统一的数据平台为后续分析做准备 基于模型的输出，提供智能决策支持，通过智能体实现自动化响应，如自动生成运维工单，启动应急机制，启动容错机制，结合自动化脚本修改配置或调整资源配置 检测与预测 AI可能取代不了运维？ AI目前还取代不了运维。 但……有前提……请运维先抬头！ 技术人的路和远方 当前AI大模型技术服务能力项 •面相行业特点的多场景方案•知识数据完善治理及评测•业务应用及前端集成及交互工程 •提供Prompt优化•面向场景的Agent构建及优化•按需模型调优 •沉淀Rag知识管理工具等开源工具集•支持部署架构•面向场景Agenttools库，插件库 n算力、存储、网络的技术选型和容量配比 AI技术探索实践 基于知识库大模型运维问答 人脸年轻化图形大模型实现 合同文本比对大模型实现 代码工作轻量化大模型实现 技术人的路和远方，几个小建议 n一定要有技术追求，运维赖以生存生命线是技术n一专多能，想清楚专是什么，多能是什么n学会思考比埋头苦干更重要，没有价值的技术很可能是要丢“垃圾桶”n每年问自己一个问题：”你的工作和去年有什么变化？“nAI技术上限不断扩大，技术下限不断革新，学会自我革命n工作和生活可能不存在平衡，但请保持松弛感n希望我们都还是那个运维少年 高效运维社区DevOps时代荣誉出品