从0-1如果提升质量保障体系（下）
2.2 演练及紧急预案2.2.1 演练
针对异常及故障进行常态化演练，包括ES双机房切换演练、索引迁移演练、业务线日常演练，异常演练等等，截止目前为止大大小小的演练执行了大概18次，值得一提的双机房切换演练，往年ES双机房切换方案无脚本化执行，纯手工敲命令，全靠经验跟临场发挥，切换耗时基本1个小时以上，且每次切换必修数据，耗时耗人耗精力，演练的目的是为了快速高效切换，一键脚本化，保障了切换时间保持在10分钟内，打破了“ES一切换必故障”的魔咒！
2.2.2 预案
通过演练以及结合线上问题预估出可能的风险，推进开发进行一些技术改造，配合执行验证预案效果，下图为核心的几个预案：
简单举例：
ES异常处理Tips：
ES集群异常场景大部分都会涉及到一个索引切流到备的操作，我们通过apollo配置双机房分流，紧急情况直接切备：
但是如果切备还解决不了问题，就需要对集群做更细粒度操作，问题大致可分为以下几个异常场景：
1、proxy线程池满
先检查确定问题诱因，proxy或者ES集群，观察ES集群是否健康
ES集群问题，处理不过来负载高出现reject
写reject提高吞吐量，修改refresh_interval（默认5s）改大
读reject，增加proxy层Tesla索引限流
如果某一机器出现reject，分片迁移，使集群平衡
2、CPU高负载爆满
清除集群缓存
更改索引刷新时间，将refresh_interval（默认5s）调大
切到备机房，将问题索引切到备机房
迁移分片，使集群平衡
针对索引限流，避免影响其他索引，Tesla限流
重启，某个节点上执行
3、某一节点不可用
切备，单独索引切备
重建索引，导入备份数据
2.3 监控治理
搜索承接将近300个的索引，每个索引的慢查或者错误使用都可能会拉高整体集群的load，所以急需一套完善的监控体系实时监控各条业务线及索引的操作情况；
搜索监控治理主要为事前、事中、事后：
事前监控
ES慢查统计、Top Query、错误码监控、总体性能指标、操作占比等，这些以天网大盘的形式实时监测，目前总共配置了11个大盘，主要是为了提前感知到业务方错误使用的方式和慢查Query的业务场景，如下图所示：
事中监控
主要包括应用级别监控，底层集群监控，另外还有依赖的中间件监控，Tesla告警等，主要是应用发布或者集群索引迁移的时候能够及时观测应用及集群情况；
应用级别：L1L2级别应用已经全部覆盖，告警项有rt、同比、线程池、KV及NSQ等；
ES集群：grafana监控26个，告警涉及到每个集群的CPU、磁盘、bulk及search操作，load等；
中间件主要有：kv、nsq配置在应用级别，flink监控告警配置在任务级别；
此外错误日志治理是2021 H1重点，为了提高error日志的准确性，降低排查难度，目前L1应用error量至少降低60%，报警粒度细化到了场景，例如“获取商品详情异常”、“店铺服务异常”、“美业深翻&value过长”等等；
经过2021年上半年监控告警治理，线上有效bug数明显降低，如下图所示：
事后监控
搜索事后监控场景不是很多，事后的线上数据如果有问题肯定也是“木已成舟”，主要包括BCP定时对账，即同步链路上Hbase与es数据对比，还包括一些索引级别的每天读写请求量，大部分是为了统计或后续索引优化提供依据。
3 搜索中台流程规范补全
俗话说：无规矩不成方圆，搜索各项流程的制定也是经历一波阵痛，有不少是依据线上问题和跟研发的合作磨合下一步步补充起来的，如下图所示：
其中在研发提测质量上，搜索中台从搭建初始单测覆盖率为0，针对这种情况，我们对搜索的应用进行了一个梳理，重新定义各应用的UT标准，其中L1级别应用增量覆盖率需要达85%，L2级别应用增量覆盖率达75%，杜绝出现无断言或断言过简的情况，通过流程规范的卡点，目前搜索核心应用单测情况：
此外集群切换规范包括切换步骤的梳理及各项checklist，源于双机房切换演练中的一环，最后落定成统一的集群切换规范；
索引迁移规范包括新老索引切换前后的check，例如切换索引topQuery新集群性能是否符合预期、是否要开始同版本写操作、是否有索引数据一致性保障方案等等。
三、未来展望
搜索现存问题和挑战还有很多，搜索结果排序还达不到灵活精排，搜索分词类目预测，产品词，近义词还比较零散，ES 提供的ik_max 最细粒度分词能保证足够的召回量，但最细粒度的召回策略无法满足业务需求；所以对测试人员来说，提升搜索GMV任重而道远，业务场景也会更复杂，测试面需要更加广泛；智能搜索是未来，搜索算法技术测试方案需要探索落地，搜索保障手段需要更多样化。
页:
[1]
