简介：每年都有大促，稳定保障这个词大家都不陌生。虽然业务场景不同，但“套路”往往是趋同的。全链路压测、容量评估、限流、应急预案等等，来来去去，总有那么多花样。跳出这些“套路”，回归问题本质，我们为什么要遵循这些策略呢？除了口耳相传，我们还能做什么？理论依据是什么？1.前言每年都有大促销。每个人都熟悉术语稳定性保证。虽然业务场景不同，但“套路”往往是趋同的。全链路压测、容量评估、限流、应急预案等，来来去去，没那么多花样。跳出这些“套路”，回归问题本质，我们为什么要遵循这些策略呢？除了口耳相传，我们还能做什么？理论依据是什么？第二，什么样的系统是稳定的？先回答另一个问题，什么样的系统才算稳定？在GoogleSRE（SRETrilogy[1]）中，有一个描述系统可靠性基础和高层需求的层次模型（Dickerson'sHierarchyofServiceReliability），如下图所示：该模型由GoogleSRE提出工程师MikeyDickerson于2013年将系统稳定性需求按照基础层级进行系统区分，形成稳定性标准金字塔模型。金字塔的底部是监控，监控是一个系统对稳定性最基本的要求。缺乏监控的系统就像一匹蒙着眼睛狂奔的野马，谈不上可控性，更谈不上稳定。上层是事件响应。从监控发现问题到最终解决问题，这段时间的长短直接取决于应急机制的成熟度。合理的应急策略可以保证在故障发生时，所有的问题都能得到有序、妥善的处理，而不是惊慌失措变成一锅粥。事后分析与根本原因分析（Postmortem&RootCaueAnalysis），也就是我们平时说的“检讨”，虽然很多人不喜欢这个活动，但是我们不得不承认，这是最有效的预防我们的方式从下次再犯同样的错误意味着，只有找到失败的根本原因和相应的缺陷，才能对症下药，合理避免。假设一个系统在初次发布后就不再更新迭代，做好以上三个方面基本可以满足系统对稳定性的所有要求。可惜目前这样的系统基本不存在，各种规模的应用都离不开不断的变化和发布。因此，要保证系统在这些迭代中的持续稳定性，测试和发布过程是必不可少的。有效的测试和发布策略可以保证系统所有的新变量都在可控和稳定的范围内，从而达到整体服务终态的稳定。除了代码逻辑的更新，迭代还可能带来业务规模和流量的变化。CapacityPlanning是这些变化的保障策略。现有系统容量是否足以支撑新的流量需求，整体链路上是否存在不均等的弱节点，是容量规划需要考虑的问题。位于金字塔模型顶端的是产品设计和软件开发（Development），即通过优秀的产品设计和软件设计，使系统具有更高的可靠性，构建高可用的产品架构体系，提升用户体验。3.大促的稳定性保障方法从金字塔模型中，我们可以看到构建和维护一个高可用服务需要做的几个方面的工作。那么问题又回到大促的稳定性上，大促期间如何系统地保证系统的稳定性？大促保障实际上是??针对特定业务场景的集中稳定建设。与日常保障工作相比，具有并发量高、保障周期短的特点，对系统性能和保障时间有明确要求（一般2个月左右）。针对以上特点，对于大规模推广、大流量业务场景，如何在短时间内优化巩固系统稳定性需求？时间有限，盲目撒网绝非上策，需要有针对性地从重点和薄弱环节入手。因此，第一步是获取全局系统链路的现状，包括关键的外部依赖、关键的业务影响等，找到整体保障的核心重点。接下来，进一步分析大促业务数据，得到系统本身以外的可变干扰因素。在这两者的基础上，我们在金字塔模型中围绕系统监控、规划容量、应急响应、测试和审查，对系统进行有针对性的集中保障建设，并得出最终的保障结果。至此，我们基本掌握了大促维稳策略的完整方向。执行的顺序是：System&BizProfiling（系统&业务分析）监控（Monitoring）容量规划（CapacityPlanning）应急响应（IncidentResponse）Testing&Postmortem1.System&BizProfiling——系统链接梳理系统链接梳理是一切保障工作的基础，如同对整个应用系统的全面体检，从流量入口出发，沿着链路轨迹，逐层节点分层，得到系统的全局画像和核心保障点。入口整理和盘点一个系统往往有十几个甚至更多的流量入口，包括HTTP、RPC、消息等多种来源。如果无法覆盖所有环节，可以从以下三类入口进行梳理：核心再保险流量入口用户对服务SLI承诺度高，对数据准确性、服务响应时间、和可靠性。对于企业级用户，资产损失事件对应入口为公司资金收益或客户资金收益收费服务。TPS&QPSTOP5~10。这类入口虽然对SLI和资金损失要求不高，但是流量比较大，对整个系统不利。负载有很大的影响。节点分级判断流量入口就像是线球中的线头。挑出线头后，链路上的节点（HSFDBTairHBase等所有外部依赖）可以根据流量轨迹按照依赖程度、可用性、可靠性进行分类。(1)强弱依赖节点判断如果节点不可用、链路业务逻辑中断或高层损坏(有一定的容忍阈值)，则为强业务依赖；否则就是弱依赖。如果节点不可用，链接执行逻辑中断（返回错误），则为强系统依赖；否则就是弱依赖。如果节点不可用，影响系统性能，则为系统强依赖；否则就是弱依赖。按照快速失败的设计逻辑，这种节点不应该存在，但是在不改变应用代码的情况下，如果出现这种类型的节点，应该算是强依赖。如果节点是不敏感的并且可以降级，或者对于轻微的业务损坏有替代解决方案，则它是弱依赖。(2)低可用依赖节点判断。严重节点服务每日超时。严重节点系统资源不足。(3)高危节点判断上次大促后节点是否有大版本。高级别故障节点故障后存在资金损失风险。应该产生数据。完成这个梳理工作后，我们应该产生如下数据：对应业务领域的所有核心环节分析，技术&业务强依赖，核心上下游系统，资产流失风险要清晰标注。下图为单链路分析示例：2.System&BizProfiling-业务策略同步不同于高可用系统构建体系，它促进了针对具体业务活动的稳定性保障体系和针对性保障建设。因此，经营策略和数据是我们进行保护之前必不可少的数据。一般推广业务数据分为两大类，全球业务形态评估和应急策略&玩法。全局评估这类数据可以帮助我们进行精准的流量评估、高峰预测、大促人力调度等，一般包括以下几类：大促营业时长（XX天-XX天）业务量预估（每日X次）预估高峰期业务场景预估流量分配应急策略此类数据是指本次大促相比往年大促活动的业务变量，可用于应急预案和高危节点评估等，一般包括以下两类：特殊业务玩法应急情况策略3.监控——监控&告警排序目前业界常用的监控方式一般有两种模式，黑盒监控和白盒监控监控。黑盒监控是面向对象的，一般监控正在发生（而不是即将发生）的异常，即系统中已经存在的故障。白盒监控主要依靠对系统内部指标的监控。它是面向对象的，也是面向事业的。可以对系统将面临的异常进行预警，也可以在异常发生时同步监控底层内部指标，从而定位根源。所以在大促的稳定性保障上，我们一般会选择白盒监控。从监控的角度来看，我们的系统一般可以从上到下分为三层：业务（Biz）、应用（Application）、系统（System）。系统层是底层基础，代表了操作系统的相关状态；应用层为JVM层，覆盖主要应用进程和中间件的运行状态；业务层是最上层，从业务角度看是服务对外的运行状态。因此，在梳理大促的稳定性监控时，可以先脱离现有的监控，从核心和资产丢失环节入手，按照业务、应用（中间件、JVM、DB）和系统，然后根据这些指标找到对应的监控告警。如果不存在，相应添加；如果存在，检查阈值、时间、报警人是否合理。监控监控系统一般有四个黄金指标：Latency、Error、Traffic、Situation。每一层的重点监控也可以根据这四个指标进行分类，具体如下：表1中的告警是否需要对每个监控项进行告警？答案当然是否定的。建议优先在Biz层设置告警，因为Biz层对外服务提供最直观的业务表现，最贴合用户体验。Application&System层的指标主要用于监控，可以对一些关键、高危指标设置告警，用于故障排除和早期发现。对于一个告警，我们一般需要关注level、threshold、notifier等几个点。1）级别是指触发当前告警时问题的严重程度。一般来说，有几个衡量点：是否与GOC有关联，是否对业务造成严重影响，是否造成资金损失。2）阈值是告警的触发条件&时间，需要根据具体场景合理制定。一般遵循以下原则：不要太沉闷。在一个合理的监控系统中，一旦出现异常，就应该触发相关的告警。不要太敏感。过于敏感的阈值会导致频繁的警报，使响应者疲劳并且无法过滤掉真正的异常。如果告警频繁出现，一般有两种原因：系统设计不合理或阈值设置不合理。如果单个指标不能反馈覆盖整个业务场景，可以通过多个指标组合构建。需要顺应业务波动曲线，不同时间可以设置不同的条件和通知策略。3）通知者&方法如果业务指标异常（Biz层告警），通知者应该是问题处理者（开发运维同学）和业务关注人员（TL，业务同学）的集合，通知方法为更实时，比如电话通知。如果是应用&系统层告警，主要用于定位异常原因。通知人可以设置故障处理人员。通知方式可以考虑钉钉、短信等低干扰方式。除了关联级别之外，不同级别告警的通知者范围也可以适当扩大，尤其是与GOC故障相关的告警指标，范围要适当放宽，通知方式要更加实时和及时。直接的。应输出数据完成梳理工作后，应输出如下数据：系统监控模型，格式同表1。Biz、Application、System中有哪些需要监控的点？告警模型列表需要包含以下数据相关的监控指标（链接）。告警的关键级别是否推送到GOC，是否有资金损失，是否与故障相关。系统&应用指标面板包括核心系统的关键系统指标，可用于白盒监控和定位问题。4.CapacityPlanning——容量规划容量规划的本质是追求计算风险最小化和计算成本最小化之间的平衡，只追求其中之一是不合理的。为了使两者达到最佳平衡，需要尽可能准确地计算出系统的峰值负荷流量，然后根据单点资源负荷上限将流量换算成相应的容量来得到最终的容量规划模型。流量模型评估1）入口流量对于一个大促，系统的峰值入口流量通常由常规业务流量和非常规增量（如容灾计划变更带来的流量模型比例变化&商业营销策略）。(a)常规业务流量的计算方法一般有两类：历史流量算法：这类算法假设当年大促的增长率完全符合历史流量模型，计算当年-基于当前和过去一年每日流量的整体业务量的同比增量模型；然后根据历年大促-每日对比，计算预估流量链增量模型；对最后两个进行拟合，得到最终的评价数据。由于计算不需要依赖任何业务信息的输入，因此在保障工作初期，业务尚未给出业务总量评估时，可以利用该类算法得到初步预估业务流量。业务量-流量转换算法（GMVDAU订单量）：该类算法一般以预估总业务量（GMVDAU订单量）为输入，根据历史推广&每日业务量-流量转换模型（如经典漏洞模型）对应子域业务量评估。该方法严重依赖于对总业务量的估算，可用于保障工作的中后期，在初始业务流量估算的基础上考虑业务评价因素。(b)非常规增量流量一般是指系统应急预案实施后，前端业务营销策略改变或流量模型改变而引起的流量增量。例如，当NA61机房出现故障时，100%流量切换到NA62，造成增量变化。考虑到成本最小化，一般不需要将非常规增量P和常规业务流量W一起计算，全量计入叠加入口流量K中。一般会采用非常规策略的发生概率λ作为权重，即：2)节点流量节点流量由确定入口流量根据流量分支模型按比例转换。分支流量模型基于系统链路计算，遵循以下原则：同一入口，不同链路比例流量独立计算。对于同一条链路上的同一个节点，如果有多次调用，需要按倍数计算放大（如DBTair等）。注意DB写流量，可能会出现热点导致DB挂死。容量转换1)LittleLawDerivativeRules不同类型的资源节点（应用容器、Tair、DB、HBASE等）有不同的流量-容量转换比例，但都遵循LittleLawDerivativeRules，即：2）N+X冗余原则在满足目标流量所需的最小容量的基础上，冗余储备X单位冗余容量X与目标成本和资源节点的故障概率正相关。不可用的概率越高，X就越高。对于一般的应用容器集群，可以认为X=0.2N以上规则只能用于初始容量预估（大促压测&新增依赖前），最终准确的系统容量还是需要结合系统定期压力测试。输出数据应基于模型评估的ingress流量模型&集群自身容量的转换结果（如果是非ingress应用，则在限流点整理）。基于链路组合和外部依赖容量转换结果的分支流量模型。5事件响应-应急&预案梳理大促高并发流量背景下想要快速响应线上突发事件，仅靠值班同学的现场表现是远远不够的.在与时间赛跑中，不可能给加工人员留下足够的战略思考空间，错误的加工决策往往会导致更多的失控，对业务和系统造成严重的影响。因此，为了在宣传现场能够快速、正确地回答问题，值班同学需要做选择题（Which），而不是陈述题（What）。选项的组成是我们的业务和系统计划。从执行时机和解决问题的属性来划分，预案可分为技术应急预案、技术预案、业务应急预案和业务预案四类。结合前面的链路排序和业务评估结果，我们可以快速分析出链路中需要的应急方案，遵循以下原则：技术应急方案：这类应急方案用于处理某一级节点不可用的情况在系统链接中。例如技术/业务依赖性强、稳定性弱、风险高等节点不可用等异常场景。技术预案：这类预案用于平衡整体系统风险和单节点服务的可用性，通过熔断等策略保证全局服务的可靠性。例如，弱稳定性&弱依赖服务提前降级，与高峰流量时间冲突的离线任务提前暂定等。业务应急预案：该类预案用于处理业务变更等非系统性异常导致需要紧急处理的问题，如业务数据错误（数据正确性敏感节点）、业务策略调整（配合业务应急策略）)等。预案：这类预案用于匹配全球业务战略的预服务调整（非系统性需求）。应该输出数据。)触发阈值（应急预案，必须关联相关告警）关联影响（系统&业务）决策&执行&验证人员开启验证模式和关闭阈值（应急预案）关闭验证模式阶段性输出-全链路作战图完成以上几项保障任务，我们基本可以得到全局链路作战图，包括链路分支流量模型、强弱依赖节点、资产损失评估、对应方案&处理策略等信息。推广期间，可以利用地图从全局视角快速查看突发事件的影响，同时也可以基于地图反向评估规划和运力是否完善、合理。6.事件响应-实战手册梳理出操作手册是整个大促保障的行动依据。它贯穿于整个大促生命周期，可以分为活动前、活动中、活动后三个阶段来考虑。整体排序应以精、细为原则。理想情况下，即使是不熟悉业务和系统的轮班生，也能借助手册快速应对线上问题。Prefond1)Pre-checkitemlist大促前必须执行的检查项目列表，通常包括以下项目：集群机器重启或手动FGC影子表数据清理检查上下游机器权限检查限流值检查机器切换一致性检查数据库配置检查中间件文件容量、配置（DB缓存、NoSQL等）检查监控有效性（业务市场、技术市场、核心告警）每项需要包括具体执行者、检查计划、检查结果三项数据列2)预案领域和技术预案中的所有业务。进行中1)应急技术&业务预案拟包含的内容与预案基本相同，不同点如下：执行条件&恢复条件：具体的触发阈值，对应监控告警项。通知决策者。2）应急工具&脚本常见故障处理方法、核心告警止血方式（强弱依赖不可用等）、业务相关的日志钓鱼脚本等3）告警&仪表盘应包括业务、系统集群、中间件告警监控排序结果，核心业务和系统仪表盘，以及相应的日志数据源详情：日志数据源详情：数据源名称、文件位置、样本、分段格式。业务、系统集群、中间件告警监控结果：关联监控指标（链路）、告警临界级别、是否推送GOC、是否产生资金损失、是否关联故障、是否关联计划。CoreBusiness&SystemDashboard：Dashboard地址，包括指标详情（意思是，是否关联告警，对应的日志）。4)上下游机器组包括核心系统、上下游系统、不同机房、单元集群组、应用名称，可用于事前机器权限检查、事中黑屏处理应急排查.5)值班注意事项包括每个值班学生必须做的事情、紧急变更流程、与核心市场的联系等。6)核心广播指标包括核心系统&服务指标（CPULOADRT）、业务关注指标、等。每项指标应明确具体的监测地址和采集方式。7)域内&关联域人员通讯录及值班包括域内技术、TL、业务方对应轮班情况、联系方式（电话）、相关上下游、基础组件（DB、中间件等）)相应的值班状态。8)值班问题记录实战记录，记录工单、业务问题、应急预案（pre-emergency）（至少包括：时间、问题描述（截图）、影响分析、决策&解决过程等。).值日学生应在值日结束前进行记录。事后1）系统恢复设置列表（限流、减容）一般对应预检项目列表，包括限流阈值调整、集群缩容等大促后的恢复操作。2）大促问题回顾记录应包括大促中遇到的核心事件的总结。7事件响应——沙盘推演沙盘实战演练是应急响应的最后一道保障工作。推广期间以历史真实故障CASE作为应急场景的输入，模拟应急情况，旨在测试值班学员对应急问题处理的反应。一般来说，一个在线问题从发现到解决，需要经历定位、检查、诊断、修复的过程。一般遵循以下原则：尽可能将系统恢复到服务状态，同时保护现场进行根本原因调查（机器、日志、水位记录）。避免盲目搜索，基于白盒监控进行针对性诊断定位。分工有序，各司其职，避免成群结队失控混乱。根据现场情况实时评估影响范围，无法通过技术手段挽救的情况（如强依赖不可用），转化为业务问题思考（影响范围、程度、是否存在）资金损失，如何与业务方合作）。沙盘演练旨在考验值班学员的故障处理能力，重点围绕止血策略、分工安排、问题定位三个方面进行：国际华台双11买家域演练。根据故障类型，常见的止血策略有以下解决方案：流量：降低相应Provider服务源的限流值，以应对突发的大流量，导致自身系统和下游高依赖负载满负荷加载。下游降级：降级对应下游服务的下游弱依赖不可用。下游业务严重依赖业务同意后降级（业务部分损坏）。单点故障去除：当单机不可用节点水位飙升时，不可用单机服务优先下线（无需下线保持站点）。应对集群单点不可用、性能不佳。切换：单元流切换或切换备份由于自身原因（主机或网络）要处理单库或单元依赖，导致本地流量成功率下降。在GoogleSRE中，应急管理有以下几个要素：职责嵌套分离，即职能分工明确职能分工安排，达到各司其职、有序处理的效果，一般可分为以下角色：事故控制：负责协调分工和未分配的事务，掌握总体概况信息，一般为PM/TL服务。事务处理团队：真实的事故处理人员可以根据具体的业务场景和系统特点，分成多个小团队。班组内有域负责人与事故控制人员进行沟通。发言人：事故对外联络人员，负责事故处理内部成员与外部相关人员的定期信息同步，需要实时维护和更新事故文件。计划负责人：负责对外持续支持工作，如发生大面积故障、多班轮换时，负责组织责任交接记录。作者：开发助手_LS原文链接本文为阿里云原创内容，未经允许不得转载
