ENG_DE_3

Để mọi người hiểu down, nên dùng…

• Một định nghĩa mơ hồ và không rõ ràng
• SLO/SLI cụ thể và ví dụ user journey
• Chỉ dựa vào cảm giác của đội ngũ vận hành
• Chỉ dựa vào số lượng log được ghi lại

Answer explanation

Để mọi người cùng hiểu về sự cố, cần sử dụng các định nghĩa định lượng cụ thể (SLO/SLI) và các ví dụ thực tế về hành trình của người dùng (user journey).

Tình huống: user báo “chậm” nhưng server metrics bình thường. Hành động đúng?

• Bỏ qua và không cần xử lý
• Đo theo user journey + latency/error rate
• Đổ lỗi cho kết nối mạng của người dùng
• Tắt máy chủ và khởi động lại

Answer explanation

Khi người dùng báo chậm, cần phải đo lường hiệu suất theo đúng hành trình của người dùng (user journey) để tìm ra vấn đề thực tế (user-centric observability).

Nhóm nào KHÔNG thuộc 4 nhóm nguyên nhân system down?

• Bug trong mã nguồn ứng dụng
• Hết bộ nhớ (memory) hoặc dung lượng ổ đĩa (disk)
• Sai sót trong quá trình cấu hình hệ thống
• Chiến dịch marketing không hiệu quả

Answer explanation

Marketing là hoạt động kinh doanh phi kỹ thuật, không phải là nguyên nhân kỹ thuật trực tiếp gây sập hệ thống theo phân loại 4 nhóm nguyên nhân chính của sách.

Định nghĩa down tốt nên dựa trên…

• Số lượng lỗi ghi trong log
• Mức sử dụng CPU của server
• Cam kết chất lượng dịch vụ (SLA/SLO) và trải nghiệm người dùng
• Cảm nhận chủ quan của đội ngũ vận hành

Answer explanation

Một định nghĩa về sập hệ thống tốt cần dựa trên các chỉ số cam kết chất lượng dịch vụ (SLA/SLO) và trải nghiệm thực tế của người dùng để có thể đo lường và đánh giá chính xác mức độ ảnh hưởng.

Theo sách, “system down” được hiểu đúng nhất theo góc nhìn nào?

• Trạng thái của server (CPU/memory)
• Người dùng và dịch vụ không đạt kỳ vọng
• Số lượng lỗi (exception) trong log
• Tình trạng của cơ sở dữ liệu (database)

Answer explanation

Theo sách, sự cố hệ thống (system down) phải được đánh giá từ góc nhìn của người dùng: liệu dịch vụ có thực hiện được mục tiêu sử dụng hay không, thay vì chỉ nhìn vào trạng thái kỹ thuật của máy chủ hay mã nguồn.

“Hiệu ứng dây chuyền” (Cascade effect) nghĩa là gì?

• Lỗi chỉ xảy ra ở tầng cơ sở dữ liệu
• Lỗi nhỏ lan rộng gây sập nhiều phần
• Lỗi chỉ xuất hiện trong quá trình triển khai
• Lỗi do một thành phần phần cứng duy nhất

Answer explanation

Hiệu ứng sập dây chuyền (cascade effect) là khi một lỗi nhỏ ban đầu không được kiểm soát tốt, lan rộng sang các thành phần khác do sự phụ thuộc phức tạp, dẫn đến sập toàn bộ hệ thống.

Sự cố dễ tái diễn nhất nếu…

• Có các hành động theo dõi sau sự cố
• Không làm postmortem/không sửa quy trình
• Hệ thống có công cụ giám sát tốt
• Sử dụng phương pháp canary release

Answer explanation

Sự cố sẽ rất dễ tái diễn nếu chúng ta không rút kinh nghiệm (postmortem) để tìm ra nguyên nhân gốc rễ và thực hiện các cải tiến thực chất (make improvements real) cho hệ thống và quy trình.

Loại test giúp phát hiện lỗi tích lũy theo thời gian…

• Unit test
• Soak/long-run
• Snapshot test
• Manual UI

Answer explanation

Các bài kiểm thử chạy dài (soak/long-run test) được thiết kế đặc biệt để phát hiện các lỗi tích lũy chậm theo thời gian như rò rỉ bộ nhớ (memory leak).

Test không thể bao phủ vì hệ thống…

• Quá đơn giản
• Phức tạp và state space lớn
• Không có mã nguồn
• Không có người dùng

Answer explanation

Kiểm thử không bao giờ có thể bao phủ 100% (limits of testing) vì các hệ thống hiện đại quá phức tạp và có không gian trạng thái (state space) khổng lồ, không thể liệt kê hết mọi trường hợp.

Bài học quan trọng: dù test kỹ vẫn phải…

• Bỏ qua việc giám sát hệ thống
• Chuẩn bị giám sát (monitoring) + phản hồi (response) + sổ tay quy trình (runbook)
• Không cần thực hiện họp rút kinh nghiệm (postmortem)
• Không cần kiểm thử các trường hợp ngoại lệ

Answer explanation

Vì không thể kiểm thử hết 100% các trường hợp, chúng ta phải luôn chuẩn bị sẵn sàng bằng các công cụ giám sát (monitoring), quy trình phản hồi và sổ tay vận hành (runbook) để ứng phó khi sự cố xảy ra.