今天对告警模块的一个外部故障进行深度故障复盘，是三月底紧急合入的一个多时区大需求引入的，这个需求提出很紧急，当时直接跳过了需求实例化和MFQ，简单的进行了需求分析开始开发。我也只是在本子上简单的对测试场景进行了梳理，也只是跟我们团队的开发进行了沟通反馈。
这个故障泄露原因从测试角度来看：缺失服务端和网元不在同一时区的场景，而且告警数据在一天的每个小时都有分布，即数据分布的边界要求。那做了需求实例化和MFQ能考虑到这种场景吗？能避免这个故障的泄漏吗？答案：不一定。这个场景的信息怎么获取，怎么才能考虑到？需求前期的KYM（knowyourmission）中从8个维度来剖析需求时，其中用户，信息这两个维度信息深入了解，这个需求的使用用户是谁？多时区是哪些国家的？实际的时区是多少？服务端时区，客户端时区，网元时区分别分布在哪些时区？当时提交这个需求的背景是什么？用户实际用的功能点是哪些？对数据有什么要求？而当时我们是随意的设置不同的时区来测试，凭经验来准备数据，缺失了实际的场景考虑。
MFQ脑图中有一个分支是Data，分析需求需要的环境信息，数据配置等。这个故障泄露的原因归类的话也就属于这个Data分支考虑不全。后续在做MFQ脑图时，这个分支的信息最好要跟需求实际应用场景的数据配置要求一致。而且要例行的考虑到环境要求，告警数据要求，告警数据的分布情况等要点。
当时这个需求合入点很多，没有自动化，做一次全面的手工测试很耗时。稍微稳定了，开发同学说要修改，我心里就紧张，不知道会影响到哪？是不是又要全面覆盖一次，我的时间。若我们实现了自动化，有自动化做基本保障，我的小心脏也不用一上一下的，时间也不至于这么紧张。
网友评论