QA与Ops通力合作打造反脆弱的软件系统

软件系统的脆弱性

伴随着不断演进的软件技术和架构,日趋复杂的软件系统基础设施,以及大量增加的业务和数据,开发和运行环境中不稳定的因素也在增加,系统行为变得不可预测,同时软件系统的不确定性日益严重。

人们无法通过预先设定的测试场景和测试脚本去测试软件,预生产环境已经不够用,软件系统的质量保障工作受到挑战,软件系统变得脆弱。

面对复杂的环境和脆弱的软件系统,该如何保障软件的质量呢?借用反脆弱[1]的概念,我们可以把软件的质量保障工作延伸到生产环境,利用这些不确定因素,从中受益,构建反脆弱的软件系统。

生产环境下的QA就是利用系统在生产环境的不可预测性,通过监控预警等方式收集生产环境的信息,总结分析以指导软件开发和测试过程,从而提高软件系统的健壮性、优化业务价值。其中,日志处理是最为关键的一个部分。

日志处理的常见误区与改进思考

提到日志处理,通常都会想到Ops(可能有Ops和开发人员组成,下面简称Ops)团队,认为日志处理是Ops该做的事情,往往关注的都是利用什么工具、什么技术来监控和分析,很少听到有对仅仅Ops人员处理日志的质疑。

作为QA,想从QA的角度来考虑一下,如果QA能够参与日志处理,跟Ops人员合作会有什么惊喜发生呢?

当然,并不是质疑Ops人员的能力,我们相信Ops人员在监控分析方面的专业技术能力是完全没有问题的,但是受限于不同的思维模式,Ops人员处理日志还是会有局限性的:

  1. Ops人员主要关注的是系统运行的稳定性和系统资源使用情况,做日志监控也会着重关注这些方面,比如内存、CPU利用率等等,缺乏对系统整体质量的关注。
  2. Ops也会对业务有所了解,但肯定比不上业务分析和QA人员,在做日志监控和分析的时候容易漏掉高业务风险的日志,没有及时止损,导致给业务带来损失。
  3. Ops人员很难把生产环境日志信息做详尽的分析,并把结果共享给开发团队来指导上线前的开发和测试工作,难以做到最优化利用日志信息。

凭着对业务的了解、对系统的熟悉以及对整体质量的关注,QA参与日志处理有着独特的优势。

  • 质量反馈

敏捷QA有一项非常重要的职责就是在每个环节做好质量分析、掌握质量状态,并把质量信息反馈给团队。QA利用生产环境的日志信息,能够更好的了解产品的质量状况,更好的掌握系统易出错的薄弱功能点,对于后续的开发和测试工作有很好的指导意义。

  • 分析优化

QA作为质量的倡导者,不会放过任何有利于做好质量保障的环节。当QA参与日志处理,发现日志处理过程中存在的可改进空间,定会促使优化日志处理,最大化利用日志信息。

  • 业务敏感度

QA是团队里对系统最了解的角色里边业务敏感度最高的,QA参与任何活动都会以用户角度出发,考虑业务价值和业务风险。

QA参与日志处理,对于业务优先级较高的日志会比较敏感,能够更有的放矢的关注日志信息,让日志处理更有效。

同时,QA分析生产环境的日志信息,了解到真实业务的运行状况,从而可以更好的帮助优化业务价值。

下面通过一个项目上日志处理的故事来分享QA与Ops合作做好日志处理的实践。

项目的故事

项目背景

蓝鲸项目是一个历时九年多的离岸交付项目,团队不同阶段有50-80人不等,有三个系统同时并行开发,包括企业系统、客户系统和用户系统。随着业务的不断扩展、微服务的规模化,系统的不确定因素也开始暴露出来,生产环境下的缺陷增多、错误日志增长迅速,日均新增错误日志数达到几千条。

加强日志监控和处理迫在眉睫。

被动日志分析

刚开始项目上的一个Ops人员专职处理生产环境的日志,分析的方法是在Splunk里按Punct[2]查询错误日志重复出现的数量排序,每天处理重复出现数量比较多的一部分日志。这个阶段没有QA介入。

这是一个被动分析日志的过程,处理过程本身存在很多的问题:

  • 时间和精力原因,每天新增的日志并没有办法全部覆盖到;
  • 分析日志的同事的业务敏感度不够,没法基于风险优先级来处理,可能导致某些关键业务的错误信息漏掉;
  • 没有可能进行详细的总结分析,对后续的处理没有指导意义;
  • 虽然参与处理日志的同事越来越专业,但没有很好的将日志信息共享给团队,形成信息孤岛。

在这个过程中发现了很多当时日志记录本身存在的问题:级别定义不清晰、记录信息不够用、记录格式不一致等。

这个时候,QA也想参与,可是心有余力不足,主要是因为以下几个方面的痛点:

  • QA没有权限接触生产环境;
  • 由于没有接触过,对生产环境的基础设施并不了解;
  • 日志记录的信息QA理解起来很有难度。

主动出击内建日志

意识到前一阶段日志处理的问题,团队决定投入更多的精力来加强日志处理。

首先,利用结构化日志技术,优化日志记录本身的问题。同时,QA从流程上把关做好日志内建,控制好每个环节,确保该有的日志能够正确的记录下来。

同时,QA、Tech lead跟Ops人员一起讨论识别出业务风险较高的特性,在监控面板设置对这些特性相关的前端和API的监控,并设置好一些定时Alert,每天通过邮件的方式告知性能和故障情况。每个特性团队的再派出开发人员加入Ops团队,兼职负责对监控得到的信息进行诊断,QA则负责跟踪通过日志信息定位出来的缺陷问题的修复。

另外,也对测试环境的日志进行监控,QA开始分析测试环境的日志信息,尽早发现问题。

这一阶段团队开始主动出击,有了业务优先级,不再是从茫茫日志大海去分析,这一举措给忙季带来很好的效果,顺利度过了忙季。

但是随着忙季的过去,也开始暴露出问题:错误日志在不断减少,团队对此的关注也越来越少,原来加入Ops团队的开发人员主要关注点也是在新的特性开发上,邮件收到的定时Alert也渐渐地被忽视…对于突然出现的错误日志并不能第一时间发现处理。

QA主导进一步优化

错误日志不能及时发现,导致用户报过来的生产环境缺陷也在增加。

QA作为生产环境支持的主要负责人,承担起处理生产环境缺陷和加强日志监控两项职责。

  1. QA组织跟参与日志处理的Ops人员的访谈,收集痛点,针对性的优化Alert机制,改为错误触发,不再是定时的,减少噪音;
  2. QA从流程上督促各特性团队Ops人员分析和查看自己组内负责的监控信息,关注Ops处理日志的进度状态更新;
  3. 对于Ops人员比较抓狂难以定位的问题,QA也会参与一起pair分析,或者根据Ops人员提供的信息去在测试环境尝试重现;
  4. QA对于一些特别重要的特性,定期查看是否有相关错误出现,以免漏掉相关错误信息。 比如,系统有个专供大老板发邮件的功能,某天突然挂掉了,这个错误日志信息在监控里边也有,但是并没有引起重视,QA查看的时候发现了才把优先级提上来赶紧处理;
  5. 优化整个生产环境支持流程,把日志处理纳入其中。周期性的对日志处理结果进行分析和回顾,把日志信息跟业务关联起来,识别出易出错的业务功能点,在后续的开发和测试过程中重点关注,同时也进一步优化现有的监控预警设置。

这个阶段QA不管是流程上还是实际日志分析上都有参与,日志处理更高效、生产环境缺陷发现更及时,生产环境的支持收到客户的好评。

项目故事回顾

前面故事主要分享的是随着业务和架构的演进,生产环境缺陷和错误日志都在大量增加,项目团队如何一步步优化日志处理、利用日志信息加强质量保障工作。从QA不参与、QA参与到最后QA主导,QA在整个日志处理过程中承担着以下几个非常关键的作用:

  • 监督协调,流程把控
  • 基于业务风险的分析和优化
  • 日志处理与开发过程形成闭环,持续改进

写在最后

软件系统所处生态环境的复杂性、不确定性并不是毫无益处,生产环境下的QA技术就是利用这种不确定性,并从中受益,从而增强软件系统的反脆弱性。

QA参与日志处理,主要承担的是分析者和协调者的角色。QA参与,持续的分析、优化,利用生产环境的日志信息来指导和优化软件开发和测试过程,最大化业务价值,是生产环境下的QA最核心内容之一。

同时,QA利用开发和测试过程中对系统的了解,以及对业务的敏感度,可以进一步指导和协调日志处理过程的优化和改进。QA与Ops团队的合作,生产环境日志处理会更高效,也更能体现其价值。

这样,生产环境和预生产环境形成了良性循环,打造出一个反脆弱的软件系统。


注1:反脆弱

脆弱的反面是什么?是坚强?是坚韧?《反脆弱》这本书给出了这样的解释:

脆弱的反面并不是坚强或坚韧。坚强或坚韧只是保证一个事物在不确定性中不受伤,保持不变,却没有办法更进一步,让自己变得更好。而脆弱的反面应该完成这个步骤,不仅在风险中保全自我,而且变得更好、更有力量。

做一个类比的话,坚强或坚韧就像一个被扔到地上的纸团,不会摔坏,但是也只是维持了原貌,这还不够。

和纸团相反,乒乓球扔到地上非但不会摔坏,反而可以弹得更高。乒乓球拥有的就是脆弱反面的能力,也就是反脆弱。

注2:PUNCT

PUNCT是Splunk提供的一个功能,就是将日志信息的第一行的所有字母和数字去掉,剩下的标点符号,其中空格用下划线代替,最后结果为显示成类似正则表达式的形式。根据这个表达式来归类,同一类日志就会归到一起。

Share
林冰玉

林冰玉

十年的软件质量相关工作,积累了丰富的对企业级应用和大型产品应用的测试和管理经验。目前除了在项目上负责质量相关工作之外,还是ThoughtWorks中国QA社区负责人、BQConf负责人。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据