Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Hạ tầng & Đám mây
#SLO#SLI#SLA#오류 예산#서비스 신뢰성#관측성#DevOps
Cập nhật lần cuối · 2026-08-18

Quản lý độ tin cậy dịch vụ dựa trên SLO, SLI và ngân sách lỗi (Error Budget)

1. Tổng quan

A. Định nghĩa

SLI (Service Level Indicator) là chỉ số định lượng được đo để quan sát độ tin cậy của dịch vụ, còn SLO (Service Level Objective) là mức mục tiêu mà chỉ số đó phải đáp ứng trong khoảng thời gian mục tiêu.

SLA (Service Level Agreement) là hợp đồng ghi rõ mức dịch vụ đã thỏa thuận giữa nhà cung cấp và người sử dụng cùng các điều kiện trách nhiệm/bồi thường khi không đạt, còn ngân sách lỗi (Error Budget) là tiêu chí ra quyết định vận hành, trong đó SLO không được xem là 100% mà được quy đổi thành phần dư địa cho phép đối với thất bại và độ trễ.

SLO, SLI và ngân sách lỗi không đơn thuần là một tập hợp chỉ số trên dashboard giám sát. Bản chất của hệ thống này là biến sự căng thẳng giữa tốc độ phát triển và sự ổn định dịch vụ thành một chính sách có thể đo lường. Nếu tuyên bố dịch vụ phải luôn hoạt động hoàn hảo, mọi sự cố thực tế và độ trễ mạng đều bị coi là thất bại. Ngược lại, nếu vận hành theo kiểu chấp nhận sự cố thì tác động đến khách hàng và trách nhiệm khôi phục trở nên mơ hồ. SLO biểu diễn chất lượng có thể kỳ vọng bằng con số, còn ngân sách lỗi chỉ ra phạm vi thay đổi có thể chấp nhận trong mục tiêu chất lượng đó.

Tính sẵn sàng cao không đồng nghĩa với dịch vụ tốt. Độ tin cậy mà người dùng cảm nhận thay đổi tùy theo kết quả họ yêu cầu có chính xác không, phản hồi có đủ nhanh không, dữ liệu có mới nhất không, và tác vụ có hoàn thành trong thời gian quy định không. Vì vậy phải chọn SLI phù hợp với mục đích dịch vụ và hành trình người dùng, đồng thời xác định rõ đối tượng đo và đối tượng loại trừ. Ví dụ, với dịch vụ đăng nhập thì tỷ lệ thành công và độ trễ là quan trọng, nhưng với dịch vụ phân tích theo lô thì tỷ lệ hoàn thành tác vụ trong thời gian nhất định và chất lượng dữ liệu có thể quan trọng hơn.

B. Bối cảnh ra đời và sự cần thiết

Thứ nhất, nhận định "ổn định" của đội vận hành thường xung đột với nhận định "có thể triển khai" của đội phát triển. Nếu chặn triển khai chỉ dựa trên cảm giác không có sự cố thì ngay cả cải tiến nhỏ cũng bị chậm lại, ngược lại nếu chỉ tối ưu số lần triển khai thì tác động đến khách hàng sẽ tích lũy. Ngân sách lỗi tính lượng rủi ro có thể dùng cho thay đổi dựa trên tỷ lệ đạt SLO gần đây, nhờ đó chuyển tiêu chí tranh luận từ kinh nghiệm hay chức vụ sang dữ liệu.

Thứ hai, giám sát tập trung vào giá trị trung bình có thể che lấp những thất bại nghiêm trọng của một bộ phận người dùng. Dù thời gian phản hồi trung bình tốt, timeout vẫn có thể tập trung ở một khu vực, một tenant hay một API cụ thể. Nếu thiết kế SLO dựa trên thành công/thất bại theo từng sự kiện và độ trễ theo phân vị thay vì trung bình toàn bộ, có thể biểu diễn sát hơn những thất bại người dùng thực sự gặp phải.

Thứ ba, dịch vụ càng phân tán thì ranh giới nguyên nhân và trách nhiệm càng mờ nhạt. Khi frontend, API gateway, xác thực, thanh toán và cơ sở dữ liệu được gọi nối tiếp, độ trễ của một thành phần biểu hiện thành thất bại của toàn bộ hành trình người dùng. Phải quản lý SLO của từng dịch vụ một cách độc lập nhưng đồng thời liên kết với mục tiêu của hành trình người dùng cấp trên, mới giảm được vấn đề tối ưu cục bộ làm tổn hại độ tin cậy tổng thể.

Thứ tư, ngân sách lỗi không phải con số biện minh cho sự cố mà là ngân sách để quản lý rủi ro. Không được tự động phê duyệt thay đổi liều lĩnh chỉ vì ngân sách vẫn còn. Phải sử dụng ngân sách khi cân nhắc đồng thời mức rủi ro của thay đổi, khả năng khôi phục, khả năng hỏng dữ liệu, ảnh hưởng về quy định và mức độ quan trọng của khách hàng.

2. Khái niệm và mối quan hệ giữa SLI, SLO, SLA

A. Nguyên lý cấu thành SLI

Với SLI, điều quan trọng là trước hết định nghĩa "sự kiện người dùng nào được xem là thành công" hơn là bản thân giá trị đo. SLI tính sẵn sàng lấy số yêu cầu làm mẫu số và số yêu cầu thành công làm tử số thì dễ hiểu, nhưng cần có chính sách về việc có coi cache hit và truy vấn dữ liệu gốc là thành công như nhau hay không. Ngoài ra, nếu chỉ tính tỷ lệ thành công bằng health check thì có thể bỏ sót các thất bại về xác thực, phân quyền và xử lý dữ liệu của yêu cầu người dùng thực.

Dịch vụ dựa trên thời gian có thể dùng tỷ lệ thời gian cung cấp dịch vụ bình thường trên toàn bộ khoảng quan sát. Dịch vụ dựa trên yêu cầu có thể dùng tỷ lệ yêu cầu thành công trên toàn bộ yêu cầu hợp lệ. SLI độ trễ nếu được định nghĩa là "tỷ lệ yêu cầu nằm trong ngưỡng mục tiêu" thay vì trung bình của mọi yêu cầu thì sẽ liên kết trực tiếp hơn với trải nghiệm người dùng. Khi đó phải ghi lại đồng thời ngưỡng, điểm đo, timeout và quy tắc đếm trùng yêu cầu thử lại.

Độ mới hoặc độ chính xác của dữ liệu cũng có thể trở thành SLI tùy theo mục đích dịch vụ. Ví dụ, trong dịch vụ tra cứu tồn kho, đo tỷ lệ phản hồi có thời điểm cập nhật gần nhất nằm trong khoảng thời gian nhất định giúp giám sát chất lượng mà chỉ riêng việc máy chủ đã phản hồi không thể hiện ra. Trong dịch vụ gợi ý, có thể đặt chỉ số chất lượng không chỉ là tỷ lệ trả về kết quả mà còn là tỷ lệ vượt qua bộ lọc từ cấm hoặc tỷ lệ thiếu thuộc tính bắt buộc. Tuy nhiên, nếu đánh giá chất lượng mang tính chủ quan thì phải định nghĩa riêng phương pháp đo và mẫu kiểm chứng.

B. Cách thiết lập SLO

SLO không phải là việc chỉ định một con số như "tính sẵn sàng 99.9%". Phải định nghĩa thành một bộ gồm dịch vụ đối tượng, tập người dùng, kỳ đo, điều kiện thành công, nguồn dữ liệu, điều kiện ngoại lệ và hành động khi không đạt mục tiêu thì mới thành mục tiêu có thể vận hành. Kỳ đo được chọn giữa cửa sổ trượt (rolling) và kỳ theo lịch tùy mục đích, và khi kỳ thay đổi thì cách diễn giải xu hướng và tốc độ tiêu hao ngân sách lỗi cũng thay đổi.

Nếu SLO tính sẵn sàng là 99.9% thì tỷ lệ thất bại cho phép là 0.1%. Nếu mỗi ngày có 1,000,000 yêu cầu hợp lệ thì theo phép tính đơn giản, số yêu cầu thất bại cho phép là 1,000. Tuy nhiên, không phải mọi thất bại đều có cùng giá trị và thiệt hại, nên nếu gộp thất bại phê duyệt thanh toán với thất bại của widget gợi ý không cốt lõi vào một SLO thì quyết định có thể bị sai lệch. Đó là lý do phải tách hành trình người dùng quan trọng và chức năng quản trị nội bộ khi thiết kế SLO.

Mục tiêu không phải càng cao càng tốt mà phải ở mức cân bằng giữa chi phí và chất lượng kỳ vọng. Nâng mục tiêu lên 99.99% khiến tỷ lệ thất bại cho phép giảm còn một phần mười so với 99.9%, và chi phí dự phòng, dung lượng, kiểm thử, trực on-call có thể thay đổi rất lớn. Đôi khi đầu tư loại bỏ nguyên nhân khiến thất bại tập trung tạo ra giá trị lớn hơn việc nâng mục tiêu một chút mà khách hàng thực tế không phân biệt được. Vì vậy SLO ban đầu được xác định dựa trên cả mức hiện tại đo được và kỳ vọng của khách hàng, rồi điều chỉnh dần qua dữ liệu vận hành.

C. Khác biệt với SLA

SLA là hợp đồng hoặc cam kết chính thức với khách hàng bên ngoài nên có thể kéo theo trách nhiệm pháp lý và thương mại. Ngược lại, SLO có thể dùng làm mục tiêu vận hành nội bộ, và có thể nghiêm ngặt hơn hoặc chi tiết hơn theo từng dịch vụ so với SLA. Nếu đã cam kết tính sẵn sàng 99.9% trong SLA, có thể đặt SLO nội bộ là 99.95% để có dư địa phát hiện và cải thiện trước khi vi phạm hợp đồng. Nếu đặt SLO bằng SLA thì cảnh báo nội bộ và tiêu chí bồi thường khách hàng dính sát vào ngưỡng giới hạn, khiến việc ứng phó sớm trở nên khó khăn.

Hạng mục SLI SLO SLA
Bản chất Chỉ số đo lường Mức mục tiêu Thỏa thuận·hợp đồng bên ngoài
Câu hỏi Đo cái gì và đo như thế nào Sẽ giữ ở mức nào Nếu không giữ được thì chịu trách nhiệm gì
Người dùng chính Đội phát triển·vận hành·phân tích Chủ sở hữu dịch vụ·đội vận hành Khách hàng·kinh doanh·pháp chế·vận hành
Ví dụ Tỷ lệ phản hồi trong 300ms Từ 99.9% trở lên theo tháng Cung cấp service credit khi không đạt
Cách thay đổi Rà soát thay đổi đo đạc·định nghĩa Điều chỉnh qua chính sách·rà soát Cần thủ tục sửa đổi hợp đồng

Nếu nhầm lẫn ba thuật ngữ này sẽ dẫn đến tình trạng dashboard có nhiều chỉ số nhưng không có chính sách để quyết định. Sự phân biệt hữu ích là: SLI là ngôn ngữ của quan sát, SLO là tiêu chuẩn chất lượng, và SLA là ngôn ngữ trách nhiệm giữa các bên liên quan. Khi tài liệu hóa mối quan hệ này, Kỹ sư chuyên nghiệp (Professional Engineer) không chỉ liệt kê con số mà phải liên kết với mục tiêu nghiệp vụ và hành động vận hành.

3. Tính toán và vận hành ngân sách lỗi

A. Công thức tính

Ngân sách lỗi được định nghĩa là lượng thất bại được cho phép ở mức mục tiêu. Nếu SLO tính sẵn sàng là 99.9% thì tỷ lệ ngân sách lỗi được tính như sau.

[ Tỷ\ lệ\ ngân\ sách\ lỗi = 1 - SLO ]

Trong đo lường dựa trên yêu cầu có thể biểu diễn như sau.

[ Số\ thất\ bại\ cho\ phép = Tổng\ số\ yêu\ cầu\ hợp\ lệ \times (1 - Tỷ\ lệ\ thành\ công\ mục\ tiêu) ]

Trong đo lường dựa trên thời gian, nhân kỳ quan sát với tỷ lệ ngân sách lỗi để tính thời gian gián đoạn cho phép. Nếu coi 30 ngày là 43,200 phút và áp dụng SLO 99.9% thì về lý thuyết thời gian gián đoạn cho phép là 43.2 phút. Con số này không có nghĩa là được phép để sự cố kéo dài đến 43.2 phút, mà là tiêu chí quản lý tổng lượng tác động dịch vụ bao gồm cả bảo trì có kế hoạch và sự cố ngoài kế hoạch. Tùy phương thức đo, các chính sách như loại trừ bảo trì, loại trừ kiểm thử đã lên lịch, tách theo khu vực sẽ khác nhau, nên phải xác định phạm vi trước khi tính.

Tốc độ tiêu hao ngân sách lỗi (burn rate) cho phép ứng phó nhanh hơn so với chỉ nhìn ngân sách còn lại. Nếu 10% ngân sách bị tiêu hao trong một tháng thì có thể trông bình thường, nhưng nếu 10% bị tiêu hao trong một giờ thì có thể đang có sự cố lớn. Vì vậy cần quan sát đồng thời tốc độ tiêu hao tích lũy và tốc độ tiêu hao ngắn hạn, và khi tiêu hao ngắn hạn vượt ngưỡng thì có thể kích hoạt cảnh báo page hoặc đóng băng thay đổi.

B. Luồng tiêu hao ngân sách

flowchart TD
    A[Yêu cầu người dùng·sự kiện tác vụ] --> B[Thu thập: log·trace·metric]
    B --> C[Tính SLI: thành công/tổng hoặc tỷ lệ trong ngưỡng]
    C --> D{Có đạt SLO không}
    D -->|Đạt| E[Cập nhật ngân sách lỗi còn lại]
    D -->|Không đạt| F[Tính lượng·tốc độ tiêu hao ngân sách]
    F --> G{Ngưỡng chính sách}
    G -->|Thấp| H[Phân tích nguyên nhân·tiếp tục thay đổi thường]
    G -->|Cao| I[Hạn chế thay đổi·ưu tiên ổn định hóa]
    G -->|Tiêu hao nhanh| J[Ứng phó sự cố·rollback·truyền thông khách hàng]
    E --> K[Rà soát SLO hàng tuần/tháng]
    H --> K
    I --> K
    J --> K
    K --> L[Cải tiến SLO·đo đạc·chính sách đầu tư]

Trước tiên thu thập sự kiện người dùng và tính SLI từ nguồn đáng tin cậy. Sau đó so sánh với SLO để khấu trừ ngân sách lỗi, rồi áp dụng chính sách vận hành theo lượng ngân sách còn lại và tốc độ tiêu hao. Trong luồng này, nếu dashboard cập nhật chậm hoặc thiếu mẫu số thì ngân sách có thể trông như vẫn còn, nên chất lượng đo đạc cũng là đối tượng quản lý.

Với ngưỡng ngân sách, các hành động theo từng giai đoạn phù hợp hơn một con số duy nhất. Chẳng hạn, bắt đầu phân tích nguyên nhân khi ngân sách còn 50%, thêm thủ tục phê duyệt bổ sung cho thay đổi rủi ro cao khi còn 25%, và ưu tiên công việc ổn định hóa khi gần 0%. Tuy nhiên, nếu thiết kế để ngưỡng tự động chặn mọi triển khai thì ngay cả bản vá bảo mật khẩn cấp cũng bị trì hoãn, nên cần thủ tục ngoại lệ theo loại thay đổi và mức khẩn cấp.

C. Ra quyết định dựa trên ngân sách

Khi ngân sách lỗi đủ, có thể chấp nhận một mức rủi ro nhất định cho các công việc đổi mới như triển khai chức năng, thử nghiệm hiệu năng, thay đổi kiến trúc. Ở đây chấp nhận rủi ro không có nghĩa là cho phép sự cố ngẫu nhiên, mà là chọn những thay đổi giới hạn được phạm vi ảnh hưởng và có thể hoàn tác nhanh. Triển khai canary, feature flag, rollback tự động và môi trường kiểm chứng trước giúp thu được nhiều bài học hơn với cùng một ngân sách lỗi.

Khi ngân sách lỗi thiếu, thay vì dừng hẳn phát triển chức năng thì nâng mức ưu tiên cho công việc về độ tin cậy. Ví dụ, nếu nguyên nhân timeout là cạn kiệt connection pool của cơ sở dữ liệu, thay vì chỉ tăng dung lượng thì phải phân tích đồng thời mẫu truy vấn, bùng nổ thử lại, thu hồi kết nối và phân tán tải. Nếu không giải quyết nguyên nhân gốc mà tạm hạ mục tiêu SLO thì chỉ số sẽ đẹp hơn nhưng trải nghiệm khách hàng không được cải thiện.

4. Thiết kế đo lường và triển khai kỹ thuật

A. Định nghĩa sự kiện và mẫu số

SLI tốt phải có công thức tính ngắn, tái lập được với cùng đầu vào, và chủ sở hữu dịch vụ có thể giải thích kết quả. Định nghĩa "yêu cầu bình thường" có thể bao gồm không chỉ mã trạng thái HTTP mà cả việc nghiệp vụ có thành công không và tính đầy đủ của dữ liệu bắt buộc. Ví dụ, nếu trả về HTTP 200 nhưng kết quả phê duyệt thanh toán là pending thì không thể coi là thành công trong SLI hoàn tất thanh toán.

Phải quyết định có đưa các lần thử lại nội bộ và yêu cầu trùng lặp vào mẫu số hay không. Nếu một cú nhấp của người dùng được gửi ba lần do thử lại mạng mà cả ba yêu cầu đều được đếm vào mẫu số thì có thể phát sinh chênh lệch giữa cảm nhận người dùng và chỉ số. Ngược lại, nếu đếm mọi yêu cầu thực tế mà máy chủ nhận được thì có thể thấy hệ thống bị phơi bày trước bùng nổ thử lại đến mức nào. Nếu cần cả hai góc nhìn thì tách SLI sự kiện người dùng và SLI yêu cầu hạ tầng.

Điều kiện loại trừ phải được quản lý minh bạch. Có thể loại trừ thời gian bảo trì, lưu lượng kiểm thử và yêu cầu độc hại bị chặn, nhưng nếu loại trừ dữ liệu bất lợi sau khi sự cố xảy ra thì SLO trở thành công cụ "tẩy trắng" chỉ số. Danh sách loại trừ nên được quản lý phiên bản trong mã và tài liệu, và khi thay đổi thì cần được chủ sở hữu dịch vụ và người phụ trách quan sát rà soát.

B. Độ trễ và phân vị

Độ trễ trung bình có thể che lấp một số ít yêu cầu rất chậm. p50 thể hiện trải nghiệm của người dùng điển hình, còn p95 và p99 được dùng làm chỉ số bổ trợ thể hiện độ trễ đuôi và trải nghiệm xấu của một bộ phận người dùng. Tuy nhiên, thay vì lấy nguyên giá trị quan sát "p99 dưới bao nhiêu ms" làm SLO, việc đặt mục tiêu là tỷ lệ yêu cầu trong ngưỡng trên toàn bộ yêu cầu hợp lệ có thể rõ ràng hơn khi so sánh giữa các kỳ.

Giá trị thay đổi tùy theo điểm đo. Độ trễ đo ở phía client bao gồm cả DNS, truyền tải và render nên gần với trải nghiệm người dùng nhưng chịu ảnh hưởng lớn của môi trường mạng. Độ trễ đo bên trong máy chủ thuận lợi cho phân tích nguyên nhân nhưng không giải thích được tổng thời gian mà client cảm nhận. Vì vậy cần vận hành đồng thời SLI hành trình người dùng và chỉ số phân tích nguyên nhân theo từng thành phần, nhưng không trộn lẫn hai loại này vào cùng một SLO.

C. Pipeline dữ liệu

flowchart LR
    C[Client·Edge] --> G[Gateway·đo đạc dịch vụ]
    G --> T[Truy vết phân tán]
    G --> M[Tổng hợp metric]
    G --> L[Log có cấu trúc]
    T --> Q[Kiểm tra chất lượng·lấy mẫu]
    M --> Q
    L --> Q
    Q --> S[Engine tính SLI]
    S --> D[Dashboard SLO]
    S --> A[Cảnh báo·on-call]
    S --> R[Chính sách pipeline triển khai]
    S --> W[Báo cáo độ tin cậy hàng tuần]

Tầng thu thập phải quản lý chi phí và thông tin cá nhân mà không làm mất sự kiện gốc. Ghi log toàn bộ nội dung mọi yêu cầu có thể hữu ích cho gỡ lỗi nhưng làm tăng rủi ro về thông tin cá nhân và chi phí. Thay vào đó, phi định danh hóa các định danh, chỉ cấu trúc hóa các trường cần thiết, và tách riêng thời hạn lưu giữ bản gốc cùng quyền truy cập.

Độ trễ tổng hợp và lấy mẫu cũng ảnh hưởng đến việc diễn giải SLO. Trace có thể được lấy mẫu vì chi phí, nhưng cần chính sách ưu tiên giữ lại yêu cầu lỗi và yêu cầu chậm. Với metric, nếu dùng không giới hạn nhãn có cardinality cao thì chi phí lưu trữ và hiệu năng truy vấn sẽ xấu đi, nên trước hết chọn các chiều cần cho ra quyết định như dịch vụ, khu vực, phiên bản, tenant.

5. Quy trình vận hành và áp dụng trong tổ chức

A. Quy trình xây dựng SLO

  1. Xác định các hành trình người dùng cốt lõi và kết quả quan trọng về mặt kinh doanh.
  2. Định nghĩa bằng văn xuôi sự kiện thành công và sự kiện thất bại cho từng hành trình.
  3. Chọn nguồn đo đáng tin cậy trong số log, trace và metric.
  4. Tài liệu hóa mẫu số, tử số, ngưỡng, điều kiện loại trừ và kỳ đo của SLI.
  5. Xác định SLO dự thảo phản ánh mức hiện tại, kỳ vọng khách hàng, chi phí và yêu cầu quy định.
  6. Áp vào các sự cố trong quá khứ và lưu lượng cao điểm để kiểm chứng mục tiêu có thực tế không.
  7. Thống nhất các hành động vận hành theo từng giai đoạn tiêu hao ngân sách và thủ tục ngoại lệ.
  8. Sau một thời gian vận hành, rà soát cảnh báo sai, bỏ sót và sự không khớp nghiệp vụ để cải tiến.

Ban đầu, nên bắt đầu từ hành trình cốt lõi thay vì áp dụng cùng một SLO cho mọi chức năng. Định nghĩa trước các luồng gắn trực tiếp với khách hàng và doanh thu như đăng nhập, thanh toán, trạng thái đơn hàng sẽ làm rõ ưu tiên đầu tư. Sau đó mở rộng sang chức năng phụ và hệ thống nội bộ, đồng thời xây dựng mẫu chung cần thiết cho việc vận hành chỉ số.

Tài liệu SLO không chỉ ghi đội phụ trách mà còn ghi cả các dịch vụ phụ thuộc và thẩm quyền ra quyết định. Nếu sự cố của đội cơ sở dữ liệu ảnh hưởng đến SLO của dịch vụ đặt hàng, vai trò của đội gây ra nguyên nhân và đội truyền thông khách hàng phải được xác định trước. Mục đích phân chia trách nhiệm không phải là đùn đẩy trách nhiệm mà là rút ngắn đường khôi phục khi có sự cố.

B. Liên kết với triển khai và quản lý thay đổi

Pipeline CI/CD có thể tận dụng ngân sách lỗi cho việc phê duyệt triển khai. Nếu tỷ lệ đạt SLO trong kỳ gần đây và tốc độ tiêu hao ngắn hạn tốt thì cho phép triển khai canary phạm vi nhỏ, còn nếu tiêu hao nhanh thì có thể tự động thu hẹp phạm vi triển khai hoặc bổ sung người phê duyệt. Tuy nhiên, pipeline là phương tiện thực thi chính sách chứ không thay thế định nghĩa SLO. Phải giám sát riêng độ mới của dữ liệu và lỗi tính toán để tránh việc chặn tự động hay phê duyệt tự động xảy ra do lỗi đo đạc.

Với thay đổi rủi ro cao, áp dụng song song các cơ chế an toàn ngoài ngân sách lỗi. Thay đổi lược đồ dữ liệu có thể khó rollback, nên cần cách tiếp cận theo từng bước: mở rộng tương thích rồi mới chuyển đổi. Thay đổi về xác thực và thanh toán có thể không đủ chỉ với feature flag, nên bổ sung phê duyệt trước, nhóm người dùng giới hạn, thủ tục dừng giao dịch và nhật ký kiểm toán.

C. Ứng phó sự cố và học hỏi

Khi sự cố xảy ra, trước hết ưu tiên tác động đến khách hàng và việc khôi phục, còn truy tìm nguyên nhân được tiến hành song song với khôi phục. SLO và ngân sách lỗi trở thành ngôn ngữ chung để nhanh chóng giải thích mức độ nghiêm trọng của sự cố. Tuy nhiên, con số ngân sách lỗi thấp không có nghĩa tác động đến khách hàng luôn nhỏ, nên phải xem xét cả số người dùng bị ảnh hưởng, giá trị giao dịch và việc dữ liệu có bị hỏng hay không.

Trong rà soát sau sự cố (postmortem), phân tích điều kiện của hệ thống thay vì lỗi của cá nhân. Đặt câu hỏi: cảnh báo có bị chậm không, có đường rollback không, thay đổi có đủ nhỏ không, kiểm thử có phản ánh đặc tính lưu lượng thực không, có thể biết được trạng thái của dịch vụ phụ thuộc không. Biện pháp ngăn tái diễn phải xác định người phụ trách và thời điểm hoàn thành, và kiểm chứng xem hiệu quả có được xác nhận trong xu hướng của cùng SLO đó hay không.

6. So sánh và tình huống

A. So sánh KPI truyền thống với SLO

KPI truyền thống có thế mạnh trong việc thể hiện năng suất kinh doanh như doanh thu, thông lượng, số lần triển khai. Nhưng khi thông lượng tăng, lỗi và độ trễ có thể tăng theo, và nếu chỉ nhìn KPI thì sự suy giảm chất lượng có thể lộ ra muộn. SLO xác định ngưỡng chất lượng tối thiểu xoay quanh kết quả dịch vụ mà người dùng kỳ vọng, và được dùng cùng KPI để cân bằng giữa tốc độ và sự ổn định.

Trục so sánh KPI vận hành truyền thống Hệ thống SLO·ngân sách lỗi
Trọng tâm Sản lượng·khối lượng hoạt động Độ tin cậy theo góc nhìn người dùng
Diễn giải thất bại Số sự cố·giá trị trung bình Tiêu hao ngân sách so với mục tiêu
Quan hệ phát triển và vận hành Xung đột mục tiêu phụ thuộc thương lượng Chính sách thay đổi dựa trên dữ liệu
Hướng cải tiến Nhiều hơn·nhanh hơn Học hỏi trong khi kiểm soát rủi ro
Hạn chế Tác động khách hàng bị biểu diễn phân tán Chi phí thiết kế chỉ số·đo đạc

Hai hệ thống không thay thế mà bổ sung cho nhau. Ví dụ, số lần triển khai thể hiện tốc độ đổi mới, còn SLO thể hiện tác động chất lượng mà việc triển khai gây ra cho khách hàng. Nếu số lần triển khai nhiều mà SLO vẫn được duy trì thì có thể xác nhận hiệu quả của tự động hóa và thay đổi nhỏ. Ngược lại, nếu số lần triển khai tăng nhưng ngân sách lỗi giảm nhanh thì có thể đó là kết quả của việc chỉ tối ưu chỉ số tốc độ.

B. Tình huống API đặt hàng thương mại điện tử

Giả sử một API đặt hàng thương mại điện tử ghi nhận 9,995,000 yêu cầu thành công trên 10,000,000 yêu cầu hợp lệ mỗi tháng. Tỷ lệ thành công là 99.95%, và nếu SLO mục tiêu là 99.9% thì ngân sách lỗi dựa trên yêu cầu của kỳ này là 10,000 yêu cầu, nghĩa là đã dùng 5,000 và còn lại 5,000. Ngân sách còn lại không có nghĩa là phê duyệt mọi thay đổi, mà phải xác nhận lần triển khai tiếp theo có gắn với việc trừ tồn kho hay không.

Nếu thất bại trừ tồn kho xuất hiện muộn hơn thất bại tạo đơn hàng thì SLI tỷ lệ thành công đơn giản có thể bỏ sót vấn đề. Cần tách tiếp nhận đơn hàng thành công và xác nhận tồn kho thành công thành các hành trình người dùng riêng, đồng thời đo thêm thời gian xử lý của giao dịch bù trừ và đơn hàng chưa xác nhận. Làm vậy có thể thu hẹp khoảng cách ý nghĩa giữa "API phản hồi thành công" và "đơn hàng của khách thực sự hoàn tất".

Nếu 40% ngân sách lỗi bị tiêu hao trong một giờ thì không được chỉ nhìn lượng còn lại theo tháng mà kết luận là bình thường. Phân rã mức tiêu hao theo phiên bản triển khai, khu vực, cơ sở dữ liệu phụ thuộc, rồi dừng phiên bản có vấn đề ở canary hoặc rollback. Đồng thời hướng dẫn khách hàng về việc thử đặt lại hay khả năng thanh toán trùng, và sau khi khôi phục thì cải thiện idempotency key và kiểm tra tính nhất quán tồn kho.

C. Tình huống dịch vụ phân tích theo lô

Với dịch vụ chạy batch dự báo nhu cầu mỗi giờ, điều cốt lõi là kết quả có sẵn sàng trước thời điểm quy định hay không, hơn là tỷ lệ phản hồi tức thì của mọi yêu cầu. Ví dụ, có thể định nghĩa SLO là "99% tác vụ có kết quả dự báo với dữ liệu mới nhất được chuẩn bị xong trước 30 phút khi bắt đầu giờ kinh doanh". Khi đó cần phân biệt thất bại tác vụ, trễ dữ liệu đầu vào, trễ thực thi mô hình, thất bại nạp kết quả và đặt chỉ số theo từng nguyên nhân.

Tác vụ batch có đặc tính có thể chạy lại, nên nếu chỉ tính ngân sách lỗi bằng số yêu cầu thất bại thì không phản ánh chi phí thực. Quản lý chi phí tính toán cho việc chạy lại, độ trễ ra quyết định và thời gian hiệu chỉnh thủ công do con người thực hiện như các chỉ số vận hành riêng. SLO biểu diễn cam kết thời gian đối với kết quả cho khách hàng, còn chỉ số chi phí thể hiện nguồn lực đã chi trả để giữ cam kết đó.

7. Chuyên sâu: Phân tầng SLO trong môi trường đa dịch vụ

A. Hành trình người dùng và mục tiêu thành phần

Trong môi trường microservice, không được đơn giản nhân các SLO của từng dịch vụ để khẳng định SLO tổng thể. Bởi đồ thị gọi thực tế tồn tại gọi song song, chức năng tùy chọn, cache hit, thử lại và đường thay thế. An toàn hơn là phân tích cấu trúc gọi và đo trực tiếp điều kiện thành công của hành trình người dùng, rồi dùng SLO của các dịch vụ cấp dưới làm giá trị tham khảo cho việc phân bổ ngân sách.

SLO của hành trình cốt lõi đại diện cho kết quả giá trị khách hàng. SLO của dịch vụ cấp dưới đại diện cho chất lượng kỹ thuật mà đội có thể kiểm soát. Nếu mục tiêu cấp trên không đạt dù mọi dịch vụ cấp dưới đều đạt mục tiêu thì có thể có thiếu sót đo đạc hoặc vấn đề tương tác, còn nếu chỉ một số dịch vụ cấp dưới không đạt thì có thể xác định ưu tiên cải thiện cho phụ thuộc tương ứng.

B. Phân bổ ngân sách và quản lý phụ thuộc

Nếu hành trình đặt hàng cấp trên có ngân sách thất bại 0.1% thì không thể cấp cùng ngân sách đó riêng cho xác thực, sản phẩm, tồn kho và thanh toán. Rủi ro đóng góp khác nhau tùy theo gọi song song hay tuần tự, có thể thay thế khi thất bại hay không, và có phải bước cốt lõi mà khách hàng nhìn thấy hay không. Phân bổ ngân sách bắt đầu bằng tính toán toán học nhưng được chốt bằng thương lượng chính sách phản ánh đường lan truyền sự cố và khả năng khôi phục.

Hợp đồng phụ thuộc phải bao gồm không chỉ điều kiện thành công mà cả timeout và thử lại. Nếu dịch vụ cấp trên vừa chờ độ trễ của dịch vụ cấp dưới vừa thử lại thì độ trễ nhỏ có thể khuếch đại thành sự cố toàn bộ. Chia ngân sách timeout theo từng đoạn, giới hạn số lần thử lại và backoff, áp dụng circuit breaker và bulkhead pool sẽ làm dịu sự tiêu hao đột ngột của ngân sách lỗi.

C. Danh mục đầu tư vào độ tin cậy

Dữ liệu ngân sách lỗi trở thành căn cứ đánh giá khoản đầu tư nào cải thiện chất lượng cho khách hàng. Đưa vào cache, cải thiện chỉ mục cơ sở dữ liệu, tăng cường khả năng quan sát, rollback tự động khi triển khai và diễn tập khôi phục thảm họa có chi phí và hiệu quả khác nhau. Nếu chỉ đánh giá bằng cải thiện SLO ngắn hạn thì có thể bỏ sót nợ vận hành ẩn và chi phí bảo trì dài hạn, nên cần kiểm chứng hiệu quả đầu tư đồng thời bằng xu hướng của tốc độ tiêu hao, thời gian khôi phục, tỷ lệ thay đổi thất bại và khối lượng công việc thủ công.

8. Các vấn đề cần cân nhắc và hàm ý

A. Tính nhất quán của thiết kế chỉ số

Thứ nhất, SLI phải phản ánh kết quả mà người dùng đánh giá là thành công, chứ không phải giá trị mà hệ thống dễ đo. Nếu mã trạng thái HTTP không đủ để biểu diễn thành công nghiệp vụ thì đưa sự kiện miền và trạng thái kết quả vào đo đạc. Quản lý định nghĩa và ngoại lệ ở mức review mã để không tùy tiện loại bỏ lưu lượng nhất định khỏi mẫu số.

Thứ hai, nếu định nghĩa chỉ số khác nhau giữa các dịch vụ thì việc so sánh toàn tổ chức trở nên khó khăn. Xây dựng thuật ngữ chung và mẫu tính toán, nhưng không ép buộc cùng một ngưỡng cho mọi dịch vụ. Thứ cần chuẩn hóa là cách định nghĩa và quy trình kiểm chứng, còn mức mục tiêu được phân cấp theo kỳ vọng người dùng và tầm quan trọng nghiệp vụ.

B. Nhất quán cuối cùng và truyền thông với người dùng

Thứ ba, trong hệ thống phân tán, dù đạt SLO thì dữ liệu vẫn có thể bị trễ trong chốc lát. Cung cấp cho người dùng trạng thái đang xử lý, thời điểm cập nhật cuối và cách thử lại sẽ giúp họ không trải nghiệm tính nhất quán trễ chỉ như một vấn đề chất lượng. Người vận hành phải kiểm tra cả độ chính xác của thông báo trạng thái cùng với tỷ lệ thành công kỹ thuật.

Thứ tư, thông báo sự cố nên được viết xoay quanh tác động, phạm vi và cách ứng phó thay vì thuật ngữ kỹ thuật. Lượng tiêu hao ngân sách lỗi hữu ích cho ra quyết định nội bộ, nhưng với khách hàng thì ưu tiên giải thích chức năng nào không dùng được đến khi nào và các biện pháp bảo vệ dữ liệu.

C. Tự động hóa và kiểm soát ngoại lệ

Thứ năm, tự động hóa gắn với ngân sách cho phép ứng phó nhanh nhưng đo đạc sai có thể khiến toàn bộ tổ chức hoạt động sai. Cần có giám sát cấp meta (meta-monitoring) để phân biệt lỗi tính SLO, trễ dữ liệu và sự cố của hệ thống quan sát với sự cố dịch vụ. Với những thay đổi phải thực hiện bất kể ngân sách như bản vá bảo mật khẩn cấp hay biện pháp theo luật định, cần có thủ tục phê duyệt riêng và rà soát sau.

Thứ sáu, rollback tự động không phù hợp với mọi lỗi. Với những tác vụ đã phát sinh hiệu ứng bên ngoài như di chuyển dữ liệu và thay đổi hợp đồng bên ngoài, cần tác vụ bù trừ và duy trì tương thích hơn là quay lui phiên bản. Xây dựng runbook chiến lược khôi phục theo loại thay đổi và diễn tập thực tế định kỳ.

D. Thông tin cá nhân, kiểm toán và chi phí

Thứ bảy, log và dữ liệu truy vết thu thập để tính SLI cũng có thể là đối tượng bảo vệ thông tin cá nhân. Áp dụng thu thập tối thiểu, giới hạn mục đích, thời hạn lưu giữ, kiểm soát truy cập và che (masking), đồng thời không lưu dữ liệu nguyên bản không cần thiết cho phân tích vận hành. Khi cần truy vết kiểm toán, tách dữ liệu gốc và dữ liệu dẫn xuất phục vụ phân tích để phân cấp quyền truy cập và chính sách lưu giữ.

Thứ tám, điều chỉnh mức độ đo đạc để chi phí quan sát không vượt quá giá trị dịch vụ. Nhãn cardinality cao và lưu trữ bản gốc dài hạn có thể làm tăng chi phí, nên phân chia dữ liệu tính SLO cốt lõi và dữ liệu điều tra chi tiết theo cấp độ lưu giữ. Kiểm chứng mẫu đại diện và chính sách ưu tiên lưu giữ lỗi/độ trễ để việc cắt giảm chi phí không làm tổn hại năng lực phân tích lỗi.

Tóm tắt một câu: Cốt lõi của vận hành dịch vụ dựa trên dữ liệu là đo độ tin cậy theo góc nhìn người dùng bằng SLI, đặt mục tiêu bằng SLO, rồi điều chỉnh triển khai, ổn định hóa và đầu tư theo tốc độ tiêu hao của ngân sách lỗi.