Cách đánh giá độ tin cậy hệ thống công nghệ

Vì vậy, đánh giá độ tin cậy cần kết hợp ít nhất ba góc nhìn: tính sẵn sàng, độ ổn định khi vận hành và khả năng phục hồi sau lỗi. Mỗi góc nhìn lại phải được chuyển thành chỉ số có thể đo được thay vì chỉ nhận xét hệ thống “ổn định”, “bền” hay “ít downtime”.

ISO/IEC 25010:2023 cung cấp mô hình chất lượng dùng cho sản phẩm ICT và phần mềm, cho thấy chất lượng hệ thống cần được xem xét theo các đặc tính và đặc tính con có thể được quy định, đo lường và đánh giá. Điều này cũng cho thấy reliability nên được tiếp cận như một thuộc tính có tiêu chí kiểm chứng, không phải một cảm nhận chủ quan.

Độ tin cậy hệ thống công nghệ được đánh giá bằng những gì?

Cách đánh giá hợp lý nhất là bắt đầu từ câu hỏi: hệ thống phải cung cấp chức năng nào, cho ai và với mức gián đoạn chấp nhận được bao nhiêu? Sau đó mới xác định các chỉ số đo.

Một hệ thống có thể được xem là đáng tin cậy khi dữ liệu thực tế cho thấy nó đáp ứng đồng thời các yêu cầu chính:

·         Có mặt và sử dụng được trong tỷ lệ thời gian hoặc tỷ lệ yêu cầu đủ cao

·         Thực hiện chức năng với tỷ lệ lỗi nằm trong giới hạn đã xác định

·         Không thường xuyên rơi vào trạng thái suy giảm, quá tải hoặc bất ổn

·         Khi xảy ra lỗi, có thể phát hiện, cô lập và phục hồi trong thời gian cho phép

·         Có thể khôi phục dữ liệu tới điểm phù hợp với mức mất mát mà tổ chức chấp nhận

·         Tiếp tục đáp ứng mục tiêu dịch vụ trong các điều kiện tải và sự cố đã được xác định

Điểm quan trọng là các ngưỡng này không có một giá trị chung cho mọi hệ thống. Một cổng thông tin nội bộ, hệ thống thanh toán, nền tảng thương mại điện tử và hệ thống điều khiển thời gian thực có hậu quả khi gián đoạn rất khác nhau. AWS cũng khuyến nghị yêu cầu availability phải gắn với mức độ quan trọng và nhu cầu kinh doanh của từng workload thay vì áp một mục tiêu cao nhất cho toàn bộ hệ thống.

Do đó, độ tin cậy không nên được đánh giá bằng một con số duy nhất. Nó là kết quả của nhiều phép đo cùng mô tả khả năng duy trì dịch vụ và kiểm soát tác động của lỗi theo thời gian.

Tính sẵn sàng cho biết hệ thống có sử dụng được khi cần hay không

Availability là một trong những chỉ số trực tiếp nhất của độ tin cậy. AWS định nghĩa availability là tỷ lệ thời gian workload ở trạng thái có thể sử dụng và thực hiện thành công chức năng đã thỏa thuận khi được yêu cầu. Công thức cơ bản là:

Availability = Thời gian hệ thống sử dụng được / Tổng thời gian quan sát

Với dịch vụ trực tuyến, phép đo theo request thường sát trải nghiệm người dùng hơn: tỷ lệ các yêu cầu hợp lệ được xử lý thành công trên tổng số yêu cầu hợp lệ. Google SRE cũng sử dụng availability như một Service Level Indicator, thường thể hiện bằng tỷ lệ request thành công.

Ý nghĩa của các mức availability trở nên rõ hơn khi đổi chúng thành downtime tối đa. Theo bảng tham chiếu của AWS:

Khoảng cách giữa 99,9% và 99,99% chỉ là 0,09 điểm phần trăm nhưng tương ứng với việc giảm thời gian gián đoạn cho phép từ gần chín giờ xuống dưới một giờ mỗi năm. Vì vậy, nhận xét “availability rất cao” không đủ giá trị nếu không nêu rõ ngưỡng đo và khoảng thời gian đánh giá.

Availability cũng cần được đo ở vị trí phản ánh trải nghiệm thực tế. Server vẫn hoạt động không đồng nghĩa người dùng đang sử dụng được dịch vụ nếu gateway, cơ sở dữ liệu, mạng hoặc một dependency bắt buộc đã hỏng. Google SRE khuyến nghị xác định SLI theo những gì người dùng thực sự cảm nhận thay vì chỉ dựa vào trạng thái của từng thành phần phía máy chủ.

Độ ổn định phải được nhìn qua tần suất lỗi và chất lượng vận hành

Availability cho biết bao nhiêu dịch vụ đã được cung cấp thành công, nhưng chưa mô tả đầy đủ cách hệ thống vận hành trong khoảng thời gian đó.

Hai hệ thống cùng đạt 99,9% availability có thể có chất lượng vận hành rất khác nhau. Một hệ thống có thể chỉ gặp một sự cố lớn trong năm; hệ thống còn lại có thể phát sinh hàng trăm lỗi ngắn, timeout và đợt suy giảm hiệu năng. Tỷ lệ sẵn sàng cuối cùng gần giống nhau nhưng trải nghiệm và rủi ro vận hành không giống nhau.

Vì vậy cần xem thêm các chỉ số như:

·         Số incident trong một khoảng thời gian

·         Tỷ lệ request lỗi

·         Tần suất timeout

·         Tần suất service restart hoặc failover

·         Khoảng thời gian trung bình giữa các lần lỗi

·         Mức biến động latency

·         Tỷ lệ request vượt ngưỡng latency

·         Khả năng duy trì throughput khi tải tăng

·         Mức saturation của CPU, bộ nhớ, connection pool, queue hoặc tài nguyên giới hạn

Đối với hệ thống phân tán, Google SRE khuyến nghị theo dõi bốn “golden signals”: latency, traffic, errors và saturation. Chúng không phải toàn bộ reliability nhưng giúp phát hiện tình trạng một dịch vụ vẫn “online” trong khi chất lượng thực tế đang suy giảm.

MTBF giúp nhìn vào tần suất xuất hiện lỗi

Với những hệ thống hoặc thành phần có thể sửa chữa, Mean Time Between Failures — MTBF — có thể được sử dụng để mô tả khoảng thời gian trung bình giữa các lần thất bại.

MTBF càng dài thường cho thấy lỗi xuất hiện càng ít thường xuyên trong điều kiện đo tương đương. Tuy nhiên, MTBF không nói hệ thống cần bao lâu để phục hồi. Vì thế nó phải được đọc cùng với chỉ số phục hồi như MTTR.

AWS đưa ra cách ước lượng availability từ hai đại lượng này:

Availability ước tính = MTBF / (MTBF MTTR)

Ví dụ của AWS: nếu MTBF là 150 ngày và MTTR là 1 giờ, availability ước tính đạt khoảng 99,97%.

Điều này cho thấy độ tin cậy có thể được cải thiện theo hai hướng khác nhau: giảm tần suất xảy ra lỗi hoặc giảm thời gian tồn tại của mỗi lỗi.

Khả năng phục hồi quyết định hậu quả khi hệ thống thực sự xảy ra sự cố

Không có kiến trúc thực tế nào bảo đảm mọi thành phần đều không bao giờ thất bại. Do đó, độ tin cậy còn phụ thuộc mạnh vào cách hệ thống phản ứng sau failure.

Một hệ thống có khả năng phục hồi tốt phải có thể phát hiện lỗi, hạn chế phạm vi ảnh hưởng, chuyển sang tài nguyên thay thế hoặc trạng thái an toàn và khôi phục dịch vụ trong giới hạn đã cam kết. AWS xem resiliency là khả năng workload phục hồi từ gián đoạn hạ tầng hoặc dịch vụ, thích nghi với nhu cầu tài nguyên và giảm tác động của những sự cố như lỗi cấu hình hoặc gián đoạn mạng tạm thời.

MTTR cho biết hệ thống phục hồi nhanh đến đâu

MTTR thường được sử dụng để thể hiện thời gian trung bình từ khi sự cố bắt đầu đến khi dịch vụ được phục hồi.

Nếu hai hệ thống có tần suất lỗi tương đương nhưng một hệ thống mất vài phút để khôi phục trong khi hệ thống kia cần vài giờ, mức reliability thực tế sẽ rất khác nhau.

MTTR thấp thường phụ thuộc vào nhiều yếu tố phối hợp:

·         Phát hiện sự cố nhanh

·         Telemetry đủ để xác định nguyên nhân

·         Phân vùng lỗi tốt

·         Failover hoạt động đúng

·         Có rollback an toàn

·         Có runbook rõ ràng

·         Các thao tác phục hồi được tự động hóa khi phù hợp

Tự động hóa không tự động đồng nghĩa với an toàn. AWS khuyến nghị recovery automation phải được tài liệu hóa, kiểm thử, quan sát được và có khả năng dừng khi quy trình phục hồi tạo thêm rủi ro.

RTO và RPO đánh giá khả năng phục hồi ở cấp độ mục tiêu

MTTR phản ánh dữ liệu thực tế trung bình của nhiều sự cố, còn RTO và RPO thể hiện giới hạn mà tổ chức đặt ra trước khi sự cố xảy ra.

Recovery Time Objective — RTO là khoảng thời gian gián đoạn tối đa có thể chấp nhận từ lúc dịch vụ bị ngắt đến lúc được khôi phục.

Recovery Point Objective — RPO là mức mất dữ liệu tối đa có thể chấp nhận, được thể hiện bằng khoảng thời gian kể từ điểm dữ liệu khôi phục gần nhất.

Ví dụ, một hệ thống có:

·         RTO = 30 phút

·         RPO = 5 phút

thì thiết kế phục hồi phải hướng tới việc đưa dịch vụ trở lại trong không quá 30 phút và giới hạn dữ liệu cần mất hoặc tái tạo ở khoảng tương ứng không quá 5 phút.

Một backup tồn tại chưa chứng minh rằng mục tiêu này được đáp ứng. Quy trình restore phải được kiểm thử. AWS cũng yêu cầu việc sao lưu dữ liệu gắn với RTO/RPO và khuyến nghị định kỳ thực hiện recovery để xác nhận tính toàn vẹn của dữ liệu và quy trình khôi phục.

Vì thế, khả năng phục hồi phải được chứng minh bằng recovery test, không chỉ bằng sơ đồ kiến trúc hoặc tuyên bố rằng hệ thống “có backup”.

SLO và error budget biến độ tin cậy thành mục tiêu có thể quản trị

Để reliability có giá trị vận hành, các chỉ số cần được liên kết với mục tiêu cụ thể.

Service Level Indicator — SLI — là chỉ số đo một khía cạnh dịch vụ, chẳng hạn tỷ lệ request thành công hoặc latency.

Service Level Objective — SLO — là mục tiêu đặt ra cho SLI trong một khoảng thời gian nhất định.

Nếu availability SLO là 99,9%, phần 0,1% còn lại chính là lượng thất bại được phép trong phạm vi mục tiêu. Trong mô hình SRE, phần này được gọi là error budget. Google mô tả error budget bằng 1 trừ SLO; chẳng hạn SLO 99,99% tương ứng error budget 0,01%.

Cách tiếp cận này giải quyết một vấn đề quan trọng: reliability không phải cuộc đua đạt 100% bằng mọi giá.

Một SLO cao hơn thường đòi hỏi kiến trúc dự phòng lớn hơn, quy trình thay đổi chặt hơn, thử nghiệm failure kỹ hơn và chi phí vận hành cao hơn. AWS lưu ý rằng những mức availability cao thường làm tăng chi phí và yêu cầu mức tự động hóa, kiểm thử cùng kiểm soát vận hành nghiêm ngặt hơn.

Do đó, hệ thống đáng tin cậy không nhất thiết là hệ thống có con số availability cao nhất. Nó là hệ thống đạt đúng mức reliability mà hoạt động thực tế yêu cầu một cách ổn định và có bằng chứng.

Không nên đánh giá reliability chỉ bằng uptime

Uptime là dữ liệu quan trọng nhưng có thể tạo kết luận sai nếu đứng một mình.

Một dịch vụ có thể vẫn chạy nhưng:

·         10% request trả lỗi

·         Latency tăng từ vài trăm mili giây lên hàng chục giây

·         Một chức năng quan trọng không sử dụng được

·         Chỉ một số khu vực hoặc nhóm người dùng truy cập được

·         Dữ liệu được trả về chậm hoặc không nhất quán

·         Hệ thống liên tục chuyển trạng thái degraded

Trong những tình huống này, phép đo dựa hoàn toàn vào trạng thái process, máy chủ hoặc endpoint “còn sống” sẽ đánh giá reliability cao hơn trải nghiệm thực.

Google SRE chỉ ra rằng đối với dịch vụ chỉ khả dụng một phần, việc đo tỷ lệ operation thất bại có thể hữu ích hơn chỉ tính tổng chiều dài outage.

Vì thế, điểm đo nên được đặt càng gần chức năng người dùng thực sự cần càng tốt.

Quy trình đánh giá độ tin cậy hệ thống công nghệ

Một phép đánh giá có ý nghĩa có thể thực hiện theo năm bước liên tiếp.

Xác định chức năng và mức độ quan trọng

Trước tiên phải xác định chức năng nào thực sự cần đáng tin cậy. Không nên gộp mọi chức năng của một hệ thống thành một mục tiêu duy nhất nếu mức độ quan trọng của chúng khác nhau.

Ví dụ, tiếp nhận giao dịch mới có thể yêu cầu availability cao hơn trang báo cáo quản trị.

Đặt SLI và mục tiêu định lượng

Chọn chỉ số trực tiếp phản ánh chức năng đó, chẳng hạn:

·         Tỷ lệ giao dịch thành công

·         Tỷ lệ request thành công

·         Latency ở percentile cần theo dõi

·         Error rate

·         Availability

·         RTO

·         RPO

Sau đó xác định SLO hoặc giới hạn chấp nhận được.

Thu thập dữ liệu đủ dài và đúng điểm đo

Một vài ngày vận hành tốt không đủ chứng minh độ tin cậy dài hạn.

Dữ liệu phải bao phủ tải bình thường, giờ cao điểm, triển khai phiên bản mới, lỗi dependency và các tình huống suy giảm đã biết. Quan trọng hơn, measurement window phải được ghi rõ để tránh so sánh các số liệu được tính trên những khoảng thời gian khác nhau.

Phân tích cả failure lẫn recovery

Khi incident xảy ra cần ghi nhận không chỉ downtime mà cả:

·         Nguyên nhân

·         Blast radius

·         Thời gian phát hiện

·         Thời gian bắt đầu xử lý

·         Thời gian phục hồi

·         Dữ liệu bị mất hoặc phải tái tạo

·         Failover có thành công hay không

·         Sự cố có tái diễn hay không

Điều này giúp phân biệt hệ thống “hiếm khi lỗi” với hệ thống “phục hồi tốt khi lỗi”.

Kiểm thử giả định về khả năng phục hồi

Backup, redundancy hoặc multi-region chỉ có giá trị khi cơ chế thực sự hoạt động.

AWS Well-Architected yêu cầu chiến lược disaster recovery phải được kiểm thử để xác nhận khả năng đáp ứng mục tiêu phục hồi. Các mô hình phục hồi khác nhau cũng tạo ra trade-off rõ rệt giữa chi phí, RTO và RPO.

Một hệ thống chưa từng kiểm thử restore, failover hoặc recovery ở điều kiện gần thực tế vẫn còn một khoảng bất định lớn về reliability.

Khi nào có thể kết luận một hệ thống thực sự đáng tin cậy?

Kết luận nên dựa vào khoảng cách giữa mục tiêu đã định nghĩa và kết quả đo thực tế, không dựa vào một tiêu chuẩn cảm tính chung.

Một hệ thống có cơ sở để được coi là đáng tin cậy khi:

·         SLI liên quan trực tiếp đến người dùng đạt SLO trong cửa sổ đánh giá

·         Availability đạt mục tiêu và downtime nằm trong error budget

·         Error rate, latency và saturation được duy trì trong giới hạn

·         Tần suất incident không có xu hướng bất thường hoặc tái diễn không kiểm soát

·         MTTR đáp ứng yêu cầu vận hành

·         RTO và RPO được chứng minh qua thử nghiệm phục hồi

·         Failover, backup và recovery hoạt động khi được kiểm thử

·         Dependency quan trọng và các điểm lỗi đơn đã được đưa vào phạm vi đánh giá

Ngược lại, một hệ thống có uptime cao nhưng thường xuyên degraded, mất nhiều giờ để phục hồi hoặc chưa từng chứng minh khả năng restore dữ liệu vẫn chưa có đủ bằng chứng để kết luận reliability cao.

Độ tin cậy vì vậy nên được xem như một đặc tính được đo trong vận hành và kiểm chứng dưới failure, chứ không phải đặc tính suy ra trực tiếp từ kiến trúc.

Đánh giá độ tin cậy hệ thống công nghệ cần kết hợp tính sẵn sàng, chất lượng vận hành và khả năng phục hồi. Availability cho biết dịch vụ có sử dụng được khi cần hay không; error rate, latency, incident frequency và MTBF phản ánh mức ổn định; còn MTTR, RTO, RPO cùng các bài kiểm thử failover và restore cho biết hệ thống xử lý failure tốt đến đâu. Chỉ khi các chỉ số này được gắn với SLI/SLO rõ ràng, đo trên dữ liệu thực tế và kiểm chứng bằng thử nghiệm phục hồi, kết luận về reliability mới có cơ sở kỹ thuật thay vì chỉ là nhận xét định tính.