# Jira Ticket Classification Standard ## 1. Introduction This document defines the standardized root-cause classification system for Jira tickets. This system aims to unify the team's approach to categorizing issues to enable accurate data statistics and trend analysis, which in turn drives product improvements, optimizes operational efficiency, and provides data-driven support for decision-making. ## 2. Design Philosophy The core design philosophy of this classification system is to distinguish between an **"Analyzable Root Cause Pattern"** and a **"Specific Root Cause"**. * **Analyzable Root Cause Pattern**: This is the target for this classification system. It categorizes issues into a finite, standardized set of categories suitable for high-level statistics (e.g., `slow_query`). This allows us to quantify and track the frequency and trends of a particular type of problem. * **Specific Root Cause**: This refers to the deepest, most specific reason causing an individual issue (e.g., "a missing index on the `email` column of the `users` table"). This type of information should be recorded in detail within the **Jira ticket's description, comments, or a dedicated RCA text field**, not as an option in this classification system. In short, the goal of this system is not to answer "What is the specific cause of this issue?" but rather "To which analyzable problem pattern does this issue belong?". ## 3. Classification Structure The system uses a flattened two-level structure (`L1` -> `L2`) to achieve a balance between precision and ease of use. ### Level 1 (L1): Root Cause Domain Level 1 defines the highest-level **"Root Cause Domain"** or **"Area of Responsibility"** for an issue. It answers the question: "To which broad domain does this issue ultimately belong?" Examples: `kernel`, `operation`, `cloud_vendor` ### Level 2 (L2): Problem Pattern Level 2 defines the specific, **quantifiable "Problem Pattern"** within that Root Cause Domain. It answers the question: "Within this domain, what kind of typical problem is it?" Examples: `slow_query`, `scaling`, `oom` ## 4. Usage Guidelines To ensure data consistency and accuracy, team members should follow these guidelines when handling Jira tickets: 1. **Classify Based on the Final Conclusion**: Tickets should be classified after the investigation is complete and the core problem pattern has been identified, not based on the initial customer report. 2. **Select the Most Representative Pattern**: Choose the `L1` and `L2` combination that best summarizes the essence of the issue. 3. **Detail the Specific Root Cause in the Ticket**: Document the detailed analysis process and the specific root cause in the ticket's description or comments. ## 5. Classification Table The following is the complete classification definition table. | Level 1 (L1) | Level 2 (L2) | Description | | :---------------------------------------------- | :------------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------- | | **Kernel** `(kernel)` | **Slow Query** `(slow_query)` | Slow SQL query execution that requires analysis or tuning. | | | **High Resource Usage** `(high_resource_usage)` | High resource utilization, such as CPU, memory, or IO. | | | **Performance Jitter** `(performance_jitter)` | Unexpected latency or performance instability in the database service, e.g., Leader Drop. | | | **Slow Write** `(slow_write)` | Poor write performance for DML, data loading, etc. | | | **Query Error** `(query_error)` | An SQL execution returns an unexpected error. | | | **Inconsistent Behavior** `(inconsistent_behavior)` | Database behavior does not match documentation or expectations. | | | **Stuck Component** `(stuck_component)` | A core component is stuck or unresponsive but has not crashed. | | | **DDL Issue** `(ddl)` | A DDL operation takes too long, fails, or causes problems. | | | **OOM** `(oom)` | A core component crashed due to an Out of Memory (OOM) error. | | | **Panic** `(panic)` | A core component experienced a panic due to other internal reasons. | | | **Bug** `(bug)` | A confirmed or highly suspected product kernel defect. | | **Operation** `(operation)` | **Scale Out** `(scaling_out)` | Adding new nodes to the cluster (e.g., TiKV, TiFlash). | | | **Scale In** `(scaling_In)` | Safely removing nodes from the cluster. | | | **Scale Up** `(scaling_up)` | Increasing the specifications of existing nodes (e.g., CPU, Memory). | | | **Scale Down** `(scaling_down)` | Decreasing the specifications of existing nodes. | | | **Upgrade** `(upgrade)` | Performing a version upgrade for the cluster. | | | **Config Change** `(config_change)` | Modifying configuration parameters for the cluster or nodes. | | | **Node Restart** `(node_restart)` | Restarting a specific service node. | | | **Data Cleanup** `(data_cleanup)` | Cleaning up expired or invalid data. | | | **Health Check** `(health_check)` | Proactively performing a health check on the cluster. | | | **Manual Scheduling** `(manual_scheduling)` | Manually triggering or intervening in PD scheduling (e.g., adjusting balance speed). | | | **Whitelist Request** `(whitelist_request)` | A request to enable a feature that is not generally available. | | | **Quota Request** `(quota_request)` | A request to increase quotas for nodes, storage, etc. | | **Data Utils** `(data_utils)` | **TiDB Lightning** `(tidb_lightning)` | Issues related to importing data using TiDB Lightning. | | | **DM** `(dm)` | Issues related to migrating/synchronizing data using the DM (Data Migration) tool. | | | **BR** `(br)` | Issues related to backing up or restoring data using the BR (Backup & Restore) tool. | | | **CDC Latency** `(cdc_latency)` | The Changefeed data synchronization task is experiencing latency. | | | **CDC Interruption** `(cdc_interruption)` | The Changefeed task was interrupted or has an error. | | **Monitoring** `(monitoring)` | **Alert** `(alert)` | Investigating and handling an alert triggered by the system. | | | **Metrics Interpretation** `(metrics_interpretation)` | A consultation regarding the meaning, trend, or abnormality of monitoring metrics. | | | **Custom Rule** `(custom_rule)` | A request to configure or modify custom monitoring or alert rules. | | **Connectivity** `(connectivity)` | **Driver Issu** `(driver)` | Connection failure due to an incompatible client driver version or protocol. | | | **Timeout or Refused** `(timeout_or_refused)` | The connection was refused or timed out. | | | **VPC Peering** `(vpc_peering)` | Issues with VPC network connectivity or routing. | | | **IP Whitelist** `(ip_whitelist)` | The access IP is not in the whitelist or security group. | | **Consultation** `(consultation)` | **How To** `(how_to)` | Technical questions about product features, concepts, or principles. | | | **Best Practice** `(best_practice)` | A request for advice on best practices for solution or schema design. | | **Feature Request** `(feature_request)` | **New Feature** `(new_feature)` | A request for a new feature or capability that the product currently lacks. | | | **Improvement** `(improvement)` | A suggestion to improve or enhance an existing product feature. | | **Cloud Vendor** `(cloud_vendor)` | **Infra Fail** `(infra_fail)` | A failure in the underlying cloud vendor's infrastructure, such as VMs, physical hosts, or network. | | | **Disk Jitter** `(disk_jitter)` | Sub-par performance or jitter in the cloud vendor's disk storage. | | | **Network Latency** `(network_latency)` | High latency in the underlying cloud vendor's network. | | **Others** `(others)` | **Not Our Issue** `(not_our_issue)` | The issue is ultimately determined to be caused by the customer's application or a third-party component. | | | **Insufficient** `(insufficient)` | The root cause cannot be determined due to insufficient information or inability to reproduce the issue. | | | **To Be Defined** `(tbd)` | The initial state of a ticket, where there is not yet enough information to classify it effectively. |