高楼的性能工程实战课笔记-005-性能方案

传统测试方案：
    常规项目信息：比如说测试背景、测试范围、测试准则、测试环境、实施准备、组织结构、项目风险、里程碑。
    性能实施信息：比如说测试模型、测试策略、监控策略。
    项目输出：比如说测试脚本、测试用例/测试场景、监控采集数据，测试报告、调优报告。
工程级完整测试方案
    背景
        项目背景
        性能目标
    测试范围
        需要测试的特性
        不需要测试的特性
    准则
        启动准则
        结束准则
        暂停/再启动准则
    业务横型和性能指标
        业务模型/测试模型
        业务指标/性能指标
    系统架构图
        系统技术栈
        系统逻辑架构图
        系统部署架构图
    性能实施前提条件    
        硬件环境
        工具准备
            测试工具
            监控工具
        数据准备
            基础数据
    性能设计
        场景执行策略
            场景递增策略
            业务场景
                基准场景
                容量场景
                稳定性场景
                异常场景
        监控设计：
            全局监控
            定向监控
    项目组织架构
    成果输出：
        过程性输出
        结果输出
            性能项目测试报告
            性能调优报告
    项目风险分析
    
方案细化：    
    性能目标【在每一个性能项目中，性能目标都会影响项目的整个过程。因此，对目标的把握将决定一个性能项目的走向。】
        1. 根据经典的电商下单流程，测试当前系统的单接口最大容量。
        2. 根据业务比例设计容量场景，充分利用当前资源，找到当前系统的性能瓶颈，并优化，以达到系统的最佳运行状态。
        3. 根据稳定性场景，判断当前系统可支持的系统最大累加容量。
        4. 根据异常场景，判断当前系统中的异常对性能产生的影响。
        
    测试范围
        需要测试的特性
            列举需要测试的场景及涉及到的接口
            
        不需要测试的特性
        
    准则
        启动准则
            1. 确定系统逻辑架构和部署架构和生产一致。
            2. 确定基础数据和生产一致或按模型缩放。
            3. 确定业务模型可以模拟生产真实业务。
            4. 环境准备完毕，包括：
                4.1. 功能验证通过。
                4.2. 各组件基础参数梳理并配置正确。
                4.3. 压力机到位，并部署完毕。
                4.4. 网络配置正确，连接通畅，可以满足压力测试需求。
            5. 测试计划、方案评审完毕。
            6. 架构组、运维组、开发组、测试组及相关专家人员到位。
        结束准则
            1. 达到项目要求的性能需求指标。
            2. 关键性能瓶颈已解决。
            3. 完成性能测试报告和性能调优报告。
        暂停 / 再启动准则
            1. 暂停准则
                <1>. 系统环境变化：举例：系统主机硬件损坏、网络传输时间超长、压力发生器出现损坏、系统主机因别的原因需升级暂停等。
                <2>. 测试环境受到干扰，比如服务器被临时征用，或服务器的其他使用会对测试结果造成干扰。
                <3>. 需要调整测试环境资源，如操作系统、数据库参数等。
                <4>. 该测试机型无法达到规划指标要求。
                <5>. 出现测试风险中列出的问题。
            2. 再启动准则
                <1>. 测试中发现问题得以解决。
                <2>. 测试环境恢复正常。
                <3>. 测试风险中出现的问题已解决。
                <4>. 环境调整完毕。
    业务横型和性能指标
        业务模型/测试模型
            涉及接口及所占比例【从生产环境中取得的业务比例。】
        业务指标/性能指标
        
    系统架构图
        系统技术栈
            整个架构中用了哪些技术组件。
            技术组件中有哪些常见的性能瓶颈点，有哪些性能参数
        系统逻辑架构图
            逻辑架构图是为了后续性能分析的时候，脑子里能有一个业务路径。
            我们在做性能分析时，要做响应时间的拆分，而只有了解了逻辑架构图才可以知道从哪里拆到哪里。
        系统部署架构图
            为了让我们知道有多少节点、多少机器。
            在执行容量场景时，脑子里要有一个概念，就是这样的部署架构最大应该可以支持多少的容量上限。
    性能实施前提条件    
        硬件环境
            作为性能从业人员，我们必须要了解硬件配置和整体业务容量之间的关系。
        工具准备
            测试工具
            监控工具
                在全局监控中，我们要尽量避免使用定向的监控手段
                参考线上运维的监控手段,不要自己臆想，随意搭建监控工具。
        数据准备
            基础数据
                1. 满足生产环境的真实数据分布,最合理的方式是脱敏生产数据。
                2. 参数化数据一定要使用基础数据来覆盖真实用户
        性能设计
            场景执行策略：============要模拟生产场景，连续递增一定要做到的，不容迟疑。
                性能的场景必须满足两个条件：
                    连续
                    递增:递增过程中，被测系统的资源要动态分配。系统可能在这个时候抖动
                场景递增策略
                业务场景：执行顺序先后为：基准场景、容量场景、稳定性场景、异常场景。
                    基准场景：基准场景必须是容量场景的前奏。
                        在基准场景中，通过递增连续的场景做到最大 TPS。在基准场景中，我们要把单接口或单业务压到最大 TPS，然后来分析单接口或单业务的瓶颈点在哪里。
                        如果单接口或单业务的最大 TPS超过目标TPS，并且响应时间也在业务可接受的范围之内，那就不用调优。如果没有超过，那必须要做调优。
                        
                        根据 RESAR 性能工程理论，性能执行的第一阶段目标就是把资源用光，第二阶段的目标是将系统优化到满足业务容量。
                    容量场景
                        在容量场景中，秉承“连续、递增”的执行思路，最重要的是，要实现业务模型，来真实模拟线上的业务场景。
                        JMeter可以通过调整 线程数+Throughput Controller 来控制业务比例
                        
                        【注意】：
                            1. 容量场景的最大 TPS 是指最大的稳定 TPS。在已经抖动了，已经不稳定了的压测中，我们再去找它的最大 TPS 没有意义
                            2. 以后尽量不要再用“性能拐点”这个词来尝试描述性能的曲线，除非你是真的看到了拐点。
                    稳定性场景
                        在稳定性场景中，我们只有两个关键点：
                            1. 第一个关键点：稳定性场景的时长【怎么计算？】。在性能的稳定性场景中，我们要完全覆盖业务容量。
                                在运维周期内，有 1 亿笔业务容量。根据上面容量场景中的测试结果，假设最大稳定 TPS 是 500，那稳定性场景的执行时长就是：稳定性时长=100000000÷500÷3600÷24≈2.3(天)
                            2. 第二个关键点：用多大的 TPS 来执行。
                                在执行稳定性场景时，完全可以用最大的稳定 TPS 来运行【不比非要使用传说中的80%】，只要覆盖了运维周期之内的业务容量即可。
                    异常场景
                        对于常规的异常场景，我们经常做的就是：
                        宕主机；
                        宕网卡；
                        宕应用
                        宕容器
                        
                        也可以用一些所谓的“混沌工程“的工具来实现对容器的随机删除、网络丢包、模拟 CPU 高等操作
            监控设计：
                全局监控
                    Prometheus/Grafana/Spring Boot Admin/SkyWalking/Weave Scope/ELK/EFK 就可以实现具有全局视角的第一层监控。
                定向监控
                    有问题的时候才会去使用定向监控
                        监控Java应用
                            jstack
                            jmap
                            jvisualvm
                            Arthas
                        分析MysQL
                            mysglreport pt-digest-query
                        跟踪操作系统级别的调用。
                            perf
                            strace
    项目组织架构
        性能项目经理
            性能脚本工程师:负责编写性能测试脚本和场景执行
            性能分析工程师:负责分析性能场景执行过程中遇到的性能瓶颈
            架构师:负责支持性能分析
            开发工程:师负责支持性能分析
            运维工程师:负责支持性能分析
            业务方:确定性能项目的业务级需求
            老板:当资源不足时，请你一定要让老板知道，同时降低老板的预期，要不然在后续的沟通中会非常费劲。
                理智的老板负责协调支持
                不理智的老板负责指手画脚地捣乱
    成果输出：
        过程性输出:建议在性能项目中，尽量多做一些归档整理的工作，以备在后面的项目中查阅，并实现自己的技术积累
            脚本
            场景执行结果
            监控结果
            问题记录
        结果输出
            性能项目测试报告
                我们要给出“当前系统可支持 XXX 并发用户数，XXX 在线用户数”这样的结论。
                一定不要用“可能”、“或许”、“理应”这种模棱两可的词。
                性能结果报告中要有对运维工作的建议，也就是要给出关键性能参数的配置建议，比如线程池、队列、超时等。
                性能结果报告中要有对后续性能工作的建议。
            性能调优报告
                调优报告才是整个性能项目的精华，调优报告中一定要记录下每一个性能问题的问题现象、分析过程、解决方案和解决效果。
    项目风险分析    
        
        
        
技术组件：
        技术                        说明                            官网
        Kubernetes(k8s)            容器云                    https://kubernetes.io
        Helm                    Kubernetes包管理器        https://helm.sh
        Docker                    应用容器引擎                https://www.docker.co
        Weave Scape                Kubernetes可视化监控工具    https://www.weave.works
        Spring Cloud            微服务框架                    https://spring.io/projects/spring-cloud
        Spring Cloud Allbaba    微服务框架                    https://github.com/alibaba/spring-cloud-alibaba
        Spring Boot                容器+ MVC框架                https://spring.io/projects/spring-boot
        knife4j                 文档生产工具                https://github.com/xiaoymin/swagger-bootstrap-ui
        Elasticsearch            搜索引擎                    https://github.com/elastic/elasticsearch【bad】
        RabbitMQ                消息队列                    https://www.rabbitmq.com
        Redis                    分布式缓存                    https://redis.io
        MongoDB                    NoSQL数据库                https://wwww.mongodb.com
        Logstash                应用日志收集                https://github.com/logstash/logstash-logback-encode
        Jenkins                    DevOps调度工具            https://github.com/jenkinsci/ienkins【bad】
        Promethues                资源监控系统                https://prometheus.io
        Grafana                    监控可视化看板                https://grafana.com
        Harbor                    Docker镜像仓库            https://github.com/goharbor/harbor-helm【bad】
        SkyWalking                分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案    http://skywalking.apache.org
        Kibana                    日志可视化看板                https://www.elastic.co/cn/downloads/kibana【bad】
        Fluentd                    容器日志收集                https://github.com/kubernetes/kubernetes/tree/master/cluster/addonsfluentd-elasticsearch
        GitLab                    代码仓库                    https://about.gitlab.com
        Nexus-3 oss                制品仓库                    https://wwww.sonatype.com
        JMeter                    压测引擎                    https://imeter.apache.org
        Kuboard                 微服务管理工具                https://github.com/eip-work/