免费企业黄页网站入口,网站访问量怎么增加,爱名网22自助网站建设,公司做网站费会计科目什么是稳定
百度百科关于稳定的定义#xff1a;
“稳恒固定#xff1b;没有变动。”
很明显这里的“稳定”是相对的#xff0c;通常会有参照物#xff0c;例如 A 车和 B 车保持相同速度同方向行驶#xff0c;达到相对平衡相对稳定的状态。
那么软件质量的稳定是指什么…什么是稳定
百度百科关于稳定的定义
“稳恒固定没有变动。”
很明显这里的“稳定”是相对的通常会有参照物例如 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)发生停电导致服务中断
稳定状态
上文提到稳定是一种相对的状态因此更关注基于预期的结果对比和基于质量基线的趋势对比。
1确定基线
最新版的国家标准 GB/T 25000.10-2016 将软件系统的使用质量拆分为以下影响途径 每个阶段的质量都有对应的测量指标例如产品质量的 8 个特性如下 目前业内较为常见的 SLA/SLO 系列指标属于使用质量的评估维度体现软件系统对其利益相关方的影响MTTR 是产品质量可靠性的重要评估指标体现软件系统恢复到正常情况所花费的全部时间。
通过质量指标的拆解也可以看出为什么我们常说的是稳定性质量保障而不是可用性质量保障、可靠性质量保障等等显然稳定性视角覆盖到的是更全面的维度。
2确定预期
不同产品/系统/组件的质量指标预期值可能各有不同没有标准答案但“用户期望什么样的质量水平”一定是所有产品都重点考虑的必要标准。
什么是质量保障
质量 产品/服务固有特性满足用户要求的程度。
质量保障 Quality assurance官方译为“质量保证”日常更多称“质量保障”缩写是 QA。
质量保障、质量控制、测试的区别
质量保障Quality Assurance 指为使人们确信产品/服务能满足质量要求而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动
质量控制Quality Control
为使产品或服务达到质量要求而采取的技术措施和管理措施方面的活动
测试Testing 在规定的条件下对程序进行操作以发现程序错误衡量软件质量并对其是否能满足设计要求进行评估的过程
这三种活动过程的目的都是交付符合质量的软件在项目中的实施范围从大到小是质量保障质量控制测试。
与质量控制和测试相比质量保障更关注“预防”通常通过“测试左移”和“测试右移”将测试活动构建于整个业务流程过程中预防为主防治结合。
质量控制关注产品结果本身验证其是否达到预期要求并给出改进建议包括需求确认、产品测试等操作。质量控制的概念早于 QA 形成至少 10 年以上。测试是质量控制的最后一道关卡是验证质量的手段。
为什么要做质量保障
质量控制和测试对产品结果的验证但是实际项目中只重视产品结果往往为时过晚想要修复产品初期的问题需要投入更多的时间和人力成本。
那么控制问题的产生、控制问题带来的影响是产品研发效能提升的关键。质量保障应运而生。
什么是质量保障体系
体系 泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体是不同系统组成的系统。
质量保障体系质量保证体系 通过一定的制度、规章、方法、程序和机构等把质量保障活动加以系统化、标准化及制度化。
质量保证体系的运行应以质量计划为主线以过程管理为重心按 PDCA 循环进行通过计划Plan—实施Do—检查Check—处理Action的管理循环步骤展开控制提高保证水平。
体系不是一天两天建成的更不建议为了建设而建设一定是先有质量需求开展了质量保障活动逐步完善活动过程形成体系并逐步优化。
例如 google 定义的 SRESRE 不仅仅是职位的名称更是一套迭代了接近 20 年的体系覆盖了延迟优化、性能优化、效率优化、变更管理监控、应急响应、容量规划与管理等等多个方面非常值得借鉴和学习。但任何外来体系在本土化的过程中都需要经过筛选、调整、消化如果直接生搬硬套大概率会水土不服、事倍功半。
稳定性质量保障建设方向
通过前几章的概念拆解我们对“稳定性质量保障“说法的由来有了一定了解那么稳定性质量保障活动在产品项目中如何开展呢此处仅从上文概念拆解的角度来看整体围绕以下几个方向
自身健壮-Design for failure
1提高自身稳定
关注所有与软件生命周期有关的因素包括但不限于
人 如何规避人为因素产生的负面影响流程 如何规避流程缺失或腐化的负面影响技术 如何规避技术缺陷引起的风险组件/系统 如何规避内部组件关系或系统架构的潜在风险变更 如何规避以上所有因素的变更带来的风险
2防御外界扰动
常见的外界影响包括基础设施问题、外部依赖问题、用户异常操作等。需要针对不同的外部影响、影响范围、影响阶段制定不同的策略。
及时发现-Multiplex monitor
1质量影响途径维度
质量影响途径维度更多关注质量内的健康状态。从第二章的质量途径图示中可以看到使用质量依赖软件生命周期中的过程质量和产品质量过程质量的监控和评价有利于产品质量改进产品质量的监控和评价有利于改进使用质量同样评价使用质量可以为改进产品提供反馈而评价产品可以为改进过程提供反馈。
GB/T 25000 系列已对各维度的质量评价指标做了详细说明例如可靠性最常见的评估指标 MTBF/MTTR本文不再赘述。
2用户访问链路维度
用户访问链路维度更多关注系统组成要素在生产环境中的健康状态经典的监控体系分层包括
用户体验层
页面响应时间、渲染时间、业务指标等
应用服务层
服务可用性包括服务状态、Four Golden Signals错误、流量、延迟、饱和度、调用链路等
组件层
系统软件、中间件、数据库等
主机层
硬件、虚拟机、容器等
基础设施层
机房、网络等
快速解决-Emergency response
在任何生产或质量保障活动中成本都是必须考虑的事情权衡取舍之后永不失败、100% 稳定可靠的服务不可能存在那么问题出现后如何快速解决是提高用户使用质量的关键。
Things break; that’s life。
快速定位 精准定位故障点
快速决策 精准选择解决方案
快速执行 快速并有效执行
这三个方向主要做了两件事降低问题发生概率和降低问题发生后的影响对标信通院总结的稳定性建设目标是“降发生“和”降影响“对标 GB/T25000 质量指标是提高 MTBF、减低 MTTR。 云商稳定性保障建设历程
稳定性质量保障在云商落地的过程中经历了如下几个阶段 阶段1质量控制
重心在测试执行通过在测试阶段的活动发现软件问题推动质量改进。
阶段2质量内建
重心在通过流程卡点、架构改造等一系列优化动作提高 MTBF该阶段的思路已逐渐向质量保障靠拢但缺乏“质量右移“视角 。
阶段3风险防控
该阶段从软件生命周期维度将“风险”到“故障”的过程划分为风险产生的阶段、问题暴露阶段和故障损失阶段并认为不管故障有没有带来具体的用户损失只要在生产环境中被发现都属于损失。
重心在多维度巡检和报警但缺少有效的跟进和管理手段。 阶段4故障管理
该阶段的思路是从故障闭环角度入手从时间维度分故障前、故障中、故障后粗力度划分如下细分项较多此处不再展开。
因前几个阶段在预防、发现、复盘方面发力已基本满足“自身健壮”和“及时发现”第四阶段的建设重心在补齐“快速解决”的短板提高故障定位和故障恢复的速度降低 MTTR。
按时间顺序MTTR 一般拆分为四个指标
MTTIMean time to identify ) 定义为识别服务或组件问题所需的平均时间有时被称为平均检测时间或 MTTD
MTTKMean Time To Know 定义为找出问题发生原因所需的平均时间
MTTFMean Time To Fix 定义为解决问题所需的平均时间
MTTVMean Time To Verify 定义为验证问题所需的平均时间
在实际故障中发现MTTK 和 MTTF 占用 MTTR 的更多时间消耗。 MTTK-故障定位
通过“工具赋能”提高问题聚焦能力通过“人员能力提升”补齐工具覆盖不到的路径。
1工具赋能 借助健全的运维系统能力提高效率包括指标监控平台、日志平台、分布式追踪平台等重心在可观测性平台的建设 2人员能力提升 工具能定位到的路径之外需要人工能力补齐重心在通过实操演练等途径提升人员排查定位故障的能力
MTTF-故障恢复
通过提前预案、快恢平台、应急流程的建设助力恢复操作迅速、有序地开展控制和防止故障进一步恶化。
1应急预案 针对可能发生的事故预先制定的行动方案并周期性演练验证保鲜
2快恢平台 将预案执行手段沉淀到平台中缩短执行路径并结合可观测平台做自动决策、自动执行实现故障快速自愈
3应急流程 故障恢复过程中免不了多人、多部门的协作将流程规范化并达成共识助力大家紧密协作有条不紊地推进故障恢复
经过几年建设和迭代云商稳定性质量保障建设体系已基本成型下面是体系建设全景图供读者参考。 结语
本文尝试从概念诠释的角度解读稳定性质量保障的由来以及建设方向未对具体的落地措施做展开描述如有进一步了解的需求欢迎交流。 总结
感谢每一个认真阅读我文章的人
作为一位过来人也是希望大家少走一些弯路如果你不想再体验一次学习时找不到资料没人解答问题坚持几天便放弃的感受的话在这里我给大家分享一些自动化测试的学习资源希望能给你前进的路上带来帮助。 软件测试面试文档
我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。 视频文档获取方式 这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。
