SLO (Service-Level Objective) - Introduce for implement
Ảnh hưởng của độ tin cậy (Relability)
Độ tin cậy là một vấn đề được ưu tiên hàng đầu đối với các hệ thống hay service phục vụ người dùng, đối với các hệ thống phục vụ hàng triệu user mỗi ngày thì độ tin cậy sẽ phải quy định nghiêm ngặt về thời gian phản hồi hay khả năng xử lý yêu cầu. hay hệ thống xử lý dữ liệu lớn thì độ tin cậy giúp giám sát được tính đúng đắn của việc xử lý dữ liệu (batch processing, streaming processing). Vì vậy, hệ thống lớn hay nhỏ đều cần có một ngưỡng về độ tin cậy nhất định. Vậy quy tắc hay chỉ số nào giúp định nghĩa được độ tin cậy hệ thống một cách hiệu quả nhất ?
Trả lời ngắn gọn. Đó chính là SLO.
Định nghĩa SLO
Trong các phương pháp SRE, chỉ số SLO (Service Object Level) giúp đặt ra những mục tiêu ngắn hạn hoặc dài hạn về độ tin cậy đối với các thành phần hệ thống. Độ tin cậy tương quan với tính khả dụng và khả năng bảo mật, vậy nên việc định nghĩa SLO như thế nào đẻ giúp người dùng hài lòng với service là việc khó khăn.
Fact:
"Những hệ thống có tính bảo mật cao thường rườm rà và khó khăn hơn trong việc sử dụng vì chúng thường thông qua nhiều lớp xác thực hoặc ủy quyền khác nhau"
Vì vậy việc đánh đổi độ tin cậy hệ thống với trải nghiệm người dùng sẽ là vấn đề lớn vì những cải thiện liên quan đến trải nghiệm người dùng như phát triển thêm tính năng, cải thiện UI/UX sẽ dễ dàng thúc đẩy trải nghiệm người dùng hơn so với việc cải thiện độ tin cậy hệ thống. Tuy nhiên việc tăng tốc độ phát triển tính năng dịch vụ sẽ có thể làm cho hệ thống có thêm nhiều khả năng xảy ra lỗi hơn. Vì vậy cần cân nhắc kĩ quyết định trong việc cải thiện độ tin cậy hệ thống và tốc độ phát triển tính năng. Lúc này dựa trên SLO ngắn hạn hoặc dài hạn sẽ giúp đưa ra những phương án cải tiến phù hợp với tình hình thực tế.
Chỉ số SLO dài hạn có thể giúp đưa ra những ké hoạch trong tương lai trong khi SLO ngắn hạn giúp đặt ra các task trước mắt giúp cải thiện chất lượng hệ thống. Vậy căn cứ nào để đặt ngưỡng SLO hay việc tiếp cận đến SLO như thế nào?
Tiếp cận SLO
Để tiếp cận SLO cho các service thì việc đầu tiên cần làm là xác định các chỉ số SLIs (Service-Level Indicator) tiêu chí lựa chọn SLIs sẽ ưu tiên vào trải nghiệm người dùng vì nó phản ánh thực tế nhất đến mục tiêu sản phẩm là phục vụ tốt nhất đến những người sử dụng vì người dùng "happy" với dịch vụ thì những người dùng đó sẽ đem lại nhiều lợi ích hơn đến với tổ chức giúp sản phẩm phát triển hơn -> thu hút thêm những người dùng khác.
Error budget
Ngân sách lỗi là lượng lỗi mà dịch vụ có thể tích lũy trong một khoảng thời gian nhất định trước khi user "unhappy". Có thể hiểu nó như giới hạn chịu đựng khó khăn giữa người dùng và dịch vụ.
Ví dụ set ngưỡng SLO về avaibility cho dịch vụ 99.99% uptime trong vòng 4 tuần -> Error budget = 4 minutes downtime. Nghĩa là trong vòng 4 tuần, dịch vụ chỉ được xảy ra lỗi hoặc tạm dừng cung cấp dịch vụ trong vòng 4 phút, nếu downtime > 4 phút thì sẽ vi phạm SLO. Có thể sử dụng error budget cho các mục đích khác nhau như áp dụng những công nghệ mới vào dịch vụ hoặc thực hiện các cuộc diễn tập về xử lý sự cố.
SLI
Quy ước chỉ số SLIs:
Theo như SRE Workbook nhấn mạnh về việc quy ước SLIs thì nó là tỉ lệ giữa 2 chỉ số: good event/total event. Tuy nhiên, khi mới bắt đầu tiếp thì cận những chỉ số sức khỏe liên quan đến dịch vụ đều có thể coi là SLIs.
Đối với những quá trình nền (background process) không ảnh hưởng trực tiếp tới trải nghiệm người dùng như pipeline processing hay period task thì sẽ cần xác định các chỉ số SLIs liên quan đến tính đúng đắn dữ liệu, khả năng process dữ liệu lớn trong khoảng thời gian, các step khi thực hiện giữa các pipeline hay độ phủ dữ liệu khi process trong một ngưỡng quy định.
Khi mong muốn áp dụng SLO vào dịch vụ thì lời khuyên nên bắt đầu vào 2 thuộc tính cơ bản trước là Latency và Avaibility vì 2 thuộc tính này là 2 thuộc tính dễ collect nhất và chúng đều sẽ tồn tại trên tất cả các service, tiếp theo sẽ liệt kê SLIs cần thực hiện giám sát trên service đó và đặt ra SLO phù hợp dựa trên đặc tính của service dựa trên 2 thuộc tính trên. Việc xác định SLOs sẽ không cần phải chặt chẽ ngay từ lúc đầu bởi vì nếu chặt chẽ ngay từ lúc đầu sẽ vô tình tạo nên gánh nặng hay áp lực đối với các SREs và product team trong trường hợp dịch vụ không đạt như kì vọng, SLOs đó có thể cải thiện dần dần để phù hợp hơn với trải nghiệm người dùng và tổ chức cần.
Referrence:
All rights reserved
