Những bài học Google rút ra sau 20 năm làm Site Reliability Engineering (SRE)

20 năm bài học rút ra từ Site Reliability Engineering (SRE)

Những bài học về kỹ thuật độ tin cậy học được từ YouTube

• Lựa chọn biện pháp giảm thiểu rủi ro

  • Khi xảy ra lỗi nghiêm trọng, cần chọn biện pháp giảm thiểu rủi ro tương xứng với mức độ nghiêm trọng của lỗi đó.
  • Biện pháp giảm thiểu quá mức có thể gây ra tác dụng phụ, và chỉ nên làm như vậy khi có lý do chính đáng để bỏ qua quy trình tiêu chuẩn.

• Kiểm thử cơ chế phục hồi để chuẩn bị cho tình huống khẩn cấp

  • Cần luyện tập và kiểm thử đầy đủ trước đối với các cơ chế phục hồi và biện pháp giảm thiểu để có thể ứng phó hiệu quả ngay cả trong tình huống nguy cấp.
  • Thông qua kiểm thử, có thể giảm rủi ro trong tương lai và cải thiện năng lực ứng phó.

• Triển khai thay đổi theo từng bước (áp dụng canary test)

  • Trước khi triển khai thay đổi trên diện rộng, cần đưa vào dần dần để khi có sự cố phát sinh sẽ không ảnh hưởng đến toàn bộ hệ thống.
  • Qua trường hợp thay đổi cấu hình cache của YouTube, người ta nhận ra rằng ngay cả thay đổi nhỏ cũng cần được đưa vào một cách có hệ thống.

Những bài học rút ra từ Google Calendar

• Tầm quan trọng của chức năng dừng khẩn cấp

  • Cần có một chức năng như "nút đỏ lớn" để có thể phản ứng nhanh với các thay đổi tiềm ẩn rủi ro.
  • Cần chuẩn bị chức năng dừng khẩn cấp để đối phó với các phụ thuộc của dịch vụ.

• Sự cần thiết của kiểm thử tích hợp

  • Kiểm thử đơn vị hữu ích trong phạm vi hạn chế, nhưng cần xác minh sự phù hợp của hệ thống bằng kiểm thử tích hợp gắn với môi trường thực tế.
  • Từ trường hợp lỗi của Google Calendar, người ta nhận ra tầm quan trọng của việc kiểm thử theo đúng luồng sử dụng thực tế.

Bài học của Google năm 2017

• Tầm quan trọng của kênh liên lạc cho tình huống khẩn cấp

  • Cần chuẩn bị các kênh liên lạc và kênh dự phòng.
  • Khi dịch vụ bị gián đoạn, cần có nhiều phương thức liên lạc không phụ thuộc lẫn nhau và phải kiểm thử hiệu quả của chúng.

• Duy trì chức năng tối thiểu khi hiệu năng suy giảm

  • Cần thiết kế để dịch vụ không bị ngừng hoàn toàn, mà vẫn có thể cung cấp các chức năng cơ bản ngay cả trong trạng thái hiệu năng suy giảm.

Kiểm thử khả năng phục hồi trước thảm họa

• Kiểm thử khả năng phục hồi và tính chống chịu trước thảm họa
  • Cần kiểm thử khả năng chống chịu của dịch vụ hoặc hệ thống để bảo đảm tính bền vững ngay cả trong tình huống thảm họa.
  • Thông qua kiểm thử phục hồi, cần xác nhận hệ thống có thể trở lại trạng thái bình thường sau khi bị gián đoạn hay không.

Tầm quan trọng của các biện pháp giảm thiểu tự động hóa

• Tự động hóa biện pháp giảm thiểu
  • Khi xảy ra sự cố đa mạng, thay vì xử lý thủ công, cần rút ngắn thời gian giải quyết vấn đề bằng các biện pháp giảm thiểu được tự động hóa.

Rút ngắn thời gian giữa các lần triển khai

• Thực hiện rollout thường xuyên

  • Khoảng trễ thời gian dài giữa các lần rollout là yếu tố để đánh giá độ an toàn của hệ thống.

• Một phiên bản phần cứng toàn cầu duy nhất là một điểm lỗi đơn

  • Việc chỉ phụ thuộc vào một mẫu cụ thể có thể giúp đơn giản hóa vận hành, nhưng nếu mẫu đó gặp vấn đề thì việc thực hiện các chức năng quan trọng có thể bị gián đoạn.
  • Sự tồn tại của nhiều network backbone khác nhau giúp ngăn chặn sự cố gián đoạn trên diện rộng và cho phép định tuyến lưu lượng ưu tiên cao sang các phương án thay thế vẫn còn hoạt động.