百度百科关于稳定的定义：
“稳恒固定；没有变动。”
很明显这里的“稳定”是相对的，通常会有参照物，例如 A 车和 B 车保持相同速度同方向行驶，达到相对平衡相对稳定的状态。
那么软件质量的稳定是指什么呢？
假设软件系统是辆车，质量预期是满足客户行驶要求，那么功能是指能正常行驶，性能是指按一定速度和油耗正常行驶，稳定是指平稳且持续的按一定速度和油耗正常行驶，这种稳定状态并不是质量本身的特性，而是质量表现的态势。
但在行驶中，车辆本身质量和路况不是一成不变的，轮胎磨损、刹车磨损、路面结冰、路口堵车、高峰限号等等各种状况都会影响行驶，那么此处的“平稳且持续”可以分解为质量本身的稳定及质量表现的稳定（驾驶者感受到的稳定）。
科幻电影常常可以看到这种操作：帅气的飙车中，男主车胎突然被打爆，车辆立刻变形，四胎变三胎，或者从机器触手中捞出备胎，凌空替换破损胎；一番操作炫酷丝滑，男主依然狂飙，刺激效果 upup，观众直呼给力给力。该电影场景体现了两点：产品本身质量好是硬道理（比如飙车那么久刹车依然灵敏），但是突发情况更需要有其他手段维持帅气（比如引入各种高科技手段）。
GB/T 16260 描述稳定性如下：
“软件避免由于软件修改而造成意外结果的能力。”
软考高级 《系统架构设计师》描述稳定性如下：
“软件稳定性，指软件在一个运行周期内、在一定的压力条件下，软件的出错几率、性能劣化趋势等，并观察其运行环境内的应用服务器、数据库服务器等系统的稳定性。”
2022 年 6 月由中国信通院发布的《分布式系统稳定性建设指南》描述稳定性：
“系统稳定性表示系统在遭受外界扰动偏离原来的平衡状态，而在扰动消失后系统自身仍有能力恢复到原来平衡状态的一种顽性。”
百度百科描述稳定性如下：
“系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。”
综合各方观点可以得到：系统稳定性关注的是系统随时间延续、软件修改、外界变化的关系，强调不受系统要素变更和外界扰动影响的能力。
这是一个比较泛的概念，那么如何提升这种能力呢？我们尝试从定义中的几个关键词入手：
系统要素的定义：
“系统要素是构成系统的基本组成部分或基本单元。”
系统研发过程既是生产软件系统的过程，也是制造问题（缺陷）的过程，过程质量也是影响稳定性的因素之一。
2022 年 4 月 Atlassian 出现宕机事故，原因是团队之间存在“沟通鸿沟”、系统警告不足；
2022 年 8 月谷歌搜索和谷歌地图出现宕机事故，原因是软件更新出错；
系统内部风险需要尽量在软件生产过程中避免，将制造风险的过程转变为控制风险的过程。
外界扰动指非系统本身带来的变化，往往不受系统控制，例如城市地震、机房电缆被挖、黑客 DDOS 攻击，这种不可抗力事件虽然小概率，但世界范围内随时都在发生，我们能做的是尽量提高抵御外界扰动的能力，减少对系统稳定性的摧残。
2022 年 6 月微软出现宕机事故，原因是微软的冗余电力系统的组件产生了意外的电气瞬变，导致空气处理单元（ahu）检测到潜在的故障，因此自动关闭；
2022 年 7 月甲骨文（Oracle）出现访问延迟，原因是创纪录的夏季高温导致冷却系统出现故障，数据中心的温度攀升，计算基础设施的一部分进入保护性关闭状态；
2022 年 7 月亚马逊的 EC2 实例瘫痪，原因是亚马逊网络服务（AWS）可用区 1 (AZ1)发生停电，导致服务中断；
上文提到稳定是一种相对的状态，因此更关注基于预期的结果对比和基于质量基线的趋势对比。
最新版的国家标准 GB/T 25000.10-2016 将软件系统的使用质量拆分为以下影响途径：
每个阶段的质量都有对应的测量指标，例如产品质量的 8 个特性如下：
目前业内较为常见的 SLA/SLO 系列指标属于使用质量的评估维度，体现软件系统对其利益相关方的影响；MTTR 是产品质量可靠性的重要评估指标，体现软件系统恢复到正常情况所花费的全部时间。
通过质量指标的拆解也可以看出为什么我们常说的是稳定性质量保障，而不是可用性质量保障、可靠性质量保障等等，显然稳定性视角覆盖到的是更全面的维度。
不同产品/系统/组件的质量指标预期值可能各有不同，没有标准答案，但“用户期望什么样的质量水平”一定是所有产品都重点考虑的必要标准。
质量： 产品/服务固有特性满足用户要求的程度。
质量保障： Quality assurance，官方译为“质量保证”，日常更多称“质量保障”，缩写是 QA。
质量保障（Quality Assurance）： 指为使人们确信产品/服务能满足质量要求而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动；
质量控制（Quality Control）：
为使产品或服务达到质量要求而采取的技术措施和管理措施方面的活动；
测试（Testing）： 在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程；
这三种活动过程的目的都是交付符合质量的软件，在项目中的实施范围从大到小是质量保障>质量控制>测试。
与质量控制和测试相比，质量保障更关注“预防”，通常通过“测试左移”和“测试右移”将测试活动构建于整个业务流程过程中，预防为主，防治结合。
质量控制关注产品结果本身，验证其是否达到预期要求并给出改进建议，包括需求确认、产品测试等操作。质量控制的概念早于 QA 形成至少 10 年以上。测试是质量控制的最后一道关卡，是验证质量的手段。
质量控制和测试对产品结果的验证，但是实际项目中，只重视产品结果往往为时过晚，想要修复产品初期的问题，需要投入更多的时间和人力成本。
那么控制问题的产生、控制问题带来的影响，是产品研发效能提升的关键。质量保障应运而生。
体系： 泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体，是不同系统组成的系统。
质量保障体系（质量保证体系）： 通过一定的制度、规章、方法、程序和机构等把质量保障活动加以系统化、标准化及制度化。
质量保证体系的运行应以质量计划为主线，以过程管理为重心，按 PDCA 循环进行，通过计划（Plan）—实施（Do）—检查（Check）—处理（Action）的管理循环步骤展开控制，提高保证水平。
体系不是一天两天建成的，更不建议为了建设而建设，一定是先有质量需求，开展了质量保障活动，逐步完善活动过程形成体系并逐步优化。
例如 google 定义的 SRE，SRE 不仅仅是职位的名称，更是一套迭代了接近 20 年的体系，覆盖了延迟优化、性能优化、效率优化、变更管理，监控、应急响应、容量规划与管理等等多个方面，非常值得借鉴和学习。但任何外来体系在本土化的过程中都需要经过筛选、调整、消化，如果直接生搬硬套，大概率会水土不服、事倍功半。
通过前几章的概念拆解，我们对“稳定性质量保障“说法的由来有了一定了解，那么稳定性质量保障活动在产品项目中如何开展呢？此处仅从上文概念拆解的角度来看，整体围绕以下几个方向：
关注所有与软件生命周期有关的因素，包括但不限于：
常见的外界影响包括：基础设施问题、外部依赖问题、用户异常操作等。需要针对不同的外部影响、影响范围、影响阶段制定不同的策略。
质量影响途径维度更多关注质量内的健康状态。从第二章的质量途径图示中可以看到使用质量依赖软件生命周期中的过程质量和产品质量，过程质量的监控和评价有利于产品质量改进，产品质量的监控和评价有利于改进使用质量；同样，评价使用质量可以为改进产品提供反馈，而评价产品可以为改进过程提供反馈。
GB/T 25000 系列已对各维度的质量评价指标做了详细说明，例如可靠性最常见的评估指标 MTBF/MTTR，本文不再赘述。
用户访问链路维度更多关注系统组成要素在生产环境中的健康状态，经典的监控体系分层包括：
用户体验层：
页面响应时间、渲染时间、业务指标等；
应用服务层：
服务可用性包括服务状态、Four Golden Signals（错误、流量、延迟、饱和度）、调用链路等；
组件层：
系统软件、中间件、数据库等；
主机层：
硬件、虚拟机、容器等；
基础设施层：
机房、网络等；
在任何生产或质量保障活动中成本都是必须考虑的事情，权衡取舍之后，永不失败、100% 稳定可靠的服务不可能存在，那么问题出现后如何快速解决是提高用户使用质量的关键。
Things break; that’s life。
快速定位： 精准定位故障点；
快速决策： 精准选择解决方案；
快速执行： 快速并有效执行；
这三个方向主要做了两件事：降低问题发生概率和降低问题发生后的影响，对标信通院总结的稳定性建设目标是“降发生“和”降影响“，对标 GB/T25000 质量指标是提高 MTBF、减低 MTTR。
稳定性质量保障在云商落地的过程中经历了如下几个阶段：
阶段1：质量控制
重心在测试执行，通过在测试阶段的活动发现软件问题推动质量改进。
阶段2：质量内建
重心在通过流程卡点、架构改造等一系列优化动作提高 MTBF，该阶段的思路已逐渐向质量保障靠拢，但缺乏“质量右移“视角 。
阶段3：风险防控
该阶段从软件生命周期维度将“风险”到“故障”的过程划分为风险产生的阶段、问题暴露阶段和故障损失阶段，并认为不管故障有没有带来具体的用户损失，只要在生产环境中被发现都属于损失。
重心在多维度巡检和报警，但缺少有效的跟进和管理手段。
阶段4：故障管理
该阶段的思路是从故障闭环角度入手，从时间维度分故障前、故障中、故障后，粗力度划分如下，细分项较多，此处不再展开。
因前几个阶段在预防、发现、复盘方面发力，已基本满足“自身健壮”和“及时发现”，第四阶段的建设重心在补齐“快速解决”的短板，提高故障定位和故障恢复的速度，降低 MTTR。
按时间顺序，MTTR 一般拆分为四个指标：
MTTI（Mean time to identify )： 定义为识别服务或组件问题所需的平均时间，有时被称为平均检测时间或 MTTD；
MTTK（Mean Time To Know）： 定义为找出问题发生原因所需的平均时间；
MTTF（Mean Time To Fix）： 定义为解决问题所需的平均时间；
MTTV（Mean Time To Verify）： 定义为验证问题所需的平均时间；
在实际故障中发现，MTTK 和 MTTF 占用 MTTR 的更多时间消耗。
MTTK-故障定位
通过“工具赋能”提高问题聚焦能力，通过“人员能力提升”补齐工具覆盖不到的路径。
1）工具赋能： 借助健全的运维系统能力提高效率，包括指标监控平台、日志平台、分布式追踪平台等，重心在可观测性平台的建设；
2）人员能力提升： 工具能定位到的路径之外，需要人工能力补齐，重心在通过实操演练等途径提升人员排查定位故障的能力；
MTTF-故障恢复
通过提前预案、快恢平台、应急流程的建设，助力恢复操作迅速、有序地开展，控制和防止故障进一步恶化。
1）应急预案： 针对可能发生的事故预先制定的行动方案，并周期性演练验证保鲜；
2）快恢平台： 将预案执行手段沉淀到平台中，缩短执行路径，并结合可观测平台做自动决策、自动执行，实现故障快速自愈；
3）应急流程： 故障恢复过程中免不了多人、多部门的协作，将流程规范化并达成共识，助力大家紧密协作，有条不紊地推进故障恢复；
经过几年建设和迭代，云商稳定性质量保障建设体系已基本成型，下面是体系建设全景图，供读者参考。
本文尝试从概念诠释的角度解读稳定性质量保障的由来以及建设方向，未对具体的落地措施做展开描述，如有进一步了解的需求，欢迎交流。
生命不息，奋斗不止。每一份努力都不会被辜负，只要坚持不懈，终究会有回报。珍惜时间，追求梦想。不忘初心，砥砺前行。你的未来，由你掌握！
生命短暂，时间宝贵，我们无法预知未来会发生什么，但我们可以掌握当下。珍惜每一天，努力奋斗，让自己变得更加强大和优秀。坚定信念，执着追求，成功终将属于你！
只有不断地挑战自己，才能不断地超越自己。坚持追求梦想，勇敢前行，你就会发现奋斗的过程是如此美好而值得。相信自己，你一定可以做到！
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
