底层技术是系统稳定运行的基石，往往牵一发而动全身。通过底层技术的优化，有效地管理和减少代码量，能极大提升系统的运行效率。去哪儿网作为业内较早落地“代码瘦身”的企业，该项目让其系统成功地减少了50%的代码量，26%的服务数量，提高了9.5%的发布效率。 本文旨在分享其如何运用可观测性技术识别并清除无用代码，并尝试通过还原实施细节、总结方法论，并为读者在系统精简方面提供一种新的思考和实践方式。
去哪儿网的原有监控系统在指标数量上展现出了强大实力——上亿指标量和百万级的告警量，但在故障数据方面却稍显不足——订单类故障平均发现时间长达4分钟，仅有20%的订单类故障能在1分钟内被发现，近半数的故障处理时长超过30分钟。为了解决这些问题，去哪儿网决定从优化故障指标出发，对故障发现、故障根因定位、故障修复等各个环节展开全面优化。 本文将深入探讨这一系列优化改革的详细过程，剖析各个阶段所采用的监控方法和工具，以及在实践过程中遇到的关键问题。
备份对数据库系统非常重要。当数据由于人为或意外的原因导致被误修改、误删除时，可能会造成服务显示错误或无法访问，进而给业务造成很多损失。部分情况下我们可以通过服务器上的日志立即进行恢复，但是服务器上的日志不会永久保留。如果需要查看整个库中的数据时，日志恢复就不能满足我们的需求。这时如果有一份合适的全量备份将数据库中的数据恢复到指定的时刻，则业务可以立即恢复，挽回损失。所以备份对数据库系统而言是一项必不可少的功能。
分布式链路追踪系统在企业的APM体系中扮演着重要的角色。本文分享了去哪儿旅行构建分布式链路追踪系统的实践经验。从APM整体架构设计入手，讲述了日志收集、Kafka传输和Flink任务处理等环节的性能优化实践和踩坑经验。 同时，作者结合丰富的分布式系统架构经验，探讨了APM系统和Trace数据的价值。通过阅读本文，你将了解到去哪儿旅行在构建APM体系中所面临的挑战，并学习如何应对这些挑战，实现更高效的性能监控和管理。
一、架构设计理念与技术 二、业务系统重构背景 三、系统重构改造模式和架构选择 四、业务驱动的微服务架构演进实践 五、总结和思考 六、Q&A
我们在去哪儿交易拦截可视化项目中，落地了自动化根因分析（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 页流量表的内在标签。
