随着携程机票BU业务规模的不断提高，业务系统日趋复杂，各种问题和挑战也随之而来。对于研发测试团队，面临着各种效能困境，包括业务复杂度高、数据构造工作量大、回归测试全量回归、沟通成本高、测试用例数量多且难以复用、测试数据维护量大以及自动化用例管理等问题。每个都会影响测试团队的效率和质量，给软件研发过程带来挑战。 总结下来主要是两个核心困难点：成本与复杂度。 成本方面，我们通常需要在成本和质量之间做出取舍，需要在快速迭代的同时保证质量，又需要在限定的投入下保证质量。 复杂度方面，当业务规则积累一段时间后，业务流程、规则、场景和数据处理的复杂度在叠加后呈二次或者指数等形式增加，给测试质量工作带来很大的挑战。
携程作为在线旅游公司，对外提供机票、酒店、火车票、度假等丰富的旅游产品，其系统稳定性关乎用户是否具有顺滑的出行体验。然而，流量激增、代码发布、运维变更等都会给系统稳定性带来挑战。 我们在2020年对生产故障的“发现-定位-解决效率”提出了“1-5-10”的目标（即一分钟发现故障，五分钟定位故障，十分钟解决故障），这无疑对监控告警提出了很高的要求。订单量是生产故障异常检测场景中最核心最显性的指标，订单量在自身形态上具有周期性、规律上升和下降、业务高峰和低谷等特点，影响因素包括节假日、促销等。倘若数以万计的业务线通过人工配置规则的方式来覆盖到所有业务场景，并且做到高准确率和召回率，是非常不现实的。因此，迫切需要一套配置费力度低、普适性强、准确率高、时效性强的智能异常检测算法体系来及时发现异常。 指标异常检测是智能运维领域的重要落地场景，携程AIOPS团队致力于提升告警质量，寻找告警效率、准确率和真实故障召回率三者之间的平衡点。我们将统计学方法和机器学习方法结合，根据指标的历史数据，将训练的多个模型组成一套异常检测系统，在覆盖真实故障的基础上，减少告警数量，产生更有价值的告警。
眨眼之间，距离 React 18.2.0 发布已过了一年多的时间，越来越多的开发者从当初的观望心态，逐步已经将 React18 的新特性投入开发/生产中了，当然，笔者所在的团队也不例外。 今天这篇文章就和大家简单聊聊 React 18 中的 Streaming 。
大多数的技术研发都对重构有所了解，而每个研发又都有自己的理解。从代码重构到架构重构，我参与了携程大型全链路重构项目，积累了一点经验心得，在此抛砖引玉和大家分享。
互联网蓬勃发展的今天是流量为王的时代，但随着流量红利逐渐消失，获客成本的日益增高，用户留存成为各大互联网公司的重点关注问题，其中流失用户的召回在当今的流量红海市场中显得尤为关键，为此，基于大数据和机器学习的智能营销技术应用而生。 携程火车票业务每周都会有短信营销活动，旨在通过对近期未下单的老客发送短信将其召回，促进复购，提升用户粘性（业务流程如图 1 所示）；原有业务策略是基于规则的方式随机从满足条件的用户池中选择一部分进行短信投放，针对该方法过于粗放、召回效果不佳、短信发送 ROI 不高的问题，我们分阶段提出基于 Response Model 的转化率预估模型、基于 Uplift Model 的短信敏感度预估模型，逐一对问题进行更科学的定义、拆解和优化。
目前我们团队小程序是使用 Taro 跨端方案 React 框架进行开发，基于现有样式方案，在编译打包后会产生大量的样式代码冗余，在项目编译后的产物中占有较大比例。
随着上云项目的不断推进，大量的应用需要部署到 aws 上，其中有很多应用都依赖延迟队列的功能。而在 aws 上，我们选择以 Kafka 作为消息队列，但是 Kafka 本身不支持延迟队列，这就需要思考如何基于 Kafka 来实现延迟队列。
携程火车票营销页使用 css 制作动画很多年了，这大大提高了动画给予页面丰富的视觉体验。不过，在开发的过程中，也遇到了一些性能相关问题和用户反馈，比如头部动画卡顿、页面打开时间较长、页面打开后部分数据加载时间较长等问题。为解决这些问题，我们借助性能检测工具定位问题，并查阅源码、文档等资源解决问题，形成了这篇文章。
