首页 > 其他分享 >服务质量保障规范

服务质量保障规范

时间:2022-11-10 08:46:12浏览次数:39  
标签:服务 服务质量 可用 处理 保障 规范 故障 线上 测试

如何做好质量保障         

高可用类型

简单理解

高可用方案

业务高可用

用户的操作都可以正常被处理

冗余设计+故障预案+监控告警+良好的服务发布体系

服务高可用

service可持续处理请求,但不对业务的正确性负责

分布式集群+限流熔断方案+
多可用区多机房

  

上述的内容只是一个引子,因为高可用和线上服务的稳定性有密切的关系。而软件测试或者说质量保障的工作范畴,不仅仅在测试环境,线上环境的服务质量保障,也是我们需要关注的重点。

这其实也是我在之前的文章《如何建立高效的质量保障体系》中提到的一点:交付(线上)质量持续运营。见下图:

 

发现线上故障 

业内程序员面试时候据说有个三高的说法,即:高并发、高性能、高可用。

分布式架构中有CAP理论,即:Consistency(数据一致性)、Availability(服务可用性)、Partition tolerance(分区容错性)。

这些点对软件系统提出了很高的要求,既要能扛得住高并发流量冲击,又要具备很好的性能来处理请求,还要达到服务和业务的高可用,并且要保证业务数据的一致性,最后还要对异常场景有一定的冗余处理能力,简直是难上加难。

而线上服务(或者说生产环境),我们最担心也最常见的就是出现线上故障。故障的种类很多,什么服务挂了、支付失败、无法加载商品图片等等不一而足。

要保障线上服务质量,避免出现线上故障的前提,除了在测试阶段做好测试,上线发布前仔细验证之外,还需要具备在故障发生时及时发现故障的能力。

目前最常见的发现故障的手段有两种,分别是:日志分析和监控告警

当然,很多的监控告警系统也是通过埋点数据和日志采集,对采集的数据进行过滤,解析成一定的结构数据,然后进行存储以及可视化展示来做的。

比如很经典的ELK(Elasticsearch+Logstash+Kibana),如下图:

 

通过日志分析和监控告警,我们可以快速的发现线上故障,及时的进行处理。

 处理线上故障

发现线上出现故障后,第一优先级永远是快速恢复线上业务的可用性,然后再考虑其他。

写到这里突然想起之前就职的某家企业交易团队负责人的话:优先业务止血,再考虑问题定位分析和优化

以我的工作经历来说,一般发现线上故障后的处理流程如下:

 

一般来说,线上故障处理,主要会涉及到如下四种角色:

NOC:一般指专门的线上服务巡检和监控值班人员,出现故障时作为信息收集和信息分发中心;

运维/研发:线上故障由对应业务域/服务的研发和运维进行处理(研发对代码最熟,运维有服务配置发布和变更权限);

测试/产品:故障恢复后测试进行观察验证,如果影响范围较大,还需要通知产品甚至市场运营进行对应的配合处理;

高层领导:如果故障比较严重,需要上升到更高级别的负责人,并且某些重要操作需要高层决策和授权;

修复线上故障

一般来说,对于线上出现故障,快速恢复服务可用业务可用,降低故障带来的损失是首要的,修复bug反而是其次。

所以在线上出现故障时,一般都会采用一些临时方案来达到快速止血的目的。常见的临时方案有:

  • 服务重启;
  • 部署回滚;
  • 限流降级;

有临时方案就有后续的优化方案,一般在线上故障恢复后,会进行如下几个步骤:

  • 利用日志和故障现场保留的dump文件等进行根因分析;
  • 修复故障后在测试环境进行验证,确认没问题后再发布到生产环境;
  • 记录故障从发生到彻底修复的全过程,进行线上故障复盘,提出后续改进方案并跟进落地;

当然,除了上述的一些手段,还可以通过如下几种方式来降低线上出现故障的影响和损失:

  • 组织线上故障演练,培养技术同学的临时反应和处理问题能力;
  • 通过灰度发布或者发布beta版本,让用户成为帮助我们发现问题;
  • 做专项的混沌工程,在不断的攻防演练中提升线上服务的质量和稳定性;

运营线上质量

聊了这么多,那测试同学如何针对线上故障,做好质量持续运营呢?可以从上面的几张配图来切入。

线上服务巡检:NOC并不是一个岗位,而是一种职责,测试同学对于业务和自己负责的项目相对更熟悉,要做到最快速度发现和处理线上故障,就是要让最正确的人第一时间响应和介入处理。

而测试同学可以达到监控巡检和信息分发以及快速验证的作用。当然,这种机制需要一定的时间建立,还需要一定的基础技术服务设施支撑。

组织故障复盘:流程和规范可以将好的实践标准化流程化自动化,让技术团队共享经验,而组织故障复盘并且跟进后续的优化落地效果,就是一个测试同学可以很好胜任的事情。

故障处理手册:有了日常线上巡检,组织了故障复盘,可以沉淀很多的最佳实践,可以将这些实践抽取共性,沉淀输出为一份故障处理手册,并在团队内做宣讲和落地。

这样既可以让其他同学在面对故障时能更快的响应处理,也能让新同学入职后快速的熟悉团队的技术栈,加快融入速度。

 

                                                                                                                 

 内容来源:https://www.cnblogs.com/imyalost/p/16867940.html

标签:服务,服务质量,可用,处理,保障,规范,故障,线上,测试
From: https://www.cnblogs.com/dj2016/p/16875852.html

相关文章

  • [杂记] 一些我自己的代码规范
    一些我自己的代码规范写代码的时候,代码规范确实是一个不大不小的问题。为了防止代码变成“屎山”,养成一个好的代码习惯还是十分重要的。本文就简单记录一些章鱼自己的代......
  • 2.Restful规范
    restful规范是一套主流的API规范,目的是将前后端统一规范。节省二者的沟通成本,提高开发效率,常见的规范有以下9种1.https协议在实际项目部署中,使用https协议代替http,目......
  • Day05.2:常量及变量命名规范
    常量常量:一旦被初始化后不能更改的的值。被设定死了的变量finaltypeVARNAME=value;finaldoublePI=3.14;final数据类型常量名=值;常量名字符使用大写final作为......
  • RPC请求&响应参数规范
    §0.有话先说0.0“开卷有益”-->如下是《码出高效:Java开发手册》书中5.3节的截图,文中提到“公司内部跨应用远程服务调用优先考虑使用Result对象来封装错误码、错误描述信......
  • 京东云开发者|代码评审的价值和规范
    评审目的代码评审的目的就是为了保证公司整体代码的健康状况随着不断迭代,始终保持一个较高的水平,所有在评审中使用的工具和流程都应是为此目的而设计的。评审原则鼓励......
  • 如何做好线上服务质量保障
    昨天下午星球有同学问了一个问题:目前业内高可用部署主要采用方案?看到这个问题,我的第一反应是问题太宽泛,不够明确。我反问了她一个问题:“你需要什么高可用?业务高可用?服务......
  • web前端编码规范/编码习惯❤️
    web前端编码规范/编码习惯​​一、CSS文件命名规范​​​​二、页面结构命名​​​​三、导航命名​​​​四、功能命名​​​​五、CSS书写规范-性能优化方案​​​​六、H......
  • 新的 ES2022 规范终于发布了,我总结了8个实用的新功能
    英文|https://betterprogramming.pub/es2022-features-javascript-a9f8f5dcba5a新的ES13规范终于发布了。 JavaScript不是一种开源语言,它是一种需要遵循ECMAScript......
  • 数据库安全管理规范
    1.目的为规范数据库系统安全使用活动,降低因使用不当而带来的安全风险,保障数据库系统及相关应用系统的安全,特制定本规范。2.适用范围本规范中所定义的数据管理内容,特指存放在......
  • 在Azure DevOps中使用Checkstyle自动检查编码规范
    1.概述什么是checkstyle?checkstyle(https://checkstyle.org/)是一个督促开发人员遵守统一编码标准的工具,它是基于java编写的工具,使用自动化的方式,将开发人员从检查代码规......