Phase 3: Quy Trình Vận Hành & Full-Link Stress Testing

Phiên bản đa ngôn ngữ: Bài viết này có phiên bản tiếng Anh chuẩn quốc tế tại Phase 3: Operational Engineering & Full-Link Stress Testing (tanhdev.com).

📖 Bản tiếng Anh (English Edition)

← Chương trước: Phase 2: Kiến Trúc LDC & OceanBase | Mục lục Series | Chương tiếp theo: Phase 4A: Middle Platform & CTU Risk Control →

Answer-first: Quy trình vận hành đỉnh cao của Alipay dựa trên Full-Link Stress Testing tự động hóa trên môi trường Production bằng cách gắn cờ traffic giả lập (shadow data), giúp nâng mức độ tin cậy hệ thống từ 60% lên 95% và cắt giảm nhân sự ứng trực từ 200 xuống 10 người.

Điều kiện tiên quyết: Nắm vững quy trình vận hành SRE, cơ chế kiểm thử tải hiệu năng cao, kỹ thuật phân lập dữ liệu và chiến lược hạ cấp dịch vụ trong hệ thống microservices.

Phase 3: Quy Trình Vận Hành & Chuẩn Bị

3.1 Capacity Planning

Peak Prediction Models

Vấn đề: Double 11 có traffic peak gấp hàng chục lần bình thường, nhưng chỉ diễn ra trong thời gian ngắn.

Giải pháp: Hybrid Strategy

┌──────────────────────────────────────────────────────────────┐
│               Capacity Planning Strategy                      │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│  Daily Traffic                  Peak Traffic (Double 11)     │
│       │                              │                       │
│       ▼                              ▼                       │
│   ┌───────┐                    ┌───────────┐                │
│   │On-prem│ ──── Elastic ─────►│ On-prem   │                │
│   │(Base) │      Scaling       │ + Cloud   │                │
│   └───────┘                    └───────────┘                │
│       │                              │                       │
│       │                              │                       │
│   Normal Ops                     Peak Ops                    │
│   (Year-round)                   (1-2 months)                │
│                                                               │
│   Cost Optimization: Giữ resources 1 năm → Chỉ 1-2 tháng      │
└──────────────────────────────────────────────────────────────┘

Resource Buffer Calculation:

1. Baseline: Capacity cho daily traffic (80% utilization)
2. Peak multiplier: Tính toán peak / baseline ratio
3. Buffer: Thêm 20-30% cho unexpected spikes
4. Elastic capacity: Cloud burst cho phần vượt quá on-prem

Hybrid Cloud Strategy

Cost Per Transaction Optimization

Mục tiêu: Giảm 50% cost per transaction qua các năm

Các biện pháp:

1. Co-location: Chia sẻ resources giữa online và batch
2. Elastic scaling: Scale up/down theo nhu cầu thực tế
3. Containerization: Tăng density, giảm waste
4. Automation: Giảm manual ops cost

3.2 Stress Testing System - Chi Tiết

graph LR
    CAP["Traffic capture<br/>(ghi chụp năm trước)"] --> GEN["Tải synthetic<br/>(tái tạo burst nửa đêm)"]
    GEN --> INJ["Inject trên production<br/>(cờ X-Stress-Test)"]
    INJ --> ISO["Cô lập shadow<br/>(shadow table)"]
    ISO --> OBS["Observation toàn-link<br/>(ngưỡng vỡ từng service)"]
    OBS --> REP["Báo cáo capacity<br/>(ngưỡng an toàn 11.11)"]

    style OBS fill:#e8f4f8,stroke:#2a7da0

Evolution của Stress Testing

2010: Manual single-machine testing
  ↓
2013: First full-link stress test (200+ people, all-night)
  ↓
2014: Automated stress testing system (core systems)
  ↓
2017+: Intelligent stress testing (< 10 people, work hours)

Full-Link Stress Testing Architecture

┌──────────────────────────────────────────────────────────────┐
│                Full-Link Stress Testing                      │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│   Traffic Generation                                          │
│   ┌──────────────────────────────────────────────────────┐  │
│   │  Stress Testing Controller (Intelligent)              │  │
│   │  • Generate realistic traffic patterns                │  │
│   │  • Simulate 559M users, 55M warehouses                │  │
│   └──────────────────────┬───────────────────────────────┘  │
│                          │                                    │
│   ┌──────────────────────▼───────────────────────────────┐  │
│   │                    Full Link                          │  │
│   │  CDN ─► LB ─► App ─► Service ─► Cache ─► DB         │  │
│   │   │      │      │        │        │       │            │  │
│   │   └──────┴──────┴────────┴────────┴───────┘            │  │
│   │   All components participate in stress test             │  │
│   └──────────────────────────────────────────────────────┘  │
│                                                               │
│   Data Isolation: Shadow Tables                               │
│   ┌─────────────┐    ┌─────────────┐                        │
│   │ Online Table│    │ Shadow Table│                        │
│   │ (Production)│    │ (Stress Test)│                        │
│   │   orders    │    │   orders_st  │                        │
│   └─────────────┘    └─────────────┘                        │
│   Same structure, isolated location                           │
└──────────────────────────────────────────────────────────────┘

Stress Testing Process (7 năm evolution)

Phase 1: Process & Management

Timeline (Simulated Sequence):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

T-60 days: Planning & preparation
    ├── Data preparation
    ├── Architecture reconstruction
    └── Team assignment

T-30 days: Pre-testing
    ├── Single-link debugging
    ├── Middleware transformation
    └── Business reconstruction

T-14 days: Full-link stress tests
    ├── Peak pulse simulation
    ├── Vertical jump test
    ├── Rate limiting verification
    └── Destructive testing

T-7 days: Issue fixing & re-test

T-1 day: Final preparation

T+0: Double 11 Event

T+7 days: Post-mortem
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Team Evolution:

• 2013: 200+ people, all-night testing
• 2020: < 10 people, work hours testing
• Equation: Effective solution + Adequate preparation + Reliable platform = Successful test

Phase 2: Environment Reconstruction

Business Reconstruction:

• Identify APIs affected by multiple stress tests
• Đánh giá dirty data impact
• Implement data isolation mechanisms

Middleware Transformation:

• Message queue: Separate stress test traffic
• Cache: Shadow cache keys
• Database: Shadow tables

Phase 3: Data Preparation

Two Types of Data:

1. Business Model Data:

   • User profiles
   • Product catalog
   • Inventory levels
   • Historical transactions

2. Stress Testing Base Data:

   • 559,440,000 emulated users (2019)
   • 55,944,000 warehouses
   • Realistic traffic patterns

Phase 4: Traffic Security Policy

Data Isolation:

Method: Shadow Table
- Same schema as production
- Writable stress testing data
- Isolated storage location
- Result: No data pollution

Traffic Filtering:

Method: Special identifier
- Mark stress test traffic
- Lift security policies slightly
- Prevent DDoS detection
- Result: Test runs successfully

Third-party Integration:

• 2013: Failed (không connect downstream)
• 2014+: Alipay và logistics connected
• External: Alipay cung cấp mock services

Phase 5: Test Implementation

Pre-operations:

1. System Ramp-up:

   • Cache warm-up
   • Connection pool preparation
   • Pre-load critical data

2. Logon Preparation:

   • Flash sale scenarios
   • Persistent connection warmup
   • Simulate real user login patterns

Formal Stress Testing Steps:

Peak Pulse Details:

• Simulate chính xác target peak traffic
• Test promotion-state system performance
• Verify auto-scaling triggers

Vertical Jump Test:

• Disable rate limiting/degradation
• Increase traffic đến khi system gặp exception
• Tìm “breaking point” của hệ thống
• Chỉ chạy sau khi đã đạt target traffic

3.3 Incident Response & Monitoring

graph TD
    AL["Alarm<br/>(metrics ngưỡng)"] --> AU{"Tự chữa<br/>trong RTO<2s?"}
    AU -->|"CÓ"| REC["Phục hồi tự động<br/>(failover drill đã tập)"]
    AU -->|"KHÔNG"| SH["Traffic shaving tự động<br/>+ ladder hạ cấp"]
    SH --> HUM["Human duty:<br/>quyết định kinh doanh<br/>(không thao tác kỹ thuật)"]
    SH --> REC
    REC --> POST["Postmortem line<br/>(vào changelog vận hành)"]

    style REC fill:#e8f8e8,stroke:#2a7da0
    style HUM fill:#f8f8e8,stroke:#a0a02a

“Guangming Peak” - Command Center

┌──────────────────────────────────────────────────────────────┐
│              Guangming Peak Command Center                    │
│              (光明顶 - Alibaba Xixi Campus)                  │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│   ┌──────────────────────────────────────────────────────┐  │
│   │                Giant Screens                         │  │
│   │  ┌────────────┐  ┌────────────┐  ┌────────────┐      │  │
│   │  │ Real-time  │  │ System     │  │ Business   │      │  │
│   │  │ Traffic    │  │ Health     │  │ Metrics    │      │  │
│   │  └────────────┘  └────────────┘  └────────────┘      │  │
│   └──────────────────────────────────────────────────────┘  │
│                                                               │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│   │  Commander   │  │   Alipay     │  │   Taobao     │      │
│   │   in Chief   │  │   Rep (2013+)│  │   Team       │      │
│   └──────────────┘  └──────────────┘  └──────────────┘      │
│                                                               │
│   Hundreds of engineers monitoring 24/7 during event          │
└──────────────────────────────────────────────────────────────┘

Real-time Monitoring Dashboards

Key Metrics:

1. Traffic Metrics:

   • TPS (Transactions Per Second)
   • QPS (Queries Per Second)
   • RT (Response Time)
   • Error rate

2. System Metrics:

   • CPU utilization
   • Memory usage
   • Disk I/O
   • Network throughput

3. Business Metrics:

   • GMV (Gross Merchandise Volume)
   • Order count
   • Payment success rate
   • Active users

Contingency Plans & Downgrade Strategies

Three Levels of Protection:

Level 1: Rate Limiting (AHAS)
├── Throttle non-critical requests
├── Priority queue for core transactions
└── Auto-trigger khi latency tăng

Level 2: Degradation
├── Tắt non-essential features
├── Giảm image quality
├── Disable recommendations
└── Static page fallback

Level 3: Emergency Mode
├── Cash-only payments
├── Disable coupons/discounts
├── Offline payment redirect
└── Manual override available

Downgrade Priority:

1. Core payment flow (không bao giờ downgrade)
2. User authentication
3. Inventory check
4. Logistics tracking
5. Recommendations (đầu tiên bị downgrade)

Post-Mortem Process

Timeline:

• T+1 day: Initial incident summary
• T+1 week: Detailed post-mortem
• T+1 month: Action items implementation review

Template:

1. Incident summary (what happened)
2. Timeline (minute-by-minute)
3. Impact assessment (users affected)
4. Root cause analysis (5 Whys)
5. Action items (who, what, when)
6. Lessons learned

3.4 Smart Operations (2025-2026)

AI-Driven Efficiency & Marathon Strategy

Trong giai đoạn 2025-2026, chiến lược vận hành đã chuyển từ việc tập trung chuẩn bị cho một “đêm thức trắng” (sprint) sang một chiến dịch kéo dài nhiều tuần (marathon) với sự hỗ trợ của AI là “động cơ vô hình”.

1. AI-Optimized Marketing:
   • Tối ưu hóa phân phối mã giảm giá tự động hóa dựa trên phân tích hành vi người dùng trong chu kỳ dài (mở rộng đánh giá trên chu kỳ 10 năm).
   • Đơn giản hóa cơ chế giảm giá (từ nhiều tầng logic phức tạp sang giảm giá trực tiếp) để giảm tải tính toán và decision fatigue.
2. Real-time Inventory AI:
   • Hỗ trợ merchant tự động điều chỉnh stock theo thời gian thực dựa trên xu hướng Agentic Commerce.
3. Global Connectivity:
   • Vận hành hạ tầng mở rộng quy mô đa quốc gia thông qua Alipay+ kết nối hàng triệu merchants với hàng tỷ consumers toàn cầu trong các sự kiện Mega Sale.

3.5 Cultural Aspects

“Worshiping Guan Gong” Tradition

History:

• Bắt nguồn từ khi Alipay mới thành lập
• 2013: Zheng Yangfei mang painting vào phòng chuẩn bị
• “Prince of Stress Testing” - Zheng Yangfei

Evolution:

2013: Painting of Guan Yu
2014: Guan Gong shadow puppet (từ Xi'an campus recruitment)
2015: Wooden Guan Gong statue (Cheng Li mua)
2016+: Bronze Guan Gong statue (Hu Xi mua)

Practice:

• Mỗi release quan trọng: Forward Guan Gong emojis trong Wangwang
• Cầu nguyện: “No bugs”
• Ý nghĩa: Respect và sự kính sợ đối với unpredictable

Temple Traditions

“Lingyin Temple Faction” vs “Faxi Temple faction”:

• Hai phe đi chùa cầu may trước Double 11
• Lingyin Temple (灵隐寺) - gần West Lake
• Faxi Temple (法喜寺) - nơi lãnh đạo đi

Post-Double 11 Ritual:

1. Cheng Li và Hu Xi dẫn team đi chùa Faxi
2. Đi bộ từ Alipay Building đến chùa
3. “Redeem vow” - trả lời hứa với thần
4. Nhặt rác trên đường về

Team Collaboration

Key Principles:

1. “You are never fighting alone” - Li Junkui
2. Trust your teammates: “First, don’t panic. Say ‘Got it. Let me take a look.’ Then convey to backend team.”
3. Monthly release cycles: 2013 LDC project - release hầu như mỗi tháng (gấp nhiều lần bình thường)

Stress Relief Methods:

Operations Checklist

Pre-Event (T-30 days)

• Full-link stress test completed
• All critical issues fixed
• Contingency plans reviewed
• Monitoring dashboards verified
• Team assignments confirmed
• Guangming Peak setup complete

Pre-Event (T-7 days)

• Final stress test passed
• Rate limiting tested
• Degradation paths verified
• Cache warmed up
• Database optimized
• Team on-call schedule confirmed

During Event (T-0)

• Command center active
• All teams in position
• Real-time monitoring
• Incident response ready
• Communication channels open

Post-Event (T+1 day)

• Initial summary
• Thank team
• Temple visit scheduled 😄

Next: Phase 4 - Công Nghệ Chi Tiết (Middle Platform, Risk Control, Payment Flow) ➔

🔗 Đọc thêm các chuyên đề liên quan:

• Kiến trúc Microservices Golang & DDD
• Triển khai Agentic AI Swarm trong Production với OpenClaw & LiteLLM
• Kiến trúc Microservices Golang gRPC: Protobuf, TLS & Middleware

Phân Tích Thực Chiến: Kiến Trúc Phân Lập Dữ Liệu Bóng FLST & Thang Hạ Cấp Tự Động 5 Cấp

Answer-first: Kiểm thử tải toàn trình (Full-Link Stress Testing - FLST) trên production đòi hỏi sự bảo đảm toán học tuyệt đối rằng dữ liệu giả lập không bao giờ làm ô nhiễm báo cáo tài chính kiểm toán, thông qua cơ chế định tuyến bảng bóng tự động, cách ly bộ đệm Redis và thang hạ cấp tự động 5 cấp độ bảo vệ lõi thanh toán.

1. Đường Ống Phân Lập Dữ Liệu Bóng Đa Tầng

Để kiểm thử tải chịu đựng 544.000 TPS ngay trên hạ tầng thực tế trước ngày hội mua sắm, Alipay xây dựng cơ chế đánh chặn và phân luồng dữ liệu giả lập xuyên suốt mọi tầng dịch vụ:

• Tầng Cơ Sở Dữ Liệu (OceanBase Shadow Tables): Mỗi bảng dữ liệu thực tế đều có bảng bóng song sinh (t_order đi đôi với t_order_shadow). Trình phân tích cú pháp SQL trong middleware tự động viết lại tên bảng khi phát hiện cờ ngữ cảnh X-Stress-Test: true. Kết thúc buổi diễn tập, toàn bộ dữ liệu bảng bóng được lệnh TRUNCATE dọn sạch trong tích tắc mà không ảnh hưởng tới bảng chính.
• Tầng Bộ Nhớ Đệm (Redis Namespace Isolation): Mọi khóa cache phát sinh từ đợt kiểm thử tải đều được tự động gán tiền tố __shadow__. Hệ thống cấp riêng hạn ngạch bộ nhớ và áp dụng chính sách TTL ngắn (10 phút) cho dữ liệu bóng, triệt tiêu nguy cơ dữ liệu test đẩy văng (evict) các cache nóng của người dùng thật ra khỏi RAM.
• Tầng Hàng Đợi Thông Điệp (RocketMQ Shadow Topics): Toàn bộ sự kiện thanh toán giả lập được xuất bản vào các topic bóng riêng biệt (TOPIC_PAYMENT_SHADOW). Các consumer group phụ trách gửi tin nhắn SMS, email xác nhận đơn hàng hoặc bắn webhook cho đối tác bán hàng đều chỉ lắng nghe topic thật, ngăn chặn 100% rủi ro gửi thông báo nhầm cho người tiêu dùng.
• Tầng Giả Lập Hệ Thống Ngân Hàng Ngoại Vi: Mạng lưới thanh toán liên ngân hàng không thể tiếp nhận hàng trăm nghìn giao dịch giả lập mỗi giây. Các proxy biên egress của Alipay đánh chặn toàn bộ lệnh gọi ra ngoài và phản hồi tức thì bằng mô hình độ trễ xác suất Gamma phân phối thực tế (p50: 35ms, p99: 450ms, tỷ lệ lỗi mô phỏng 0.05%), giúp đo đếm chính xác năng lực chịu tải của toàn bộ chuỗi microservices nội bộ.

2. Thang Hạ Cấp Dịch Vụ Tự Động 5 Cấp Độ (Degradation Ladder)

Khi lưu lượng truy cập thực tế vượt quá năng lực dự kiến hoặc các cổng ngân hàng bên ngoài bị tắc nghẽn, bộ ngắt mạch tự động (Circuit Breaker) kích hoạt thang hạ cấp theo từng nấc định trước mà không cần sự can thiệp thủ công của kỹ sư trực ca:

← Chương trước: Phase 2: Kiến Trúc LDC & OceanBase | Mục lục Series | Chương tiếp theo: Phase 4A: Middle Platform & CTU Risk Control →

❓ Câu Hỏi Thường Gặp (FAQ)

📚 Nguồn nghiên cứu (verification anchors)

Bản nghiên cứu: reports/research-alipay-executive-summary-100-rounds.{md,json} (ledger Ch1) + research-alipay-phases-consolidated-100-rounds.md (dossier hợp nhất Ch2–Ch9), mirror cả 2 repo. Ghi chú grounding: các con số đỉnh là Ant-reported (hệ thống đóng); TPC-C là con số duy nhất được audit độc lập.