稳定性保障6步走：高可用系统大促作战指南！

一 前言

年年有大促，大家对于大促稳定性保障这个词都不陌生，业务场景尽管各不相同，“套路”往往殊路同归，全链路压测、容量评估、限流、紧急预案等，来来去去总少不了那么几板斧。

跳出这些“套路”，回到问题的本质，我们为什么要按照这些策略来做？

除了口口相传的历史经验，我们还能做些什么？又有什么理论依据？

二 怎样的系统算是稳定？

首先回答另一个问题，怎样的系统算是稳定的？

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个月左右）。

考虑到上述特性，我们如何在短时间内针对大促大流量业务场景对系统稳定性需求进行优化巩固？

既然时间有限，盲目撒网必然不是最佳策略，需要有针对性地从关键点、薄弱点下手。因此第一步，需要获得全局系统链路现状，包括关键外部依赖、重点业务影响等，找到整体保障的核心关注点。接下来进一步分析大促业务数据，得到除系统本身以外的变量干扰因素。以这两者为基础，集中围绕金字塔模型中系统监控、规划容量、应急响应、测试和复盘等几个方面需求对系统进行针对性集中保障建设，得到最终保障结果。

至此，基本获得了完整的大促稳定性保障策略方向，按照执行顺序依次是：

1. 系统链路&业务策略梳理（System & Biz Profiling）
2. 监控（Monitoring）
3. 容量规划（Capacity Planning）
4. 应急响应（Incident Response）
5. 测试
6. 事后总结（Testing & Postmortem）

1 System & Biz Profiling - 系统链路梳理

系统链路梳理是所有保障工作的基础，如同对整体应用系统进行一次全面体检，从流量入口开始，按照链路轨迹，逐级分层节点，得到系统全局画像与核心保障点。

入口梳理盘点

一个系统往往存在十几个甚至更多流量入口，包含HTTP、RPC、消息等都多种来源。如果无法覆盖所有所有链路，可以从以下三类入口开始进行梳理：

• 核心