Reliability
Định nghĩa
Reliability là khả năng hệ thống tiếp tục hoạt động đúng ở mức performance yêu cầu khi gặp hardware fault, software fault hoặc human error.
Mental model
Fault trong một thành phần
-> detect
-> contain / recover / degrade có kiểm soát
-> service vẫn đáp ứng guarantee
Nếu fault thoát khỏi hàng rào bảo vệ
-> system failure mà user quan sát đượcFault là một thành phần lệch khỏi đặc tả; failure là toàn hệ thống ngừng cung cấp service yêu cầu. Vì fault không thể bị loại bỏ hoàn toàn, thiết kế reliable tập trung ngăn fault trở thành failure.
Hardware Faults
Hardware fault thường ngẫu nhiên và tương đối độc lập: disk, RAM, nguồn điện hoặc network component bị lỗi. Ở quy mô lớn, sự kiện hiếm trên từng component trở thành sự kiện thường xuyên của cả fleet; nguồn minh họa cluster 10.000 disk có thể trung bình gặp một disk hỏng mỗi ngày.
Hai lớp bảo vệ:
- Component redundancy: RAID, nguồn dự phòng, hot-swappable component, backup power.
- Software fault tolerance: service tiếp tục chạy khi mất cả machine, đồng thời hỗ trợ rolling upgrade.
Software Errors
Software error thường có tính hệ thống và tương quan giữa node. Một bad input, runaway process, dependency hỏng hoặc cascading failure có thể tác động nhiều replica cùng lúc vì chúng chia sẻ code và assumption.
Assumption ẩn bị phá vỡ
-> cùng bug được kích hoạt trên nhiều node
-> redundancy không còn độc lập
-> fault lan thành failureBiện pháp gồm làm rõ assumption và interaction, test corner case, process isolation, crash/restart, production monitoring và runtime self-check cho invariant quan trọng.
Human Errors
Human error là một phần của system model. Interface quá lỏng tạo cơ hội sai, nhưng quá hạn chế khiến operator tìm workaround. Thiết kế cần cân bằng guardrail với khả năng hoàn thành công việc hợp lệ.
Các lớp bảo vệ:
- non-production sandbox;
- test nhiều cấp;
- gradual rollout và rollback nhanh;
- công cụ recompute dữ liệu;
- telemetry, alert và training;
- giới hạn blast radius của một thao tác.
Kiểm thử fault tolerance
Fault có thể được kích hoạt có chủ đích để kiểm tra recovery mechanism thường xuyên. Cách này hữu ích với fault có thể phục hồi; với hậu quả không thể đảo ngược như rò rỉ dữ liệu nhạy cảm, ưu tiên phòng ngừa.
Nguyên tắc thiết kế
- Nêu rõ loại fault nào được hệ thống chịu đựng.
- Cô lập fault để giảm blast radius.
- Phát hiện invariant bị vi phạm càng sớm càng tốt.
- Thiết kế recovery path và thường xuyên kiểm thử nó.
- Đánh giá reliability từ guarantee người dùng nhận được, không chỉ uptime của từng component.
- Nhận diện trường hợp cần phòng ngừa thay vì phục hồi, đặc biệt khi hậu quả không thể đảo ngược.
How Important Is Reliability?
Reliability quan trọng cả với hệ không được xem là safety-critical:
- Kết quả business sai gây mất năng suất và legal risk.
- Ecommerce outage gây mất doanh thu và uy tín.
- Mất dữ liệu cá nhân như ảnh gia đình có thể không thể bù đắp.
Reliability tốn chi phí xây dựng, test và vận hành. Có thể chấp nhận mức thấp hơn cho prototype hoặc use case nhạy cảm về chi phí, nhưng cần quyết định có ý thức dựa trên guarantee bị giảm, failure user nhìn thấy, khả năng phục hồi dữ liệu và hậu quả kinh doanh.
Câu hỏi review
- Fault và failure khác nhau ở boundary nào?
- Vì sao software fault có thể nguy hiểm hơn hardware fault trong hệ nhiều node?
- Cơ chế nào ngăn configuration error gây ảnh hưởng toàn bộ production?
- Recovery path đã được kiểm thử trong điều kiện giống production chưa?