Những điều cần lưu ý khi xây dựng SLO trong SRE !

Những điều cần lưu ý khi xây dựng SLO trong SRE !Cuongquach.com | Như bạn đã biết, SLI SLO là hai chỉ số rất quan trọng để xác định và đo lường độ tin cậy của dịch vụ. Trong bài viết này, chúng ta sẽ tập trung đi sâu vào các phương thức để thiết lập SLO và SLI tốt nhất cho doanh nghiệp. (Xem thêm: Những nguyên tắc cơ bản SRE – SLI, SLO và SLA)

nhung-dieu-can-luu-y-khi-xay-dung-SLO-trong-SRE

1. Đánh giá về SLO

SLO là mục tiêu về độ khả dụng mà một doanh nghiệp đặt ra và luôn nỗ lực hành động để đạt được. Có thể bạn sẽ liên tưởng đến SLA, nhưng hãy nhớ rằng: bạn cố gắng làm việc để đạt được SLO vì sự thành bại của tổ chức, không phải vì bị ràng buộc bởi một thỏa thuận nào cả! Vậy nên, khi xác định SLO, nên chú trọng vào việc nâng cao trải nghiệm người dùng. Vì sự hài lòng của khách hàng chính là điều mà doanh nghiệp hướng đến.

Để “bảo vệSLO, doanh nghiệp phải hạn chế số lần xảy ra downtime hoặc tìm cách làm giảm ảnh hưởng của nó đến hoạt động của hệ thống. Khi xảy ra tình trạng trên,  bạn có thể khắc phục bằng cách chuyển trọng tâm vào cải tiến độ tin cậy thay vì phát triển tính năng và sản phẩm mới.

sla vs slo
sla vs slo

2. Lưu ý khi thiết kế SLO

  • SLO có thể là công cụ hữu ích đối với những nhóm chưa có mục tiêu rõ ràng. Vậy nên, hãy chọn SLO phù hợp với mong muốn của tổ chức, đừng cố gắng đặt mục tiêu cao hơn những gì bạn thực sự cần. Có như vậy, SLO mới trở thành kim chỉ nam định hướng hành động cho cả nhóm của bạn!
  • SLO nên được thiết kế theo yêu cầu trải nghiệm của người dùng – về độ khả dụng và độ trễ, thay vì theo các đặc điểm, chi tiết cụ thể của sản phẩm. Chẳng hạn: các phản hồi trực tiếp (direct response request) cho người dùng nên được nhóm thành một SLO tách biệt với phản hồi nền (response background) hoặc phản hồi phụ trợ (bằng hình ảnh thu nhỏ).
  • Bạn phải nắm rõ phạm vi điều chỉnh của SLO và chắc chắn rằng SLO của mình đã xem xét đến các vấn đề: liệu có tính các request không hợp lệ của người dùng là một lỗi hay không hoặc sẽ xử lý như thế nào khi khách hàng spam hệ thống với hàng loạt các yêu cầu.
  • Lưu ý cuối cùng, hãy thiết kế SLO thật đơn giản và cụ thể. Bạn có thể lược bỏ các hoạt động không quan trọng nhưng đừng thêm chúng vào SLO để rồi “pha loãng” những vấn đề thật sự cần quan tâm.

3. Một vài ví dụ về SLO

Độ khả dụng

Độ khả dụng được đo lường bằng cách tính toán số số lượt truy cập thất bại và số request lỗi, sau đó lập báo cáo dưới dạng tỷ lệ phần trăm. Một báo cáo SLO có dạng như sau:

Độ khả dụng: có ít nhất <phần trăm> yêu cầu trong tổng số …

Cụ thể:

Độ khả dụng: Nodejs sẽ phản hồi các truy vấn không phát sinh lỗi 503 trong vòng 30s đối với các pageviews của trình duyệt và phản hồi 99.95% tất cả các truy vấn trong tháng.

hoặc

Độ khả dụng: Nodejs sẽ phản hồi các truy vấn không phát sinh lỗi 503 trong vòng 60s đối với các lệnh gọi API và phản hồi ít nhất 99.9% tất cả các truy vấn trong tháng.

Nếu yêu cầu mất hơn 30 giây (60 giây cho thiết bị di động), dịch vụ có thể đã bị ngừng hoạt động. Và chúng ta dựa vào đó để tính SLO.

Độ trễ

Độ trễ là thước đo tốc độ hệ thống phản hồi lại yêu cầu của khách hàng. hệ thống sẽ đếm số lượt nhận phản hồi lâu hơn mức quy định sau đó tổng hợp lại thành báo cáo.

Độ trễ: sẽ phản hồi ít nhất các yêu cầu trong vòng…

Cụ thể:

Độ trễ: Node.js sẽ phản hồi ít nhất 50% yêu cầu trong tháng trong vòng 250ms và ít nhất 99% yêu cầu trong tháng trong vòng 3000ms.

Tỷ lệ là thước đo quan trọng của chúng ta ….

Độ trễ SLI được biểu diễn theo tỷ lệ phần trăm. Cùng với SLO – cũng được quy về tỷ lệ phần trăm, khiến cho dữ liệu nhất quán và dễ hiểu, vì chúng đều có cùng đơn vị và cùng phạm vi ảnh hưởng.

Hạn chế sử dụng các chỉ số trung bình (chẳng hạn như độ trễ trung bình) vì các số này có thể ẩn chứa các ngoại lệ và các giá trị quá nhỏ không thể phân biệt được. Điều này cũng như việc người dùng khó nhận thấy sự khác biệt giữa hai thời gian phản hồi là 50 ms250 ms.

. . . ngoại trừ 100%

Mục tiêu 100% là bất khả thi, thậm chí, mục tiêu này cũng có thể không cần thiết. Bởi vì nếu mục tiêu SLO là 100% có nghĩa là bạn không có ngân sách lỗi!

  • Báo cáo

Chúng tôi khuyên bạn nên lập báo cáo hàng quý dựa trên SLO và sử dụng số liệu đó để ra quyết định. Kỳ báo cáo càng ngắn, sẽ càng liên quan nhiều đến các vấn đề nhỏ, mang tính hàng ngày hơn là các vấn đề lớn, có ảnh hưởng lâu dài.

  • Ví dụ về SLO hàng quý:

Dưới đây là một cách báo cáo hiệu suất dịch vụ so với SLO:

báo cáo hiệu suất dịch vụ so với SLO
báo cáo hiệu suất dịch vụ so với SLO

Ví dụ: bạn có thể kích hoạt một trang nếu bạn đã sử dụng ≥1% error budget hàng quý trong bốn giờ qua hoặc bạn có thể đóng băng các bản phát hành nếu đã sử dụng ≥ ⅓ error budget hàng quý trong 30 ngày qua.

Phân tích hiệu suất SLI (theo từng địa phương, vùng miền, khách hàng và RPC cụ thể) có thể được áp dụng để sửa lỗi và ra cảnh báo nhưng thường không góp vai trò gì trong việc xác định SLO hoặc lập bảng tóm tắt hàng quý.

Kết luận

SLO là một lĩnh vực sâu rộng, chúng ta không thể bàn luận hết tất cả chỉ trong một bài viết. Mặc dù bài này chỉ bao gồm những hướng dẫn cơ bản nhưng nếu xem xét kỹ, bạn có thể sẽ tránh được những lỗi phổ biến mà mọi người mắc phải khi bắt đầu với SLO.

Nguồn: https://cuongquach.com/

Previous articleEbook Quản Trị Mạng Nâng Cao – TT KHTN HCM (PDF)
Next articleTạo/Xoá thông tin Credential trên Jenkins bằng CLI
Bạn đang theo dõi website "https://cuongquach.com/" nơi lưu trữ những kiến thức tổng hợp và chia sẻ cá nhân về Quản Trị Hệ Thống Dịch Vụ & Mạng, được xây dựng lại dưới nền tảng kinh nghiệm của bản thân mình, Quách Chí Cường. Hy vọng bạn sẽ thích nơi này !