构建高效的容量保障体系
之前写过性能测试体系建设、质量保障机制构建的文章，最近重读有一些新的感触。
性能测试体系建设的内容偏向技术实践，质量保障机制构建的文章又类似方法论，中间存在一定Gap。
或者说在方法论和技术实践之间，我个人认为存在一个粘合的部分，能让其他人可循径前行落地的机制。
这篇文章如标题所述，我想基于容量保障这个话题，来尝试将方法论和技术实践中间的粘合部分描述出来。
思维导图
如上图所示，结合我个人实践经验，我理解的容量保障体系由这几部分构成：
容量保障对象：明确容量保障的对象是谁，有哪些特性，在什么时间可能有容量问题；
容量保障方法：方法是指导技术实践的抽象总结，定义了在容量保障过程中不同阶段做什么事情；
容量保障工具：工具主要作为支撑方法落地和提高过程效率的手段，上图列举了最重要的几个工具；
容量保障组织：容量保障涉及多个部门或团队，需要一个独立或虚拟团队负责协调资源和保持高效信息同步；
容量保障对象
构建容量保障体系之前，首先要明确被保障的对象是谁，有什么特性，什么时间可能会发生故障。
按照常见的一些工作场景，可以将其分为如下三类：
日常事件
日常事件指的是我们工作中经常会遇到的事情，比如有规律的版本迭代，业务拆分新服务上线等。
以版本迭代来说，可以通过梳理出核心业务+核心应用+核心链路+核心场景+核心接口的方式，将这些压测任务融入正常的版本迭代测试流程中。
这样做一方面是从研发测试流程上将日常容量保障做了流程化，另一方面也可将其作为一种长期的容量水位基线，来评估整体的性能变化趋势。
计划事件
计划事件指的是还未发生但将来要开展的事情。比如电商的双11，比如国家电网月初月末的电费缴纳，这些通过需求分析或者业务计划就可以明确的事情。
以双11来说，可以在活动开始前几个月就针对性的进行需求分析，指标分析，流量建模，链路梳理、预案准备等工作，并提前进行资源预购、单接口压测以及业务性能优化。
等到9-10月份，在线上开展全链路压测前，将很多性能容量问题提前解决掉，这样效率会更高。
突发事件
无论是日常事件还是计划事件，都是确定性比较强的，而突发事件则是没有确定性的。
面对突发性的紧急事件，应对措施主要有这几种：
- 提前评估可能发生的风险，并做好应对方案；
- 尝试混沌工程和容灾演练，不断丰富应对方案，提高团队面对突发情况的应对能力；
- 不断分析和优化业务以及技术架构，使系统具备弹性伸缩能力和一定的故障自愈措施（限流降级熔断）；
容量保障方法
了解了容量保障的对象特性之后，就可以针对性的进行技术实践了。
无论是日常事件还是突发事件，应对措施其实都是同一个流程，我将其分为如下几个阶段：
事前：需求分析、风险评估、技术方案、各种前置准备工作如测试数据测试脚本；
事中：压测执行、查看监控、分析指标和异常问题、定位分析优化、重复测试验证；
事后：针对测试验证过程中出现的问题进行复盘分析，找到当前团队的不足之处，不断迭代优化；
全局：这点也可以理解为长期的宏观视角，即长期目标。事前事中事后是比较详细的短期手段，解决具体的问题。
而容量保障需要从全局考虑，哪些方面需要纳入保障范围，全局角度存在什么风险，哪些方面当前没问题以后可能会出现问题。
全局角度来说，线上的容量基线（参考日常事件的解决方法），日常巡检治理（慢sql/异常/毛刺指标/redis大key）等都是需要长期进行治理的。
而这个治理过程，则可以通过事前事中事后的方式来落地验证效果。
容量保障工具
聊完容量保障方法，接下来聊聊容量保障的一些工具。
压测平台
要做好容量保障，容量测试是必备的一个环节和手段。
传统的压测，都是每个场景重新写脚本，造数据，手动或者命令行启动压测。
这样的做法不仅效率低，不利于多人协同，而且每个人的能力、工作习惯都不一样，对于复杂的业务场景和比较大的团队来说，是很难达到高效的容量保障的。
而平台的好处在于，通过平台提供标准化操作，将不同个体差异通过流程化的方式约束起来，减少重复造轮子和轮子之间差异导致的排查和解决问题的成本，进一步提高人效。
压测平台一方面可以将脚本和数据进行持久化管理，另一方面也可以将压测的结果进行长期存储，便于分析和优化。
关于压测平台详细的落地实践，我会在下一篇文章重点说明。
监控平台
容量测试很重要，但更快的发现问题和高效的分析定位瓶颈也很重要。
而一个比较完善的监控平台（体系）可以提高发现问题的速度和定位分析问题的效率。
要对监控有个全面的了解，大体要了解三方面的知识，如下图所示：
一般在企业级监控领域，大体分为五种类型的监控：
- 基础监控：包括带宽、CDN、服务器CPU、Memory、DiskIO、Network、Load5等指标；
- 指标监控：服务+接口维度，常见指标有QPS、TPS、SLB、RT、99RT、timeout、activethreads等指标；
- 业务监控：拿电商来说，常见的有同比下单量、支付量、履约率、DAU、GMV、支付取消率等多重指标，一般需要根据具体的业务需要来定制化；
- 链路监控：链路监控主要用来快速定位排查问题，在目前大多数互联网公司的微服务架构下，服务调用关系复杂，链路追踪监控可以帮助技术同学快速的找到调用链路上某个环节的问题；
- 舆情监控：主要指对外部的一些讯息的监控，比如某APP突然挂了、下不了单、有BUG可以刷单、客诉等一些列对企业或者品牌不利的因素，便于快速处理甚至公关；
当然，开源成熟或者商业的监控工具和框架已经很多了，常见的工具如下表：
|
工具名称 |
工具作用 |
类似工具 |
|
grafana |
可视化监控面板，可自由定制 |
kibana |
|
exporters |
数据采集工具，兼容多种操作系统 |
telegraf |
|
promethous |
时序数据库，存储exporters采集的数据 |
influxdb |
|
skywalking |
链路追踪，请求调用链耗时/状态展示 |
cat/pinpoint |
|
mysqlreport |
mysql全局监控工具 |
pt-query-digest |
|
jvisualvm |
Java代码分析工具，JVM自带 |
arthas/google-perftools |
更多监控相关的内容，请参考我前面的文章：《我经历过的监控系统演进史》、《监控能给你带来什么》。
发布平台
前面的文章中提到了容量保障一个很重要的词，就是系统要具备弹性伸缩的能力。
现在的互联网企业，无论是分布式的架构还是基于容器/云原生的微服务架构，基本都具备这种能力。
而弹性伸缩的能力要么是公有云自带的，要么是自建的能力，这种能力一般都是在发布平台进行管理。
还有一点比较重要的是，性能优化后需要进行再次验证，而发布平台所具备的CICD能力可以降低这个等待的过程，快速提高服务重新发布的速度，如果集成了自动化测试在发布流程里，可以更好的提高发布的质量。
毕竟，容量很重要，质量也很重要。
预案平台
在容量保障和容量治理过程中，我们面对日常事件和突发事件，其实都是针对可能出现的问题进行前置评估和预防。
这些预防的手段可以是弹性扩容，可以是限流降级熔断隔离，但最终这些手段都是需要去执行并且保证有效的。
如果是手动去执行，难免出现错误，造成更大的损失。
而预案平台就是将这些应对可能出现的故障的手段，通过平台固化下来，让其具备一定的自动处理能力，即我们所说的故障自愈。还有一点就是降低人员无法及时响应或者误操作引起的问题。预案平台有几点需要明确的是：
- 所有的预案都应该经过评估和验证确保有效；
- 所有的预案执行和变更都应经过审批和授权；
- 所有预案的执行和变更都需要经过快速决策；
容量保障组织
容量保障是个复杂的软件技术工作实践，涉及到多个团队或者部门，这种复杂的需要跨团队沟通协作的技术实践，需要极高的组织能力和项目推进能力，因此一个专门负责容量保障的团队是必须的。
这个团队不一定需要专职，团队可以是虚拟的组织，团队成员从各个其他团队选择有经验有能力的同学担任。但无论是专职还是虚拟，容量保障和响应线上突发情况的优先级对他们来说是最高的。
容量保障团队，主要的职责有如下几点：
- 沉淀案例库：容量保障是个复杂的技术项目，特别是针对一些比较棘手的问题，定位分析和优化过程，经过复盘后都是很好的案例，可以帮助日常工作更好的开展；
- 制定流程规范：复杂的跨团队的技术实践，需要制定流程规范，让大家保持同一个方向和频次去落地的。因此制定流程规范并且推进规范的执行也是容量保障团队的重要职责；
- 降本增效运营：容量保障最重要的目的就是保障线上稳定性，降低成本。稳定性的提升和成本的降低也能从另一个角度促进团队效率的提高。而且容量保障是一个长期的持续的技术实践，需要持续的运营来保证稳定性的不断提升。
- 跨团队协调推进：复杂的跨团队的技术实践，需要制定流程规范，但是更需要有专门的角色来负责推动跨团队的协作以及信息的透明和同步。而且在企业内，不同部门之间的资源协调也是个很有意思的事情，需要专门的获得授权的团队才能从一定程度上解决部门墙问题。
