第三方舆情收集与质量闭环建设

【案例背景】

    软件研发过程经历了三个阶段，从瀑布式开发、至敏捷、至精益，不同研发理念背后对质量有着不同诉求。在硬件性能依据摩尔定律爆发式增长的八九十年代，高级语言面世，微机普及，软件需求爆发式增长。当时的实践发现，面临复杂大型软件工程，往往项目失败率高，因而有强烈的对软件工程理论的诉求，瀑布开发模式走上了历史舞台。这种模式下，对测试团队的诉求是交付完美吻合规格说明（specification）的软件产品，核心待解决的问题是用较低成本高效覆盖测试点，因而在这个时代各种测试设计方法得以长足的进步。

    之后随着零零年前后互联网的起伏，互联网企业为了快速响应用户多变的诉求，软件工程的核心诉求发生了变化，从严格按图纸施工的瀑布式开发，转而追求质量与效率的平衡。在这个时期，“敏捷模式”大行其道，为了实现敏捷而持续集成，为了实习持续集成而自动化，多半测试团队在风风火火地进行自动化改造，各种工具平台应运而生，直至今日。

    敏捷的基础上提出的精益理念，构建了从产品到用户的闭环，所谓小步快跑，产品需要第一时间被用户见到，收集用户的数据和观点，从而不断修正产品形态。一次境外会议上听到一句挺有意思的话：If you release a product that doesn’t embarrassed you, it only meansthat you could release sooner. （如果你发布的产品很完美，不令你感到尴尬，只能说明产品发布得太晚了）。精益模式在用户用脚投票的互联网行业中尤为适用，著名的Facebook即采用类似的方式研发产品。收集用户对新增功能的反馈，并将反馈融入产品迭代过程中，是一件对互联网产品越来越重要的事。

    弯弯绕绕赘述了冗长的背景，让我们切入正题。获取用户反馈，除了从用户行为分析入手外，主动收集用户投诉（客服途径、产品的反馈表单）和被动获取用户反馈信息，都是协同产品迭代的重要补充。本次分享讲述了百度建立反馈体系与质量闭环的过程，详细讲述第三方舆情反馈的架构实践要点与细节。期望对有类似诉求的企业和团队，提供参考经验。

【解决方案综述】

     整体工程架构，讲分为三个部分展开描述，分别是数据抓取、数据清洗、数据输出。数据抓取面临的困难是应对第三方数据源的格式变更与屏蔽策略，在多变的内外部环境下确保数据流时效性，是工程实践过程中较困难的方面。数据清洗主要解决抓取反馈数据的精粹提纯，怎样平衡时延、准召、成本，是这个部分需要讨论的话题。数据输出解决的问题是平衡好一个基础架构与业务之间的关系，我们看到不少同类系统，最终深陷于各种多样需求难以自拔，在这里我们会给出一些解答思路。整体架构见下图。