日常我们在浏览某个网页的时候，可能会遇到打不开的问题，技术支持在处理工单问题时也会遇到此类问题，今天我们就来讲下网页打不开问题背后的逻辑，也就是网页浏览在 Windows 系统层面的生效流程，这样当遇到问题后才能更全面、更效率的去解决。

随着有赞的业务发展，数据同步的场景越来越多，主要是 MySQL、Hive 与文本文件之间的数据同步，Sqoop 已经不能完全满足需求。在2017年初，我们已经无法忍受 Sqoop 给我们带来的折磨，准备改造我们的数据同步工具。

离线存在大量零散的无用数据，人工治理成本很高。有赞是如何识别并自动化下线的呢？

我们在移动助手 App 集成了本地抓包的功能，在测试抓包，线上问题排查等场景发挥着重要的作用。

本文主要介绍了有赞微商城 Android 组件化的一些思路和实现。

本文介绍了 Java 代码转化为 Dex 文件的步骤和 Dex 文件的格式，以及在 Tinker 热修复技术方案中的使用。

随着有赞实时计算业务场景全部以Flink SQL的方式接入，对有赞现有的引擎版本—Flink 1.10的SQL能力提出了越来越多无法满足的需求以及可以优化的功能点。目前有赞的Flink SQL是在Yarn上运行，但是在公司应用容器化的背景下，可以统一使用公司K8S资源池，同时考虑到任务之间的隔离性以及任务的弹性调度，Flink SQL任务K8S化是必须进行的，所以我们也希望通过这次升级直接利社区的on K8S能力，直接将FlinkSQL集群迁移到K8S上。特别是社区在Flink 1.13中on Native K8S能力的支持完善，为了紧跟社区同时提升有赞实时计算引擎的能力，经过一些列调研，我们决定将有赞实时计算引擎由Flink 1.10升级到Flink 1.13.2。

本文介绍了有赞如何通过JVM、机器规格和参数调优，实现提升稳定性和降低成本的双重收益。

介绍了有赞的数据中台产生的背景和建设思路。

高频问题在技术支持岗位管理中有哪些“生命周期”呢？我将其分为四个阶段：问题暴露阶段、信息传递阶段、问题解决阶段、问题回顾阶段。

有赞现有的线上保障手段可分为运维层面、产品层面、安全层面、服务层面和测试层面等维度。本文重点介绍我们在测试层面的实践。

在有赞，技术支持日常工作中最重要的内容是快速解决商家问题，通常线上发生问题后我们将会根据影响商家数、影响范围、影响场景做级别区分。但商家在遇到问题时候，不同商家反馈的现象描述也存在区别、接待处理的人员也是来自不同业务线。这里会导致技术支持在查看问题工单，在对影响范围的判断上比较滞后，下面我们就来探索如何从不同问题中找出相似问题。

首先在判断 2 个现象描述是否为同一问题时候，通过模块是没办法区分的，比如营销玩法-优惠券，关于优惠券的问题会非常多，无法具体场景的区分。不可能是优惠券场景的都有问题，那么我们只有从不同工单中的描述内容中去进行字符串匹配。

中台营销业务涉及丰富的玩法和众多组合场景。活动优惠价格计算，再加上复杂的叠加互斥规则，很容易造成场景遗漏，甚至造成资损。传统的功能测试需要极大的人力成本，且大量重复性的回归测试会导致测试积极性受挫。因此，流量回放成了主要的自动化回归手段~

目前有赞共享技术团队测试介入的微服务应用有几百个，大部分底层应用的单测覆盖率在 70% 以上，同时测试组提供的多纬度集成测试自动化的覆盖率也在 70% 以上。有赞的业务发展非常快，当存量代码较多时，新项目功能测试的整体覆盖率偏低是正常现象，另外开发提测时，并不能依据已有的全量覆盖率来判断对新增代码的自测完成度，基于这个背景，我们研发了增量代码覆盖率工具，作为项目质量的参考纬度之一，支持统计功能测试、单测和集成测试，并集成到了 DevOps 平台。

如何从浩瀚的知识库中搜索出我们想要的结果，本文将从算法模型和工程实现为你介绍有赞知识库检索匹配的实践方法。

对于技术支持团队来说，很大一个优化工作的方向是从无序纷乱的日常线上问题处理和客户支持的过程中梳理事务、整理 SOP（标准流程），然后从 SOP 中提炼出各类可以被自动化的场景需求。

然而从「混乱-->标准-->自动化」的过程是比较反直觉的。因为重复于一些自己熟悉的工作流程、动作会给人带来安全感，这种安全感很容易使人安于当前的工作现状。因此很难跳出圈子来去分析和观察一些工作内容和流程是不是可以被优化。

在有赞，除了鼓励对接线上问题和商家的小伙伴有效能改进的意识，我们也有专门的角色去分析和提炼日常工作中的可以被自动化完成的工作。机器人流程自动化（RPA）相关的技术，就是我们其中的一个探索和应用方向。