软件系统|QA与Ops通力合作打造反脆弱的软件系统软件系统的脆弱性伴随着不断

软件系统的脆弱性伴随着不断演进的软件技术和架构，日趋复杂的软件系统基础设施，以及大量增加的业务和数据，开发和运行环境中不稳定的因素也在增加，系统行为变得不可预测，同时软件系统的不确定性日益严重。
人们无法通过预先设定的测试场景和测试脚本去测试软件，预生产环境已经不够用，软件系统的质量保障工作受到挑战，软件系统变得脆弱。
文章插图
面对复杂的环境和脆弱的软件系统，该如何保障软件的质量呢？借用反脆弱[1]的概念，我们可以把软件的质量保障工作延伸到生产环境，利用这些不确定因素，从中受益，构建反脆弱的软件系统。
生产环境下的QA就是利用系统在生产环境的不可预测性，通过监控预警等方式收集生产环境的信息，总结分析以指导软件开发和测试过程，从而提高软件系统的健壮性、优化业务价值。其中，日志处理是最为关键的一个部分。
日志处理的常见误区与改进思考提到日志处理，通常都会想到Ops（可能有Ops和开发人员组成，下面简称Ops）团队，认为日志处理是Ops该做的事情，往往关注的都是利用什么工具、什么技术来监控和分析，很少听到有对仅仅Ops人员处理日志的质疑。
作为QA ，想从QA的角度来考虑一下，如果QA能够参与日志处理，跟Ops人员合作会有什么惊喜发生呢？
当然，并不是质疑Ops人员的能力，我们相信Ops人员在监控分析方面的专业技术能力是完全没有问题的，但是受限于不同的思维模式， Ops人员处理日志还是会有局限性的：

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

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

质量反馈

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

分析优化

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

业务敏感度

QA是团队里对系统最了解的角色里边业务敏感度最高的， QA参与任何活动都会以用户角度出发，考虑业务价值和业务风险。
QA参与日志处理，对于业务优先级较高的日志会比较敏感，能够更有的放矢的关注日志信息，让日志处理更有效。
同时， QA分析生产环境的日志信息，了解到真实业务的运行状况，从而可以更好的帮助优化业务价值。
下面通过一个项目上日志处理的故事来分享QA与Ops合作做好日志处理的实践。
项目的故事项目背景
蓝鲸项目是一个历时九年多的离岸交付项目，团队不同阶段有50-80人不等，有三个系统同时并行开发，包括企业系统、客户系统和用户系统。随着业务的不断扩展、微服务的规模化，系统的不确定因素也开始暴露出来，生产环境下的缺陷增多、错误日志增长迅速，日均新增错误日志数达到几千条。
加强日志监控和处理迫在眉睫。
被动日志分析
刚开始项目上的一个Ops人员专职处理生产环境的日志，分析的方法是在Splunk里按Punct[2]查询错误日志重复出现的数量排序，每天处理重复出现数量比较多的一部分日志。这个阶段没有QA介入。

文章插图
这是一个被动分析日志的过程，处理过程本身存在很多的问题：

时间和精力原因，每天新增的日志并没有办法全部覆盖到；
- 上一页
- 1
- 2
- 3
- 下一页