Độ tin cậy hệ thống phản ánh khả năng hoạt động thế nào?

Độ tin cậy chỉ có ý nghĩa khi xác định chức năng, thời gian và điều kiện

Các bộ thuật ngữ IEC và ISO/IEC/IEEE về dependability, kỹ thuật hệ thống và phần mềm đều đặt khái niệm độ tin cậy quanh chức năng yêu cầu, khoảng thời gian và điều kiện đã nêu. Failure (hỏng hoặc mất chức năng) trong ngữ cảnh này là sự kiện hệ thống không còn đáp ứng chức năng theo tiêu chí đã định. Vì thế, phát biểu “hệ thống có độ tin cậy cao” vẫn thiếu ý nghĩa kỹ thuật nếu ba điều kiện trên chưa rõ.

Giả sử một bộ điều khiển công nghiệp phải duy trì chức năng điều khiển trong 1.000 giờ ở dải nhiệt độ và tải xác định. Câu hỏi cần trả lời không phải “thiết bị có tốt không?” mà là “xác suất nó hoàn thành 1.000 giờ đó mà không mất chức năng yêu cầu là bao nhiêu?”. Nếu tăng tải, đổi môi trường hoặc kéo dài nhiệm vụ, giá trị độ tin cậy có thể thay đổi dù thiết kế vật lý vẫn giữ nguyên.

Tiêu chí hỏng cũng phải được xác định trước. Với hệ thống lưu trữ, hỏng có thể là không đọc được dữ liệu yêu cầu; với hệ thống điều khiển, hỏng có thể là mất khả năng điều khiển. Khi tiêu chí này thay đổi, kết quả đánh giá cũng thay đổi. Do đó, độ tin cậy là một thuộc tính gắn với nhiệm vụ cụ thể chứ không phải nhãn chất lượng tuyệt đối.

Cấu trúc hệ thống quyết định cách xác suất hỏng tích lũy

Độ tin cậy cấp hệ thống không thể suy ra từ một linh kiện riêng lẻ. Nếu một chức năng chỉ thành công khi tất cả thành phần trên đường thực hiện đều hoạt động, các điểm có thể hỏng sẽ tích lũy. Trong mô hình đơn giản với các lỗi độc lập, độ tin cậy của chuỗi bằng tích độ tin cậy của từng thành phần.

Nếu 10 thành phần đều bắt buộc phải hoạt động và mỗi thành phần có độ tin cậy 0,99 cho cùng một khoảng nhiệm vụ, độ tin cậy của cả chuỗi là 0,9910, xấp xỉ 0,904. Nói cách khác, mười phần tử “99%” chỉ cho khoảng 90,4% xác suất toàn chuỗi hoàn thành nhiệm vụ trong mô hình này.

Dự phòng có thể cải thiện kết quả theo cơ chế ngược lại. Nếu hai phần tử độc lập đều có độ tin cậy 0,99 và chỉ cần một phần tử hoạt động để duy trì chức năng, mô hình song song lý tưởng cho 1−(1−0,99)2=0,9999. Mức tăng này chỉ có giá trị khi giả định độc lập đủ hợp lý và cơ chế chuyển sang phần tử dự phòng thực sự hoạt động.

Trong hệ thống thực, các bản sao có thể dùng chung nguồn điện, mạng, cấu hình, dữ liệu đầu vào hoặc cùng chứa một lỗi phần mềm. Một nguyên nhân chung khi đó có thể làm tất cả bản sao thất bại cùng lúc. Bởi vậy, lỗi nguyên nhân chung (common-cause failure), điểm lỗi đơn (single point of failure), khả năng cô lập lỗi và đường lan truyền lỗi có thể chi phối độ tin cậy mạnh hơn số lượng phần tử dự phòng.

R(t), tỷ lệ hỏng và MTBF cho biết những điều khác nhau

Hàm R(t) biểu diễn trực tiếp xác suất hệ thống còn hoàn thành chức năng mà không hỏng đến thời điểm t: R(t)=P(T>t), với T là thời gian đến lần hỏng. Đại lượng này trả lời câu hỏi về xác suất hoàn thành một nhiệm vụ có độ dài xác định.

Xác suất R(t) đo khả năng không hỏng trong một khoảng thời gian

Nếu mô hình giả định tỷ lệ hỏng λ không đổi theo thời gian, R(t)=e−λt. Với λ=0,001 lần hỏng/giờ, sau 100 giờ ta có R(100)=e−0,1, xấp xỉ 90,5%. Đây là xác suất một nhiệm vụ 100 giờ kết thúc mà không có lần hỏng; nó không có nghĩa hệ thống “ngừng 9,5% thời gian”.

Mô hình tỷ lệ hỏng không đổi hữu ích để minh họa nhưng không phải điều kiện phổ quát. Tỷ lệ hỏng có thể thay đổi theo tuổi thiết bị, tải, nhiệt độ, hao mòn hoặc giai đoạn vận hành. Khi hành vi hỏng thay đổi theo thời gian, cần mô hình xác suất hoặc dữ liệu thực nghiệm phù hợp hơn để ước lượng R(t).

MTTF và MTBF mô tả thời gian kỳ vọng, không phải lời bảo đảm

MTTF thường dùng cho phần tử không sửa chữa để mô tả thời gian trung bình đến hỏng; MTBF thường dùng cho hệ thống sửa chữa được để mô tả thời gian trung bình giữa các lần hỏng. Hai chỉ số này cho biết một thang thời gian trung bình, nhưng không tự động cho biết xác suất không hỏng trong một nhiệm vụ cụ thể.

MTBF 1.000 giờ, chẳng hạn, không bảo đảm hệ thống sẽ chạy đủ 1.000 giờ trước khi hỏng. Chỉ khi giả định phân bố mũ với tỷ lệ hỏng không đổi, MTBF 1.000 giờ mới tương ứng λ=0,001 mỗi giờ; khi đó R(1.000)=e−1, khoảng 36,8%. Ví dụ này cho thấy thời gian trung bình giữa các lần hỏng và xác suất hoàn thành nhiệm vụ không hỏng là hai đại lượng khác nhau.

Độ tin cậy không đồng nghĩa với tính sẵn sàng hay khả năng chịu lỗi

Độ tin cậy và tính sẵn sàng (availability) liên quan nhưng trả lời hai câu hỏi khác nhau. Độ tin cậy hỏi hệ thống có đi hết một khoảng nhiệm vụ mà không hỏng hay không. Availability hỏi trong tổng thời gian quan sát, hệ thống ở trạng thái sử dụng được bao nhiêu phần thời gian. Vì vậy, một hệ thống hỏng tương đối thường xuyên nhưng được sửa rất nhanh vẫn có thể đạt tính sẵn sàng cao.

Trong mô hình sửa chữa đơn giản ở trạng thái ổn định, tính sẵn sàng thường được xấp xỉ bằng A≈MTBF MTTRMTBF​. Với MTBF 1.000 giờ và MTTR 1 giờ, A xấp xỉ 99,90%. Trong khi đó, với cùng MTBF và giả định phân bố mũ ở phần trước, xác suất đi hết 1.000 giờ mà không hỏng chỉ khoảng 36,8%. Hai con số cùng đúng vì chúng đo hai hiện tượng khác nhau: một bên là tỷ lệ thời gian hệ thống dùng được, bên kia là xác suất không xuất hiện lần hỏng trong cả nhiệm vụ.

Khả năng bảo trì (maintainability) liên quan đến việc khôi phục hoặc sửa chữa và thường được phản ánh qua các đại lượng như MTTR, nên nó tác động mạnh đến availability. Khả năng chịu lỗi (fault tolerance) lại là cơ chế kiến trúc cho phép hệ thống tiếp tục cung cấp chức năng khi một số lỗi (fault) đã xuất hiện. Fault tolerance có thể cải thiện độ tin cậy của nhiệm vụ hoặc tính sẵn sàng, nhưng bản thân nó không phải là một giá trị độ tin cậy.

Vì vậy, uptime hoặc thời gian khôi phục không đủ để chứng minh hệ thống có độ tin cậy cao. Nếu nhiệm vụ không cho phép hỏng trong suốt một khoảng liên tục, cần đánh giá R(t) hoặc bằng chứng tương đương cho chính khoảng nhiệm vụ đó. Nếu mục tiêu là duy trì dịch vụ sẵn dùng dài hạn dù có thể phát sinh sự cố, tính sẵn sàng và khả năng bảo trì trở thành các đại lượng trực tiếp hơn.

Một hệ thống đáng tin cậy cần được chứng minh bằng yêu cầu và dữ liệu

Độ tin cậy trở thành tiêu chí kỹ thuật khi yêu cầu được viết theo cách đo được. Thay vì đặt mục tiêu “hệ thống phải rất ổn định”, có thể quy định R(1.000 giờ)≥0,99 cho một chức năng cụ thể, dưới tải và điều kiện môi trường đã nêu. Giá trị 0,99 ở đây chỉ là ví dụ về cách viết yêu cầu; ngưỡng thực tế phải xuất phát từ nhiệm vụ, hậu quả của hỏng và bối cảnh ứng dụng. Không có một tỷ lệ phần trăm phù hợp cho mọi công nghệ.

Thiết kế hướng đến độ tin cậy cao thường loại bỏ điểm lỗi đơn, giới hạn phạm vi lỗi, dùng dự phòng khi cần và kiểm soát nguyên nhân hỏng chung. Nhưng sơ đồ kiến trúc mới chỉ cho thấy cơ chế dự kiến. Bằng chứng cần đến từ kiểm thử phù hợp, dữ liệu vận hành, phân tích chế độ hỏng (failure mode) và việc ghi nhận các lần hỏng theo đúng tiêu chí đã định. Một cơ chế dự phòng chưa được thử trong tình huống lỗi thực hoặc mô phỏng lỗi chưa thể chứng minh mức cải thiện mà mô hình lý tưởng dự đoán.

Dữ liệu cũng phải đại diện cho thời gian và điều kiện cần chứng minh. Không quan sát thấy lần hỏng trong một số ít lần thử không đồng nghĩa xác suất hỏng bằng 0; điều đó chỉ cho biết lần hỏng chưa xuất hiện trong lượng dữ liệu đã quan sát. Khi số mẫu, tổng thời gian thử hoặc mức tải còn hạn chế, độ bất định của ước lượng vẫn lớn.

Một đánh giá độ tin cậy có thể được kiểm tra bằng sáu câu hỏi liên tiếp: chức năng nào phải được duy trì, hỏng được định nghĩa ra sao, nhiệm vụ dài bao lâu, điều kiện nào áp dụng, mục tiêu xác suất là gì và dữ liệu nào hỗ trợ mục tiêu đó. Khi các yếu tố này rõ ràng, “độ tin cậy” trở thành thuộc tính có thể thiết kế, đo và kiểm chứng thay vì một nhận xét định tính.

Độ tin cậy hệ thống phản ánh khả năng hoàn thành chức năng yêu cầu mà không xảy ra hỏng trong một khoảng thời gian và điều kiện đã xác định. Bản chất của nó là một phát biểu xác suất gắn với nhiệm vụ, nên phải được đọc cùng tiêu chí hỏng, cấu trúc hệ thống và giả định của mô hình đo.

Một hệ thống chỉ thực sự “đáng tin cậy” theo nghĩa kỹ thuật khi yêu cầu độ tin cậy đo được và bằng chứng phù hợp với chính nhiệm vụ cần bảo đảm. R(t), tỷ lệ hỏng, MTTF/MTBF, tính sẵn sàng và MTTR đều hữu ích, nhưng chúng trả lời những câu hỏi khác nhau; dùng đúng đại lượng quan trọng hơn việc chọn một con số nghe có vẻ cao.