在讨论大促质量保障可以做些什么之前，我们先了解一下为什么要做大促质量保障？ 一般而言，平台大促即意味着流量暴涨和优惠力度暴增，特别是每年的618、双11和双12等大促更是一场电商圈的狂欢；暴涨的流量对系统稳定性的冲击，高额优惠对业务资损防控的考验，都比平常要高出数倍，出现了问题也会被放大数倍；这是一场没有硝烟的战争，宁可准备充足但毫无用武之地，也不能出现问题束手无策。
得物技术沙龙-研发效能专场在3月5日已经圆满结束啦，本次沙龙主要分享了： 在需求管理、研发生产、测试验收、发布部署、运营等阶段提效 平衡局部提效和全局提效 如何做到个人效率和团队效率双向提升 如何找到合适的方法和工具来提升研发效能，实现需求交付全生命周期的线上化、数字化、智能化
随着蓝绿发布项目落地进入试运行，也对蓝绿发布项目做个简要回顾。 早在2022年初的时候效能、交易和中间件的同学就如何提高发布效率做过讨论，蓝绿发布当时也被提出。由于彼时有更重要的事情去落地，蓝绿发布也被搁置未能成行。 随着染色环境项目的落地，推进接入工作的基本完成。测试开发环境存在的众多问题（多套环境、运维问题、环境冲突、沟通问题）基本得到根治。 测试环境得到根治的同时，生产环境自然就成为接下来的重点。大版本发布时长达7个小时，的确是大家的痛点，我们也希望从根本上提高发布效率。本文主要内容有： 应用发布诉求 发布方案对比 蓝绿发布流程 蓝绿流量调度 组件能力支持
随着CV算法在业务场景中使用越来越多，给我们带来了新的挑战，需要提升Python推理服务的性能以降低生产环境成本。为此我们深入去研究Python GPU推理服务的工作原理，推理模型优化的方法。最终通过两项关键的技术: 1.Python的GPU与CPU进程分离，2.使用TensorRT对模型进行加速，使得线上大部分模型服务QPS提升5-10倍左右，大量节约了线上GPU推理服务的成本。 针对上面的两项关键技术，我们还自研了相关框架与工具进行沉淀。包括基于Python的CPU与GPU进程自动隔离的推理服务框架，以及对推理模型进行转TensorRT优化的调试工具。 此外针对不同的推理服务性能瓶颈，我们还梳理了各种实战优化技巧，比如CPU与GPU分离，TensorRT开启半精度优化，同模型混合部署，GPU数据传输与推理并行等。 下面从理论，框架与工具，实战优化技巧三个方面介绍下推理服务性能优化的方法。
公司存在多种物料种类、不同类型的库存和价值管理不一，存货系统目前主要接入包装耗材、商品数据。目的是为了： 管理出入库价格、数量、库龄等业务数据，便于管理部门追溯及财务管控，协助仓库提升存货和物料的管理能力。 管理仓库物料及商品的费用价值，提升核算及业务的效率，实现业务信息一体化及凭证自动化。 辅助计划或采购部门查看库存，为采购计划提供数据支撑。 存货系统先接入了包耗材数据，这类数据的特性是行数据不多，但每行数量很大。后接入了商品的库存，由于行数据量增长N倍以上，并且随着业务不断增长数据量越来越大，考虑到原有底层设计不能很好的支撑这么大的数据量，故有了这次系统的模型升级。
客服一站式工作台集成了在线、热线和工单三个核心应用，支撑着自营客服和BPO客服每天处理大量的会话信息，工作台的稳定性就显得非常重要。接入前端监控以来，我们坚持每双周跟进工作台以及客服几个核心应用的线上稳定性情况，围绕页面的访问情况、JS错误率、资源加载异常情况、API接口成功率、自定义业务模块指标这五大监控模块，做了详细的数据分析，从中发现了很多问题并且通过实时告警解决了潜在的问题，也通过数据分析推进了客服职场完善工作台的运行环境。本文主要阐述我们是如何通过监控稳定性数据分析来提升应用系统的稳定性。
消息中心为得物App提供了强大，高效的用户触达渠道，其中push对于得物DAU的贡献有可观的占比，这也就意味着每一条推送消息都是一次与用户沟通的宝贵机会，所以推送的稳定性成为我们关注的首要问题，那么我们遇到的以下痛点就亟待解决。 消息中心没有明确消息推送的耗时标准，业务和技术之间存在gap，业务方对于推送的消息什么时候到达没有明确的心理预期。 从技术上来讲消息推送各个节点的耗时不明确，无法对各个节点的耗时做针对性的优化，这也就需要我们针对消息推送的节点耗时进行监控。 消息推送的稳定性依赖于第三方的推送通道，而三方通道对于我们来讲就是个黑盒子，如何做到三方通道异常及时发现并止损也是需要考虑的问题。 在我们正常的迭代过程中有时候不可避免的会出现些异常或者有坏味道的代码，这些问题能不能及时发现、及时止损，能不能及时告警出来。
我们期望平台能够覆盖的三类运营诉求如下： （1）突发事件的应对：包括不限于外部的不可抗力影响，网络上的热点事件、爆仓等突发事件，在搜索&推荐等个性化流量场景下，单纯依靠算法模型的学习来适应，时间上不被业务方接受。 （2）新品/新人等缺少数据的情况：在扶持新品、留存新人等问题上，新品召回难、个性化分数低导致排名靠后无法曝光，而新人缺少画像也会对推荐效果造成影响。因此对于新品的加权、新人定向投放需要频繁调整的情况，往往需要人工进行变更。 （3）平台的实验/探索项目：如品类价格带分布控制，一些探索尝试性的实验，需要先小流量定向推送指定商品进行实验，取得一定结果、经验后，再进行优化、推全等情况。需要在圈品、圈人、AB实验、数据大盘等多角度进行分析；频繁的调整策略打法，也需要技术侧进行迭代升级。
榜单在经历了供给量迅速增长及C端分发场景多样化等迭代，数据量及峰值流量呈十倍百倍增长，这必然带来数据库的极大存储压力和C端查询性能降低。为满足未来各类复杂定制化规则和亿万级数据甄选，综合引导消费者的购物决策，得物商品榜单生产迁移及B/C端数据存储隔离应运而生。
