SRE và DevOps: Cạnh tranh hay Hỗ trợ lẫn nhau? – Cuongquach.com | DevOps và SRE là hai ngành có nhiều khía cạnh tương đồng, thậm chí là chồng chéo nhau, dễ gây nhầm lẫn. Trước đây, nhiều người cho rằng SRE cạnh tranh với DevOps. Nhưng thật sự hai lĩnh vực này hỗ trợ cho nhau, và bài viết này sẽ chứng minh điều đó.
Contents
1. Sự khác biệt giữa DevOps và SRE
Vài nét về DevOps
Trước đây, Developer chỉ tập trung viết code; vận hành chúng là nhiệm vụ của bộ phận Operation. Chuyên môn hóa như vậy sẽ giúp nâng cao hiệu suất của cả hai phòng ban, nhưng lại dễ nảy sinh mâu thuẫn do mỗi nhóm đều có những ưu tiên và mục đích công việc riêng. DevOps ra đời nhằm giải quyết vấn đề này.
Một kỹ sư DevOps phải là người thành thạo cả phát triển lẫn vận hành, để công việc được phối hợp nhịp nhàng. Tuy nhiên, khái niệm DevOps khá trừu tượng, vì thông thường DevOps chỉ ra phương hướng hành động của một tập thể, nhưng thực hiện nó như thế nào là việc của từng cá nhân.
Vài nét về SRE
Thuật ngữ SRE xuất hiện sau DevOps. Cụ thể là vào đầu những năm 2000, SRE được Google khởi động nhằm đáp ứng các nhu cầu nội bộ. Tuy độc lập với văn hóa DevOps nhưng “tình cờ” cả hai đều hướng đến cùng một lý tưởng. Điểm khác là SRE có vạch ra phương pháp đo lường cũng như đạt được độ tin cậy cao hơn thông qua điều phối các kỹ thuật phát triển và vận hành. Nói cách khác, SRE hướng dẫn cách thành công trong từng lĩnh vực DevOps khác nhau. Để hiểu rõ hơn, mời bạn xem qua bảng thống kê dưới đây.
Nói tóm lại, DevOps và SRE không phải là hai đối thủ cạnh tranh, mà chúng bổ sung, hỗ trợ lẫn nhau phá vỡ các rào cản trong tổ chức, nhằm cung cấp phần mềm tốt hơn, nhanh hơn.
2. SLI, SLO và SLA
Tại Google, khái niệm về SRE bắt đầu với ý tưởng rằng các số liệu nên được gắn chặt với mục tiêu kinh doanh và được đo lường bằng các chỉ số SLI, SLO và SLA. Những công cụ này cho biết hệ thống có đáng tin cậy, sẵn sàng và hữu ích hay không.
• SLI (Service-Level Indicator) – Chỉ số cấp độ dịch vụ là các thông số theo thời gian như độ trễ của request, thường được đo lường bằng đơn vị request/giây hoặc số lỗi/request, sau đó chuyển đổi thành tỷ lệ, trung bình hoặc tỷ lệ phần trăm.
• SLO (Service-Level Objective) – Mục tiêu cấp độ dịch vụ là mục tiêu được các bên liên quan đặt ra để đánh giá kết quả của SLI trong khoảng thời gian nhất định (như “30 ngày qua” hoặc “trong một quý”).
• SLA (Service-Level Agreement) – Thỏa thuận cấp độ dịch vụ là lời hứa của nhà cung cấp với khách hàng về tính khả dụng của dịch vụ và trách nhiệm nếu không đáp ứng được.
3. Ngân sách rủi ro và lỗi
Phần này đề cập đến việc đo lường rủi ro của việc thành lập “ngân sách lỗi”. Khái niệm ngân sách lỗi (error budget) ở đây chỉ những thỏa thuận của team SRE và chủ sở hữu sản phẩm để cân bằng giữa việc phát triển tính năng sản phẩm đó với việc đảm bảo tính khả dụng của nó.
Đôi khi, việc tối đa hóa sự ổn định của hệ thống là vô nghĩa và phản tác dụng. Vì nếu đặt mục tiêu độ tin cậy không phù hợp sẽ ảnh hưởng đến tốc độ phát triển sản phẩm. Trên thực tế, người dùng thường không đánh giá được độ khả dụng của sản phẩm, mặc dù mức độ có thể đạt tới 99.99999%. Bởi vì chất lượng trải nghiệm còn phụ thuộc vào nhiều yếu tố như ISP, mạng di động hoặc WiFi…
Vậy nên, thông thường có hai kịch bản có thể xảy ra:
- Một là, chủ sở hữu muốn cung cấp nhiều tính năng mới sẽ chọn các SLO ít nghiêm ngặt hơn để tiếp tục vận hành khi xảy ra lỗi.
- Hai là, họ muốn tập trung vào độ tin cậy sẽ chọn SLO cao hơn, nhưng chấp nhận rằng việc phá vỡ SLO đó sẽ trì hoãn việc phát hành tính năng. SRE định lượng rủi ro này dưới dạng “ngân sách lỗi”. Khi ngân sách lỗi bị cạn kiệt, trọng tâm sẽ chuyển từ phát triển tính năng sang cải thiện độ tin cậy.
4. Toil và toil budget
Một yếu tố quan trọng khác trong nguyên tắc hoạt động của SRE là toil và toil budget. Toil ở đây không chỉ đơn giản là “công việc bạn không muốn làm”. Mà toil thường nảy sinh ở các vị trí gắn liền với vận hành quy trình sản xuất, đối với những công việc có tính thủ công, lặp đi lặp lại và không có giá trị lâu dài. Hơn nữa, toil còn có xu hướng mở rộng khi dịch vụ phát triển.
Để giảm thiểu toil, đội ngũ SRE thường chú trọng nâng cao kỹ thuật, tập trung nghiên cứu cách để tự động hóa nó. Tuy việc giảm thiểu toil là rất quan trọng, nhưng thực tế, chúng ta không thể loại bỏ nó hoàn toàn. Dù vậy, chúng ta có thể tận dụng toil để “lên dây cót” cho một nhân viên mới. Bởi vì toil thường là những công việc dễ dự đoán và lặp đi lặp lại, họ sẽ ít cảm thấy căng thẳng khi thực hiện.
5. CRE – Customer Reliability Engineering – Kỹ sư độ tin cậy khách hàng
Yếu tố cuối cùng, CRE – được xem là công cụ để thực hiện các nguyên tắc của SRE. Trước đây, Google không chủ trương phổ biến SRE vì họ cho rằng, SRE tạo nên lợi thế cạnh tranh cho Google. Tuy nhiên, mỗi khi hệ thống của khách hàng gặp sự cố, họ lại phải ngừng việc phát triển và đổi mới để giải quyết vấn đề. Đó có thể chỉ là một lỗi nhỏ đối với một khách hàng, nhưng trên quy mô thế giới, là hàng tỷ người dùng. Đội ngũ SRE của Google nhận thấy, rõ ràng đã đến lúc cần phải phổ biến SRE cho các khách hàng của mình.
Do đó, vào năm 2016, Google đã triển khai chương trình CRE vừa giúp khách hàng của Google Cloud Platform (GCP) cải thiện độ tin cậy của họ, vừa đưa Google SRE tiếp cận gần hơn với các vấn đề khách hàng thường gặp phải.
Nguồn: https://cuongquach.com/
