SLI, SLO, SLA

Ba Chữ Cái Vận Hành Production

Độ tin cậy mà không có đo lường chỉ là sân khấu. SRE biến độ tin cậy thành một con số, được thống nhất trước, mà mọi người đều có thể kiểm chứng.

Chỉ số Mức độ Dịch vụ (SLI): một phép đo hành vi dịch vụ. Ví dụ: độ trễ yêu cầu, tỷ lệ lỗi, thông lượng, độ sâu hàng đợi. SLI là thứ bạn có thể vẽ biểu đồ.

Mục tiêu Mức độ Dịch vụ (SLO): giá trị hoặc khoảng mục tiêu cho một SLI. Ví dụ: '99,9% yêu cầu HTTP thành công trong cửa sổ trượt 28 ngày.' SLO là lời hứa bạn đưa ra cho chính mình và người dùng về chất lượng dịch vụ chấp nhận được.

Thỏa thuận Mức độ Dịch vụ (SLA): cam kết hợp đồng, thường kèm theo hình phạt tài chính khi vi phạm. Ví dụ: 'Chúng tôi hoàn 10% nếu tỷ lệ sẵn sàng hàng tháng giảm xuống dưới 99,9%.' SLA là lời hứa được thực thi bởi luật sư.

Sự khác biệt quan trọng: SLA của bạn phải luôn lỏng lẻo hơn SLO. Nếu bạn nhắm mục tiêu 99,9% nội bộ và ký hợp đồng 99,9% bên ngoài, bạn không còn biên độ. Các SRE thường chạy SLO chặt hơn SLA một chữ số 9: mục tiêu 99,95%, hợp đồng 99,9%. Khoảng cách này hấp thụ tuần xấu không thể tránh khỏi.

Ngân sách lỗi: SLO ngược

Từ mục tiêu độ tin cậy đến quyết định kỹ thuật

Một SLO đặt ra mục tiêu độ tin cậy. Ngân sách lỗi là phần còn lại: lượng lỗi bạn có thể chấp nhận trước khi bỏ lỡ mục tiêu.

Nếu SLO của bạn cam kết 99.9% thành công trong 28 ngày, ngân sách lỗi của bạn là 0.1% số yêu cầu, hoặc khoảng 40 phút downtime hoàn toàn mỗi tháng. Ngân sách này là của bạn để sử dụng theo cách bạn muốn: cho các bản phát hành đã lên kế hoạch, cho các tính năng thử nghiệm, cho kỹ thuật hỗn loạn, hoặc để chịu đựng một phụ thuộc hoạt động không ổn định.

Ngân sách lỗi thay đổi xung đột giữa dev và ops. Không có ngân sách, mọi sự cố đều dẫn đến tranh cãi về ai đã triển khai thay đổi sai và làm thế nào để ngăn chặn sự cố tiếp theo. Với ngân sách:

- Ngân sách còn: triển khai nhanh hơn, chấp nhận rủi ro cao hơn, chạy thử nghiệm. Ngân sách sẽ chi trả cho điều đó.

- Ngân sách đã hết: dừng phát hành tính năng mới, đóng băng các thay đổi rủi ro, tập trung vào công việc độ tin cậy cho đến khi ngân sách được tái tạo.

Điều này chuyển đổi độ tin cậy từ một cuộc tranh luận cảm tính thành một nguồn lực có thể đo lường. Kỹ sư có thể chi tiêu ngân sách một cách có chủ đích, giống như bất kỳ đầu vào sản xuất nào khác.

Xác Định Toil

Những Gì Được Coi Là Toil

Không phải mọi tác vụ vận hành đều được coi là toil. SRE định nghĩa toil một cách chính xác: công việc thủ công, lặp lại, có thể tự động hóa, mang tính chiến thuật, không mang lại giá trị bền vững, và tăng tuyến tính khi dịch vụ mở rộng.

Tất cả sáu đặc tính phải đồng thời tồn tại. Một lần di chuyển dữ liệu là thủ công nhưng không lặp lại: điều đó không được coi là toil. Một kỹ sư cao cấp thiết kế kiến trúc dịch vụ mới đưa ra quyết định mang tính chiến thuật nhưng tạo ra giá trị bền vững: điều đó không được coi là toil.

Các ví dụ được coi là toil:

- Thủ công khởi động lại dịch vụ sau khi bị crash do rò rỉ bộ nhớ

- Dán các đoạn log vào kênh chat trong quá trình xử lý sự cố

- Điền form ticket để cung cấp cơ sở dữ liệu mới

- Chạy báo cáo dung lượng hàng quý thủ công

- Phê duyệt từng yêu cầu triển khai định kỳ một cách thủ công

Quy tắc năm mươi phần trăm giới hạn toil ở mức một nửa thời gian của SRE. Nếu vượt quá 50%, đội ngũ phải chuyển trách nhiệm trở lại cho đội ngũ sản phẩm hoặc tuyển thêm kỹ sư, nhưng mục tiêu vẫn rõ ràng: đưa toil về gần bằng không bằng cách thay thế nó bằng các hệ thống được thiết kế sẵn để thực hiện cùng công việc mà không cần can thiệp thủ công.

Tự động hóa không chỉ tiết kiệm thời gian. Nó loại bỏ hoàn toàn một nhóm lỗi do con người gây ra. Một script cung cấp cơ sở dữ liệu sẽ không bỏ sót bước nào sau một ca làm việc dài.

Lý luận kiểm toán toil

Đội ngũ của bạn theo dõi cách thời gian được sử dụng. Quý trước phân bổ như sau: 30% triển khai, 25% xử lý sự cố, 20% công việc dung lượng, 15% phát triển tính năng, 10% yêu cầu một lần từ các đội sản phẩm.

On-Call Hygiene

Engineers, Not Pagers

On-call mang lại chi phí thực sự. Giấc ngủ bị gián đoạn, cuối tuần bị phá vỡ, và áp lực từ những vấn đề chưa biết ngày càng tăng. SRE coi on-call như một nguồn lực hữu hạn cần duy trì bền vững, không phải là gánh nặng anh hùng do người quan tâm nhất gánh vác.

Các vòng xoay on-call lành mạnh tuân theo một số nguyên tắc:

- Thời gian được bù đắp: giờ on-call được quy đổi thành thời gian nghỉ bù, lương bổ sung hoặc quyền lợi tương đương. On-call miễn phí sẽ làm kiệt sức đội ngũ.

- Độ sâu vòng xoay hợp lý: đội ngũ sáu người chạy primary và secondary đồng nghĩa mỗi kỹ sư chỉ phải trực một ca mỗi ba tuần. Vòng xoay hai người sẽ phá hủy sự nghiệp.

- Ngân sách số lượng trang: sách SRE của Google gợi ý tối đa hai sự kiện báo động mỗi ca mười hai giờ. Vượt quá mức đó, đội ngũ phải đầu tư thời gian kỹ thuật để giảm khối lượng cảnh báo, thay vì chỉ chịu đựng nó.

- Chỉ cảnh báo có thể hành động: mỗi trang phải yêu cầu hành động của con người. Nếu một trang bị bỏ qua, tự động hóa hoặc lặp lại trong quá trình vận hành bình thường, nó không nên tồn tại. Mệt mỏi cảnh báo là một khiếm khuyết về độ tin cậy.

- Bàn giao theo mặt trời: các đội ngũ phân bố toàn cầu bàn giao ca trực tại ranh giới múi giờ để không ai bị gọi lúc 3 giờ sáng trừ khi hệ thống thực sự không thể chờ đến sáng.

Blameless Postmortems

Làm thế nào Sự cố trở thành Cải tiến

Mọi sự cố quan trọng đều có một bản phân tích sau sự cố (postmortem): một bản phân tích bằng văn bản về những gì đã xảy ra, lý do tại sao, cách khắc phục và những thay đổi nào để ngăn ngừa tái phát. Bản phân tích sau sự cố là tương đương SRE của lãi kép: mỗi bản phân tích thêm độ tin cậy vĩnh viễn cho hệ thống.

Không đổ lỗi nghĩa là tài liệu quy trách nhiệm cho các hệ thống và quy trình, không bao giờ quy cho cá nhân. Nếu một kỹ sư chạy sai lệnh, bản phân tích sau sự cố sẽ hỏi: tại sao hệ thống cho phép lệnh đó? Tại sao không có biện pháp bảo vệ nào phát hiện ra? Thay đổi nào đối với hệ thống, tài liệu hoặc công cụ sẽ ngăn kỹ sư tiếp theo mắc cùng một sai lầm?

Văn hóa không đổ lỗi tồn tại vì một lý do duy nhất: con người che giấu sai lầm khi họ sợ bị trừng phạt. Những sai lầm bị che giấu sẽ trở thành sự cố tiếp theo. Chi phí của một văn hóa không đổ lỗi được coi là rẻ so với chi phí tích lũy các lỗi không được tiết lộ.

Các bản phân tích sau sự cố thường bao gồm:

- Tóm tắt: mô tả một đoạn về sự cố và tác động

- Dòng thời gian: tái tạo từng phút với dấu thời gian

- Phân tích nguyên nhân gốc rễ: các yếu tố kỹ thuật và quy trình đã cho phép sự cố xảy ra

- Phát hiện: cách nhóm biết về sự cố và mất bao lâu để phát hiện

- Khắc phục: các hành động được thực hiện để khôi phục dịch vụ

- Bài học rút ra: những gì đã hoạt động, những gì chưa hoạt động

- Hạng mục hành động: các tác vụ kỹ thuật cụ thể, có chủ sở hữu và có thời hạn

Các hạng mục hành động được lưu trong công cụ theo dõi. Chúng được ưu tiên như bất kỳ công việc kỹ thuật nào khác. Các bản phân tích sau sự cố không có hạng mục hành động chỉ là kể chuyện. Công việc không thay đổi điều gì.

Bốn Tín hiệu Vàng

Những gì Mọi Dịch vụ Phải Đo lường

Cuốn sách SRE của Google đề xuất bốn tín hiệu mà mọi dịch vụ hướng tới người dùng phải cung cấp: độ trễ, lưu lượng, lỗi và độ bão hòa. Cùng nhau, chúng mô tả tình trạng dịch vụ từ góc nhìn của người dùng. Giám sát với ít tín hiệu hơn sẽ để lại các điểm mù; giám sát với hàng trăm chỉ số sẽ khiến đội ngũ chìm trong tình trạng mệt mỏi cảnh báo.

Độ trễ: thời gian xử lý các yêu cầu. Theo dõi phân phối, không phải trung bình. p50 (trung vị) mô tả trải nghiệm điển hình. p99 mô tả 1% người dùng tệ nhất. Trung bình đơn thuần che giấu các đuôi dài: một dịch vụ có trung vị 50 ms và p99 5.000 ms trông ổn trên trung bình nhưng làm hỏng trải nghiệm của một người dùng trong số một trăm.

Lưu lượng: nhu cầu đối với dịch vụ. Với dịch vụ web, đây là số yêu cầu mỗi giây. Với dịch vụ phát trực tuyến, là số kết nối đồng thời. Với công việc hàng loạt, là số mục được xử lý mỗi phút. Lưu lượng tương quan với các quyết định về dung lượng và tiết lộ các bất thường trong khối lượng công việc.

Lỗi: tỷ lệ các yêu cầu thất bại. Các lỗi rõ ràng (HTTP 500), lỗi ngầm (HTTP 200 với dữ liệu bị hỏng), và lỗi chính sách (phản hồi quá chậm so với SLO) đều được tính. Việc phân biệt giữa các loại này rất quan trọng: một mã 200 với payload xấu thường gây hại cho người dùng nhiều hơn một mã 500 trung thực.

Độ bão hòa (Saturation): mức độ đầy tải của hệ thống. Tỷ lệ sử dụng CPU, độ sâu hàng đợi, áp lực bộ nhớ, mức chiếm dụng pool kết nối. Độ bão hòa dự đoán độ trễ trong tương lai: một hệ thống chạy ở 95% CPU gần như không còn dư địa trước khi độ trễ người dùng tăng đột biến.

Hầu hết các cảnh báo SRE đều xuất phát từ bốn tín hiệu này. Cảnh báo dựa trên triệu chứng (cảnh báo khi người dùng nhận thấy) hiệu quả hơn cảnh báo dựa trên nguyên nhân (cảnh báo khi CPU vượt 80%). Bốn tín hiệu vàng mô tả các triệu chứng.

Lộ Trình Nghề Nghiệp SRE

Nơi Kỹ Năng SRE Được Đánh Giá Cao

Sự nghiệp SRE phân nhánh tùy theo phần nào của lĩnh vực mà kỹ sư yêu thích nhất:

SRE Hạ tầng: xây dựng nền tảng mà các đội khác chạy trên đó. Kubernetes, service mesh, cloud nội bộ. Công việc đòi hỏi kỹ thuật hệ thống sâu, lý thuyết hệ thống phân tán và thiết kế nền tảng. Mức lương rất cao tại các công ty lớn vì công việc có khả năng mở rộng: một SRE hạ tầng hỗ trợ hàng trăm kỹ sư sản phẩm.

SRE Nhúng: làm việc song song với đội kỹ sư sản phẩm để cải thiện độ tin cậy của một dịch vụ cụ thể. Nửa kỹ sư, nửa huấn luyện viên. Kỹ năng giao tiếp và review code quan trọng không kém chiều sâu kỹ thuật. Thường là con đường tốt nhất cho những kỹ sư thích giảng dạy.

Công cụ Độ tin cậy: xây dựng hệ thống quan sát: giám sát, cảnh báo, bảng điều khiển, công cụ phân tích sau sự cố, nền tảng quản lý sự cố. Công việc nặng về frontend và kỹ thuật dữ liệu. Kết quả được sử dụng bởi mọi đội khác.

Kỹ thuật Production: thuật ngữ của Facebook/Meta cho SRE tập trung vào dung lượng, triển khai và quản lý lưu lượng. Công việc nặng về mạng và hệ thống.

Các chứng chỉ kỹ thuật đáng có: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional và các chứng chỉ CNCF (Kubernetes Administrator, Kubernetes Application Developer) thể hiện sự thành thạo về cloud-native. Các chứng chỉ của Linux Foundation thể hiện chiều sâu về hệ thống. Không chứng chỉ nào thay thế được công việc portfolio, nhưng chúng giúp vượt qua các vòng sàng lọc của nhà tuyển dụng.

Tổng Kết

Những Gì Bạn Đã Biết

Kỹ thuật độ tin cậy trang web bắt đầu như giải pháp của Google cho vấn đề mở rộng quy mô và đã phát triển thành một ngành nghề hiện được áp dụng rộng rãi trong ngành. Bạn đã tìm hiểu về:

- Sự chuyển dịch từ vận hành thủ công sang độ tin cậy được thiết kế

- SLI, SLO, SLA và khái niệm ngân sách lỗi (error budget) là nghịch đảo của SLO

- Định nghĩa toil, quy tắc 50% và việc giảm toil thông qua kỹ thuật

- Các ca trực bền vững và thực hành phân tích sự cố không đổ lỗi

- Bốn tín hiệu vàng (golden signals) như điểm khởi đầu cho giám sát dịch vụ

- Các lộ trình sự nghiệp SRE và các chứng chỉ mở ra cơ hội

Hai ý tưởng quan trọng nhất. Độ tin cậy là một con số, được thống nhất trước. Và toil là một khiếm khuyết, không phải mô tả công việc. Giữ hai ý tưởng này và phần còn lại của SRE sẽ tự nhiên đi theo.

Tài liệu khuyến nghị: Sách SRE của Google (miễn phí trực tuyến: sre.google/books/), Sổ tay SRE để thực hành, và các bài viết của Charity Majors về khả năng quan sát. Bài học hình học-đồng hành đi sâu hơn về cấu trúc trực quan bên dưới thực tiễn SRE: phân phối độ trễ, hình nón ngân sách lỗi, đồ thị phụ thuộc và bố cục bảng điều khiển.