2023龙蜥操作系统大会全面推进运维智能化分论坛.pdf

2023龙蜥操作系统大会全面推进运维智能化分论坛智在创新：产学研联动开源模拟故障案例集系统助力行业标准的建立创造共识CEO 苌程云观秋毫鸡同鸭讲现象严重盲人摸象的IT运维可观测性行业摸到象尾巴的厂商CMDB很重要，没有CMDB所有的可观测性工具都失去了灵魂摸到象耳朵的厂商动环监控非常重要，是机房稳定的基石摸到象前腿的厂商网络流量监控非常重要摸到象后腿的厂商应用监控非常重要摸到象鼻子的厂商基础设施监控非常重要什么样的产品适合我可观测性运维产品使用者的困惑踩坑血泪史运动式上工具平均一家企业可能使用超过10个可观测性产品产品和预期不一样ESG Report：用于采集数据的可观测工具数量统计图1：Enterprise Strategy Group.ech Target,(ESG)-Observability from Code to Clod,2002年2月10%22%46%17%3%2%超过 2016 to 2011 to 156 to 10不清楚5或更少遇到了网络故障，耽误的时间较久，老板很生气，上一个网络流量监控产品以防万一应用的软件bug，那帮外包程序员总也没法根治问题，三条两头crash，老板很生气，上一个应用监控产品来管管那帮外包程序员机器死机了，凌晨爬起来去机房，才发现空调坏了，折腾一晚上才恢复，上个动环监控吧，这样可以提早发现问题IT运维可观测性产品落后于国外同类型的产品厂商受限于自身的认知水平使用者受限于自身的认知水平产品的设计哲学依据产品经理或者某一个专家经验构建，同时会参考国内外同行成熟产品厂商对用户故障案例缺乏全局的理解，导致产品只能解决部分故障案例厂商对故障缺乏全局认知，进而导致厂商之间以竞争为主，产品之间缺少生态合作同质化严重，不同厂商的产品宣传资料都差不多选择产品专注于经历过的故障，产品是否能够解决之前痛点，对未来可能出现的故障场景缺乏了解采购产品之后与预期效果有差距，进而对厂商提出超出其能力的要求，导致厂商盲目扩大产品线，厂商不配合就换个厂商继续折腾思想实验：假设有一个完美的故障案例集系统01覆盖主流开发技术和基础设施02开源开放欢迎所有人一起完善故障案例03任何人都可以在私有环境构建部署04任何人可以产生一致理解的典型故障05绝大多数故障案例可以恢复，案例可以重复实验运维产品使用视角运维可观测厂商视角促进运维行业技术进步更加精准地理解客户需求认清自我强项和不足更好在行业生态上合作发展适合自己的产品道路科研高校视角科研验证更加有的放失科研结果更接地气产学研更加高效非常容易验证厂商的能力边界对生态有更深的认知，减少定制化需求更容易定制符合自身业务发展的运维需求不再重复采购，投资回报率提升遗憾的是完美案例系统在现实中不存在开发架构的差异故障理解的差异基础设施差异123云原生云主机虚拟机不同品牌硬件设备业务不一致不同中间件代码风格人对故障机理理解深度不一致人对程序原理理解深度不一致人的工作职责不一致构建基于云原生环境故障案例集系统开发架构的差异故障理解的差异基础设施差异123小范围共识达成之后逐渐演进成大范围共识逼近理想故障案例集系统聚焦云原生，云原生是未来公认的技术架构仍然存在基础设施差异，但是差异性极大的减小了聚焦主流微服务技术，同时提供可扩展性，不断完善引入不同中间件，开发基础件的场景可重复的故障实验能够统一大家的认知与话术可扩展的故障，能够不断演进支持各种故障模拟业务系统复旦SELab开源的TrainTicket项目基于云原生环境部署，基础设施标准化基于SpringCloud微服务开发，符合主流开发框架链路调用深度较长，接近实际业务场景开源开放License友好故障案例集系统基于TrainTicket构建故障案例集系统需求故障注入和故障撤销的可视化界面基于chaosMesh的故障集代码层面的故障案例集故障案例集系统特征01基于复旦开源的TrainTicket，覆盖了基础的主流微服务开发技术02开源开放欢迎所有人一起完善故障案例03任何人都可以在私有环境构建部署04任何人可以产生一致理解的典型故障05绝大多数故障案例可以恢复，案例可以重复实验故障案例集SOMA-CHAOS介绍开源开放，开源协议是木兰协议https:/ GC频率很高已经支持的故障案例网络类故障TCP建连延时高丢包率较高带宽限制打满重传率较高DNS故障CPU类故障共享环境其它进程抢占CPU代码自身CPU使用率高代码类故障HTTP请求返回错误码代码抛出异常导致错误码返回K8s类故障Ingress故障Pod重启代码类故障代码锁并发类故障故障案例集SOMA-CHAOS介绍存储类故障存储满短期内将要支持的故障案例网络类故障增加意料之外的网络访问CPU类故障内存类故障代码类故障微服务雪崩故障案例集SOMA-CHAOS介绍存储类故障中远期将要支持的故障案例网络类故障CPU类故障内存类故障TCP建连不成功网络连接断连TCP 0窗口中间件故障数据库死锁redis响应慢数据库连接池打满故障案例集SOMA-CHAOS全景图中国信通院系统稳定性保障标准体系研究中国信通院 稳定性保障实验室负责人 王海清2023年12月为什么？开展稳定性保障能力建设的背景和价值0101是什么？稳定性保障体系都包含哪些内容怎么办？稳定性保障技术能力稳定性保障建设路径02020303开展稳定性保障能力建设的背景和价值01 为什么？近年来云服务发展迅速，产业生态日益成熟，云服务的运行稳定已经是信息通信行业稳定安全运行的重要组成部分。各级政府具体政策和措施各级政府具体政策和措施2022.62021.122021.122022.1云服务稳定安全运行应急演练专项活动“十四五”数字经济发展规划“十四五”国家信息化规划关于银行业保险业数字化转型的指导意见工信部 举措类工信部统一部署，联合信通院开展面向全国云服务运营商的云服务稳定安全运行应急演练专项行动国务院 政策规划类培育壮大人工智能、大数据、区块链、云计算、网络安全等新兴数字产业，开发网络安全技术及相关产品，提升网络安全自主防御能力国务院 政策规划类增强网络安全防护能力。强化落实网络安全技术措施同步规划、同步建设、同步使用的要求。2022.2金融标准化“十四五”发展规划银保监 政策规划类强化网络安全防护。构建云环境、分布式架构下的技术安全防护体系，加强互联网资产管理，完善纵深防御体系，做好网络安全边界延展的安全控制。中国人民银行 政策规划类提出统筹金融数据中心标准体系建设，制定数据中心灾备体系标准2023年1月25日微软Azure云产品由于广域网问题造成众多Microsoft365服务的持续性故障，用户服务中断5个小时。2023年6月13日AWS出现2个小时的宕机，多个AWS服务的错误率和延迟持续增加，电子商务等多个业务受到影响。2021年12月7日国内某云厂商部分CDN域名解析发生了异常，由其支撑的服务也发生了短暂崩溃事件。2022年7月19日谷歌和甲骨文在伦敦数据中心的冷却系统出现故障，导致部分实例终止和服务降级，该问题在十几小时后才得到解决。2021年11月16日，Google Cloud服务器由于网络配置问题造成负载均衡中断，引发全球宕机数小时，影响波及全球用户。2022年12月18日国内某云厂商由于其香港机房出现故障出现大规模服务中断事件，持续超过15个小时。2022年7月29日，神州专车发布通知称，因网络故障导致通讯受阻，出行平台暂时无法使用叫车服务，相关人员正在紧急抢修。2022年7月21日微软的团队群聊与协作软件Teams出现宕机，无法访问和使用其功能，服务中断数小时，影响波及全球用户。2023年6月19日早盘10时左右，中信证券的交易系统瘫痪，挂单后无法完成成交且无法撤销交易。国外国内2022年6月13日，“同花顺崩了”冲上微博热搜。同花顺在其官方微博上表示，部分用户受某云服务故障影响。云服务故障案例重要性：云服务稳定安全运行事关人民切身利益，事关社会稳定运行急迫性：分布式系统稳定性挑战加剧，产品侧与用户侧双向推动稳定性保障体系变革技术域技术域核心系统日常流量保持在高水位，并发请求量大、业务激增随机性强应用之间依赖关系错综复杂，单一节点问题可能会被无限放大，故障难以避免服务性能瓶颈难以分析，故障影响范围难以评估流量冲击系统复杂难预测节点分布范围更广、数量更多，为日志采集、分析带来新挑战难分析管理域管理域稳定性保障建设投入产出比难衡量，大部分组织以业务产出为导向，稳定性工作易被忽视技术标准、规范缺失，难以满足组织内技术发展要求管理机制老旧，不能适配快速发展、迭代的技术体系稳定性意识差技术规范缺失管理制度欠佳产品侧用户侧系统依赖更强10.079.749.349.048.427.714.692.9812345678不同应用用户规模*第49次中国互联网络发展状况统计报告故障容忍度低稳定性保障难度升高稳定性需求及预期升高 分布式系统稳定性保障难度升高，用户侧需求及预期的提升加剧稳定性保障挑战，急需适配新一代系统稳定性保障体系。稳定性保障体系都包含哪些内容02 是什么？业界通常用MTBF和MTTR这两个关键指标来衡量稳定性，这两个指标分别是平均故障时间间隔(Mean Time Between Failure)、平均故障修复时间(Mean Time To Repair)。IT系统稳定性度量系统稳定性内涵及度量系统稳定性释义系统的稳定性，表示系统在遭受外界扰动偏离原来的平衡状态，而在扰动消失后系统自身仍有能力恢复到原来平衡状态的一种顽性。-现代控制理论如果你不能度量它，你就无法改进它。-管理学大师彼得德鲁里稳定性是系统抗干扰和返回平衡状态的能力MTBF稳定MTTR：系统不稳定MTBF稳定故障前故障中故障后核心目标是提升系统稳定的时间（MTBFMTBF）和降低系统不稳定的时间（MTTRMTTR）系统稳定性建设路径需求导向原则政府引导目标降低故障发生概率降低故障影响范围/程度实践路径流程机制人员组织运营能力生态建设多元共治共建共享，推进系统稳定安全生产能力提升技术能力故障预防故障前故障发现故障中故障定位故障恢复故障改进故障后稳定性保障技术能力稳定性保障建设路径03 怎么办？稳定性保障实施路径=流程机制+组织建设+运营能力+生态建设稳定性保障运营能力建设目标降低故障发生概率降低故障影响范围/程度稳定性保障组织建设组织与驱动力团队建设与组织文化值班机制稳定性巡检稳定性周期总结专题行动生态建设人才培养标准建设技术生态稳定性保障流程机制开发测试机制产品发布机制产品变更机制持续运维与应急管理安全运营运维故障演练机制29落实组织内稳定安全运行责任组织与驱动力战略规划团队建设组织文化稳定性团队构建战略规划需要考虑对系统稳定性的持续发展和支撑，系统稳定性在组织战略中以一定的形式体现。系统稳定运行需作为战略目标的重点考虑因素和内容组织架构应明确系统稳定性的责任人或责任部门，负责系统稳定性工作的统筹规划、整体布局、组织协调和实施落实,包括组织制定并实施战略规划和技术路线、审议技术方案等稳定性意识培育设置稳定性专职岗位，明确稳定性建设目标，并针对该岗位发展有明确的培训课程、培训目标以及考核机制总结事件经验，形成稳定性知识库，建设组织内部沟通和协作机制，设立奖励机制，激励员工积极参与稳定性保障建设工作参考中国信通院标准分布式系统稳定性成熟度模型完善稳定性组织能力，压实稳定安全运行主体责任组织建设：组建横向交流合作、监督改进的组织，筑基企业韧性建设流程机制：以保障系统整体稳定性为目标，构建全流程稳保机制总体总体事前事前事中事中事后事后事前降低风险，事中及时预警，事后降低影响，持续提升用户体验用户体用户体验验指导企业建设，提升全流程稳定性保障能力 第一：辅导企业优化稳定性保障整体机制，协助企业早期发现和修复潜在问题，提高产品质量；第二：通过优化稳定性保障流程，咨询服务可以帮助组织降低后期运维成本。减少故障修复的时间和资源投入，提高效率，降低维护负担。第三：稳定性保障咨询可以将最佳实践和专业知识传递给组织内部的团队。这有助于建立内部能力，使组织能够独立地管理和维护稳定性保障机制点石成金参考中国信通院标准分布式系统稳定性成熟度模型 第二部分：机制成熟度持续运营：持续运营是确保组织的系统和服务持续高效运行的“不老针”稳定性体系的建设是一个持续不断的过程，其根本在于不断提升基础组件的容量和性能，以及确保研发和变更流程的安全升级。就像古罗马城并非一日之功，系统稳定性的构建也需要时间和不懈的运营。组织的运维和运营活动是分散的，无明确的流程和标准问题的管理系统化，组织建立标准的运维和运营流程，并开始自动化重复性任务。持续改进和创新是核心价值，组织实现高度自动化，并采用先进的技术和最佳实践。运营能力梯度提升参考中国信通院标准服务韧性工程（SRE）建设成熟度体系 第四部分 持续运营能力协助组织建立更强大的运维团队和流程，提高系统的稳定性和可靠性通过咨询建议的最佳实践和流程改进，组织可以降低运维成本咨询可以帮助组织更好地管理和监控其系统和应用程序咨询建设价值生态建设：云程发轫，技术、人才、标准多方共建组织内系统稳定性生态技术生态 系统稳定性保障赛道足够宽，整体而言参与者并不多，行业发展尚处于起步阶段，头部厂商技术一枝独秀，中部厂商能力各有千秋；稳定性保障建设行业发展成熟度差异明显，互联网与金融行业对新技术体系的接纳度较高。人才培养 企业内部沉淀稳定性保障相关技术文档，定期组织技术分享。组织结构化故障复盘，在企业范围内共享经验，帮助其他员工学习经验教训。整合培训资源，以企业内部培养为主，外部多种培养方式为辅。可以考虑行业企业协同培养，结合各自优点，打造相对完善的培养方案 积极联合高校开展专业领域的合作并开设专属课题，将人才培养前置到高校阶段，为系统稳定性保障领域输送更多的专业人才。标准建设 建立负责技术标准管理的相关部门，制定标准管理措施和步骤，规范企业技术标准管理工作，提升标准质量。广泛开展合作共建，积极与国家信息技术标准制定机构合作，推进系统稳定性的细分领域标准的制定。稳定性课程培训信通院可协助企业制定企业内部标准稳定性保障技术能力稳定性保障建设路径03 怎么办？系统稳定性保障技术体系 结合通信、金融、互联网等行业用户对系统稳定性保障技术的理解与实践，总结归纳系统稳定性保障技术体系包括故障预防、故障发现、故障定位、故障恢复及故障改进五大能力域。故障发现故障预防故障定位故障恢复故障改进MTBF：稳定MTBF：稳定MTTR：系统不稳定故障发现故障预防故障定位故障恢复故障改进容量管理故障告警根因分析容灾切换故障复盘故障改进与追踪链路追踪故障巡检故障演练建设反馈全链路压测事前：备战能力故障预防事中：作战能力统一指挥 恢复优先事后：改进能力故障复盘与改进架构设计消除单点依赖设计容错设计应用多活可观测性变更管控【事前】容量管理：动态流量下稳定性与成本的重要平衡手段 容量管理是指以最高的性价比和快速的方法，使IT基础设施的容量切实且持续符合不断变化的业务需求的活动。精准的容量管理，可以使企业上云的预算规划更科学，同时也更贴合业务发展阶段的需要。明确必要性企业的业务是动态发展的，业务依赖的云上资源也需要相应地动态调整。过多资源配置会导致资源闲置、成本浪费，过少的资源影响服务响应性能、阻碍业务快速发展。容量管理相关规范中国信通院容量管理技术分级能力要求国家规定与标准要求信息技术服务 数据中心服务能力成熟度模型 GB33136-2016分布式系统稳定性度量模型ISO20000 信息服务管理体系认证ITIL 信息技术基础架构库 随着系统上云进程推进，系统架构越发复杂，业务场景越发多样化，对性能测试的要求也越来越高，传统的压测无法覆盖到所有的环节，导致通常会忽略掉某些基础服务或节点，所以传统压测已不能满足微服务场景下压力测试的需求。【事前】全链路压测：在微服务场景下发现系统中可能存在的性能瓶颈和问题明确全链路压测必要性压测测试方式变革面向单机或单系统，主要关注单系统接口架构较简单调用链路也较短，单个系统功能点多微服务被拆得越来越细，调用链路明显变长，单个系统功能点少性能测试必须做到覆盖“全部”系统系统架构变革中国信通院通信行业标准全链路压测平台技术要求压测前压测中确定压测环境数据准备场景编排压力机准备压力模型施压策略发压调度压测监控压测熔断数据清理压测报告压测记录性能建议压测中流量透传数据隔离服务挡板生产压测风险保护【事前】架构设计：构建韧性架构，避免架构设计不合理造成稳定性事故或性能瓶颈基础技术单点数据单点服务注册中心单点存储单点网络单点机房单点硬件单点外部服务单点前端资源单点内部服务单点确保集群节点位于不同的云“区域”和“可用区”关键服务器冗余成集群网络连接冗余成多通道存储做镜像或者RAID冗余数据中心通过容灾和双活实现冗余服务做容错处理和依赖设计用户建设者系统启动依赖基础软件依赖业务域依赖数据库依赖硬件依赖网络依赖依赖治理操作步骤应用接入依赖分析依赖预判依赖验证方案归档构建限流、降级、熔断机制，防止系统雪崩限流针对服务请求数量的一种自我保护机制，当请求数量超出服务的处理能力时自动丢弃新来的请求。系统容错能力降级是通过开关配置将某些不重要的业务功能屏蔽掉，以提高服务处理能力。熔断当被调用方出现故障时，调用方主动停止调用，并根据业务需要进行相应处理。行为我们称之为熔断。谨防隐藏在云的无形基础设施中的单点故障陷阱高等级服务不允许强依赖于低等级的服务或资源架构架构设计设计原则原则参考中国信通院分布式系统稳定性建设指南，构建稳定韧性的系统架构数据统计：由变更问题而触发的生产事故占比超过50%亚马逊系统复杂度NETFLIX系统复杂度系统复杂度无法避免：任何设计系统的组织产生的所有设计都将受限于组织间的沟通结构。变更操作越发高频且团队离散：从单一的运维团队可执行生产操作，会逐步演化到研发、SRE、业务运营等团队都具备线上变更操作。中国信通院变更管控成熟度模型010102020303变更前变更中变更后变更管控准入变更计划变更影响面分析变更风险分析变更审核及审批变更感知灰度/分批发布变更指挥风险防御可恢复变更结果验证配置管理系统更新变更报告及数据沉淀变更度量与审计服务稳定性平台基础能力变更日历权限管控安全管控高可用云化后的系统复杂度提升，依赖复杂，一处改变就可能带来潜在的稳定性风险，同时云原生化改造促使变更操作越发频繁且团队离散，变更成为导致线上稳定性问题的主要引发因素。需要将变更管控视为技术问题来解决，完善相应的技术架构、管理制度以及适配的技术平台能力。机制变更制度管理变更规范管理变更流程管理变更执行容量上下游依赖其他【事前】变更管控：降低由变更带来的稳定性风险【事前】故障演练(1/2)：采用混沌工程开展故障演练，有效发掘系统潜在故障点混沌工程是故障演练的一种技术手段，作为保障分布式系统稳定性的重要技术，其提供了主动发现系统稳定性弱点的方法，近几年成为推动企业IT韧性系统建设的强大助力。为什么需要混沌工程混沌工程使用频率与产品可用性提升显著相关。从未使用过混沌工程的受访者中，有近三成受访者产品可用性低于99%，而随着混沌工程使用频率提升，在每天都会演练的受访者中，这一比例急剧缩减到2.5%（右图蓝色模块），即随着混沌工程使用频率提升，低可用性的产品占比急剧萎缩。价值与成效云生产环境线上事故驱动出混沌工程起源2008年奈飞DVD租赁业务因数据库故障中断3天2008年奈飞业务上AWS云，但AWSAWS服务实例会突然消失2010年推出生产环境随机关闭服务实例的“混沌猴”故障发现故障发现定位故障恢复与复盘监控告警故障上报体系建设场景分析生产环境/仿真环境故障场景基础资源故障中间件故障应用故障业务系统预案执行人工恢复故障巡检容灾切换故障恢复故障复盘监控项检查改进措施故障复盘日志分析链路追踪故障监控根因诊断定位实施规划混沌工程平台用户入口故障模拟演练工单经验沉淀混沌工程理念【事前】故障演练(2/2)：混沌工程平台能力及成熟度模型是实现混沌工程落地的最佳组合混沌工程成熟度融合风险分析指导培训改进建议混沌工程能有效通过故障模拟触发应急流程，同时融合行业需求及故障复盘沉淀经验持续丰富故障库，构建持续演练、持续提升的良性循环。工程熟练度实验环境实验计划管理故障场景实验工具原子故障实验观测实验环境爆炸半径实验结果应用成效度演练计划完成度故障场景探索度产品赋能程度原子故障覆盖度故障闭环程度故障场景覆盖程度组织建设度混沌工程团队建设混沌工程文化建设混沌工程成熟度模型行业标准混沌工程平台分级能力要求行业标准指导混沌工程在组织内阶梯化落地助力企业构建优秀混沌工程平台能力【事中】可观测性建设帮助组织快速定位故障根因：巡检操作步骤*分布式系统稳定性建设指南明确确定性风险指标及基准各子域稳定性指标数据采集数据比对并出具风险报告实现日常巡检巡检评估维度业务连续性状况性能状况基础设施状况容量状况信息安全现状主动地、有目的地巡回检查生产设备，有效了解设备运行状态故障巡检应急响应流程的启动开关故障告警根因分析监控告警应急告警规则告警通知人员配置设定告警级别：1级，2级，3级，4级。设定告警阈值：将维度，指标，阀值与告警级别关联设定通知方式：邮件，IM，短信，电话。根据紧急程度设置通知方式。设置值班组：对应的值班组的人员接收全部告警信息。多面性冗余性耦合性如何在告警风暴时压缩告警？如何快速从大量告警中找到故障根源？如何提高不同团队的故障处理协作效率？如何实现对云设施的风险管理？告警知识库：规则集推理机：思维方式解释器：why how核心组件 故障根因诊断为人工智能的分支，属于诊断性专家系统 根因诊断系统构建 系统可观测性建设（故障巡检+故障告警+根因分析）帮助组织精准发现系统故障，识别定位故障根因。【事中】监控告警、日志分析和链路追踪统一建设为可观测性 云上的复杂系统中将监控、日志与链路追踪有机结合的高效的“可观测能力”。未来可观测性从概念认知、标准制定、建设规范等方面实现大一统：传统监控VSVS可观测性传统监控目标是及时的发现系统运行中发生的问题可观测性是在发现问题的基础上，具备分析问题和解决问题的能力MetricsLoggingTracing采集到维度丰富、联动的数据集监控指标：固定类型的时序数据链路追踪：单个请求的完整处理流程日志：软硬件/通讯事件记录不是什么是什么可观测性工具能高效全面地收集系统运行状态数据，制定完善的告警策略，提高故障排查速率打造可观测性底座，串联其他稳定性保障技术手段全生命周期可观测，避免开发过程中“暗疾”将可观测性应用到软件开发全生命周期，使得软件开发、测试、部署、运营等关键环节白盒化，避免“暗疾”。CI/CD可观测，敏捷开发的同时保障软件质量 敏捷开发流水线与观测工具的结合 打破“先发布，后观测”的现有格局：流水线实时读取观测数据，确保部署前的测试过程无问题、部署之后版本运行状况良好。在提升迭代效率的同时，保障版本质量。应用领域多样化可观测平台标准化、普及化观测数据统一化、丰富化【事中】可观测性系列标准推动组织提升可观测能力可观测性平台技术要求：可观测性是软件系统质量探索的基石，软件系统的可观测使得在此基础上的各种系统行为分析有据可依。可观测性建设成熟度模型：为组织提供一种系统性的方法来评估、改进和提升其可观测性体系建设。根因分析平台能力要求：诊断复杂架构故障原因，提升云系统性能质量。根因分析平台能力要求可观测性平台技术要求可观测性建设成熟度模型【事中】应用多活：云时代容灾能力建设的典型解决方案 应用多活是以应用为中心的云原生容灾架构，是“应用容灾”技术的一种高级形态。当灾难发生时，多活系统可以分钟级内实现业务流量切换，用户甚至感受不到故障发生。同城多活和异地多活是应用多活的典型部署形态多活架构的技术特性多种布局模式多地理节点部署业务并行多点接入业务并行多点处理数据并行多点存储降低故障业务影响多活架构驱动因素更高的灾难恢复要求接管能力难以把控单数据中心扩展受限业务覆盖需要技术提升需要资源利用率低驱动异地多活同城多活应用多活成熟度模型联盟标准应用多活架构能力要求行业标准指导容灾建设能力在组织内阶梯化落地助力企业构建优秀应用多活架构能力主备容灾可视化数据库复制双活云容灾、云迁移、多活、混合云容灾指导容灾能力梯度提升【事后】故障复盘与跟进：全面推动各方分析和经验沉淀，降低故障复现率1、复盘全流程确定故障复盘方式-判断复盘主题：明确机制、临时决策.-关注点：参与人员、时效性、复盘方式.梳理故障应急时间轴-时间轴组成：时间点、评估方法.-关注点：客观、量化、在线还原故障处置动作-故障处置行动：发现方式-关注点：能力、协同、机制、工具根因分析及经验沉淀-故障起因：架构高可用、容灾、性能、容量-影响恢复因素：工具、性能、机制问题及改进措施跟踪-团队定位：研发、测试、第三方厂商、运维、流程经理-跟踪方式：线上打通闭环、问题催办、专项分析编写故障报告并发布-故障分析过程、根因分析、定责、改进方案-发布方式：风险通报、专项例会、监控部门2 2、故障改进及跟踪应急管理-可观测性平台、应急预案、应急演练、应急协同架构问题-高可用架构设计、容灾设计、架构实施应用问题-应用开发、应用设计、应用测试、版本控制变更问题-变更测试、变更计划、变更故障、变更实施配置问题-配置更新、参数配置、配置检查产品及功能设计-产品缺陷、硬件故障、产品补丁维护问题-数据备份、监控预警、保障方案问题管理-问题跟踪、解决时间、总结分析3、故障原因分析平台团队流程控制研发团队测试团队需求产品第三方加强平台能力建设，提升监控覆盖面与准确率，提升根因诊断等异常诊断工具能力。完善应急处置过程的协同效率，信息传输及触达效率，完善人员能力、工具平台能力的提升修复程序设计逻辑缺陷，提升系统健壮性，增加日志完备度与监控埋点需求，加强版本管理优化等提升非功能性测试、功能性测试覆盖面等完善业务逻辑设计、功能设计完善硬件、软件、线路等方面的健壮性等管理机制4、故障追踪问题管理问题催办变更闭环问题关闭数据驱动绩效支持保障高优先级的问题通过管理机制及工具赋能故障复盘是为了分析故障处置行动，沉淀经验，转化为团队能力分角色推进故障改进构建故障跟踪平台，基于线上化的问题跟踪数据进行自动化催办中国信通院基于研究基础，提供复盘优化能力建设评估和咨询故障后故障中故障前提升架构韧性加强故障隐患排查提升系统容错能力提升风险感知敏锐度加强故障定位、分析能力提升应急处置水平责任到人，跟踪处理完善落实复盘强化绩效前期准备抓住重点信息传导上医治未病中医治欲病下医治已病尽早预防故障，降低故障发生几率50%止血大于修复40%推动故障闭环，降低故障复现率10%系统稳定性保障技术体系建设系统稳定性保障关键技术总结专项演练内容共3部分，分别从云服务系统稳定可靠能力、云服务系统容灾恢复能力、云服务事故应急处理能力开展演练，基本框架如下：1.云服务系统稳定可靠能力1.1 全链条压力测试1.2 云服务混沌测试1.3 可观测性能力测试3.云服务事故应急处理能力3.1 云服务应急响应机制审查（制度、组织、流程、实践）3.2 云服务应急预案演练（监控告警、评估分析、应急响应）2.云服务系统容灾恢复能力2.1 容灾恢复制度检查（预案管理、响应处置、过程监控）2.2 容灾恢复能力测试（网络故障、存储故障、机房断电演练）应用：2022年“稳保行动”48应用：2023年“稳保行动”督促事项分为三大维度，6个方面，内容如下：云服务稳定安全运行保障体系 安全运行责任制 云服务分类分级管理 考评考核制度 联防联控机制风险隐患排查化解能力“两个清单”维护情况 平台关键指标监测 接口管控 风险预测关键业务智能管控能力 可观测性技术能力 全链路压测技术能力 混沌工程技术能力 配置管理能力 变更管控能力重要系统冗余保障能力 链路冗余 备份策略 数据恢复策略 系统可用性策略 倒换测试 容量监测管理运行事故应急管理体系 安全培训 应急预案 预案演练机制 信息上报及披露机制运行事故应急处置能力 应急启动 决策部署 应急关闭 事后复盘 应急管理复盘 应急管理平台能力保障体系稳保技术应急处置踏实、务实、求实的“稳保”梦之队SysOM的可观测和智能监控实践阿里云高级开发工程师龙蜥社区系统运维SIG Contributor刘馨蔚当前运维的趋势和挑战0101探索及实现路径SysOM 应用观测实践SysOM 智能监控实践02020303040401 当前运维的趋势和挑战数据数据应用Serverless应用应用数据Serverless数据应用Serverless中间件（DB、MQ、Mesh）中间件（DB、MQ、Mesh）Serverless虚拟化(xen、kvm)操作系统操作系统操作系统容器容器操作系统容器容器物理机物理机物理机网络&存储物理机网络&存储网络&存储网络&存储数据中心数据中心数据中心数据中心中间件（DB、MQ、Mesh）中间件（DB、MQ、Mesh）虚拟化(xen、kvm)虚拟化(xen、kvm)虚拟化(xen、kvm)ColocationIaaSPaaSFaaSAIOps应用运维功能上移两大趋势应用开发边界上移 开发变得更为简单 无需感知容器、系统以及IaaS底层 系统运行情况无法深入了解 系统的运维无所适从可观测云原生倒逼智能化“零”运维目前的运维产品现状与挑战配置部署系统监控问题定位常见工具Ansible/AWXGrafana/Zabbixperf/ftrace/bcc现状开环的执行过程无法对部署的系统进行稳定性评估基于操作系统现有的数据接口、日志进行采集，收集粒度粗糙基于基线的告警存在大量的误报需要专业级别系统运维人员通过大量工具的组合应用挑战不知其然只知其然而不知其所以然难知所以然内核的复杂性导致问题解决难度居高不下进程A读写文件大量Page Cache形成系统空闲内存急剧减少进程B申请内存并访问内存回收可能引发的内存不足告警可能引发的内存访问时延更糟的是，我们没有办法知道，究竟在哪个时刻会引发问题。进程B的内存问题，很难让运维人员关联到进程A的写文件操作糟糕的是，不仅仅是案例所阐述的内存问题，在操作系统内部网络、IO、内存、调度皆大量存在类似问题。02 探索及实现路径Linux 跟踪及观测技术一览前端工具/库（用户态）Tracing框架（内核态）数据源（内核态）prefLTTngSystemTapTrace-cmdfuncgraphbpftraceBBCTraceeFalcoauditdlibbpfgolibbpflibscapPerf_event_opensyscallLTTngKernel modtracefsbpf syscallNetlinkeBPF(JIT)SystemTapKernel modAuditing SubsystemHarware events(HPC)tracepointkprobe/kretprobefunction hooks(ftrace)fentry/fexit（eBPF）audit hooks数据源提供tracing数据的来源底层框架对接数据源，采集解析发送数据，并对用户态提供接口前端工具对接底层框架，直接与用户交互，负责数据分析和展示SysOM 系统观测实现路径kernelmoduleperf/ftraceCoolbpfContinuesprofiling应用可观测使用ko跟踪内核事件跟踪问题发生路径，分析性能问题点使用eBPF诊断和监控持续对问题追踪、性能监测从应用视角，进行智能诊断、系统可观测-runlatency-iohangPerf 火焰图功能Surftrace工具基于eBPF的持续追踪和分析工具raptorMysql、Nginx、Java；AI 根因分析eBPF诊断和监控工具：-irqoff-iolatency，-Pingtrace，-Rtrace等可观测成熟度模型1 监测健康状态，2 自动触发警报“三大支柱数据”洞察系统内部状态从业务角度深入洞察，降低成本、增加营收、提升转化率，辅助商业决策监控Monitoring基础可观测性Basic Observability因果可观测性Causal Observability主动可观测性Proactive Observability业务可观测性Business Observability12 34 5可靠性和用户满意度Level 1Level 2Level 3Level 4Level 5网络&拓扑问题的根本性原因1 自动化根因分析2 自动化响应与处置3 智能化预测与风险阻断SysOM 系统智能监控指标聚合、分析指标关联、根因分析自动分析诊断轻量级诊断深度诊断延时内核响应用户空间请求所需要的时间系统调用中断延时IO延时.流量系统的吞吐和负载情况load每秒系统调用数每秒网络包数.错误系统出现错误或异常的情况，通常用错误数、错误率hungtasksoft lockup.饱和度有限资源的使用情况CPU内存磁盘.SysOM 系统智能监控主要覆盖指标关联根因分析集群健康度节点健康度SysOM 系统智能监控混部场景由于在线任务普遍存在潮汐规律，因此可以通过时间序列算法来构建系统资源画像。根据资源画像的预估结果和系统预分配资源进行水位评估，根据评估结果来指导调度系统进行资源调度以及系统配置调整。SysOM 智能运维系统平台eBPF 无侵入数据监控采集SysOM 观测和监控平台根因分析和智能诊断应用性能和瓶颈发现、智能监控、异常告警、根因分析、深入诊断OS 系统指标Nginx基于ECS、裸金属、物理机、K8S 容器集群数据库JAVA中间件网络流量分析应用异常事件分析系统侧链路追踪应用RED指标分析日志和指标关联分析AI 根因分析发起诊断和分析数据系统和应用指标关联分析诊断结论和修复建议中心端数据分析根因分析，重新发起诊断Continues Profiling03 SysOM 应用观测实践SysOM应用观测实践慢查询系统级根因剖析拓扑自发现提供常规的查询优化分析，还能在全索引等DBA的优化能力极限下找出更具体的影响因数自动检测POD间关联关系自动分析流量以及应用类型全局流量拓扑数据库应用可观测应用RT分析通过应用的RED指标，分析业务延迟原因Java应用可观测超时TimeOut检测Http应用可观测异常自发现自动抓取关键指标和异常提示并跳转执行抖动（RT）跟踪分析实时跟踪每个SQL执行的RT，自动化关联系统指标并推送最佳解决方案性能火焰图自动分析从火焰图自动分析出GC异常、锁异常分析等常见问题，并筛选出主因的调用栈。流量和错误分析从应用到内核，分析典型的超时问题、tcp重传等可能引起超时的异常检测分析请求流量和错误根因覆盖的典型应用：Mysql、Java、Nginx深 度 剖 析 问 题 成 因基于内核深度剖析降 低 应 用 运 维 门 槛自顶向下关联 追踪可理解应用观测实践-全局流量拓扑全局流量拓扑发现RT指标异常跳转到应用监控大盘分析应用和系统指标，跳转执行相应诊断跳转应用典型异常事件大盘分析典型问题根因，输出结论全局流量拓扑，可以可视化展示集群内业务Pod之间的交互关系。如果发生异常的Pod，会以红色标记出来。当将鼠标悬停在Pod节点上时，可以查看该Pod的名称、最大网络延迟、相关的URL请求和网络流量等详细信息。应用观测实践-Mysql 应用实践应用观测实践-Nginx 应用实践应用观测实践-JAVA 应用实践Java 运行时分析异常原因和进一步诊断/修复建议关键调用栈信息融合java和系统的调用栈信息实时RT诊断主要时间消耗在oncpu异常原因和进一步诊断/修复建议相关系统指标的对比关系Java 占用节点cpu高Java 实时rt大Java rt抖动04 SysOM 智能监控实践智能监控实践-智能监控指标分析智能监控实践-集群健康度智能监控实践-指标关联智能监控实践-根因分析1 选择CPU争抢的时间点将鼠标放到毛刺发生的起点，弹出一个对话框，对话框显示了毛刺发生时的时间戳和实例IP2 点击弹出诊断中心链接在步骤1中已经选择了一个毛刺点，然后鼠标单机左键，对话框中有“CPU争抢诊断中心”按钮，点击这个按钮将跳转到(新开)CPU争抢的诊断页面创新视角下的微服务性能、安全与故障感知探索与实践以