跳到主要内容

Service Requirement

AWS Graviton Self-Assessment- Service Requirement

Hardware & OS Prerequisites​

Supported CPU Architectures​

The system currently provides comprehensive, native support for the following mainstream 64-bit processor architectures, featuring deep instruction-set-level optimizations specifically designed for big data I/O and parallel computing scenarios:

  • x86_64 (AMD64) Architecture:
    • In the AWS environment, it is fully compatible with mainstream EC2 instance families such as M5/M6i (General Purpose), C5/C6i (Compute Optimized), and R5/R6i (Memory Optimized).
  • ARM64 (aarch64) Architecture:
    • Fully compatible with and deeply optimized for modern ARM architectures to deliver a superior performance-per-watt ratio.
    • We strongly recommend utilizing instances powered by the AWS Graviton series processors. For high-concurrency query and data ingestion scenarios in production, the M6g/M7

Supported Operating Systems​

Please ensure that your server is running a supported enterprise-grade 64-bit Linux operating system. The kernel version must meet the foundational dependency requirements of Sensors Data and must perfectly match the underlying CPU architecture.

descript

Architecture Parity​

Version Support & Release Date​

As a significant milestone in the evolution of our multi-architecture underlying compute capabilities, Sensors Data officially declares: Starting from version 3.0 (officially released in July 2024), Sensors Data fully and natively supports the AWS Graviton (ARM64) architecture. From this version onward, our foundational runtime base, data collection modules, and all upper-layer analytics engines have undergone deep compilation and performance tuning specifically for the ARM64 instruction set.

Feature Parity Declaration​

To facilitate multi-architecture support, Sensors Data is built on a single, unified codebase. All product modules, data analytical capabilities, and interfaces running on the AWS Graviton (ARM64) architecture maintain 100% feature parity with the traditional x86_64 architecture. Whether the underlying infrastructure relies on traditional x86 physical servers or modern Graviton instances, all business-layer features utilized by customers—including data ingestion SDKs, global user segmentation, real-time query analytics engines, visual dashboards, and Open APIs—remain strictly identical.

Release Cadence Parity​

To ensure a consistent operational experience and maintain a strict system security baseline for customers across all architectures, all major and minor version updates, as well as critical security patches, are released completely synchronously for both the AWS Graviton and x86 architectures.

Resource Provisioning & Tagging Specifications​

To ensure system security, high availability, and transparent cloud cost management, please strictly adhere to the resource allocation and network planning guidelines in this section.

Infrastructure Provisioning Guide​

Before running the Sensors Data automated deployment scripts, please prepare the following core architectural components in your environment:

Basic Network and High Availability Topology​

VPC & Subnets: We recommend creating a dedicated VPC within your selected Region. Please provision Private Subnets across at least two AZs for deploying the Sensors Data core compute and storage nodes.

Load Balancing​

In a standard production environment, provisioning __1 __Application Load Balancer is typically sufficient to meet the needs of most scenarios:

  • External Access (Internet/Business-facing): The Load Balancer should be configured as internet-facing or internal , depending on your business data collection pipeline. It serves as a unified entry point to receive data streams collected by various SDKs and provides HTTPS access to the Sensors Data system for internal users.

Security Group and Port Access Rules​

Please configure dedicated Security Groups for the Sensors Data cluster.

Internal Cluster Communication: Within the Security Group allocated to the Sensors Data EC2 instances, it is mandatory to permit instances within this same Security Group to communicate with one another across all relevant server ports. This ensures the normal interaction and proper functioning of distributed components.

Inbound Rules: Only expose the necessary ports to external sources.

Resource Tagging​

To ensure your company can achieve precise Cost Attribution in the environment, we explicitly guide and strictly require customers to implement a standardized tagging workflow when provisioning resources.

Scope of Resources Requiring Tags​

When creating the following resources , standard tags must be uniformly applied:

  • Compute Resources: All cloud server instances hosting Sensors Data system components (including both x86_64 and ARM64 architecture instances).
  • Storage Resources: All cloud disks (system and data volumes) attached to the compute instances, as well as associated snapshots.
  • Network Resources: Load balancers, elastic network interfaces (ENIs), and NAT Gateways dedicated to Sensors Data workloads.

Standard Tag Key-Value Examples​

Please ensure the following tags are integrated into your resource configurations (You can adjust the Key names according to their internal cloud management standards, but retaining the identifier Value is highly recommended):

  • Core Cost Attribution Tags (Mandatory):
    • Key: Project
    • Value: SensorsData
  • Environment and Operations Tags (Recommended):
    • Key: Environment
    • Value: Production or Staging
    • Key: Architecture
    • Value: ARM64 or x86_64

Enterprise Support & SLA​

Sensors Data is committed to providing the highest level of 24/7 stability assurance for our enterprise customers' digital foundations. Our first-party service and support system is strictly independent of the underlying compute hardware. We enforce a globally unified service management standard across all officially supported deployment environments and compute platforms.

5.1 Standardized Technical Support Matrix​

Sensors Data has built a cross-platform, architecture-agnostic standardized troubleshooting and IT operations support system. When customers deploy their business workloads in any supported environment—including AWS Graviton (ARM64) instances—they seamlessly integrate into Sensors Data's highest-tier technical support matrix, which encompasses the following core channels:

  • Dedicated Customer Success & Expert Support Groups: We establish dedicated technical support groups (via Enterprise IM tools) for each enterprise customer. Our delivery architects and Technical Support Engineers (TSEs) provide highly efficient, point-to-point communication covering cluster deployment, performance tuning, and business enablement across all hardware environments.
  • Enterprise 24/7 Ticketing System: We provide a 24/7 online ticketing system. For complex underlying component errors or architectural upgrade requirements, our support team has established Standard Operating Procedures (SOPs) that cover all supported instruction set architectures, ensuring efficient and precise ticket routing and resolution.
  • 24/7 Emergency Response Hotline: For maximum-severity P0/P1 incidents in production environments (e.g., core data flow interruptions), we provide round-the-clock emergency telephone intervention. Our expert team will immediately assemble a cross-functional War Room to deliver end-to-end emergency recovery services.

5.2 Globally Unified Service Level Agreement (SLA)​

Regarding service response timeliness and quality control, Sensors Data delivers a single, highest-standard Service Level Agreement (SLA) to all customers globally. The system's incident response, fault demarcation, and recovery processes have been thoroughly standardized:

  • Standardized Mean Time to Acknowledge (MTTA): For technical requests of varying priorities (P0 to P3), the initial acknowledgment and intervention times by our support team strictly adhere to a unified, enterprise-grade baseline.
  • Predictable Mean Time to Resolve (MTTR): Benefiting from our R&D infrastructure team's profound experience in cross-platform adaptation and troubleshooting, we can transcend hardware boundaries when dealing with complex OS-level or underlying middleware issues. This allows us to deliver predictable, high-standard fault demarcation and business recovery times across all architectures.

3.1 Version Support & Release Date

作为底层算力多架构演进的重要里程碑，神策数据在此明确官方声明：神策数据从3.0 版本（正式发布于 2024年07月）起，正式全面、原生支持 AWS Graviton (ARM64) 架构。 自该版本起，我们的基础运行底座、数据采集模块及所有上层分析引擎均已完成针对 ARM64 指令集的深度编译与性能调优。

3.2 Feature Parity Declaration

针对多架构的并行支持，神策数据基于单一代码库 构建，在 AWS Graviton (ARM64) 架构上运行的产品模块、数据分析能力与接口，与传统 x86_64 架构保持 100% 的功能对等。 无论底层基础设施依托于传统的 x86 物理机还是新型的 Graviton 实例，客户所使用的数据接入 SDK、全域用户分群、实时查询分析引擎、可视化看板及 Open API 等所有业务层功能均一致。

3.3 Release Cadence Parity

为了保障全架构客户的运维体验与系统安全基线，针对 AWS Graviton 和 x86 架构大小版本更新以及核心安全补丁均保持完全同步发布。

4.1 基础设施预置流程指南

在正式运行神策数据自动化部署脚本之前，请在您的云端环境中准备好以下核心架构组件：

4.1.1 基础网络与高可用拓扑

  • 虚拟私有网络 (VPC) 与子网： 建议在所选的云厂商地域（Region）内创建一个专用的 VPC。为满足企业级高可用（HA）要求，请至少跨两个可用区（Availability Zones, AZs）划分私有子网，用于部署神策数据的核心计算与存储节点。

4.1.2 负载均衡器配置

在标准生产环境中，通常仅需准备 1 个七层/应用级负载均衡器（如 AWS ALB、阿里云 SLB 等） 即可满足绝大多数场景需求：

  • 对外接入 (面向公网/业务侧)： 负载均衡器配置为面向互联网（公网型）或内部私网（内网型，取决于您的业务端数据采集链路），用于统一接收各端 SDK 采集的数据流，并为内部业务人员提供神策分析 UI 面板的 HTTPS 访问入口。

4.1.3 安全组与网络隔离规范 (Security Group Rules)

遵循云原生“最小权限”安全最佳实践，请为神策集群配置独立的网络安全组（Security Group / 防火墙策略）。

  • 集群内部通信： 在分配给神策计算实例的安全组内，必须允许该安全组内的所有实例互相通过相关的服务端端口进行通信，以保障分布式组件（如 Kafka, 数据库, 查询路由）的正常交互。
  • 入站规则 (Inbound Rules)： 仅对外开放以下必要端口：

企业级技术支持与 SLA (Enterprise Support & SLA)

神策数据（Sensors Data）致力于为企业客户的数字化底座提供最高规格、全天候的稳定保障。我们的原厂服务保障体系独立于底层计算硬件，针对所有官方支持的部署环境与算力平台，均执行全局统一的服务管理规范。

5.1 标准化技术支持矩阵 (Standardized Support Matrix)

神策数据构建了跨平台、架构无关的标准化排障与运维服务体系。当客户将业务负载部署于包括 AWS Graviton (ARM64) 实例在内的任何受支持环境时，均直接无缝接入神策最高级别的原厂技术支持矩阵，涵盖以下核心渠道：

  • 专属客户成功与支持专家群组： 为每个企业客户建立专属的企微/钉钉/飞书技术保障群。由神策原厂的交付架构师与技术支持专家 (TSE) 提供点对点的高效沟通，全面覆盖各类硬件环境下的集群部署、性能调优与业务赋能。
  • 企业级全天候工单系统： 提供 24/7 开放的在线工单系统。针对复杂的底层组件报错或架构升级需求，支持团队已沉淀出覆盖全指令集架构的标准作业程序 (SOP)，确保工单流转的高效与精准。
  • 7x24 小时紧急响应热线： 针对生产环境中的 P0/P1 级最高严重度故障（如核心数据流中断等），提供全天候的紧急电话介入。专家团队将第一时间拉起跨部门作战室 (War Room)，提供端到端的应急恢复服务。

5.2 全局统一的服务等级协议 (Globally Unified SLA)

在服务响应时效与质量管控上，神策数据向全网客户交付单一、最高标准的服务等级协议（SLA）。系统的故障响应、定界与恢复流程已实现彻底的标准化封装：

  • 标准化的平均响应时间 (MTTA)： 针对不同优先级的技术诉求（P0 至 P3），支持团队的初次接办与介入时间严格遵循统一的企业级基线。
  • 可预期的平均恢复时间 (MTTR)： 得益于研发底座团队深厚的跨平台适配与排障经验，在应对操作系统层级或底层中间件的复杂问题时，我们能够跨越硬件形态的壁垒，交付可预期、高标准的故障定界与业务恢复时效。

是什么 (概述) -> 跑在哪 (环境要求) -> 没阉割 (对等性声明) -> 怎么搞 (部署与标签) -> 出事找谁 (技术支持)。

一级目录 1：产品与联合解决方案概述 (Overview)​

【设计目的】：定调产品形态，明确满足 AWS 对“部署模式 (Deployment Model)”的披露要求。

  • 二级目录 1.1：神策数据 CDP 简介
    • 具体内容： 简要介绍神策产品的大数据分析能力。
  • 二级目录 1.2：基于 AWS Graviton 的联合优势
    • 具体内容： 强调结合 AWS 自研 ARM 架构带来的超高性价比、降本增效及低碳环保优势。
  • 二级目录 1.3：AWS 部署方式说明 (核心考点)
    • 具体内容： 明确声明神策采用**“客户托管 / 客户自带云 (Customer-Hosted / BYOC)”**模式。说明底层 AWS 资源（如 EC2、ALB）由客户在自己的 AWS 账号内预置，神策负责提供自动化脚本进行纯应用层的软件安装。

一级目录 2：系统架构与环境要求 (System Prerequisites)​

【设计目的】：精准命中 AWS 关于“处理器架构”、“操作系统”和“依赖项支持”的核查点。

  • 二级目录 2.1：支持的处理器架构 (核心考点)
    • 具体内容： 使用清晰的表格或列表，明确将 AWS Graviton (ARM64 / aarch64) 列为与 x86_64 并在的一级受支持架构。建议直接写明推荐的实例族（如 M6g, R6g, C7g 等）。
  • 二级目录 2.2：支持的操作系统 (核心考点)
    • 具体内容： 列出支持 Graviton 实例的 ARM64 操作系统镜像 (AMI) 要求。例如：Amazon Linux 2/2023 (ARM64)、Ubuntu 22.04 LTS (ARM64)、CentOS 8 (ARM64) 等。
  • 二级目录 2.3：底层依赖与环境准备
    • 具体内容： 简要提及神策自动化部署工具已原生兼容 ARM 架构，安装脚本会自动识别并拉取适用于 ARM64 的底层中间件（如 JDK, MariaDB 等）。

一级目录 3：版本发布与对等性声明 (Version & Parity Declaration)​

【设计目的】：这是应对 AWS FDL（基础生命周期）审核的最核心防线，必须用词斩钉截铁。

  • 二级目录 3.1：支持的产品版本与发布日期 (核心考点)
    • 具体内容： 明确写出：“神策数据从 vX.X.X 版本（发布于 YYYY年MM月DD日）起，正式全面原生支持 AWS Graviton 架构。”
  • 二级目录 3.2：功能对等性承诺 (Feature Parity - 核心考点)
    • 具体内容： 官方声明：“神策数据基于单一代码库构建，在 AWS Graviton (ARM64) 架构上运行的产品模块、数据分析能力与接口，与传统 x86_64 架构保持 100% 的功能对等，无任何功能降级或缺失。”
  • 二级目录 3.3：统一的发布节奏 (Release Cadence - 核心考点)
    • 具体内容： 官方声明：“得益于自动化的多架构 CI/CD 流水线，针对 AWS Graviton 和 x86 架构的安装包、大小版本更新以及核心安全补丁均保持__完全同步发布__，确保零延迟。”

一级目录 4：AWS 云上资源预置与标签规范 (Provisioning & Tagging)​

【设计目的】：指导客户如何开机器，并完美解决 FinOps（成本归因）和打标签的合规要求。

  • 二级目录 4.1：基础设施预置流程指南
    • 具体内容： 提供给客户的操作指导，说明需要开通哪些安全组端口、准备多少个 ALB 等（可附带一份简易的架构拓扑图）。
  • 二级目录 4.2：资源标签添加与 FinOps 流程 (核心考点)
    • 具体内容： 明确指导客户：“为确保云上资源的成本精确归因与 FinOps 可见性，请在预置 AWS EC2、EBS 等资源时，统一添加以下标准标签 (Tags)：例如设置键值对 Project : SensorsData。” 说明神策完全兼容并支持 AWS 标签最佳实践。

一级目录 5：企业级技术支持与 SLA (Enterprise Support)​

【设计目的】：给客户吃定心丸，同时满足 AWS 关于“多架构支持渠道无差异”的硬性规定。

  • 二级目录 5.1：多架构统一技术支持通道 (核心考点)
    • 具体内容： 明确指出：“针对在 AWS Graviton 实例上部署神策系统的客户，我们提供与 x86 架构__完全一致的技术支持通道与响应 SLA__。” 列出支持渠道（如：专属支持群组、工单系统、7x24 紧急响应电话等）。