[Tâm Sự Code] Bí kíp sinh tồn khi cháy Production - Kịch bản xử lý khủng hoảng từ số 0

Chào anh em, như đã hứa ở bài trước, hôm nay chúng ta sẽ tạm rời xa môi trường dev/local màu hồng để bước vào một chiến trường thực sự máu lửa: Production.

Hãy tưởng tượng một kịch bản vô cùng quen thuộc: Đêm thứ 6, anh em đang ngồi quán nhậu, miếng thịt nướng vừa đưa lên miệng, ly bia chuẩn bị cụng thì điện thoại réo liên hồi. Tin nhắn Slack nhảy loạn xạ, sếp gọi cháy máy: "Hoàng ơi, hệ thống sập rồi! User bấm thanh toán bị trừ tiền mà app báo lỗi!".

Cảm giác lúc đó thế nào? Mồ hôi lạnh toát ra, tim đập thình thịch, miếng thịt nướng bỗng trở nên vô vị.

Sự khác biệt giữa một Junior "tập sự" và một Senior "cáo già" không nằm ở việc ai code ít bug hơn (ai code mà chả có bug!), mà nằm ở cách họ xử lý khi hệ thống đứt gánh giữa đường. Dưới đây là "Bí kíp sinh tồn" – kịch bản chuẩn mực để anh em cứu server (và cứu cả chén cơm của mình) từ con số 0.

1. Phút thứ 1: Định thần & Quy tắc "Mặt nạ dưỡng khí"

Khi nghe tin báo lỗi, phản xạ của 90% anh em chiếu mới là: Cuống cuồng bật máy tính, lao ngay vào đọc Source Code để tìm xem dòng lệnh nào sai, hoặc lôi code ra gõ gõ sửa sửa hòng tìm ra "Hotfix" nhanh nhất.

DỪNG LẠI NGAY! ĐÓ LÀ MỘT TỘI ÁC!

Lúc hoảng loạn, chỉ số IQ của bạn giảm xuống bằng 0. Càng sửa sẽ càng nát. Quy tắc đầu tiên giống hệt khi đi máy bay: Hãy đeo mặt nạ dưỡng khí cho mình trước.

Hít một hơi thật sâu.
Nhắn một tin ngắn gọn vào group chat: "Mình đã nhận được thông tin, đang bật máy kiểm tra. Sẽ update cho mọi người trong 5 phút nữa."
Hành động nhỏ này giúp sếp và team CSKH (Customer Service) yên tâm rằng "đã có người cầm lái", họ sẽ ngừng gọi điện làm phiền bạn.

2. Phút thứ 2 - 5: Cầm máu (Stop the Bleeding)

Mục tiêu tối thượng lúc này KHÔNG PHẢI LÀ TÌM BUG, mà là KHÔI PHỤC DỊCH VỤ NHANH NHẤT CÓ THỂ. Hãy nghĩ bạn là bác sĩ cấp cứu: Bệnh nhân đang phun máu thì phải ga-rô cầm máu trước, chứ không phải lôi máy X-Quang ra soi xem vết cắt sâu bao nhiêu mm.

Hãy đặt 3 câu hỏi sinh tử:

A. "Mình vừa mới Deploy cái gì lên không?"

Nếu câu trả lời là "Có" (vừa push code cách đây 10 phút). Không cần suy nghĩ, không cần giải thích: ROLLBACK NGAY LẬP TỨC! Đưa hệ thống về phiên bản ổn định gần nhất. Code của bạn có thể đúng, nhưng có thể nó thiếu config, sai biến môi trường,... Rollback xong, hệ thống sống lại rồi thì bạn mang code về local mà từ từ điều tra.

B. "Hệ thống có đang quá tải tài nguyên không?"

Mở ngay Dashboard (Grafana, Datadog, CloudWatch...):

CPU / RAM của App Server có chạm nóc 100% không? -> Scale up (Thêm server, thêm pod).
Connection của PostgreSQL có bị full không? Redis có bị OOM (Out Of Memory) không? -> Tìm và kill ngay các query bị treo (Slow queries) hoặc restart lại service.

C. "Lỗi do bên thứ 3 (Third-party)?"

App lỗi do cổng thanh toán (ZaloPay, Momo) hoặc SMS Gateway bị sập?

Bật Circuit Breaker (Cầu dao tự động): Tạm thời tắt tính năng thanh toán đó đi, treo một cái banner "Hệ thống thanh toán đang bảo trì", để user vẫn dùng được các tính năng khác của app thay vì trắng xóa toàn bộ màn hình.

3. Phút thứ 5 - 30: Điều tra & Triển khai Hotfix

Sau khi đã "cầm máu" (rollback thành công, hoặc đã scale up server tạm thời để hứng traffic), lúc này bạn mới bắt đầu bật mode "Thám tử Conan".

Soi Log tập trung (ELK Stack, Kibana...): Lọc theo level: ERROR trong khung giờ xảy ra sự cố. Tìm xem cái Exception nào đang văng ra nhiều nhất.
Tái hiện lỗi (Reproduce): Tuyệt đối không test thẳng trên Database Production. Hãy export một phần data lỗi về môi trường Staging/Local để chạy thử nghiệm.
Viết Hotfix: Khi đã tìm ra chỗ sai (ví dụ: thiếu check null, hoặc sai công thức tính toán), hãy code cẩn thận, chạy lại Unit Test. Mọi Hotfix đều phải được một người khác trong team Review chéo (Cross-check) trước khi bấm nút Merge. Đừng vì vội mà để con bug thứ 2 đẻ ra từ con bug thứ nhất.

4. Nghệ thuật Truyền thông (Communication)

Trong suốt quá trình từ phút thứ 1 đến lúc giải quyết xong, đừng bao giờ "lặn mất tăm". Bạn đang điều tra, nhưng sếp không nhìn thấy màn hình của bạn.

Hãy biến mình thành một Kĩ sư chuyên nghiệp bằng cách update liên tục (mỗi 15-30 phút):

"Em đã tìm ra nguyên nhân do deadlock ở DB. Đang viết script xử lý. Dự kiến 20 phút nữa sẽ fix xong."
"Đã deploy bản vá, team Tester vào check lại giúp em trên môi trường Live nhé."

5. Hậu phẫu: Báo cáo Post-Mortem (Khám nghiệm tử thi)

Khủng hoảng trôi qua, anh em thở phào đi ngủ. Nhưng với một kĩ sư giỏi, công việc chưa kết thúc. Đầu tuần sau, hãy chủ động viết một file báo cáo Incident Post-Mortem. Đừng đợi sếp chửi mới làm. Báo cáo cần có:

Timeline sự việc: Mấy giờ sập, mấy giờ phát hiện, mấy giờ khắc phục xong.
Impact (Mức độ ảnh hưởng): Bao nhiêu user bị văng lỗi? Bao nhiêu giao dịch thất bại?
Root Cause (Nguyên nhân gốc rễ): Dùng phương pháp "5 Whys" (Hỏi tại sao 5 lần).

VD: Tại sao lỗi? (Vì update trạng thái bill xịt). Tại sao xịt? (Vì hàm lock xài sai). Tại sao xài sai? (Vì code review sót).
Action Items (Hành động ngăn chặn): Đây là phần ăn tiền nhất. "Tôi sẽ bổ sung thêm Alert nếu có trên 50 giao dịch fail trong 1 phút", "Tôi sẽ viết thêm 3 cái Unit Test bao phủ case này".

Nhớ lại bài trước: Post-mortem là để tìm lỗi của quy trình, KHÔNG phải để tế sống thằng code ra con bug đó nhé!

Tổng kết

Xử lý sự cố Production giống như việc cứu hỏa. Khác biệt nằm ở chỗ bạn có quy trình chuẩn (Playbook) trong đầu hay không.

Làm backend, "cháy server" là chuyện không thể tránh khỏi. Cứ sau mỗi lần server sập, nếu bạn biết cách Rollback, biết cách đọc Log, và biết cách viết Post-mortem, trình độ của bạn (và cả sự nể trọng của team dành cho bạn) sẽ tăng lên theo cấp số nhân.

Chuỗi bài chia sẻ kinh nghiệm xương máu của anh em mình đi từ Architecture đến Soft Skills cũng đã hòm hòm rồi. Mình đang định bài tới sẽ đá sang một chút về "Tối ưu hóa Database - Từ những câu query ngây ngô đến nghệ thuật đánh Index" hoặc đi sâu vào "Bóc tách kiến trúc Microservices".

Anh em hứng thú với chủ đề nào hơn? Cứ comment "đặt hàng" bên dưới nhé! Upvote mạnh tay để lấy động lực lên bài tiếp nào!