Root Cause Analysis(RCA)

Sự cố xảy ra, ai cũng muốn vá thật nhanh rồi đi ngủ. Ba tuần sau nó quay lại, có khi còn to hơn. Root Cause Analysis là phần việc chán nhất sau sự cố: truy ngược cho tới khi tìm ra cái nguyên nhân mà sửa xong thì lỗi không tái diễn theo cách cũ được nữa.

RCA là quy trình truy từ triệu chứng về nguyên nhân gốc, để bản sửa lỗi diệt được cả họ nhà lỗi chứ không riêng lần này.

Khi nào BA cần dùng

Không phải bug nào cũng đáng RCA. Ba trường hợp đáng bỏ nửa ngày:

• Sự cố production đụng tới tiền hoặc dữ liệu khách hàng.
• Cùng một loại lỗi tái diễn từ 3 lần trở lên, dù biểu hiện mỗi lần một khác.
• Vấn đề nghiệp vụ dai dẳng không ai giải thích được: tồn kho lệch đều đặn, số liệu hai hệ thống không khớp.

Điểm hay bị bỏ qua: nguyên nhân gốc thường không nằm trong code. Nó nằm ở quy trình, ở một quy tắc nghiệp vụ chưa ai viết ra, ở chỗ hai phòng ban hiểu khác nhau về cùng một khái niệm. Vì thế buổi RCA cần có BA chứ không riêng dev.

5 Whys

Hỏi "vì sao" liên tiếp, mỗi câu trả lời thành đối tượng của câu hỏi kế. Con số 5 chỉ là gợi ý, có thể dừng ở 3 hoặc phải đi tới 7. Dấu hiệu tới đáy: câu trả lời chạm vào một quyết định của con người hoặc một lỗ hổng quy trình, sửa nó thì cả nhánh phía trên tự sập.

Hai cái bẫy. Một, dừng quá sớm ở tầng kỹ thuật ("vì code thiếu validate") rồi đi vá; lần sau chỗ khác lại thiếu. Hai, đi lạc sang đổ lỗi cho người. Câu trả lời chỉ tay vào một cá nhân gần như luôn sai; hỏi tiếp "vì sao hệ thống của ta cho phép sự ẩu đó lọt tới production".

Fishbone (Ishikawa)

Khi nguyên nhân đến từ nhiều hướng cùng lúc, 5 Whys tuyến tính quá. Fishbone vẽ một xương sống trỏ vào vấn đề, các xương sườn là nhóm nguyên nhân. Bộ 6M của sản xuất (Man, Machine, Method, Material, Measurement, Environment) sang dự án phần mềm nên đổi thành sáu nhánh dễ dùng hơn:

• Con người — thiếu đào tạo, đổi nhân sự giữa chừng, không ai chịu trách nhiệm.
• Quy trình — thiếu bước kiểm tra, không có định nghĩa Done, duyệt bằng miệng.
• Hệ thống — lỗi code, thiếu ràng buộc ở tầng dữ liệu, hạ tầng.
• Dữ liệu — dữ liệu cũ bẩn, migration thiếu, hai nguồn lệch nhau.
• Yêu cầu — spec mơ hồ, thiếu luồng ngoại lệ, quy tắc chỉ nằm trong đầu một người.
• Môi trường — cấu hình lệch giữa staging và production, bên thứ ba đổi API.

Cách dùng: cả team ngồi 45 phút ném giả thuyết vào từng nhánh, chọn 2–3 nhánh khả nghi nhất rồi đào bằng 5 Whys. Fishbone mở rộng, 5 Whys đào sâu.

Ví dụ thực tế: truy tới cùng

217 giao dịch trong một tháng: khách bị trừ tiền, bên điện báo là chưa nhận. Đội vận hành ngồi hoàn tay từng ca, trung bình hai ngày một ca. Bối cảnh là dịch vụ thu hộ hoá đơn điện của một ví điện tử, 40 nghìn giao dịch mỗi ngày.

1. Vì sao khách bị trừ tiền mà đơn không hoàn tất? Hệ thống ghi nhận giao dịch thành công trước khi có phản hồi xác nhận từ đối tác.
2. Vì sao ghi nhận trước? Khi gọi API đối tác bị timeout, code bắt exception rồi coi như thành công để "khách khỏi thấy lỗi".
3. Vì sao xử lý timeout kiểu đó? Đặc tả chỉ mô tả hai trạng thái là thành công và thất bại, không có trạng thái "đang chờ đối tác xác nhận".
4. Vì sao đặc tả thiếu trạng thái đó? Lúc lấy yêu cầu, BA hỏi đối tác "API mất bao lâu" và nhận câu trả lời "dưới 2 giây", nên không ai nghĩ tới nhánh chờ.
5. Vì sao không ai kiểm chứng con số đó? Hợp đồng tích hợp không có cam kết SLA, và team không có bước rà soát giả định trước khi chốt thiết kế.

Nguyên nhân gốc: thiếu bước kiểm chứng giả định về hệ thống bên ngoài, dẫn tới mô hình trạng thái giao dịch không đầy đủ. Bản vá đúng gồm ba phần: thêm trạng thái PENDING_CONFIRMATION kèm job đối soát sau 15 phút; đưa "kiểm chứng giả định về bên thứ ba" thành mục bắt buộc trong checklist đặc tả tích hợp; đàm phán SLA vào phụ lục hợp đồng. Dừng ở tầng 2 và sửa cái try-catch thì lần sau tích hợp nhà mạng viễn thông sẽ lặp lại y nguyên.

Lỗi hay gặp

Hay hỏng ở mấy chỗ này. Ngồi RCA lúc cả team còn đang căng vì sự cố: chờ xử lý xong đã, buổi đó cần cái đầu lạnh. Gọi mỗi dev vào phòng, trong khi nguyên nhân nằm ở tầng yêu cầu thì không dev nào tự tìm ra. Kết luận dừng ở câu "đã nhắc anh em cẩn thận hơn", vốn là một lời hứa chứ chưa phải hành động. Và tệ nhất là biên bản có hành động khắc phục nhưng không ai theo: mỗi hành động phải kèm mã ticket, người chịu trách nhiệm và hạn hoàn thành, không thì nó chỉ là bài văn.