软件系统的脆弱性
伴随着不断演进的软件技术和架构，日趋复杂的软件系统基础设施，以及大量增加的业务和数据，开发和运行环境中不稳定的因素也在增加，系统行为变得不可预测，同时软件系统的不确定性日益严重。
人们无法通过预先设定的测试场景和测试脚本去测试软件，预生产环境已经不够用，软件系统的质量保障工作受到挑战，软件系统变得脆弱。
image
面对复杂的环境和脆弱的软件系统，该如何保障软件的质量呢？借用反脆弱[1]的概念，我们可以把软件的质量保障工作延伸到生产环境，利用这些不确定因素，从中受益，构建反脆弱的软件系统。
生产环境下的QA就是利用系统在生产环境的不可预测性，通过监控预警等方式收集生产环境的信息，总结分析以指导软件开发和测试过程，从而提高软件系统的健壮性、优化业务价值。其中，日志处理是最为关键的一个部分。
日志处理的常见误区与改进思考
提到日志处理，通常都会想到Ops（可能有Ops和开发人员组成，下面简称Ops）团队，认为日志处理是Ops该做的事情，往往关注的都是利用什么工具、什么技术来监控和分析，很少听到有对仅仅Ops人员处理日志的质疑。
作为QA，想从QA的角度来考虑一下，如果QA能够参与日志处理，跟Ops人员合作会有什么惊喜发生呢？
当然，并不是质疑Ops人员的能力，我们相信Ops人员在监控分析方面的专业技术能力是完全没有问题的，但是受限于不同的思维模式，Ops人员处理日志还是会有局限性的：
- Ops人员主要关注的是系统运行的稳定性和系统资源使用情况，做日志监控也会着重关注这些方面，比如内存、CPU利用率等等，缺乏对系统整体质量的关注。
- Ops也会对业务有所了解，但肯定比不上业务分析和QA人员，在做日志监控和分析的时候容易漏掉高业务风险的日志，没有及时止损，导致给业务带来损失。
- Ops人员很难把生产环境日志信息做详尽的分析，并把结果共享给开发团队来指导上线前的开发和测试工作，难以做到最优化利用日志信息。
image
凭着对业务的了解、对系统的熟悉以及对整体质量的关注，QA参与日志处理有着独特的优势。
- 质量反馈
敏捷QA有一项非常重要的职责就是在每个环节做好质量分析、掌握质量状态，并把质量信息反馈给团队。QA利用生产环境的日志信息，能够更好的了解产品的质量状况，更好的掌握系统易出错的薄弱功能点，对于后续的开发和测试工作有很好的指导意义。
- 分析优化
QA作为质量的倡导者，不会放过任何有利于做好质量保障的环节。当QA参与日志处理，发现日志处理过程中存在的可改进空间，定会促使优化日志处理，最大化利用日志信息。
- 业务敏感度
QA是团队里对系统最了解的角色里边业务敏感度最高的，QA参与任何活动都会以用户角度出发，考虑业务价值和业务风险。
QA参与日志处理，对于业务优先级较高的日志会比较敏感，能够更有的放矢的关注日志信息，让日志处理更有效。
同时，QA分析生产环境的日志信息，了解到真实业务的运行状况，从而可以更好的帮助优化业务价值。
下面通过一个项目上日志处理的故事来分享QA与Ops合作做好日志处理的实践。
项目的故事
项目背景
蓝鲸项目是一个历时九年多的离岸交付项目，团队不同阶段有50-80人不等，有三个系统同时并行开发，包括企业系统、客户系统和用户系统。随着业务的不断扩展、微服务的规模化，系统的不确定因素也开始暴露出来，生产环境下的缺陷增多、错误日志增长迅速，日均新增错误日志数达到几千条。
加强日志监控和处理迫在眉睫。
被动日志分析
刚开始项目上的一个Ops人员专职处理生产环境的日志，分析的方法是在Splunk里按Punct[2]查询错误日志重复出现的数量排序，每天处理重复出现数量比较多的一部分日志。这个阶段没有QA介入。
image
这是一个被动分析日志的过程，处理过程本身存在很多的问题：
- 时间和精力原因，每天新增的日志并没有办法全部覆盖到；
- 分析日志的同事的业务敏感度不够，没法基于风险优先级来处理，可能导致某些关键业务的错误信息漏掉；
- 没有可能进行详细的总结分析，对后续的处理没有指导意义；
- 虽然参与处理日志的同事越来越专业，但没有很好的将日志信息共享给团队，形成信息孤岛。
在这个过程中发现了很多当时日志记录本身存在的问题：级别定义不清晰、记录信息不够用、记录格式不一致等。
这个时候，QA也想参与，可是心有余力不足，主要是因为以下几个方面的痛点：
- QA没有权限接触生产环境；
- 由于没有接触过，对生产环境的基础设施并不了解；
- 日志记录的信息QA理解起来很有难度。
主动出击内建日志
意识到前一阶段日志处理的问题，团队决定投入更多的精力来加强日志处理。
首先，利用结构化日志技术，优化日志记录本身的问题。同时，QA从流程上把关做好日志内建，控制好每个环节，确保该有的日志能够正确的记录下来。
同时，QA、Tech lead跟Ops人员一起讨论识别出业务风险较高的特性，在监控面板设置对这些特性相关的前端和API的监控，并设置好一些定时Alert，每天通过邮件的方式告知性能和故障情况。每个特性团队的再派出开发人员加入Ops团队，兼职负责对监控得到的信息进行诊断，QA则负责跟踪通过日志信息定位出来的缺陷问题的修复。
另外，也对测试环境的日志进行监控，QA开始分析测试环境的日志信息，尽早发现问题。
这一阶段团队开始主动出击，有了业务优先级，不再是从茫茫日志大海去分析，这一举措给忙季带来很好的效果，顺利度过了忙季。
但是随着忙季的过去，也开始暴露出问题：错误日志在不断减少，团队对此的关注也越来越少，原来加入Ops团队的开发人员主要关注点也是在新的特性开发上，邮件收到的定时Alert也渐渐地被忽视…对于突然出现的错误日志并不能第一时间发现处理。
QA主导进一步优化
错误日志不能及时发现，导致用户报过来的生产环境缺陷也在增加。
image
QA作为生产环境支持的主要负责人，承担起处理生产环境缺陷和加强日志监控两项职责。
- QA组织跟参与日志处理的Ops人员的访谈，收集痛点，针对性的优化Alert机制，改为错误触发，不再是定时的，减少噪音；
- QA从流程上督促各特性团队Ops人员分析和查看自己组内负责的监控信息，关注Ops处理日志的进度状态更新；
- 对于Ops人员比较抓狂难以定位的问题，QA也会参与一起pair分析，或者根据Ops人员提供的信息去在测试环境尝试重现；
- QA对于一些特别重要的特性，定期查看是否有相关错误出现，以免漏掉相关错误信息。 比如，系统有个专供大老板发邮件的功能，某天突然挂掉了，这个错误日志信息在监控里边也有，但是并没有引起重视，QA查看的时候发现了才把优先级提上来赶紧处理；
- 优化整个生产环境支持流程，把日志处理纳入其中。周期性的对日志处理结果进行分析和回顾，把日志信息跟业务关联起来，识别出易出错的业务功能点，在后续的开发和测试过程中重点关注，同时也进一步优化现有的监控预警设置。
这个阶段QA不管是流程上还是实际日志分析上都有参与，日志处理更高效、生产环境缺陷发现更及时，生产环境的支持收到客户的好评。
项目故事回顾
前面故事主要分享的是随着业务和架构的演进，生产环境缺陷和错误日志都在大量增加，项目团队如何一步步优化日志处理、利用日志信息加强质量保障工作。从QA不参与、QA参与到最后QA主导，QA在整个日志处理过程中承担着以下几个非常关键的作用：
- 监督协调，流程把控
- 基于业务风险的分析和优化
- 日志处理与开发过程形成闭环，持续改进
image
写在最后
软件系统所处生态环境的复杂性、不确定性并不是毫无益处，生产环境下的QA技术就是利用这种不确定性，并从中受益，从而增强软件系统的反脆弱性。
QA参与日志处理，主要承担的是分析者和协调者的角色。QA参与，持续的分析、优化，利用生产环境的日志信息来指导和优化软件开发和测试过程，最大化业务价值，是生产环境下的QA最核心内容之一。
同时，QA利用开发和测试过程中对系统的了解，以及对业务的敏感度，可以进一步指导和协调日志处理过程的优化和改进。QA与Ops团队的合作，生产环境日志处理会更高效，也更能体现其价值。
这样，生产环境和预生产环境形成了良性循环，打造出一个反脆弱的软件系统。
注1：反脆弱
脆弱的反面是什么？是坚强？是坚韧？《反脆弱》这本书给出了这样的解释：
脆弱的反面并不是坚强或坚韧。坚强或坚韧只是保证一个事物在不确定性中不受伤，保持不变，却没有办法更进一步，让自己变得更好。而脆弱的反面应该完成这个步骤，不仅在风险中保全自我，而且变得更好、更有力量。
做一个类比的话，坚强或坚韧就像一个被扔到地上的纸团，不会摔坏，但是也只是维持了原貌，这还不够。
和纸团相反，乒乓球扔到地上非但不会摔坏，反而可以弹得更高。乒乓球拥有的就是脆弱反面的能力，也就是反脆弱。
注2：PUNCT
PUNCT是Splunk提供的一个功能，就是将日志信息的第一行的所有字母和数字去掉，剩下的标点符号，其中空格用下划线代替，最后结果为显示成类似正则表达式的形式。根据这个表达式来归类，同一类日志就会归到一起。
文/ThoughtWorks 林冰玉
网友评论