我们在去哪儿交易拦截可视化项目中，落地了自动化根因分析（RCA Root Cause Analysis）方案，实现了秒级根因分析准确率95%以上，以及常见业务分析场景小时级接入，极大地提升了业务分析效率，获得业务方广泛认可。本文通过项目的前因后果介绍，结合业界方案，向大家分享我们一路的思考和成果。
1.1.1 如何提高代码复用性 随着业务的发展，前端需要处理的逻辑越来越多，导致前端工程的体积也越来越大。同时，不同的系统之间，或者系统的不同模块之间，也有一些功能类似或者相同的模块，所以如果这些相似功能对应的代码逻辑可以复用将会大大节省开发成本，因此，提高代码的复用性就成为了前端优化的一个重要方向。 1.1.2 如何实现模块的跨技术栈引用 前端技术栈发展迅速，不可避免的会出现不同技术栈项目同时进行维护的情况。一般来说，相同功能的模块，如果存在于不同技术栈项目中，则需要分别进行开发和维护，这对开发资源来说是一种浪费。如果能够实现模块的跨技术栈引用，达到“一处开发，多处使用”的效果，将能够极大的节省开发成本，从而实现降本增效。 1.1.3 如何提高代码的部署效率 对于大部分互联网公司来说，需求迭代很快，因此，敏捷开发模式被广泛应用，这就需要频繁的进行工程部署，因此，提升部署效率，也是提升前端整体开发效率的一部分。
客户数据平台 CDP（Customer Data Platform）已成为精细化运营的标配工具，去哪儿旅行经过多年的建设，广泛应用于各种业务场景中，产生累计亿级别的收益，并且 CDP 项目也获得了公司年度金项奖。本主题先后受邀在CSDI SUMMIT、InfoQ QCon+、DataFun 峰会，以及 Qunar 对外直播大数据系列课中进行了分享。本文结合对外分享内容进行整理，从 CDP 的业务背景、建设实践、总结应用、未来展望四个方面进行介绍精细化运营中 CDP 的业务价值，希望对这方面感兴趣的同学有所启发和收获。
在当前软件开发过程中，如何保证系统的稳定性和质量一直是一个重要的挑战。特别是对于复杂的业务系统，涉及多个流程和多个端，如何全面验证其功能和性能，并发现和解决潜在问题，成为了一个关键需求。因此，构建一个能够串联多个业务流程、覆盖多个端的全流程自动化测试平台，对于提高系统的稳定性和质量是至关重要的。本文将介绍背景、现状分析、具体实现和运营机制等方面，帮助读者全面了解和理解该平台的重要性和实现原理。
随着旅游市场的回暖、出行需求的激增，去哪儿网酒店的单日预订量也刷新了历年的前高还在不断突破产生新高。 与此同时，酒店数仓每天处理的数据也在不断上涨，为了保障日常 SA 级的报表正常产出，需要我们持续优化数据处理的链路，消除存在的瓶颈与卡点。 酒店流量链路产出的核心宽表为：搜索( search S页 )、列表( list L页 )、详情( Detail D 页)、预订( booking B 页)和提交订单( order O 页）流量表，对应了酒店主流程各个页面的用户流量数据。 我们以一个具体的案例 “ L 页流量表” 优化作为切入点，来展开对流量链路的优化实践，承诺 SLA、体量够大、关联够多、逻辑够复杂、使用够广一直是 L 页流量表的内在标签。
在 iOS16 上，苹果推出了实时活动( Live Activities )。实时活动可以出现在用户锁屏界面，并可实时展示用户关心的一些核心信息。由于使用远程推送通道更新实时活动不需要主 app 保持开启，并且相比小组件需要用户手动添加到桌面这个门槛，实时活动功能是默认开启的，所以这一机制保证了信息的触达概率会远高于小组件。 笔者认为，实时活动是一种更高级的推送形态，对比传统的推送，实时活动显得灵活许多。传统推动在用户接收并读取到内容的瞬间信息就失效了，如果想要为用户提供持续更新的信息需要依赖一条接一条的推送才可以实现，这无论从成本还是用户体验上，都是难以接受的。而实时活动则会在持续期间，无干扰的保持着信息的更新，并且又会在合适的时机自行消失，因此用户体验极佳。 作为一家在线旅行产品平台，我们一直追求为用户提供极致的用户体验，在今年的上半年，我们上线了基于实时活动开发的实时出行信息展示功能，用户可以在出行全周期内，通过锁屏或者灵动岛看到最新实时的出行信息。
随着业务日益复杂，应用微服务化已成为主流趋势，业务领域通常在多个微服务应用中实现。DevOps 工程从应用角度，虽实现了应用流水线和项目流水线，但也面临着测试阶段管理多套应用流水线的复杂场景。通常情况下，这些业务会存在多套互相隔离的环境，而这些环境的构建也依赖人工处理资源申请和部署。由于构建不易，这些环境通常被长期反复使用，并需要定期与生产环境同步以确保开发和测试的有效准确。这些工作要求工程师对业务的应用架构熟悉且有时间频繁进行操作，但实际上这些工作大多落在项目资深的 DEV 或 QA 身上，浪费了宝贵的人力资源。因此，我们可以考虑建立“环境构建平台”，实现环境即用即建，让 DEV 和 QA 专注于自己擅长的事情，并最终节约人力资源提升效率。Qunar 的基础平台团队对此问题进行了长期实践，本文将分享 Qunar 在测试环境治理领域的实践经验和思考。
随着去哪儿网业务的发展和微服务架构的普及，公司内微服务的拆分粒度越来越细，导致服务间的调用错综复杂。比如机票和酒店的下单场景，就会涉及到成百上千个应用的调用，而当此类场景出现异常产生报警甚至产生故障时，对开学同学来说查找并定位问题是个很大的挑战。 去哪儿网构建了自己的 APM 系统，包括监控(metric)、日志(logging)和调用链路(Tracing)，帮助开发同学定位问题。但在实际排查问题的过程中，开发同学需要排查是报警的应用本身还是下游依赖的问题，需要逐层去排查调用链路、异常日志、监控指标等，这样就会导致有时定位问题的时间比较长。而对于影响业务的故障而言，导致的后果便是恢复时间较长，造成的损失较大。
对于去哪儿平台而言，酒店业务主要是通过整合不同货源，对客提供优质低价酒店。而我们本次提到的 SPA 系统（全称 supplier-product-adapter，中文全称为供应商产品报价适配系统），负责接入供应商的酒店信息以及报价信息，为上层应用提供了统一格式的报价数据。其在酒店业务定位中处于一个非常关键的位置。
在线应用的诊断一直是日常维护中的难点和痛点，2018年下半年，Alibaba 开源了 java 应用诊断工具 arthas ，让 java 应用的诊断能力上了一个台阶。作为基础架构团队，我们自然也对它非常感兴趣。研究后发现，arthas 确实是一个非常优秀的 java 诊断工具，但是也存在一些不足。 一是 arthas 更像是一个工具，而不像一个产品。如果要使用它，首先要登录相关机器，然后在机器上下载 arthas，再执行一些命令来运行。这整个流程里，下载可能出现问题，运行 arthas 也需要具有目标进程相应的权限，还需要先看看对应进程id等等...这些确实只是一些小问题，但也可以选择让这些问题不存在，让整个使用过程更加流畅。 二是 arthas 缺少 web 界面。命令行界面用起来确实很酷，但不可否认在相当一部分情况下 web 界面更直观更友好，很多需要查文档的情况在 web 界面下都可以直接操作，降低了使用门槛。 三是 arthas 所有功能都针对单台机器，实际上很多时候我们需要考虑和观察整个应用的运行情况，需要一个应用级的视角。 四是 arthas 是一个独立的工具。
