STPA - Đào tạo phương pháp phòng ngừa sự cố mới của Google SRE

• STPA (System Theoretic Process Analysis, phân tích quy trình theo lý thuyết hệ thống) là phương pháp mô hình hóa vòng lặp điều khiển-phản hồi của các hệ thống phức tạp dựa trên lý thuyết hệ thống và điều khiển
  • Google sử dụng STPA để phân tích các hệ thống phần mềm và phát hiện các rủi ro tiềm ẩn
• STPA xem an toàn hệ thống là một bài toán điều khiển, đồng thời phân tích mọi hành động điều khiển có thể khiến hệ thống rơi vào trạng thái nguy hiểm
• Thay vì tập trung vào kết quả của từng hành động riêng lẻ, phương pháp này tập trung vào trạng thái nguy hiểm để tìm ra nguyên nhân gốc rễ
  • Khi hiểu được các hành động điều khiển dẫn tới trạng thái nguy hiểm, có thể ngăn chặn chúng hoặc tự động phục hồi
  • Nếu khó tự động phục hồi, có thể cảnh báo cho người vận hành

Vì sao Google tùy biến chương trình đào tạo STPA

• Ngày càng có nhiều trường hợp thành công trong việc phát hiện trước các vấn đề chưa được nhận diện và ngăn ngừa sự cố nhờ STPA
• Tài liệu đào tạo STPA hiện có chủ yếu được xây dựng xoay quanh các hệ thống vật lý nên khó áp dụng vào môi trường phần mềm
• Vì vậy cần một chương trình đào tạo được tùy biến cho các hệ thống thuần phần mềm của Google

Những thử nghiệm đào tạo STPA ban đầu

• Bắt đầu đào tạo ban đầu từ năm 2021 (cho 40 kỹ sư Google)
• Sử dụng các ví dụ về hệ thống vật lý (ví dụ: vụ rơi của Mars Polar Lander) → các kỹ sư phần mềm khó đồng cảm
• Từ đó nhận ra cần những ví dụ thực tế được áp dụng trên các hệ thống của Google

Đào tạo về khái niệm cấu trúc điều khiển

• Cấu trúc điều khiển (control structure) được tạo thành từ các vòng lặp điều khiển-phản hồi cơ bản
  • Bộ điều khiển điều khiển việc thay đổi trạng thái → xác nhận trạng thái qua phản hồi rồi quyết định hành động tiếp theo
• Ví dụ áp dụng trong môi trường phần mềm
  • Ví dụ: xóa hoặc sửa nội dung sai trong cơ sở dữ liệu nội dung do người dùng tạo
  • Nếu vòng lặp phản hồi không được thiết kế đúng, có thể phát sinh hành động điều khiển sai
• Thách thức trong đào tạo
  • Khó đào tạo cách thiết kế cấu trúc điều khiển hữu ích trong thời gian hạn chế
  • Mỗi hệ thống phần mềm có cấu trúc điều khiển khác nhau nên khó đưa ra phản hồi

Chiến lược cải thiện đào tạo STPA

• Đào tạo toàn bộ các bước của STPA → hỗ trợ kỹ sư có thể tự thực hiện STPA một cách độc lập
• Sử dụng các trường hợp thực tế của Google → giải thích lý thuyết rồi áp dụng vào ví dụ thực tế
• Tập trung tăng cường đường phản hồi trong cấu trúc điều khiển
  • Phân tích các trường hợp phản hồi sai → dẫn đến hành động điều khiển sai → gây ra sự cố
  • Thiếu phản hồi cho người vận hành → dẫn đến trạng thái nguy hiểm

Tầm quan trọng của phản hồi

• Trong một hệ thống của Google, phản hồi sai đã dẫn đến hành động điều khiển sai sau 30 ngày → gây ra sự cố
• Nguyên nhân là phản hồi sai và thiếu phản hồi cho người vận hành
• Nếu thiết kế phản hồi đúng cách, có thể ngăn ngừa sự cố
• Vụ nổ tên lửa Ariane 5 cũng là một ví dụ về lỗi phản hồi
  • Lỗi xảy ra khi chuyển đổi dữ liệu dấu chấm động sang số nguyên
  • Lỗi phản hồi → nhận diện trạng thái sai → sai hướng tên lửa và phát nổ

Sơ đồ luồng dữ liệu vs. cấu trúc điều khiển

• Sơ đồ luồng dữ liệu (Dataflow Diagram)
  • Cho thấy dữ liệu di chuyển giữa các thành phần phần mềm như thế nào
  • Không làm rõ phản hồi và cấu trúc điều khiển
• Cấu trúc điều khiển (Control Structure)
  • Hiển thị các hành động điều khiển và phản hồi → làm rõ hệ thống phân cấp điều khiển
  • Dễ xác định vấn đề phản hồi → có thể truy vết nguyên nhân vấn đề trong các tương tác hệ thống phức tạp

Hiệu quả khi áp dụng STPA

• Trong phần mềm phức tạp, STPA thu hẹp phạm vi từ hàng triệu dòng mã xuống vài trăm dòng có khả năng cao gây ra vấn đề
• Xây dựng kịch bản cho các hành động điều khiển nguy hiểm → có thể xác định đoạn mã gây lỗi
• Trong các trường hợp thực tế, sau khi xây dựng cấu trúc điều khiển đã xác định và sửa các điểm thiếu phản hồi

Thay đổi trong chiến lược đào tạo

• Chuyển từ thời lượng đào tạo dài sang các phiên học ngắn
  • Hướng dẫn 30 đến 60 phút → thu hút các kỹ sư quan tâm tham gia workshop
• Áp dụng mô hình học tập tự chủ
  • Video ngắn + bài tập → khuyến khích áp dụng STPA vào hệ thống thực tế
  • Tăng cường đào tạo để có thể thực hiện STPA ban đầu mà không cần chuyên gia can thiệp

Chiến lược mở rộng STPA trong Google

• Đào tạo chuyên gia STPA → có thể lan tỏa STPA trong nội bộ nhóm
• Thành công ban đầu → mở rộng sang các nhóm khác → áp dụng STPA trên toàn tổ chức
• Sau đào tạo STPA, có thể loại bỏ trước các yếu tố rủi ro ngay từ giai đoạn thiết kế

Cũng có thể áp dụng ở các doanh nghiệp khác

• STPA là công cụ mạnh để tìm ra các “yếu tố rủi ro chưa được nhận diện” trong các hệ thống phần mềm phức tạp
• Có thể bắt đầu từ các nhóm nhỏ rồi mở rộng dưới sự dẫn dắt của chuyên gia STPA
• Việc phát triển chương trình đào tạo STPA được tùy biến phù hợp với từng doanh nghiệp là then chốt
• Sau những thử và sai ban đầu có thể điều chỉnh hướng đi → cuối cùng nâng cao độ ổn định và độ tin cậy của hệ thống

[GN⁺]

Bình luận trên Hacker News

• Có một trường hợp tại Google khi một bộ điều khiển phần mềm nhận phản hồi sai và thực thi một hành động điều khiển nguy hiểm

  • Hành động này được lên lịch để thực thi sau 30 ngày
  • Có các dấu hiệu cho thấy hành động nguy hiểm sẽ xảy ra, nhưng không có kỹ sư nào theo dõi chúng
  • Cuối cùng, sau 30 ngày, hành động điều khiển nguy hiểm đã xảy ra và gây gián đoạn dịch vụ
  • Có ý kiến thắc mắc liệu đây có phải là vụ xóa cơ sở dữ liệu của chính phủ hay không
  • Việc cố gắng khái quát hóa theo hướng không đổ lỗi là tốt, nhưng bài viết dùng phong cách quá cường điệu nên không học được gì

• Khóa học STPA được cấu trúc tốt và ví dụ của Google khá hữu ích

  • Tuy nhiên, bản thân bài viết lại không có ví dụ cụ thể

• STPA là một framework review thiết kế để tìm ra các chế độ lỗi ít rõ ràng hơn

  • FMEA phổ biến hơn, nhưng chỉ liệt kê các chế độ lỗi đã biết sẵn
  • STPA bổ sung những chế độ lỗi mà người ta chưa nghĩ tới

• Có ý kiến nói rằng nội dung khó hiểu nhưng vẫn muốn tìm hiểu

  • Cần có giải thích cụ thể về cách nó được áp dụng cho một dịch vụ nhất định ở Google
  • Bài viết chưa giải thích đầy đủ vì sao việc "B thiếu phản hồi từ C" lại là điều xấu

• Nếu có các ví dụ thực tế về việc STPA đã giải quyết vấn đề độ tin cậy tại Google thì bài viết sẽ thuyết phục hơn

• STAMP/STPA hoạt động tốt như một mô hình và phương pháp luận cho các hệ thống phức tạp

  • Có người từng quan tâm đến việc định lượng rủi ro an ninh mạng
  • Trong các cách tiếp cận khác, không có mô hình nào giúp dễ hiểu các hành động điều khiển nguy hiểm
  • Mong rằng sẽ có nhiều công ty áp dụng nó hơn

• Sau khi hợp tác với các chuyên gia hệ thống để xây dựng cấu trúc điều khiển, người ta ngay lập tức nhận ra rằng bộ điều khiển C thiếu phản hồi gửi tới B

  • Có một vòng lặp phản hồi thông qua D
  • Có người thắc mắc vì sao vấn đề không phải là việc thiếu kết nối trực tiếp từ B tới D
  • Đọc lại thì nhận ra hướng theo chiều dọc là yếu tố quan trọng để biểu thị điều khiển và phản hồi

• Đây là kiểu kể chuyện cường điệu của doanh nghiệp, dùng từ ngữ thời thượng và cố làm cho những ý tưởng cũ trông như đổi mới

  • Có một nỗ lực khá gượng ép khi liên hệ câu chuyện sửa radio thời thơ ấu với STPA
  • Google tuyên bố việc áp dụng STPA vào phần mềm là đổi mới, nhưng thực ra đây là phương pháp cũ
  • Phần lớn nội dung chỉ là các khái niệm kỹ thuật cơ bản về vòng lặp phản hồi và cấu trúc điều khiển
  • Thông điệp thực sự là Google đã tạo ra một chương trình đào tạo nội bộ
  • Phần cuối mang kiểu chiến lược doanh nghiệp quen thuộc rằng bạn bắt buộc phải dùng STPA

• Có ý kiến cho rằng Google nên im lặng một năm trời và chỉ phát ra tiếng máy hút bụi