Quá trình phát triển của SRE tại Google

• SRE của Google đã giảm sự cố ngay cả khi quy mô dịch vụ tăng lên, nhưng nhận thấy các phương pháp hiện có là chưa đủ đối với những tổn thất phải tuyệt đối phòng ngừa như xâm phạm quyền riêng tư hay mất dữ liệu, nên đã áp dụng STAMP
• STAMP tập trung vào tương tác hệ thống và thất bại trong kiểm soát hơn là lỗi của từng thành phần riêng lẻ; CAST được dùng để điều tra sự cố, còn STPA được dùng để phân tích rủi ro
• Mô hình luồng dữ liệu và chuỗi nguyên nhân tuyến tính ngày càng bộc lộ giới hạn phân tích trước các sơ đồ RPC có hơn 100 nút, mô hình kiến trúc lỗi thời và yêu cầu bị thiếu
• Trong sự cố nội bộ năm 2021 với quota rightsizer, phản hồi sai về mức sử dụng tài nguyên và pending change không được truyền đạt đã khiến hệ thống ở trạng thái rủi ro trong nhiều tuần, cuối cùng dẫn đến sự cố
• Google đang đầu tư nỗ lực ở quy mô engineer-weeks cho phân tích STPA để tìm ra hàng trăm kịch bản, đồng thời mở rộng phạm vi SRE sang thiết kế an toàn cho Google Cloud, mạng nội bộ và nhiều sản phẩm

---

Những giới hạn mà phương pháp SRE hiện có gặp phải

• Các sản phẩm của Google được hàng tỷ người trên toàn thế giới sử dụng mỗi ngày; trong 25 năm qua, quy mô dịch vụ đã tăng mạnh nhưng sự cố lại trở nên hiếm hơn
• SRE từ trước đến nay đã mở rộng độ tin cậy bằng SLO, ngân sách lỗi, chiến lược cô lập, phân tích hậu sự cố kỹ lưỡng và triển khai dần dần
• Thách thức hiện nay không chỉ là giảm tần suất sự cố, mà là xử lý những tổn thất phải được ngăn chặn ngay từ đầu
  • Xâm phạm quyền riêng tư
  • Mất dữ liệu
  • Không đáp ứng yêu cầu tuân thủ quy định
• Ngân sách lỗi truyền thống nhìn chung phù hợp với các dịch vụ web có ít trạng thái, nhưng chưa đủ để xử lý những tổn thất gần như có ngân sách lỗi bằng 0
• Khi AI và ML trở thành lõi của hầu hết sản phẩm, và tự động hóa giúp đạt được khả năng mở rộng, chi phí và hiệu quả năng lượng cũng trở nên quan trọng như các tính năng dành cho người dùng

Cấu trúc của tư duy SRE hiện có

• Phân tích rủi ro truyền thống gồm ba yếu tố chính
  • Cách mô hình hóa hệ thống
  • Lý thuyết nguyên nhân giải thích cách vấn đề xảy ra
  • Thuật toán tìm kiếm để phát hiện rủi ro
• Cách tiếp cận hiện có của SRE tại Google chưa được chính thức hóa thành một lý thuyết tường minh, nhưng đã phân tích rủi ro xoay quanh kiến trúc phần mềm và mô hình luồng dữ liệu
• Mô hình luồng dữ liệu cho thấy các yêu cầu mạng hoặc dữ liệu di chuyển giữa các phần khác nhau của hệ thống như thế nào
• Mô hình này tự nhiên dẫn đến suy luận nguyên nhân-kết quả tuyến tính
  • Xem SLO của từng thành phần để hiểu các bảo đảm về độ tin cậy
  • Kiểm tra xem chúng có đáp ứng hoặc vượt yêu cầu của bên gọi hay không
• Trong phân tích hậu sự cố, phương pháp suy luận quy nạp được dùng để rút ra các mẫu hình chung từ từng sự kiện riêng lẻ
  • Không dừng lại ở việc sửa một sự kiện, mà tìm cách ngăn toàn bộ nhóm sự kiện cùng loại
  • Cố gắng loại bỏ nguyên nhân vấn đề bằng cách chuyển các cảnh báo lặp lại thành giải pháp kỹ thuật

Giới hạn của mô hình luồng dữ liệu và phân tích nguyên nhân tuyến tính

• Khi độ phức tạp của hệ thống tăng qua từng năm, mô hình luồng dữ liệu ngày càng khó gánh được mức độ phức tạp ở quy mô Google
• Sơ đồ RPC và mô hình kiến trúc phần mềm sẽ trở nên quá phức tạp nếu không dùng các mức trừu tượng một cách nhất quán, và thường vẫn ở trạng thái không đầy đủ hoặc đã lỗi thời
• Những mô hình này không thể hiện đầy đủ động lực học của hệ thống
  • RPC nào có thể khởi tạo luồng
  • Lỗi lan truyền như thế nào
  • Thành phần nào có thể tạo ra sự cố nghiêm trọng, và thành phần nào chỉ có thể tạo ra vấn đề nhỏ
  • Một tương tác cụ thể có an toàn trong ngữ cảnh này nhưng không an toàn trong ngữ cảnh khác hay không
  • Mục tiêu tổng thể của hệ thống là gì
  • Mỗi thành phần chịu trách nhiệm gì đối với mục tiêu tổng thể
• Sơ đồ luồng dữ liệu có hơn 100 nút đã áp đảo ngay từ điểm khởi đầu của việc tìm kiếm khiếm khuyết
• Nếu yêu cầu an toàn bị thiếu hoặc sai ngay ở giai đoạn định nghĩa yêu cầu, hệ thống vẫn có thể mất an toàn dù thiết kế triển khai hoàn hảo các yêu cầu đó
• Cách học từ dữ liệu sự cố có giới hạn trong việc dự đoán và ngăn chặn những tổn thất chưa từng xảy ra

STAMP thay đổi cách tư duy như thế nào

• SRE của Google tiếp nhận lý thuyết hệ thống và lý thuyết điều khiển, đồng thời áp dụng khung STAMP do Nancy Leveson tại MIT phát triển
• STAMP xem tai nạn không phải là chuỗi lỗi của các thành phần, mà là kết quả của việc kiểm soát hệ thống không hoạt động đầy đủ
• CAST được dùng để điều tra sau tai nạn, còn STPA được dùng để phân tích rủi ro
• STAMP xem an toàn không phải là thuộc tính của từng thành phần riêng lẻ, mà là thuộc tính nổi lên ở cấp hệ thống
• Câu hỏi phân tích cũng thay đổi
  • Câu hỏi hiện có: Dịch vụ phần mềm nào đã thất bại?
  • Câu hỏi của STAMP: Những tương tác nào giữa các phần của hệ thống chưa được kiểm soát đầy đủ?
• Nhiều tai nạn trong hệ thống phức tạp có thể là kết quả của việc từng thành phần đều hoạt động đúng thiết kế, nhưng khi kết hợp lại tạo ra trạng thái không an toàn

Bốn điều kiện của lý thuyết điều khiển

• Các điều kiện kiểm soát trong 『An Introduction to Cybernetics』 của W.R. Ashby được tích hợp vào phương pháp STAMP của Leveson
• Để kiểm soát một quy trình, cần bốn điều kiện
  • Điều kiện mục tiêu: Bộ điều khiển phải có mục tiêu
  • Điều kiện hành động: Bộ điều khiển phải có khả năng tác động đến trạng thái hệ thống
  • Điều kiện mô hình: Bộ điều khiển phải có mô hình của hệ thống
  • Điều kiện khả năng quan sát: Bộ điều khiển phải có khả năng nắm bắt trạng thái hệ thống
• Trong thực hành SRE, có thể dùng các điều kiện này làm tiêu chí để xác định những yếu tố cần thiết nhằm kiểm soát hiệu quả các hệ thống phức tạp

Khoảng ứng phó do trạng thái rủi ro tạo ra

• Mô hình chuỗi nguyên nhân tuyến tính thường chỉ cho thấy hai trạng thái: vận hành bình thường và vận hành gây tổn thất
• Chuyển tiếp từ vận hành bình thường sang vận hành gây tổn thất thường rất đột ngột, gần như không có thời gian ứng phó để ngăn tổn thất
• Lý do SRE dùng cả SLO burn nhanh và burn chậm cũng là để phát hiện vấn đề trước khi có thiệt hại thực tế, nhưng các SLO như vậy thường là thuộc tính của từng thành phần riêng lẻ
• STAMP chính thức hóa điều này thành trạng thái rủi ro ở cấp hệ thống
  • Trạng thái rủi ro là một trạng thái hoặc tập hợp điều kiện của hệ thống, khi kết hợp với một số điều kiện môi trường xấu nhất định, sẽ gây tổn thất cho một hoặc nhiều bên liên quan
• Trạng thái rủi ro không phải là hiện tượng ở cấp sự kiện riêng lẻ hay thành phần riêng lẻ
• Hệ thống có thể ở trạng thái rủi ro trong thời gian dài trước khi tai nạn xảy ra
  • Bug đã được đưa vào nhưng chưa bị kích hoạt
  • Cảnh báo đã phát sinh nhưng không ai nhận được
  • Máy chủ bị cấp phát thiếu tài nguyên nhưng bất ngờ nhận lưu lượng từ một tính năng phổ biến
• Mục tiêu kỹ thuật không phải là loại bỏ mọi lỗi đơn lẻ, mà là không để hệ thống rơi vào trạng thái rủi ro hoặc đưa hệ thống từ trạng thái rủi ro trở lại vận hành bình thường

Ví dụ quota rightsizer năm 2021

• Google thiết lập và thực thi quota tài nguyên cho một số phần mềm trong hạ tầng nội bộ
• Để tăng hiệu quả, hệ thống giám sát mỗi dịch vụ dùng bao nhiêu trong quota của mình, và tự động giảm quota nếu dịch vụ liên tục dùng ít
• Từ góc nhìn STPA, quota rightsizer có một hành động điều khiển là giảm quota của dịch vụ
• Hành động này trở nên không an toàn khi rightsizer giảm quota xuống thấp hơn nhu cầu thực tế của dịch vụ
  • Dịch vụ rơi vào trạng thái thiếu tài nguyên
  • Trong STPA, đây được gọi là hành động điều khiển không an toàn, tức UCA
• UCA có bốn loại
  • Hành động điều khiển cần thiết không được cung cấp
  • Hành động điều khiển không chính xác hoặc không đầy đủ được cung cấp
  • Hành động điều khiển được cung cấp sai thời điểm hoặc sai thứ tự
  • Hành động điều khiển bị dừng quá sớm hoặc được áp dụng quá lâu
• Việc giảm quota xuống thấp hơn nhu cầu thực tế là UCA thuộc loại thứ hai

Điểm yếu lộ ra trên đường phản hồi

• Yêu cầu an toàn có thể được tóm gọn là “quota rightsizer không được giảm quota xuống thấp hơn nhu cầu hiện tại của dịch vụ”
• Yêu cầu này hữu ích cho thiết kế tương lai, kế hoạch kiểm thử và việc hiểu hệ thống
• STPA cấu trúc việc phân tích để tìm các kịch bản cụ thể khiến yêu cầu an toàn này bị vi phạm
• Trong ví dụ rightsizer, có thể điều tra bốn kịch bản tiêu biểu
  • Bản thân rightsizer hoạt động sai
  • Rightsizer nhận phản hồi sai hoặc không nhận được phản hồi nào
  • Rightsizer cố gửi hành động nhưng hệ thống quota không nhận được
  • Bản thân hệ thống quota hoạt động sai
• Kịch bản nổi bật trong thực tế là trường hợp phản hồi về mức sử dụng tài nguyên hiện tại được tính quá thấp
  • Việc tính toán mức sử dụng tài nguyên bao gồm nhiều bộ thu thập dữ liệu và logic tổng hợp phức tạp
  • Nếu kết quả tính toán thấp hơn thực tế, rightsizer vẫn hoạt động đúng thiết kế nhưng lại giảm quota sai
• Trước đây có nhiều sự chú ý dành cho thuật toán điều chỉnh quota và độ chính xác của đầu ra, nhưng đường phản hồi ít được hiểu hơn
• STPA giúp phát hiện vấn đề không chỉ trên đường điều khiển mà cả đường phản hồi; trong phân tích nhiều hệ thống của Google, cũng thường thấy đường phản hồi ít được hiểu rõ

Dòng diễn biến từ sự cố đến tổn thất

• Trong sự cố năm 2021, phản hồi sai về tài nguyên đang được sử dụng bởi một dịch vụ quan trọng của hạ tầng Google đã được gửi đến rightsizer
• Rightsizer tính quota mới, dẫn đến việc cấp phát lượng tài nguyên thấp hơn rất nhiều so với mức sử dụng thực tế
• Như một biện pháp phòng ngừa, việc giảm quota không được áp dụng ngay mà bị giữ lại trong vài tuần để có thời gian cho ai đó can thiệp
• Tuy nhiên, phản hồi về pending change không được truyền đạt đến bất kỳ ai
• Hệ thống ở trạng thái rủi ro trong nhiều tuần, nhưng vì không ai tìm kiếm trạng thái đó nên cơ hội ngăn tổn thất đã bị bỏ lỡ
• Vài tuần sau, khi việc giảm quota được áp dụng, một sự cố đáng kể đã xảy ra
• Google đã dùng STPA để dự đoán trước các vấn đề tương tự trong nhiều hệ thống

Hướng đi của SRE tại Google

• SRE của Google không xem độ phức tạp là bug, mà đang chuyển sang một cách tiếp cận độ tin cậy toàn diện và chủ động hơn bằng cách dùng lý thuyết điều khiển, STPA và CAST
• Mục tiêu không chỉ là phản ứng với sự cố, mà là thiết kế các hệ thống an toàn hơn ngay từ đầu
• Google đã phân tích một số hệ thống phức tạp nhất bằng STPA, và với nỗ lực cỡ engineer-weeks cho mỗi lần phân tích, đã tìm ra hàng trăm kịch bản với nhiều phạm vi ảnh hưởng khác nhau
• Các kịch bản được phát hiện được giảm thiểu trước khi dẫn đến sự cố
  • Sửa tạm nhanh
  • Kỹ thuật phần mềm được lập kế hoạch cẩn trọng hơn
  • Tận dụng quy trình lập kế hoạch định kỳ của Google để giảm thiểu chi phí và gián đoạn
• Công việc hiện tại tập trung vào các hệ thống Google Cloud rất phức tạp, hệ thống mạng nội bộ quy mô lớn và nhiều sản phẩm Google
• Việc SRE chuyển sang phương pháp luận an toàn hệ thống cung cấp cho kỹ sư một cách mới để hiểu các hệ thống họ xây dựng, đồng thời hướng tới việc đưa ra các bảo đảm mạnh hơn về cách hệ thống vận hành