SRE (Site Reliability Engineering) là gì?
Một chuyện rất thường xảy ra trong các công ty là các nhóm phát triển (development teams) và nhóm vận hành (operation teams) luôn có những mâu thuẫn với nhau. Các nhóm phát triển muốn thêm các tính năng mới hấp dẫn vào sản phẩm. Các nhóm vận hành muốn đảm bảo rằng các tính năng này không gây rối loạn hay phá hỏng chương trình.
Chuyện này bắt đầu thay đổi vào năm 2003 khi kỹ sư phần mềm Benjamin Treynor phát minh ra kỹ thuật độ tin cậy của trang web (site reliability engineering- SRE) khi làm việc tại Google. Benjamin đã yêu cầu nhóm kỹ sư phần mềm của mình chịu trách nhiệm về một số nhiệm vụ liên quan đến vận hành, tạo ra khái niệm về SRE và giúp giải quyết các vấn đề giữa phát triển và vận hành.
SRE hoạt động thế nào?
SRE được thực hiện bởi các kỹ sư độ tin cậy trang web (site reliability engineer), còn được gọi là kỹ sư độ tin cậy dịch vụ. Những chuyên gia này thường là những nhà phát triển phần mềm đã có được một số kinh nghiệm vận hành. Họ cũng có thể là các chuyên gia IT có các kỹ năng xây dựng phần mềm.
Các nhóm SRE thiết lập các thỏa thuận mức dịch vụ (SLA – Service Level Agreement) cho mỗi dịch vụ trong hệ thống. SLA xác định độ tin cậy cần thiết của hệ thống, giúp các nhóm tìm ra những tính năng mà họ có thể triển khai.
Trong mỗi SLA là các chỉ số mức dịch vụ (SLI – service level indicators) và mục tiêu mức dịch vụ (SLO – service level objectives).
SLI là các chỉ số đo lường một khía cạnh cụ thể của cấp độ dịch vụ. Ví dụ về SLI mà bạn có thể muốn theo dõi có thể là tính khả dụng, tỷ lệ lỗi hoặc hiệu năng của hệ thống.
SLO chỉ đơn giản là mục tiêu bạn muốn đạt được để đạt được SLI. Ví dụ: mục tiêu là đạt được 99,8% khả dụng của một hệ thống trong suốt một năm.
Sự khác biệt là mức thời gian chết. Mức thời gian ngừng hoạt động được gọi là ngân sách lỗi (error-budget), là số lỗi tối đa cho phép trong hệ thống.
Bằng cách thừa nhận lỗi là không thể tránh khỏi, sau đó bạn có thể lập kế hoạch cho các lỗi, giúp nhóm phát triển phát hành các tính năng mới dễ dàng hơn. Hãy xem, nhóm phát triển có thể phát hành bất kỳ tính năng nào họ muốn, bất cứ khi nào họ muốn, miễn là chúng nằm trong phạm vi ngân sách lỗi. Ngay khi bước ra ngoài, họ phải chịu lỗi trước khi tiếp tục với các tính năng mới.
Một phần quan trọng trong công việc của Site Reliability Engineering là tự động hóa. Các SRE thường phải tự động hóa các công việc thủ công lặp đi lặp lại, được gọi là toil (công việc nặng nhọc) , để họ có thể tập trung vào công việc lâu dài, gia tăng giá trị.
Khác nhau giữa DevOps và SRE
DevOps là một triết lý và tập hợp các thực hành kết hợp phát triển phần mềm và các hoạt động IT. Nó bao gồm năm trụ cột. Google định nghĩa các trụ cột này là:s:
- Giảm rào cản silo trong tổ chức
- Chấp nhận thất bại
- Thực hiện các thay đổi dần dần
- Tận dụng công cụ và tự động hóa
- Đo lường mọi thứ
Nếu DevOps là Cái gì (What), thì SRE là Thế nào (How) . Nó chỉ đơn giản là một cách triển khai triết lý DevOps. Trên thực tế, SRE đáp ứng tất cả năm trụ cột của DevOps:
- Giảm rào cản silo trong tổ chức: SRE chia sẻ quyền sở hữu với các nhà phát triển và họ sử dụng các công cụ và kỹ thuật giống nhau.
- Chấp nhận thất bại: SREs định lượng thất bại bằng cách sử dụng SLI và SLO. Họ cho rằng lỗi sẽ xảy ra, nhưng hãy đặt số lượng lỗi tối đa cho phép để cân bằng thất bại so với các bản phát hành mới.
- Thực hiện các thay đổi dần dần: SRE khuyến khích triển khai nhỏ hơn, lặp đi lặp lại các tính năng mới để giảm chi phí thất bại.
- Tận dụng công cụ và tự động hóa: SREs tự động hóa các tác vụ thủ công, như đã đề cập ở trên.
- Đo lường mọi thứ: SRE sử dụng số liệu (SLI) để định lượng mức độ dịch vụ. Do đó, họ có thể giảm số lượng lỗi.
Lợi ích của SRE:
Cung cấp các chỉ số rõ ràng
Các chỉ số (metrics) rõ ràng cho phép các nhóm SRE nêu bật các lĩnh vực cần cải thiện, chẳng hạn như giảm các lỗ hổng bảo mật.
Các nhóm SRE cũng có thể sử dụng các số liệu để tính toán tác động trong các lĩnh vực khác, chẳng hạn như doanh thu. Ví dụ: họ có thể xem họ mất bao nhiêu doanh thu mỗi phút thời gian ngừng hoạt động.
Cải thiện code
Các nhóm phát triển và SRE chia sẻ cùng một nguồn nhân lực. Nếu nhóm phát triển viết code kém, thì sẽ có nhiều nhận lực hơn cần được phân bổ cho các SRE để khắc phục những vấn đề này. Và như vậy, để lại ít người hơn cho nhóm phát triển.
Do đó, nhóm phát triển được khuyến khích viết code tốt hơn. Khi code của họ hoạt động tốt, họ có thể có thêm đồng đội, mang lại cho họ những tài nguyên cần thiết để tạo ra các tính năng tốt hơn.
Giải phóng thời gian và tài nguyên để tăng giá trị
Mã tốt hơn, ít lỗi hơn và hiệu quả hơn tạo ra nhiều thời gian hơn để tăng giá trị cho sản phẩm. Các nhà phát triển có thể tạo ra các tính năng tốt hơn và thú vị hơn mà ít gây ra sự cố hơn. Mặt khác, team vận hành có thể dành nhiều thời gian hơn để kiểm tra và thực hiện bảo trì. Kết hợp những thứ này lại với nhau và bạn có một sản phẩm tốt hơn cho khách hàng.
Kết luận
Site Reliability Engineering đang nhanh chóng trở thành một phần thiết yếu của nhiều công ty. SRE có thể giúp thu hẹp khoảng cách giữa vận hành và phát triển. Do đó, bạn có thể cung cấp các ứng dụng tốt hơn nhanh hơn mà không làm giảm độ tin cậy của các ứng dụng đó.
