Oct 16, 2026

Production Incident Investigation Playbook

Mục tiêu

Trong quá trình vận hành hệ thống, điều quan trọng nhất không phải là giải quyết sự cố nhanh nhất.

Điều quan trọng nhất là:

Khống chế phạm vi ảnh hưởng.
Thu thập đủ dữ liệu.
Xác định đúng nguyên nhân gốc.
Phòng tránh tái diễn.

Bài viết này tổng hợp quy trình xử lý production incident được sử dụng cho các hệ thống Java Enterprise.

Nguyên tắc số 1

Không đoán

Trong trạng thái áp lực cao rất dễ xuất hiện các nhận định kiểu:

Chắc database chậm.
Chắc network lỗi.
Chắc JVM đầy heap.
Chắc thread pool không đủ.

Mọi kết luận đều phải dựa trên số liệu.

Không được sửa hệ thống chỉ vì cảm giác.

Incident Levels

P1

Toàn bộ hệ thống ngừng hoạt động.

Ví dụ:

Người dùng không truy cập được.
Tất cả giao dịch thất bại.
Không thể đăng nhập.

P2

Hệ thống còn hoạt động nhưng ảnh hưởng lớn.

Ví dụ:

Chậm nghiêm trọng.
Nhiều giao dịch timeout.
Tỷ lệ lỗi tăng mạnh.

P3

Ảnh hưởng cục bộ.

Ví dụ:

Một module lỗi.
Một nghiệp vụ lỗi.

Quy Trình Xử Lý Chuẩn

Bước 1 - Xác nhận sự cố

Không xử lý dựa trên tin nhắn.

Ví dụ:

Người dùng báo chậm.

Cần xác nhận bằng dữ liệu:

Response Time
Error Rate
TPS
Active Service

Bước 2 - Đánh giá phạm vi ảnh hưởng

Trả lời các câu hỏi:

Ai bị ảnh hưởng?

Toàn bộ người dùng
hay
Một nhóm người dùng?

Nghiệp vụ nào bị ảnh hưởng?

Thanh toán?

Đăng nhập?

Tra cứu?

Từ khi nào?

Bước 3 - Thu thập dữ liệu

Không restart ngay.

Đây là sai lầm phổ biến nhất.

Khi restart:

Mọi bằng chứng biến mất.

Thu thập APM

Ví dụ Jennifer:

TPS
Response Time
Active Service
SQL Time
External Call Time

Thu thập JVM

Thread Dump

jstack PID > thread-1.txt

Sau 10 giây:

jstack PID > thread-2.txt

Sau 10 giây:

jstack PID > thread-3.txt

Heap

Nếu nghi ngờ memory:

jmap -dump

Thu thập OS

Linux:

top
vmstat
iostat
sar

Windows:

Task Manager
PerfMon
Resource Monitor

Bước 4 - Xác định nút thắt

CPU

CPU > 90%

Khả năng:

Loop
Mã xử lý nặng
GC

Memory

Heap tăng liên tục.

Khả năng:

Memory Leak
Cache không giải phóng

Thread

Active Thread tăng liên tục.

Khả năng:

SQL chậm
External Call chậm
Lock

Database

Session tăng cao.

Khả năng:

Query chậm
Lock
Missing Index

Network

Timeout tăng.

Khả năng:

API chậm
Route lỗi
DNS lỗi

Playbook Điều Tra Theo Triệu Chứng

Triệu chứng 1

Response Time tăng

Kiểm tra:

TPS

Response Time

SQL

External Call

Triệu chứng 2

Active Thread = Max

Kiểm tra:

Thread Dump

Profiles

SQL

External Call

Triệu chứng 3

CPU cao

Kiểm tra:

GC

Thread CPU

Loop bất thường

Triệu chứng 4

Memory tăng

Kiểm tra:

Heap Dump

Cache

Static Collection

Triệu chứng 5

TPS giảm

Kiểm tra:

Database

Network

Thread Pool

Quy Tắc 5 Why

Khi tìm nguyên nhân không được dừng ở triệu chứng.

Ví dụ:

Hệ thống chậm

Tại sao?

Response Time cao

Tại sao?

Thread Pool đầy

Tại sao?

External Call chậm

Tại sao?

API đối tác timeout

Tại sao?

Network routing lỗi

Nguyên nhân gốc nằm ở tầng cuối cùng.

Sai Lầm Phổ Biến

Restart ngay lập tức

Mất toàn bộ chứng cứ.

Tăng Thread Pool

Đôi khi chỉ làm vấn đề tệ hơn.

Nếu downstream đang nghẽn:

100 thread
↓
200 thread

chỉ làm hệ thống downstream chết nhanh hơn.

Chỉ nhìn CPU

CPU thấp không đồng nghĩa hệ thống khỏe.

Chỉ nhìn TPS

TPS thấp không đồng nghĩa hệ thống rảnh.

Checklist Incident

Khi nhận thông báo hệ thống chậm:

Mẫu RCA

Incident

Mô tả ngắn gọn sự cố.

Timeline

13:30

Người dùng phản ánh chậm.

13:40

Xác nhận Response Time tăng.

14:10

Xác định External API chậm.

14:40

Khắc phục hoàn tất.

Root Cause

Nguyên nhân gốc.

Corrective Action

Các hành động xử lý.

Preventive Action

Các hành động phòng ngừa.

Nguyên Tắc Cuối Cùng

Production Incident không phải là cuộc thi sửa lỗi nhanh nhất.

Production Incident là quá trình:

Thu thập dữ liệu
→ Phân tích
→ Xác định nguyên nhân
→ Khắc phục
→ Ngăn tái diễn

Nếu không tìm được Root Cause thì sự cố đó chưa thực sự được giải quyết.