Building and Managing Business Monitoring Indicators: Principles, Design, and Implementation

Significance of Business Monitoring

Metrics are defined numerical values used to quantify and abstract facts; technical staff must consider both technical and business metrics.

1) Technical Metrics

Technical metrics such as service availability, performance TP99, and call volume help developers understand system status and detect issues early, but they cannot guarantee the absence of business problems caused by non‑technical factors.

2) Business Metrics

Business metrics focus on data correctness and completeness, playing a crucial role in system stability management and data‑driven decision making.

2.1) Early Problem Detection Monitoring business metrics can reveal technical or data issues, shortening mean time to repair (MTTR).

2.2) Understanding Business Operations Analyzing metrics such as order volume or delivery time helps identify operational trends and plan strategies.

2.3) Driving Business Operations Business monitoring can proactively drive improvements, e.g., optimizing delivery routes when regional latency exceeds expectations.

3) Relationship Between Technical and Business Metrics

Technical and business data correctness are interrelated; a failure in a technical metric often leads to business metric failure, but the reverse is not always true.

One technical metric may correspond to one or many business metrics, and vice versa.

Basic Process for Building a Business Indicator System

1) Define Indicator Value Understand the core value of the service or API and ensure the metric reflects that value.

2) Measurability Verify the metric can assess data accuracy and detect configuration or upstream issues.

3) Operability Ensure the metric can trigger actionable responses; otherwise it is meaningless.

4) Understandability The metric should be easily understood by the whole team.

Indicators do not need sophisticated models; they must reflect real business conditions and be maintainable.

Business Indicator Design

2.1) Indicator Classification

Indicators are classified as:

Basic indicators: atomic, indivisible business attributes.

Composite indicators: derived from basic indicators through calculations.

Derived indicators: combine basic/composite indicators with dimensions or statistical attributes (e.g., cumulative values, YoY).

2.2) Characteristics of a Good Indicator

Good indicators are clear, actionable, comparable, simple, and monitorable.

Methods and Tools for Business Indicator Monitoring

Common methods include:

Year‑over‑year / month‑over‑month comparison to show trends.

Standard deviation analysis for anomaly detection.

Intelligent threshold alerts based on historical data.

Follow‑up After Business Indicator Alarm

When an alarm triggers, analyze whether it stems from normal logic, code issues, upstream parameters, or configuration problems.

Practical Implementation – Iterative Improvement

1) Small Steps, Fast Runs Start with coverage of P3/P4 level incidents, then iterate and refine.

1.1) From Nothing to Something Example: a synchronization success‑rate metric initially noisy due to input anomalies; after filtering, it became stable and meaningful.

1.2) From Something to Accurate Removing irrelevant noise made the metric reliable.

|xx服务>tid=xxxx>orderId=xxxxxxxx>|transferService|-1|Tue Jan 07 00:00:00 CST 2025

Model Improvement

2.1) Pre‑order – Settlement Calendar

Images illustrate early calendar monitoring using pfinder.

2.2) Post‑order – Order Transmission Rate

Addresses scenarios where business configuration data is inaccurate.

2.3) After‑sale – Reverse Pickup Calendar

Monitors calendar availability, length, and wave options to detect risks early.

Common Pitfalls

1) Too Many Indicators More indicators do not equal better monitoring.

2) Unclear Definitions Indicators must have clear definitions and shared understanding.

3) Prefer Fewer Over Redundant Use the minimal set of indicators that can explain issues.

4) Indicators Must Enable Rapid Problem Localization Alarms should include logs with order IDs, trace IDs, error codes, etc., for quick diagnosis.

5) Monitoring Code Must Not Impact Technical Availability Monitoring code should catch exceptions and never affect normal service logic.

Future Plans

1) Refine existing business indicators for faster, more accurate alerts.

2) Build a link‑level business indicator system for external order flows.