一、导读
年前在测试交流的微信群里面，看到了关于美军的“宙斯盾”系统的文章（https://mp.weixin.qq.com/s/_0nALr8rJ1Tq5pIFEZAikA），引发了一系列的讨论和思考，同时结合自己在测试十年的文章（https://www.atatech.org/articles/58031）最后一段，关于自己做测试的一个小小梦想，就是想要那样超酷的指挥部大屏，内心一直不能平静，尽管自己的能力有限，不能很好的设计这样的系统，一直犹豫要不要写LIUDAO一系列的文章，来阐述下我个人的想法，因为这个是个负责的工程，我不能思考的太片面太简单，一直不太自信去思考这块内容，现在好不容易下定了决心，不管怎么样，我也必须抛砖引玉下，找回自己一直做测试、一直做质量的初心。
二、背景
对于一个软件产品来说，不管我们在这个产品迭代了多少项目或需求，也不管我们是使用了什么样的研发流程，对于这个产品本身来说，TA随时随地的存在着质量或稳定性的风险；对于测试人员来说，我们有一个潜在需求，就是要对SUT的质量或稳定性风险做到了如指掌，经验丰富的测试人员可以或多或少的做到这一点，TA的思考、分析、行动点和结论大部分是在TA的脑子里面，其他人很难知晓其正确性和合理性，只能主观的认可和接收；我们可以想象下，测试人员在和SUT进行着无时间限制的持续战争，那么对于敌我的现状分析和思考、行动点就必须持续的迭代，同时为了协助你的决策的正确性，我们必须要有一个敌我的现状（质量或稳定性、发布等相关分析）的实时全面了解，同时能做出最快最合理的技术决策，确保对敌人进行致命一击，消除或最大降低风险，同时保护自己不受伤害。
目前来说，我们针对SUT的迭代发布，有完整的发布流程和风险评估；我们针对应用系统有完整的监控，包括系统层面、数据库层面、业务层面、数据层面的实时监控；每次大促我们针对系统应用来一次稳定性大扫除，偿还之前迭代那么多功能需求后的技术债务。但是我们分析线上故障的时候，重大故障有明显的下降，P3P4故障还是居高不下，我们有50%的故障类型是变更类故障，根据业务属性不同，运行态类的故障也是有明显的上升趋势，这里面就很明显的告诉我们，我们在和SUT进行战争的时候，在24小时持续作战的情况下，在系统环境多变且不确定的情况下，我们的作战能力是不够的，我们对于敌我的现状分析能力、决策能力、快速应对能力是不够的；对于很多产品或系统来说，我们在传承技术文档或沉淀的时候，都是无效、过时、不完整的技术沉淀，同时这些沉淀也是因人而异的，这些SUT的敌我的现状分析就是非常不可确定的状态和结果，我们随时都有可能被致命一击，风险识别和应对能力非常弱。
针对一个需要24小时持续作战的SUT对手，而且这个对手随时随地的出现风险，同时不同程度的伤害到我们，我们必须要有一个智能化的情报分析能力、风险识别能力、风险应对能力、SUT现状视图能力，同时将这些能力统一到一个智能化的指挥中心，通过自动化、半自动化、人工的预案和机制来取得这场残酷的战争。
三、LIUDAO定位
LIUDAO（六道）系统旨在智能化的快速提供SUT现状分析和我方技术决策能力的一套可视化系统。核心几个关键词：
智能化：SUT的现状分析和风险识别、风险应对必须是高度自动化，且部分能力是智能化的。
现状分析：全面的在系统层面、业务层面、SUT的攻击手段、迭代项目需求的变更层面等进行全面高精度的可视化数据收集和分析。
技术决策能力：针对SUT现状，实时快速给出高精度分析和预案，高效率的提供决策能力和实施决策能力。
高精度可视化：SUT现状、风险、风险应对、核心的关键数据和指标，高度浓缩，高效提供指挥部作战强大的的数据能力。
四、LIUDAO解决什么问题
我们有了那么多监控和评估系统，为什么我们还有设计和开发LIUDAO（六道）系统呢，很显然，LIUDAO要解决的问题是一个面的问题，而不是一个点的问题；我们要在24小时内，永久范围内（只要这个SUT不下线）高效应对SUT的不确定的未知的风险进攻，这就是LIUDAO核心要解决的问题，具体以下几个方面：
SUT系统现状分析不全面：目前SUT系统的系统监控、应用监控、数据库监控、数据监控都有，但是不在一个监控平台里面，且监控指标非常多，缺少核心高精度的指标，无法高效现状分析；另外一个核心就是系统变更的过程和结果的现状分析目前还少，且和运行态的监控分析割裂开了，没有进行一个全面的聚合分析；同时解决SUT系统的技术沉淀和传承问题，我们不再是无效的文档，而是实打实的LIUDAO系统的接入，同时也是具体实时性和有效性，同时也是接入程度的标准级别。
SUT系统风险分析不全面：目前我们针对SUT可能存在的质量或稳定性风险，提供各个维度的风险分析，这里面我们需要把风险从现状分析里面剥离出来，给出额外的高度重视和关注；真正的聚合变更过程的风险和运行态的风险、依赖影响的风险等等，同时进行智能化的风险分析，给出预案和辅助决策的数据和行动点。针对现状了解和风险关注的双重需求，我们现在更多的是把风险监控放在稳定性监控和稳定性专项行动点上，这个不是24小时持续作战的应对思路，所以我们必须解决在大促稳定性大扫除之前，常态化的智能化的识别风险和预警风险。
我方应对决策效率低：目前业务平台星环体系，做了很多关于故障快速恢复的能力；但是针对其他相关的产品系统较难应用类似的快速恢复能力，同时我们在预案建设和风险应对方面还没有做到比较全的映射关系，所以目前在应对故障恢复的应急能力上，我们还需要进一步提升；但是LIUDAO核心要解决的问题不是故障恢复，而是强调故障预防、故障预警和在故障发生或扩大影响之前的应对能力，包括预案的智能化推荐和实施，同时同步观察风险和现状数据，这是一套完整的质量风险决策能力。
这里看下来，是不是感觉LIUDAO解决的都是非常大的质量相关问题，且是大而全的问题，然而非然，LIUDAO其实就是一个指挥部大屏，帮助测试人员对SUT做到真正的了如指掌，24小时持续作战中做出最正确的技术决策；而要能实时准确的这些可视化数据和信息，背后是有多套风险引擎和数据引擎，这些可能70%我们已经在其他平台或工具上都已经做到了（部分已存在的平台的在设计上的输入输出可能会有标准化的修改）。
五、LIUDAO目标愿景
虽然一直很想思考LIUDAO系统的产品架构、技术架构、设计架构方面，但是里面的细节也不能不涉及，我对里面的细节了解的不全面，很容易比较宏观，正好借这个机会，重新梳理下自己在质量和稳定性方面的积累和想法，之前也说了，我作为测试人员，我对自己的SUT要做到了如指掌，且能让人信服，不仅仅是过去经验的信服，也能够在过程上，思考逻辑上，让人信服。
目前对于LIUDAO系统来说，TA可以设计成一个平台，接入所有可以标准化接入的SUT，也可以设计成一个SAAS服务，提供扩展性的API和个性化的基础服务能力，当然也可以设计成独立SUT的客户端SDK，提供SUT独有的能力，对于以下私有化、独立部署等独立特有需求的能力。每个不同的设计方式都有各自的利弊，目前还没有完全确定一个完美的方式，不管怎样，LIUDAO的目标就是让测试人员随时随地对SUT的现状和风险了如指掌，变更前后都心领神会，运行态能紧急预警；测试管理者对于任何一个产品业务的现状和风险了如指掌，对于大促的核心链路也心里有底，任何时刻，都可以和SUT进行对抗，提前预防和预警风险，智能化补助技术决策。
总结一句话，LIUDAO的愿景就是成为CIA+FBI的合体，具备高效全面的情报收集和分析能力，也具备智能化的风险决策和行动能力，时刻准备着和SUT进行常态化作战，并取得最终的胜利。
六、后记
万事开头难，这次关于LIUDAO系统的开篇总算完成了，接下来才是最难最核心的产品架构设计、产品组件设计、技术架构设计、系统标准接入和应用等核心内容，这些内容都是比较复杂的，需要长时间去积累沉淀，去梳理思路，给自己定一个flag吧，2021年完成所有LIUDAO系统的内容编写，平均每2-3个月产出一篇（这个难度真不小，接下来的文章需要画很多图，需要了解更多细节点，这些比较耗时间）。
