简介： 年年有大促，大家对于大促稳定性保障这个词都不生疏，业务场景只管各不相同，“套路”往往殊路同归，全链路压测、容量评估、限流、紧急预案等，来来去去总少不了那么几板斧。跳出这些“套路”，回到问题的实质，咱们为什么要依照这些策略来做？除了口口相传的历史教训，咱们还能做些什么？又有什么理论依据？
一 、前言
年年有大促，大家对于大促稳定性保障这个词都不生疏，业务场景只管各不相同，“套路”往往殊路同归，全链路压测、容量评估、限流、紧急预案等，来来去去总少不了那么几板斧。
跳出这些“套路”，回到问题的实质，咱们为什么要依照这些策略来做？
除了口口相传的历史教训，咱们还能做些什么？又有什么理论依据？
二 、怎么的零碎算是稳固？
首先答复另一个问题，怎么的零碎算是稳固的？
Google SRE中(SRE三部曲[1])有一个层级模型来形容系统可靠性根底和高层次需要(Dickerson's Hierarchy of Service Reliability)，如下图：
该模型由Google SRE工程师Mikey Dickerson在2013年提出，将零碎稳定性需要依照根底水平进行了不同档次的体系化辨别，造成稳定性规范金字塔模型。
金字塔的底座是监控(Monitoring)，这是一个零碎对于稳定性最根底的要求，短少监控的零碎，如同蒙上眼睛狂奔的野马，无从谈及可控性，更遑论稳定性。更下层是应急响应(Incident Response)，从一个问题被监控发现到最终解决，这期间的耗时间接取决于应急响应机制的成熟度。正当的应急策略能保障当故障产生时，所有问题能失去有序且妥善的解决，而不是慌乱成一锅粥。预先总结以及根因剖析(Postmortem&Root Caue Analysis)，即咱们平时谈到的“复盘”，尽管很多人都不太喜爱这项流动，然而不得不抵赖这是防止咱们下次犯同样谬误的最无效伎俩，只有当摸清故障的根因以及对应的缺点，咱们能力隔靴搔痒，正当进行躲避。
假如一个零碎从首次公布后就不再进行更新迭代，做好上述三个方面的工作就能根本满足零碎对于稳定性的全副需要。惋惜目前根本不会存在这样的零碎，大大小小的利用都离不开一直的变更与公布，因而要保证系统在这些迭代中继续稳固，测试和公布管控(Testing&Release procedures)是必不可少的。无效的测试与公布策略能保障系统所有新增变量都处于可控稳固区间内，从而达到整体服务终态稳固。除了代码逻辑更新，迭代同样可能带来业务规模及流量的变动，容量布局(Capacity Planning)则是针对于这方面变动进行的保障策略。现有零碎体量是否足够撑持新的流量需要，整体链路上是否存在不对等的单薄节点，都是容量布局须要思考的问题。
位于金字塔模型最顶端的是产品设计(Product)与软件研发(Development)，即通过优良的产品设计与软件设计使零碎具备更高的可靠性，构建高可用产品架构体系，从而晋升用户体验。
三 、大促稳定性保障办法
从金字塔模型咱们能够看到构建保护一个高可用服务所须要做到的几方面工作，那么问题回到大促稳定性，如何体系化地保障大促期间零碎稳定性？
大促保障实际上针对于特定业务场景的集中稳定性建设工作，相较于日常保障工作，具备高并发流量、短保障周期的特点，对系统性能与保障工夫有明确要求（个别为2个月左右）。
思考到上述个性，咱们如何在短时间内针对大促大流量业务场景对系统稳定性需要进行优化坚固？
既然工夫无限，自觉撒网必然不是最佳策略，须要有针对性地从关键点、薄弱点下手。因而第一步，须要取得全局零碎链路现状，包含要害内部依赖、重点业务影响等，找到整体保障的外围关注点。接下来进一步剖析大促业务数据，失去除零碎自身以外的变量烦扰因素。以这两者为根底，集中围绕金字塔模型中系统监控、布局容量、应急响应、测试和复盘等几个方面需要对系统进行针对性集中保障建设，失去最终保障后果。
至此，根本取得了残缺的大促稳定性保障策略方向，依照执行程序顺次是：
- 零碎链路&业务策略梳理（System & Biz Profiling）
- 监控（Monitoring）
- 容量布局（Capacity Planning）
- 应急响应（Incident Response）
- 测试
- 预先总结（Testing & Postmortem）
1、 System & Biz Profiling - 零碎链路梳理
零碎链路梳理是所有保障工作的根底，如同对整体利用零碎进行一次全面体检，从流量入口开始，依照链路轨迹，逐级分层节点，失去零碎全局画像与外围保障点。
入口梳理盘点
一个零碎往往存在十几个甚至更多流量入口，蕴含HTTP、RPC、音讯等都多种起源。如果无奈笼罩所有所有链路，能够从以下三类入口开始进行梳理：
- 外围重保流量入口用户承诺服务SLI较高，对数据准确性、服务响应工夫、牢靠度具备明确要求。面向企业级用户
- 资损事件对应入口关联到公司资金支出或者客户资金支出免费服务
- 大流量入口零碎TPS&QPS TOP5~10该类入口尽管不波及较高SLI与资损要求，然而流量较高，对整体零碎负载有较大影响。
节点分层判断
流量入口就如同线团中的线头，挑出线头后就可依照流量轨迹对链路上的节点(HSFDBTairHBase等所有内部依赖)依照依赖水平、可用性、可靠性进行高级分层辨别。
（1）强弱依赖节点判断
- 若节点不可用，链路业务逻辑被中断 or 高级别有损(存在肯定耐受阈值)，则为业务强依赖；反之为弱依赖。
- 若节点不可用，链路执行逻辑被中断(return error)，则为零碎强依赖；反之为弱依赖。
- 若节点不可用，零碎性能受影响，则为零碎强依赖；反之为弱依赖。依照疾速失败设计逻辑，该类节点不应存在，然而在不变更利用代码前提下，如果呈现该类节点，应作为强依赖对待。
- 若节点无感可降级 or 存在业务轻微伤害替换计划，则为弱依赖。
（2）低可用依赖节点判断
- 节点服务日常超时重大
- 节点对应系统资源有余
（3）高风险节点判断
- 上次大促后，节点存在大版本零碎革新
- 新上线未经验过大促的节点
- 节点对应零碎是否已经呈现高级别故障
- 节点故障后存在资损危险
应产出数据
实现该项梳理工作后，咱们应该产出以下数据：对应业务域所有外围链路剖析，技术&业务强依赖、外围上游、上游零碎、资损危险应明确标注。
下图为单条链路剖析示例：
2、 System & Biz Profiling - 业务策略同步
不同于高可用零碎建设体系，大促稳定性保障体系与面向特定业务流动的针对性保障建设，因而，业务策略与数据是咱们进行保障前不可或缺的数据。
个别大促业务数据可分为两类，全局业务状态评估以及应急策略&玩法。
全局评估
该类数据从能够帮忙咱们进行精准流量评估、峰值预测、大促人力排班等等，个别蕴含上面几类：
- 大促业务时长（XX日-XX日）
- 业务量预估体量（日常X倍）
- 预估峰值日期
- 业务场景预估流量调配
应急策略
该类数据指相较于今年大促流动，本次大促业务变量，可用于应急响应预案与高风险节点评估等，个别蕴含上面两类：
- 非凡业务玩法
- 应急状况打法策略
3 、Monitoring - 监控&告警梳理
目前业界罕用的监控伎俩个别有两种模式，黑盒监控(Black-box monitoring)与白盒监控(White-box monitoring)。黑盒监控面向对象，个别监控正在产生（而非行将产生）的异样，即零碎现有故障。而白盒监控次要依赖零碎外部指标监控，面向对象的同时也面向起因，可对系统行将面临的异样进行提前预警，也可在异样产生时同步监控上层外部指标，从而定位根本原因。因而大促稳定性保障中，咱们个别抉择的是白盒监控。
站在监控的角度看，咱们的零碎从上到下个别能够分为三层：业务（Biz）、利用（Application）、零碎（System）。零碎层为最上层根底，示意操作系统相干状态；应用层为JVM层，涵盖主利用过程与中间件运行状态；业务层为最上层，为业务视角下服务对外运行状态。
因而进行大促稳定性监控梳理时，能够先脱离现有监控，先从外围、资损链路开始，依照业务、利用（中间件、JVM、DB）、零碎三个档次梳理须要哪些监控，再从依据这些索引找到对应的监控告警，如果不存在，则相应补上；如果存在则查看阈值、工夫、告警人是否正当。
监控
监控零碎个别有四项黄金指标：延时（Latency）, 谬误（Error）,流量（Traffic）, 饱和度（Situation），各层的关键性监控同样也能够依照这四项指标来进行归类，具体如下：
表 1
告警
是不是每项监控都须要告警？答案当然是否定的。倡议优先设置Biz层告警，因为Biz层咱们对外服务最直观业务体现，最贴切用户感触。Application&System层指标次要用于监控，局部要害&高风险指标可设置告警，用于问题排查定位以及故障提前发现。
对于一项告警，咱们个别须要关注级别、阈值、告诉人等几个点。
1）级别
即以后告警被触发时，问题的重大水平，一般来说有几个掂量点：
- 是否关联GOC
- 是否产生重大业务影响
- 是否产生资损
2）阈值
即一项告警的触发条件&工夫，需依据具体场景正当制订。个别遵循以下准则：
- 不可过于机灵。一个正当的监控体系中，任何异样产生后都应触发相干告警。
- 不可过于敏感。过于敏感的阈值会造成频繁告警，从而导致响应人员疲劳应答，无奈筛选实在异样。若一个告警频繁呈现，个别是两个起因：零碎设计不合理 or 阈值设置不合理。
- 若繁多指标无奈反馈笼罩整体业务场景，可联合多项指标关联构建。
- 需合乎业务稳定曲线，不同时段可设置不同条件&告诉策略。
3）告诉人&形式
若为业务指标异样(Biz层告警)，告诉人应为问题解决人员(开发、运维同学)与业务关注人员(TL、业务同学)的汇合，告诉形式较为实时，比方电话告诉。
若为利用 & 零碎层告警，次要用于定位异样起因，告诉人设置问题排查解决人员即可，告诉形式可思考钉钉、短信等低烦扰形式。
除了关联档次，对于不同级别的告警，告诉人范畴也可适当扩充，尤其是关联GOC故障的告警指标，应适当放宽范畴，告诉形式也应更为实时间接。
应产出数据
实现该项梳理工作后，咱们应该产出以下数据：
- 系统监控模型，格局同表1Biz、Application、System 别离存在哪些待监控点监控点是否已全副存在指标，仍有哪些待补充
- 零碎告警模型列表，需蕴含以下数据关联监控指标（链接）告警要害级别是否推送GOC是否产生资损是否关联故障是否关联预案
- 业务指标大盘，蕴含Biz层重点监控指标数据。
- 零碎&利用指标大盘，蕴含外围零碎要害零碎指标，可用于白盒监控定位问题。
4 、Capacity Planning - 容量布局
容量布局的实质是谋求计算危险最小化和计算成本最小化之间的均衡，只谋求任意其一都不是正当的。为了达到这两者的最佳平衡点，需尽量精准计算零碎峰值负载流量，再将流量依据单点资源负载下限换算成相应容量，失去最终容量布局模型。
流量模型评估
1）入口流量
对于一次大促，零碎峰值入口流量个别由惯例业务流量与非常规增量（比方容灾预案&业务营销策略变动带来的流量模型配比变动）叠加拟合而成。
（a）惯例业务流量个别有两类计算形式：
历史流量算法：该类算法假如当年大促增幅完全符合历史流量模型，依据以后&历年日常流量，计算整体业务体量同比增量模型；而后依据历年大促-日常比照，计算预估流量环比增量模型；最初二者拟合失去最终评估数据。
因为计算时无需依赖任何业务信息输出，该类算法可用于保障工作初期业务尚未给出业务总量评估时应用，失去初估业务流量。
业务量-流量转化算法(GMVDAU订单量)：该类算法个别以业务预估总量（GMVDAU订单量）为输出，依据历史大促&日常业务量-流量转化模型（比方经典破绽模型）换算失去对应子域业务体量评估。
该种形式强依赖业务总量预估，可在保障工作中后期应用，在初估业务流量根底上纳入业务评估因素思考。
（b）非常规增量个别指前台业务营销策略变更或零碎应急预案执行后流量模型变动造成的增量流量。例如，NA61机房故障时，流量100%切换到NA62后，带来的增量变动。
思考到老本最小化，非常规增量P计算时个别无需与惯例业务流量W一起，全量纳入叠加入口流量K，个别会将非常规策略产生概率作为权重，即：
2）节点流量
节点流量由入口流量依据流量分支模型，按比例转化而来。分支流量模型以零碎链路为计算根底，遵循以下准则：
- 同一入口，不同链路占比流量独立计算。
- 针对同一链路上同一节点，若存在屡次调用，需计算按倍数同比放大（比方DBTair等）。
- DB写流量重点关注，可能呈现热点造成DB HANG死。
容量转化
1）Little Law衍生法令
不同类型资源节点(利用容器、Tair、DB、HBASE等)流量-容量转化比各不相同，但都遵从Little Law衍生法令，即：
2）N + X 冗余准则
- 在满足指标流量所须要的最小容量根底上，冗余保留X单位冗余能力
- X与指标老本与资源节点故障概率成正相干，不可用概率越高，X越高
- 对于个别利用容器集群，可思考X = 0.2N
上述法令只能用于容量初估(大促压测前&新依赖)，最终精准零碎容量还是须要联合零碎周期性压力测试得出。
应产出数据
- 基于模型评估的入口流量模型 & 集群本身容量转化后果（若为非入口利用，则为限流点梳理）。
- 基于链路梳理的分支流量模型 & 内部依赖容量转化后果。
5 Incident Response - 紧急&前置预案梳理
要想在大促高并发流量场景下疾速对线上紧急事变进行响应解决，仅仅依赖值班同学临场发挥是远远不够的。争分夺秒的状况下，无奈给解决人员留有短缺的策略思考空间，而谬误的解决决策，往往会导致更为失控重大的业务&零碎影响。因而，要想在大促现场疾速而正确的响应问题，值班同学须要做的是选择题(Which)，而不是陈说题(What)。而选项的形成，便是咱们的业务&零碎预案。
从执行机会与解决问题属性来划分，预案可分为技术应急预案、技术前置预案、业务应急预案、业务前置预案等四大类。联合之前的链路梳理和业务评估后果，咱们能够疾速剖析出链路中须要的预案，遵循以下准则：
- 技术应急预案：该类预案用于解决零碎链路中，某档次节点不可用的状况，例如技术/业务强依赖、弱稳定性、高风险等节点不可用等异样场景。
- 技术前置预案：该类预案用于均衡整体零碎危险与单节点服务可用性，通过熔断等策略保障全局服务牢靠。例如弱稳定性&弱依赖服务提前降级、与峰值流量工夫抵触的离线工作提前暂定等。
- 业务应急预案：该类预案用于应答业务变更等非系统性异样带来的需应急解决问题，例如业务数据谬误（数据正确性敏感节点）、务策略调整（配合业务应急策略）等
- 业务前置预案：该类预案用于配和业务全局策略进行的前置服务调整（非系统性需要）
应产出数据
实现该项梳理工作后，咱们应该产出以下数据：
- 执行&敞开工夫（前置预案）
- 触发阈值（紧急预案，须关联相干告警）
- 关联影响（零碎&业务）
- 决策&执行&验证人员
- 开启验证形式
- 敞开阈值（紧急预案）
- 敞开验证形式
阶段性产出-全链路作战地图
进行完上述几项保障工作，咱们根本可失去全局链路作战地图，蕴含链路分支流量模型、强弱依赖节点、资损评估、对应预案&解决策略等信息。大促期间可凭借该地图疾速从全局视角查看应急事件相干影响，同时也可依据地图反向评估预案、容量等梳理是否欠缺正当。
6 、Incident Response - 作战手册梳理
作战手册是整个大促保障的口头根据，贯通于整个大促生命周期，可从事前、事中、预先三个阶段开展思考。
整体梳理应本着精准化、精细化的准则，现实状态下，即使是对业务、零碎不相熟的轮班同学，凭借手册也能疾速响应解决线上问题。
事先
1）前置查看事项清单
大促前必须执行事项checklist,通常蕴含以下事项：
- 集群机器重启 or 手动FGC
- 影子表数据清理
- 查看上下游机器权限
- 查看限流值
- 查看机器开关一致性
- 查看数据库配置
- 查看中间件容量、配置(DB缓存NoSQL等)
- 查看监控有效性（业务大盘、技术大盘、外围告警）
- 每个事项都需蕴含具体执行人、查看计划、查看后果三列数据
2）前置预案
域内所有业务&技术前置预案。
事中
1）紧急技术&业务预案
须要蕴含的内容根本同前置预案，差别点如下：
- 执行条件&复原条件：具体触发阈值，对应监控告警项。
- 告诉决策人。
2）应急工具&脚本
常见故障排查形式、外围告警止血形式(强弱依赖不可用等)，业务相干日志捞取脚本等。
3）告警&大盘
应蕴含业务、零碎集群及中间件告警监控梳理后果，外围业务以及零碎大盘，对应日志数据源明细等数据：
- 日志数据源明细：数据源名称、文件地位、样例、切分格局。
- 业务、零碎集群及中间件告警监控梳理后果：关联监控指标（链接）、告警要害级别、是否推送GOC、是否产生资损、是否关联故障、是否关联预案。
- 外围业务&零碎大盘：大盘地址、蕴含指标明细(含意、是否关联告警、对应日志)。
4）上下游机器分组
应蕴含外围零碎、上下游零碎，在不同机房、单元集群分组、利用名，可用于事先-机器权限查看、事中-应急问题排查黑屏解决。
5）值班注意事项
蕴含每班轮班同学值班必做事项、应急变更流程、外围大盘链接等。
6）外围播报指标
蕴含外围零碎&服务指标(CPULOADRT)、业务关注指标等，每项指标应明确具体监控地址、采集形式。
7）域内&关联域人员通讯录、值班
蕴含域内技术、TL、业务方对应排班状况、联系方式(电话)，相干上下游、根底组件(DB、中间件等)对应值班状况。
8）值班问题记录
作战记录，记录工单、业务问题、预案(前置紧急)（至多蕴含：工夫、问题形容（截图）、影响剖析、决策&解决过程等）。值班同学在值班完结前，进行记录。
预先
1）零碎复原设置事项清单(限流、缩容)
个别与事先查看事项清单对应，蕴含限流阈值调整、集群缩容等大促后复原操作。
2）大促问题复盘记录
应蕴含大促遇到的外围事件总结梳理。
7 Incident Response - 沙盘推演
实战沙盘演练是应急响应方面的最初一项保障工作，以历史实在故障CASE作为应急场景输出，模仿大促期间紧急状况，旨在考验值班同学们对应急问题解决的响应状况。
一般来说，一个线上问题从发现到解决，两头须要经验定位&排查&诊断&修复等过程，总体遵循以下几点准则：
- 尽最大可能让零碎先复原服务，同时为本源考察爱护现场（机器、日志、水位记录）。
- 防止自觉搜寻，根据白盒监控针对性诊断定位。
- 有序分工，各司其职，防止一窝蜂失控乱象。
- 根据现场状况实时评估影响范畴，切实无奈通过技术手段解救的状况(例如强依赖不可用)，转化为业务问题思考（影响范畴、水平、是否有资损、如何协同业务方）。
- 沙盘演练旨在测验值班同学故障解决能力，着重关注止血策略、分工安顿、问题定位等三个方面：
国际化中台双11买家域演练
依据故障类型，常见止血策略有以下解决思路：
- 入口限流：调低对应Provider服务起源限流值应答突发流量过高导致本身零碎、上游强依赖负载被打满。
- 上游降级：降级对应上游服务上游弱依赖不可用。上游业务强依赖经业务批准后降级（业务局部有损）。
- 单点失败移除：摘除不可用节点单机水位飙高时，先下线不可用单机服务（无需下线机器，保留现场）。应答集群单点不可用、性能差。
- 切换：单元切流或者切换备份应答单库或某单元依赖因为本身起因（宿主机或网络），造成部分流量成功率上涨上涨。
Google SRE中，对于紧急事变治理有以下几点因素：
- 嵌套式职责拆散，即分确的职能分工安顿
- 控制中心作战室
- 实时事变状态文档
- 明确公开的职责交接
其中嵌套式职责拆散，即分确的职能分工安顿，达到各司其职，有序解决的成果，个别可分为下列几个角色：
- 事变总控：负责协调分工以及未调配事务兜底工作，把握全局概要信息，个别为PM/TL负责。
- 事务处理团队：事变真正解决人员，可依据具体业务场景&零碎个性分为多个小团队。团队外部存在域内负责人，与事变总控人员进行沟通。
- 发言人：事变对外联系人员，负责对事变解决外部成员以及内部关注人员信息做周期性信息同步，同时须要实时保护更新事变文档。
- 布局负责人：负责内部持续性反对工作，比方当大型故障呈现，多轮排班轮转时，负责组织职责交接记录。
作者：开发者小助手_LS
原文链接
本文为阿里云原创内容，未经容许不得转载