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

分析日志的同事的业务敏感度不够，没法基于风险优先级来处理，可能导致某些关键业务的错误信息漏掉；

没有可能进行详细的总结分析，对后续的处理没有指导意义；

虽然参与处理日志的同事越来越专业，但没有很好的将日志信息共享给团队，形成信息孤岛。

在这个过程中发现了很多当时日志记录本身存在的问题：级别定义不清晰、记录信息不够用、记录格式不一致等。
这个时候， QA也想参与，可是心有余力不足，主要是因为以下几个方面的痛点：

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

主动出击内建日志
意识到前一阶段日志处理的问题，团队决定投入更多的精力来加强日志处理。
首先，利用结构化日志技术，优化日志记录本身的问题。同时， QA从流程上把关做好日志内建，控制好每个环节，确保该有的日志能够正确的记录下来。
同时， QA、Tech lead跟Ops人员一起讨论识别出业务风险较高的特性，在监控面板设置对这些特性相关的前端和API的监控，并设置好一些定时Alert ，每天通过邮件的方式告知性能和故障情况。每个特性团队的再派出开发人员加入Ops团队，兼职负责对监控得到的信息进行诊断， QA则负责跟踪通过日志信息定位出来的缺陷问题的修复。
另外，也对测试环境的日志进行监控， QA开始分析测试环境的日志信息，尽早发现问题。
这一阶段团队开始主动出击，有了业务优先级，不再是从茫茫日志大海去分析，这一举措给忙季带来很好的效果，顺利度过了忙季。
但是随着忙季的过去，也开始暴露出问题：错误日志在不断减少，团队对此的关注也越来越少，原来加入Ops团队的开发人员主要关注点也是在新的特性开发上，邮件收到的定时Alert也渐渐地被忽视…对于突然出现的错误日志并不能第一时间发现处理。
QA主导进一步优化
错误日志不能及时发现，导致用户报过来的生产环境缺陷也在增加。

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

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

这个阶段QA不管是流程上还是实际日志分析上都有参与，日志处理更高效、生产环境缺陷发现更及时，生产环境的支持收到客户的好评。
项目故事回顾
前面故事主要分享的是随着业务和架构的演进，生产环境缺陷和错误日志都在大量增加，项目团队如何一步步优化日志处理、利用日志信息加强质量保障工作。从QA不参与、QA参与到最后QA主导， QA在整个日志处理过程中承担着以下几个非常关键的作用：

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

文章插图
写在最后软件系统所处生态环境的复杂性、不确定性并不是毫无益处，生产环境下的QA技术就是利用这种不确定性，并从中受益，从而增强软件系统的反脆弱性。
QA参与日志处理，主要承担的是分析者和协调者的角色。 QA参与，持续的分析、优化，利用生产环境的日志信息来指导和优化软件开发和测试过程，最大化业务价值，是生产环境下的QA最核心内容之一。