Trạng thái Nguy hiểm và Tai nạn: Bài học về an toàn hệ thống cho kỹ sư phần mềm

Tôi đã lâu muốn viết về việc tại sao phân tích nguyên nhân gốc rễ (root cause analysis) thực chất là một kỹ thuật tồi để học hỏi từ những thất bại. Tuy nhiên, để làm được điều đó, chúng ta cần nắm vững một số nguyên tắc cơ bản trước. Những kiến thức này cực kỳ hữu ích cho bất kỳ ai đang thiết kế các hệ thống mà họ muốn hoạt động một cách đáng tin cậy.

Hazardous States and Accidents

Nguy cơ là một tai nạn đang chờ xảy ra

Trong các hệ thống an toàn nghiêm ngặt (safety-critical systems), chúng ta phân biệt rõ giữa tai nạn (thiệt hại thực tế, ví dụ: mất mạng người, hỏng thiết bị, v.v.) và trạng thái nguy hiểm (đôi khi chỉ gọi là "nguy cơ"). Nếu gọi (H) là trạng thái nguy hiểm, (E) là điều kiện môi trường, và (A) là tai nạn, thì phương trình sẽ là:

[H \land E \Leftrightarrow A]

Điều này có nghĩa là một tai nạn đòi hỏi cả hai yếu tố: điều kiện môi trường bất lợi và hệ thống đang ở trạng thái nguy hiểm. Hệ quả là, nếu một hệ thống nằm trong trạng thái nguy hiểm, nó có thể bị đẩy vào tai nạn bởi những điều kiện môi trường xấu.

Ngược lại, hệ thống có thể nằm trong trạng thái nguy hiểm trong một thời gian dài mà không xảy ra tai nạn nếu điều kiện môi trường đủ tốt.

Vì chúng ta chỉ có thể kiểm soát hệ thống chứ không thể kiểm soát môi trường của nó, chúng ta đạt được sự an toàn bằng cách tránh các trạng thái nguy hiểm. Nếu chúng ta cố gắng ngăn chặn tai nạn mà không chú ý đến trạng thái nguy hiểm, chúng ta đang thực sự đặt niềm tin vào việc môi trường sẽ đứng về phía mình. Nhiều người làm điều này và nó có thể thành công trong một thời gian, nhưng sớm muộn gì nó cũng sẽ thất bại.

Ví dụ từ hàng không

Gần đây, một chuyến bay thương mại đã làm rùm beng vì hạ cánh với lượng nhiên liệu còn lại dưới 30 phút. Nhiều người tự hỏi tại sao đây lại là vấn đề lớn, vì nghe có vẻ hệ thống đang hoạt động như dự định: có dự trữ, cần dùng đến, và đã dùng. Kết thúc câu chuyện?

Điều cần nhận ra là hạ cánh với ít hơn 30 phút nhiên liệu là một trạng thái nguy hiểm đối với các máy bay thương mại. Nếu một máy bay hạ cánh với ít hơn 30 phút nhiên liệu, thì chỉ cần một điều kiện môi trường xấu là đủ để khiến nó坠 máy thay vì hạ cánh an toàn. Do đó, chúng ta thiết kế hàng không thương mại để máy bay luôn còn 30 phút nhiên liệu khi hạ cánh. Nếu không, đó là vấn đề lớn. Chúng đã rơi vào trạng thái nguy hiểm, và chúng ta không bao giờ muốn thấy điều đó.

Ví dụ từ trò chơi trẻ em

Một trong những đứa con của tôi rất thích chơi quanh các vách đá và tảng đá. Ban đầu, nó rất hứa sẽ không bị ngã. Tôi đã giải thích sự khác biệt giữa tai nạn và trạng thái nguy hiểm cho nó (theo ngôn ngữ của trẻ em), và nó dần nhận ra rằng nó không thể kiểm soát việc mình có gặp tai nạn hay không, vì vậy hứa không bị ngã là một ý tưởng tồi.

Điều nó có thể kiểm soát là việc các điều kiện môi trường xấu có dẫn đến tai nạn hay không, và nó làm điều đó bằng cách giữ mình ra khỏi các trạng thái nguy hiểm. Trong trường hợp này, trạng thái nguy hiểm sẽ là đứng ở vị trí thấp hơn chiều cao của một đứa trẻ so với mép đá khi không có ai ở dưới sẵn sàng đỡ. Nó có thể hứa với tôi là tránh điều đó, và điều đó làm tôi hài lòng hơn nhiều so với lời hứa không bị ngã.

Duy trì các ràng buộc là một vấn đề kiểm soát động

Các điều kiện nguy hiểm, như chúng ta đã thấy, được định nghĩa bởi các ràng buộc. Để giữ mình ra khỏi các điều kiện nguy hiểm, chúng ta phải khiến hệ thống duy trì các ràng buộc an toàn đó. Tuy nhiên, nói chung, môi trường thường cố gắng đẩy hệ thống vào việc phá vỡ các ràng buộc này, và thường làm theo những cách không thể đoán trước. Điều này có nghĩa là chúng ta không thể tuyên bố trước một chuỗi các bước mà hệ thống nên tuân theo để luôn duy trì các ràng buộc.

Thay vào đó, duy trì các ràng buộc là một vấn đề kiểm soát động. Có nhiều bộ điều khiển tương tác với hệ thống để cố gắng giữ nó ra khỏi các điều kiện nguy hiểm. Chúng quan sát phản hồi (feedback), tức là thông tin về vị trí hiện tại của hệ thống; chúng thực thi các mô hình tư duy, tức là chạy các mô phỏng về vị trí tương lai của hệ thống; và sau đó chúng đưa ra các hành động điều khiển, tức là cố gắng điều chỉnh hệ thống để duy trì các ràng buộc dựa trên dự đoán của họ.

Bất cứ khi nào một hệ thống rơi vào điều kiện nguy hiểm, đó là vì có vấn đề với cấu trúc điều khiển, cụ thể là một trong ba thành phần được liệt kê ở trên:

• Phản hồi đến các bộ điều khiển có thể không đủ, nghĩa là các bộ điều khiển không hiểu chuyện gì đang xảy ra với hệ thống tại một thời điểm cụ thể.
• Mô hình tư duy có thể không đủ, nghĩa là các bộ điều khiển hiểu chuyện gì đang xảy ra với hệ thống, nhưng chúng không thể dự đoán điều gì sẽ xảy ra trong tương lai.
• Hành động điều khiển có thể không đủ, nghĩa là các bộ điều khiển biết chúng cần làm gì với hệ thống để duy trì các ràng buộc, nhưng hành động đó không tạo ra tác động với cường độ mong muốn. (Điều này có thể vì tác động quá yếu — hoặc quá mạnh!).

Chúng ta cũng có thể thấy sự kết hợp của các vấn đề này. Khi cả ba đều gặp vấn đề, chúng ta có thể đang thực sự nhìn thấy một bộ điều khiển toàn bộ bị thiếu vắng mà lẽ ra phải có mặt.

Các bộ điều khiển tồn tại ở mọi cấp độ. Đối với máy bay duy trì các ràng buộc về nhiên liệu, các bộ điều khiển bao gồm hệ thống điều khiển động cơ đầy đủ (FADEC) bên trong động cơ phản lực, máy tính quản lý chuyến bay, phi công, nhân viên mặt đất, người điều phối tại hãng hàng không, chương trình đào tạo phi công, kiểm soát không lưu, cũng như các hội đồng quy định quốc gia và quốc tế. Đối với đứa trẻ của tôi giữa những tảng đá, các bộ điều khiển bao gồm sự cân bằng, sức mạnh, ý thức tự bảo vệ cực kỳ hạn chế của nó, chỉ dẫn của tôi, sự giám sát của tôi, những nơi tôi quyết định đưa chúng ta đến, v.v.

Các bộ điều khiển cấp thấp thường được tự động hóa, trong phần cứng hoặc phần mềm. Các bộ điều khiển cấp cao thường mang tính xã hội, văn hóa và pháp lý.

Dự đoán trạng thái nguy hiểm dễ hơn dự đoán tai nạn

Các tai nạn trong hệ thống an toàn nghiêm ngặt có thể trông giống như những sự cố hiếm gặp, kỳ quái mà không thể dự đoán trước. Cơ hội một chuyến bay gặp chậm trễ trên đường, sau đó phải cố gắng hạ cánh nhiều lần tại điểm đến dự định bao gồm cả sự chậm trễ ở đó, chuyển hướng, không thể hạ cánh tại sân bay dự phòng, và phải đi khá xa đến một sân bay thứ cấp là bao nhiêu? Điều này là vì để tai nạn xảy ra, không chỉ chúng ta cần điều kiện môi trường xấu, mà còn nhiều bộ điều khiển phải không thể duy trì các ràng buộc an toàn. Sự kết hợp này có vẻ khó xảy ra. Tuy nhiên, bằng cách suy nghĩ theo các trạng thái nguy hiểm thay vì tai nạn, chúng ta có lợi thế là các trạng thái nguy hiểm dễ dự đoán hơn.

Hãy nghĩ về bất kỳ công nghệ phổ biến nào, như ô tô. Chúng ta có thể liệt kê nhanh một số ràng buộc mà chúng ta muốn nó duy trì, một số khá bình thường. Ô tô của chúng ta không được thực hiện một cú quay đột ngột không có lệnh, ví dụ. Một trong những bộ điều khiển duy trì ràng buộc này là độ ổn định dương trong trục quay: nếu chúng ta buông tay lái trên mặt đất phẳng, nó sẽ tự động quay trở lại vị trí trung tâm theo thời gian. Điều này đảm bảo những va đập nhỏ chỉ làm chúng ta chệch hướng một chút, lúc đó một bộ điều khiển khác sẽ can thiệp: người lái xe thực hiện một điều chỉnh nhỏ để đưa hướng đi trở lại như cũ. Ở một số ô tô, một lớp tự động hóa khác sẽ tiếp quản trước người lái: phần mềm hỗ trợ giữ làn đường có thể thực hiện việc sửa chữa đó.

Chúng ta không cần thực sự chứng kiến một vụ tai nạn ô tô do cú quay không có lệnh gây ra để nhận ra đó sẽ là điều tồi tệ nếu một chiếc ô tô bắt đầu quay đột ngột không có lệnh. Bây giờ chúng ta có thể tiếp tục làm việc với các bộ điều khiển của mình — tại sao trục quay lại có độ ổn định dương? Nó có thể hỏng không? Chắc chắn rồi, nếu áp suất lốp không đều. Đó là một ràng buộc khác mà chúng ta có thể thiết kế các cấu trúc điều khiển xung quanh, và cứ thế.

Phân tích nguy cơ như tai nạn

Lợi ích thêm của việc suy nghĩ về các trạng thái nguy hiểm thay vì tai nạn là chúng ta không phải đợi một tai nạn xảy ra trước khi cải thiện sự an toàn của hệ thống. Việc không thể duy trì các ràng buộc đã là một vấn đề an toàn và nên được phân tích bất kể điều kiện môi trường có đứng về phía chúng ta vào ngày hôm đó hay không, tức là liệu nó có biến thành tai nạn hay không.

Điều này có vẻ hiển nhiên. Nếu chúng ta đã thiết kế một chiếc ô tô bắt đầu một cú quay đột ngột không có lệnh, chúng ta sẽ không đợi nó làm bị thương ai trước khi giải quyết vấn đề. Nhưng tôi thường thấy mọi người — đặc biệt là trong ngành công nghiệp phần mềm — lờ đi các sự cố suýt xảy ra (near misses) miễn là không ai bị hại. Ngành hàng không thì không như vậy. Bạn có thể cá là các hội đồng an toàn sẽ đưa ra các báo cáo về chuyến bay hạ cánh với ít hơn 30 phút nhiên liệu.

Thêm về an toàn và lý thuyết hệ thống

Các ý tưởng được đề cập trong bài viết này chủ yếu đến từ góc độ lý thuyết hệ thống về an toàn. Một trong những nhân vật trung tâm trong việc thúc đẩy góc nhìn này là Nancy Leveson. Tôi là một người hâm mộ lớn các công trình của bà, trong số đó có các cuốn sách Engineering a Safer World, CAST Handbook, và STPA Handbook.

Vấn đề của những cuốn sách này là chúng (a) không được biết đến rộng rãi, và (b) khá dày đặc và chứa đựng hàng thập kỷ kinh nghiệm của Leveson.

Tôi muốn trình bày một góc nhìn đơn giản, dễ hiểu về an toàn theo lý thuyết hệ thống, nhưng tôi thấy khó để cấu trúc nó tốt. Bài viết này là một trong số hy vọng sẽ là một loạt bài đi qua các điểm quan trọng. Vì đây là một chủ đề rộng lớn, chúng ta mới chỉ lướt qua bề mặt cho đến nay. Một số điều tôi muốn đưa ra sau này bao gồm:

• Ngoài việc tránh tai nạn, giảm thiểu hậu quả của chúng là một phần quan trọng của an toàn. Khi so sánh độ tin cậy giữa các hệ thống tương tự, tôi gần như luôn thấy rằng hệ thống đáng tin cậy hơn thực sự thất bại thường xuyên hơn, nhưng với hậu quả ít nghiêm trọng hơn.
• Chúng ta có thể thiết kế hệ thống để làm cho các bộ điều khiển hiệu quả hơn. Cải thiện chất lượng phản hồi thường là "trái cây thấp treo" (dễ thực hiện), cả vì nó cải thiện sự hiểu biết về hệ thống, và đặc biệt vì nó cho phép các nhà vận hành tự đào tạo các mô hình tư duy tốt hơn.
• Các nhà thiết kế hệ thống thường có các mô hình tư duy không chính xác. Điều này có nghĩa là tuân thủ các quy trình (được thiết kế bởi nhà thiết kế hệ thống) không chỉ có thể ngăn chặn tai nạn, mà còn có thể gây ra chúng.
• Phân tích nguyên nhân gốc rễ, và nhiều kỹ thuật tương tự, dựa trên một lý thuyết nhân quả được đơn giản hóa quá mức.
• Lỗi của con người không phải là kết thúc của phân tích tai nạn, mà là một điểm khởi đầu tốt.
• Bất kỳ quyết định nào trong quá khứ đều phức tạp hơn những gì chúng ta thấy bây giờ.
• Chúng ta có thể học hỏi nhiều hơn từ các tai nạn so với những gì chúng ta đang làm hiện nay. Điều đó tốn nhiều công sức hơn cho mỗi tai nạn, nhưng sự đánh đổi là xứng đáng vì chúng ta học hỏi chung chung hơn và điều này cải thiện độ tin cậy nhiều hơn so với việc chúng ta thực hiện các phân tích nông hơn trên ít tai nạn hơn.
• Cách thực sự thực hiện phân tích một hệ thống từ góc độ này, theo một chuỗi các bước quy định.

Tôi không biết bao giờ chúng ta sẽ thấy phần còn lại của những bài này, nhưng hãy theo dõi. Nếu bạn là người hâm mộ RSS, bạn biết phải làm gì. Nếu không, bạn có thể đăng ký qua email.