大规模检索系统的DevOps实践

1、大规模检索系统的DevOps实践技术创新 变革未来百度检索系统的现状凤巢检索系统的DevOps选型凤巢检索系统的DevOps实践凤巢检索系统的DevOps应用效果主要内容百度检索系统的现状搜索：立足之本凤巢：发展之匙手百：时代之趋业务复杂团队庞大迭代快速线上服务模块200+ 代码量10w+/周大商业团队400+人核心模块要求每周2次上线具有紧急上线的能力凤巢检索系统的DevOps选型三大特性：Single Code Base产品源代码，只保持最新的版本，每次编译都基 于该最新版本，每次发布二进制产品也基于该最 新版本。Continuous Build Verification对该base的源代

2、码，维护一套自动化测试的系统， 对该base上源代码的质量进行持续编译，测试， 再编译，再测试的过程。Regular Release Process软件产品的发布是定期的。该周期不依赖于某一 个特性是否研发完毕而决定的，只要到了时间， 就发布。合并代码统一测试merge成本需求1需求2需求nBUG Meeting解决merge回主干困难，回归成本高问题。解决随着项目增多，分支增多，越来越难管理问题。修复bug，可以达到修改主干，多处都可以fix的效果。解决在实验过程中，难以比较两个实验间的相互影响问题。解决QA只保证单上线分支质量，忽视merge后质量的问题。Single branch相对Mu

3、ti branch development之优势：分 支 开 发版本库代码其他开发人员的提交第一次本地验证第二次本地验证1234456提交构建阶段代码流向代码修改 |运行测试 |图例：构建成功的版本 |将代码从版本库检出到本地为新功能或者bug修改代码，或开发测试代码第一次运行本地验证（localbuild）与版本库中的代码合并，再次执行本地验证(localbuild)提交代码到版本库（提交前需要发起CodeReview，并通过）构建任务被自动触发六步 走master/trunk上线模式A：主干上线上线上线上线？bugfix线上代码独立于主干之外上线模式B：分支上线master/trunk上线

4、上线bugfixbranch1branch2支持紧急上线凤巢检索系统的DevOps实践线上质量需求管理提交准入构建系统灰度发布静态代码检查规则可定制监控快速预警&止损需求流程管理 规范化、明确化持续集成 功能测试 系统测试部署测试仿真线上需求管理全流程内部规则代码分析函数调用关系代码清理单测覆盖率模块编码规则内部lib使用规范前置测试：代码提交准入阶段（绑定代码库hook）低成本：不需要case、不需要环境、不需要数据避免误报常见工具存在误报cppcheck规则可定制When？Why？Jenkins分级构建调度层静态检查编译功能测试系统测试覆盖率cov统计灰度发布部署测试组件层cppcheck

5、并行集群单元测试diff测试findbugs模块测试性能测试local发起压力测试资源层RD + QA运行环境机器资源测试数据代码提交后，进行测试任务分级构建check in功能测试：验证某功能点是否符合预期系统测试：本次升级对整个服务的影响（diff、性能、压力）范围单函数、单模块整个系统：多模块、多服务环境轻量级仿真线上数据单条、多条万/十万级别下游mock真实下游运行时长秒级别分钟/小时级别功能测试和系统测试的对比系统测试：构建系统中最复杂的环节1、环境仿真、数据量大、任务执行时间长2、涉及范围广：多模块、多服务系统测试三大挑战资源机器&数据需求效率环境&任务时间成本准确百万测试数据真实

6、性BDC云储存offlineAeNBeNBeNBonlinetcpcopyredisredisredis多库eNB回 放 服 务压力数据管理ABVI PeNBeNBC压 力 工 具测试任务测试平台线上录制数据运维回放集群测试解耦线线上下录回制放压力数据通用dirverABCeNBeNBeNB0库1库n库回放服务redis集群VIP协议测试解耦过程回放数据对应关系：signB 9002A 9001C 9003支持动态变更可扩展&易维护ABCDECDEPTESTdriverABDEABDEONLINE北京 上海 深圳 杭州CC灰度发布：避免线上环境不一致&配置冲突导致的问题上线前的最后一道闸门：环境仿真&配置一致启动？ 崩溃？PASS不进行业务逻辑检查目的：对线上服务了如指掌磁盘内存流量展现同环比绝对值基本数据业务数据采集存储监控进程core收入平响个性化redismysqlhdfs团队专题健康页机器信息日志信息模块采集数据聚合数据对比支持监控图表类型：趋势图：同环比、多维对比表格：报表展现等其他个性化图表： 分布图，健康页等主要报警类型：同环比报警, 绝对值报警,小流量报警(支持指