Quá trình tiến hóa của SRE tại Google

• Sản phẩm của Google được hàng tỉ người dùng trên toàn cầu sử dụng, nên việc chúng hoạt động ổn định là rất quan trọng. Nhóm SRE của Google đã phát triển nhiều phương pháp để nâng cao độ tin cậy của dịch vụ.
• Các kỹ thuật SRE truyền thống (như error budget, postmortem) đã đóng góp lớn trong việc giúp Google mở rộng quy mô dịch vụ web.
• Gần đây, khi AI/ML làm độ phức tạp hệ thống tăng vọt, việc cần có cách tiếp cận mới đã trở nên cấp thiết.
• Lý thuyết hệ thống và lý thuyết điều khiển hữu ích cho việc nắm bắt có hệ thống các tương tác phức tạp.
• Thay vì chỉ "giải quyết sau khi sự cố xảy ra", cần một hướng tiếp cận đảm bảo an toàn ngay từ thiết kế nền tảng ở cấp hệ thống.

Tổng quan về STAMP

• STAMP (System-Theoretic Accident Model and Processes) do Giáo sư Nancy Leveson (MIT) đề xuất phân tích tai nạn (sự kiện) từ góc nhìn tương tác hệ thống phức tạp hơn là lỗi riêng của một bộ phận.
• Thay vì nhân quả truyền thống ("bị lỗi nên hỏng"), STAMP nhấn mạnh rằng điều quan trọng là: "toàn bộ hệ thống đã rơi vào luồng điều khiển sai như thế nào".
• Mô hình phân tích nhân quả dựa trên lý thuyết hệ thống (CAST) tái cấu trúc sự cố, và Phân tích quá trình theo lý thuyết hệ thống (STPA) giúp nhận diện trước các yếu tố rủi ro.

Nền tảng của lý thuyết điều khiển – bốn điều kiện

• Trong lý thuyết điều khiển, cần bốn điều kiện để kiểm soát có hiệu quả:
  • Điều kiện mục tiêu: phải có mục tiêu (ví dụ: duy trì một chỉ số cụ thể).
  • Điều kiện hành vi: phải có khả năng tác động lên trạng thái hệ thống để đạt mục tiêu.
  • Điều kiện mô hình: cần các mô hình (nội tại và bên ngoài) để hiểu hệ thống.
  • Điều kiện quan sát: cần cơ chế quan sát như cảm biến để xác định trạng thái hiện tại của hệ thống.

Xử lý sự cố (Outage) như một bài toán điều khiển

• Trước đây, xu hướng mô tả sự cố thường nghiêng về "hỏng đứt dây chuyền".
• STAMP diễn giải nó dưới góc nhìn "điều khiển và tương tác không phù hợp", từ đó đảm bảo an toàn ở cấp hệ thống.
• Thay vì chỉ tìm "sự cố đầu tiên bắt đầu từ đâu", STAMP xem xét toàn diện "luồng điều khiển/phản hồi nào bị bất thường".

Giành thêm thời gian từ trạng thái Hazard

• Mô hình nhân quả truyền thống cho rằng hệ thống chuyển từ trạng thái bình thường sang trạng thái sự cố trong tích tắc, nên thời gian ứng phó rất ngắn.
• STAMP đưa vào khái niệm "trạng thái hazard" để tìm điểm đã bước vào nguy cơ trước khi thành sự cố hoàn chỉnh.
• Sau khi phát hiện trạng thái hazard và can thiệp tích cực, có thêm cơ hội ngăn chặn trước khi chuyển thành sự cố thực sự.

Xem xét qua trường hợp thực tế

• Trong Google, "Quota Rightsizer" tái phân bổ tài nguyên theo lượng dùng của dịch vụ.
• Theo góc nhìn STPA, có thể nhận diện sớm tình huống "nhận sai thông tin mức sử dụng, rồi giảm tài nguyên thấp hơn mức cần thiết thực tế".
• Ở giai đoạn thiết kế, chủ yếu chỉ chú ý đến "logic điều khiển chính xác", nhưng khi áp dụng STPA đã phát hiện vấn đề trong đường phản hồi (như quá trình tính toán mức tiêu thụ tài nguyên).
• Có trường hợp thực tế năm 2021 cho thấy phản hồi sai tích lũy rồi dẫn đến sự cố lớn, nhưng đã ở trạng thái hazard trong vài tuần mà không biết.

Hướng đi tiếp theo

• Google SRE theo đuổi mức an toàn cao hơn và quản lý độ phức tạp tốt hơn bằng các cách tiếp cận dựa trên lý thuyết hệ thống như STAMP, STPA và CAST.
• Chỉ với đầu tư kỹ thuật quy mô nhỏ (khoảng vài tuần), đã có thể phát hiện rất nhiều kịch bản rủi ro tiềm ẩn trong hệ thống lớn.
• Nếu bổ sung phân tích dựa trên lý thuyết điều khiển vào văn hóa độ tin cậy truyền thống, khả năng cung cấp dịch vụ ổn định trong kỷ nguyên AI/ML sẽ tăng cao hơn.

[GN⁺]

Ý kiến trên Hacker News

• Cách tiếp cận kỹ thuật của Google có thể bất lợi cho startup. Các kỹ sư SRE có xu hướng mắc hội chứng nhân vật trung tâm và muốn thiết kế lại cách các nhóm khác triển khai kỹ thuật.

  • Điều này giống với việc phòng pháp chế cố gắng điều hành cả công ty.

• Có những điểm tương đồng với cuốn sách của Sidney Dekker.

  • Nó đánh giá toàn bộ hệ thống và xem xét trạng thái nhận thức của những người tham gia sự cố, để phân tích vì sao họ tin rằng đã đưa ra quyết định đúng.
  • Giải thích cách những thay đổi độc lập trong hệ thống phức tạp có thể tác động đến an toàn.

• Phương pháp CAST có vẻ rất thuyết phục.

  • Nó cần nhiều phân tích về lỗi và gần lỗi; và phần khó nhất khi triển khai là con người.

• Có những tương đồng thú vị giữa CAST và việc phân tích cơ học.

  • Nó cung cấp một khung để phân tích cách các thành phần của hệ thống tương tác với nhau.

• Tôi tự hỏi đã có trường hợp nào áp dụng khung kỹ thuật an toàn chính quy cho phân tích mạng nơ-ron chưa.

  • Theo dõi quan hệ nhân quả phức tạp và hành vi ở cấp hệ thống có thể hữu ích.

• Ngay cả khi ví dụ "rightsizer" được phân tích theo cách truyền thống, họ có thể vẫn đạt cùng một kết quả.

  • Nhưng cách tiếp cận mới dễ làm hơn và khả thi hơn.

• Lý do họ không thích kiểm thử phần mềm là vì lỗi do các yếu tố bên ngoài.

  • Cách tiếp cận này có thể giúp giải quyết vấn đề đó.

• CAST tương tự như phân tích nguyên nhân gốc rễ đa yếu tố.

  • Ủng hộ CAST của giáo sư Nancy Leveson tại MIT.

• Có ý kiến cho rằng SRE/DevOps là một phần của công việc hằng ngày hay không.

  • Trong nhiều trường hợp, tôi nghĩ đây chỉ là việc đổi tên lại vai trò vận hành hiện có.

• Đặc điểm nổi bật lớn nhất của Google SRE là khi sản phẩm mới ra mắt thì cần có sự hỗ trợ của SRE.

  • Việc chỉ có số lượng SRE hạn chế lại khiến những ý tưởng hay trở nên tốt hơn.

• Bài viết quá dài nên khó tìm ra điểm mấu chốt.

  • Những đề cập tới CAST và STPA là phần đáng giá và quan trọng nhất.

• Tò mò liệu cách tiếp cận này có giá trị ở quy mô ngoài FAANG hay không.

  • Có khuynh hướng đầu tư rất nhiều vào việc tránh rủi ro.

• Tương tự như DevOps, phạm vi của SRE đang được mở rộng.

  • SRE đang gánh nhiều vai trò, từ viết phần mềm đến xử lý sự cố hệ thống.