“追求卓越”是神策军的三大信念之一。我们希望通过「卓越产品计划」，在服务客户数量越来越多、业务逻辑和技术架构越来越复杂的背景下，全面保障产品技术架构和技术支撑系统稳步提升。除了将产品打磨好之外，要在内部实现极致文化与产品研发结合的最佳实践，致力于把功能做到极致，把性能做到极致，把稳定性做到极致。

神策分析是公司成立之初推出的用户行为分析产品，支持私有化部署、云版部署等多种部署方式，如今已是神策“两云一平台”（神策分析云、神策营销云、神策数据根基平台）的重要组成部分。

本文将针对神策分析，围绕服务质量指标、错误码系统、服务治理，详细讲述解决查询报错类问题（如分析模型的查询报错、未知使用报错等）的产品迭代实践。

制定服务质量指标体系，先于客户发现问题

在我们为客户解决问题的过程中，通常能够明确地定位问题，但是我们又不满足于对具体问题的发现和解决——希望能够在客户发现实际问题之前消灭隐患，变被动为主动，先于客户发现问题。

面对千余家大大小小不同规模的私有化部署集群，传统的服务监控 + 报警的方式对运维人工的依赖较高，问题处理进度相对滞后，无法满足我们对卓越产品的需求，因此，我们决定通过制定和完善服务质量指标体系（简称 SLI)，先于客户发现问题。

制定服务质量指标体系，一方面可以将问题反馈转化为量化指标，用数据说话；另一方面，合理地监控服务质量指标的变化情况，可以在集群环境出现隐患时及时介入并处理。同时，基于服务质量指标我们也可以对产品实施效果进行持续评估，更好地指导产品优化思路。

对于不规律的查询报错类问题，服务质量指标通常包括：

1、分析模型查询错误率。神策分析核心功能度量指标，直接影响客户的查询体验。

2、单客户平均请求报错数。重点度量客户的前端使用体验，统计客户侧直观的报错数据量。

通过服务质量指标体系，我们可以在保证合规的前提下，全面洞察客户服务质量技术类指标，对于提前发现问题和观测产品服务质量的优化效果都起到重大作用。

神策分析功能丰富，依赖较多技术组件，加上私有化部署集群带来的机器配置和硬件环境差异，使得快速地定位和归因问题、解决问题成为我们提升技术支撑能力的重点。

在神策，我们一直坚持“能用产品解决的问题，就不要用服务解决”。因此，我们通过自研错误码管理系统，一方面形成一套统一的错误码规范和管理标准，以产品化的方式管理错误信息，让技术支持和运维等售后同学能够更准确地获取报错提示；另一方面也为我们提供错误码的检索能力，作为技术支持知识的一部分进行沉淀，快速针对相关错误码获取对应的原因和解决方案。

在具体的实践过程中，错误码系统包含错误码规范定义、错误码字典、开发工具和错误码展示四个部分。

• 「错误码规范定义」由“应用 - 错误阶段 - 单元 ID - 错误编号”组成，如 SA-D-1-1。其中，“核心编码”是唯一标识，用于代码开发过程，保证全局唯一性，在各种场景下固定无变更。“关键属性”用于直观描述，在错误码中直观地外显更多错误定义信息；“连接符”用于功能区分及扩展，是各个组成属性间的连接，方便各属性之间不限位数的扩展。

• 「错误码字典」用于错误码注册、查询、编辑、审批等维护与管理，通过流程机制确保错误码按照统一规范进行接入，让每一个错误码都有结构化的详细描述错误信息，能够更好地辅助问题的排查和定位。

• 「开发工具」是指错误码系统提供适用于不同技术端的错误码开发工具、适用于不同语言的 SDK & 编辑工具等，实现低成本的快速接入与开发。

• 「错误码展示」可以根据错误码的定义规范，提供产品化的通用错误提示框，以更加详细、清晰的结构化方式具体描述错误，同时提供描述信息的复制、截图、错误文件下载等功能。

到目前为止，错误码系统包含了 20+ 类错误信息，其中累计完善错误码数 700 多个。基于该错误码系统，我们的产品和技术围绕报错信息形成了更加高效的问题处理和反馈机制。

通过服务治理指标的采集与分析、错误码系统的构建，我们可以对业务中存在的各种报错问题进行统计和归因。但是在解决实际问题的过程中，我们会发现很多问题都不是复杂技术架构下对单一节点进行优化就能够解决的，通常需要进行一些系统性的治理工作。因此，结合神策的技术架构和业务特点，我们制定了服务治理的三板斧策略。

第一板斧:“应用化”重构

神策分析发展至今，产品组件的数量明显增加，不同产品组件之间也存在复杂的依赖关系。与此同时，随着公司业务的快速发展，过去的管理方式已经不能够满足产品迭代和质量标准提升的需求。因此，在神策私有化部署和云版部署多种部署模式共存的背景下，我们定义了一套服务管理标准——从技术和产品层面将服务模块划分为应用、产品组件、模块三个级别，通过明确职责范围以降低组件之间的依赖和团队之间的沟通成本。同时，将所有不符合新规范定义的服务间访问定义为“飞线”问题。围绕着新的“应用化”定义，启动多个技术重构类项目，消除“飞线”访问，降低服务间的技术耦合，实现应用化定义要求的高内聚、低耦合的目标。

第二板斧：容器化

在完成“应用化”重构的基础之上，我们将服务间存在的无状态服务和有状态服务进行剥离，同时严格避免无状态服务对本地文件、本地服务等的依赖。另外，对于新产品组件内的服务模块，我们统一构建了 Docker 镜像，将原来只能在物理机上进行裸机部署的服务进行了容器化部署的改造，支持容器化的方式进行部署。除此之外，对于打包、升级、安装等一系列流程，按照容器化标准进行改造，使产品组件的管理更加轻量和灵活。

第三板斧：容错和降级

随着产品组件数量的增多，我们需要进行服务间容错和降级的处理，以避免当部分服务出现故障时对整体业务产生影响，尽量减少底层组件的报错对实际用户体验造成的干扰。

首先，我们将依赖的底层应用组件划分为强依赖和弱依赖两种类型。对于强依赖类型的应用组件，我们提供一定的服务降级能力，比如，当查询引擎不可用时，查询请求会进行重试；但当系统整体查询资源紧张时，查询接口会尝试降级并查找历史缓存数据。对于弱依赖类型的应用组件，我们提供足够的服务容错能力，比如，当标签系统完全不可用时，在分析模型中仍然可以使用基础的元数据和属性，只是不再提供关联用户标签的分析能力。通过对服务容错和降级的处理，大大减少了服务故障对客户实际产品体验的影响。

通过以上服务治理“三板斧”，我们已经取得了预期的效果。下图是某客户上线私有部署集群之后的查询错误率情况统计，可以看到，分析模型查询错误率已经从最高时 1.2% 降低到目前的 0.2% 左右。