# Wetech Classification Standard

## 1. Introduction

This document defines the Wetech team's standardized classification system for Jira tickets. This system is used by the Wetech support team to categorize issues based on their investigation outcomes and service activities.

The classification uses a three-level hierarchical structure (`L1` -> `L2` -> `L3`) that separates **Issue Investigation** (reactive problem solving) from **Service Support** (proactive assistance and consulting).

## 2. Design Philosophy

The core design philosophy of this system:

* **Outcome-Focused**: Classify based on the final investigation result or service delivered, not the initial symptoms.
* **Root Cause Oriented**: For investigation tickets, identify the actual root cause component (TiDB, Hardware, Workload).
* **Service Value Capture**: For support tickets, capture the type of proactive service delivered.
* **Complementary to Existing Dimensions**: This classification provides an alternative perspective that can be cross-analyzed with Problem Pattern, Root Cause, and Service Type.

## 3. Classification Structure

The system uses a three-level hierarchy:

| Level | Name | Description |
|-------|------|-------------|
| **L1** | Category | Top-level category: `Issue Investigation` or `Service Support` |
| **L2** | Domain | The domain of investigation or support: `TiDB`, `Hardware`, `Workload`, `Service Support` |
| **L3** | Specific Type | The specific root cause pattern or service type |

## 4. Classification Table

### L1: Issue Investigation

Reactive problem-solving where the team investigates and diagnoses issues.

#### L2: TiDB (Database Kernel Issues)

| L3 Code | L3 Name | Description |
|---------|---------|-------------|
| `alert_analysis` | Alert Analysis | Investigate an alert to confirm impact and severity |
| `backup_conflict` | Backup Conflict | Backup tasks interfere with performance or cause issues |
| `bad_query_plan` | Bad Query Plan | The optimizer chooses an inefficient execution plan, leading to slow queries or high resource usage |
| `ddl_exception` | DDL Exception | A DDL job fails, hangs, or behaves abnormally during schema changes |
| `downstream_bottleneck` | Downstream Bottleneck | Downstream system bottleneck affects TiCDC or replication performance |
| `hotspot_in_statistics` | Hotspot in Statistics | Statistics show skew/hot partitions that concentrate traffic on specific keys/ranges |
| `metrics_threshold` | Metrics Threshold | A metric crosses a threshold (CPU/latency/IO/etc.); may be noise or an early sign of issues |
| `provisioning_configuration` | Provisioning (Configuration) | Problems caused by wrong/insufficient configuration, sizing, or deployment settings |
| `slow_statistics` | Slow Statistics | Statistics collection or analyze is slow/blocked, causing stale stats and potential plan issues |
| `sql_hotspot` | SQL Hotspot | Specific SQL patterns or keys create hotspots, driving uneven load and high latency |
| `ticdc_bug` | TiCDC Bug | A confirmed or suspected defect in TiCDC replication components |
| `tidb_bug` | TiDB Bug | A confirmed or suspected defect in TiDB (SQL layer) behavior or performance |
| `tikv_bug` | TiKV Bug | A confirmed or suspected defect in TiKV (storage/raft layer) behavior or performance |
| `pd_bug` | PD Bug | A confirmed or suspected defect in Placement Driver (PD) behavior or performance |
| `grafana_bug` | Grafana Bug | A confirmed or suspected defect in Grafana (monitor system) behavior or performance |
| `dashboard_bug` | Dashboard Bug | A confirmed or suspected defect in Dashboard (monitor system) behavior or performance |
| `ticdc_capability_bound` | TiCDC Capability Bound | TiCDC hits a capability limit (throughput/latency/replication lag) under current workload or resources |
| `tidb_capability_bound` | TiDB Capability Bound | TiDB hits capability limit (CPU/IO/concurrency/QPS) and can't meet performance/latency targets |
| `tidb_release_features` | TiDB Release Features | Features introduced in a TiDB release that affect behavior or require understanding |
| `transaction_conflict` | Transaction Conflict | Transactions conflict (e.g., write-write) causing retries or failures due to contention |
| `transaction_exception` | Transaction Exception | A transaction fails due to errors other than normal conflicts (timeouts, locks, aborted, etc.) |
| `unbalanced_region` | Unbalanced Region | Regions/leaders are unevenly distributed, causing hotspot nodes or unstable performance |
| `uncertain_root_cause` | Uncertain Root Cause | The root cause is not confirmed yet; still under investigation |
| `backup_restore_exception` | Backup/Restore Exception | Backup or restore fails, is too slow, or produces errors/incomplete results |

#### L2: Hardware (Infrastructure Issues)

| L3 Code | L3 Name | Description |
|---------|---------|-------------|
| `disk_exception` | Disk Exception | Disk/storage failures or I/O errors (e.g., high latency, read/write errors, or disk full) |
| `server_exception` | Server Exception | Server-level faults (e.g., host crashes, hardware failures, or OS-level issues) |
| `network_exception` | Network Exception | Network problems affecting connectivity or performance (e.g., packet loss, high latency, or link flaps) |
| `limited_resource` | Limited Resource | Resource shortages or limits (CPU/memory/disk/IO/FDs) causing throttling or instability |

#### L2: Workload (Application/Traffic Issues)

| L3 Code | L3 Name | Description |
|---------|---------|-------------|
| `burst_workload` | Burst Workload | A sudden traffic spike or workload surge that overloads the system |
| `performance_test` | Performance Test | Performance issues caused by stress testing, benchmarking, or synthetic load |
| `software_arch_issue` | Software/Arch Issue | The issue is not caused by the database itself, but by the application architecture and/or third-party software |
| `unexpected_operation` | Unexpected Operation | The issue is caused by an unexpected (unintended) application operation |

### L1: Service Support

Proactive assistance and consulting services delivered to customers.

#### L2: Service Support

| L3 Code | L3 Name | Description |
|---------|---------|-------------|
| `capacity_assessment` | Capacity Assessment | Help evaluate current/future capacity needs (CPU, memory, storage, QPS) and plan sizing |
| `consult` | Consult | Provide technical consulting, recommendations, and best practices for the customer's case |
| `deployment_advocate` | Deployment Advocate | Help with deployment/installation, environment setup, and go-live guidance |
| `provisioning_advocate` | Provisioning Advocate | Help provision resources and configure the cluster/services correctly |
| `version_upgrade_advocate` | Version Upgrade Advocate | Help plan and execute version upgrades, including risk checks and rollback plans |
| `scale_advocate` | Scale Advocate | Help with scaling (scale out/in, add/remove nodes) and capacity expansion strategies |
| `solution` | Solution | Provide an end-to-end solution design or workaround for a specific problem or requirement |
| `sql_performance` | SQL Performance | Help optimize SQL performance (indexes, plans, statistics, tuning suggestions) |
| `standby_service` | Standby Service | Provide on-call/standby support during critical windows (e.g., release, migration) |
| `health_check` | Health Check | Perform a system health review and report issues/risks with improvement suggestions |

## 5. Usage Guidelines

1. **Classify at Resolution**: Apply this classification when the ticket is being resolved, after the investigation is complete.
2. **Select the Most Specific Path**: Choose the L1 -> L2 -> L3 path that best describes the outcome.
3. **Investigation vs. Support**: If the ticket involved both investigation and support, classify based on the primary activity.
4. **Uncertain Cases**: Use `uncertain_root_cause` only when investigation is truly incomplete, not as a default.

## 6. Relationship to Other Dimensions

### Wetech vs. Problem Pattern

| Aspect | Wetech Classification | Problem Pattern |
|--------|----------------------|-----------------|
| **Focus** | Root cause outcome | User-facing symptom |
| **Timing** | At resolution | At triage |
| **Perspective** | Engineering diagnosis | Support triage |

### Wetech vs. Root Cause

| Aspect | Wetech Classification | Root Cause |
|--------|----------------------|------------|
| **Granularity** | Domain + specific type | Component + subcomponent |
| **Coverage** | Includes service support | Technical causes only |
| **Team Origin** | Wetech team | Cloud team |

## 7. Cross-Reference with Existing Classifications

| Wetech L2 | Wetech L3 | Similar Problem Pattern | Similar Root Cause |
|-----------|-----------|------------------------|-------------------|
| TiDB | bad_query_plan | kernel/slow_query | kernel/optimizer_executor/incorrect_plan |
| TiDB | tidb_bug | kernel/bug | kernel/* |
| TiDB | ticdc_bug | data_utils/cdc_* | kernel/cdc_fault/* |
| Hardware | disk_exception | cloud_vendor/disk_jitter | cloud_vendor/resource_degradation/storage_performance_issue |
| Hardware | network_exception | connectivity/* | cloud_vendor/resource_degradation/network_performance_issue |
| Workload | burst_workload | kernel/high_resource_usage | (application-side) |
| Service Support | sql_performance | consultation/* | (N/A - service) |
| Service Support | health_check | operation/health_check | (N/A - service) |