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