在线应用的诊断一直是日常维护中的难点和痛点，2018年下半年，Alibaba 开源了 java 应用诊断工具 arthas ，让 java 应用的诊断能力上了一个台阶。作为基础架构团队，我们自然也对它非常感兴趣。研究后发现，arthas 确实是一个非常优秀的 java 诊断工具，但是也存在一些不足。 一是 arthas 更像是一个工具，而不像一个产品。如果要使用它，首先要登录相关机器，然后在机器上下载 arthas，再执行一些命令来运行。这整个流程里，下载可能出现问题，运行 arthas 也需要具有目标进程相应的权限，还需要先看看对应进程id等等...这些确实只是一些小问题，但也可以选择让这些问题不存在，让整个使用过程更加流畅。 二是 arthas 缺少 web 界面。命令行界面用起来确实很酷，但不可否认在相当一部分情况下 web 界面更直观更友好，很多需要查文档的情况在 web 界面下都可以直接操作，降低了使用门槛。 三是 arthas 所有功能都针对单台机器，实际上很多时候我们需要考虑和观察整个应用的运行情况，需要一个应用级的视角。 四是 arthas 是一个独立的工具。
去哪儿发布的数据显示，在过去一年中，其发布故障率始终保持在4‰ 以下并不断降低。作为一家出行旅游服务平台，去哪儿网如何在复杂的业务场景下，仍能保持如此低的故障率？其中功能测试左移功不可没。 本文介绍了去哪儿网通过自动化测试、智能推荐、本地化等平台的建设，在低成本、低故障率、高效率方面的显著成效，并详细介绍了各阶段的实践重难点。
2022年，Qunar 技术中心完成了轰轰烈烈的服务瘦身项目，在各个技术团队的努力下，最终完成了将上千个应用和千万行代码瘦身50%的目标。 在如此艰巨的任务达成目标之后，对于技术团队来讲，接下来的重点就变成了如何维持住这来之不易的成果，如何避免反弹。作为一家处于激烈竞争的互联网公司，Qunar 致力于不断为用户提供低价的产品，同时维持优秀的服务水平和用户体验，业务的演进和系统的迭代在持续不断的进行。随着业务的演进和系统的迭代，原本瘦下来的系统上会有新的代码填充进来，也会有新的应用加入或者拆分出来，这些动作都是会重新增加系统的臃肿程度，如果没有治理手段，会导致我们好不容易取得的瘦身成果慢慢流失。就像一个成功瘦身的人，如果瘦下来之后没有制定和执行合理健康的饮食计划和运动计划，迟早又会回到身体臃肿的状态。 基于此，在瘦身项目推进的同时，Qunar 技术中心启动了系统防腐化治理的项目，目的是在瘦身项目达成目标之后，建立和运用治理手段，防止或者减缓系统不受控制的膨胀，将系统的维护成本维持在较低的水平。这项工作由作者牵头，Qunar 技术中心业务架构 SIG 承接。
Qunar 的实时日志平台使用的是 ELK 架构，其中 Elasticsearch 集群（以下简称：ES 集群）和 kibana 平台在机房 A，Logstash 集群在机房B。 目前机房 A 在使用过程中存在以下一些问题隐患： 机房 A 目前为饱和状态，批量新增机器难以支持 机房 A 主要由 Hadoop、ES 集群组成，业务交互会产生大量跨机房流量，峰值会影响到业务 基于上述因素，与 Ops 同事沟通后，决定整体迁移 ES 集群到机房 B。这样不仅可以解决上述两个问题，和写入端的 Logstash 集群也同在一个机房，网络通信更有保障。 此文主要介绍 ES 集群节点迁移实战过程中的一些实践与探索演进经验，对于日常的平台开发与运维也能有所借鉴和参考。
分库分表是大型互联网应用经常采用的一种数据层优化方案，常见的分库分表中间件如 sharding-jdbc、mycat 都已经比较成熟，基本上可以应对我们一般的分库分表需求。做过分库分表的同学应该知道，在给业务系统做分库分表改造过程中，难的不是如何使用这些组件进行分库分表，而是如何将非分库分表的系统平滑的升级成一个分库分表的系统，升级期间业务不可暂停，升级过程及升级后风险可控，这个过程就像是给飞行中的飞机更换引擎，处理不好会产生重大的业务事故。去哪儿网机票辅营业务就经历过从主从读写分离系统升级到分库分表系统的过程，并在多次迭代过程中形成了一种与业务轻相关的平滑的分库分表方案，后续业务升级分库分表只需通过配置切换就可以将单库单表系统瞬切至分库分表系统。
Qunar 大前端团队一直致力于提升 App 页面的用户体验，基于前端技术手段，提高页面的流畅度和稳定性。 国内酒店作为 Qunar 的核心业务，需要时刻关注、提升预订主流程各个页面的性能指标和用户体验。近期我们使用非关键模块延迟加载、Bundle 预加载、接口提速等方案提升核心页面的流畅度，均得到了很好的效果，但是酒店详情页还未实现页面秒开的目标，需要继续提升。 酒店详情页的功能是展示酒店的基础信息、房型报价，是为用户提供预订酒店下单服务的重要入口，而 TTI 是衡量页面秒开的重要标准。 本文从现状、优化空间、具体方案设计及优化效果等方面来讲解我们对提升酒店详情页 TTI 的思考和动作，希望能给读者一些启发。
目前开源的监控系统越来越多，不同的系统针对的侧重点和特性也不同，像 Zabbix/Nagios 这种老牌的监控系统侧重于主机系统层监控和告警，比如 Zabbix 和 Nagios 都自带有一套完善的系统层面监控插件，而且还允许运维很方便的利用 Shell 脚本或任何其他脚本语言来扩展自己想要的插件，同时 Zabbix 还提供了比较便利的 Discovery 功能，创建一套模板后，便能自动发现和检测相应主机状态，省掉了繁琐的配置过程。而 Graphite/Prometheus 这样的则更兼顾业务应用层监控，它们提供了一套机制，应用可以在代码里记录自己在运行时的状态数据，然后通过 Exporter 或者 Push 的方式将状态数据暴露或推送到 Server 端，Server 存储在时序 DB 中用于之后的分析、查看和告警等。 很多企业在用开源软件的一个路径大概都是这样的，纯开源使用 → 少量的定制化开发或外层封装 → 深度的二次开发 → 自研。
随着业务发展和微服务架构的普及，企业内微服务拆分粒度越来越细，服务间调用关系错综复杂。对于一些复杂的，比如机票和酒店售卖业务场景，可能动辄涉及上百个应用，当某个系统发生异常时会导致多个服务受到影响。此时 APM 系统就派上了用场，监控（Metrics）、调用链（Tracing）、日志（Logging）帮助业务同学快速定位问题。普通的业务监控报警能起到快速发现问题的作用，但具体case的排查还需要研发人员通过异常栈信息来分析，比如数据库连接异常、空指针等等。 去哪儿网很早就有了监控系统 Watcher，能够起到快速提醒业务响应异常的作用，然后开发同学排查是接到报警的系统本身的问题还是下游依赖的系统的问题，如果是下游系统的问题，就要这样一层层地找下去，有时候定位问题时间会比较长。当某个系统出现问题时最根本的表现就是产生异常，如果能直接提示开发同学系统产生了新的异常，或者异常量上涨了，就能够大大缩短开发同学排查问题的时间，做到快速恢复故障。
在移动互联网时代，良好的用户体验至关重要，但如何量化其对业务的贡献一直是痛点和难点。毋庸置疑，体验是必须要持续推进的事情，产品、交互以及开发同学也投入很大精力去进行体验优化，但是相关的ROI(投入产出比)无法快速量化。在大多数情况下，只能通过录屏、纯技术指标(FPS/FCP/TTI等)来表现技术优化对用户体验的数据提升，但这表征不了整体用户体验的状态，更无法量化体验优化所产生的业务价值。 通过调研发现，关于用户体验的度量标准有各种各样的规范和模型，较为典型的有下表中的 Google Pulse、Google Heart、支付宝 PTECH、阿里云 UES，其中有满意度、任务效率、体验性能、易用性、收益、留存率、参与度、接受度、与一致性等关键项，其中前三项是较为普遍的共识。
